核心摘要
规则文件是一种上下文交付机制，既不是通用标准，也不是安全边界。TRAE、Cursor、GitHub Copilot 暴露的制品格式和加载行为各不相同，而且会随版本、客户端和入口不断变化。要比较它们，就固定住确切的版本，搭一个最小的夹具仓库，测量针对典型任务时到底有哪些上下文抵达了模型。
规则文件适合承载经过评审的编码约定和任务提示；而授权、密钥、受保护分支、网络出口和部署审批，必须留在那些不依赖模型输出、能独立强制执行的系统里。
真正该比较的东西
以产品名开头的横评，往往在某个客户端一改指令格式或优先级时就立刻过时。请从你团队真正要完成的工作开始：
| 要问的问题 | 该收集的证据 |
|---|---|
| 制品是如何被发现的？ | 确切的客户端版本、文档链接或发布说明、夹具路径 |
| 它在什么时候被注入？ | 一份捕获到的任务记录，或宿主支持的调试视图 |
| 冲突时哪份制品胜出？ | 一个故意制造冲突的夹具，以及观察到的输出 |
| 哪些客户端会消费它？ | 客户端/版本矩阵，而不是"整个厂商都支持"的假设 |
| 它是否可能引发外部操作？ | 可信的工具权限与审批配置 |
| 如何安全地变更它？ | 代码评审、测试套件、回滚责任人和版本历史 |
把这些证据记录进一份小小的兼容性档案：
host: recorded-host
host_version: recorded-version
client_surface: recorded-client
artifact: repository-relative-path
claims_tested:
- discovery
- precedence
- path_scope
- manual_attachment
fixture_commit: recorded-commit
checked_at: recorded-time
owner: developer-experience
这样一来，一次宿主升级就成了显式的工程变更，而不是一次悄无声息的 Prompt 变更。
上下文不是策略
规则文本可能被忽略、被误解，也可能被不可信的仓库内容、工具结果和用户输入所影响。一条写着"禁止部署生产环境"的规则，并不能阻止模型去请求一次部署；一份限制了工具参数形状的 Schema，也证明不了调用者有权对它选中的那个对象采取行动。
请为这些关切使用一个独立的控制面：
| 层级 | 用途 | 由谁强制执行 |
|---|---|---|
| 上下文制品 | 编码约定、仓库地图、任务提示 | 宿主工具与模型行为 |
| 工具契约 | 参数形状、结果上限、错误语义 | 工具实现本身 |
| 身份与授权 | 谁能读、写、部署哪个对象 | 可信后端 |
| 副作用策略 | 确认、幂等、配额、审批 | 可信工作流服务 |
| 运行时隔离 | 文件、网络、进程、密钥隔离 | 沙箱与平台控制 |
不要把凭据放进指令文件里。不要信任模型给出的仓库、租户、角色或审批状态。一处代码改动，仍然需要评审、测试和正常的交付控制。
标准化之前，先搭一个夹具
建立一个由开发效能团队负责的最小仓库。它应当可以随时丢弃，且不含任何真实密钥或生产连接。
至少测试这几种情况：
- 一份仓库全局制品，和一份更具体的制品，声明了互相矛盾的约定。
- 分别编辑一个位于宣称作用域内、和一个位于作用域外的文件。
- 从对话、内联编辑、代码评审，以及你团队用到的任何自动化入口发起同一个任务。
- README、Issue、夹具或工具结果里，有不可信文本要求 Agent 忽略既有指令。
- 某个操作需要访问受保护资源，或需要一次明确的确认。
- 宿主工具被升级、被禁用，或降级切换到另一个客户端。
验收标准不是"模型照做了一次"。在宿主支持时捕获实际生效的上下文，检查它提出的补丁，跑一遍确定性检查，并记录失败。要把模型的遵从视为概率性的；不变量要靠构建和策略控制来保证。
一套可移植的制品模型
把源头指引独立维护，不依附于任何厂商的目录布局。只有在验证过目标版本之后，才去生成或手工维护那层薄薄的宿主适配层。
context/
shared/
repository-map.md
coding-conventions.md
testing-expectations.md
host-adapters/
recorded-host-a.md
recorded-host-b.md
fixtures/
precedence/
injection/
每份源制品都应标明它的责任人、目标受众、作用域、评审日期和证据。要短到让一个评审者能一眼看出矛盾。按有边界的关注点拆分，而不是按固定的行数规则拆分。
<!-- owner: platform-team -->
<!-- scope: server/api -->
<!-- reviewed: recorded-date -->
# API 变更契约
- 在服务边界校验不可信输入。
- 通过仓库既有的错误契约返回错误。
- 为改动过的授权行为增加一个聚焦的测试。
- 不在返回给客户端的响应里暴露密钥或内部诊断信息。
宿主适配层可以描述这份制品是如何被附加进去的，但它绝不能悄悄变成唯一的事实来源。
不发明排名，也能比较宿主
用同一张矩阵评估每个候选：
| 维度 | 测试 |
|---|---|
| 发现机制 | 一份已提交进仓库的制品，能在所有必需的入口被发现吗？ |
| 作用域 | 观察到的上下文，是否符合预期的文件与任务边界？ |
| 优先级 | 冲突是否可解释，并且有回归测试兜底？ |
| 可移植性 | 共享指引能否脱离某一个宿主依然可读？ |
| 可观测性 | 维护者能否诊断出某条指引为何生效、或为何没生效？ |
| 治理 | 归属、评审、回滚和升级检查是否清晰？ |
| 安全 | 工具权限和外部副作用，是否在 Prompt 之外强制执行？ |
| 可及性 | 必要的贡献者能否用他们支持的工具检查和编辑这套流程？ |
只有当 TRAE、Cursor、Copilot 各自已记录在案的客户端行为满足这张矩阵时，它们才算合格的候选。不要把某个路径、某个 Frontmatter 字段或某项宣传中的能力，想当然地当成能跨所有客户端、跨未来版本通用。
迁移与回滚
把迁移当作一次受控变更来做：
- 盘点当前的制品、消费方、责任人，以及未记录在案的本地覆盖。
- 把文本分类为共享约定、宿主适配层、敏感配置或可信策略。
- 把共享约定挪进经过评审的源制品里；移除其中的密钥和授权声明。
- 在夹具仓库里，一次只实现一个宿主适配层。
- 跑一遍有代表性的编码、评审、测试和失败场景。
- 先小范围灰度给一个小团队，配上问题反馈渠道和明确的回滚路径。
- 监控补丁质量、测试失败、覆盖被触发的频率和用户反馈，而不是去编造生产力数字。
在替代方案通过约定好的夹具用例之前，先保留旧的适配层。一次回滚，应当只移除或禁用适配层，而不删除共享指引，也不改动可信的访问控制。
Prompt 注入与隐私测试
任何文件、检索到的文档、Issue、依赖元数据或工具结果，都可能包含对抗性文本。一份上下文制品可以告诉模型"把这类材料当作数据"，但宿主还必须把工具权限和网络访问约束住。
测试一份不可信文档不能做到以下几点：
- 改变已选中的仓库或租户；
- 扩大工具权限，或泄露某个密钥；
- 触发对任意 URL 的远程抓取；
- 绕过写入、支付或部署所需的确认；
- 未经评审就持久化新的指令。
对遥测做脱敏和最小化。尽可能只存引用、哈希、策略决策和有边界的摘录；不要把完整 Prompt、私有源码或凭据当作默认的日志载荷。
运营检查表
- [ ] 在兼容性档案里固定住宿主、扩展和客户端的版本。
- [ ] 维护经过评审的源头指引，并有清晰的责任人和作用域。
- [ ] 在夹具里测试发现机制、优先级、作用域和降级行为。
- [ ] 把密钥处理和授权，留在模型可读的指令之外。
- [ ] 对副作用强制执行确认、幂等、配额和审计事件。
- [ ] 要求走正常的代码评审、测试和受保护的交付控制。
- [ ] 宿主升级后重新验证，一旦观察到回归就回滚。
总结
真正有用的问题，不是哪个品牌的规则格式"最好"，而是某个具体的宿主版本，能否向你团队所用的客户端可预测地交付经过评审的上下文，同时让可信系统继续强制执行安全与交付策略。把规则文件当作版本化的上下文契约，用夹具证明它的行为，并始终让模型引导与授权分离。