用Spec-kit踩完3个坑后才明白，Constitution才是真正的起点!

很多人在用 Spec-Kit 的时候，都会有一种相似的感觉：

"流程看起来挺清楚，但我一上来就有点不知道该从哪下手。"

我也是。

后来我才发现，真正让我卡住的不是 Specify 怎么写，而是我下意识地跳过了 Constitution 这一步。

这篇文章想聊的，就是我在 Constitution 这一步踩过的坑，以及我是如何慢慢理解其真正价值的。

---

一、Spec-Kit 的流程本身没问题，问题在于你从哪开始

Spec-Kit 的完整流程，其实是非常克制、也非常工程化的：

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

官方文档：github.com/github/spec...

如果你按顺序来，每一步都很合理。

但现实中，大多数人（包括我一开始）都会下意识地：

跳过 Constitution，直接 Specify。

因为：

• Specify 看起来"更像干活"。
• Constitution 看起来"像一段背景说明"。
• 好像写不写，对能不能生成代码影响不大。

直到你真的用了一段时间，才会发现：

Specify 写得再认真，只要 Constitution 没想清楚，后面每一步都会反复摇摆。

---

二、第一次写 Constitution，我写得非常"敷衍"

我第一次用 Spec-Kit 时，是这样操作的：

1. 运行 specify init。
2. 看到有 /speckit.constitution 这个命令。
3. 心想："那我在这个指令后面写一句话不就好了？"

于是我写了类似这样的话：

"本项目使用 TypeScript，追求高质量代码。"

写完的一瞬间，我自己就知道不对劲了。

它的问题很明显：

• 太泛：什么是"高质量"？没有定义。
• 太安全：这是一句永远不会错的"废话"。
• 对 AI 几乎没有约束力：AI 完全可以按照自己的理解去解释"高质量"。

这不是宪法，更像 README 的第一句。

---

三、第二次更"认真"，但方向彻底错了

后来我决定认真一点，于是做了另一件事：把能想到的所有规则都塞了进去。

• Cursor 里的 rules
• ESLint / Prettier 规则
• 命名规范
• 目录结构
• 测试要求

全部贴进 Constitution。

这一次的问题刚好相反：内容非常多、非常具体，但读起来像一份**"开发手册"**，而不是"宪法"。

我真正困惑的是：如果这些都是 Constitution，那 rules 和各种配置文件又是什么？界限在哪里？

---

四、真正想明白，是在我换了一个问题之后

后来我不再问："Constitution 应该写什么？"

而是换成问：

"当 AI、工具和我意见不一致时，到底该听谁的？"

比如：

• AI 为了快，想绕过类型系统。
• AI 为了省事，直接把逻辑写死，而不是做成可配置。
• AI 引入了第二套技术方案，看起来也说得通，但破坏了系统一致性。
• Spec-Kit 默认用英文输出，但团队其实更习惯中文沟通。

这些问题的共同点是，它们不是"怎么写更好"的实现问题 ，而是"这样做行不行"的原则问题。

这时候我才意识到，Constitution 的核心角色有两个：

1. 基石（Baseline）：为项目定义一套所有参与者（包括 AI）都必须遵守的、不可动摇的质量和原则底线。
2. 裁决者（Tie-Breaker）：当出现模棱两可或冲突的情况时，为 AI 提供最高决策依据，告诉它应该"站哪一边"。

它不是在教 AI 如何一笔一划地写代码，而是在设定整个项目的"价值观"和"行为准则"。

---

五、一个更清晰的判断标准：区分"What"与"How"

为了准确地区分什么该放进 Constitution，我总结了一个更好用的标准：这条规则是在定义"我们追求什么（What）"，还是在定义"我们如何实现（How）"？

• 定义"What & Why"的规则 ，应该进入 Constitution。它们是关于目标的、原则性的、跨技术栈的，回答的是"我们的价值观是什么？"
• 定义"How"的规则 ，则应该由具体的 rules 或配置文件管理。它们是关于实现的、工具性的，回答的是"我们用什么工具/方法来实现那个目标？"

通过一个表格对比，会非常清楚：

规则类型	示例	是否应放入 Constitution	理由
价值原则	类型安全优先于开发速度	是	定义了项目核心的价值取向，是典型的"What"。
质量底线	不可测试的代码视为不完整	是	设定了代码可接受的最低标准，是"What"。
一致性标准	所有API响应体必须使用 camelCase	是	确保了"系统一致性"，是关于代码形态的"What"。
量化指标	单元测试覆盖率必须达到 80%	是	将"测试标准"这一原则具体化，是可衡量的"What"。
工具配置	ESLint 使用 @typescript-eslint/recommended 规则集	否	这是实现"类型安全"和"一致性"的具体"How"。
路径约定	rules 文件放在 .cursor/rules 目录	否	这是工具层面的约定，是纯粹的"How"。

