工程宪章模板

用这份模板定义所有规格、设计、任务计划和 AI 编码请求都要遵守的规则。它是一层很轻的团队工作协议。

constitution.md

# Engineering Constitution

Owner:
Applies to:
Last reviewed:

## Principles
- 高风险实现前必须先有规格。
- 验收标准必须可观察。
- 高风险变更合并前必须有证据。
- AI 生成代码必须留在批准范围内。

## Required Gates
- Spec review:
- Design review:
- Test evidence:
- Release stop signal:

## AI Coding Rules
- Allowed context:
- Allowed files:
- Non-goal handling:
- Evidence summary:

## Exceptions
- Allowed exception:
- Required approver:
- Follow-up review date:

什么时候使用这份模板

团队希望 SDD 成为工作约定，而不只是模板集合。
多人使用 AI 编码工具，需要一致护栏。
评审质量不稳定，因为证据标准不统一。
负责人需要一份能放进仓库的轻量政策。

填好后应该是什么样

模板只有在写入真实决策、负责人和证据后才有价值。下面是一个可评审的片段。

## Required Gates
- 支付、认证、迁移和公开 API 变更必须经过规格评审。
- AI 生成代码必须包含证据总结和测试命令。
- evidence.md 中的指标超过阈值时停止发布。

实现前先检查这些点

原则具体到能影响评审行为。
门禁区分低风险和高风险工作。
AI 规则写明允许上下文、文件和证据。
例外必须有批准人和复盘日期。

弱写法 vs 强写法

弱写法

写好规格，负责任地使用 AI。

强写法

支付、认证、迁移和公开 API 变更必须有评审过的规格、链接的证据日志和上线停止信号。AI 生成 diff 必须列出允许文件、实际修改文件和覆盖的验收标准。

FAQ

小团队会不会太正式？

可以很短。一页以内也能有用，前提是写的是团队真正会执行的规则。

它应该放在哪里？

放在仓库或团队手册里，并从模板、PR 描述和 AI 编码说明链接过去。

多久更新一次？

事故、重复评审漏项或工具变化之后更新；不要为了润色文字频繁改。

编辑说明

这份模板面向 spec-driven development 工作流，示例用于展示结构，不代表特定公司的内部流程。

作者: Daniel Marsh
编辑政策: 我们如何审阅和更新内容

建议把它放在仓库的 /docs/specs/ 或 /.specs/ 下，并在实现过程中持续更新。最后更新：2026 年 5 月 11 日。