Spec Coding 过时了吗？强模型时代，复杂工作流为什么开始失效

发布于：2026-03-24 · #AI Coding

写在前面

这篇文章是我在这大半个月里断断续续用语音跟 Claude 聊出来的，都是我这几个月的实际经验和体感，内容比较杂，但贵在真实，**不聊各种高大上的 AI 术语、各种 Engineering，只聊 100% 纯粹的个人经验和体感。**碍于个人视角局限，部分观点可能存在争议，请批判性阅读。🥸

前几天惨遭 Anthropic 封号丢失了大量记忆包括聊这篇文章的会话，但好在 Typeless 保存了全部的语音转写历史记录，于是手动重新”聊”了一遍”找”回了这篇文章 🤧 忍不住再安利一下 Typeless

TL;DR

  • Spec Coding 在 2026 年之前确实有价值，它比 Vibe Coding 强得多。

  • 但它不是银弹，完整需求很难靠一条大链路一次跑通，后面沿着一份不稳的骨架持续修补，很快就会退化成另一种 Vibe Coding

  • 我现在更常用的流程，不是直接一键生成整套 Spec 一键开工，而是先和 AI 共读 PRD，做细致的任务拆解、技术方案评审，然后子需求 worktree 并发 brainstorm & plan mode，最后执行和验收。

  • Plan Mode 本质非常简单。它更好用更多是因为交互更顺手，更适合终端分屏、语音 Voice Coding 以及并行多任务推进。

  • 如果你觉得 Plan Mode 效果不好，要么是需求拆得不够细，要么可能是你没使用 SOTA 模型。

  • 对 Agent 来说，过时文档是毒药。代码通常比历史 Spec 文档更接近真相源。而客户端 AI Coding 再往前走一步，真正缺的也不是更重的流程，而是一个足够便宜、足够快速的 feedback loop。

这几个月我一直在 100% AI Coding，平均每天消耗一两亿 Token，从 IDE 到 CLI，从 vibe coding 到 spec coding。OpenSpec、SpecKit、Superpowers 等各种流行的框架以及一些内网的 spec coding 工具多多少少都有一些体感。

随着模型能力越来越强，有些几个月前还很流行的做法，到了今天已经该重新看一遍了。AI Coding 的最佳实践变得很快。几个月前还是主流的方法，放到今天，可能就已经开始显得笨重。

开箱即用的 Spec Coding 👨‍💻 工作流

我在 2025 年 12 月介绍 Spec Coding 的文章，在三个月后的今天已经不再适用 🥸

一开始我也觉得这些各种工具和框架很厉害，于是把上下文工程、AGENTS.md、各种 MCP、各种 Skills、superpowers、get-shit-done、awesome-claude-code、oh-my-opencode 等等各种乱七八糟的东西都堆了上去，但是现在反而基本都删干净了，只留下了少数自己打磨出来的适合自己的 Skill

这里不是想否定 Spec Coding 的价值，而是说到了今天这个模型能力阶段，在很多日常研发任务里，尤其是客户端这类链路长、边界多、需要频繁人工判断的任务里，Spec Coding 已经开始有点过时了。现在我更愿意把精力花在需求拆解和脑暴上，然后用 Plan Mode 把计划和执行接起来。

这里说的“过时”，不是说它彻底没用了，也不是说以后再也不会有人用。我想表达的是，在我现在的工作流里，它已经不再是默认最优解了。现在我更愿意把精力花在需求拆解、技术评审、brainstorm 和一份真正可以直接开工的 Plan 上。

它为什么会在 2025 年流行起来

如果把时间拉回到 2025 年下半年，Spec-Driven Development 的流行是很好理解的。那时模型没有今天这么强。你如果只给一句需求，直接让它做，跑偏是很常见的。边界漏掉、约束漏掉、关键场景没覆盖、写着写着开始加戏，这些问题都不少。

所以社区开始强调 Spec Coding。先写 proposal，再写 spec、design、tasks。把需求、边界、方案、实施步骤都尽量写清楚，再让 AI 去落地，跟几十年前的瀑布流开发流程如出一辙。

