夜雨聆风
15.1 模型差距不等于产出差距
15.1.1 朋友的故事（经典引子）
去年冬天帮一位朋友检查他的 AI 编程配置。他刚把订阅从某海外厂商换成另一家，理由是"新模型跑分高了 3 分"。我打开他的项目目录：没有总章程文件，没有规格文件，没有一条子 Agent 定义，所有对话挤在同一个会话里，上下文窗口长期处于溢出边缘。当时给出的判断是——换模型换来的 3 分，一个缺乏工程约束的运行环境随时可以抵消掉 30 分。
这一判断有研究支撑。2026 年 arXiv 上的一项研究（编号 2605.23950）专门分析过这个问题：基准测试的分数从来不是"模型能力"的纯函数，而是模型与其外部工程环境的联合产物[ref]。这层环境——提示词如何组装、上下文提供什么、工具如何定义、失败如何重试、任务是否拆给子 Agent——英文称为 harness，直译为"马具"，本书统一称为"脚手架"，即前十四章反复讨论的那层工程结构。
15.1.2 两组实验
第一组实验：其余条件完全相同，仅向系统中增加一个负责代码搜索的子 Agent WarpGrep，在 SWE-bench Pro（一个比 SWE-bench Verified 更难、更防污染的编程基准）上，两个模型的排名就发生了翻转——尽管后者在多数其他基准上更高[ref]。一个检索子 Agent 为所有模型带来 2.1 到 2.2 分的提升，论文评价其"相当于一次常规模型升级"。
第二组实验：来自 Cursor 的内部研究：同一个模型，在一套脚手架下得分 46%，在另一套下得分 80%。差距来自四个变量——是将整个代码库灌入上下文还是只检索相关文件、是提交一个大任务还是拆分为带作用域的子任务、工具调用失败后是直接放弃还是纠正重试、中间结果是随手丢弃还是写入结构化工作记忆[ref]。
这四个变量没有一项属于模型问题。它们正是本章要收口的四根杠杆：检索、上下文管理、工具设计、子 Agent 架构。
现场细节：某次大型遗留系统的接入项目，工程师团队按论文里的"加一个检索子 Agent"思路试了三周。前两次试用的子 Agent 都配成了"全权限"——它们读完代码后顺手把发现的几个 bug 修了，改完直接 commit。结果是：主会话收到一份 8,000 字的"探索摘要"，里面夹杂 4 个未被评审的代码改动。第三次，团队把子 Agent 改成只读权限，只准看不准动，返回内容也限定在 1,500 字以内。这次主会话的上下文保持干净，工程师的评审压力从 4 个意外 commit 降到 0，周报里的"返工工时"也直接归零。教训：子 Agent 不是"小型主 Agent"，它是一份权限合同——不写清楚，代价由主会话和工程师一起付。
研究将同一批模型放入不同脚手架中反复测试，结论相当明确：更换脚手架造成的分数波动，稳定超过更换一代模型。厂商发布新模型时宣称的进步通常只有 2 到 4 分，而脚手架的更换可以带来几十个百分点的波动[ref]。
15.2 规范层与执行习惯
15.2.1 两个常被混淆的项目
现场还原：某次内部技术分享会前，某 SaaS 团队的技术主管花了两个晚上把 OpenSpec 和 superpowers 都装了一遍，准备在内部分享时给出"团队该装哪个"的建议。第一晚，他跑了 OpenSpec 的 /opsx:propose，在某个中型模块上产出了一份 23 个 task 的清单；第二晚，他装了 superpowers，跑了一个 600 行的小型脚本改造，Agent 在第一步就被强制要求"先 brainstorm 需求"。第二天分享会上，工程师当场追问："那我们到底装哪个？"他沉默了几秒，答："两个都装——一个负责想清楚，一个负责把活干好。"会后，这位技术主管在团队 wiki 里加了一句话：OpenSpec 与 superpowers 不是竞品，是时间线上的两段工序。
OpenSpec 与 superpowers 这两个名字在 2026 年的中文技术圈经常被并排提起，"装 OpenSpec 还是 superpowers"是一个高频提问。这个问题的前提本身不成立：两者不是竞品，甚至不属于同一类工具。一个负责"动手之前先想清楚"，一个负责"动手之后把活干好"。划清这条分界线，比记住任何一条命令都重要。
15.2.2 规范层：OpenSpec 的角色
规范驱动开发（SDD, Spec-Driven Development）的主张可以概括为一句话：规格说明取代代码成为"唯一事实来源"，人与 AI 在编写任何代码之前，先就"要建什么"形成书面一致。需求只存在于聊天记录中，是 AI 编程中绝大多数返工的来源——这一判断在第 4 章、第 11 章分别强调过，SDD 是它的产业化形态。
该领域目前有三个主要项目：Spec Kit 是 GitHub 官方的 SDD 工具包，采用刚性阶段门的重流水线；Kiro 是 AWS 的 agentic IDE，把 SDD 固化为默认工作流；OpenSpec 出自 Fission-AI 团队，定位是"比 Spec Kit 轻、比 Kiro 开放"[ref]。
OpenSpec 的具体形态：每个变更对应一个文件夹，内含四份工件——proposal（为什么改）、specs（改成什么样）、design（怎么改）、tasks（分几步），由 /opsx:propose、/opsx:apply、/opsx:archive 等斜杠命令驱动，兼容 30 多种 AI 编程助手[ref]。
OpenSpec 对老项目的适配需要特别指出：不要从项目第一天就订立宪法，改动哪个功能就为哪个功能补一份 spec——这正是第 11 章处理遗留系统时切身体会的方法。OpenSpec 的 README 中还有一条容易被忽略的提醒：开始实现前应先清空上下文窗口，等于把"上下文卫生"写进了使用须知。
15.2.3 执行习惯层：superpowers 的角色
superpowers 属于另一个物种。它的项目中有 14 个 Markdown 技能文件和一个"确保 Agent 真正使用它们"的加载器，没有一行可执行代码。装上之后的效果，相当于为 Agent 引入一位严格的工程主管：不允许直接写代码，先讨论需求（brainstorming）；讨论完成后编写实现计划，细化到"没有判断力的初级工程师也能执行"的程度；随后启动子 Agent 分工开发；全程测试先行——若 Agent 先写了实现代码，技能的指令是删除重写，而非补写测试[ref]。作者称之为"方法论即代码"：把资深工程师的工作习惯写成 Agent 必须遵守的强制流程。
superpowers 的自动触发机制被设计得相当强硬——"只要认为有哪怕 1% 的可能某个技能适用，就绝对必须调用它"。配合各技能的描述，Agent 会在该讨论时主动停下来讨论，该写测试时主动先写测试。这套机制目前已跨工具通用：Claude Code 官方插件市场收录了它，Codex、Cursor、Gemini CLI、Kimi Code 等 8 种以上工具均可安装[ref]。
15.2.4 两者的互补关系
至此可以明确那条分界线。OpenSpec 的产出是计划工件：动工之前，把"要建什么"固化为文件，人与 AI 围绕文件达成一致。superpowers 的产出是执行纪律：动工之后，每一步按什么规范执行、如何验证、由谁评审。一个管"先想清楚"，一个管"把活干好"，在时间线上首尾相接，因此社区的主流用法是叠加而非二选一：由 OpenSpec 产出 proposal 和 tasks，由 superpowers 接管执行过程[ref]。
15.2.5 反对意见与剂量匹配
作为全书最后一章，反对意见必须给足篇幅，否则本章难免有带货之嫌。
Spec Kit 自己的 GitHub 讨论区挂着一条高赞批评（Discussion #1784）："SpecKit 制造了工作的幻觉（the illusion of work）"。其含义是 spec 阶段会产生大量"关于工作的工作"：花两天写完宪法和规格文档，主观上感觉进展显著，实际上一行可运行的代码都没有[ref]。
superpowers 一侧的反噬更为具体：2026 年年中，中文社区出现一波卸载潮，用户的抱怨集中在三点——强制流程拖慢速度、Token 消耗高、14 个技能占用上下文反而使 Agent 分心、犯错增多。一位 Hacker News 用户的评论被反复引用："装了 superpowers 之后 Claude 犯的错误比不装还多。"压力最终大到维护者亲自下场，将 14 个技能的总代码量从 3,150 行削减到 977 行，砍掉 69%，目的只有一个：少占上下文[ref]。
这些反对意见不是噪音，而是剂量说明书。结论只有一条：纪律必须与场景匹配。新项目、大团队、需严格审计的行业，适合 Spec Kit 的重流程；老项目、小团队、快速迭代，OpenSpec 加 superpowers 的轻量组合已经足够；探索性工作——验证一个想法、写一个一次性脚本、周末的个人项目——应当保持随意。流程的功能是偿还认知债；没有认知债的项目强行引入流程，付出的只是净开销。
15.3 子 Agent 设计模式
图 15-1 真实世界后果由脚手架（harness）决定，模型只是底层算力
15.3.1 子 Agent 的本质
子 Agent（sub-agent）是由主 Agent 派生的、在独立上下文窗口中执行特定任务的二级 Agent，拥有自己的系统提示、工具权限与会话历史，任务结束后仅将结论返回主会话。
子 Agent 的核心价值是隔离上下文——把"探索"这种最消耗上下文的工作派给子 Agent。子 Agent 可以在独立窗口里消耗几万 token 遍历整个仓库，最后只向主会话返回 1,000 到 2,000 个 token 的蒸馏摘要[ref]。主会话的上下文因此保持清洁，代价是 Token 成本上升。
图 15-2 三个子 Agent 共烧掉约 85,000 token 做探索，主会话只承担约 3,400 token——噪声留在子上下文里，悟性务结回来无异
15.3.2 子 Agent 的骨架设计
以 Claude Code 为例，一个自定义子 Agent 是放在 .claude/agents/ 目录（项目级）或 ~/.claude/agents/ 目录（用户级）下的一个 Markdown 文件：YAML 头部写元数据，正文写系统提示[ref]。
三个设计点需要单独说明。
第一点：description 是委派触发器，不是简介。主 Agent 决定"这项工作派给谁"时，读取的是各子 Agent 的 description 字段。检验标准很简单：读完这句话，能否说出它什么时候会被派活？说不出，就重写。
第二点：权限最小化。评审类子 Agent 只授予只读工具（Read、Grep、Glob），不给写权限——它发现的任何问题都只能报告，不能"顺手改掉"。这不是不信任 AI，而是故障隔离。
第三点：上下文节俭。并非每个子 Agent 都需要知晓项目的全部规矩，探索类的给它任务本身即可，省下的都是上下文预算。
15.3.3 7 倍 Token 代价
代价必须说明，这是多数教程回避的部分：重度使用子 Agent 的工作流，Token 消耗约为单线程会话的 7 倍[ref]。原理不难理解——每个子 Agent 都要维护一份自己的上下文，三份上下文就是三份输入 Token 账单。
子 Agent 购买的不是省钱，而是主会话上下文的纯净度与并行度。三种值得使用的情形：并行探索（5 个子 Agent 同时研究 5 个主题，时间从 1 个下午压缩到 40 分钟）、隔离高噪声任务（把"会污染上下文"的工作派给子 Agent）、收敛权限（把危险操作圈进权限最小的子 Agent）。三种纯属浪费的情形：任务本身两分钟就能查完、任务依赖主会话的完整对话历史才能理解、为"显得高级"而拆分子 Agent。
15.4 成本路由
15.4.1 原则：规划用旗舰，执行向下分发
原则可以概括为一句话：最贵的模型只做规划与编排，执行层的工作逐级下放给便宜模型。重度用户按此分层可节省 40% 到 85%[ref]。
节省的机理不是"便宜模型够用"，而是任务的不对称性：一个重构任务中，真正需要旗舰判断力的可能只有 10% 的 Token（定方案、裁决争议），其余 90% 是按方案执行的工作。全程使用旗舰，相当于让架构师去搬砖。
15.4.2 按任务选模型速查
2026 年真正用得好的实践者，没有一个只忠于单一模型[ref]。按任务类型整理的路由表：
15.4.3 三个成本错点
仅掌握路由原则不够，落地需要会算账。三个错点均注明出处。
错点一：每拿下一分的成本。Haiku 每拿下一个 SWE-bench Pro 分的 output 成本约 $0.13，是全行业最便宜的路径；Opus 档约 $0.48[ref]。
错点二：订阅 vs 按量付费的平衡点。Claude Code 的 API 消耗平均约 $13/开发者/活跃日，90% 的用户低于 $30/活跃日[ref]。按此价格倒推，每月 API 用量在 370 万 Token 以内，按量付费比 Pro 订阅划算；超过这个量级，订阅制更优。
错点三：新一代模型的纪律是"删提示词"。Opus 5 发布时，官方迁移指南中有一条反直觉的建议：删掉提示词中"自我验证""完成后汇报进度"类指令，因为模型已内建这些行为，保留只会导致重复验证、浪费 Token；它还会更主动地委派子 Agent，使用者要做的是显式设置上限[ref]。
15.5 四根杠杆：全书方法论收口
15.5.1 四根杠杆及其证据
回到 15.1 那篇论文给出的框架。决定 AI 编程产出的，不是模型的单点能力，而是四根杠杆的组合[ref]。
检索：喂给模型的信息是否恰好相关。第 14 章的三件套、第 11 章的遗留系统探索，都是在调节这根杠杆。
上下文管理：有限的窗口里放什么、不放什么、何时清空。这根杠杆有一条清晰的文献主线：Anthropic 官方将上下文工程定义为"找到尽可能小的高信号 Token 集合，使期望结果概率最大化"[ref]——要点不是塞得多，而是塞得准。
工具设计：给 Agent 的工具接口如何定义，失败时如何重试，权限如何收口。第 3 章的凭据管理、第 5 章的脱敏规则、第 6 章的最小权限，都属于这根杠杆。
子 Agent 架构：任务如何拆分、噪声如何隔离、结果如何蒸馏。15.3 整节都在讨论它。
四根杠杆中，检索与上下文管理决定"模型看到什么"，工具设计与子 Agent 架构决定"模型能做什么、怎么做"。前两根管输入质量，后两根管执行结构。
15.5.2 四杠杆 × 全书章节映射
阅读这张表的正确方式是按列读。主杠杆一列：以检索为主杠杆的有四章（2、7、11、14），以上下文管理为主的两章（4、8），以工具设计为主的两章（3、5），以子 Agent 架构为主的三章（6、9、10）。检索多出一章，是因为第 14 章整个就是它的深化专题。案例篇越往后写，越确信"喂对信息"是一切的前提。
15.5.3 落地路径：20 条自检清单
知道四根杠杆与真正能用，中间差一个落地动作。建议的路径分三步。
第一步：脚手架健康度自检。下面这份清单共 20 条，四根杠杆各 5 条，建议每月给自己的项目过一次。能勾选 15 条以上，说明脚手架状况超过我见过的九成配置；勾不到 10 条，应当先暂停研究换模型。
【检索】
新会话开工前，先告诉 Agent 去哪里找 项目里有机器可读的导航（总章程文件/目录说明/索引） 外部数据按三件套分工：常识问内置知识、时事走搜索、私有数据走爬虫 检索回来的内容抽查过真实性 大库探索派给了探索子 Agent
【上下文管理】
总章程文件在 500 行以内 每个任务开工前清上下文 长任务有检查点/进度文件 跨会话的经验有地方沉淀 窗口占用常年飘红时，知道该删什么
【工具设计】
危险操作（写库/发消息/付费）有白名单或人工批准门 凭据不进对话、不进提示词 工具失败时，有明确报错和重试策略 每个自动化流程先手动跑通一遍 插件按需加载，不用的及时卸载
【子 Agent 架构】
每个子 Agent 职责单一，description 里写清了"什么时候用它" 评审/审计类子 Agent 只有读权限 子 Agent 返回的是蒸馏摘要（千字级） 并行派子 Agent 的活，事先评估过 7 倍 Token 代价值不值 拆子 Agent 是因为有隔离/并行/权限需求，不是因为"显得高级"
第二步：定位短板杠杆。自检完成后看哪一栏勾得最少——那就是当前产出质量的天花板。检索栏空得最多的人，症状是"AI 答非所问"；上下文栏空得多，症状是"聊着聊着就忘了前面的规矩"；工具栏空的，症状是"不敢让 AI 碰真实系统"；子 Agent 栏空的，症状是"主会话又乱又贵"。四种症状对应第 13 章的四类问题，病根都在杠杆上。
第三步：按顺序改造。顺序即 15.2 至 15.4 的顺序：先补规范层与执行习惯（想清楚、干好活），再上子 Agent（拆活），最后调成本路由（省钱）。不宜倒过来——路由优化省的是钱，规范层救的是方向，方向错了，省钱没有意义。这就是"先把脚手架修好再换模型"的完整含义：它不是一句口号，而是一个带顺序的决策框架——自检定位短板、按序改造，改造后仍有差距，那时才轮到换模型。
15.6 全书收束
谈到这里，有一个事实需要回到读者的桌面上：人会系统性地高估 AI 提效——而这个偏差，本身就是本书要展开回答的问题。METR 找了一批资深开源维护者做随机对照试验：使用 AI 工具的一组，完成任务实际慢了 19%，但他们事前预测自己会快 24%，事后还坚持认为快了 20%——感知与实测之间有 39 个百分点的偏差[ref]。该实验后来经历了自我修正（2026 年初的后续研究因"开发者不愿回到无 AI 条件"而无法复现，METR 官方承认真实加速效果可能已经转正），但其方法论教训保留了下来：人对 AI 提效的感知，系统性地偏离真实。
整本书其实就是这句话的展开。表面上的瓶颈是模型不够聪明，于是换模型；实际的瓶颈是脚手架漏风——需求只存在于聊天记录中（第 4 章）、凭据缺乏保护（第 3 章）、上下文持续腐烂（第 7 章）、经验从不沉淀（第 8 章）、评审形同虚设（第 13 章）。表面上换脚手架是折腾，论文给出的数据是它的影响超过换一代模型[ref]。而子 Agent、规格文件、成本路由这些曾经属于"高级玩家的小技巧"，2026 年的工具生态已经把它们做成了默认配置——superpowers 的 25 万星与 OpenSpec 进入 30 多种工具，说明整个行业都在朝这个方向收口。
模型还会换代，这个月的旗舰半年后就是旧型号；套餐还会改价，在我写这本书的三个月里，GLM 的 Coding Plan 涨了两次。会过时的，不值得惋惜；不会过时的，是围绕四根杠杆的自检与改造能力：知道去哪里看分数的口径、知道上下文该放什么、知道什么工作该派给子 Agent、知道什么任务该用什么价位的模型。本书交付的从来不是一份可以照做的说明书——说明书六个月就会过期——而是一套判断框架。
框架至此交付完毕。它能在多大程度上转化为产出，取决于读者在自己的项目里如何使用它。
15.7 思考题与延伸阅读
15.7.1 本章思考题
- 15.1.1 的"换模型 3 分，脚手架 30 分"：
你团队最近一次"换模型"的决策，有没有先做"脚手架健康度自检"？如果先做自检，会改变决策吗？ - 15.2.5 的"剂量匹配"：
你团队当前的项目，适合 OpenSpec 加 superpowers 的轻量组合，还是 Spec Kit 的重流程？为什么？ - 15.3.2 的子 Agent description：
你的子 Agent description 是"Agent 简介"还是"委派触发器"？读完能否说出"什么时候会被派活"？ - 15.3.3 的 7 倍 Token 代价：
你的项目子 Agent 调用率是多少？如果低于 5%，这个子 Agent 是否值得保留？ - 15.4.1 的成本路由：
你的 AI 调用是"全程旗舰"还是按"规划/执行/批量"分层？分层后月度账单降幅是多少？
15.7.2 本章延伸阅读
【文章】arXiv 2605.23950 harness 研究（2026-05-07 v1） — 换 harness 波动 > 模型代际差；WarpGrep 翻转排名；四杠杆框架的一手文献 | 第 15 章 【文章】mindstudio agent harness 分析 — harness > 模型实践佐证；同一模型在两套脚手架下得分 46% vs 80% | 第 15 章 【工具文档】Fission-AI/OpenSpec GitHub README — SDD 轻量规范层、四件套工件、/opsx 命令、30+ 助手兼容 | 第 15 章 【工具文档】obra/superpowers GitHub README — 14 个 Markdown skill 强制 TDD/调试/评审工作流；2026-07 超 25 万 stars | 第 15 章 【文章】掘金 Superpowers 卸载潮（2026-07-15） — 强制流程过重反而失言；skill 代码砍 69% 的维护者亲历 | 第 15 章
