PactKit

Anthropic 工程团队公开了他们的 AI 原生软件研发生命周期(AI-native SDLC) 实践:六个阶段,每个阶段产出一个提交进版本库的制品;一个阶段的提交就是下一阶段开工的信号。人留在闸门上,提交链本身就是审计轨迹。

PactKit 把这套模型工具化落地——不是 Claude 专属实践,而是可部署到 Claude Code、OpenCode、Codex CLI 三个 host 的同一套治理。

三条核心原则

这套实践建立在三条原则上,每一条都是 PactKit 的既有设计决策:

原则含义PactKit 实现
提交链就是审计轨迹谁要求了什么、agent 产出了什么、谁批准了——同一份历史Spec、Story、Board、snapshot、enforcement 记录全部是提交制品
人留在闸门上需要判断的决定由人负责;注意力从每一行代码移到每一份制品授权闸门(pactkit gate)要求 push、PR、release、publish 必须显式人工确认
结束即触发一个阶段被接受的制品,就是下一阶段的放行信号PDCA 链:/project-plan 的产出闸住 /project-act,Done 闸住 release

逐阶段映射

AI-Native SDLC 阶段公开实践PactKit 机制
计划 Planintent.md原始想法变成带作者和时间戳的提交制品/project-clarify 澄清歧义,/project-plan 写 Spec 和 Board——溯源信息在 git 历史里
设计 Designspec.md需求与设计合并在一次会话;组织策略在生成时就被应用Spec 生成时读取 rule 模块(品牌/安全/UX 约束作为版本化规则);spec_guard 在 Act 期间保护 Spec 即法律
构建 Buildplan.md没有被接受的计划就不写代码;护栏是代码不是 promptSpec lint + 一致性检查闸住 /project-act;enforcement hooks 强制执行 prompt 只能陈述的规则
测试 Testdiff + tests会话自检;steering 配置本身被回归测试TDD 循环(RED -> GREEN)+ 回归门禁;commit-gate 拦截 RED 测试套件,skip 不等于 pass
部署 DeployPR + findings多道评审(bug/安全/合规);hooks 作为 allow/ask/block 闸门auth_gate 授权对、保护分支的 push_gate、执法制品的 tamper_guard——全部留审计
运维 Maintain事故写回下一轮循环门禁遥测 + 摩擦统计(pactkit stats)决定下一个调优点

超出公开实践的部分

该实践描述的是单 host(Claude Code)工作流。PactKit 走得更远:

  • 同一套治理,三个 host —— Claude Code、OpenCode、Codex CLI 跑同样的 PDCA 生命周期、同样的闸门、同样的审计轨迹。团队用多个 coding assistant 时治理不会碎片化。
  • 中断围栏 —— 会话在 attempt 和 outcome 之间死掉时,会留下机器可观测的 outcome_unknown 围栏。围栏关闭前 resume 被阻断;被中断的验证永远无法伪装成通过。
  • 审计化的授权对 —— 每个闸门决定(询问、授予、绕过)都以成对记录落进 .pactkit/enforcement/。不只是日志——一条能在冲突指令下存活的审计链。
  • 防篡改 —— 修改执法制品(hooks、gate 注册、审计记录)本身就是被闸门拦截、被审计的操作。

有意的差异

两处 PactKit 有意不同的地方:

  1. Spec 合并了 spec + plan。 公开生命周期把 spec.md(需求+设计)和 plan.md(实现计划)分成两个制品。PactKit 的 Spec 同时承载两者——需求和测试证据在同一个文件里,这正是 Done 阶段诚实门禁(pactkit done-verify)成立的前提:按 Story 逐条校验需求到测试证据的链路。
  2. PDCA 切片。 六阶段和 Plan-Act-Check-Done 是同构的——同一个环的两种切法。PactKit 保持 PDCA,因为它的阶段与可部署的命令、受约束工具的 agent 一一对应。

总结

如果你在采用 AI 原生 SDLC,想要的是"被强制执行"而不是"靠自觉记住"——而且不管团队实际用哪个 coding assistant——PactKit 就是那层执行器。

目录