从“能写代码”到“能交付软件”：DeepSWE 对照实验揭示的规格驱动开发、上下文工程与验证闭环

目录一、一个只有两个失败测试的实验为什么值得认真研究一Coding Agent 的竞争焦点已经从“会不会写”转向“能不能交付”1、代码生成能力越强流程问题越容易成为主要矛盾2、二元 Reward 会放大“最后两个坑”的工程意义二实验最有价值的地方是提供了一个近似控制变量1、A 方案适合做旁证B 与 C 才适合做流程因果分析2、单任务不能证明普遍规律但足以提出强假设二、从 18/20 到 20/20真正的差距不是“多想一会儿”而是“提前定义什么算对”一第一个失败错误被二次包裹暴露的是错误语义契约1、异常不仅要“发生”还要以正确形式发生2、这是典型的“主路径语义正确、接口语义不完整”二第二个失败0 没被判为假值暴露的是配置语义与优先级契约1、字符串配置不是语言布尔值2、配置优先级天然属于规格而不是实现细节三两个失败看似无关实质上属于同一种认知缺口1、Agent 容易完成“显性目标”却漏掉“约束目标”2、SDD 把约束从“注意力问题”转换成“工件问题”三、SDD 到底在做什么它不是“写更多文档”而是为 Agent 建立外部认知结构一把 SDD 理解成一套“意图编译链”更准确1、从自然语言意图到可执行约束需要多次降歧义2、规格的本质是“可执行的判断标准”二SDD 同时充当“外部记忆”和“阶段门禁”1、外部记忆解决长链路任务中的上下文衰减2、阶段门禁把错误发现时间从“测试末尾”提前到“计划阶段”三规格本身也会出错因此 SDD 不是天然正确1、错误规格会稳定地放大错误2、最有效的规格不是最详细而是信息密度最高四、重新理解原实验SDD 的收益不是“多做一步”而是改变了错误分布一直跑模式优化的是平均速度SDD 优化的是尾部风险1、13 分钟与 44 分钟分别代表两种优化目标2、这与生产系统中的 P99 思维很相似二补丁更小并不自动意味着更好但它提示了搜索纪律的差异1、544 行对 1068 行不能简单解释为“SDD 代码质量高一倍”2、Patch Scope 是值得加入 benchmark 的工程指标五、成本账SDD 为什么更贵以及“贵多少才值得”应该怎样算一原始成本表揭示了一个非常有意思的结构1、调用次数、输出 token 与成本都显著上升2、“新输入”反而下降提示结构化工件可能改善缓存与复用二是否值得取决于失败成本而不是只取决于 token 单价1、对 benchmark 来说1.75 倍成本换 0→1 Reward 可能非常划算2、对大规模探索来说直跑依然可能是全局最优六、Context-hub 应该怎样被验证先把概念从“感觉有帮助”变成可测量变量一报告提出了正确的问题但 Context-hub 的定义仍需要先操作化1、材料提出两阶段 benchmark 思路但没有给出实现细节2、没有操作化定义就无法判断增益来自哪里二最推荐的是“分层因子 配对运行”而不是排行榜式混跑1、核心因子至少有五个2、不要用“不同模型跑不同流程”替代真正控制变量三指标体系必须同时覆盖质量、成本和过程1、质量指标不能只剩一个 Reward2、成本指标要拆成“推理成本”和“等待成本”3、过程指标能够解释同样结果背后的不同路径七、为什么“模型变强后SDD 就没用了”是一个过早的结论一模型能力和流程能力是互补关系不是简单替代关系1、更强模型会降低显性错误但系统复杂度也会同步上升2、模型越强流程可能从“纠错器”升级为“能力放大器”二真正可能消失的不是 SDD而是固定、笨重的 SDD1、未来更合理的是自适应规格深度2、规格会越来越机器可读而不是越来越像传统文档八、Verify 的位置可能比 SDD 本身更值得单独拆解一报告已经暗示了一个有吸引力的折中先快跑再独立验收1、Hybrid 模式可能拿到大部分收益却不承担全部 SDD 成本2、Verify 应该尽量独立于实现轨迹二验证器质量决定了整个闭环的上限1、测试不是越多越好而是要覆盖可观察行为2、如果验证器只复现实现偏好会产生“为了测试而编码”九、如何把这套方法真正落到团队工程流程里一不要全量上最重流程先按风险和复杂度分层1、低复杂度、低失败成本直跑 快速重试2、低复杂度、高失败成本轻量规格 Verify3、高复杂度、低失败成本Sketch / Plan First4、高复杂度、高失败成本完整 SDD 独立验证门二把“规格质量”纳入工程资产而不是临时 prompt1、稳定约束应沉淀成仓库级知识2、任务特定约束应保持短小并与验收绑定三把失败样本变成流程资产才能形成复利一次失败的价值在于以后不再以同一种方式失败十、一个更成熟的结论我们要优化的不是“Agent 自主性”而是“可控的自主性”一完全自动并不天然优于有人类门禁1、实验中 B 的“全自动”与 C 的“需门禁”代表不同产品目标2、门禁应该审查不可逆决策而不是逐行看代码二最终要建立的是工程控制系统而不是更长的提示词1、控制系统至少包含四个闭环2、最强模型也需要可观测性十一、下一轮实验最值得优先回答的六个问题1、同模型同任务重复跑SDD 的提升是否稳定2、只加 Verify不加完整 SDD能否从 18/20 修到 20/203、只加 Sketch/Plan不生成完整规格效果是多少4、Context-hub 对复杂任务的边际收益是否显著高于简单任务5、模型越强SDD 增益是收敛、持平还是转移到更复杂任务6、将“成功率—成本—耗时”画成 Pareto 前沿十二、结语真正稀缺的能力是让模型不漏掉“你以为它应该知道”的那部分可参考文章与资料干货分享感谢您的阅读在一项围绕 DeepSWEabs-module-cache-flags任务的对照实验提供了一个很有代表性的观察窗口在模型基本一致的条件下直接运行 coding agent 可以在约 13 分 26 秒内完成实现但 F2P 仅通过 18/20最终二元 Reward 为 0引入规格驱动开发Spec-Driven DevelopmentSDD后耗时上升到约 44 分钟成本从 5.3413 美元上升到 9.3735 美元但 F2P 达到 20/20Reward 为 1。更值得关注的不是“谁更快”而是两个失败测试都属于典型的隐性语义边界错误包装后的前缀约束、字符串0的真假值与运行时环境优先级。它们说明 coding agent 的主要风险正在从“不会写主路径代码”转向“能写出看似合理的实现却遗漏不显眼但决定交付成败的契约”。我们在原始实验材料基础上结合 DeepSWE、SWE-bench、SWE-agent、GitHub Spec Kit 与上下文工程的公开资料进一步分析 SDD 为什么有效、它究竟在优化什么、成本是否值得以及如何把单点对照升级为可以验证 Context-hub、模型能力、规格粒度与 Verify Gate 价值的系统实验框架。一、一个只有两个失败测试的实验为什么值得认真研究一Coding Agent 的竞争焦点已经从“会不会写”转向“能不能交付”1、代码生成能力越强流程问题越容易成为主要矛盾过去评价代码模型常见问题是“能不能把函数补全”“能不能根据题意写出算法”。进入 coding agent 阶段后任务结构已经完全不同模型需要自己浏览仓库、理解已有抽象、定位修改点、运行测试、解释失败、决定是否继续探索并最终给出一个可以在真实工程环境中被验证的补丁。此时模型只是系统中的一个部件工具接口、上下文供给、任务分解、验证方式和停止条件都会显著影响结果。SWE-agent 的研究很早就明确指出Agent-Computer InterfaceACI的设计会影响语言模型代理的行为与软件工程任务表现。换句话说即使底层模型不变给它什么工具、如何反馈环境状态、允许它怎样编辑和验证代码也可能改变最终成功率。[3] 这一结论与本文分析的实验形成呼应B 与 C 的核心价值不在于比较两个模型而在于同一个能力层级的模型在“直接执行”与“先规格化再执行”的流程下产生了不同结果。DeepSWE 进一步把评测推进到更长链路、更真实的软件工程任务。其公开论文与仓库强调任务是原创的、跨多个活跃开源仓库采用手写功能验证器来检查可观察行为而不是仅复用某个历史补丁自带的测试。[1][2] 这意味着 agent 不能只靠“像一个已知补丁”取巧而要真正满足功能契约。在这种评测环境下流程能否保存需求语义、能否覆盖边界条件、能否对实现进行独立验收就变得比短题中的“生成速度”更重要。2、二元 Reward 会放大“最后两个坑”的工程意义原始对照报告中B 方案的 F2P 为 18/20P2P 为 3/3C 方案的 F2P 为 20/20P2P 同样为 3/3。看起来只是 90% 与 100% 的差异但最终 Reward 一个是 0一个是 1。这正是软件交付与普通问答最不同的地方很多工程任务不是按“平均正确率”结算而是按“是否满足全部关键验收条件”结算。一个支付接口有 18 个场景正确、2 个场景错误不能理解为“90 分基本可用”如果这两个场景分别涉及幂等与金额边界它可能就是不可发布。一个模块加载器绝大部分路径正确但循环依赖错误的语义被包装坏、环境变量优先级解析不符合约定也可能让调试工具、调用方逻辑或兼容行为在真实环境中失效。工程交付里的“最后 10%”往往不是润色而是风险最集中的部分。二实验最有价值的地方是提供了一个近似控制变量1、A 方案适合做旁证B 与 C 才适合做流程因果分析原始材料给出了 A、B、C 三个方案。A 为 Opus-4.8 SDDB 为 Pier 直跑C 为 Opus-4.5 SDD。A 与其他方案在模型或运行环境上存在差异因此它可以说明“SDD 路线也能跑通”但不适合用来证明“SDD 导致了成功”。真正接近控制变量的是 B 与 C二者围绕同一 Opus-4.5 能力层级进行对照主要改变的是执行流程。这一区分非常重要。很多 coding agent 对比会把“模型换了、scaffold 换了、工具换了、提示词换了、测试策略也换了”全部揉在一起然后用一次结果直接归因。这样的实验最多能告诉我们“系统 A 比系统 B 好”却无法回答“好在哪里”。B/C 对照虽然仍是单任务、单次实验但至少把问题收敛到了更有研究价值的方向当底层模型不是主要变量时规格化流程是否能降低边界遗漏2、单任务不能证明普遍规律但足以提出强假设必须强调一次 18/20 对 20/20不能直接推出“SDD 一定优于直跑”。模型推理存在随机性agent 执行轨迹受工具返回、搜索顺序、测试时间、上下文压缩等因素影响。一个更严格的结论应该是这次对照提供了支持“流程显式化隐性约束可以提高边界完整性”这一假设的机制证据。所谓机制证据是指失败不是随机的语法错误也不是“模型完全没理解任务”而是集中在两个典型的契约细节上。更关键的是报告指出这两个坑在 SDD 方案中都被正确处理。这样的结果非常适合进一步做多任务、重复运行、配对统计而不适合停留在“某一次跑赢了”的经验判断上。二、从 18/20 到 20/20真正的差距不是“多想一会儿”而是“提前定义什么算对”一第一个失败错误被二次包裹暴露的是错误语义契约1、异常不仅要“发生”还要以正确形式发生B 方案失败的测试之一是TestChallengeRequireCycleDetection。报告给出的原因是循环错误被doSource二次包裹后原有前缀丢失。这里最容易犯的判断错误是“循环依赖已经被检测出来了功能不是基本正确吗”但对软件接口而言错误的类型、消息前缀、包装层次、可匹配性都可能是契约的一部分。上层代码也许会通过错误类型做分支也可能通过稳定前缀识别特定异常测试之所以检查前缀本质上是在检查一个对调用方可观察的行为。若 agent 只把需求理解为“发现循环就报错”它会倾向于接受任何“看起来合理”的错误包装若规格明确写出“必须保留循环错误的可识别语义不得被通用 source error 覆盖”实现空间就会立刻收紧。2、这是典型的“主路径语义正确、接口语义不完整”人类工程师在熟悉代码库时往往能从现有错误类型、调用链、测试命名、日志规范里推断这些隐含约束。coding agent 也可以做到但它必须在有限上下文与有限搜索预算中决定“哪些细节值得保留”。没有显式规格时模型更容易优化局部合理性让错误路径工作、让测试大部分通过、让代码风格一致。恰恰是这种局部最优可能把“错误必须长什么样”视为非核心信息。二第二个失败0没被判为假值暴露的是配置语义与优先级契约1、字符串配置不是语言布尔值另一个失败测试是TestChallengeRequireRuntimeEnvPrecedenceOverOSEnvForDebug。报告指出0没有被判为假值导致跟踪未关闭。这个问题在工程里极其常见环境变量从操作系统进入程序时通常是字符串0、false、空字符串、未设置变量是否表示关闭需要由产品或代码库约定而不是由编程语言自动决定。如果实现写成“只要变量存在就开启 debug”那么DEBUG0仍然可能被当作真如果还存在 runtime env 与 OS env 的优先级则问题进一步从“值解析”变成“值解析 来源优先级”两个维度。主路径测试通常很容易覆盖DEBUG1但真正容易出错的是关闭语义、覆盖顺序和默认值。2、配置优先级天然属于规格而不是实现细节当一个系统同时存在命令行参数、运行时注入、进程环境变量、配置文件和默认值时优先级应该被视为稳定契约。若没有写清楚agent 很容易依据“常见经验”自行选择顺序而“常见经验”在具体仓库里可能恰好是错的。SDD 的直接价值就是把这种原本散落在代码、测试或历史习惯中的知识转写成一个模型在实现前必须处理的判断题哪些字符串代表 falseruntime env 与 OS env 谁覆盖谁未设置与显式设置为空是否等价debug 关闭时是否仍允许部分 tracing既有行为是否需要向后兼容三两个失败看似无关实质上属于同一种认知缺口1、Agent 容易完成“显性目标”却漏掉“约束目标”需求通常同时包含两类信息。第一类是显性目标例如“支持模块缓存标志”“检测循环”“允许 debug 配置”第二类是约束目标例如“错误前缀必须保持”“某个配置源具有更高优先级”“0必须关闭追踪”。前者决定“做什么”后者决定“做到什么程度才算兼容且可交付”。直接运行 agent 时约束目标往往只存在于任务描述、代码库蛛丝马迹和模型临时注意力中。一旦 agent 开始大量搜索、编辑、运行测试原始要求会与成百上千行工具输出竞争上下文。模型不是完全遗忘而是重要性排序可能发生漂移眼前的编译错误、失败栈和文件内容变得更“近”最初的边界约束变得更“远”。2、SDD 把约束从“注意力问题”转换成“工件问题”如果要求被固化在规格、计划、任务清单和 Verify Gate 中模型每次进入新阶段时不必重新从长对话里“想起”全部需求。它只需要读取当前阶段的结构化工件。这种改变看似只是多了 Markdown 文件实质上改变了信息的生命周期要求不再依赖某一次推理时是否被注意而变成可以被复查、引用、对照和交接的外部状态。三、SDD 到底在做什么它不是“写更多文档”而是为 Agent 建立外部认知结构一把 SDD 理解成一套“意图编译链”更准确1、从自然语言意图到可执行约束需要多次降歧义GitHub Spec Kit 把 Spec-Driven Development 描述为以意图为中心的结构化过程并提供Spec → Plan → Tasks → Implement的核心路径。[4][5] 这种流程的关键不在于文件名而在于每一阶段都在降低一种不同的歧义Spec降低“需求到底是什么”的歧义Plan降低“如何与现有架构兼容”的歧义Tasks降低“执行顺序与完成标准”的歧义Implement才进入代码层若再加入独立 Verify则继续降低“实现看起来对但是否真的满足契约”的歧义。本文可以把完整 SDD 抽象为“需求澄清 → 规格 → 计划 → 任务分解 → 实现 → 验证 → 复盘”七个阶段。需要说明的是原始报告只给出了“SDD 七阶段”的成本统计并没有公开每一阶段的确切命名上述七阶段是为了分析机制而做的通用抽象而不是对原流程内部实现的还原。2、规格的本质是“可执行的判断标准”传统文档经常在代码完成之后补写因此很多工程师会本能地把“写规格”理解为额外负担。AI 原生开发改变了这件事规格不再只是给人阅读的说明而是可以直接进入模型上下文驱动计划、实现与验证。GitHub 对 Spec Kit 的表述也强调规格会成为 agent 的共享事实来源并通过阶段性检查点让人类在实现前发现遗漏。[5]因此一份高价值规格不应该只是把需求扩写得更长而应该增加“可判定性”。例如低价值描述支持通过环境变量关闭 debug。高价值规格运行时环境值优先于 OS 环境值0、false、空值均解释为关闭未提供运行时值时才读取 OS 环境关闭后不得产生 trace 输出既有默认行为保持不变。两段话长度差别不大但第二段可以直接转成测试、检查表与实现分支。SDD 的收益来自这种结构化而不是字数本身。二SDD 同时充当“外部记忆”和“阶段门禁”1、外部记忆解决长链路任务中的上下文衰减Anthropic 将 Context Engineering 定义为在 agent 运行过程中持续选择和维护进入有限上下文窗口的信息集合而不只是写一个更好的初始 prompt。[6] 对长时任务而言历史消息、工具结果、代码片段、计划、状态都会不断增长如果不做主动管理模型容易出现上下文腐化、信息淹没或目标漂移。SDD 的中间工件可以看作一种低成本的上下文压缩不是把所有历史内容都保存而是把“以后还必须记得的内容”提炼成规格与计划。它类似人类团队里的 ADR、任务卡、验收标准和设计说明大家并不需要记住会议每句话只需要保留影响后续决策的结论。2、阶段门禁把错误发现时间从“测试末尾”提前到“计划阶段”对复杂任务而言最贵的错误通常不是写错一行代码而是方向走错后继续执行十几轮。若直接模式在实现末尾才发现“原来0要当 false”模型需要重新定位解析逻辑、修改、复测如果这个要求在计划阶段就进入验收清单错误甚至不会产生。这就是 SDD 的第二个收益把反馈环前移。它用更多前置推理换取更少的后期返工。单次实验里 SDD 总耗时仍然明显更高说明这次前置成本没有被返工节省完全抵消但在更复杂、更长链路的任务上前移反馈是否能降低失败率和重试次数正是值得通过大样本 benchmark 验证的核心问题。三规格本身也会出错因此 SDD 不是天然正确1、错误规格会稳定地放大错误一个经常被忽略的风险是没有规格时agent 可能随机偏离有错误规格时agent 可能非常稳定地执行错误。规格驱动并不会自动把不清晰的产品决策变正确它只是把决策变得更有约束力。因此 SDD 的流程必须允许规格被质疑、修订和验证而不是把第一版 spec 当作圣经。2、最有效的规格不是最详细而是信息密度最高过度规格化同样会伤害 agent。几十页需求里混入大量低价值背景会占用上下文、增加冲突概率、降低模型对关键约束的权重。Context Engineering 的经验反复强调“只保留对下一步有用的信息”。[6] 因而 SDD 的质量指标不应该是“产生了多少文档”而应该是是否覆盖可观察行为是否明确边界值与优先级是否记录不可破坏的兼容约束是否能映射成测试或验证动作是否足够短使 agent 能反复读取而不被噪声淹没。四、重新理解原实验SDD 的收益不是“多做一步”而是改变了错误分布一直跑模式优化的是平均速度SDD 优化的是尾部风险1、13 分钟与 44 分钟分别代表两种优化目标B 方案约 13 分 26 秒完成C 方案约 44 分钟完成墙钟时间约为 3.28 倍。若目标是“尽快产出一个可尝试的 patch”直跑显然更优。它非常适合探索、生成候选解、批量 benchmark 初筛因为同样的算力预算可以跑更多样本。但 C 方案的目标更像“让单次执行尽量跨过完整验收门槛”。在二元 Reward 机制下18/20 与 0/20 最终都可能是 0因此系统优化目标会自然从平均测试通过率转向尾部错误。SDD 本质上是把资源投入到这些低频但致命的遗漏上。2、这与生产系统中的 P99 思维很相似很多在线系统不会只看平均延迟因为 P99 才决定最差用户体验软件交付也不能只看“平均功能正确率”因为最隐蔽的兼容性错误可能决定是否回滚。对 coding agent 而言SDD 类流程可以理解为一种“认知 P99 优化”主路径模型本来就会额外流程主要用于捕获尾部语义、跨文件约束和隐含验收条件。二补丁更小并不自动意味着更好但它提示了搜索纪律的差异1、544 行对 1068 行不能简单解释为“SDD 代码质量高一倍”报告显示 C 方案补丁约 544 行、2 个文件B 方案约 1068 行并注明包含 agent 自己编写的测试。由于统计口径不同不能直接拿 544/1068 得出“SDD 少写 49% 所以更优”的结论。自写测试本身可能是好事也可能扩大 diff。更合理的解读是SDD 在这次任务中表现出更明确的修改边界而直跑 agent 采取了更宽的探索和实现动作。后续实验应该把“生产代码行数”“测试代码行数”“文件数”“无关改动数”分开记录才能判断 SDD 是否真的提高了 patch 精确性。2、Patch Scope 是值得加入 benchmark 的工程指标对于真实代码库过大的补丁会增加 review 成本、回归面和合并冲突。即使两个方案都通过测试修改 2 个文件与修改 12 个文件的风险并不相同。因此下一代 agent benchmark 不应只输出 solved/unsolved还应该统计修改范围、无关 diff、重复代码、复杂度变化等指标。2026 年的一些长时软件演进研究已经开始关注“当前测试通过但代码结构逐步恶化”的问题这说明只用一次性 pass rate 衡量 agent 越来越不够。[9]五、成本账SDD 为什么更贵以及“贵多少才值得”应该怎样算一原始成本表揭示了一个非常有意思的结构1、调用次数、输出 token 与成本都显著上升报告中的成本估计显示直跑 claude-code 发生 76 次 LLM 调用SDD 七阶段为 141 次约 1.86 倍输入 token 从 7,765,264 上升到 10,570,120约 1.36 倍输出 token 从 25,695 上升到 70,298约 2.74 倍成本从 5.3413 美元上升到 9.3735 美元约 1.75 倍。这说明 SDD 的主要成本并非只是“多读了一点上下文”而是多轮阶段推理与更多显式产物生成。输出 token 增幅最大符合“需要生成 spec、plan、task、verify 结论”等中间工件的直觉。2、“新输入”反而下降提示结构化工件可能改善缓存与复用报告同时列出一个值得追踪的细节直跑的新输入为 18,182而 SDD 为 9,529缓存读从 7,619,341 增加到 10,162,655缓存写从 127,741 增加到 397,936。由于材料没有给出供应商计费与缓存实现的完整定义不应对这些数字做过度解释。但它至少提示一个实验方向结构化、稳定的阶段工件可能让更多上下文以可复用形式被读取而不是不断生成新的临时输入。如果这一现象在更大样本上成立SDD 的成本优化重点就不应该只是“少调用模型”还包括“让阶段上下文可缓存、可裁剪、可复用”。这与 Context Engineering 的核心目标高度一致。二是否值得取决于失败成本而不是只取决于 token 单价1、对 benchmark 来说1.75 倍成本换 0→1 Reward 可能非常划算如果一次成功解决任务的价值远高于多花的约 4 美元那么这次 SDD 显然是正收益。特别是在二元验收里直跑的 90% 测试通过并没有转化为任何最终 Reward。从“每次尝试成本”看 SDD 更贵从“交付一个通过完整验收的结果需要多少总成本”看直跑方案可能需要多次重试甚至需要人工定位最后两个坑真实成本未必更低。2、对大规模探索来说直跑依然可能是全局最优反过来如果我们要在 113 个任务上快速比较十个模型或十种 scaffold全部使用最重的 SDD 会极其昂贵。此时更合理的策略是分层先用直跑得到宽覆盖结果再对失败但接近通过的任务升级到规格/验证流程或者让 agent 先生成草案再由一个较小成本的 verify 阶段专门检查边界。这意味着最终工程形态很可能不是“所有任务都 SDD”而是动态流程路由根据任务复杂度、失败成本、历史成功率、测试信号决定当前任务应该使用多强的结构化流程。六、Context-hub 应该怎样被验证先把概念从“感觉有帮助”变成可测量变量一报告提出了正确的问题但 Context-hub 的定义仍需要先操作化1、材料提出两阶段 benchmark 思路但没有给出实现细节原始报告建议先用开源 benchmark 验证 Context-hub 的增益再用自建 benchmark 检查简单/复杂问题、Sketch/SDD、模型能力和 Verify 的影响。这是一个很好的研究框架雏形。但材料并没有定义 Context-hub 到底包含哪些信息、如何检索、何时注入、是否跨任务记忆。因此本文不能把它当作一个已知实现来描述。为了便于实验本文将 Context-hub分析性抽象为一个“上下文供给层”它负责在不同阶段向 coding agent 提供项目规则、相关代码、历史设计决策、既有失败模式、接口契约与验收信息。这个抽象只用于实验设计不代表任何具体内部产品实现。2、没有操作化定义就无法判断增益来自哪里假设“开启 Context-hub”后成功率提升我们至少需要知道是因为多提供了相关代码是因为提供了历史 ADR/规范是因为把之前失败样本写成了记忆是因为检索减少了无关上下文还是因为 Context-hub 顺便改变了系统提示或工具调用因此 Context-hub 的实验不应只有 on/off 两个黑盒版本。至少应该记录每次注入了哪些上下文类别、token 数、检索命中、agent 实际引用了哪些信息以及这些信息是否在原始仓库里可通过普通搜索找到。二最推荐的是“分层因子 配对运行”而不是排行榜式混跑1、核心因子至少有五个可以把实验设计成五类主要变量问题复杂度简单问题 vs 复杂/长链路问题上下文供给Context-hub 关闭 vs 开启开发流程直跑 vs Sketch/Plan First vs 完整 SDD模型能力轻量模型、中等模型、前沿模型验证强度仅基础测试 vs 独立 Verify Gate。这五类变量可以回答报告里最重要的四个问题复杂问题是否更受益SDD 是否比 Sketch 更有增益模型越强时“拐杖”是否仍然有效Verify 到底贡献了多少。2、不要用“不同模型跑不同流程”替代真正控制变量例如“模型 A SDD 比模型 B 直跑高 10 分”没有足够解释力。更有价值的是对同一个任务、同一个模型版本、同一个环境镜像随机运行多次 direct/Sketch/SDD并使用相同的最大预算。如此才能估计流程的平均处理效应。若模型本身具有非确定性至少应保存多个随机种子或多次轨迹并报告均值、置信区间与 Passk而不是只展示最好一次。DeepSWE 公共评测本身也强调完整轨迹与可验证结果适合做这种更精细的对照。[1]三指标体系必须同时覆盖质量、成本和过程1、质量指标不能只剩一个 Reward建议至少保留二元 Reward / solvedF2P、P2P 等子指标首次通过率边界测试通过率回归测试失败数人工复核发现的语义错误数patch scope 与无关改动若是长期演进任务再加入可扩展性和结构退化指标。二元 Reward 对最终交付非常重要但它不告诉我们“为什么失败”。研究 Context-hub 或 SDD 时失败结构比一个总分更有价值。2、成本指标要拆成“推理成本”和“等待成本”建议统一记录LLM 调用数、输入 token、缓存读写、输出 token、模型费用、工具调用数、测试次数、墙钟时间、CPU/容器时间、人工门禁时间。这样才能回答“SDD 贵在模型还是贵在串行流程”“Verify 是计算密集还是推理密集”“Context-hub 是否减少搜索步骤”等问题。3、过程指标能够解释同样结果背后的不同路径两个 agent 都通过 20/20一个可能第一次实现就通过另一个可能改了六轮、运行了二十次测试。对生产效率来说二者差异巨大。因此应保存探索文件数、计划变更次数、失败后回滚次数、上下文压缩次数、被读取的 spec 条目、最终实现与规格的覆盖关系。七、为什么“模型变强后SDD 就没用了”是一个过早的结论一模型能力和流程能力是互补关系不是简单替代关系1、更强模型会降低显性错误但系统复杂度也会同步上升报告把 SDD 比作“拐杖”并提出一个非常关键的问题模型能力变强后拐杖还有多大作用这是必须验证的而不是靠直觉回答。强模型确实更可能主动发现边界条件、更能理解多文件架构也可能在没有显式 spec 时自行生成计划。因此在简单任务上SDD 的边际收益很可能下降甚至出现“多做流程只增加成本”的情况。但与此同时强模型被委托的任务通常也会变复杂从改一处 bug 变成跨模块重构从 10 分钟任务变成数小时任务从单仓库修改变成包含部署、数据迁移和文档更新的完整工作流。能力提升会抬高任务天花板因此“更强模型不需要流程”并不必然成立。人类最强的工程师也仍然使用设计文档、测试、代码审查和发布门禁原因不是他们不会编码而是复杂系统需要外部协调机制。2、模型越强流程可能从“纠错器”升级为“能力放大器”弱模型需要 SDD 帮它记住需求强模型可能利用 SDD 做更深入的方案权衡、并行子任务拆分、风险清单和验证设计。此时 SDD 的价值不再是“防止低级遗漏”而是把模型的推理能力组织到一个可复查、可协作、可复现的工程过程里。二真正可能消失的不是 SDD而是固定、笨重的 SDD1、未来更合理的是自适应规格深度简单任务只生成 10 行验收清单复杂任务生成完整 spec高置信度路径直接实现低置信度或多模块任务自动进入 plan当测试显示边界失败时再升级 verify。也就是说SDD 可能从“固定七阶段流水线”演化成“动态决策策略”。2、规格会越来越机器可读而不是越来越像传统文档最理想的规格未必是长 Markdown而可能是结构化约束接口行为、状态机、属性测试、允许/禁止的修改范围、兼容矩阵、可执行示例。随着 agent 工具链成熟spec、test 与 verifier 的边界可能进一步融合一部分需求直接编译成验证器一部分成为检索上下文一部分成为执行计划。这也解释了为什么 Spec-Driven Development 与 Context Engineering 会逐渐靠近。一个负责定义“必须知道什么”另一个负责决定“在当前时刻把哪些信息送进模型”。两者组合起来才是长链路 coding agent 的真正控制平面。八、Verify 的位置可能比 SDD 本身更值得单独拆解一报告已经暗示了一个有吸引力的折中先快跑再独立验收1、Hybrid 模式可能拿到大部分收益却不承担全部 SDD 成本报告给出的场景建议里有一个很实用的折中agent 先出草案再在 SDD verify 阶段补做边界体检。它值得被单独做成实验组因为 B 方案的问题不是完全没实现而是最后两个边界漏掉。如果一个独立 verifier 能在 13 分钟的草案上发现这两个问题再让原 agent 定向修复可能比完整 44 分钟 SDD 更高效。这个策略的本质是把“生成”和“审计”分离。生成 agent 追求速度和覆盖验证 agent 追求反例、边界和契约一致性。Anthropic 关于有效 agent 工作流的工程总结也强调复杂系统可以使用 evaluator-optimizer 等反馈模式让一个模型生成、另一个模型依据明确标准评价并触发迭代。[7]2、Verify 应该尽量独立于实现轨迹如果验证阶段只是让同一个 agent 再问自己“你确定吗”很容易受到已有方案的锚定影响。更高质量的 Verify 应该重新读取任务规格与最终 diff尽量减少实现过程中的推理历史只问哪些要求没有证据证明已满足哪些边界值还没有测试哪些错误或配置语义被实现改变是否存在无关改动或回归风险是否能构造一个反例击穿当前实现这种独立视角有点像代码审查而不是继续编码。二验证器质量决定了整个闭环的上限1、测试不是越多越好而是要覆盖可观察行为DeepSWE 的一个重要设计选择是手写功能验证器强调检查任务描述所要求的可观察行为并允许不同内部实现通过。[1][2] 这与 SDD 非常契合规格定义可观察契约verifier 检查契约而不是强迫 agent 复刻某个参考 patch。2、如果验证器只复现实现偏好会产生“为了测试而编码”这也是很多 benchmark 的结构性风险。测试若过于绑定参考实现agent 可能被判错即使行为合理测试若太弱agent 又可能通过不完整实现。因此在自建 Context-hub benchmark 里验证器本身需要独立审查并最好采用“需求条目—测试条目”映射确保每个核心约束都有对应证据。九、如何把这套方法真正落到团队工程流程里一不要全量上最重流程先按风险和复杂度分层1、低复杂度、低失败成本直跑 快速重试适合原型、一次性脚本、探索性修改、benchmark 大规模初筛。目标是提高吞吐不追求每次都完美。需要的只是最小任务描述、可运行测试和明确停止条件。2、低复杂度、高失败成本轻量规格 Verify例如配置变更、权限逻辑、接口兼容性、小范围核心代码。实现本身不复杂但一个边界错误可能影响生产。此时不一定要完整七阶段只需要把验收边界写成短清单并独立验证。3、高复杂度、低失败成本Sketch / Plan First适合技术探索、可丢弃实验、多方案原型。先要求 agent 给出架构 sketch、修改范围和不确定点人类快速看一眼再允许执行。这样可以控制大方向而不需要为每个细节写完整规格。4、高复杂度、高失败成本完整 SDD 独立验证门核心交易链路、兼容性重构、跨服务协议、发布迁移等任务应把规格、计划、任务、实现证据和验证结果都保存下来。此时 SDD 的额外成本更容易被风险降低与审计价值抵消。二把“规格质量”纳入工程资产而不是临时 prompt1、稳定约束应沉淀成仓库级知识例如错误类型约定、环境变量真假值规则、配置优先级、日志与追踪规范、公共 API 兼容策略、测试命名规范。这些内容如果每个任务都重新让 agent 从代码里推理既浪费 token也容易不一致。它们更适合沉淀成可检索、可版本化的项目知识由 Context-hub 或类似机制按需注入。2、任务特定约束应保持短小并与验收绑定本次abs-module-cache-flags任务最关键的两条边界完全可以在一个很短的任务规格里写清。理想状态不是“每个任务都写十页 spec”而是用几十行把会决定 Reward 的语义列清楚并为每条约束指定验证方式。三把失败样本变成流程资产才能形成复利一次失败的价值在于以后不再以同一种方式失败如果 B 方案的两个坑只被修在代码里下一次遇到另一个仓库的错误包装或环境变量解析agent 仍可能重犯。如果团队把它们抽象成通用检查模式错误包装是否改变可观察语义字符串配置是否显式定义 truthy/falsey多来源配置是否有优先级表那么一次 benchmark 失败就会变成后续任务的先验知识。这正是 Context-hub 最值得验证的复利效应不是一次检索多给几段代码而是让历史工程经验能够被后续 agent 可靠调用。十、一个更成熟的结论我们要优化的不是“Agent 自主性”而是“可控的自主性”一完全自动并不天然优于有人类门禁1、实验中 B 的“全自动”与 C 的“需门禁”代表不同产品目标B 方案全自动完成C 方案需要门禁。若只看自动化率B 更漂亮若看最终 RewardC 更好。真正的产品问题不是“能不能去掉人”而是“在人参与最少的前提下把失败概率降到目标水平”。很多成熟自动化系统都不是追求 100% 无人而是把人放在最有杠杆的位置审核规格、批准高风险计划、处理低置信度异常。随着模型能力提升人类门禁可以越来越稀疏但不一定立即消失。2、门禁应该审查不可逆决策而不是逐行看代码如果 SDD 只是把人工 review 变成“每一步都点确认”那么速度损失会非常大也难以规模化。更合理的是让 agent 自动完成大部分低风险动作只在以下节点请求人类判断需求存在多种合理解释计划会改变公共 API 或数据格式需要删除/迁移大量代码测试与规格发生冲突Verify 发现无法自动裁决的行为差异。这会把人类从“执行监督者”升级为“目标与风险裁决者”。二最终要建立的是工程控制系统而不是更长的提示词1、控制系统至少包含四个闭环一个可靠的 coding agent 平台长期看需要四个相互作用的闭环意图闭环需求 → 规格 → 澄清执行闭环计划 → 工具调用 → 环境反馈 → 修正验证闭环实现 → 测试/审计 → 反例 → 修复学习闭环失败/成功经验 → 可复用知识 → 后续上下文供给。SDD 主要强化前两个Verify 强化第三个Context-hub 可能承担第四个并反向增强前三个。把它们分开测量才能知道系统真正的收益来自哪里。2、最强模型也需要可观测性OpenAI、Anthropic 以及 SWE-agent 等公开系统都越来越强调通过终端日志、测试结果、工具调用和阶段状态提供可验证证据而不是只返回最终代码。[3][7][8] 这不是因为模型能力不足而是因为软件工程天然需要可追溯性。一个只能“给答案”的 agent 很难进入生产一个能解释自己做过什么、依据什么、哪些验证通过、哪些假设仍未确认的 agent才更接近可委托的工程执行单元。十一、下一轮实验最值得优先回答的六个问题从低成本到高信息量排序1、同模型同任务重复跑SDD 的提升是否稳定对abs-module-cache-flags至少做多次 direct 与 SDD 配对运行报告 F2P/Reward 分布和成功率置信区间。先确认这不是一次轨迹偶然性。2、只加 Verify不加完整 SDD能否从 18/20 修到 20/20这是最有商业价值的消融实验。如果成立说明大量收益来自“独立边界审计”可以构建更轻的默认流程。3、只加 Sketch/Plan不生成完整规格效果是多少这能回答“SDD 的收益到底来自先规划还是来自验收约束显式化”。如果 Plan 能解决大部分问题则完整 SDD 只需用于高风险任务。4、Context-hub 对复杂任务的边际收益是否显著高于简单任务报告已经给出这一理论预期。实验上应做交互效应而不是只分别看简单/复杂平均分。若复杂度越高、Context-hub 增益越大才能证明它解决的是长链路上下文问题而非一般 prompt 增强。5、模型越强SDD 增益是收敛、持平还是转移到更复杂任务同一批任务上使用多档模型比较Δsuccess success(SDD) - success(direct)。如果简单任务上的差值下降但复杂任务仍保持说明流程价值从基础纠错迁移到长时协调。6、将“成功率—成本—耗时”画成 Pareto 前沿最终决策不能只按分数排名。一个方案成功率 80%、成本 1另一个成功率 90%、成本 4第三个成功率 88%、成本 1.5。真正应该选择的是 Pareto 前沿上的方案再根据业务失败成本选点。这样才能把“流程好不好”转化成可用于产品决策的经济模型。十二、结语真正稀缺的能力是让模型不漏掉“你以为它应该知道”的那部分abs-module-cache-flags的对照结果之所以有启发性不是因为 SDD 在一个任务上拿到了 20/20也不是因为直跑只差两个测试而是因为这两个测试精准地击中了当前 coding agent 的典型薄弱点模型通常能够完成显而易见的实现却可能遗漏那些没有被明确写成判断标准的工程语义。直接模式的优势是真正的快、自动、适合大规模探索。SDD 的代价也是真正的更多模型调用、更多输出 token、更长墙钟时间、更复杂的流程状态。不能因为一次成功就把 SDD 神化成通用答案。但这次实验同样清楚地说明当任务以完整验收为门槛时“先固化验收口径”可以改变错误分布把一部分隐性约束从模型的临时注意力转移到可复查的外部工件中。下一阶段最重要的工作不是继续争论“直跑还是 SDD”而是把它们拆成可测量的机制规格、计划、上下文供给、验证、人工门禁分别贡献多少在什么复杂度下开始值得随模型变强哪些环节可以省略怎样用 Context-hub 把历史失败与项目规则转化为可复用上下文怎样让验证器真正检查行为契约而不是参考实现偏好。如果这些问题被系统地回答coding agent 的发展方向就会从“更会写代码的聊天机器人”转向“具有工程控制面的自主执行系统”。届时决定生产可用性的可能不再只是模型榜单上多几个百分点而是一个更朴素的问题系统能否稳定地把需求里的隐性约束变成显式、可执行、可验证、可追溯的工程事实。可参考文章与资料DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering TasksarXiv, 2026DeepSWE 官方 GitHub 仓库datacurve-ai/deep-sweSWE-agent: Agent-Computer Interfaces Enable Automated Software EngineeringarXivGitHub Spec Kit 官方文档Spec-driven development with AI: Get started with a new open source toolkitGitHub BlogEffective context engineering for AI agentsAnthropic EngineeringBuilding Effective AI AgentsAnthropic EngineeringIntroducing CodexOpenAI, 2025SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative TasksarXiv, 2026SWE-bench 官方 GitHub 仓库mini-SWE-agent 官方 GitHub 仓库