企业官网建设流程全解析

你让 AI 写了一个用户注册模块，它顺手给你引入了三个新依赖、抽象出两层工厂模式、加了五个你根本没要求的配置项。功能是能跑，但你看着那 800 行代码，心里只有一个念头：100 行就够了。

这不是模型不够聪明的问题。这是缺乏约束的问题。

2025 年，两个人/组织的实践分别从不同角度指向了同一个解法：用一份文件，给 AI 立规矩。

一个是 OpenAI 创始成员之一 Andrej Karpathy，他在 X（原 Twitter）上分享了自己大量使用 AI 辅助编码后的实践观察，这些观察随后被开发者 Forrest Chang 整理为一份 CLAUDE.md 文件（andrej-karpathy-skills 项目，GitHub 上获得较高关注度）。

另一个是 GitHub 旗下开源项目 spec-kit，它提出了"规范驱动开发"（Spec-Driven Development, SDD）方法论，其中constitution.md是 spec-kit 工作流中的核心初始化文件之一，用于定义项目不可协商的核心原则。

这篇文章拆解这两个来源的实践，文末附 constitution.md 模板的获取方式。

一、两个来源：谁说了什么

在讲怎么做之前，先弄清楚 constitution.md 这个概念不是凭空冒出来的。它有两条清晰的来源脉络，理解了来源，才能理解为什么需要它。

来源一：Andrej Karpathy 的 AI 编码"吐槽"与 andrej-karpathy-skills

Andrej Karpathy 是谁？OpenAI 创始成员之一、特斯拉 AI 前负责人、斯坦福 CS231n 课程讲师，也是推动"vibe coding"概念传播的重要人物。他在 AI 圈的影响力意味着他的实践观察具有很高的参考价值。

2025 年，Karpathy 在 X 上分享了自己大量使用 AI Agent 辅助编码后的实践观察（原文地址：https://x.com/karpathy/status/2015883857489522876）。这个过程中暴露了 AI 编码的几个核心问题：

“模型会代你做错误假设，然后不假思索地执行。它们不管理自身的困惑，不寻求澄清，不呈现矛盾，不展示权衡，在应该提出异议时也不反驳。”

“它们真的很喜欢把代码和 API 搞复杂，堆砌抽象概念，不清理死代码……明明 100 行能搞定的事情，非要实现成 1000 行的臃肿架构。”

“它们有时仍会改动或删除自己理解不足的代码和注释，即使这些内容与任务本身无关。”

Karpathy 还观察到一个关键点：LLM 擅长循环执行直到达成特定目标，问题在于你给它的是指令而不是目标。如果你说"添加验证"，它会自行决定怎么验证；如果你说"为无效输入编写测试，然后让它们通过"，它就有了明确的成功标准。

这条推文引发了大量关注和讨论。开发者 Forrest Chang 创建了 GitHub 项目andrej-karpathy-skills（https://github.com/forrestchang/andrej-karpathy-skills），将 Karpathy 的实践观察整理为一份 CLAUDE.md 形式的 AI 编码约束，目前在 GitHub 上获得较高关注度。

这个项目将 Karpathy 的观察提炼为四条原则：

andrej-karpathy-skills 的价值在于它证明了：把约束写进文件，比每次对话时口头重复有效得多。在支持项目级配置文件的 AI 编码工具中（如 Claude Code 会自动读取 CLAUDE.md），这些原则在每次交互中都生效，不需要你反复提醒。不同工具的机制有所差异，但核心思路一致：用文件固化约束。

来源二：GitHub spec-kit 与规范驱动开发

差不多同一时间，GitHub 旗下开源了spec-kit项目（https://github.com/github/spec-kit），提出了"规范驱动开发"（Spec-Driven Development, SDD）方法论。

spec-kit 要解决的问题和 Karpathy 观察到的一样：AI 编码缺乏约束，导致输出不一致、难以维护。但 spec-kit 的解法更系统化——它不只是写一份约束文件，而是定义了一个完整的开发工作流：

clarify（澄清需求）→ specify（写规格说明）→ plan（技术方案）→ tasks（任务拆解）→ implement（实现代码）

