团队协作篇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 projects 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 specspec.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考