这个标准帮助我们守住 Constitution 的边界：它只关心那些最核心、最稳定、能够指导长期决策的原则。

---

六、我最后整理出的 Constitution，刻意"少写了很多东西"

最终，我将我的 Constitution 从"某个项目的规范"，抽象成了一份"通用的 AI 协作裁决协议"。

这份 Constitution 只关心三件事：

1. 价值排序（Priorities）
   • 类型安全 > 开发速度
   • 可维护性 > 一时便捷
   • 系统一致性 > 个人风格
2. 不可谈判的边界（Non-Negotiables）
   • 不能绕过类型系统。
   • 不能引入平行的技术体系（如在 React 项目中引入 Vue）。
   • 不可测试的代码视为不完整。
3. 冲突时的取向（Defaults）
   • 当工具默认语言与团队主语言冲突时，优先使用团队主语言（如中文）。
   • 当可配置性与硬编码有冲突时，优先选择可配置性。

它刻意不关心：

• 具体的 ESLint 规则细节。
• 某个函数的命名方式。
• src 目录的具体结构。

因为这些都属于实现层面的"How"，它们会、也应该随着项目演进而变化。而 Constitution 里的"What"，则应该像真正的宪法一样，保持高度稳定。

---

七、最后一个非常实际的问题：Constitution 放哪？

这是我踩过的最后一个坑。

官方默认的做法，是将 Constitution 存放在 .specify/memory/constitution.md。

但这种做法长期来看是不安全的：

• memory 可能会被意外清空。
• specify re-init 的时候可能会覆盖它（切换工具，比如从cursor切换到codebuddy的过程中，会重新执行specify init --here）。

我现在的最佳实践，是采纳一种"治理即代码（Governance as Code） "的思路，将 Constitution 视为项目的一等公民。具体做法是：

specs/
  _governance/
    constitution.md

这意味着：

• Constitution 是项目核心资产，与源代码一起接受版本控制。
• 它不依赖于任何特定的工具（无论是 Cursor、CodeBuddy 还是其他 Agent）。
• 它的变更历史是清晰、可追溯的。

至于 memory 里的那份？可以把它当成一个临时的"缓存"，但项目的"单一事实来源（Single Source of Truth）"必须是版本库中的这份文件。

然后执行

/speckit.constitution 使用/specs/_governance/constitution.md

---

写在最后

如果你现在也卡在 Spec-Kit 的第一步，我的结论是：

Spec-Kit 真正的起点不是 Specify，而是你有没有想清楚，当 AI 和你意见不一致时，谁说了算。

当 Constitution 这一步稳住了，它就为整个项目提供了一个稳定的"引力场"，无论后面的 Clarify、Plan、Tasks 走得多远，都不会偏离核心轨道。

分享一下此时此刻我在用的前端Vue3全家桶（其实跟框架已经毫无关系了）场景的constitution

# Universal AI-Driven Engineering Constitution  
**Constitution v1.3（Tool-Agnostic · Project-Agnostic）**

> **权威声明（Source of Truth）**  
> 本文件定义 AI 与人类在软件工程中的协作治理原则，  
> 是所有基于 spec-kit 或等价规范驱动流程的项目的  
> **最高裁决协议（Single Source of Truth）**。  
>  
> 当效率、工具默认行为、个人偏好与本宪法发生冲突时，  
> **以本宪法为最高优先级**。

---

## I. 类型优先，安全第一  
**Type-First, Safety-First（NON-NEGOTIABLE）**

### 裁决原则
- 类型安全 **优先于** 开发速度  
- 编译期确定性 **优先于** 运行时容错  
- 明确约束 **优先于** 模糊灵活  

### 不可违背的边界
- 所有可类型化系统必须启用严格类型检查  
- 不允许绕过类型系统规避问题（如 `any`、隐式弱类型）  
- 所有对外边界（API、模块、组件、状态）必须具备明确契约  

> **裁决说明**：  
> 当"先跑起来"和"类型完整性"发生冲突时，必须选择后者。

---

## II. 配置驱动，组合优先  
**Configuration-Driven, Composition-First（NON-NEGOTIABLE）**

### 裁决原则
- 组合优于继承  
- 声明式优于命令式  
- 配置优于硬编码  

### 不可违背的边界
- 业务能力必须通过组合式抽象构建  
- 系统行为应可通过配置表达  
- 禁止将核心业务规则硬编码进表现层或入口逻辑  

