# 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 个月里，规格驱动开发已从博客文章的话题跨越成为 AI 编程的默认架构。
Thoughtworks、Martin Fowler、GitHub、亚马逊，以及一份涵盖了 67 个来源的学术评论，都在 2025 年和 2026 年达成了共识。
问题已不再是“是否使用 SDD”，而是“使用哪种实现”。
## 发生了什么
多个独立的来源在 18 个月内汇聚到了同一个建议上。
Thoughtworks 在其《技术雷达》第 32 期中将规格驱动开发列为一种值得采用的技术。Martin Fowler 在他的网站上介绍了它。
GitHub 发布了 Spec Kit，这是一个 MIT 许可的工具包，旨在作为“氛围式编程”的解决方案。亚马逊推出了 Kiro，这是一个代理工具，引导用户在生成任何代码之前完成需求、设计和任务定义。Tessl 则在激进的一端上线，将规格定位为新的源代码。
红帽发布了企业级 SDD 指南。InfoQ 在架构层面报道了它。
Bryan Finster 提出了恰当的反驳。SDD 不是一场革命，它只是披上了品牌外衣的 BDD（行为驱动开发）。
这种反驳反而加强了论据。这个理念并不新鲜，但背景是全新的。
BDD 是一种团队可以选择采用或忽略的自律规范。随着 84% 的专业开发者正在使用或计划使用 AI 工具，且 46% 的代码输出现在由 AI 生成，规格约束已变得在结构上必不可少。
## 为何变得必不可少
四篇学术论文在 12 个月内发表，从不同角度映射了同一个问题。
东伦敦大学的 Sabry Farrag 对生产率悖论进行了包含 67 个来源的系统综述。AI 编码工具在交付真实的个人层面收益的同时，也造成了真实的系统层面损害。
Peng 等人在一项涉及 95 名开发者的随机对照试验中测量到 55.8% 的速度提升。而 Becker 等人的 METR 研究发现，对于在成熟代码库上工作的经验丰富的开发者，速度反而降低了 19%。
DORA 报告称，25% 的 AI 采用率与交付稳定性下降 7.2% 相关。Faros AI 追踪了超过 10,000 名开发者，发现合并的 PR 增加了 98%，审查时间增加了 91%，而 Bug 增加了 9%。
微软研究院的 Shuvendu Lahiri 指出了底层的差距。AI 生成的代码在构造上是看似合理的，而不是在构造上正确的。用户意图与程序行为之间的语义距离是中心可靠性瓶颈。
一篇 AIware 2026 愿景论文指出了第二个差距。代码审查评估的是“看似合理性”，而非“合规性”。大多数 AI 生成的变更能通过测试，看起来也合理，但仍然偏离了本应遵守的规则。
Deepak Babu Piskala 编写了将这一切联系起来的从业者手册。他围绕三个严格度级别和一个四阶段工作流来构建 SDD。
Farrag 的经济学论证完成了闭环。为特定代码库生成的代码具有很高的资产专用性。LLM 带来了很高的行为不确定性。
开发者每天调用 AI 数百次。用交易成本经济学的术语来说，这种组合使得一份书面的、可执行的合同成为理性的治理响应。SDD 就是那份合同。
## 实际运作方式
SDD 浓缩为从业者需要掌握的三件事。
一个四阶段工作流。指定软件应该做什么。计划如何构建它。以小的、经过验证的增量进行实施。验证代码是否符合规格。每个阶段都会产生一个约束下一阶段的产物。
三个严格度级别。“规格优先”意味着在编码之前编写规格，但之后可能会出现偏差。“规格锚定”意味着规格与代码共存，测试强制执行一致性。“规格即源头”意味着规格是人类编辑的唯一产物，代码是重新生成的，而不是手动修改的。
一个治理谱系。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
宪法和分析步骤是正式治理存在的地方。
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 处理头脑风暴和研究。
- PM John 负责 PRD。
- 架构师 Winston 负责 8 步架构工作流。
- 开发者 Amelia 处理开发故事、冲刺规划和代码审查。
- UX 设计师 Sally 负责界面决策。
- 技术文档撰写人 Paige 负责文档。
“派对模式”将多个角色带入一个会话，从不同的专业角度进行辩论。
生命周期有四个阶段：分析、规划、解决方案设计、实施。每个阶段都有自己的工作流。
一个 .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 旨在改造现有代码库。Delta-spec 格式（按变更跟踪的添加、修改、删除）使其成为可能。
通过斜杠命令与 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 的《真正工程师的技能》偶然出现在同一仓库列表中。他反对这一类别。
他的演讲《软件基础比以往任何时候都更重要》直接阐明了论点。“代码并不廉价。事实上，糟糕的代码比以往任何时候都更昂贵。”
具体关于规格驱动运动：“从规格到代码，我们并没有在系统设计上进行投资。我们正在从中撤资。”
他的立场基于一个软件工程主张。糟糕的代码库之所以总是昂贵，是因为它们抵制变更。AI 加速了这一点。被 AI 吞吐量复合的糟糕代码库是新时代最昂贵的失败模式。
他的仓库是可组合的实践，而不是工作流框架。每个技能独立存在：
- /grill-me 进行无情的面试，以建立 Frederick Brooks 所谓的共享设计概念。
- /grill-with-docs 添加领域驱动设计（DDD）的 ubiquitous language 文件，人类和 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 沦为重命名的提示工程。
这六个仓库都没有解决的三件事，取自四篇论文的未解决问题部分。
预言机充分性。目前的评估将模型质量、工具可靠性和线束质量合并为一个最终任务数字。没有指标来衡量规格的实际价值。
证据捆绑。每个被接受的变更都应该附带一份记录，说明检查了什么、没有检查什么以及剩余哪些风险。目前的 SDD 工具都没有产生这个。
自我进化的线束。SDD 框架本身也是软件。它们会改变。它们中没有一个为自己的进化制定了变更合同。
请阅读这些仓库，将其视为关于可靠性来源的具体理论。选择其理论与您实际拥有的瓶颈相匹配的那个。如果您不知道您的瓶颈，请先应用 Pocock 的批评。
您的技术栈依赖于哪种可靠性理论？宪法、角色、变更文件夹、上下文、自动触发，还是设计纪律？
所有源链接都在第一条回复中。
我们通讯中有最近的更新的详细分解 + 每日信号（简介中有链接）。