每一步都有对应的 Markdown 文件作为产出物：spec.md、plan.md、tasks.md。而贯穿所有步骤的核心约束文件，就是constitution.md。

在 spec-kit 中，constitution.md存放在.specify/memory/constitution.md路径下。它的定位非常明确：

“constitution 中的任何内容都应凌驾于所有其他指令之上，因为它们是你不可协商的原则。”

（注：这里的"凌驾于其他指令"应理解为项目开发上下文中的约束优先级，而非 AI 系统级权限。）

需要注意的是，spec-kit 说的"凌驾于所有其他指令之上"，指的是在项目开发上下文范围内——即约束 AI Agent 在代码生成、技术方案设计等开发环节的行为。它不是 AI 系统级权限，不能覆盖模型运行环境的安全策略，也不能覆盖用户在会话中明确给出的指令。理解这个边界很重要：constitution.md 是项目级约束，不是万能控制开关。

spec-kit 在规划流程中体现了 Constitution Check 和 Gate 式检查的思想。当 AI 执行/speckit.plan生成技术方案时，它会对照 constitution.md 的条款进行检查：

• Simplicity Gate（简单性门禁）：项目结构是否超过 3 个层级？是否加入了不必要的未来扩展性？
• Anti-Abstraction Gate（反抽象门禁）：是否直接使用了框架特性？是否创建了不必要的抽象层？
• Integration-First Gate（集成优先门禁）：是否在实现前先定义了 API 规格？

如果门禁未通过，AI 必须在plan.md中明确记录原因。这就把"原则"变成了"可执行的流程节点"。

两条来源的关系

Karpathy 的观察回答了"AI 编码有什么问题"，andrej-karpathy-skills 回答了"怎么用文件约束这些问题"，spec-kit 则回答了"怎么把约束变成系统化的开发流程"。

本文讨论的 constitution.md，核心思想来自 spec-kit 的定义（高层级原则契约、不可协商条款、宪法门禁），四条具体原则来自 Karpathy 的观察（编码前思考、简洁优先、精准修改、目标驱动执行）。两者结合，构成了一套完整的实践方案。

二、项目宪法的设计理念与核心原则

constitution.md 是什么

如果说 CLAUDE.md 是交给 Claude Code 的"操作指南"，那么 constitution.md 就是你和 Claude Code 签署的"原则契约"。

两者的差异体现在三个维度：

需要说明的是，以上是常见实践中的分工，不是标准定义。CLAUDE.md 也可以包含原则，constitution.md 也可以包含流程，实际边界由团队自行约定。两者的关系是互补的，不是对立的。

四大核心原则

这四条原则直接对应 Karpathy 在推文中列出的四个问题，每一条都是针对 AI 编码特定弱点的精确反制：

原则一：编码前思考

对应 Karpathy 的观察：“模型会代你做错误假设，然后不假思索地执行。”

• 明确说明假设，不确定就问而不是猜
• 存在歧义时呈现多种解释，不默默选择
• 发现更简单的方法时主动提出
• 困惑时停下来，指出不清楚的地方并要求澄清

原则二：简洁优先

对应 Karpathy 的观察：“它们真的很喜欢把代码和 API 搞复杂，堆砌抽象概念……明明 100 行能搞定的事情，非要实现成 1000 行的臃肿架构。”

• 不添加要求之外的功能
• 不为一次性代码创建抽象
• 不添加未要求的"灵活性"或"可配置性"
• 如果 200 行代码可以写成 50 行，重写它

检验标准：资深工程师会觉得这过于复杂吗？如果是，简化。

原则三：精准修改

对应 Karpathy 的观察：“它们有时仍会改动或删除自己理解不足的代码和注释，即使这些内容与任务本身无关。”

• 不要"改进"相邻的代码、注释或格式
• 不要重构没坏的东西
• 匹配现有风格，即使你更倾向于不同的写法
• 注意到无关的死代码，提一下就行，不要擅自删除

检验标准：每一行修改都应该能直接追溯到用户的请求。

原则四：目标驱动执行