这个思路在去年是成立的，因为它确实能把模型约束住。它在那个阶段是有价值的，而且价值很明确。你甚至可以说，它当时是一种很实用的补偿机制。模型不够稳，那就靠流程把它扶稳一点。模型容易漏，那就靠文档把关键点补进去。

问题是，今天的情况已经不太一样了。像 Claude Opus 4.6、GPT-5.4 这一档模型，指令遵从性和计划能力极强。你只要明确告诉它先调研、先聊计划、先别动代码，它大多数时候都能做得很好。

这时候，原来那些为了约束模型而设计出来的重框架，收益就开始下降了，甚至会负向。文档约束、格式约束、流程约束还在，但模型能力已经不是当时那个水平了。结果就是，很多额外成本留了下来，原来的收益却没那么大了。模型为了遵循这些条条框框，吭哧吭哧写了一大堆文档，反而分散了在原始需求上的注意力，效果变差。

而且这些额外成本不是抽象的。它会表现成更长的生成时间，更长的文档，更重的阅读负担，更多的切换，更高的 Token 消耗。你在一天里高频做这件事，体感会非常明显，你的脑子 🧠 远远跟不上 AI 产出的大量文档。

Spec Coding 不是银弹

SDD (Spec-Driven Development) 不是魔法。你不能指望丢进去一个完整的产品需求，然后出一套 proposal / spec / design / tasks 等看似很厉害，实则各种车轱辘话的文档，再一路往下跑，不断反复澄清各个地方，最后把需求交付出来。

这条路在真实项目里很难走通。原因不是一句“上下文窗口有限”就能讲完的。更现实的问题是，一个正常规模的需求会牵扯很多链路、模块、历史逻辑、边界条件、相关方。你就算不断补材料，模型的注意力有限，很难把所有细节都照顾到位。

比如一个客户端业务需求，表面上可能只是“补几个埋点”“改两个交互”“多一个状态”，但往下挖通常会带出很多东西：

  • 页面生命周期到底怎么切

  • 老页面和新页面是否并存

  • 消息流、异步回调、结果区是不是同一条状态链

  • AB 实验、灰度开关、权限态、登录态要不要覆盖

  • iOS 和 Android 两端是不是完全一致

  • 埋点、容错、回退、降级分别落在哪一层

这些东西不是写一句“请综合考虑所有边界”就能自动被考虑到的。

第一轮产物通常都会有偏差。这时麻烦才刚开始。如果你接下来沿着这份产物继续修，一点点补，一点点改，看起来像是在推进，实际很容易退化成另一种 Vibe Coding：这里不对改这里，那里漏了补那里，局部修复越来越多，全局视角越来越弱。

SWE-CI: 用CI评估Agent维护代码库的能力

上下文开始跑偏。会话开始腐烂。你后面喂给它的，不再是清晰的问题，而是一串修补历史。

这种状态下，Agent 很容易陷入局部最优。你会发现自己不是在交付一个需求，而是在维护一条已经开始失真的会话链。到了后面，这个会话其实已经废了，最现实的做法通常不是继续修，而是重新拆问题，重新开会话。

很多人会误以为这是“AI 不够聪明”，但我后来越来越觉得，这更像是输入组织方式的问题。你一开始就把问题组织错了，后面再怎么修，都是在错位的上下文上继续加东西。

这也是为什么我现在很少会在一条已经明显跑偏的大会话里死磕。我宁愿停下来，重新拆问题，重新开会话，也不愿意继续往一条已经开始腐烂的上下文里堆更多补丁。

如果一个大需求从一开始就没被正确拆开，那后面不管套多少层 Spec Coding，都很难把它救回来。

我现在更常用的起手式

我现在接一个真实需求，起手通常不是先让 Agent 给我生成一整套 Spec。更常见的起手式是，我先和 AI 一起看 PRD。

我会先把需求文档丢给它，让它先帮我分析结构、关键目标、核心链路、潜在边界，再顺着它的讲解去重新读一遍文档。这个过程不是让 AI 替我理解需求，而是借它的拆解能力，把我自己阅读 PRD 的效率提上去。

