Engineering

最近看到不少关于 harness engineering 的文章，中文圈和英文圈都有。 但大多数只是在讲概念，细节很少。而且说实话，有些系统描述得太复杂了，很难相信它们真的能稳定跑起来。 于是周末我自己动手试了试。 说来有点好笑，我做过很多个人项目，但大部分撑不过 10 次迭代。所谓"撑不住"，就是进入了一种死循环：加一个功能引入了 bug，修这个 bug 又带来新的 bug。 而 harness engineering 要解决的，正是这种螺旋式崩塌。 很多人把它讲得很复杂。但我自己尝试下来，核心思路其实挺朴素的。原文 中其实有两点，我觉得非常关键。 第一条：让 worktree 能直接启动。 这是让多个 agent 并行工作的前提。 前端包管理器用 bun（或者 pnpm），不要把时间浪费在装依赖上。数据 pipeline 的环境依赖用 uv 管理。每一个 worktree 都能快速启动。 第二条：定好标准。 把每个需求当成一张完整的 ticket 来处理。Lint、单元测试、构建通过——这些是基础。但如果是有 UI 的应用，UI 测试是比较关键的一环。 这里我用的是 agent browser 和 Playwright CLI 。它们和传统 e2e 测试不同，不会因为 selector 变了就挂掉。你只需要配合它们跑一两轮，描述你的应用长什么样，然后把结果写进一个 markdown 文件。 之后你只需要说：“当我点击 X Button 时，Y 应该出现。” 验证规则用纯自然语言描述就行了。 定下这两条规则花了我最多的时间。剩下的——技术栈和基础设施——我自己来决定。代码交给 agent 写，架构还是得自己拿主意。 然后，构建过程就开始自己运转起来了。 我创建了一个叫 decision-plan 的 skill。 ...