对应 Karpathy 的观察：“LLM 擅长循环执行直到达成特定目标，但你给它的是指令而不是目标。”

弱标准（“让它工作”）需要不断人工澄清。强标准让 AI 能够独立循环执行。

spec-kit 的工程约束（本文归纳为九类）

除了上述四条通用原则，spec-kit 自身的 constitution 还定义了更具体的工程约束。为了方便讨论，本文将其归纳为以下九类（注意，"九类"是本文的概括，不是 spec-kit 官方术语）：

1. 库先行：对复杂功能优先考虑库化设计，强制模块化。简单 CRUD 项目或前端项目不一定适用
2. CLI 接口暴露：对可独立运行的工具类模块，优先提供 CLI 或自动化测试入口。Web 服务和 SDK 不强制
3. 测试先行铁律：核心业务逻辑必须在实现前先写测试。探索性开发和原型验证允许快速试错
4. 集成优先：强调集成测试的重要性
5. 可观测性：要求结构化日志
6. 版本控制规范：定义清晰的版本号规范
7. 简单性原则：初始项目结构不宜超过 3 个层级
8. 反过度抽象：优先使用框架特性，而不是过度包装
9. 集成优先测试：优先使用真实数据库而非纯 Mock

这九类约束不是随便写的。每一条都针对 AI 在实际编码中暴露出的具体弱点。比如"初始结构不宜超过 3 个层级"这条，就是专门为了对抗 AI 喜欢堆叠抽象层的倾向——spec-kit 称之为 Anti-Abstraction Gate。但要注意，这些约束是 spec-kit 针对自身项目场景设定的，直接搬到你的项目里不一定全适用，需要按项目类型裁剪。

三、constitution.md 的结构与关键字段说明

整体结构

一份完整的 constitution.md 包含两个部分：核心条款和治理机制。核心条款定义"什么必须做、什么不能做"，治理机制定义"宪法怎么执行、怎么更新、怎么处理例外"。

下面以一个真实的 Spring Boot 项目宪法为例，逐段拆解。

文件头：版本与声明

# [项目名] 项目开发宪法 # Version: 1.0, Ratified: 2025-10-20 本文件定义了本项目的核心开发原则。 所有 AI Agent 在进行技术规划和代码实现时，应优先遵循本文件定义的项目原则。 默认情况下必须遵循，例外情况需要明确说明原因。

关键字段：

• 项目名：明确宪法的作用域
• Version：版本号，每次修订递增，便于追溯。spec-kit 建议遵循语义化版本
• Ratified：批准日期，标记宪法的生效时间
• 声明语句：一句话定义文件的权威性。注意措辞——"优先遵循"和"例外需说明原因"比"无条件遵循"更符合实际工作方式，也避免读者误认为 constitution.md 可以覆盖用户明确指令

核心条款：条目结构

每一条条款遵循统一的结构：

## 第N条：[原则名称] ([英文原名]) **核心：** [一句话概括这条原则的精髓] - **N.1 ([子原则名]):** [具体规则描述] - **N.2 ([子原则名]):** [具体规则描述] - **N.3 ([子原则名]):** **不可协商**：[具体规则描述]

三个关键设计点：

"核心"字段：用一句话浓缩原则精髓。AI 在快速扫描时能立刻抓住要义。例如"遵循 Spring Boot 的’约定优于配置’哲学。绝不进行不必要的抽象，绝不引入非必需的依赖。"

子原则编号：N.1、N.2、N.3 的编号不是装饰。在合宪性审查时，AI 需要逐条对照："计划是否符合 1.2？是否符合 2.3？"编号让审查可追溯。

"不可协商"标记：这是 constitution.md 最有力的字段，直接来自 spec-kit 的 NON-NEGOTIABLE 概念。标记为"不可协商"的规则，AI 不得以任何理由绕过。典型场景包括：安全相关规则（禁止硬编码密钥）、测试先行、错误处理规范。

典型条款清单

一份覆盖完整开发周期的 constitution.md 通常包含以下条款：

治理机制

核心条款之后，是四个治理模块。这部分直接参考 spec-kit 的治理设计：