很多时候，人在第一次看需求文档时，脑子里只会先抓住主流程。但 AI 会更容易先把文档里藏着的分支条件、状态差异、历史兼容点、上下游依赖给你拎出来。你一边看文档，一边听它帮你拆，通常会比自己硬啃更快进入状态。

所以我现在经常不是“自己看完文档，再找 AI 帮忙”，而是一开始就让 AI 参与进来，和我一起把 PRD 看透。这是后面一切工作的前提。因为如果一开始连需求都没真正读明白，后面的 Spec、Plan、代码实现，都会建立在一个不稳的理解上。

补充一下

PRD 很多时候不可能写得尽善尽美，简陋的 PRD 才是常态，甚至有些需求点非常模糊不清。我们可以跟 Agent 一起去研究 PRD 并结合代码库和飞书文档知识库获取更多的上下文信息，跟 Agent 一起脑暴、让 Agent 写出一个更完善的 PRD。

在这个过程中，Agent 会针对产品层面问你非常多的问题。此时可以先一边聊着，拍脑袋下临时决策，同时让 Agent 总结整理一份需求澄清明细表，生成一个文档甚至多维表格，然后找 PM 一起把需求聊透，敲定尽可能多的边界、细节问题。

真正关键的是需求拆解和技术方案

既然完整需求很难一次跑通，下一步就不是“把 Spec 写得更长”，而是回到拆解。但这里我现在越来越不把“拆解”理解成一个孤立动作。更准确地说，它通常是和技术方案评审绑在一起的。

我现在更常见的一条链路是：

先和 AI 共读 PRD，把完整需求吃透；然后做任务拆解；拆完以后，不是立刻施工，而是进行传统的技术方案评审，跟大家一起对方案进行把关；把方案确定以后，再切成多个可以独立推进的子需求；从这里开始，才进入 brainstorm、Plan 和执行。

这一步里，真正要定下来的，不只是“拆成几块”。而是这些事情：

  • 每个子需求到底解决什么问题

  • 每个子需求的方案选型是什么

  • 具体要动哪些模块、哪些层次、哪些页面或组件

  • 两端实现是不是要完全对齐

  • 哪些历史逻辑要兼容，哪些可以顺手收口

  • AI 在后续阶段应该承担调研、方案讨论、计划生成还是直接编码

这一步的本质，是先把“该干嘛”拍死。

因为如果这一层都还没确定，后面不管你让 Agent 写 Spec 还是写 Plan，都只是在放大前面的不确定性。我现在对拆解的一个很重要的判断标准，是它是不是一个内部闭环的子需求。

所谓内部闭环，不是说它完全没有边界，而是说：

  • 它的目标是清楚的

  • 它牵扯的模块数量是可控的

  • 它不会把太多上下游问题卷进来

  • 它可以被单独 review、单独讨论、单独验收

  • 它值得被拿出来并发推进

我更看重的是，这个子需求是不是已经小到足够放进单次上下文里认真处理，同时又完整到不会碎得没有意义。

这一步其实也很适合和 AI 一起做。以前拆需求往往是 RD 自己硬拆。现在你完全可以先让 Agent 帮你拆一版，再用你的工程经验去判断它拆得是不是对，边界是不是干净，切法是不是值得并发。新时代了，这件事已经不需要再自己苦哈哈地独自完成。

为什么拆成子需求以后，效率会高很多

很多人会把“拆解”理解成一种认知管理。这当然没错，但还不够。AI 时代里，拆解更重要的价值其实是并发。

如果你抱着一个大需求单线程往下跑，那并发数就是 1。你只能等 AI 慢慢分析、慢慢吐文档、慢慢执行。你的人也会被这个大任务一直绑住、反复 Review 文档、反复澄清细节，效率提升上不去。

而且这种绑定不是线性的。任务越大，你越难抽身。因为你知道它里面牵扯的点太多，你不敢随便切走。你会一直盯着它，反复 review，不断纠偏。这样一来，你一天的注意力很容易被这个一个任务吃掉。

拆成子需求以后，情况就完全不一样了。

