Vibe Coding 共享仓库指令：让所有人和 Agent 遵守同一层级规则

同一个仓库，开发者 A 的个人 Prompt 写着“不要本地运行 Docker”，开发者 B 只在群聊里见过，CI 没有这条规则，新 Agent 也从未收到。直到某次任务真的启动了错误环境，团队才发现所谓“大家都知道”只是局部上下文。Vibe Coding 要让规则跟着代码范围走，而不是跟着某个账号或会话走。

共享仓库指令不是团队文化的替代品，也不是把所有工程文档塞进一个超长 Prompt。它只保存开始任务时必须知道、违反后会造成错误或风险、且能判断适用范围的执行事实。不同产品支持的文件名、加载方式和优先级并不完全相同；AGENTS.md 提供开放约定，GitHub Copilot 也有自己的 repository custom instructions。团队应明确一个规范来源和必要适配层，不能假设任意工具都会自动读懂同一文件。

根指令回答全仓不变量

仓库根部的指令保持短而稳定，至少包含：

• 项目与主要目录的职责，不复制完整架构文档；
• 依赖管理、格式化、测试和构建的真实入口；
• 允许与禁止的环境、网络、容器和外部服务操作；
• 生成文件、迁移、秘密和数据的所有权边界；
• Git 与发布权限，例如是否允许建分支、commit、push 或部署；
• 遇到脏工作树、规则冲突和无法验证时的升级动作。

把命令写成可复制的准确形式，并注明工作目录和前置条件。“运行测试”不如“在仓库根执行 pnpm test; 需要数据库的集成测试另行授权”。“不要改无关文件”应进一步引用脏工作树安全改码的状态和所有权规则。指令中绝不保存 token、生产地址凭证或个人绝对路径。

子目录只覆盖真正局部的差异

Monorepo 中，前端、移动端、迁移和基础设施可能需要不同命令与风险边界。把局部规则放在对应子树，说明它继承什么、覆盖什么。优先级必须按团队选用的工具真实行为验证；如果两种 Agent 的解析规则不同，适配文件应指向同一规范片段，或在 CI 中生成并检查一致性，不能维护几份独立手写副本。

出现冲突时采取 fail closed：更具体规则与根规则矛盾、用户请求越过仓库禁令、文档和脚本给出不同命令，都先停止并展示冲突来源。用户可以对当前任务作明确授权，但要记录范围和期限；临时许可不能静默改写长期仓库政策。人类与 AI 角色边界决定谁有资格批准例外。

一个实用结构是：

Scope: 本文件覆盖 packages/web/**
Use: pnpm --filter web test
Do not: 启动共享后端、修改 prisma/**、读取真实用户数据
Generated: src/api/** 由 pnpm api:generate 产生，不直接编辑
Before done: lint + unit + 指定 viewport 人工检查
Escalate when: 合同漂移、生成器不可达、工作树归属未知

这些句子必须指向真实存在的脚本和路径。路径改名、包管理器切换或远端工作流变化时，指令与代码在同一 PR 更新。仅改文案也要 reviewer 判断是否扩大 Agent 权限；“提高效率”不是删除禁止项的充分理由。

把自然语言规则接到确定性门禁

能自动检查的部分不要只靠模型记忆：锁定包管理器、禁止秘密、生成产物一致性、格式范围和必要状态检查都可进入脚本或 CI。自然语言负责解释为什么、何时停和谁决定，确定性工具负责重复执行。这样 Agent 漏读一条规则时，门禁仍能阻断；门禁失败时，指令又能告诉它不要自行降级测试。

任务开始协议固定为：从工作目录向上读取适用指令，列出实际命中的层级，核对脚本存在，复述允许写集、禁止动作和验证门，再进入 plan。陌生仓库冷启动负责其余代码探索，任务上下文包承载本次需求；仓库指令只提供跨任务稳定约束。

用冷启动测试指令是否真的共享

选择一个不熟悉项目的开发者和两个不同工具，给出同一低风险任务，不补口头提示。观察它们能否找到正确目录、选择正确命令、避开禁区，并在制造一个规则冲突后主动停下。失败若来自工具根本不加载该格式，应修适配或启动脚本，不能继续声称“仓库已有规则”。

每次复盘只把可复用且稳定的发现升级为指令；一次性任务状态进入跨会话重启摘要，设计理由进入 ADR 或规格，操作细节进入 runbook。定期删除已由工具强制或已失效的重复文字，保留变更原因。

共享指令的完成标准不是文件存在，而是任何获准参与者进入某个目录后，都能得到相同的硬边界、命令入口和升级条件。它让 Vibe Coding 从“依赖谁记得提醒 Agent”变成仓库自身可检查的协作接口。