企业官网建设流程全解析

团队协作篇：Spec Kit 的 constitution 怎么写，才能让五个程序员和一个 Agent 不吵架

【免费下载链接】spec-kit💫 Toolkit to help you get started with SDD or any other process!项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit

在引入 AI 编码助手之前，团队里最大的协作成本是"人跟人的理解偏差"：同一个需求，前端、后端、测试各自有一套默认假设，代码评审时互相觉得对方"没常识"。引入 Agent 之后，这个问题的烈度直接翻倍——Agent 没有团队记忆，它把"常识"理解成你 prompt 里碰巧提到的内容，于是五个程序员和一个 Agent 的六套默认假设一起上线，规格与实现脱节成为常态。

Spec Kit 给出的解法很特别：在写任何一行需求之前，先让团队写一份constitution（宪法）。它不是 README 里那种"我们重视代码质量"的装饰性愿景，而是一份会被后续每个环节运行时读取、逐条校验的机器可读约束。本文基于 Spec Kit 仓库的真实源码，拆解 constitution 的结构、写法要点，以及不同成熟度团队的配置差异，帮助你把这个"六方吵架"的源头，变成一纸提前签好的契约。

一场预先签好的"开发契约"：constitution 的结构

Spec Kit 把 constitution 定位为"项目级指导原则"，它存放在.specify/memory/constitution.md，由/speckit-constitution命令创建或更新（见 核心命令说明）。每个后续步骤——specify、plan、tasks、implement、analyze——都会以它为准绳做评估，这一点在官方文档中写得很直白："Establishes the project's guiding principles, which every later step is evaluated against."（快速入门）。

基础模板（templates/constitution-template.md）给出了清晰的骨架，任何团队都可以照此填充：

# [PROJECT_NAME] Constitution ## Core Principles ### [PRINCIPLE_1_NAME] <!-- 例：I. Library-First --> [PRINCIPLE_1_DESCRIPTION] ### [PRINCIPLE_2_NAME] <!-- 例：II. CLI Interface --> [PRINCIPLE_2_DESCRIPTION] ## [SECTION_2_NAME] <!-- 例：Additional Constraints, Security Requirements... --> [SECTION_2_CONTENT] ## Governance [GOVERNANCE_RULES] **Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]

这个结构本身就在传递治理理念：原则（Principles）负责"为什么"，附加约束（Additional Constraints）负责"必须怎样"，Governance 负责"改规则要按什么流程"，最后一行版本号让每一次规则变更都有迹可循。换句话说，constitution 不是一份静态文档，而是一个有版本、有修订流程的"活的法律"。

怎么写：把"常识"变成"硬约束"的五个要点

模板只是骨架，真正决定团队能否"不吵架"的是填充进去的内容质量。结合仓库中的命令实现（templates/commands/constitution.md），有五个要点值得专门说。

第一，只写"已经为真"或"团队已明确同意"的规则，禁止为了填空而发明标准。这是官方文档里最尖锐的提醒："Do not invent standards merely to fill the constitution template. The constitution governs later planning and analysis, so unrealistic rules create noise instead of useful constraints."（在既有项目中落地 Spec Kit）。空泛的"代码要优雅"写在宪法里，Agent 无法执行，人也会选择性忽略；而"每次数据库迁移必须包含回滚方案"这种规则，plan 阶段就能被当做一个真实的 gate 来校验。constitution 是后续所有决策的输入，写一条无法验证的规则，就是给后续每个环节埋一条噪音。

第二，规则必须声明式、可测试，把"should"替换成 MUST/SHOULD 并说明理由。命令实现中的 Validation 步骤明确要求："Principles are declarative, testable, and free of vague language"，并强制校验原则是否可以用事实判定。快速入门里给了教科书式的例子（docs/quickstart.md）：

/speckit-constitution Taskify is a "Security-First" application. All user inputs must be validated. We use a microservices architecture. Code must be fully documented.

每条都能被机器理解："Security-First"是定位，"所有用户输入必须校验"是可判定的硬性约束，"微服务架构"直接约束了 plan 阶段的技术选型范围。这就是 Agent 能听懂的"常识"。

