很多人在使用 Spec‑Kit 时都会有一种相似的困惑：

我也曾如此。

真正卡住我的，并不是 Specify 怎么写。而是我下意识跳过了关键的第一步先——Constitution。

下面这篇文章，将把我踩过的三个坑逐一拆解。并把你的常见痛点嵌入其中，让你在阅读时直接对号入座。

一、流程本身没问题，问题出在“起点”选择上

Spec‑Kit 的完整流程如下逻辑严谨且工程化：

Constitution → Specify → Clarify → Plan → Tasks → Analyze → Implement

官方文档的观点是。

如果严格按顺序执行，每一步都能顺畅推进。但大多数人会本能地：

跳过 Constitution直接进入 Specify

• Specify 看起来“更像干活”。
• Constitution 似乎只是一段背景说明。
• 误以为写不写它，对生成代码影响不大。

使用者痛点：

• “我想快点写代码，却总是被前置工作拖慢进度？说起来，”
• “跳过宪法后总是出现需求反复、方向摇摆的情况？按理说，”

二、第一次写 Constitution。我写得非常“敷衍”

1. 运行 specify init
2. 看到生成的 /speckit.constitution
3. 心想这方面，“只要写一句话就行吧？”

说到于是我写下，

This looked fine at moment。but instantly felt wrong.

为什么这句话是“废话”？

• 太泛：什么是 “高质量”？ 没有定义，
• 太安全：a safe statement that never gets you in trouble.
• No constraint for AI：The model can interpret “high quality” in countless ways.

三、第二次更“认真”，但方向彻底错了——把所有规则塞进去

I thought “being thorough” meant dumping every rule I could think of:

• C​ursor rules
• E​SLint / Prettier 配置
• Naming conventions 
• D​irectory layout 
• T​esting requirements 

The result?A massive “development handbook”。not a constitution.

从痛点对照表来看，到底该放哪里？

...

四、转变思路：从「应该写什么」到「冲突时谁说了算」

I stopped asking “what belongs in Constitution?” and started asking:

"When AI and I disagree,whose decision wins?" / p> / blockquote>

• 主要原则示例 ✅︎ 放入 Constitution
  • 类型安全优先于开发速度。
  • Apollo GraphQL 必须统一错误格式。
  • CICD 流水线必须通过安全审计。
  • `memory` 容易被 `specify re‑init` 覆盖；
  • `memory` 不受版本控制，历史难以追溯。把 Constitution 当作代码资产。与源码同级管理，是最稳妥的做法。--- ## 写在最终