spec kit ai code review
目录
这是一个非常高级、而且正是 Spec Kit /constitution 的“正解用法”的问题。
我直接给你工程化答案，而不是概念描述。
一句话结论（先给结论）
Spec Kit 的
/constitution本质上是：
「把 code review 的隐性经验，显式化为 AI 可执行的审查规则」
它不是文档，而是：
自动 Code Review 的“裁判规则 + 判罚标准”
一、/constitution 在 Spec Kit 中的真实定位
你可以把它理解为三件事的合体：
| 传统角色 | /constitution 对应 |
|---|---|
| 技术规范文档 | ❌（太弱） |
| Code Review Checklist | ⚠️（部分） |
| Reviewer 的判断逻辑 | ✅ 本质 |
它解决的是一个长期痛点：
为什么同样的代码，不同 reviewer 给出完全不同结论？
二、Spec Kit 如何用 /constitution 做“自动 Code Review”
1️⃣ 核心机制（非常重要）
Spec Kit 的 Code Review 不是 diff-based，而是：
Code Change
↓
Spec（Intent / Action / Constraint）
↓
Constitution（原则）
↓
Judgement（通过 / 警告 / 拒绝）
👉 代码是否“好”，取决于是否违背 constitution
2️⃣ /constitution 写的不是“规则”，而是“价值判断”
❌ 错误示例（没法自动 review）
Code should be clean and readable
✅ 正确示例（AI 可执行）
Principle:
- Business logic must not be implemented in controllers
- Controllers may only orchestrate services
Violation:
- Any conditional logic beyond parameter validation in controller layer
关键点：
constitution = 可判定（decidable）的工程约束
三、一个完整的“自动 Code Review 架构”
1️⃣ Constitution 示例（工程级）
/constitution
Architecture Principles:
1. Controllers must be stateless
2. No direct database access outside repository layer
3. Domain services must not depend on infrastructure packages
Quality Gates:
- Cyclomatic complexity > 10 requires refactor
- Functions > 80 LOC are not allowed
Testing Principles:
- New business logic must include unit tests
- Critical user flows require E2E tests
Security:
- No hard-coded secrets
- External input must be validated at boundaries
这已经是 AI 可审查的标准。
2️⃣ Code Review 的执行方式（真实落地）
在 PR / CI 中：
1. PR 提交
2. Spec Kit 收集：
- 改动代码
- 关联 Spec
- /constitution
3. AI Reviewer 执行判断：
- 是否违背原则
- 违反哪一条
- 严重级别
4. 输出 Review 结论
3️⃣ Review 输出长什么样（不是点评，是判决）
❌ Rejected
Violation:
- Architecture Principle #2 violated
- Controller OrderController directly accesses OrderRepository
Evidence:
- src/controllers/OrderController.ts:45
Suggested Fix:
- Move repository access to OrderService
👉 这是 可自动 gate 的。
四、Spec Kit /constitution 与“普通 AI Code Review”的本质差异
| 普通 AI Review | Spec Kit + constitution |
|---|---|
| 主观建议 | 可判定规则 |
| 看代码“像不像好代码” | 是否违背项目原则 |
| 每次不一致 | 高一致性 |
| 无法作为门禁 | 可作为 CI Gate |
五、如何把 /constitution 变成“真正的自动化”
推荐落地方式（成熟团队）
方式一：PR Gate（强烈推荐）
PR → AI Review → 判断是否违反 constitution
↓
pass / fail
- ❌ fail → 不允许 merge
- ⚠️ warn → 允许 merge，但标记技术债
方式二：Spec 级 Review（更高级）
/specify
↓
/plan
↓
AI 判断：此设计是否违反 constitution
例如：
“该设计引入了 controller 层业务逻辑，违反原则 1”
六、哪些原则“非常适合”写进 constitution
✅ 非常适合：
- 架构边界
- 分层约束
- 依赖方向
- 测试覆盖要求
- 安全底线
- 性能硬限制
❌ 不适合：
- 风格偏好（变量名好不好看）
- 模糊表述（“优雅”“简洁”）
- 需要上下文判断的主观感受
七、你现在这个阶段，应该怎么用（务实建议）
你已经在跑 Spec Kit，小项目阶段建议：
最小可行 Constitution（MVP）
1. Controller 禁止业务逻辑
2. 新增业务逻辑必须有 unit test
3. 修改核心流程必须更新 Spec
先用这 3 条 跑自动 review。
八、一个非常重要的认知升级（送你一句）
/constitution 不是“约束 AI”，
而是“把你最好的工程师固化下来”
它让：
- 新人 = 老手
- AI = 稳定 reviewer
- Code Review = 工程治理
如果你愿意，下一步我可以直接帮你：
- 写一份 “可执行的 /constitution 模板（工程级）”
- 设计 Spec Kit + PR Gate 的完整 CI 流程
- 或把你现有的 code review checklist 翻译成 constitution
你更想从哪一个开始？
浙公网安备 33010602011771号