技术方案评审做完，子需求边界清楚了，后面很多事情就能并发推进。终端分屏也好，多 Tab 也好，你都可以让几个子需求同时处在不同阶段：有的在调研代码，有的在 brainstorm，有的在写 plan，有的已经开始执行，有的在跑编译或者等待反馈。

这件事对客户端尤其重要。因为很多客户端工程不是人脑先扛不住，而是电脑先扛不住。你不能无限开 worktree，不能无限开 IDE，也不能无限同时跑编译。你的并发数本来就有上限。

比如 TikTok 工程在 M4 Pro 的电脑上同时打开 4 个 Xcode 的话 100% 会死机 🥸，最多只能勉强开三个

在这种前提下，你更要把并发留给真正值得并发的东西，也就是已经拆清楚的子需求。这样你机器资源花得值，你的注意力也花得值。

这才是 AI Coding 真正能把效率拉起来的地方。不是单个任务跑得有多快，而是你能不能把一个大需求拆分成一组可以并发推进的任务。

子需求阶段，最值钱的是 brainstorm

拆完以后，我其实不太愿意再为每个子需求跑一整套 Spec Coding。

原因很简单。如果子需求还没拆清楚，那这套 Spec Coding 流程救不了你。

如果子需求已经拆清楚了，再去给每个点都补一整套 proposal/spec/design/tasks，属实太多余了。

我现在更看重的是 brainstorm。也就是，针对每个子需求，先把它聊透。这里的“聊透”不是一句空话，而是一个多轮发散再收敛的过程。

通常是我先把当前理解、背景、限制条件、担心点说出来，Agent 再顺着这些信息继续发问、继续摸边界、继续扩展可能的方案。然后我再根据它追问出来的新问题，补更多细节。它拿到新细节后，再继续发散。

这个过程会一轮一轮往前走，直到问题开始收敛。我觉得 brainstorm 真正值钱的地方，不是它替你写文档，而是它会逼着你把很多原来没意识到的点说出来。

比如：

  • 旧逻辑到底要不要兼容

  • 哪些状态一定要覆盖

  • 空数据时怎么降级

  • 失败态是 toast、兜底页还是静默失败

  • 两端要不要完全对齐

  • 方案 A 和方案 B 的维护成本差在哪

  • 这个需求表面上是一个页面改动，实际上是不是会牵扯 service、埋点、生命周期、异步状态链

这些问题不问出来，后面的计划再完整也是假完整。

我自己现在判断一个 brainstorm 是否该结束、能不能进入 Plan，大致就看几件事：

  • 方案已经拍死，没有待选项了

  • 主要边界已经问透，不再靠实现时边做边猜

  • 涉及模块已经明确，知道要动哪里

  • 遗留决策点已经归零，不会把关键判断丢给后面的执行者

  • 这份上下文已经完整到可以直接交给另一个工程师或 Agent 开干

只要这些条件还没满足，我通常就不会急着出 Plan。

因为对我来说，Plan 不应该是一个用来继续讨论的文档。它应该是一份已经讨论完、拍板完、可以直接执行的计划。

另外这一阶段我推荐直接用语音。

不是因为语音更高级，而是因为信息带宽更高。打字的时候，人会天然惜字如金，会把很多脑子里原本有的东西压掉。语音就不一样。你会自然地把更多背景、顾虑、判断过程和临时想到的边界说出来。

这对脑暴特别有用。我现在基本是全程用语音和 Coding Agent 交互，不只是在脑暴阶段。对我来说，这是效率最高的方式。

如果只用一句话概括，那就是：在 AI Coding 里，人机带宽本身就是生产力的一部分。语音能把这个带宽放大很多。

关于语音编程为什么有效、怎么做、语音转写工具怎么选、豆包输入法还是 Typeless、麦克风怎么选，我单独写过一篇文章。这里不展开。

👨‍🚀 别再只打字编程了，语音才是 AI 时代的输入方式

Plan Mode 的本质，其实没那么神秘

我专门抓包、看源码，拆过 Codex、OpenCode、Claude Code 这类工具里的 Plan Mode。最后得到的结论其实很简单。Plan Mode 没那么神秘。它本质上就是两件事：

  • 用 prompt 把模型带进“先调研、先计划、不要急着写代码”的状态

  • 再用一层工程上的限制，拦住它直接去改文件