治理（Governance）：定义宪法的优先级。

本宪法用于约束 AI Agent 的默认开发行为，在项目开发上下文范围内具有优先指导地位。 当用户提出明确变更需求时，应进行冲突分析，并记录例外原因。 不覆盖系统级安全策略和用户明确指令。 任何计划在生成时，应首先进行"合宪性审查"。

这里说的是"项目开发上下文范围内"的优先指导地位。constitution.md 约束的是 AI Agent 在代码生成、架构决策等开发环节的默认行为，当用户明确要求例外时，AI 应进行冲突分析而非直接阻断。它的优先级仍低于模型运行环境的系统级指令和安全策略。spec-kit 原文说的"凌驾于所有其他指令之上"，指的也是项目内开发指令，而非系统级权限。

执行（Enforcement）：定义怎么落地。

1. 自动化检查：用静态分析工具（SonarQube、Checkstyle、golangci-lint）强制执行
2. 代码审查：在 PR 审查时检查是否符合宪法
3. 阻断机制：阻止违反关键规则的 PR 合并
4. 培训：提供宪法相关培训

更新（Updates）：定义怎么演进。

1. 每季度审查宪法以确保相关性
2. 根据反馈和新技术更新规则
3. 将变更传达给团队
4. 提供更新规则的培训

例外（Exceptions）：定义怎么处理特殊情况。

1. 例外需要技术负责人批准
2. 记录例外及其原因
3. 例外应该是临时的，而非永久的
4. 定期审查例外情况

四、实际项目中的应用场景与效果分析

场景一：Spring Boot 项目的宪法实践

在一个 Spring Boot 项目的 constitution.md 中，第四条"安全第一原则"这样写：

- **4.1 (无硬编码密钥):** **不可协商**：绝不允许在代码中硬编码密码、API 密钥 或其他敏感信息。必须使用环境变量或 Spring Cloud Config。 - **4.2 (认证授权):** **不可协商**：所有 REST 端点（除公开 API 外）都必须要求认证。 必须使用 Spring Security 实现基于角色的访问控制（RBAC）。 - **4.3 (输入验证):** **不可协商**：必须使用 @Valid 和 JSR-380 注解验证所有用户输入。 绝不允许信任任何客户端数据。

效果：AI 在生成新的 Controller 时，会自动添加@Valid注解和 Spring Security 配置。如果用户要求"快速实现一个临时接口，不需要认证"，AI 会提示该需求与项目安全规则存在冲突，并要求确认是否按例外处理，而不是直接跳过安全约束。

场景二：Go 项目的宪法实践

在一个 Go 项目的 constitution.md 中，第三条"明确性原则"这样写：

- **3.1 (错误处理):** **不可协商**：所有错误都必须被显式处理。 绝不允许使用 `_` 丢弃错误。错误传递时必须使用 `fmt.Errorf("...: %w", err)` 进行包装。 - **3.2 (无全局变量):** 绝不允许使用全局变量来传递状态。 所有依赖必须通过函数参数或结构体成员显式注入。 - **3.3 (注释规范):** 注释应该解释"为什么"，而不是"是什么"。 所有公共 API 都必须有清晰的 GoDoc 注释。

第四条"单一职责原则"约束了包级别的边界：

- **4.1 (包的内聚):** internal 目录下的各个包应保持高度内聚和低耦合。 例如：github 包只负责与 GitHub API 交互，绝不能包含 Markdown 转换逻辑。 - **4.2 (接口隔离):** 定义小的、目标明确的接口，而不是大而全的"上帝接口"。

第二条"测试先行铁律"中还有一条值得注意的子原则：

- **2.3 (拒绝Mocks):** 优先编写集成测试，使用真实的依赖或 fake object （如内存中的 GitHub API 模拟服务器），而不是过度依赖 Mock。

这条"拒绝Mocks"理念值得多说一句。AI 写测试时有一个倾向：遇到外部依赖就上 mock 框架，把所有接口都 mock 掉，测试看起来覆盖率很高，但实际上只是在测"mock 是否按预期返回值"，真正的集成逻辑一点没测到。Go 宪法的要求是：用 fake object（一个实现了相同接口的内存版本）替代真实依赖，而不是用 mock 框架逐个方法打桩。

