我年初花了1个多月搭了一套 Harness 工程体系，团队每天都在跑。需求澄清、PRD、架构、feature 规格、接口设计、开发计划、开发执行、测试，每个环节都是一个 skill，串成一条完整的链。说实话，我对这套东西是有感情的，它真金白银地解决了规模化协作里的一致性和可追溯，10 个 specs 串起来开发、换人接手、三个月后回来改，证据链都在。
这是前提！
但最近看到很多人宣扬，大模型能力太强了，不需要太重的Harness流程了。真的是这样吗？
一次让人难堪的对照实验
这两天我拿同一份 specs，用 Kimi K3 跑了两遍。
第一遍走完整技能链，开发计划把需求拆成实施计划，开发任务执行派发实现者、评审者、修复者、终审者，逐任务实现、审查、勾选、提交，跑完大概 1 小时 30 分钟，消耗699套餐当天 5 小时额度的 24%。
第二遍我绕过了Harness开发技能链，同一份 specs 直接丢给 Kimi K3，不写计划，不派评审，不强制 TDD 步骤，让它自己干，二十来分钟就完事了，额度才烧了一成多点。
说白了，我多花了三四倍的时间、一倍多的额度，换回来的产出其实差不多，我自己过了一遍，功能都在，质量也还行，该有的TDD，大模型自己也加上了。放在两个月前，模型自己能跑成这样，我想都不敢想。
这种结果挺打脸的。模型已经强到 Kimi K3、GPT 5.6 这个量级了，类似 superpowers 这种大型流程，是不是应该大幅简化，降低对细节的控制？
把我的 jero3 和 superpowers 摆在一起
我把自己那套 jero3 跟 superpowers 对比了一遍，发现一个挺有意思的事儿：两套体系在执行域几乎一模一样，真正重的地方，都在规约到计划那一段。
注意：我的技能名就是中文的
| 环节 | jero3 | superpowers |
|---|---|---|
| 需求与设计规约 | 需求澄清→PRD→业务/技术 feature 规格 | brainstorming |
| 架构 | 架构设计 | 混在 brainstorming 里 |
| API和Model设计 | 接口数据设计 | 混在 brainstorming 里 |
| 开发计划 | 开发计划（00_plan.yaml + 子计划） | writing-plans（单文件 plan.md） |
| 执行派发 | 开发任务执行 | subagent-driven-development + executing-plans |
| TDD | TDD 指导（自动） | test-driven-development |
| 评审 | 代码评审 + 评审意见处理 | requesting/receiving-code-review |
| 完成验证 | 完成验证 | verification-before-completion |
| 分支 | git worktree 搭建 + 开发收尾 | using-git-worktrees + finishing-a-development-branch |
| 质量域 | 质量Owner：接口测试、e2e、测试用例 | 空白 |
| 进度与变更 | pm/fm 状态机 + 监理 + 变更硬规则 | 空白 |
你看，TDD、worktree、评审、完成验证、子代理派发，两边几乎一一对应。执行域这块的 best practice 已经定下来了，没什么可吵的。
但是，这两套Harness体系共有的毛病，规约到计划那一段都写得特别重，重的方式还一模一样（就是计划要写完整的代码）。
计划写得越完整，越是给强模型戴枷锁
jero3 的开发计划，一个 feature 的计划是 00_plan.yaml 主计划加若干子计划 md，里面写的不是要点，是完整代码：接口契约、完整函数体、完整测试代码、逐字 TDD 步骤。开发任务执行的时候还要派四个角色，每任务两阶段审阅，重试上限 3。大一点的任务，在LLM卡的时候，甚至会跑一整天。
superpowers 这边一模一样的毛病。它的 writing-plans 产出一个单文件 plan.md，社区有人测过，差不多 5 万字符，执行时上下文一压缩就得回头重读，9 个任务下来，光读计划就得烧掉五六百万 token。
怎么说呢，两套计划的问题其实出在形态上。现在的形态是完整答案，等于预设模型会写错，提前替它写好。这套逻辑在弱模型时代成立，可到了强模型时代，这个预设本身就是多余的约束。Kimi K3 本来能自己琢磨着把活干漂亮，你非把每一步给它钉死，它就只能当个抄写员。
我的对照实验就是证明，没有开发相关技能，让它自己干，二十来分钟、一成额度，产出没差太多。多花的那些时间和额度，全花在不产出代码的中间环节上：派子代理、评审、状态更新、自愈检查。这些动作该做吗？好像也该，但是不是大模型自己就做了？
规约写成完整答案，错的命令也照抄
这里还有个更坑的问题。计划写成完整答案，不光是冗余，还会把错误也一块儿固化进去。
superpowers 社区里有个重度用户的案例。一份上千行的细化计划，对抗式审查之后还是抓出了错误的 shell 命令、没激活的虚拟环境、脆弱的正则。这些跟模型会不会写代码无关，是计划里把完整代码都写进去了，而代码里的命令本身就是错的。干活的 agent 没有锚点去核验，只能照抄。
模型再强，面对一份看起来合理但有错的方案，没有东西可比对，就只能照抄或者顺着重写。
这里得分清两种东西。一种叫核验锚点，就是干完之后能马上拿来对一对的信息：接口签名、精确命令、预期输出、表名、验收用的核心断言。另一种是完整答案，把实现细节、函数体、测试代码都写死。
锚点必须钉死，因为它是质量底线。完整答案可以放开，因为强模型自己能补，而且补得比写死的更贴合上下文。
specs 规约就属于锚点那一类。jero3 里的功能需求规格说明书、接口设计文档，钉死的是契约和断言，实现留给模型。
这一层是整条链的源头，源头一松，下游每个 agent 都失去比对基准，规模化之后换人接手、三个月后回来改，对不上的毛病就全冒出来了。所以 specs 这一段，再怎么精简，都不能动它的契约密度，必须保持信息完整性。
中小任务在为重流程交智商税
质量域和审批这一段也得聊聊。
在我用AI的这一段时间里面，发现AI 对测试用例会过度设计，一个简单功能能给你整出五十来条用例，得有三十来条是废的。我当时把它当 skill 优化问题，后来才想明白，这其实是重流程思维往测试域里渗：怕漏，所以堆。堆到最后，人工还得拉回来给自动化兜底，因为判断功能对不对还得靠人。
审批环节同理。jero3 的两阶段审阅、superpowers 的 brainstorming 到 writing-plans 强制串行审批，社区里一直有人抱怨。大任务上靠这些门禁挡住退化和方差，划算。换到一个单模块、单文件、逻辑明确的小任务上跑全套，就是交智商税。
在大模型能力足够的今天，当你用够好的大模型的时候，是不是考虑让AI直接把中小型任务自己做了？
根子是同一种约束形态错位
绕了一圈说回来，两套体系犯的其实是同一个毛病。
弱模型时代，约束的形态是提供完整答案，代码、命令、测试都写死，因为模型真的会写错。强模型时代，约束该转向提供核验锚点，做完能比对，错了能发现。
两套体系都还停在旧形态里。jero3 把开发计划写成完整函数体加完整测试代码，superpowers 把 14 个 skill 写了三千多行，社区自己后来测，砍掉将近七成，压到不到一千行，行为一点没退步。被砍的全是些怕模型不懂、反复解释的内容，像 rationalization 表、red flag 列表、营销文案。留下的是流程图、速查表、安全闸门这类锚点。
这跟我前面说的判据，其实是同一件事。两边各干各的，得出的结论却一样，说明这跟谁设计得高明不高明没关系，是这一代流程框架共有的时代病（毕竟以前模型能力差的时候，确实需要）。
那我们怎么改？
specs 钉死，计划放开
我仅针对我自己的jero3的流程进行调试，我按照如下方式修改的：
specs 这一段，不动。功能需求规格、接口契约、验收断言，钉死，这是锚点。jero3 现在的 fm/pm 状态机，加上 dev_plan 完成后必须新建 feature 这条变更规则，也留着，这是规模化协作的一致性兜底，不随模型变强失效。
开发计划这一段，得大幅瘦身。计划只写接口契约和验收断言，完整函数体、完整测试代码、逐字 TDD 步骤全部放开，TDD 由执行阶段的实现者按指导自己走。
再按任务复杂度分个档。
- 单模块、逻辑明确的小任务走轻档，只写契约和断言，接近直接开发但保留可追溯；
- 跨文件、有状态流转的走中档，写契约加核心测试断言，审阅从双 verdict 降成单 verdict；
- 跨模块、多人协作、长周期的走重档，完整流程全留。任务复杂度上来之后，方差和退化的代价翻着倍往上涨，这时候重流程的成本才划算。
这么改下来，技能链变成两头重、中间轻。一头是 specs，钉死契约和断言；一头是评审、职责分离和状态机，锁定安全和一致性；中间的开发计划瘦成锚点集合，把实现还给模型。token 和时间还给模型本身的能力，方差和退化交给锚点和纪律去兜。
最后
流程是按模型的能力基线设计的。基线一挪，每道约束的性价比就跟着变。半年前的模型还得你盯着它别跳步，到 Kimi K3、GPT 5.6 这一代，再盯就成了多余动作。
Harness 不是设计一次管很多年的东西。模型每上一个台阶，就得把流程重新校准一遍，看看哪些约束是为上一代模型的能力不足买的保险，现在该退保了，哪些锚点反而要补强。