第三，原则数量要克制，允许按需增减，但每一条都要有明确的非协商属性。命令实现特别说明：用户可能只需要比模板更少或更多的原则，模板允许自由增减，但每个 Principle 段落必须包含"简洁的名称 + 捕获非协商规则的内容 + 必要时说明理由"（见 templates/commands/constitution.md 的 Outline 步骤 3）。五条以内、每条一句话能说清"违反会怎样"的原则，远比二十条抽象原则有效。

第四，用语义化版本管理 constitution 本身。命令实现把版本升级规则写得非常具体：MAJOR 对应向后不兼容的治理变更（删除/重定义原则），MINOR 对应新增原则或大幅扩充指引，PATCH 对应澄清措辞（见 templates/commands/constitution.md）。日期统一 ISO 格式（Ratified记录最初采纳日，Last Amended记录本次修订日）。这意味着"改规则"本身是一个受控动作——任何对原则的修改都会留下版本轨迹，评审时一眼就能看出这次改动的分量。

第五，constitution 命令有明确的 Scope Guard，防止越权。命令实现中规定了严格的工作边界：它只负责更新 constitution 本身，绝不顺手实现功能、生成代码或修改应用文件；如果用户输入里混入了"顺便把登录模块写了"这类非治理意图，必须提取为Next Actions延迟处理（见 templates/commands/constitution.md 的 Scope Guard 一节）。这条边界对团队协作至关重要——constitution 的维护权和功能开发权被刻意分离，避免"改规则的人顺手改了代码"这种治理失守。

面向团队协作的规格设计技巧：让宪法真正"管辖"后续环节

写好 constitution 只是第一步。它要被后续环节真正执行，才谈得上约束五个人和一个 Agent 的行为。仓库里有三个机制值得深挖。

机制一：plan 阶段的 Constitution Check 硬门禁。在 templates/plan-template.md 中，Constitution Check 被设计为一个显式的质量闸门：

## Constitution Check *GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.* [Gates determined based on constitution file]

关键细节是：模板默认保留运行时指针[Gates determined based on constitution file]，即/plan每次运行时实时读取 constitution 生成门禁，而不是把门禁文字冻结在模板里。这意味着修改宪法后，plan 阶段的校验自动跟随，不存在"宪法改了但模板没同步"的漂移。只有当你明确希望把门禁作为可评审的提交内容时，才把具体 gate 文字固化下来（这正是下面要说的 constitution-sync preset 的取舍场景）。

机制二：把"规格如何老化"写进宪法。Spec Kit 刻意不给团队规定spec.md/plan.md/tasks.md的维护策略，而是提供三种模型：Flow-back（任意工件先改、再整体对账，适合快速迭代的小团队）、Flow-forward（每个 feature 目录作为不可变历史记录，适合审计导向）、Living spec（spec.md是唯一契约，下游工件派生自它，适合规格即契约的团队）。官方文档明确建议："Once those answers are clear, document the convention in your project constitution"（规格持久化模型）。这是非常典型的团队协作决策——"改需求时先改哪个文件"如果不在宪法里写明，五个人会各自按自己习惯改，Agent 更是无从判断，规格与实现的脱节就从这里开始。

机制三：用 preset 分层实现组织级治理。单份宪法解决的是单项目内的规则一致；多团队、多仓库的组织级一致性，靠的是 Spec Kit 的 preset 解析栈。解析优先级从高到低为：项目本地覆盖 → 已安装 preset（按 priority 排序）→ 已安装 extension → 核心模板（presets 参考）。一个组织可以维护自己的合规 preset（比如compliance设 priority 5、team-workflow设 priority 10），统一压到所有仓库，而每个仓库仍可保留本地覆盖层。constitution 模板同样参与这个栈——这意味着组织可以统一"宪法的写法"，而项目可以差异化"宪法的内容"，两者互不打架。

从创业团队到质量优先团队：配置差异怎么选