不过，Mock 和 Fake 不是简单的优劣关系。Mock 适合验证交互行为（比如"是否调用了正确的 API 方法"），Fake 适合模拟复杂依赖的真实行为，Stub 适合简单返回固定值，真实服务用于端到端集成测试。Go 宪法倾向于 Fake 是因为它在保持测试速度的同时更接近真实行为，但这不意味着 Mock 没有适用场景。关键是根据测试目标选择，而不是一刀切地拒绝某种方式。

效果：AI 生成的 Go 代码中不再出现err, _ :=这样的模式，所有错误都通过%w包装传递。在生成新包时，AI 会主动将依赖通过结构体成员注入，而不是使用包级变量。生成测试时，AI 会先写一个 fake server 而不是直接导入 mock 库。

场景三：合宪性审查机制

constitution.md 单独存在效果有限。真正的力量在于把"合宪性审查"变成一个强制流程节点——这正是 spec-kit 的核心设计。

在 spec-kit 的实践中，plan.md模板里包含了一个"Constitution Check"章节，其中的门禁机制直接对应 spec-kit 的 Constitutional Gates：

## Constitution Check (合宪性审查) *GATE: 必须在进行技术方案设计前通过。* - [ ] 简单性门禁 (Simplicity Gate): 是否优先使用了标准库？是否避免了不必要的抽象？ - [ ] 测试先行门禁 (Test-First Gate): 计划中是否包含了"先写测试"的步骤？ - [ ] 反抽象门禁 (Anti-Abstraction Gate): 是否直接使用了框架特性而非创建抽象层？ - [ ] 安全门禁 (Security Gate): 是否存在硬编码密钥的风险？是否规划了认证机制？ *如果任何门禁未通过，必须在下方"复杂性追踪"部分给出充分理由。*

当 AI 被要求生成技术方案时，它看到这个模板，会被强制对照 constitution.md 的条款逐一检查打勾。如果门禁未通过，AI 不是默默跳过，而是必须在方案中明确记录"为什么违反了原则"以及"为什么这次违反是合理的"。这把抽象的原则转化为了具体的、可执行的清单，同时保留了例外决策的可追溯性。

效果分析

在实际使用中，constitution.md 带来了几个可观察的变化：

AI 生成代码规模通常会下降。反过度工程条款（“初始结构不宜超过 3 个层级”“如果 200 行可以写成 50 行，重写”）限制了 AI 生成代码的膨胀倾向。一些团队观察到引入宪法后 AI 输出更加紧凑，原本动辄数百行的模块变得更精简。

测试覆盖率提升。测试先行铁律要求 AI 先写失败测试再写实现。这意味着每个新功能天然带有测试用例，而不是事后补测试。

安全漏洞在生成阶段被拦截。安全第一原则中的"不可协商"条款，让 AI 在生成代码时就遵循安全规范，而不是在代码审查阶段才发现硬编码密钥等问题。

技术决策有据可依。当团队成员对"该用 JPA 还是 MyBatis""该不该引入 Redis"产生分歧时，宪法就是裁判。1.2 条款"Spring Boot 原生优先"直接给出了答案。

五、常见问题与最佳实践建议

常见问题

Q1：constitution.md 和 CLAUDE.md 到底什么关系？要不要都写？

都要写。它们是互补的。constitution.md 定义项目层面的核心约束，CLAUDE.md 定义日常操作规范。打个比方：constitution.md 是宪法，CLAUDE.md 是行政法规。宪法规定"公民有受教育的权利"，行政法规规定"九年义务教育的具体实施细则"。

实际操作中，先写 constitution.md 确定核心原则，再写 CLAUDE.md 落地具体规范。在 CLAUDE.md 中引用 constitution.md：