> **裁决说明**：  
> 当"快速写死逻辑"和"可组合、可配置"发生冲突时，必须选择后者。

---

## III. 语义清晰，体系一致  
**Semantic Clarity, System Consistency（NON-NEGOTIABLE）**

### 裁决原则
- 可读性优先于技巧性  
- 一致性优先于个人风格  
- 语义优先于实现细节  

### 不可违背的边界
- 命名必须表达业务或领域语义  
- 局部实现不得破坏整体体系一致性  
- 禁止引入"只有作者能理解"的隐式约定  

> **裁决说明**：  
> 当个人偏好与系统一致性发生冲突时，以系统一致性为准。

---

## IV. 分层防御，用户友好  
**Layered Defense, User-Friendly（NON-NEGOTIABLE）**

### 裁决原则
- 系统稳定性优先于功能完整性  
- 用户可理解性优先于技术精确性  

### 不可违背的边界
- 错误必须被分层捕获与处理  
- 系统不得以"静默失败"作为默认策略  
- 单点错误不得导致系统级崩溃  

> **裁决说明**：  
> 当实现复杂度与系统韧性发生冲突时，必须选择系统韧性。

---

## V. 单一数据源  
**Single Source of Truth（NON-NEGOTIABLE）**

### 裁决原则
- 状态集中管理  
- 数据来源唯一  
- 派生而非复制  

### 不可违背的边界
- 不允许多个权威来源描述同一事实  
- 表现层不得成为事实裁决者  
- 所有状态变化必须可追踪、可审计  

---

## VI. 关注点分离  
**Separation of Concerns（NON-NEGOTIABLE）**

### 裁决原则
- 每一层只解决一个问题  
- 层与层通过明确契约协作  

### 不可违背的边界
- 领域逻辑不得渗透进展示或交互层  
- 基础设施、业务规则、表现逻辑不得混杂  

> **裁决说明**：  
> 当"减少抽象层级"和"职责清晰"发生冲突时，必须选择职责清晰。

---

## VII. 可测试性优先  
**Testability-First（NON-NEGOTIABLE）**

### 裁决原则
- 可验证性是设计质量的一部分  
- 不可测试的实现视为不完整  

### 不可违背的边界
- 核心业务逻辑必须可被自动化验证  
- 关键用户路径必须具备端到端验证能力  

> **裁决说明**：  
> 当设计导致难以测试时，必须重构设计，而不是削弱测试。

---

## VIII. 技术裁决权  
**Technology Decisions（NON-NEGOTIABLE）**

### 裁决原则
- 技术选择必须服务于长期可维护性  
- 不得引入平行技术体系制造分裂  

### 不可违背的边界
- 项目级技术裁决必须显式声明  
- 未经治理流程，不得随意替换核心技术路线  

> **说明**：  
> 具体技术栈由各项目在其自身规范中声明，但必须服从本宪法。

---

## IX. 文档语言裁决  
**Documentation Language Policy（NON-NEGOTIABLE）**

### 裁决原则
- 清晰理解 **优先于** 工具默认行为  
- 团队共识 **优先于** 外部惯例  

### 不可违背的边界
- 团队内部规范性文档默认使用 **团队主语言**  
- 关键技术术语可保留原语言，但必须提供语义说明  

### 例外说明
- 对外文档或跨语言协作场景  
  可根据受众选择单语或双语形式  

> **裁决说明**：  
> 当 AI 工具未明确指定输出语言时，  
> **以团队主语言作为最终交付语言**。

---

## X. 治理与修订  
**Governance（NON-NEGOTIABLE）**

### 宪法地位
- 本宪法为最高治理协议  
- 优先级高于所有 Rules、Guidelines 与工具约定  

### 修订流程
1. 提议：说明动机与影响范围  
2. 讨论：评估对系统一致性与长期成本的影响  
3. 审批：由治理责任人裁决  
4. 实施：更新宪法与相关配套规范  
5. 迁移：必要时制定迁移方案  

### 版本策略
- **MAJOR**：治理原则或裁决权变更  
- **MINOR**：新增或强化原则  
- **PATCH**：澄清、措辞与结构优化  

---

## XI. 执行性说明  
**Execution Note**

- 本宪法定义 **"应当如何裁决"**，而非 **"具体如何实现"**  
- 具体实现规范（Rules）：  
  - 由当前工具或环境加载  
  - 其物理位置、格式与结构不属于宪法治理范围  
- 所有 AI / Agent：  
  - 必须以本宪法作为最高约束  
  - 不得自动生成、修改或绕过宪法内容  

---

**版本**：v1.3  
**生效日期**：2025-01-09  
**替代版本**：v1.2.1