就这些。

从这个角度说，Plan Mode 本身就很像一个很轻的 Spec Coding。

**甚至很多时候，你不用专门开 Plan Mode 也行。**你直接在普通模式里和模型聊计划，聊清楚以后再开工，强模型照样能做得很好。所以我并不觉得 Plan Mode 有什么神奇之处。

它真正有价值的地方，不是它创造了新的能力，而是它把一件本来就该做的事，做成了更顺手的交互。这一点我后来越来越在意。

因为很多工具和流程，看上去都在解决“能力问题”，实际解决的是“交互问题”。方法本身并没有变，变化的是你和模型来回往返的成本有没有降下来。

关于 Plan Mode 的底层实现、抓包分析和源码细节，我单独写了一篇文档。这里就不展开了。

Coding Agent 的 Plan Mode 📝 到底在「计划」什么？

顺手提一句。

如果你觉得 Plan Mode 效果不好，一种情况是，需求还没拆够细。另一种情况是，可能你用的模型不够强。

在真实编码场景里，很多榜单上看起来只差一点的模型，落到交付效果上，经常不是 90 分和 95 分的区别，而是能不能稳定干活、能用和不能用的区别

我自己的体感是，越到复杂任务，这个差距越明显

小任务上你也许觉得没差多少，大任务上差一点就是一路通顺和一路卡壳的区别

《SWE-CI: 用CI评估Agent维护代码库的能力》论文解读：为什么 Claude Opus 4.6 只领先几分，真实体验却像领先一代？

你会花很多时间去补模型能力带来的坑，然后误以为是方法不对，然后可能得出结论说：“哎呀 AI 就是不行，还得是我自己来”。🥸 其实可能只是你没有使用 SOTA 模型。

为什么我最后还是更愿意用 Plan，而不是重型 Spec

既然 Plan Mode 没那么神秘，为什么我最后还是更偏向它？

因为它顺手，而且这个“顺手”在真实工作流里是有成本差异的。

我之前做过一次同需求对比：同一个客户端需求，一个 worktree 用 Codex 原生 Plan Mode，另一个 worktree 走 OpenSpec 的 proposal 流程，输入提示词保持一致，中途都不做人肉微调，最后再让另一个 Agent 客观 review 两边的成果。

先只看计划阶段，我的体感差异就已经很明显了：

  • Plan Mode 输出一份计划大约用了 9 分钟，消耗约 231 万 Token

  • OpenSpec 产出四份文档大约用了 15 分钟，消耗约 387 万 Token

  • 仔细阅读那份 Plan，我大概花 2-3 分钟

  • 仔细阅读那四份 Spec 文档，通常要 5 分钟以上

这还不是最关键的。

最关键的是，Plan 的信息密度明显更高，而且它天然适合在终端里读。你从上往下看一遍，通常就知道这件事怎么做、哪里有风险、哪里要改。读完以后，你可以直接在同一条交互链里反馈、重出、开工。你可以不用跳出终端就能完成大部分的工作。

而重型 Spec 的问题不只是“文档更多”。它更大的问题是，信息被切碎了。

你得在 proposal、design、spec、tasks 这些文档中间来回切。主线被拆开了，很多信息需要你自己重新拼起来。终端里读不够自然，切去 IDE 或别的窗格又会打断当前节奏。

如果你一天只做一轮，这个痛感未必很强。但如果你一天要反复做很多轮，差别会越来越明显。你会发现自己很多时间不是在思考问题，也不是在 review 方案，而是在不同文档之间重新找上下文。

更现实的一点是，重型 Spec 还会明显降低人的 review 意愿。计划写得太长、太散、太碎之后，人很容易出现一种很真实的反应：**“好多字啊，不想看了。”**这不是态度问题，而是注意力问题。

而在这个对比里，我最后得到的结论其实很朴素：OpenSpec 在计划阶段多了约 66% 的耗时，多了约 **67.5%**的 Token 消耗，但最终产出质量并没有拉开到值得我持续承担这套额外流程成本的程度。

