当智能体依据规格工作时，会发生哪些变化

Agent Smith 每天就是这样构建的，跨越一千多个规格。

已验证

在构建之前，一位新的审查者会对照代码检查规格。在提交之前，一道关卡会运行你的检查。

并行

每个规格一个分支和一个工作树。ID 来自时钟，因此两个智能体永远不会取到同一个。

不中断

经过审查的规格已经回答了未决问题，因此智能体按照其完成标准构建，而不是回来询问。

结构化

一个规格、一个分支、一个提交。一个拉取请求承载一个规格或一整个系列，每个变更都具有相同的形态。

可恢复

状态保存在context.yaml中。重启机器或智能体，工作会从停止的地方继续。

已解释，作为副作用

每个选择都会记录它击败了什么以及为什么，因此推理过程与代码保持在一起。

一整个系列，并排进行

把更大的变更切分成一系列规格。/spec-first:deliver-series审查所有规格，同时构建不共享任何文件的分组，验证合并后的树并打开一个拉取请求。

deliver-series 2026-10-27-8a3f5 个规格 · 3 个分组构建中

atickets-provider-contract不依赖任何内容1

btickets-github-provider依赖 a1

ctickets-jira-provider依赖 a1

dsettings-provider-page不依赖任何内容2

eci-restore-cache不依赖任何内容3

3 个工作树并行构建 · 每个规格提交都通过关卡

PR #42

一次示例运行：/spec-first:deliver-series。不共享任何文件的规格会同时构建；相互依赖的规格共享一个分组。

一个规格，从想法到拉取请求

四个技能将一项工作通过它自己的分支和工作树推进。每个技能都会留下一个文件，供下一步以及之后阅读历史的人使用。

create-spec

目标、步骤、带文件和行号的事实、完成的含义。还没有代码。

specs/planned/{id}.yaml

review-spec

每个引用都被解析，然后一位从未看过对话的审查者会攻击它。

BUILD · CUTS · REFUSE

apply-spec

契约、代码、接线、测试，遵循项目自身的规则。

decisions/{id}.yaml

deliver-spec

一个提交通过关卡，推送，打开拉取请求。

feat: … ({id})

记录随每个规格增长，在每一步之前被读取

specs/

每个规格，从计划到完成，连同其事实和完成标准。

decisions/

每个规格选择了什么、放弃了什么，以及为什么。

memory/

你只需告诉智能体一次，就不必再说第二次。

/spec-first:bootstrap-project从你的代码中一次性写入上下文：技术栈、规则以及一次提交必须通过的检查。之后，每个规格只需添加一行状态。

规格在任何人开始构建之前先经过评审

一次 REFUSE 只会让你损失一个规格。如果没有评审，同样的错误会让你损失整个分支。

规格2026-10-27-8a3f

适用于server

分支spec/8a3f

目标

工单提供方，让流水线可以从 GitHub 和 Jira 拉取工作项。

事实，在代码中读取

目前流水线只能从 CLI 获取工作项Program.cs:40-58

配置中已经包含 tracker 段AppConfig.cs:12-19

决策

适配器优于仓储：以读取为主的数据，不需要工作单元。

完成条件

  • GitHub 提供方端到端返回工单
  • Jira 提供方位于同一接口之后
  • verify：各阶段通过

已评审 · 构建全新评审者 · 10 月 27 日

review-spec · 2026-10-27-8a3f2 处删减

✓ src/Host/Program.cs:40-58 可解析

✓ src/Config/AppConfig.cs:12-19 可解析

证据可解析：1 个规格

带删减构建改动两个步骤后规格依然成立

删减 1

步骤jira需要第二种认证模式，而配置目前还无法承载。AppConfig.cs:15将其移到单独的规格中。

删减 2

缺少分页：GitHub 每页返回 30 个 issue。GitHubClient.cs:88添加一条完成条件。

每条引用都会被检查

脚本会打开规格引用的每个文件和行。任何未在代码中核实过的断言都必须列为假设。

评审者从零开始

一个没有对话历史的新智能体按代码的实际状态阅读代码，而不是按规格所描述的状态。

一个结论，并指明删减项

BUILD、BUILD WITH CUTS 或 REFUSE，且每条发现都指明文件和行。

推理过程顺带产生

之后无需任何人再写文档。在构建过程中，智能体记录每个并非显而易见的选择：它选了什么、放弃了什么，以及为什么。每个规格一个文件，放在代码旁边。

decisions/2026-10-27-8a3f.yaml

