我从0到1写了个开源工具，让Trae、Claude Code这类AI在项目里学会「分工协作」
起因：当我把Trae当作「万能程序员」来用的时候
我和很多朋友一样，是Trae的早期用户。说实话，刚用上Trae SOLO模式的时候，那种感觉真的很奇妙——用自然语言描述需求，它就能自动拆解任务、写代码、跑测试，就像一个不知疲倦的搭档。
但问题也随之而来。
我用Trae写了几个小项目，逐渐发现一个规律：当项目比较小、只有几个文件的时候，Trae的表现堪称完美。可一旦项目变复杂——文件多了、依赖多了、历史代码积累多了——它就开始「恍惚」。有时候它会忘记之前自己做的决策，在几个方案之间反复横跳；有时候写了代码却不跑测试，导致小问题滚雪球；最头疼的是，当我新建一个会话让它接着干活时，它完全不知道上一轮发生了什么，需要我花大量时间重新「喂」上下文。
这让我开始思考一个问题：不是Trae不够聪明，而是我们给AI的项目环境本身出了问题。
转折：我发现了「Harness Engineering」这个新概念
今年年初，开发者社区开始频繁提到一个词：Harness Engineering（驾驭工程）。
什么意思呢？简单来说：模型是发动机，Harness是方向盘、刹车和仪表盘。 光有一台好发动机没用，你得有一套完整的控制系统，车才能安全、稳定地开到目的地。
我看到OpenAI发布了一篇技术博客，讲他们内部一个实验：3个工程师，5个月，用AI生成了超过100万行生产级代码，没有一行代码是人手写的。他们是怎么做到的？核心秘密不是什么超级模型，而是一套精心设计的「Harness」——让AI在结构化环境中按规则办事。
这个发现让我豁然开朗。Trae、Claude Code、Codex这些工具本身已经很强了，它们缺的不是更强的模型，而是一个能让它们有序协作的「工作台」。
尝试：我动手写了一个给AI用的「工作台生成器」
作为一个编程基础一般的学生，我做不了什么复杂的AI系统。但我懂一个道理：复杂问题的解决，往往从「标准化」开始。
于是我从4月初开始，利用opencode写了这个工具——harness-init，是的，这个工具本身也是ai做的，当然我也尽量保证它是符合我和ai讨论过的harness engineering规范。它的功能很简单：
在命令行里输入
harness-init 你的项目名，就会自动生成一个结构完整的Python项目，但这个项目内置了给AI读的「工作说明书」。
具体来说，它生成了这几样东西：
1. 一本「岗位说明书」（AGENTS.md）
这个文件用自然语言定义了三个角色：
- Planner（规划者）：收到任务后，先分析需求，写出详细的执行计划，写到
.harness/plans/目录里，然后停下来等人类确认。 - Generator（生成者）：按照确认好的计划，一步步写代码、改文件，每完成一个逻辑单元就跑一遍测试。
- Evaluator（评估者）：代码写完后，切换视角，用批判性思维审查产出，看是不是真的满足了验收条件。
这三个角色不是三个不同的AI，而是让同一个AI在不同阶段切换不同的行为模式——就像一个人上班时在不同工位上轮岗，每个工位有明确的操作手册。
2. 一个「自动化检查站」（make verify）
生成的项目自带一条验证流水线：运行 make verify，会自动执行代码风格检查（ruff）和单元测试，而且要求测试覆盖率必须达到85%以上。这意味着无论AI写了什么代码，都可以一键验证质量——过不了这关，项目就是不合格的。
3. 一套「状态管理」系统（.harness/ 目录）
这里面有 plans/（存计划文件）、state/（存进度状态）、progress.json（记录任务完成情况）。这些文件让AI有了「外部记忆」——即使开了一个全新的会话，它只需要读这些文件，就能快速理解当前进展，而不是从头开始。
效果：Trae进入这样的项目后，体验变化很大
我自己用这个工具生成了几个项目，然后在Trae里打开，让它完成一些功能开发。明显的变化是：
- 不再「失忆」了：因为状态都写在文件里，即使我关掉Trae第二天再打开，它读了
.harness/progress.json就能接上之前的工作。 - 代码质量有保障了：每次它写完代码，我让它以Evaluator角色运行
make verify，过不了就自己修，直到通过。我几乎不用再盯着测试覆盖率发愁。 - 计划不再「飞起」：以前Trae容易「想到哪写到哪」，现在它必须先写计划文件，我确认后再执行，整个过程变得可控多了。
说实话，这个工具没有任何「高深」的技术。它不调用任何AI API，不训练任何模型，它只是在项目初始化的时候，把一套经过验证的协作规范「种」进了项目里。然后Trae、Claude Code、Codex这些真正的AI工具进入项目时，读到这些规范，就会按照规矩办事。
写在最后
做这个工具的过程中，我有一个很深的体会：AI时代，开发者的角色正在从「写代码的人」变成「定义问题和规则的人」。 我们不需要比AI更会写代码，但我们需要比AI更懂「如何让一群人（包括AI）高效协作」。
harness-init 目前还很早期，只在Python项目上验证过，功能也远谈不上完善。但我把它开源了出来，因为我真的相信「为AI搭建好的工作环境」这件事，会是接下来几年开发者需要掌握的重要技能。
如果你也在用Trae、Claude Code、Cursor这类工具，遇到过类似的问题，欢迎去看看这个项目，或者在社区里和我交流。我特别想知道，你们在AI编程中遇到过哪些「环境」或「协作」层面的坑——说不定这就是下一个值得标准化解决的问题。
GitHub仓库：https://github.com/renjianguojinqianfan/Project-Bootstrap-Harness
期待在Trae社区和大家一起交流AI编程的实践心得。