甚至在这个 case 里 OpenSpec 的产出质量还不如 Plan Mode 🥸

如果认真 review、认真澄清，不管是 Spec 还是 Plan 最后都能把东西完成交付。区别更多体现在，人到底愿不愿意读、能不能快速读完、读完以后能不能马上给反馈并继续推进。这个差别在真实研发里，不是小事。

过时文档为什么是 Agent 的毒药

还有一个长期成本：很多团队喜欢把每个需求都沉淀成 Spec 文档，觉得这样能积累知识。对人来说，这些文档也许还有回看历史过程的价值。

但对 Agent 来说，过时文档就是毒药。

https://x.com/dotey/status/2026146560862474482?s=46

代码一直在迭代，历史 Spec 往往不会同步更新。过了一年，你再让模型去读一年前的执行文档，这些内容更可能是噪声和误导，而不是帮助。

这也是为什么我越来越不建议把大量历史 Spec 常驻在代码仓库里。它们或许更适合被放在知识库、放在飞书文档里，给人查历史；而不是留在 repo 里，持续污染 Agent 的上下文。

很多人会天然觉得“文档越多越好”，但这套逻辑放在 Agent 身上并不成立。

Agent 不是在做组织知识管理。它是在当前任务里找最有用、最相关、最新的上下文。只要你仓库里长期堆着一堆已经失效、但又看起来很像真的文档，它迟早会被这些东西干扰。

这个判断不只适用于 Spec。.cursorrules、CLAUDE.md、AGENTS.md 这类文件也一样，不是越长越好。只要它不能持续更新，对模型来说就是干扰。

任何能从代码库里推导出来的知识、一键”自动生成”的知识，对 Agent 都是噪声

删掉你的 CLAUDE.md 🗑️ 它很可能在给 Agent 帮倒忙

代码当然也不完美，但在实现和修改任务里，代码通常比历史文档更接近真相源。

Source Code is the Single Source of Truth

我从这些框架里留下了什么

我不是没用过那些复杂框架。相反，我正是因为把这些东西都认真用过一轮，最后才更确定自己要留下什么、丢掉什么。我最后留下来的，主要就两件事。一件是 brainstorm。另一件是 executable plan。

也就是，计划必须真的能执行，上下文必须闭环，不能带着一堆遗留问题就开工。这也是 Superpowers 这类框架里，我最认可的部分。但它那些更重的默认前提，我在客户端场景里并不想照搬。比如 worktree。

在大型 MonoRepo 里，worktree 的成本是很高的。仓库本身就很大，创建和销毁都慢，编译产物还会吃掉很夸张的磁盘和机器资源。

我的做法更接近长期复用少量 worktree，而不是为每个任务重新起一个再销毁。

这不是我反对工程纪律，而是我更在意现实成本。如果一个好习惯在你的工程环境里会带来巨大的机器开销、时间开销和切换开销，那它就不能再被当成默认动作了。

再比如 TDD (Test-Driven Development)。这件事在前端后端领域、SDK、逻辑层里当然有价值，但在很多客户端的业务产品需求里，尤其是 UI 和交互工作里，它不是最自然的起手式。很多问题你就是得跑起来看，得手工体验，得看视觉、动画、间距、交互反馈，这些不是补几条测试就能解决的。

这也是为什么我一直不太喜欢把某些局部最优的方法，直接包装成所有项目的默认流程。方法本身没有错，错的是不看场景就照搬。所以我最后留下来的，不是一整套框架。只是两个高价值能力：脑暴，和完整计划。

我精选了一些可公开的 Skill，上述两个 Skill 都在这个仓库里

https://github.com/patrick-fu/awesome-skills

使用 https://skills.sh/ 工具一键安装：npx skills add patrick-fu/awesome-skills

一键更新：npx skills update

我现在更习惯的工作流

我现在更习惯的流程，大概是这样：先把完整需求做拆解，完成技术方案评审。评审过后，把需求拆成多个可以独立推进的子需求。到了这一步，其实就可以开始并发了。终端分屏也好，多 Tab 也好，都可以让几个子需求同时往前走。