## AI 协作指令 - **[流程] 合宪性审查:** 当被要求实现新功能时，首先对照 constitution.md 的条款检查你的计划是否合规。 - **[流程] 审查优先:** 先用 @ 指令阅读相关代码，理解现有逻辑， 然后以列表形式提出实现计划，待确认后再编码。

Q2：constitution.md 和 andrej-karpathy-skills 是什么关系？

andrej-karpathy-skills 是一份 CLAUDE.md 文件，它将 Karpathy 的四条观察编码为 AI 的行为约束。constitution.md 借鉴了这四条原则，但走得更远——它不仅约束 AI 的行为模式（思考、简洁、精准、目标驱动），还定义项目层面的工程规则（安全、测试、API 设计、数据库实践等）。可以说，andrej-karpathy-skills 是 constitution.md 的"行为原则子集"，constitution.md 在此基础上增加了"工程约束"和"治理机制"。

Q3：宪法写多少条合适？

5 到 8 条为宜。太少覆盖不全，太多 AI 的注意力会被稀释。核心原则：每一条都必须是你在实践中反复遇到过的问题。如果你从来没因为 AI 过度工程而头疼，就不需要写"反过度工程"条款。

Q4：所有规则都要标"不可协商"吗？

不要。"不可协商"标记要省着用，标多了就不值钱了。只在那些违反了会造成严重后果的规则上使用：安全相关（硬编码密钥）、数据完整性相关（事务管理）、核心架构决策（构造器注入 vs 字段注入）。大部分规则应该是指导性的，允许在特殊情况下变通。

Q5：AI 真的会遵循 constitution.md 吗？

会，但有前提。第一，constitution.md 要放在项目根目录，AI 能自动读取。第二，在 CLAUDE.md 中显式提醒 AI 遵循宪法。第三，在 plan.md 模板中加入合宪性审查章节，强制 AI 在生成方案前逐条检查。三层保障缺一不可。这也正是 spec-kit 设计 Constitutional Gates 的原因——单靠文件存在不够，必须把检查变成流程节点。

Q6：要不要直接用 spec-kit？

spec-kit 是一套完整的 SDD 工作流（clarify → specify → plan → tasks → implement），适合想要系统化改造开发流程的团队。如果你只是想让 AI 编码更规矩，不需要全套流程，单独使用 constitution.md + CLAUDE.md 就够了。spec-kit 是"重型武器"，constitution.md 是"轻量装备"，按需选择。

最佳实践

实践一：从痛点出发，不从模板出发

不要拿一份模板照搬。先列出自已项目中 AI 反复犯的错误，然后针对性地写条款。你的项目没有微服务，就不需要写微服务相关的条款。你的项目不用 Go，就不需要写表格驱动测试的条款。

实践二：每条规则都附上反面案例

好的条款不只是说"不要做什么"，还要说"为什么"。例如：

- **1.3 (反过度工程):** 避免复杂的设计模式。 简单的 Service-Repository 分层优于复杂的微服务架构。 反面案例：为一个只有 3 个接口的 CRUD 模块引入 CQRS + Event Sourcing。

反面案例帮助 AI 理解边界在哪里。

实践三：把合宪性审查写进工作流

constitution.md 的价值在于执行。在 plan.md 模板中加入 Constitution Check 章节，在 PR 模板中加入宪法合规检查项，在 CI 中加入静态分析规则。三层保障确保宪法不只是文档。spec-kit 的 Constitutional Gates 就是这么做的——门禁不通过，方案就不能往下走。

实践四：定期审查和精简

每季度审查一次宪法。问两个问题：有没有写了但从没触发过的条款？有没有反复违反但宪法里没覆盖的场景？前者删掉，后者补上。宪法应该越来越精炼，不是越来越臃肿。

实践五：团队共识优于个人偏好

constitution.md 不是一个人的文档。如果团队里有 5 个人对"该不该用 MyBatis"有 3 种意见，宪法就写不清楚。在写宪法之前，先在团队内达成共识。宪法记录的是团队已经商定的决策，不是某个人的偏好。

六、适用边界

constitution.md 不是万能的。这一章说清楚它适合什么场景，不适合什么场景，以及它的能力边界在哪里。

适合的场景