spec: 2026-10-27-8a3f
decisions:
  - category: TradeOff
    chose: "使用原生 HttpClient 调用 GitHub API"
    over: "Octokit"
    reason: "为了四次调用引入三兆字节的依赖。"
  - category: Architecture
    chose: "每个 tracker 一个 ITicketProvider"
    over: "一个通用的 REST 映射器"
    reason: "每个 tracker 的分页和认证方式都不同；映射器会把这些差异泄漏出去。"

无需维护 wiki

cat decisions/*.yaml项目的推理是否逐条规格地与其所解释的代码处于同一历史中。

记录 git 无法告知的信息

操作者希望事情如何完成，这是仓库之外的约束，指向别处的指针。每个文件一条事实，索引中一行。

三十秒后回来

重启机器，重启智能体，打开context.yaml。它知道什么已完成、什么正在进行、接下来是什么。

任何东西都不能越过红色阶段落地

当提交指明其规格时，插件的提交门会运行你的上下文所声明的每个验证阶段。全部通过，它就提交。第一个红色阶段会阻止它，其输出会返回给智能体。

该提交

git commit -m "feat: ticket
  providers (2026-10-27-8a3f)"

括号中的 id 会触发它。-F <file>，-C和--amend --no-edit也受门控。

验证：阶段

✓构建dotnet build

✓测试dotnet test

✕webcd web && npm test

通过

已提交

每个阶段都通过

被阻止

未提交

第一个红色阶段会阻止它，其输出会返回给智能体

# spec-first-gate.log · 每次规格提交一行

2026-10-27T09:14:02Z被阻止2026-10-27-8a3f /work/repo a1b2c3d web

2026-10-27T09:31:47Z通过2026-10-27-8a3f /work/repo a1b2c3d build,tests,web

在账本中没有对应行的规格提交从未经过门。拥有自己门的项目会说gate: project，插件便让开。

以此方式构建

Agent Smith

开源的智能体软件工厂：一张工单进去，一个经过验证的拉取请求出来。Agent Smith 完全用这种方法构建，而这种方法也是从构建它的过程中生长出来的。插件中的一切都在那里先运行过。

Agent Smith 为你运行这个循环 →

1,300+已完成规格

1,190+决策文件：选择了什么、替代了什么、为什么

650+通过门的规格

统计于 Agent Smith 仓库，2026 年 10 月。

安装

在 Claude Code 中，插件负责记账并运行门。其他智能体通过以下方式遵循相同的文件AGENTS.md，并且一个 git 钩子运行相同的门。

/plugin marketplace add holgerleichsenring/specification-first-agentic-development

/plugin install spec-first@specification-first-agentic-development

然后运行/spec-first:bootstrap-project。它会读取你的代码，并根据其发现写入上下文和规则。

create-spec在其自己的分支和工作树上编写规格
review-spec证据检查，然后由新的审查者给出结论
apply-spec将规格构建到其完成标准
deliver-spec通过门提交并打开拉取请求
deliver-series将整个规格系列带入一个拉取请求
log-decision · update-project · bootstrap-project决策、升级、设置

关于规范优先的智能体开发的问题

规范驱动的智能体开发，简短回答。

什么是规范优先的智能体开发？

一种与 AI 编码智能体协作的工作方式：每一项变更都从仓库中的书面规范开始。在动手构建之前，由一位全新的审查者对照你的代码检查规范，智能体在自己的分支和 worktree 上构建，只有你的检查通过后提交才会落地。

这里的规范驱动的智能体开发是什么意思？

规范从头到尾驱动工作。它指明目标、所依据的事实（含文件和行号）、步骤和完成标准，智能体严格按此构建。规范优先的智能体开发就是规范驱动的智能体开发，只不过规范在写下第一行代码之前就要对照代码进行审查。

我需要 Claude Code 吗？

不需要。Claude Code 插件把各步骤作为命令运行。Codex、Cursor、Copilot 或终端通过 AGENTS.md 遵循同样的文件，而 git commit-msg 钩子会在每个安装了它的克隆中运行同样的提交门禁。

它和 vibe coding 有什么不同？

你仍然用自己的话描述功能并把它讲清楚。之后，智能体依据经过审查的规范工作，而不是依据最后一条提示词，记录每个决策及其原因，只有你的构建和测试通过后提交才会落地。

规范包含什么？

一句话目标、所依据的事实（含文件和行号）、步骤、升级对运维人员的成本，以及完成标准。构建过程中做出的决策会写入旁边的单独 YAML 文件。

它要花多少钱？

免费。方法、模板和 Claude Code 插件均采用 MIT 许可证。

它从何而来