Harness的最佳实践:DSH的64天启示录
前一篇文章我做了 DeepSeek Harness(DSH)的 git 考古,拆解了它 64 天 12293 次提交背后的构建哲学——《用Agent造Agent:DeepSeek Harness的64天考古与自进化路径》。那篇是「DSH 是什么、怎么造的」。这篇是「DSH 的经验怎么用」——把那 64 天里被验证过的工程判断,提炼成普通团队可以落地的 AI 辅助开发实践。 先说清楚为什么值得这么做。DSH 不是又一个「我们用了 AI 写代码所以快」的故事。如果只是这个,Copilot 上市五年了,行业早该被颠覆。DSH 真正反常理的是:一个不到 20 人的团队,用 64 天长出一个 221 包的 agent 运行时,工程严谨度却高得不像 AI 写的——100% 测试覆盖率门、运行时断言强制不变量、设计决策可追溯到每个 commit。这不是「AI 写代码快」,是「harness 思维组织 AI 开发」。 这件事,恰恰是所有正在探索AI辅助研发(甚至是AI主导研发)的工程团队、乃至技术Leader或负责人们日日琢磨的核心命题——如何让AI提速的同时,守住工程严谨的底线;如何把AI从「脱缰的效率工具」驯化为「可控的研发协作者」。正因如此,这套从DSH 64天实战中淬炼出的方法论,绝非空泛的理论,而是值得每一支团队深思、拆解并落地的可行路径。 一、认知转变:从「用 AI 写代码」到「用 harness 组织 AI 开发」 市场上有四个比较成熟的 AI 辅助开发流派,先把它们摆清楚: 流派一:Copilot/Cursor 模式——AI 当打字员。人主导写代码,AI 补全和局部重构。这是目前最普及的模式,门槛低,但天花板也低——AI 只能在人画的圈子里做事,产出节奏受限于人的审查速度。 流派二:Claude Code/Codex 单 agent 模式——AI 当执行者。人给一个任务描述,AI 执行多步任务(改多个文件、跑测试、修 bug)。这是 Cursor Composer、Claude Code 的典型用法。天花板比流派一高,但问题是 agent 会自己跑偏,没有不变量挡着,跑几次就积累一堆边界情况。 流派三:Aider 模式——git commit 驱动。AI pair programmer,每次改动自动 commit,人通过 git history 审查。这个模式把 git 当成 AI 产出的审计层,是个好思路,但它只管「改了什么」,不管「为什么这么改」和「规则有没有被破坏」。 ...