constitution 的内容和配套 preset 的组合方式，直接反映了团队的成熟度定位。仓库自带的 presets 恰好给出了从极简到严格的连续谱系。

创业团队 / 快速验证阶段：lean preset。presets/lean 的定位是"Minimal core workflow commands - just the prompt, just the artifact"，它只保留 specify → plan → tasks → implement → constitution 五个命令，constitution 命令的实现也极简：创建/更新.specify/memory/constitution.md，只要求"项目名、指导原则、非协商规则"，从用户输入和现有仓库上下文推导（见 presets/lean/commands/speckit.constitution.md）。这个阶段宪法不必面面俱到，三到五条"先为真"的硬约束即可，重点是让 Agent 有一个稳定的行为基线。

质量优先 / 生产级团队：完整路径 + 质量闸门。快速入门给出了两套路径：短路径（specify → plan → tasks → implement → converge）适合小功能；完整路径则额外加入/speckit-clarify、/speckit-checklist、/speckit-analyze三个质量闸门——clarify 在规划前消解歧义，checklist 生成"需求质量清单"逐条确认规格完整一致，analyze 在实现前跨spec.md/plan.md/tasks.md做一致性检查（docs/quickstart.md）。这时的宪法可以写得更厚：技术栈约束、合规标准、部署策略、评审流程都可以作为 Additional Constraints 落进来。

一个必须理解的取舍：constitution-sync preset。仓库里有一个值得单独说明的预设 presets/constitution-sync——它是可选安装的，用于"把宪法内容物化进 plan/spec/tasks 模板和命令文件"。它的 README 把代价写得非常诚实：物化副本可能漂移（改了宪法但没重跑/constitution就不同步）；对由 preset/extension 管理的组合文件的手工编辑会在下次栈对账时被覆盖；预填的 Constitution Check 还可能让/plan锚定在冻结文本上。默认的运行时解析模型才是官方推荐：实时宪法是唯一事实来源，什么都不用同步，也就什么都不会漂移。所以这个 preset 只适合"把物化模板当可评审提交物"的团队，对绝大多数项目，保持模板里的运行时指针[Gates determined based on constitution file]是更稳的选择。

多项目 / 微前端等复杂结构：按目录隔离宪法。在 monorepo 中，Spec Kit 项目是目录作用域的——apps/web/.specify/、apps/api/.specify/各自有独立的 constitution 和 feature 编号，命令解析优先最近的.specify/（monorepo 指南）。这意味着一套仓库里可以有多个"宪法辖区"，各团队在自己辖区内自治，跨项目交互则用契约驱动开发来定义接口协议。配合SPECIFY_INIT_DIR环境变量，CI 或 Agent 可以在不cd的情况下精确锁定目标项目，从机制上杜绝"写错项目"的误操作。

把吵架变成对齐：constitution 的本质是降低沟通带宽

回到开头的问题：五个程序员和一个 Agent 为什么吵架？因为六个人对"应该怎样"有六套默认假设，而 prompt 只能传递当下这一次对话的意图，传不了团队的长期约定。constitution 解决的不是某个具体 bug，而是把团队积累的规则沉淀为可持续复用的治理资产——它有版本、有修订流程、被 plan 阶段实时校验、被 preset 栈分层治理。Spec Kit 自己也这么用：在其 agentic 开发流程中，团队对 bundler 这类重要功能先用宪法约束、再走 SDD 全流程，而确定性测试和发布仍由常规 GitHub Actions 把关（Agentic SDLC 指南），这正是"人定规则、规则约束 Agent、Agent 产出由人评审"的闭环。

所以，constitution 写得好的标准不是"长"或"全"，而是每一条规则都能被机器判定、被评审复核、被版本追踪。当五个程序员和一个 Agent 都对着同一份"已为真的约束"工作时，分歧就从"互相猜默认值"变成了"对契约的明确解释"，而后者，是可以讨论、可以修订、可以仲裁的。这不就是团队协作该有的样子吗？

【免费下载链接】spec-kit💫 Toolkit to help you get started with SDD or any other process!项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit