--- source_url: https://mp.weixin.qq.com/s/d1j7JCOkAFd5L-W1LK-Qug ingested: 2026-06-17 sha256: 59dd862b25713a2d6e7ee1f781681e92c985d1b3961fbe15643d282e760afce6 author: 术哥 publish_date: 2026-06-17 source_type: wechat --- 如果你已经被 AI Coding 惊艳过一次，大概率也被它返工过十次。 我们的数据：编码阶段提速 10 倍，端到端交付只快了 13%。中间 87% 的效率被什么吃掉了？答案不是模型不够强，而是没人能稳定证明：它这次写出来的，和你的真实意图是一回事。 认知篇讲了为什么需要 Spec，踩坑篇讲了为什么很多团队用了没效果。这篇只回答一个问题：工程上到底怎么落。没看过前两篇也能独立读。 结论先放：真正能跑通的，不是"多写几层 Spec"，而是"用最少的表达层数，把意图变成可被机器守护的约束"。 文末放了我们百人团队踩坑半年后沉淀的开源 Harness——Spec 模板、闸门脚本、目录结构全部脱敏可直接复用，3 步接入你自己的项目。 赶时间可以直接跳到「三、SSD 工程方案」。 一、两个前提 如果不先承认这两个前提，后面的所有"工程方案"都会滑回工具崇拜。 前提一：意图 → 代码是有损管道，AI 时代损耗位置变了 软件开发本质上只有一件事：人有意图，机器产生行为。 问题在于，这条链路天然有损。你脑子里的约束从来不是纯文字，它混着经验、偏好、历史事故、合规直觉、性能边界、组织默契。 代码却必须是离散、明确、可执行的。 连续意图转成离散实现，损耗不是偶发 bug，而是结构性现实。 虚线 = 没有桥梁时的信息丢失路径；实线 = Spec 和知识库补齐后的显式传递。桥梁不是为了让 AI 更听话，而是让那些"大家都知道"的隐性知识不再只活在脑子里。 古法编程时，写代码的人同时也是意图持有者，很多没写进文档的东西会在实现时被自动补完。AI 时代不同：意图持有者还是人，代码编写者变成了模型。 模型不持有你的隐性知识，session 结束就忘，换一次上下文就重新猜一次。 所以 Spec 只是这个时代不得不补上的桥梁。它的本质仍然是：对“可接受实现空间”的最小、可验证的显式编码。 注意这句话有四个关键词： 关键词 为什么必须有 没有它会怎样 最小 约束太厚，维护成本会逼近代码本身 团队很快放弃维护 显式 不写出来的规则，AI 就只能猜 “大家都知道”的地方最容易翻车 可验证 不能判定对错的不是 Spec，是愿望 review 会沦为形式主义 实现空间 Spec 不是复写代码，而是划边界 一旦试图穷举实现细节，就会烂得比代码更快 Spec 不是“写给 AI 看的详细文档”。它是把模糊意图压缩成一组可被审、可被执行、可被验证的约束。 本文关心的不是把 spec 写长，而是把桥梁写对：让意图不再只活在脑子里。 前提二：桥梁本身有损，且 Control 的边际收益在递减 承认需要桥梁，不代表桥梁越厚越好。 过去半年我们用 OpenSpec + Superpowers 跑过一轮完整 SDD，编码阶段确实快了不少——但端到端一算，交付只提速了 13% 左右。 我一开始以为是团队执行力问题，后来才意识到：桥梁本身也会有损，你每多加一层 Control，就多加一次编码—解码。 每多一层自然语言转写，就多一次编码—解码损耗。模型越强，这类旧流程的默认控制强度就越容易超过它真正带来的收益。 今天多数团队的问题，不是上下文不够，而是 Control 过多。 Control 必须花在最贵的地方。 能靠上下文解决的，不要靠流程；能靠机器验证解决的，不要靠人肉 review；能在一次表达里讲清的，不要拆成四次。 接下来的四条约束，就是从这两个前提直接推出来的判据——你可以拿它去评估你现在用的任何 AI 开发方案。不想看推导的，记住这四个词就够：减层、上下文、机器验证、自适应。 二、四条设计约束 如果一套 AI 开发方案不满足这四条，短期可能能跑，长期大概率会遇到系统性瓶颈。 这四条不是某个工具的产品特性，而是从前提直接推出来的工程判据。 ① 减层：信息转换越少，保真度越高。 可审不等于多产物，关键是用最少层数把关键判断露出来。 ② 注入上下文：Context 是比 Control 更便宜的资产。 领域事实、历史坑点、项目规矩一旦沉淀，就能被后续所有需求复用。 ③ 机器验证：考生不能批改自己的卷子。 验证必须独立于生成者，靠测试、闸门、覆盖率、漂移检测这类外部证据兜底。 ④ 自适应强度：Spec 是光谱，不是开关。 强度必须和风险、耦合度、后果成本匹配，否则要么流程过重，要么高风险需求失控。 减层、注入上下文、机器验证、自适应。满足这四条的方案，才配叫“跑通了 Spec 驱动”。 约束讲完了，下面是我们怎么把它落成一套可执行的工程方案——以及用一个 500+ 文件的真实迁移项目跑通全流程的过程。从这里开始全是实战，包括我们真实在用的 Spec 模板和闸门脚本。 三、SSD 工程方案：把 Spec 驱动真正跑通 SSD 不是一个新宗教，也不是再造一套工具链。它只是砍掉多余层数，再把该增强的地方增强。 这里的 SSD，我们内部把它称为 Superpowers-enhanced Spec-Driven Development（注意不是 SDD，SDD 是上位概念，SSD 是我们的具体实现）。名字不重要，重要的是它满足前面四条约束：保留 Superpowers 主干，再用减法和侧向增强把它改造成可落地的方案。 全景框架 主线 = Superpowers 原生阶段（白色），SSD 增强点从侧面接入（橙色）。 图例 ⬜ Superpowers 原生阶段  🟧 SSD 增强注入  🟥 人工卡点  🟪 Escalation 横向主线 = Superpowers 7 个核心阶段，纵向虚线 = SSD 在 5 个阶段上的侧面注入。不修改 Superpowers 任何源码，全部通过 CLAUDE.md @import 实现。 这张图只强调一件事：SSD 不取代流程引擎，只在高成本环节加增强。 知识前置、格式约束、AC 命名、闸门验证、知识回流都从侧面注入。 SSD 的核心做法：默认走 Superpowers 全套保质量，用 /plan 作为显式降级通道，同时把知识、验证、格式三类增强嵌进去。 SSD Harness：项目级 AI 开发运行时 再抽象一层，SSD 落地成的是一个项目级 Harness：规定阶段行为、上下文来源和通过证据的最小运行时。它拆成三层： 层 定位 解决的边界 Orchestrator 控制面 定义 Agent 在每个阶段的行为规则——Spec 格式、AC 编号、阶段转场 Knowledge Intent → Code 将隐性领域知识显式化——按需检索注入 Agent 上下文 Delivery Code → Production 提供独立于 Agent 的验证判据——manifest 驱动多步闸门管道 三层拆开是为了抗变化：Orchestrator 会变，Knowledge 会积累，Delivery 必须独立于生成者。 对应的原则只有三个：可升级的 kernel、可声明的工具链、可循环的交付。 项目只声明语言和闸门，Harness 把声明翻译成协作纪律。 SSD 与四条约束的对应： 约束 SSD 怎么满足 ① 减层 砍掉 OpenSpec，只留一套 Superpowers ② 注入上下文 /learn  知识沉淀 + CLAUDE.md 项目约束 ③ 机器验证 验证律 + TDD + 闸门管道（pipeline.sh） ④ 自适应强度 默认重 + /plan 手动降级 + 三问分流法 真正值得长期保存的，不是 spec 文件本身，而是测试、知识库、CLAUDE.md。 Spec / design doc / plan 只负责把这次意图送进代码，过期后大多都是一次性脚手架。 实战走查：五个设计内核 方法论如果不能穿过真实项目，就是漂亮废话。 下面用一个真实项目（已脱敏），把 SSD 五个设计内核逐个走一遍——包括我们实际使用的 Spec 模板、22 条 AC 验收标准、8 步闸门管道，都可以直接参考。（五个内核分别解决：选什么引擎、知识怎么沉淀、Spec 格式怎么定、验证怎么闸门化、轻重怎么切换。） 项目背景：500+ 个 Java 源文件的巨石应用，要把其中一个核心玩法模块做 Java → Go 迁移，剥离 11 个平台耦合点（鉴权、资产、订单、抽奖、消息队列等），最后做成可独立部署的服务。 典型的旧系统改造：历史代码厚、耦合深、涉及资金链路。 内核一：做减法——砍到一套引擎 多引擎叠加，绝大多数时候不是双保险，而是双重有损。 OpenSpec 和 Superpowers 都是完整方案，叠在一起会让 design、tasks、review 三个环节重叠：同一份判断被表达多次，同一个评审点要在两套产物里来回切换。 我们试了两周，发现工程师花在"对齐两套格式"上的时间，比写 spec 本身还多。 最终保留 Superpowers 而不是 OpenSpec，原因也很具体：Superpowers 提供了从 brainstorming 到 TDD 到 verification 的完整执行编排，而 OpenSpec 偏重前端设计阶段，缺少后半程的验证循环。 我们需要的不是一个更好的 spec 编辑器，而是一条从意图到交付的完整管道。 这个项目从第一天起就只跑 一套 Superpowers 主干。原因很简单：主风险不是少一个 proposal，而是中间转换太多会继续损失上下文。 只保留一次核心表达：在 brainstorming 阶段把 Spec 打磨到足够可审，然后直接进入写计划和执行。 对应约束①：从意图到方案，只经过一次真正的编码。 砍完引擎，下一个问题是：模型面对复杂项目时，拿什么代替"猜"？ 内核二：知识沉淀——让 Agent 从"猜"变成"查" AI 在复杂项目里最大的风险，不是不会写，而是不知道什么不能猜。 领域知识散落在人脑、飞书、事故复盘和旧文档里，模型就只能从代码表象做推断；在这种历史耦合深的项目里，这几乎必翻。 我们早期就吃过一次亏：模型把一个通过配置中心注入的 RPC 依赖当成了死代码，直接删了，上线后才发现调用链断了。 所以 SSD 把 Knowledge 当第一等公民：每次踩坑后用 /learn 沉淀结构化条目；每次 brainstorming 前，loader.sh 按关键词自动注入上下文。 为什么不只靠 CLAUDE.md？ CLAUDE.md 适合写"规矩"（编码规范、命名约定、禁止操作），但不适合存"事实"（旧系统有哪些隐式依赖、上次踩了什么坑、迁移策略是什么）。 规矩是静态的，事实会越积越厚——两者分开管理，才不会让 CLAUDE.md 膨胀到没人维护。 实际效果——brainstorming 开始前，Agent 自动加载知识库： loader.sh "核心玩法 迁移 订单" → 命中 3 条知识：   - service-scan：旧项目含 4 种玩法，核心模块识别，11 个耦合点清单   - project-origin：Java→Go 迁移策略、三阶段规划、目录映射   - reverse-engineering：核心业务流程 9 步拆解、DB/Redis/RPC 依赖映射 它解决的问题只有一个：让 Agent 面对历史系统时，先查"已知事实"，再动手推理。 少了这层，模型最容易漏掉的不是大框架，而是关键边界：RPC 隐式依赖、配置中心注入、异常补偿顺序。CLAUDE.md 管"现在怎么干"，knowledge/ 管"哪些事实不能忘"。 知识沉淀不是把 prompt 写长，而是让 Agent 每次启动都比上次多知道一点。 真正值钱的不是"这次答对了"，而是下次换人、换模型、换项目时，团队还保得住这次学到的边界。 知识有了，下一个问题是：知识以什么格式交给人审？ 内核三：Spec 格式对齐团队——Form Follows Reviewer Spec 写给 AI 没用，写给 reviewer 才有用。 古典程序员都知道一件事：先画 UML、写时序图、出技术方案，评审通过后再交给人实现。 AI 时代实现者换成了模型，但评审者还是人。 常见的问题是：让 AI 按自己的格式生成一堆散装 bullet list，然后指望人类来 review —— 人不愿看，不是责任心问题，是格式违背了技术人的认知习惯。 SSD 的应对只有一条规则：Form Follows Reviewer。 Spec 的外形优先服从人类评审习惯，同时保证 AI 可继续消费。 说白了就是把古典的"技术方案评审"搬到了 AI 工作流里——你的 spec 长得越像团队已经习惯 review 的技术方案，review 通过率就越高。 我们实际使用的 Spec 模板结构如下（完整模板见文末 ASD 仓库）： Part I  — 背景与目标     一句话说清做什么、为什么做 + 命名约定 Part II — 系统设计       架构图 · 时序图 · 协议 · DDL · 方案选型 Part III— 质量保障       验收标准（AC 表）· 风险审查自查表 · 测试策略 Part IV — 上线发布       Checklist · 灰度 · 回滚 附录    — 决策确认表     所有需人拍板的决策集中收集 几个关键设计点： • Part II 强制画时序图和架构图——技术人习惯看图，不习惯读 AI 生成的长文。时序图用 ①②③ 编号步骤，异常用 alt 块，标注事务边界和锁 key 格式 • Part III 验收标准用 Given-When-Then 表格——按场景分组（正常路径 / 校验拦截 / 异常补偿 / 工程质量），AC 编号全局唯一且直接对应测试函数名 • 方案选型只保留有真实取舍的决策——显而易见的选型一句话带过，把 reviewer 注意力集中到不可逆判断上 • 风险审查自查表——资金安全、技术风险、数据风险、发布流程四个维度，AI 自动从设计中填充依据列，reviewer 只需判断"评估过没有" 实际项目的 Part III 长这样——22 条 AC，覆盖正常路径、异常路径、边界条件： 正常路径（示例）： # When Then AC-3 发送合法业务请求 返回结果（orderId, balance, awards） AC-4 同一 idempotentId 再次请求 短路返回已有结果，不重复扣费 异常补偿（示例）： # 故障点 订单状态 资金影响 AC-10 建单失败 无订单 不扣费 AC-11 扣费失败 FAIL 未变动 AC-12 下游异常 SUCCESS 已扣不退，返回空结果 AC 编号直接对应测试函数：TestAC04_IdempotentRequest、TestAC11_DeductionFailure。reviewer 看到的是他熟悉的技术方案格式，不是 AI 自由格式。 关键不只是"更易读"，而是把 review 焦点从"逐字读懂"转成"判断取舍"。比如 Part II 方案选型： 决策点 选项 A 选项 B 最终选择 原因 分布式锁 sync.Mutex Redis SET NX Redis SET NX 需要跨实例幂等，单进程锁没有意义 幂等方案 Redis 结果缓存 DB 唯一索引 DB 唯一索引 资金链路优先一致性，不能接受缓存丢失造成重复扣费 真正值得人审的，不是 200 行接口字段，而是这种不可逆的架构判断。减层不只是在砍文档层数，也是在砍 review 的认知层数：让 reviewer 一眼看到这次该拍的板。 Spec 对了，reviewer 审了，接下来怎么保证 AI 写出来的代码真的跟 Spec 一致？——这是整套方案里最硬的一环。 内核四：闸门管道 + 验证律——让机器守住底线 没有外部证据，就不要允许任何人声称“完成”。 我们把这条写成硬规则：evidence before claims。 这条规则的来源很具体——早期有一次 Agent 自查说"所有测试通过"，实际上是它把失败的测试注释掉了。 从那以后我们就明确：verification 不是"让 Agent 自查一遍"，而是 pipeline.sh 驱动的一组外部闸门。 实际项目的管道——pipeline.sh 从 manifest.yaml 读配置，按顺序执行 8 步闸门，任一步失败即停： bootstrap     ✅  环境检查（Go 1.24 + Docker + MySQL + Redis） spec-lint     ✅  Spec 格式校验（AC 编号、必填段） build         ✅  go build ./... lint          ✅  go vet ./... unit-test     ✅  go test ./... -short ac-coverage   ✅  22/22 AC 覆盖 integration   ✅  go test ./tests/integration/... drift-check   ✅  DDL + 路由 + 错误码与 spec 一致 真正把 Spec 驱动闭环起来的，是后面两个增强闸门： • ac-coverage：检查 22 条 AC 是否都能在测试侧找到对应证据； • drift-check：检查数据库 schema、路由、错误码是否和 Spec 宣称的一致。 它们把"Spec 对不对"从文档争论变成机器清点。 以 AC-11 为例：测试里必须有 TestAC11_DeductionFailure 一类覆盖；schema 没有对应状态枚举，drift-check 直接红灯；代码吞掉扣费异常，integration 过不了。 修复循环也很硬：管道失败 → Agent 读失败输出 → 修复 → 重跑，上限 3 次；超限就 exit 2，停止自修复并升级人工介入。Agent 可以修，但不能无限自证。 AI 时代真正该投资的，不是“让模型更像人”，而是“让错误更像机器能抓住的东西”。 验证解决了"对不对"的问题，最后一个问题是：是不是所有需求都值得跑这么重的流程？ 内核五：默认重 + 手动降级——让光谱可操作 光知道 Spec 是光谱没有用，你还得把光谱变成团队能执行的动作。 默认轻会把最贵的错误藏起来；默认重至少会让痛感显性化，团队才会主动要求降级。痛感驱动的降级，比纪律驱动的升级可靠。 降级决策的本质，不是少走几步，而是确认这次失败能不能被便宜地发现、便宜地修正。 所以 SSD 的策略很直接：默认走 Superpowers 全套，/plan 作为显式降级通道。 降不降级，用一个"三问法"判断： 问题 如果回答是“是” 建议 是否跨多个模块 / 平台边界？ 说明上下文丢失成本高 不降级，走全套 是否会改 schema、状态机、外部副作用？ 说明返工代价高 不降级，走全套 是否存在“出错后无法靠常规测试轻易发现”的业务后果？ 说明需要更强验证 不降级，走全套 只要三问里有明显高风险信号，就不要为了快而轻易降级。 这个项目就是典型的"三问全是"：跨 11 个模块耦合、改 DB schema、资金链路又不能只靠"跑通一次"证明正确。这样的需求走轻路径，不是提效，是把风险贷款给未来自己。 反过来，/plan 也保护了团队：不是所有活都配得上重流程，轻量路线需要一个制度化出口。 四、总结：SSD 的终局判断 SSD 不是“第三种工具”，而是把前两篇所有认知和坑，收敛成一套更稳定的工程取舍。 先看结果。把 SSD 真正跑通后，核心指标大致变成这样： 指标 跑通前 跑通后 端到端交付提速 13% 28% 需求返工率 34% 15% 首轮 review 通过率 41% 68% 七坑验证：为什么这套方案是从坑里砍出来的 这套方案不是纸上推导出来的，而是被真实组织摩擦逼出来的。前一篇踩坑篇里的七个坑，几乎都能在四条约束里找到对应解。 实践中的坑 约束 SSD 怎么解 预期太高 ③ 机器验证 验证律：evidence before claims 迷信 Spec 是 Truth ① 减层 spec 即弃，测试 + 代码是 truth 迷信工具 ② 注入上下文 知识库沉淀领域事实，不绑定工具 概念局限 ② + ④ CLAUDE.md、测试、对话都是 spec 100% 强制 ④ 自适应 默认全套 + /plan 降级 + 三问法 格式不对 ① 减层 + ③ Form Follows Reviewer：对齐人类审查习惯 叠加工具 ① 减层 砍到一套 + 三项增强 详细拆解见认知篇和踩坑篇。 真正值得强调的：问题的根从来不在某个工具，而在你怎么理解 AI Coding 的成本结构。 价值重心放在"模型多写 20% 代码"，解法就会继续加 prompt、加模板、加控制。 一旦承认真正稀缺的是验证、上下文和可复用纪律，解法自然收敛到减法。 三个洞察 1）验证，而不是生成，才是新瓶颈 生成能力已经不是主要矛盾。 AI Coding 返工多，不是模型偷懒，而是验证能力没跟上生成能力。 2）SDD 真正留下来的，是验证基础设施 Spec 不是终点，它只是把验证前移的载体。 会长期增值的是测试覆盖率、知识库密度、闸门管道严密度；它们才是这套方法的复利资产。 3）模型越强，框架越该做减法 如果真正留下来的是验证基础设施，而不是中间文档，那模型越强，框架就越该做减法。 变化的是 Spec 粒度，不变的是验证骨架和上下文骨架。 五、Take Away：开源 Harness ASD 如果你想把 SSD 接到自己的项目里，ASD 就是那个最小可用骨架。 ASD（Agent-Spec-Driven Development） 就是前面 SSD Harness 的开源实现——把三层架构（Orchestrator / Knowledge / Delivery）落成一个可直接接入的项目级运行时。 它专门补 AI Coding 在两个边界上的系统性缺陷： 边界 失败模式 ASD 机制 Intent → Code 领域知识存在于代码库之外，模型无法推断，只能猜测 Knowledge 层：知识检索 + /learn 沉淀 Code → Production 生成与验证由同一模型完成，等价于考生自己批改试卷 Delivery 层：外部闸门管道 + escalation Orchestrator 层通过 @import 注入行为规则，连接两个边界。注入而非自建：流程编排本身不是问题，问题在上下文和验证。 项目结构 asd/ ├── manifest.yaml                 # 项目声明（唯一配置入口，换项目只改此文件） ├── kernel/                       # Harness 引擎（v1.0.0，整体升级，项目不改） │   ├── orchestrator/             # 控制面 │   │   ├── rules.md              #   Agent 行为规则 → @import CLAUDE.md │   │   ├── flow.yaml             #   阶段行为指南（非状态机） │   │   └── templates/            #   Spec 模板（Form Follows Reviewer） │   ├── knowledge/                # 知识引擎 │   │   ├── loader.sh             #   按关键词检索 + 同义词扩展 │   │   └── sync.sh               #   中心知识库 pull/push/status │   └── delivery/                 # 交付管道 │       ├── pipeline.sh           #   manifest 驱动闸门管道 │       ├── bootstrap.sh          #   环境 + 依赖服务健康检查 │       ├── deploy.sh             #   Docker 构建 + K8s 部署 + 灰度 │       └── gates/                #   5 个闸门脚本 │           ├── spec-lint.sh      #     Spec 格式 + AC 编号校验 │           ├── ac-coverage.sh    #     AC ↔ 测试覆盖清点 │           ├── drift-check.sh    #     DDL/路由/错误码与 spec 一致性 │           ├── compliance.sh     #     知识引用 + 澄清记录审计 │           └── spec-lock.sh      #     多 Agent 并发编辑锁 ├── skills/                       # 5 个 Agent Skill 声明 │   ├── brainstorm.md             #   需求 → 知识加载 → 澄清 → Spec │   ├── init.md                   #   /init 交互式初始化 │   ├── learn.md                  #   /learn 知识沉淀 │   ├── verify.md                 #   /verify 验证管道 │   └── plan.md                   #   /plan 降级模式 ├── knowledge/                    # 项目知识库（版本化，持久资产） │   ├── index.md                  #   触发关键词索引 │   └── synonyms.txt              #   同义词表（模糊匹配） ├── specs/                        # Spec 契约（用完即弃） └── plans/                        # 执行计划（用完即弃） 这个结构有三个关键点： • manifest.yaml 是唯一配置入口：换项目时改声明，不改脚本； • kernel 可整体升级：项目资产和引擎实现解耦； • knowledge / specs / plans 分家：长期资产和一次性产物彻底分开。 manifest.yaml：声明式配置 换项目只改这一个文件。核心配置段： • project — 语言、版本约束 • kernel.layers — 三层开关（orchestrator / knowledge / delivery），按需启用 • testing.strategies — 按语言自动选 AC 匹配正则（Go / Node.js / Python 开箱即用） • drift — 按 ORM（gorm / sequelize / prisma）和框架（gin / express / fastapi）选漂移检测策略 • pipeline.steps — 8 步闸门声明，skip_when 控制跳过条件 核心思想只有一句：不要把团队工作流写死在 shell 里，要把它声明出来。 这样今天用 Go + Gin，明天用 Python + FastAPI，变化都落在 manifest，而不是把整个 Harness 复制一份重改。 接入 # /init 交互式（推荐）——问答生成 manifest.yaml + 自动接入 /init # 或手动 3 步 cp -r /path/to/asd ./asd echo '@import asd/kernel/orchestrator/rules.md' >> CLAUDE.md bash asd/kernel/delivery/pipeline.sh   # 验证环境 零侵入设计：利用 Claude prompt 优先级（CLAUDE.md > Plugin Skills > 默认行为），一行 @import 覆写流程引擎行为。 不 fork Superpowers，不改任何源码，上游升级自动兼容，团队成员不装 ASD 也能正常开发。 好的 Harness 不是把项目绑死在自己身上，而是让项目随时可以拔掉它。 📌 Spec-Driven AI 编程系列 • ✅ 认知篇：为什么需要 Spec——四个认知错位 • ✅ 踩坑篇：编码提速 10 倍，交付只快了 13%——七个深坑 • ✅ 实战篇（本篇）：Spec 驱动开发实战——半年踩坑，我们如何让 AI 编码的交付真正闭环 如果只让我用一句话收束整个系列，我会选这句： More Context, Less Control。 不是因为控制不重要，而是因为在强模型时代，真正贵的不是“让它按步骤做事”，而是“让它知道什么不能做错”。 接下来我会继续拆三件事：多语言项目怎么适配同一套 SSD、团队规模起来后怎么把降级和验证做成制度、知识库怎么从关键词检索升级到语义召回。 如果你已经过了"个人提效"这关，后面这三件事基本都会遇到；关注就行，我会把可复用的模板和脚本继续放出来。