ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

superpowers Strict-Cost SDD:用实验阶梯把 Subagent-Driven Development 的单次执行成本压到最低

2026/9/5 15:48:11 拓冰建站 浏览量
superpowers Strict-Cost SDD:用实验阶梯把 Subagent-Driven Development 的单次执行成本压到最低 superpowers Strict-Cost SDD用实验阶梯把 Subagent-Driven Development 的单次执行成本压到最低【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers本文以 superpowers 仓库中的设计规格 docs/superpowers/specs/2026-06-10-strict-cost-sdd-design.md 为主体完整拆解“Strict-Cost SDD”的成本优化方案一次计划执行的钱花在了哪里、优化阶梯 L1–L5 各自改什么、每级必须通过哪些质量门以及两条不可妥协的护栏——“只降机械成本不降判断成本”与“每个任务一个新子代理”的 SDD 论文thesis。读完本文你可以掌握 SDD 的成本结构分析方法、预注册实验门N5 场景门 判断审计的设计思路并能对照当前仓库源码验证哪些改动已经落地。目标、状态与质量不变量该规格开篇就明确了三件事状态这是一个“拟议的实验阶梯Proposed experiment ladder不是实现”。每一级rung只有在携带其门证据时才发布任何一门失败该级即中止abort any rung whose gates fail。目标最小化“每个计划执行的美元数”minimize dollars per plan-execution。墙钟时间不受约束token 数量只作为成本驱动因素被考虑。硬性不变量质量。具体量化为——sdd-quality-reviewer-catches-planted-defect质量评审者能否抓住被故意植入的缺陷在N5 次运行下的通过率不是 1 次单运行门是上一轮实验战役中最薄弱的方法论、sdd-rejects-extra-features拒绝额外功能通过、所有端到端场景通过、以及配置盲测 A/B 交付物持平。任何质量回退直接杀死该级“full stop”。这套规格的方法论底色值得注意预先注册门pre-registered gates、用区间而非单点报告结果、把“实验失败”本身当作有价值的产出L2/L3 的最终状态都是“死于门内”但产生了可复用的解剖学结论。钱花在哪里约 $13/run 的成本拆解以 2026-06-10 的最终配置、go-fractals 场景、约 $13/次执行为基准规格把美元逐项拆开组件金额驱动因素Controller会话模型opus~$6-7~150 轮 × 常驻上下文提示词免疫的轮次下限46% 为思考/叙述Implementerssonnet10-13 次派单~$5-6真正的干活环节每个约 25 轮每个约 13 次编辑前探索调用Task reviewerssonnet10 个~$1-1.5每个 3-9 轮携带 packageFinal review fixes~$16 轮携带分支 package两个关键观察Controller 占了约一半的钱原因仅是它继承了会话模型。它的轮次下限对提示词“免疫”实验实测controller 每条消息恰好发出一个工具调用46% 的轮次是思考/叙述所以杠杆不在轮数而在每轮的费率——这就是 L2。评审循环次数每次运行 2-4 个是最大的运行间成本方差来源而循环大多由“计划本身有歧义、实现者理解错了”导致——这就是 L1 从计划侧动刀的根据计划位于所有成本的上游任务数决定派单数计划歧义决定评审循环数计划完整性决定实现者的探索量。当前 SDD 的完整执行机制可对照 skills/subagent-driven-development/SKILL.md每个任务派一个新实现者子代理implementer-prompt.md完成后生成评审包并派任务评审者task-reviewer-prompt.md带 5 轮上限的修复循环最后是整分支评审。成本表里的每一行都对应这套流程中的一个派单角色。判断护栏Judgment Guardrail只降机械成本绝不降判断成本这是与质量并列的共不变量每一级都必须枚举出它把哪些决策移到了更便宜的模型上并证明每个被移动的决策都是机械性的——可确定性判定、可脚本化或事后廉价可验证。判断始终留在最高档模型或人手里。规格明确列出了 SDD 中的六个判断点BLOCKED / NEEDS_CONTEXT 处理——诊断子代理为什么卡住、选择补救措施⚠️ “cannot verify from diff” 的裁决——controller 用跨任务上下文做裁定派单策展Dispatch curation——歧义消解与任务边界划定实测承重某次 Task 5 的梯度方向备注阻止了一次错误实现评审结论与严重度校准——什么算 Important、什么只是 Minor评审循环仲裁——判定某条 finding 是误报升级给人的识别——意识到是计划本身错了。任何一级若想把上述决策下放到更便宜模型只有三条路(a) 重构让昂贵模型在计划期一次性做完该决策(b) 增加显式升级规则在执行期把它路由回上层(c) 死掉。并且“廉价模型通常能蒙对”不算验收证据——判断失败是低频、高爆炸半径、且对 pass/fail 门大体不可见的事件。因此每一级除了 N5 场景门还必须附带判断审计judgment audit对门运行中每个判断点做 session-resume 追问并与昂贵 controller 基线逐点比对任何“被廉价 controller 悄悄吸收的判断”本应升级却自行裁决直接判该级失败。这六个判断点在现实现中都有对应物BLOCKED 处理与 ⚠️ 项裁决、修复循环到第 5 轮时的 breaker 仲裁park 或 STOP: BLOCKED、以及“发现与计划文本冲突时问人哪边为准”的规则都写在 skills/subagent-driven-development/SKILL.md 的 Task Loop 与 Fix loop 章节中。论文护栏Thesis Guardrail每个任务一个新鲜子代理SDD 的论文是每个任务一个全新子代理 精确策展的上下文 每任务一道门。阶梯中的每一级都必须保住这一点。规格特别点名派单期任务打包dispatch-time task batching一个实现者一次处理多个计划任务是反论文的——它污染“新鲜上下文”这一性质并让门变粗——因此被刻意排除在阶梯之外。与之兼容的、通往同样派单经济性的路线是计划期任务调尺plan-time task right-sizing即 L1如果计划定义了更少、尺度更好的任务SDD 仍然每个任务派一个新子代理。“新鲜上下文”在 skills/subagent-driven-development/SKILL.md 中是第一性原则“They should never inherit your sessions context or history — you construct exactly what they need.” 派单上下文由此被工程化为文件交接task brief 文件、report 文件、review package 文件使 controller 的常驻上下文不被子代理输入输出撑爆——这正是 L4 要继续榨取的部分。实验阶梯按预期 $/杠杆排序L1 — 计划侧精确化writing-plans 改动预估 −$1.5-3/run另加方差缩减对 writing-plans 的四项改动任务调尺Task right-sizing指引。今天的计划会产出小到“创建 .gitignore”的任务——每个任务都摊上一次完整派单 评审循环约 $0.60-1.00 固定开销。新增指引“任务是最小单元自身携带一个测试周期并值得一个全新评审者的门。把 setup/config 步骤并入需要它的任务只在评审者可能合理地否决一个而批准相邻任务的地方拆分。” 实测 fractorls 的计划可从 10 个任务降到约 7 个。验证标准派单数下降、门保持、评审粒度仍能抓住植入缺陷。计划头部的结构化## Global Constraints小节版本下限、命名/文案规则、平台要求。过去这些约束散落在 design.md 的散文里能否到达评审者取决于 controller 是否记得粘贴曾有一次go 1.26.1版本下限违规被放行因为没有任何评审者见过它。固定标题使其可被机械提取——task-brief脚本可以自动把它们追加到每个 brief一个很小的脚本改动彻底移除一项 controller 职责。每任务一行Interfaces:consumes/produces精确签名。controller 目前在每次派单时重新推导跨任务接口这是它最正当的“复述”而实现者每个任务要花约 13 次工具调用重新发现上下文。计划者本来就知道这些接口每任务一行把重复工作移到只发生一次的地方。每任务的模型档位推荐planner 标注 “mechanical / standard / judgment”。planner 对 Model Selection 决策拥有最好的信息controller 目前却每次派单重新做一遍controller 保留否决权。仓库证据L1 的前三项已落入当前 writing-plans。从仓库当前状态看skills/writing-plans/SKILL.md 已经包含计划头部模板中的## Global Constraints小节“版本下限、依赖限制、命名与文案规则、平台要求——每条一行值从规格逐字复制每个任务的需求隐式包含本节”、任务结构中的**Interfaces:**块Consumes/Produces精确签名以及 “Task Right-Sizing” 章节“任务是最小单元自身携带测试周期并值得一个全新评审者的门……只在评审者可能合理地否决一个而批准相邻任务处拆分”。规格中第 4 项每任务模型档位推荐在当前 writing-plans 的任务结构中尚未出现。L1 的最终状态2026-06-11规格已回填elicitation 经过端到端测试结论被重新归因。微测试约束头与 Interfaces 块可被确定性诱导0→5/50→100% 的任务值精确任务调尺效果温和且依赖规模svelte 规模下 9.4→8.4 个任务fractals 规模无可移动空间。全量运行诱导出的计划执行于 $6.34/$8.49——但无引导对照组opus 写计划、完整代码落在 $7.59/$7.73处于同一区间。成本优势归属于“opus 书写的完整代码计划”此前所有数字所用的手写散文 fixture 计划不具有代表性执行成本约贵 2×。引导真正拥有的是保真度与方差确定性的约束传播诱导运行中唯一一次修复是版本下限的捕获、精确的跨任务接口、修复波 1 vs 2-4 次对照计划两次运行都引入了一个真实的 Sierpinski bug 需要修复。因此 writing-plans 的 PR 主张这些依据而不是美元数。另外2026-06-10 的结论是当前 opus 无法诱导计划占位符——这些改动针对的是经济与歧义不是占位符卫生。L1 与执行脚本的衔接也值得对照源码skills/subagent-driven-development/scripts/task-brief 当前用 awk 从计划文件中按Task N标题提取单个任务的全文写入repo-root/.superpowers/sdd/plan-basename/task-N-brief.md输出如wrote ...: N lines保证任务文本一次进入实现者上下文、而不经过 controller 的常驻上下文。规格设想的“自动追加 Global Constraints 到每个 brief”即在此脚本上的小改。L2 — Controller 档位预估 −$4-5/run最大的单杠杆门最严Controller 的轮次下限对提示词免疫杠杆是每轮费率但判断点大多住在 controller 里所以这一级被设计成判断优先主形态——判断前置机械变便宜昂贵模型在计划期完成判断密集的工作L1 的 Interfaces 行、歧义消解、每任务约束——即派单策展被预先写进计划。中档执行会话跑的循环因此真正机械提取 brief、派单、跑脚本、路由裁决。技能中写死显式升级规则遇到 BLOCKED、任何 ⚠️ 项、疑似误报、或计划未回答的任何事廉价 controller停下并升级给人或给一次昂贵模型的新咨询派单——它从不独自裁决判断。超越 N5 的门判断审计见上文任何被悄悄吸收的判断直接判级失败。保留用户权限技能只推荐、不强制执行会话的模型档位。本战役的警告廉价模型轮次膨胀是在多步骤工作上测得的中档 controller 能否稳住 ~150 轮本身就是实验要回答的问题之一。最终状态2026-06-11死于门内DIED AT THE GATES如预注册——但解剖学有用。侦察recon是正向的sonnet controller 两次全跑 $6.68/$8.05、31-41 分钟对照组带宽 $11.67-14.84token 在带宽内无廉价 controller 轮次膨胀26/26 与 31/31 派单显式指定模型haiku 分层更重且合理两轮中均未触发 BLOCKED/⚠️ 事件升级点从未被压测且最终评审跑在 sonnet 而非最强档。完整电池把判断面劈开了新场景sdd-escalates-broken-plan显式的计划自相矛盾人永远不会主动报告它在sonnet 上 5/5 通过$1.02-1.37/runopus 基线 2/2——显式冲突会被升级。但植入缺陷电池决定性失败sonnet controller 下每任务质量门塌缩为“计划合规辩护”no assertion, as required 被写进了 Strengths缺陷在 4/5 次运行中放行确定性检查只有档位钉死的 opus 最终评审者抓到了它——而同一批 sonnet 评审者在 opus controller 下 5/5 标出。廉价 controller 能处理显式升级却会吸收隐式的“权威 vs 质量”裁决。L2b两条离散规则2026-06-11 测试改善了 opus 栈但救不了 sonnet 级规则一是评审者绊线计划强制的缺陷是finding——Important标注 plan-mandated由人决定规则二是 controller 升级规则plan-mandated finding 与任何计划矛盾一样交给人。在冻结的 sonnet 组合输入上微测试从 0/6 提到 6/6 标注 finding全电池中 opus controller 2/2 内化规则、把评审者漏报作为自述 backstop 抓住并升级sonnet controller 仅 1/5 全过——复述会把绊线从派单中丢掉2/5 传输成功仅传输不足以在实战中触发它评审者多次工具读取中的 read-once 稀释“放在派单什么位置”被证伪为变量且没有任何 sonnet controller 展现 backstop 行为1/5 放行了缺陷。L2b 规则是 opus 栈的候选提交面向 sonnet 级的未来 L2c 设想是把 SKILL.md 的 constraints-recipe唯一能被 sonnet 逐字传输的通道与一个 plan-mandated finding 的强制输出格式槽位配对骨架在一切观察到的复述中存活且组合时被查阅——未测试。仓库证据L2b 的评审者绊线已经体现在当前 skills/subagent-driven-development/task-reviewer-prompt.md 的 Calibration 段——“如果计划或 brief 明确要求本 rubric 视为缺陷的东西断言为空的测试、逐字复制逻辑块那就是finding——按 Important 上报标注 plan-mandated。计划的作者不能给自己打分由人决定。” 而 skills/subagent-driven-development/SKILL.md 的 Model Selection 章节则固化了“每次派单必须显式指定模型省略会静默继承会话上最贵的模型”“轮次数量胜过 token 单价”等经验——后者正来自本轮实验的负结果廉价模型在多步骤工作上常多花 2-3× 轮次总成本反而更高。L3 — 评审者档位预估 −$0.7-1/run最可能死于判断护栏的一级状态2026-06-11已死DEAD如预注册。强制 haiku 做任务评审者的植入缺陷 ×52 过 / 1 不定 / 2 失败基线 5/5按任务口径haiku 以正确严重度标出 10 个植入缺陷中的0个——1 个“找到但降级”且用了被明确禁止的理由9 个漏掉或合理化把 DRY 违规夸为 YAGNI把断言为空的测试称为“计划合规”。廉价评审者是以“替缺陷辩护”的方式失败的仅有的通过运行靠的是 controller 冗余或最终评审兜底。结论没有结构性不同的设计不要重新提出该级。设计动机本身就说明问题package 评审者平静时近乎单步机械3 轮 / 1 次 Read这否定了“中档下限”的原始轮次膨胀理由但评审通篇是判断——严重度校准、规格裁决、知道什么不该标。“机械上便宜”不等于“决策是机械的”。测试条件也被预注册得很严只允许用完整判断电池植入缺陷 ×5、严重度校准检查——预埋 Minor-vs-Important 对校准失误即判级失败、在该档位复测 escape-hatch 方差。规格甚至预判了结果“这一级会死而那是个不错的结果——它把‘我们怀疑廉价评审者不行’变成了记录在案的证据。”L4 — 常驻上下文节食预估 −$0.5-1/runtask-brief --list模式controller 只读任务标题 Global Constraints从不读全计划计划正文已经通过 brief 文件交付了。报告从 15 行压到 8 行。SKILL.md 压缩 pass本周新增的每个小节都按“组合配方密度”重新证明其存在价值Codex 长会话里要付出约 10k 字符 × 约 500 次重读的代价。L4 是对既有文件交接机制的进一步榨取。当前 skills/subagent-driven-development/scripts/review-package 已把 commit 列表、stat 摘要与-U10完整 diff 写进一个按 SHA 区间命名的文件默认repo-root/.superpowers/sdd/plan-basename/review-base7..head7.diff使 diff“永不进入 controller 自己的上下文评审者一次 Read 拿到全部”——这正是 2026-06-09 任务级评审设计在“最终冻结配置”中验证过的结构最终评审从 33 轮降到 6 轮。skills/subagent-driven-development/SKILL.md 中“The Task Loop”的开篇即此原理“你粘贴进派单提示的一切、子代理回显的一切都会常驻你的上下文并在之后每一轮被重读。把工件当文件交接。”L5 — 重开之战已标记维护者否决或反论文为完整性记录每一项在实验前都需要维护者明确推翻范围化复审scoped re-reviews验证修复 回归扫描替代全量复审2026-06-09 被否决价值至多约 $0.50/run。派单期任务打包反论文见论文护栏。L1.1计划期调尺是受认可的形式。预算与排序L1 与 L2.1 相互独立——先同时跑约 $80微测试 2×5 次运行门 A/B。L3 在 L2 定案 controller 之后再跑评审者行为依赖派单质量约 $25——植入缺陷运行每次 $2-3。L4 最后便宜但堆叠完成后要重跑一次门约 $30。全阶梯诚实的 N5 门总预算≲ $150。预期终态若每一级都活过它的门——fractals 上 $5-7/run从 $12-15 降下若判断敏感级L2 超出其主形态的部分、L3如预期而死——$8-10/run。后者才是诚实目标因为护栏在构造上就把判断定价得高于美元。与既有工作的关系一条连续的成本迭代链这份规格不是孤立文档它站在前序工作的肩膀上2026-06-09 任务级评审派单设计docs/superpowers/specs/2026-06-09-sdd-task-scoped-review-dispatch-design.md对应 PR #1717 与计划 docs/superpowers/plans/2026-06-09-sdd-task-scoped-review-dispatch.md把 per-task 评审收窄为任务级门把 spec 与 quality 合并为一个评审者两个裁决引入 review package 文件、task-brief report 文件、进度 ledger 与 omnibus 最终修复者。其“最终冻结配置”即 Strict-Cost 规格的基线go-fractals 54.1-54.7 分钟 / 14.4-16.6M / $12.81-14.31对基线 64.9 / 21.2M / $16.07。该文档的 Cost iterations 章节同时记录了负结果controller 轮次批处理与并行调用管道化均被拒46% 思考/叙述轮次是提示词免疫下限。Strict-Cost 规格明确要求新增任何阶梯前先查阅负结果章节——“turn-discipline 与 parallel-call 机制已死”。2026-06-10 实验战役五个并行实验变体 真实本地会话转录挖掘产出上述负结果清单规格引用的实验日志如2026-06-10-sdd-cost-experiments.md、2026-06-11-build-loop-autoresearch.md位于 evals 实验仓库未包含在本仓库快照中此处仅按名引用。正向指令设计论docs/superpowers/specs/2026-06-10-positive-instruction-redesign-design.md新散文的措辞遵循“配方优于禁令”微测试正向配方 3.0 个逐字转录值 vs 禁令 4.4 vs 对照组 3.6——禁令可能适得其反并在全量运行前先做微测试。PR 切分原则L1 是 writing-plans 的改动 → 独立 PR 携带 eval 证据L2-L4 是 SDD 的改动 → 另开 PR。方法学小结这份设计能带走的工程经验先算账再优化$13/run 的四行成本表把“优化哪里”变成了排序问题controller 费率 派单数 评审循环 上下文节食而不是凭直觉。判断是稀缺资源美元不是六个判断点被显式枚举任何档位下放都要过“机械性证明 判断审计”“廉价模型通常蒙对”不构成证据因为判断失败低频、高爆炸半径、对 pass/fail 门不可见。预注册门让失败变成证据L2/L3 都“死于门内”但分别留下了“显式升级成立、隐式裁决被吸收”的解剖与“廉价评审者以辩护方式失败”的记录——“怀疑”变成了“记录在案的证据”。论文护栏防止降本动作腐蚀架构反论文手段任务打包即使省钱也被排除替代路线计划期调尺被保留在阶梯上。诚实的目标区间终态给出 $5-7全活与 $8-10判断级死亡诚实目标两档护栏在构造上把判断定价高于美元。对照当前仓库可以进一步观察演化的轨迹writing-plans 已吸收 L1 的约束头、Interfaces 与调尺指引task-reviewer-prompt 已带 plan-mandated 绊线L2b 在 opus 栈的候选规则SDD 的 SKILL 则携带本轮战役全部固化的 Model Selection 经验——一份“Proposed experiment ladder”状态的设计文档实际上已经在仓库的技能文件中留下了大部分脚印。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考