• 有明确技术栈和架构约定的中大型项目：团队对技术选型有共识，需要把这些共识固定下来让 AI 遵循
• AI 辅助开发占比高的项目：当你 50% 以上的代码由 AI 生成时，约束文件的投入产出比最高
• 新人多的团队：constitution.md 同时服务于人和 AI，帮助新成员快速理解项目的核心约定
• 反复出现同类问题的项目：比如 AI 反复引入多余依赖、反复忽略错误处理，这些用条款固化效果最好

不太适合的场景

• 探索性原型开发：快速验证想法阶段，约束反而拖慢节奏。这时候 CLAUDE.md 里写几句提醒就够了
• 技术栈尚未确定的项目：宪法条款需要具体到框架名称，技术栈都没定就写不出有效条款
• 纯视觉型前端项目：constitution.md 的核心条款（测试先行、错误处理、安全第一）更偏后端逻辑，前端项目需要大幅裁剪条款才能用。现代前端框架（React、Vue、Next.js）同样需要测试和安全约束，但条款需要重新设计
• 一人小项目：如果你一个人写代码，约束主要靠自觉，写宪法的时间不如多写几个测试

模板的 Scope 章节中还列了几类不适用的代码：临时实验代码、性能测试验证代码、一次性迁移脚本。原因是这些代码的目标是快速验证和实验，追求的是"能跑通就行"，用完整的工程治理规则去约束它们反而拖慢节奏。宪法约束的是需要长期维护的生产代码，不是所有代码。

能力边界

constitution.md 是项目级约束文件，它的作用范围有三个边界需要明确：

不能覆盖系统级安全策略。模型运行环境的安全规则、数据隐私策略、平台合规要求，优先级高于 constitution.md。宪法里不能写"跳过安全审查"之类的条款。

不能替代用户明确指令。如果用户在会话中明确要求"这次先不写测试，快速出个 demo"，AI 应该遵循用户指令，而不是用宪法条款强行阻断。constitution.md 约束的是默认行为模式，不是绝对锁死。

不能保证 100% 执行。AI 模型对 constitution.md 的遵循程度取决于模型能力、上下文窗口、文件位置等多个因素。实测中，放在项目根目录的 constitution.md 配合 CLAUDE.md 中的显式提醒，遵循率较高，但偶尔仍会有遗漏。这也是为什么需要合宪性审查作为流程节点来兜底。

七、从 Coding Rule 到 AI Engineering Governance

constitution.md 表面上是一个文件，但它背后是一个更大的趋势：AI 编码的治理方式正在演进。

很多人停留在第一阶段——写更好的 Prompt。这没错，但远远不够。Prompt Engineering 解决的是"单次对话怎么问"，当你把 50% 的编码工作交给 AI 时，单次对话的技巧就不够用了。你需要系统化的约束机制。

这条演进路径大致是这样的：

Prompt Engineering（提示工程）：关注单次对话的措辞和结构。典型问题是"怎么问才能让 AI 生成更好的代码"。局限在于约束只存在于当前对话，换一个会话就没了。

AI Coding Rules（编码规则文件）：把约束写进文件，让 AI 每次都读取。CLAUDE.md 和 andrej-karpathy-skills 处于这个阶段。典型问题是"怎么把团队的编码规范固化下来让 AI 遵循"。进步在于约束持久化了，但还缺少执行机制。

AI Agent Governance（智能体治理）：不仅有规则文件，还有执行流程。constitution.md + 合宪性审查 + Constitutional Gates 处于这个阶段。典型问题是"怎么确保 AI 真的遵循规则，而不是写完就忘"。关键变化是规则变成了流程节点，有检查、有门禁、有例外记录。

Engineering Governance（工程治理）：把 AI 编码约束融入整个工程体系。CI/CD 中的静态分析规则、PR 模板中的宪法合规检查、技术方案评审中的合宪性审查、定期的宪法审查会议。到这个阶段，AI 编码约束不再是"额外的文件"，而是工程流程的一部分。