然后，针对每个子需求，先做一轮 brainstorm。把边界、方案、改动面、风险和遗留点聊清楚。聊透以后，再给它出一份完整 Plan。后面就是执行和验收。这套流程听起来没有那么花哨，也没有太多看起来很“高级”的包装。

客户端很多场景下，目前验收还是以运行、体验和人工手工验证为主。每个人的业务线、代码环境、团队协作方式都不一样。今天我跑顺的这一套，放到别人那里未必还是最优。别的场景也许可以做得更自动化、更闭环，那是另一套条件下的玩法。真正稳定的生产力提升，很多时候就来自这种朴素的方法：问题拆对，问题聊透，计划写实，然后让执行保持流畅。

从复杂回到简单，不是倒退

Keep it simple 不是因为那些东西没价值，而是你已经知道，真正值得留下来的只有少数几件事。

对我来说，这几件事就是：和 AI 一起把需求读透，把问题拆开，把边界聊透，把计划写实，然后把执行放进一条顺手的交互链里。

Update 其实这个思路拿去看 Anthropic 那篇 Harness design for long-running application development 文章也挺有意思的：模型越强，很多过去看起来很重很完整的流程，最后都会回到一个问题——到底哪些结构今天还在承重。

解读《Harness design for long-running application development》当模型越来越强，Harness 设计的重点正在发生变化

从复杂回到简单，不是倒退，而是提纯。不是说那些框架和流程曾经没价值，而是到了今天这个模型能力阶段，很多东西已经不再值得作为默认动作保留下来。真正该留下来的，是那些仍然在稳定创造价值的部分：需求理解、任务拆解、边界收敛、完整计划，以及一条顺手的执行链路。

客户端 AI Coding 真正缺的，是 feedback loop

但如果再往前看一步，我觉得客户端 AI Coding 真正还缺的一块，其实不是更重的 Spec，而是一个足够便宜、足够快速、能让 Agent 自己验证工作的 feedback loop。

Anthropic 在 Claude Code 的 best practices 里专门强调过一点：Give Claude a way to verify its work。Agent 一旦拿不到验证回环，很多时候就只能“看起来写对了”，却没法自己确认结果到底对不对，最后还是得人不断接管、不断兜底。

前端和后端在这件事上，其实已经比客户端走得远很多。有浏览器 DevTools、可以直接跑单测、脚本和各种自动化检查等等快速高效的 feedback loop。客户端的痛点在于，今天的大型工程环境里，反馈回环的成本还是太高了。Agent 现在只能跑个编译，验证部分代码上的硬伤，难以验证实际运行起来的效果，仍需人工介入，手工测试给 AI 提供反馈，Human-in-the-loop 占比过高，效率难以提升。也许我们需要一个类似【豆包手机】形态的 Harness ，给 AI 提供一个验证工具。

编译链路重，测试框架和工具链高度定制，运行环境复杂，真机和模拟器各有各的问题，很多单测和 UI 测试或许从一开始就是为 CI 设计的，不是为开发者每开发完一个功能就在本地快速跑一遍，更不是为 AI Agent 的高频闭环验证设计的。

所以我前面说，我今天不会把 TDD 当成客户端研发的默认起手式，不是因为它没有价值。恰恰相反，我一直觉得它非常有价值。问题只在于，客户端目前还缺一条足够轻、足够快、足够稳定的验证链。只要本地跑一下编译和测试就要十几分钟，这条回路就很难真正转起来。

也正因为如此，今天真正值得投入的方向，未必是继续把前置流程做重，而是想办法把验证链路一点点补起来。

如果未来客户端这条反馈链能继续往前走，比如让 AI 更低成本地跑测试、读结果、截图、理解界面、验证交互，那很多今天还必须人工接管的事情，理论上都可以逐步交给 Agent 去完成。

所以我今天不是在说 Spec Coding 没价值。我只是越来越觉得，在强模型时代，真正开始显得过时的，是把大量日常研发任务继续塞进一套厚重 Spec 流程里的习惯。相比之下，我更愿意把精力花在需求拆解、技术评审、脑暴，以及把客户端自己的 feedback loop 一点点补起来这几件事上。