继续分享一些 harness engineering 实际经验

坦白说，在做 haicode (一个我自用的 coding agent) 的过程中，我通过 Harness 方案借鉴了 Claude Code 的不少优秀设计。虽然功能复刻个七七八八，但整体使用体验始终不如 CC 丝滑，比如有的任务执行很顺，有的任务执行就不收敛。

我今天静下心来想了下，只有功能点对齐是不够的，必须深入对齐其底层机制，正好 k2.6-code 发布，跑通了一套“四步对齐法”，效果我觉得还行，分享一下希望对你有帮助。

haicode 目前有接近 10w 行 golang，要对齐 CC 50w 行ts，确实有点困难。通过人眼来对齐肯定是没什么可能性了，看不过来。

所以需要引入文档作为中间层来对齐，我选择的是 PRD 做事实层面的对齐。分四步走

第一步：PRD 宏观对齐（Gap Analysis）

Prompt 示例：「请帮我比对当前项目与上游 Claude Code 的源码，找出我们在架构和体验上还有哪些差距？重点关注 Agent Loop、上下文管理、Agent Teams 等核心模块。请将不完善的地方拆解成独立的 PRD，并输出到 docs/product-specs 目录中」

需要注意的是，不需要像我一样说的很规范，现在 k2.6 之类的国模都比较聪明，在实际使用的过程中可以用语音说很长的一些废话，意思到位，最后确保放入对应目录中就行了。

第二步：PRD 细化与反思（Deep Dive & Questioning）

要求模型在 PRD 中明确标注“当前实现”与“上游实现”的具体差距（Delta），客观评价当前做得好的与不好的地方。

「请基于这里的 PRD结合上游源码，评价当前做得好的与不好的地方，提出你在分析过程中遇到的‘开放式问题’（例如设计意图、edge case）来问我。」

第三步：PRD 细化与反思（Deep Dive & Questioning）

使用提示词：「对于你刚才提出的开放式问题，请你直接从上游 Claude Code 的代码库中寻找答案，并补充到 PRD 中」

这时候再进行人工审核。Harness 开发中 80% 的常规逻辑模型能快速搞定，但剩下 20% 决定体验的核心逻辑，必须依赖我们把 PRD 抠得足够细。

有的朋友可能会问我为啥咱不一步到位，把三步 PRD 生成的提示词写在一起？因为效果不好。精细一些的活，分开一步一步来效果比较可控。

第四步：转化执行计划（Actionable Plan）
「请将所有梳理出的差距和 PRD 改写成具体的执行计划（Execution Plan），并放入 docs/exec-plans 目录」

然后就把 plan 目录拖到终端，让他开始干活。在 claude code 中每次干活时间还挺长的（ 没有调优的情况下，我看一个 todo 能干超过 30~40min）

因为是每个月 199 的套餐，最终我验收了两个 plan，效果还不错。

但 cc + kimi 也有一些不爽的地方，估计 claude code 有 bug，有的时候给我弹 API Error: Claude Code is unable to respond to this request

另外在调试 haicode 这种智能体上面，我还用了其他的模型 GLM 5.1 / GPT 5.4 / Opus，我的感觉是模型

GLM 5.1, 比较稳扎稳打：在连带智能体调试的体验上还不错，不会乱飞。

GPT 5.4 / Codex (容易过度设计)：它有一种“工程兜底”的强迫症。有时候会情不自禁地发明一些超出 Claude Code 原本路线的解法，比如居然想用关键词来做意图检测，反而把简单问题复杂化了。

Opus 4.6 agent 调试agent最强：在代码拆解和逻辑洞察上的表现应该是最好的， 能够连带 提示词 + 工程一起改，效果最好，但但但但我分析了两天之后 5x 订阅掉了（不知道是相关性还是因果性）......血亏🤣

点击图片查看原图