constitution.md 处于第三阶段，并向第四阶段延伸。它不仅仅是一份规则文件，更是一种治理思路：把人对 AI 的约束从"口头提醒"变成"文件固化"，从"文件固化"变成"流程节点"，从"流程节点"变成"工程体系"。

这意味着什么？

对于正在引入 AI 编码的团队，不要只关注"用什么模型"“买什么 License”。如果你不建立约束机制，AI 生成的代码越多，技术债积累越快。constitution.md 是一个低成本的起点——不需要改造工具链，不需要买新工具，一个文件就能开始。

对于技术负责人，AI 编码治理应该纳入技术治理的整体框架。就像你管理代码质量（Code Review、静态分析、测试覆盖率）、管理架构演进（ADR、技术雷达）、管理安全合规（SAST、DAST、渗透测试）一样，AI 编码行为也需要被治理。constitution.md 是这个治理体系的第一块拼图。

Karpathy 的观察揭示了问题，spec-kit 给出了方法论，但真正落地需要每个团队根据自身情况裁剪。这不是一次性工作，而是随着 AI 编码占比提升需要持续演进的治理实践。

获取 constitution.md 模板

本文配套一份通用 constitution.md 模板，覆盖项目愿景、9 条核心条款（简单性原则、测试先行铁律、明确性原则、单一职责原则、安全第一原则、API 设计原则、数据库最佳实践、性能优化原则、Git 工作流规范）、技术栈要求、架构约束、治理机制等模块，方括号标注了需要按项目填充的位置。

模板使用建议：

1. 裁剪：删掉你的项目不需要的条款。用 Go 的项目删掉 MyBatis 相关内容，不用微服务的项目删掉微服务条款
2. 填充：把方括号[...]里的内容替换为你项目的实际选择。每一条都要具体到框架名称和版本号。例如 Go 项目填 1.2 时写"Web 服务使用net/http，而不是 Gin 或 Echo"，而不是笼统地写"优先使用标准库"
3. 补充：在每条原则下补充你项目的反面案例。反面案例越具体，AI 的理解越准确
4. 测试：写完后让 AI 生成一个新功能，观察它是否遵循了宪法的规则。如果没有，检查条款是否足够明确
5. 迭代：使用两周后回顾，删掉没起作用的条款，补充新发现的问题

需要本文模板源文件的朋友，关注公众号后发送constitution-template即可获取。

参考来源

Andrej Karpathy 推文（原文）

• https://x.com/karpathy/status/2015883857489522876
• Karpathy 在 2025 年分享了大量使用 AI Agent 辅助编码后的实践观察

andrej-karpathy-skills 项目

• https://github.com/forrestchang/andrej-karpathy-skills
• 开发者 Forrest Chang 将 Karpathy 的实践观察整理为 CLAUDE.md 形式的 AI 编码约束，GitHub 上获得较高关注度
• 四条原则：编码前思考、简洁优先、精准修改、目标驱动执行

GitHub spec-kit 项目

• https://github.com/github/spec-kit
• GitHub 旗下开源的"规范驱动开发"（SDD）工具包
• 核心概念：constitution.md（宪法）+ Constitutional Gates（宪法门禁）+ SDD 工作流（clarify → specify → plan → tasks → implement）
• constitution.md 存放路径：.specify/memory/constitution.md

写在最后

constitution.md 的本质不是限制 AI 的能力，而是给 AI 的能力装上方向盘。

AI 生成代码的问题从来不是"不够智能"，而是"太智能了但方向不对"。它会自动帮你加抽象、加配置、加灵活性，每一个都出于好意，但加在一起就把一个简单功能变成了一个难以维护的工程。

Karpathy 在推文里说得很清楚：模型会代你做错误假设，会堆砌抽象，会改动无关代码。spec-kit 的解法是把约束变成文件、把文件变成流程节点、把流程节点变成门禁。两者结合，就是 constitution.md 的完整实践。

一份好的宪法，就是告诉 AI：哪些事你必须做（测试先行、安全第一），哪些事你不能做（过度抽象、硬编码密钥），哪些事你可以自己判断（其他一切）。

把规矩立在前面，比在代码审查时一个个挑毛病高效得多。