# Spec-Driven Development is the New Default for AI Coding
**作者**: AlphaSignal AI
**日期**: 2026-04-27T17:00:28.000Z
**来源**: [https://x.com/AlphaSignalAI/status/2057523186766377470](https://x.com/AlphaSignalAI/status/2057523186766377470)
---
## Top 5 repos defining it, the academic case for why, and who says it's wrong.
> In ~8 mins: what SDD is, why it became the default for AI coding, how the 5 leading repos implement it, and the one saying the whole category is wrong.
Spec-driven development crossed from blog-post topic to default architecture for AI coding in the last 12 months.
Thoughtworks, Martin Fowler, GitHub, Amazon, and a 67-source academic review all agreed in 2025 and 2026.
The question stopped being whether to use SDD and became which implementation.
## What happened
Multiple independent sources converged on the same recommendation inside 18 months.
Thoughtworks listed spec-driven development in Technology Radar Vol. 32 as a technique worth adopting. Martin Fowler covered it on his site.
GitHub shipped Spec Kit, an MIT-licensed toolkit framed as the answer to vibe coding. Amazon launched Kiro, an agentic tool that walks users through requirements, design, and tasks before any code generation. Tessl launched at the radical end, with specs positioned as the new source code.
Red Hat published enterprise SDD guidance. InfoQ covered it at the architecture level.
Bryan Finster pushed back with the right critique. SDD is not a revolution, it's just BDD with branding.
That critique strengthens the case. The idea is not new. The context is.
BDD was an optional discipline that teams could adopt or ignore. With 84% of professional developers using or planning to use AI tools (Stack Overflow, 2025) and 46% of code output now AI-generated (GitHub, 2025), specification discipline became structurally necessary.
## Why it became necessary
Four academic papers landed in 12 months, mapping the same problem from different angles.
Sabry Farrag at the University of East London ran a 67-source systematic review of the productivity paradox. AI coding tools deliver real individual-level gains and real system-level damage at the same time.
Peng et al. measured 55.8% faster completion in a 95-developer RCT. Becker et al.'s METR study found a 19% slowdown for experienced developers working on mature codebases.
DORA reported that 25% AI adoption correlates with a 7.2% drop in delivery stability. Faros AI tracked over 10,000 developers and saw 98% more merged PRs, 91% more review time, and 9% more bugs.
Shuvendu Lahiri at Microsoft Research named the underlying gap. AI-generated code is plausible by construction, not correct by construction. The semantic distance between what a user means and what a program does is the central reliability bottleneck.
An AIware 2026 vision paper named a second gap. Code review evaluates plausibility, not compliance. Most AI-generated changes pass tests, look reasonable, and still drift from the rules they were supposed to follow.
Deepak Babu Piskala wrote the practitioner manual that ties it together. He frames SDD across three rigor levels and a four-phase workflow.
Farrag's economic argument closes the loop. Code generated for a specific codebase has high asset specificity. LLMs introduce high behavioral uncertainty.
Developers invoke AI hundreds of times daily. In Transaction Cost Economics terms, that combination makes a written, executable contract the rational governance response. SDD is that contract.
## How it actually works
SDD compresses to three things a practitioner needs to hold.
A four-phase workflow. Specify what the software should do. Plan how to build it. Implement in small, validated increments. Validate that the code meets the spec. Each phase produces an artifact that constrains the next.
Three rigor levels. Spec-first means a specification is written before coding but may drift after. Spec-anchored means the spec lives alongside the code and tests enforce alignment. Spec-as-source means the spec is the only artifact humans edit, with code regenerated rather than manually changed.
A governance spectrum. Farrag's paper ranks four mechanisms by constraint intensity:
- Post-hoc review is the loosest, where a developer reviews AI output after the fact.
- Natural-language specification is next, putting requirements before generation.
- Executable contract follows, with tests and structured spec documents the agent must satisfy.
- Constitutional governance is the tightest, a meta-specification of non-negotiable principles that every change must honor.
The higher the asset specificity, behavioral uncertainty, and frequency, the further up the spectrum the rational choice sits. Production code in a mature codebase invoked by AI hundreds of times daily lands at constitutional. A throwaway prototype lands at post-hoc.
## The five SDD repos, by philosophy
Each repo encodes a different theory of where complexity belongs.
> Full comparison table at the end. Links are in replies.
## Spec Kit: constitution as authority
GitHub's official toolkit, MIT-licensed, Python CLI (specify init).
The theory of complexity: put it in the constitution. A non-negotiable principles file at .specify/memory/constitution.md sits above every spec and every implementation. The agent obeys it on every change, every session.
The workflow runs through nine slash commands:
- /speckit.constitution
- /speckit.specify
- /speckit.clarify
- /speckit.plan
- /speckit.tasks
- /speckit.taskstoissues
- /speckit.checklist
- /speckit.analyze
- /speckit.implement
The constitution and analyze steps are where the formal governance lives.
Farrag's paper evaluates Spec Kit as the direct instantiation of constitutional governance. The reported result: 12 hours to 15 minutes for upstream artifact production (PRD, design, structure, technical specs, test plans).
A pilot study saw late-stage hotfixes drop from 3-to-5 per sprint to 1-to-2, and rollbacks drop from 2-to-4 per month to 0-to-1.
30+ AI agent integrations including Claude, Codex, Copilot, Cursor, Gemini.
This is the only repo with explicit constitutional governance. The highest tier on Farrag's spectrum, and the steepest setup cost.
## BMAD-METHOD: named agents as authority
BMad Code LLC, MIT, npm (npx bmad-method install). V6, with 34+ workflows.
The theory of complexity: put it in the roles. Six named personas, each with domain expertise:
- Analyst Mary handles brainstorming and research.
- PM John owns PRDs.
- Architect Winston runs the 8-step architecture workflow.
- Developer Amelia handles dev stories, sprint planning, and code review.
- UX Designer Sally owns interface decisions.
- Tech Writer Paige owns documentation.
Party Mode brings multiple personas into one session to argue from different professional perspectives.
The lifecycle has four phases: Analysis, Planning, Solutioning, Implementation. Each phase has its own workflows.
A .decision-log.md records every decision as an audit trail. An implementation-readiness gate (PASS, CONCERNS, or FAIL) blocks the move to code if anything is missing.
Planning depth auto-adjusts to project stakes. A hobby project gets a 2-page PRD. A launch project gets full specs. The bmad-help skill answers free-form questions about what to do next.
The module ecosystem extends the core with specialized domains: BMM (core), BMB (custom agents), TEA (test architecture), BMGD (game dev), CIS (creative intelligence).
This is the only repo that treats specifications as the inter-agent communication protocol of a multi-agent organization.
## OpenSpec: change folders as the unit
Fission AI, MIT, npm (openspec init).
The theory of complexity: put it in the change. Each feature gets its own folder containing proposal.md (why this change), specs/ (requirements and scenarios), design.md (technical approach), and tasks.md (implementation checklist).
When the change ships, /opsx:archive folds the change spec into a growing source-of-truth document.
The core surface is three commands:
- /opsx:propose creates the change folder.
- /opsx:apply has the AI implement the task checklist.
- /opsx:archive closes it out.
An opt-in expanded profile adds six more: /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard.
The positioning is explicitly brownfield-first. Most SDD tools optimize for greenfield projects. OpenSpec is built to retrofit existing codebases. The delta-spec format (additions, modifications, removals tracked per change) is what makes that work.
Works with 25+ AI assistants via slash commands.
Executable contract at the lightest possible weight. No constitution, no named agents, no ceremony. The spec discipline survives without the process.
## GSD: context as the bottleneck
TÂCHES, MIT, npm (npx get-shit-done-cc@latest). Built by a solo developer for solo developers.
The theory of complexity: put it in context engineering. The main session context stays at 30 to 40 percent. Heavy work runs in fresh subagent contexts, each getting a full 200K-token window.
The hypothesis the rest of the architecture rests on: as a session grows, AI output degrades, so the architecture should keep the session small.
The loop is six commands:
- /gsd-new-project runs questions, research, requirements, roadmap.
- /gsd-map-codebase does the same for existing code.
- /gsd-discuss-phase captures decisions before planning.
- /gsd-plan-phase runs research, plan, verify in a loop.
- /gsd-execute-phase dispatches parallel waves of subagents.
- /gsd-verify-work walks through what was built and diagnoses failures.
Five persistent state files survive session boundaries: PROJECT.md (vision), REQUIREMENTS.md (scope), ROADMAP.md (direction), STATE.md (current position), CONTEXT.md (per-phase decisions).
The .planning/config.json controls mode (interactive or yolo), model profiles (quality, balanced, budget), and quality-agent toggles. Package legitimacy checks are built into the install path.
Executable contract delivered through context discipline rather than process ceremony. The repo treats the context window as the bottleneck, not the methodology.
## Superpowers: auto-triggering as discipline
Built by Jesse Vincent and Prime Radiant. MIT, zero-dependency plugin.
The theory of complexity: put it in the agent's behavior shaping. Skills auto-trigger at the right moments. No manual invocation. Mandatory workflows, not suggestions.
The using-superpowers skill loads at session start and is what makes auto-triggering work. Copying skill files alone is not a real integration.
Seven core skills run the workflow:
- brainstorming refines rough ideas before any code.
- using-git-worktrees isolates the workspace.
- writing-plans breaks work into 2 to 5 minute tasks with exact file paths and complete code.
- subagent-driven-development dispatches a fresh subagent per task with two-stage review (spec compliance, then code quality).
- test-driven-development deletes any code written before its test.
- requesting-code-review blocks critical issues.
- finishing-a-development-branch verifies tests and presents merge options.
The TDD enforcement is the unusual move. Most TDD tooling encourages the loop. Superpowers' skill deletes code that violates it.
Distributed through the official Claude plugin marketplace, the official Codex plugin marketplace, Factory Droid, Gemini extensions, Cursor, GitHub Copilot CLI, and OpenCode.
Executable contract enforced at the agent layer rather than the user layer. The user never has to remember to invoke the right skill.
## The sixth repo, and the case against the category
Matt Pocock's Skills For Real Engineers sits on the same list of repos by accident. He argues against the category.
His talk Software Fundamentals Matter More Than Ever lands the thesis directly. "Code is not cheap. In fact, bad code is the most expensive it's ever been."
On the spec-driven movement specifically: "Specs to code, we are not investing in the design of the system. We are divesting from it."
His position rests on a software-engineering claim. Bad codebases have always been expensive because they resist change. AI accelerates that. A bad codebase compounded by AI throughput is the most expensive failure mode of the new era.
His repo is composable practices, not a workflow framework. Each skill stands alone:
- /grill-me runs a relentless interview to establish what Frederick Brooks calls a shared design concept.
- /grill-with-docs adds a Domain-Driven Design ubiquitous language file that humans and AI both reference.
- /tdd enforces red-green-refactor as the rate limiter on AI speed.
- /improve-codebase-architecture rebuilds shallow modules into deep modules, per John Ousterhout.
The default pattern is gray boxes: design the interface, delegate the implementation.
The data on his side: the METR finding that experienced developers on mature codebases were 19% slower with AI suggests the bottleneck is codebase quality, not specification quality. His argument is that the five SDD repos optimize for the wrong thing.
> **AlphaSignal AI@AlphaSignalAI**: [原文链接](https://x.com/AlphaSignalAI/status/2048809516993556845)
>
His repo went viral on the strength of /grill-me alone. The position is worth taking seriously.
## The AlphaSignal take
The five SDD repos and Pocock's dissent are not answering the same question.
SDD optimizes for the plausibility-to-correctness gap. Pocock optimizes for the design-entropy gap. Both gaps are real. Both data sets support both positions.
A team that picks one and ignores the other is solving half the problem.
The reliability case for SDD is strongest at the constitutional and executable-contract levels. Spec Kit's constitution mechanism and BMAD's implementation-readiness gate are where the math actually pays off.
The case is weakest at the natural-language end, where SDD collapses into renamed prompt engineering.
Three things none of the six repos solve, drawn from the open problems sections of the four papers.
Oracle adequacy. Current evaluations collapse model quality, tool reliability, and harness quality into one end-task number. There is no metric for what a specification is actually worth.
Evidence bundles. Every accepted change should ship with a record of what was checked, what was not, and what risks remain. No current SDD tool produces this.
Self-evolving harnesses. The SDD frameworks themselves are software. They will change. None of them have a change-contract for their own evolution.
Read each of these repos as a specific theory of where reliability comes from. Pick the one whose theory matches the bottleneck you actually have. If you don't know your bottleneck, Pocock's critique applies first.
Which theory of reliability does your stack depend on, constitution, roles, change folders, context, auto-triggering, or design discipline?
All source links are in the first reply.
Full breakdown of recent updates + daily signals in our newsletter (link in bio).
## 相关链接
- [AlphaSignal AI](https://x.com/AlphaSignalAI)
- [@AlphaSignalAI](https://x.com/AlphaSignalAI)
- [8.9K](https://x.com/AlphaSignalAI/status/2057523186766377470/analytics)
- [Apr 28](https://x.com/AlphaSignalAI/status/2048809516993556845)
- [17K](https://x.com/AlphaSignalAI/status/2048809516993556845/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:05 AM · May 22, 2026](https://x.com/AlphaSignalAI/status/2057523186766377470)
- [8,914 Views](https://x.com/AlphaSignalAI/status/2057523186766377470/analytics)
- [View quotes](https://x.com/AlphaSignalAI/status/2057523186766377470/quotes)
---
*导出时间: 2026/5/22 16:05:23*
---
## 中文翻译
# 规范驱动开发成为 AI 编程的新默认范式
**作者**： AlphaSignal AI
**日期**： 2026-04-27T17:00:28.000Z
**来源**： [https://x.com/AlphaSignalAI/status/2057523186766377470](https://x.com/AlphaSignalAI/status/2057523186766377470)
---
## 定义这一范式的 5 个顶级仓库、其学术依据，以及反对者的声音。
> 大约 8 分钟阅读：什么是 SDD、它为何成为 AI 编程的默认范式、5 个领先仓库如何实现它，以及那个认为整个类别都错了的声音。
在过去的 12 个月里，规范驱动开发（Spec-driven development）从博客文章话题跃升为 AI 编程的默认架构。
Thoughtworks、Martin Fowler、GitHub、Amazon 以及一篇涵盖 67 个来源的学术综述，都在 2025 和 2026 年达成了共识。
问题不再是“是否使用 SDD”，而变成了“选择哪种实现”。
## 发生了什么
在 18 个月内，多个独立来源汇聚到了同一个建议上。
Thoughtworks 在《技术雷达》第 32 卷中将规范驱动开发列为值得采纳的技术。Martin Fowler 在他的网站上对此进行了介绍。
GitHub 发布了 Spec Kit，一个 MIT 许可的工具包，被定位为对“氛围编程”（vibe coding）的回应。Amazon 推出了 Kiro，一个智能体工具，会在生成任何代码之前引导用户完成需求、设计和任务。Tessl 的发布则更为激进，将规范定位为新的源代码。
Red Hat 发布了企业级 SDD 指南。InfoQ 从架构层面进行了报道。
Bryan Finster 提出了正确的批评。SDD 不是一场革命，它只是换了包装的 BDD。
这一批评反而强化了论点。这个想法并不新，新的是它所处的环境。
BDD 曾经是一种可选的实践，团队可以采纳也可以忽略。而当 84% 的专业开发者正在使用或计划使用 AI 工具（Stack Overflow，2025），且 46% 的代码产出已由 AI 生成（GitHub，2025）时，规范纪律就成为了结构上的必需。
## 为什么它变得必要
四篇学术论文在 12 个月内相继发表，从不同角度描绘了同一个问题。
东伦敦大学的 Sabry Farrag 对生产力悖论进行了一项涵盖 67 个来源的系统性综述。AI 编程工具在个体层面带来真实收益的同时，也在系统层面造成真实的损害。
Peng 等人在一项 95 名开发者的随机对照试验中测得完成速度提升 55.8%。Becker 等人的 METR 研究发现，经验丰富的开发者在成熟代码库上工作速度反而下降了 19%。
DORA 报告指出，25% 的 AI 采用率与 7.2% 的交付稳定性下降相关。Faros AI 追踪了超过 10,000 名开发者，发现合并的 PR 增加了 98%，评审时间增加了 91%，缺陷增加了 9%。
微软研究院的 Shuvendu Lahiri 指出了背后的根本差距。AI 生成的代码是“构造上看似合理”，而非“构造上正确”。用户意图与程序行为之间的语义距离，是可靠性的核心瓶颈。
一篇 AIware 2026 愿景论文指出了第二个差距。代码评审评估的是“看似合理”，而非“符合规范”。大多数 AI 生成的变更通过了测试、看起来合理，却依然偏离了本应遵循的规则。
Deepak Babu Piskala 写出了将其串联起来的从业者手册。他从三个严格程度和一个四阶段工作流来界定 SDD。
Farrag 的经济学论证完成了闭环。为特定代码库生成的代码具有高资产专用性。而 LLM 引入了高行为不确定性。
开发者每天调用 AI 数百次。用交易成本经济学的术语来说，这种组合使得一份书面的、可执行的契约成为理性的治理响应。SDD 就是这份契约。
## 它实际上是如何运作的
SDD 可以压缩为从业者需要掌握的三件事。
一个四阶段工作流。明确软件应该做什么（Specify）。规划如何构建它（Plan）。以小的、经过验证的增量进行实现（Implement）。验证代码符合规范（Validate）。每个阶段产出一个约束下一阶段的产物。
三个严格程度。Spec-first（规范优先）指在编码之前编写规范，但之后可能产生漂移。Spec-anchored（规范锚定）指规范与代码共存，由测试强制保持一致。Spec-as-source（规范即源码）指规范是人类唯一编辑的产物，代码通过再生成而非手动修改来更新。
一个治理谱系。Farrag 的论文按约束强度对四种机制进行排序：
- 事后评审最宽松，即开发者在事后评审 AI 的输出。
- 自然语言规范次之，将需求置于生成之前。
- 可执行契约紧随其后，用测试和结构化的规范文档约束智能体必须满足的要求。
- 宪法式治理最严格，它是一份关于不可妥协原则的元规范，每一项变更都必须遵守。
资产专用性、行为不确定性和频率越高，理性选择在谱系上的位置就越高。成熟代码库中被 AI 每天调用数百次的生产代码，落在宪法式治理一端。一次性的原型则落在事后评审一端。
## 五个 SDD 仓库，按理念划分
每个仓库都编码了一种关于“复杂性应该放在哪里”的不同理论。
> 完整对比表见文末。链接在回复中。
## Spec Kit：宪法即权威
GitHub 的官方工具包，MIT 许可，Python CLI（specify init）。
其复杂性理论：把复杂性放进宪法。一个位于 .specify/memory/constitution.md 的不可妥协原则文件，凌驾于每份规范和每个实现之上。智能体在每次变更、每个会话中都必须遵守它。
工作流通过九个斜杠命令运行：
- /speckit.constitution
- /speckit.specify
- /speckit.clarify
- /speckit.plan
- /speckit.tasks
- /speckit.taskstoissues
- /speckit.checklist
- /speckit.analyze
- /speckit.implement
宪法（constitution）和分析（analyze）步骤是正式治理的核心所在。
Farrag 的论文将 Spec Kit 评估为宪法式治理的直接实例化。报告的结果是：上游产物（PRD、设计、结构、技术规格、测试计划）的生产时间从 12 小时缩短到 15 分钟。
一项试点研究显示，后期热修复从每个冲刺 3 到 5 次下降到 1 到 2 次，回滚从每月 2 到 4 次下降到 0 到 1 次。
支持 30 多个 AI 代理集成，包括 Claude、Codex、Copilot、Cursor、Gemini。
这是唯一具有显式宪法式治理的仓库。这是 Farrag 光谱中的最高层级，也是设置成本最高的。
## BMAD-METHOD：以命名代理作为权威
BMad Code LLC，MIT 协议，npm（npx bmad-method install）。V6 版本，包含 34+ 个工作流。
其复杂性理论：把复杂性放进角色里。六个命名角色，各自拥有领域专长：
- 分析师 Mary 负责头脑风暴和研究。
- 产品经理 John 负责 PRD。
- 架构师 Winston 运行 8 步架构工作流。
- 开发者 Amelia 负责开发故事、冲刺规划和代码审查。
- UX 设计师 Sally 负责界面决策。
- 技术作家 Paige 负责文档。
Party Mode 将多个角色聚集到同一个会话中，从不同专业视角展开辩论。
生命周期分为四个阶段：分析、规划、方案设计、实施。每个阶段都有自己的工作流。
.decision-log.md 将每个决策记录为审计轨迹。一个实施就绪度门控（PASS、CONCERNS 或 FAIL）会在有缺失内容时阻止进入编码阶段。
规划深度会根据项目的重要程度自动调整。业余项目得到一份 2 页的 PRD。上线项目则获得完整的规格说明。bmad-help 技能可以自由回答关于下一步该做什么的问题。
模块生态系统通过专门的领域扩展核心：BMM（核心）、BMB（自定义代理）、TEA（测试架构）、BMGD（游戏开发）、CIS（创意智能）。
这是唯一一个将规格说明视为多代理组织内部代理间通信协议的仓库。
## OpenSpec：以变更文件夹为单元
Fission AI，MIT 协议，npm（openspec init）。
其复杂性理论：把复杂性放进变更里。每个功能都有自己的文件夹，包含 proposal.md（为什么做这个变更）、specs/（需求和场景）、design.md（技术方案）以及 tasks.md（实施清单）。
当变更发布时，/opsx:archive 会将变更规格合并到一份不断增长的唯一事实来源文档中。
核心界面只有三个命令：
- /opsx:propose 创建变更文件夹。
- /opsx:apply 让 AI 实施任务清单。
- /opsx:archive 归档结束。
可选的扩展配置额外增加六个命令：/opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive、/opsx:onboard。
其定位明确是棕地优先。大多数 SDD 工具针对绿地项目优化。OpenSpec 则是为改造现有代码库而构建的。增量规格格式（按变更追踪的新增、修改、移除）正是实现这一点的原因。
通过斜杠命令支持 25+ 个 AI 助手。
以尽可能轻量的方式交付可执行契约。没有宪法，没有命名代理，没有繁文缛节。规格纪律在没有流程负担的情况下得以延续。
## GSD：以上下文为瓶颈
TÂCHES，MIT 协议，npm（npx get-shit-done-cc@latest）。由一位独立开发者为独立开发者构建。
其复杂性理论：把复杂性放进上下文工程。主会话上下文保持在 30% 到 40%。繁重的工作在全新的子代理上下文中运行，每个都拥有完整的 200K token 窗口。
整个架构所依赖的假设是：随着会话增长，AI 输出质量会下降，因此架构应该让会话保持小巧。
循环由六个命令组成：
- /gsd-new-project 运行提问、研究、需求、路线图。
- /gsd-map-codebase 对现有代码执行同样的流程。
- /gsd-discuss-phase 在规划前捕获决策。
- /gsd-plan-phase 循环运行研究、规划、验证。
- /gsd-execute-phase 调度并行波次的子代理。
- /gsd-verify-work 逐一检查所构建的内容并诊断失败。
五个持久化状态文件跨越会话边界存续：PROJECT.md（愿景）、REQUIREMENTS.md（范围）、ROADMAP.md（方向）、STATE.md（当前进度）、CONTEXT.md（各阶段决策）。
.planning/config.json 控制模式（交互式或 yolo）、模型配置（质量、均衡、预算）以及质量代理开关。包合法性检查已内置于安装路径中。
通过上下文纪律而非流程仪式交付可执行契约。该仓库将上下文窗口视为瓶颈，而不是方法论。
## Superpowers：以自动触发为纪律
由 Jesse Vincent 和 Prime Radiant 构建。MIT 协议，零依赖插件。
其复杂性理论：把复杂性放进代理的行为塑造中。技能在恰当的时机自动触发。无需手动调用。强制工作流，而非建议。
using-superpowers 技能在会话开始时加载，正是它使自动触发生效。仅仅复制技能文件并不是真正的集成。
七个核心技能驱动工作流：
- brainstorming 在编写任何代码之前完善粗略想法。
- using-git-worktrees 隔离工作区。
- writing-plans 将工作拆分为 2 到 5 分钟的任务，包含精确的文件路径和完整代码。
- subagent-driven-development 为每个任务调度一个全新子代理，并进行两阶段审查（先看规格符合性，再看代码质量）。
- test-driven-development 删除任何在其测试之前编写的代码。
- requesting-code-review 阻止关键问题。
- finishing-a-development-branch 验证测试并提供合并选项。
TDD 强制执行是非常规之举。大多数 TDD 工具只是鼓励这个循环。Superpowers 的技能会删除违反该纪律的代码。
通过官方 Claude 插件市场、官方 Codex 插件市场、Factory Droid、Gemini 扩展、Cursor、GitHub Copilot CLI 和 OpenCode 分发。
在代理层而非用户层强制执行可执行契约。用户永远不必记住去调用正确的技能。
## 第六个仓库，以及针对这一类别的反对意见
Matt Pocock 的 Skills For Real Engineers 之所以出现在同一份仓库列表中，纯属偶然。他反对的是这个类别本身。
他的演讲《软件基础比以往任何时候都更重要》（Software Fundamentals Matter More Than Ever）直接给出了论点：“代码并不廉价。事实上，坏代码的代价达到了有史以来最昂贵的程度。”
针对规范驱动这一运动，他说：“从规范到代码，我们并没有在系统设计上投入，而是在撤离投入。”
他的立场建立在一个软件工程的论断之上。坏代码库一直都很昂贵，因为它们抗拒变化。AI 加速了这一点。一个被 AI 高吞吐量放大的坏代码库，是新时代最昂贵的失败模式。
他的仓库是一套可组合的实践，而非工作流框架。每个技能都可独立使用：
- /grill-me 运行一场毫不留情的访谈，以建立 Frederick Brooks 所说的“共享设计概念”。
- /grill-with-docs 添加一份领域驱动设计（DDD）的统一语言文件，供人和 AI 共同参照。
- /tdd 强制执行红-绿-重构循环，作为对 AI 速度的限流器。
- /improve-codebase-architecture 依照 John Ousterhout 的理念，把浅模块重建为深模块。
默认模式是灰盒：设计接口，将实现委托出去。
支持他的数据是：METR 的发现——经验丰富的开发者在成熟代码库上使用 AI 反而慢了 19%——表明瓶颈在于代码库质量，而非规范质量。他的论点是，这五个 SDD 仓库优化错了对象。
> **AlphaSignal AI@AlphaSignalAI**： [原文链接](https://x.com/AlphaSignalAI/status/2048809516993556845)
>
他的仓库仅凭 /grill-me 一项就走红网络。这个立场值得认真对待。
## AlphaSignal 的观点
五个 SDD 仓库与 Pocock 的异议，回答的并不是同一个问题。
SDD 优化的是“可信度到正确性”的差距。Pocock 优化的是“设计熵”的差距。两个差距都是真实存在的。两组数据都同时支持两种立场。
一个团队如果只选其一而无视另一方，那就是只解决了问题的一半。
SDD 的可靠性论证在宪法层和可执行契约层最为有力。Spec Kit 的宪法机制和 BMAD 的实现就绪门控，才是数学真正兑现回报的地方。
这个论证在自然语言一端最为薄弱——在那里，SDD 退化为改名换姓的提示词工程。
从四篇论文的开放问题部分提炼出六家仓库都未解决的三个问题。
Oracle 充分性。当前的评估把模型质量、工具可靠性和执行框架质量压缩成一个端到端任务数字。没有任何指标衡量一份规范的实际价值。
证据包。每一个被接受的变更都应附带一份记录：检查了什么、没检查什么、还剩哪些风险。目前没有任何 SDD 工具能产出这个。
自演化的执行框架。SDD 框架本身也是软件。它们会变化。它们之中没有任何一个为自己的演化制定了变更契约。
请把每一个仓库当作一种关于“可靠性从何而来”的具体理论来阅读。选择那个与你实际拥有的瓶颈相匹配的理论。如果你不清楚自己的瓶颈，Pocock 的批评应优先适用。
你的技术栈依赖的是哪种可靠性理论——宪法、角色、变更文件夹、上下文、自动触发，还是设计纪律？
所有源链接都在第一条回复中。
近期更新的完整解读 + 每日信号请见我们的通讯（链接在个人简介中）。
## 相关链接
- [AlphaSignal AI](https://x.com/AlphaSignalAI)
- [@AlphaSignalAI](https://x.com/AlphaSignalAI)
- [8.9K](https://x.com/AlphaSignalAI/status/2057523186766377470/analytics)
- [Apr 28](https://x.com/AlphaSignalAI/status/2048809516993556845)
- [17K](https://x.com/AlphaSignalAI/status/2048809516993556845/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:05 AM · May 22, 2026](https://x.com/AlphaSignalAI/status/2057523186766377470)
- [8,914 Views](https://x.com/AlphaSignalAI/status/2057523186766377470/analytics)
- [View quotes](https://x.com/AlphaSignalAI/status/2057523186766377470/quotes)
---
*导出时间: 2026/5/22 16:05:23*
