文章目录一、两个来源谁说了什么来源一Andrej Karpathy 的 AI 编码吐槽与 andrej-karpathy-skills来源二GitHub spec-kit 与规范驱动开发两条来源的关系二、项目宪法的设计理念与核心原则constitution.md 是什么四大核心原则spec-kit 的工程约束本文归纳为九类三、constitution.md 的结构与关键字段说明整体结构文件头版本与声明核心条款条目结构典型条款清单治理机制四、实际项目中的应用场景与效果分析场景一Spring Boot 项目的宪法实践场景二Go 项目的宪法实践场景三合宪性审查机制效果分析五、常见问题与最佳实践建议常见问题最佳实践六、适用边界适合的场景不太适合的场景能力边界七、从 Coding Rule 到 AI Engineering Governance获取 constitution.md 模板参考来源写在最后你让 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-skillsAndrej 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-skillshttps://github.com/forrestchang/andrej-karpathy-skills将 Karpathy 的实践观察整理为一份 CLAUDE.md 形式的 AI 编码约束目前在 GitHub 上获得较高关注度。这个项目将 Karpathy 的观察提炼为四条原则Karpathy 的观察对应原则核心要求模型默默做错误假设编码前思考 (Think Before Coding)明确说明假设、呈现多种解释、困惑时停下来过度工程、臃肿抽象简洁优先 (Simplicity First)不添加要求之外的功能、200 行能写成 50 行就重写改动无关代码精准修改 (Surgical Changes)只碰必须碰的、匹配现有风格、不重构没坏的东西缺少可验证目标目标驱动执行 (Goal-Driven Execution)将添加验证转化为为无效输入写测试然后让它通过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.mdconstitution.md通常用途AI 工具协作说明、项目上下文、执行规范项目治理原则、不可协商规则典型内容怎么跑命令、用什么格式、目录结构什么必须做、什么不能做、安全红线强制力指导性允许变通项目内强约束违反需给出理由可变性易变随工具升级频繁更新高度稳定代表核心技术哲学需要说明的是以上是常见实践中的分工不是标准定义。CLAUDE.md 也可以包含原则constitution.md 也可以包含流程实际边界由团队自行约定。两者的关系是互补的不是对立的。四大核心原则这四条原则直接对应 Karpathy 在推文中列出的四个问题每一条都是针对 AI 编码特定弱点的精确反制原则一编码前思考对应 Karpathy 的观察“模型会代你做错误假设然后不假思索地执行。”明确说明假设不确定就问而不是猜存在歧义时呈现多种解释不默默选择发现更简单的方法时主动提出困惑时停下来指出不清楚的地方并要求澄清原则二简洁优先对应 Karpathy 的观察“它们真的很喜欢把代码和 API 搞复杂堆砌抽象概念……明明 100 行能搞定的事情非要实现成 1000 行的臃肿架构。”不添加要求之外的功能不为一次性代码创建抽象不添加未要求的灵活性或可配置性如果 200 行代码可以写成 50 行重写它检验标准资深工程师会觉得这过于复杂吗如果是简化。原则三精准修改对应 Karpathy 的观察“它们有时仍会改动或删除自己理解不足的代码和注释即使这些内容与任务本身无关。”不要改进相邻的代码、注释或格式不要重构没坏的东西匹配现有风格即使你更倾向于不同的写法注意到无关的死代码提一下就行不要擅自删除检验标准每一行修改都应该能直接追溯到用户的请求。原则四目标驱动执行对应 Karpathy 的观察“LLM 擅长循环执行直到达成特定目标但你给它的是指令而不是目标。”模糊指令转化为可验证目标“添加验证”“为无效输入编写测试然后让它们通过”“修复 bug”“编写重现 bug 的测试然后让它通过”“重构 X”“确保重构前后测试都能通过”弱标准“让它工作”需要不断人工澄清。强标准让 AI 能够独立循环执行。spec-kit 的工程约束本文归纳为九类除了上述四条通用原则spec-kit 自身的 constitution 还定义了更具体的工程约束。为了方便讨论本文将其归纳为以下九类注意九类是本文的概括不是 spec-kit 官方术语库先行对复杂功能优先考虑库化设计强制模块化。简单 CRUD 项目或前端项目不一定适用CLI 接口暴露对可独立运行的工具类模块优先提供 CLI 或自动化测试入口。Web 服务和 SDK 不强制测试先行铁律核心业务逻辑必须在实现前先写测试。探索性开发和原型验证允许快速试错集成优先强调集成测试的重要性可观测性要求结构化日志版本控制规范定义清晰的版本号规范简单性原则初始项目结构不宜超过 3 个层级反过度抽象优先使用框架特性而不是过度包装集成优先测试优先使用真实数据库而非纯 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 通常包含以下条款条款解决的问题典型不可协商项简单性原则AI 过度工程、引入多余依赖标准库/框架原生优先测试先行铁律AI 先写代码后补测试TDD 循环不可跳过明确性原则AI 忽略错误处理、滥用全局变量显式错误处理、构造器注入单一职责原则AI 混淆包边界、定义上帝接口包内聚、接口隔离安全第一原则AI 硬编码密钥、跳过认证无硬编码密钥、业务端点默认认证API 设计原则AI 生成不一致的接口统一响应格式数据库实践N1 查询、事务缺失分页查询必选性能优化AI 凭猜测优化基于测量优化Git 工作流AI 生成不规范的提交Conventional Commits治理机制核心条款之后是四个治理模块。这部分直接参考 spec-kit 的治理设计治理Governance定义宪法的优先级。本宪法用于约束 AI Agent 的默认开发行为在项目开发上下文范围内具有优先指导地位。 当用户提出明确变更需求时应进行冲突分析并记录例外原因。 不覆盖系统级安全策略和用户明确指令。 任何计划在生成时应首先进行合宪性审查。这里说的是项目开发上下文范围内的优先指导地位。constitution.md 约束的是 AI Agent 在代码生成、架构决策等开发环节的默认行为当用户明确要求例外时AI 应进行冲突分析而非直接阻断。它的优先级仍低于模型运行环境的系统级指令和安全策略。spec-kit 原文说的凌驾于所有其他指令之上指的也是项目内开发指令而非系统级权限。执行Enforcement定义怎么落地。自动化检查用静态分析工具SonarQube、Checkstyle、golangci-lint强制执行代码审查在 PR 审查时检查是否符合宪法阻断机制阻止违反关键规则的 PR 合并培训提供宪法相关培训更新Updates定义怎么演进。每季度审查宪法以确保相关性根据反馈和新技术更新规则将变更传达给团队提供更新规则的培训例外Exceptions定义怎么处理特殊情况。例外需要技术负责人批准记录例外及其原因例外应该是临时的而非永久的定期审查例外情况四、实际项目中的应用场景与效果分析场景一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 原生优先直接给出了答案。五、常见问题与最佳实践建议常见问题Q1constitution.md 和 CLAUDE.md 到底什么关系要不要都写都要写。它们是互补的。constitution.md 定义项目层面的核心约束CLAUDE.md 定义日常操作规范。打个比方constitution.md 是宪法CLAUDE.md 是行政法规。宪法规定公民有受教育的权利行政法规规定九年义务教育的具体实施细则。实际操作中先写 constitution.md 确定核心原则再写 CLAUDE.md 落地具体规范。在 CLAUDE.md 中引用 constitution.md## AI 协作指令 - **[流程] 合宪性审查:** 当被要求实现新功能时首先对照 constitution.md 的条款检查你的计划是否合规。 - **[流程] 审查优先:** 先用 指令阅读相关代码理解现有逻辑 然后以列表形式提出实现计划待确认后再编码。Q2constitution.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 字段注入。大部分规则应该是指导性的允许在特殊情况下变通。Q5AI 真的会遵循 constitution.md 吗会但有前提。第一constitution.md 要放在项目根目录AI 能自动读取。第二在 CLAUDE.md 中显式提醒 AI 遵循宪法。第三在 plan.md 模板中加入合宪性审查章节强制 AI 在生成方案前逐条检查。三层保障缺一不可。这也正是 spec-kit 设计 Constitutional Gates 的原因——单靠文件存在不够必须把检查变成流程节点。Q6要不要直接用 spec-kitspec-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。宪法里不能写跳过安全审查之类的条款。不能替代用户明确指令。如果用户在会话中明确要求这次先不写测试快速出个 demoAI 应该遵循用户指令而不是用宪法条款强行阻断。constitution.md 约束的是默认行为模式不是绝对锁死。不能保证 100% 执行。AI 模型对 constitution.md 的遵循程度取决于模型能力、上下文窗口、文件位置等多个因素。实测中放在项目根目录的 constitution.md 配合 CLAUDE.md 中的显式提醒遵循率较高但偶尔仍会有遗漏。这也是为什么需要合宪性审查作为流程节点来兜底。七、从 Coding Rule 到 AI Engineering Governanceconstitution.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 工作流规范、技术栈要求、架构约束、治理机制等模块方括号标注了需要按项目填充的位置。模板使用建议裁剪删掉你的项目不需要的条款。用 Go 的项目删掉 MyBatis 相关内容不用微服务的项目删掉微服务条款填充把方括号[...]里的内容替换为你项目的实际选择。每一条都要具体到框架名称和版本号。例如 Go 项目填 1.2 时写Web 服务使用net/http而不是 Gin 或 Echo而不是笼统地写优先使用标准库补充在每条原则下补充你项目的反面案例。反面案例越具体AI 的理解越准确测试写完后让 AI 生成一个新功能观察它是否遵循了宪法的规则。如果没有检查条款是否足够明确迭代使用两周后回顾删掉没起作用的条款补充新发现的问题需要本文模板源文件的朋友关注公众号后发送constitution-template即可获取。参考来源Andrej Karpathy 推文原文https://x.com/karpathy/status/2015883857489522876Karpathy 在 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-kitGitHub 旗下开源的规范驱动开发SDD工具包核心概念constitution.md宪法 Constitutional Gates宪法门禁 SDD 工作流clarify → specify → plan → tasks → implementconstitution.md 存放路径.specify/memory/constitution.md写在最后constitution.md 的本质不是限制 AI 的能力而是给 AI 的能力装上方向盘。AI 生成代码的问题从来不是不够智能而是太智能了但方向不对。它会自动帮你加抽象、加配置、加灵活性每一个都出于好意但加在一起就把一个简单功能变成了一个难以维护的工程。Karpathy 在推文里说得很清楚模型会代你做错误假设会堆砌抽象会改动无关代码。spec-kit 的解法是把约束变成文件、把文件变成流程节点、把流程节点变成门禁。两者结合就是 constitution.md 的完整实践。一份好的宪法就是告诉 AI哪些事你必须做测试先行、安全第一哪些事你不能做过度抽象、硬编码密钥哪些事你可以自己判断其他一切。把规矩立在前面比在代码审查时一个个挑毛病高效得多。