Trae 企业落地 · 规范与资产沉淀实施手册
系列第四篇。 第三篇的七层能力栈里，L4「规范与资产沉淀」只占了一行；六阶段落地法里，「阶段 3」也只有一段。这一篇把那一行拆开，写成一套能照着建仓库、能进 CI、能被审计的机制。
这是一份实施方案，不是产品评测。涉及产品机制的部分已按官方文档核实，目录规范、字段模板、流程门禁与指标则是本手册的设计建议，落地前请按你们实际安装的版本验证一遍。
总纲一句话：凡是不能被版本化、不能被验证、不能被追溯的，都不算组织资产。
一、先破三个错觉：为什么"提交了配置"不等于"统一了规范"
大多数团队的资产沉淀止步于「建了个 .trae/ 目录，提交到 Git，发群公告」。三个月后发现每个人跑出来的东西还是不一样。问题不在执行力，在三个没被说破的机制事实。
错觉 1：把 .trae/rules 提交 Git，就等于团队强制统一
Git 解决的是分发，不是生效。
TRAE 官方中文社区的 Rules FAQ 给出的优先级链是：
用户输入 > 自定义 Agent Prompt > user_rules.md > project_rules.md
也就是说，个人规则压过项目规则。同一份 FAQ 还写明：当前版本暂不支持规则间的逻辑冲突自动检测；规则总量有上限（约 20000 byte，超出时 project_rules 会被先裁剪），建议单条规则不超过 10000 字符；规则遵循度受模型上下文窗口影响，长对话里会下降，建议以任务维度拆分对话、一次对话只做 1–2 件事。官方文档的最佳实践里也直说「各条规则之间不得彼此冲突或相互覆盖」，并建议新建或修改规则后开启全新对话，避免历史上下文与新规则打架。
这里还存在一处官方口径与第三方教程不一致：部分教程称项目规则优先、不会被个人偏好覆盖，与官方 FAQ 的链条相反。两者不能同时成立。合理的处理不是选一边信，而是以你实际安装版本的行为为准，并用可复现的探针去验证（见 3.3）。
结论：靠"共享文件"宣告统一是脆弱的。本地覆盖文件（
settings.local.json）、个人全局规则、自定义 Agent Prompt、以及用户在对话里的一句话，都可能盖过项目基线。企业侧能做的是减少可覆盖的面 + 加验证，而不是假装覆盖不存在。
错觉 2：规则写得越全，AI 越懂业务
官方对 Rules 与 Skills 的加载机制有明确区分：
| 机制 | 加载方式 | 官方给出的理由 |
|---|---|---|
| Rules | 对话开始即全量注入，持续占用上下文窗口 | —— |
| Skills | 先扫描各技能的简短描述，判定相关才按需加载详细内容 | 降低上下文 token 消耗、避免无关信息干扰决策 |
再加上 FAQ 的裁剪与长度限制，结论很直接：Rules 是稀缺的常驻内存，不是知识库。 把领域文档、接口说明、历史方案整篇粘进 project_rules.md，结果是常驻上下文被撑爆、超长时先被裁掉的恰好是项目规则、长对话里规则遵循度下降、且冲突无人告警。
错觉 3：MCP 配置好就能随仓库共享
项目级 MCP 有三个容易被跳过的前提：
- 默认不生效：需要在设置里手动打开「项目级 MCP」开关，
.trae/mcp.json才会被加载； - 官方安全警告：原文要求"确保工作区内所有项目文件均为可信来源，避免加载恶意配置文件导致出现安全风险"——这本质是一条供应链信任边界，不是配置提示；
- 凭证风险：官方配置示例里的
env.API_Key、headers.Authorization: Bearer ...是直接写在 JSON 中的，第三方接入指南也都提醒不要把真实凭证提交进版本库。
另外，MCP 与命令都有本地/云端运行环境之分，桌面端与网页端适用的任务不同。同一个配置文件，在不同客户端里可能根本不加载。
结论：MCP 不是"配置文件"，是一次权限授予。它该走注册表、白名单、最小权限和凭证分离，不能当普通文本资产进 Git 就完事。
二、资产分层：先定"什么该进基线"
第三篇的 L0–L7 是能力栈（工具 → 治理 → 平台）；本节用 A0–A4 表示资产分层，两者不要混淆。分层解决的是"谁有权改、改了影响谁、能保留多久"。
| 层 | 内容 | 变更频率 | Owner | 存放位置 | 生效方式 | 是否长期留存 |
|---|---|---|---|---|---|---|
| A0 组织基线 | 安全红线、语言/框架白名单、禁用依赖、日志脱敏、PR 必填项、AI 参与声明规则 | 极低 | 平台工程组 + 安全合规 | ai-assets/baseline/ | Always Apply 规则 | 是，全历史 |
| A1 领域知识 | 术语表、领域模型、接口契约、ADR、runbook | 中 | 领域 Owner | ai-assets/domains/<domain>/ | Skills + MCP 检索 | 是，带复审期 |
| A2 项目契约 | 技术栈版本、分层约束、构建/测试命令、分支策略、门禁映射 | 中高 | 项目 Owner | 仓库内 .trae/ + docs/ | globs 规则 + Commands | 随项目生命周期 |
| A3 能力包 | Rules / Skills / Commands / MCP 四件套的可复用组合，如 java-springboot@1.2.0 | 版本化 | 平台工程组 | ai-assets/packs/ | 按 scope 继承 + override | 是，保留版本 |
| A4 会话与临时产物 | 会话记录、临时 diff、试跑结果、面板视图 | 极高 | 个人 | 本地 | 不进基线 | 否，但索引必须留 |
三条判据：
- 越靠上越稳定、越需要多人评审；越靠下越易变、越不该全局强制。
- A0 不允许项目覆盖，只能提案；A1/A2 允许 override，但必须在注册表登记理由。
- A4 不进基线，但 A4 的索引要长期留存——这是第五节"产物可回看"的接入口，也是很多团队丢历史的地方。
三、四件套：统一 Rules / Skills / Commands / MCP
3.1 一张表定分工
一句口诀：Rules 定边界，Skills 定做法，Commands 定入口，MCP 定能力。
| 机制 | 官方加载方式 | 该放什么 | 不该放什么 | 位置与约束 |
|---|---|---|---|---|
| Rules | 全量注入、常驻上下文；项目规则支持四种生效模式：Always Apply / 指定文件(globs) / 智能判断(description) / 手动(@Rule) | 硬性红线、"去哪查知识"的指针、输出格式底线 | 业务文档、长篇领域知识、历史方案 | 项目 .trae/rules/（支持最多 3 层子目录，可在子模块放专属规则）；国内版全局 ~/.trae-cn/user_rules；文件名用小写字母、数字、连字符 |
| Skills | 按需加载，靠 description 判定相关性 | 领域 SOP、标准流程、输出模板、检查清单 | 一次性 prompt、需要人主动喊的动作 | .trae/skills/<name>/SKILL.md（必填 name / description）；可带 examples/、templates/、resources/ |
| Commands | 用户输入 /xxx 主动触发 | 高频固定动作：审查、补测试、生成提交信息、迁移套路 | AI 应自行判断时机的能力 | .trae/commands/，最多 3 层目录嵌套，全局命令在 ~/.trae-cn/commands；团队统一用小写字母、数字、短横线命名；内置 plan、spec 等规划类命令，各客户端略有差异 |
| MCP | 提供可调用工具，不描述流程 | 只读优先的外部连接：代码仓库、缺陷系统、内部知识库、CI 状态 | 真实凭证、无边界的写权限 | .trae/mcp.json，需开启项目级 MCP 开关；stdio 用 command/args/env，HTTP 用 url/headers；支持 ${workspaceFolder} |
一个容易混的点：Skills 和 Commands 的区别是"谁来决定触发"——你敲 /review 它才动，是命令；AI 判断"这次任务跟代码审查相关"自动加载，是技能。选择标准很清晰：想每次手动喊一声的做成命令，希望它自己判断时机的做成技能。
另一个点是官方文档自己给出的分界：Skills 描述"怎么完成任务"，MCP 提供"能调用什么工具"。所以「用 Playwright 做页面测试」里，MCP 给的是浏览器操作能力，Skill 定义的是测试目录结构、POM 约定和执行流程——两者必须成对沉淀，只搬一半就会失效。
3.2 单一事实源：ai-assets 仓库
不要在每个项目里各写一份。建一个独立仓库作为唯一事实源，再由脚本/包管理同步到各项目 .trae/（手工复制是版本漂移的主要来源）。
ai-assets/
├── README.md # 使用说明、分发命令、升级指引
├── catalog.yaml # 资产注册表（关键）
├── OWNERS # 各层审批人
├── CHANGELOG.md # 版本与破坏性变更记录
├── baseline/ # A0
│ ├── rules/
│ │ └── security-redlines.md
│ └── policies/
│ └── pr-template.md
├── domains/ # A1
│ └── payment/
│ ├── glossary.md
│ ├── domain-model.md
│ ├── contracts/ # OpenAPI / Proto
│ ├── adr/ # 0007-refund-idempotency.md
│ └── runbook/
├── packs/ # A3
│ └── java-springboot/
│ ├── pack.yaml # version / scope / owner / deps
│ ├── rules/
│ ├── skills/
│ │ └── code-review/SKILL.md
│ ├── commands/
│ │ └── review.md
│ └── mcp.template.json # 仅连接描述，绝不写凭证
├── projects/ # A2 override 登记
│ └── order-service/override.yaml
└── probes/ # 规则/知识探针用例（见 3.3、4.3）
catalog.yaml 是整套机制的中枢，也是将来换平台时的迁移清单：
- id: rules.security-redlines
kind: rule
version: 1.3.0
scope: org # org | domain | project | personal
owner: platform-security
source: baseline/rules/security-redlines.md
applies: always # always | globs | intelligent | manual
review_by: 2027-02-01
status: active # active | deprecated | stale
checksum: sha256:<...>
- id: skill.payment-refund-check
kind: skill
version: 2.0.1
scope: domain
domain: payment
owner: payment-arch
source: domains/payment/skills/refund-check/SKILL.md
requires: [rules.security-redlines@>=1.2.0, mcp.internal-kb@1.x]
knowledge_refs: [domains/payment/glossary.md, domains/payment/adr/0007-*]
review_by: 2027-01-15
status: active
字段的设计意图：owner 让资产有人负责，review_by 让过期可被自动发现，requires 让依赖关系可解析，checksum 让"项目里跑的是不是基线那一版"可被机器校验，scope 决定谁能覆盖谁。
3.3 分发 ≠ 生效：用"探针"补上最后一公里
因为第一节那三个错觉，建议把验证做成 CI 里的硬检查，而不是靠培训提醒。
静态门禁（每次提交 ai-assets 时跑）
catalog.yaml必填字段齐全、id唯一、owner在OWNERS中、无过期未复审的active条目- Rules 文件名合规、单条不超长、Always Apply 的条目总数设上限（防止常驻上下文膨胀）
- 每个
SKILL.md含name/description/When to use/Instructions；description不得出现"用于开发相关任务"这类无判别力描述 mcp.template.json扫描：无API_Key/Bearer/token/ 私钥字面量，凭证一律用环境变量占位符- 项目侧
.trae/声明的 pack 版本与catalog.yaml一致；不一致即报"版本漂移"
运行期探针（每周/每次基线升级后跑）
- 规则探针：用一个空白仓库、一句固定 prompt 生成一小段代码（例如带
await的函数），断言红线是否生效（是否中文注释、是否try-catch、是否禁用某依赖）。这类"让规则真正触发一次"的写法在社区实践里有不少可照抄的例子。 - 知识探针：从
domains/抽一批领域问题，要求 Agent 只用资产库作答并标注出处，人工判分；答错时修知识条目，而不是改提示词。 - 两类探针结果进看板。规则悄悄失效这件事，没有探针是发现不了的——官方 FAQ 自己就列了"为什么有的时候 Rules 不会被遵循"这一问。
禁止项清单（写进 README.md，并尽量用门禁拦住）：个人私改 A0、凭证进仓库、把长文档塞进 Rules、命令名用大写或下划线、手工复制 .trae/ 目录、在本地覆盖文件里改团队基线。
四、领域知识结构化：四类知识，三层消费
"把业务文档丢进知识库让 AI 自己查"通常不管用。原因是知识没有分类、没有粒度、没有 owner，检索命中了也不知道该信哪一版。
4.1 四类知识，各自有格式与更新触发
| 类型 | 回答什么 | 推荐格式 | 粒度 | 更新触发 | 主要消费方式 |
|---|---|---|---|---|---|
| 术语与概念 | "退款单"在本领域到底指什么 | 表格：term / 定义 / 别名 / 反例 / 来源 | 一个术语一条 | 需求或接口变更 | Skills 注入 + 检索 |
| 结构与契约 | 系统由什么组成、怎么调 | OpenAPI / Proto / ER 图 / 分层约束 | 一个限界上下文 | 契约变更、版本升级 | globs 规则 + MCP 检索 |
| 决策与取舍 | 为什么当初这么定 | ADR：背景 / 选项 / 决定 / 后果 / 状态 | 一个决策一篇 | 架构评审 | Spec 前置引用、Commands |
| 运行与故障 | 出事怎么办 | 步骤式 runbook + 检查项 | 一个故障场景 | 复盘之后 | 事故处置 Skill |
每条知识都带同样的元数据头，让"过期"成为可查询状态：
---
knowledge_id: KB-PAY-0042
title: 退款幂等键的生成规则
domain: payment
type: contract # glossary | contract | adr | runbook
owner: payment-arch
source: https://<内部需求系统>/<id>
last_reviewed: 2026-10-12
review_by: 2027-01-12
status: active # active | superseded | stale
supersedes: KB-PAY-0019
---
status: stale 不是删掉，而是在检索结果里降权并告警——历史决策被误当成现行约束，比查不到更危险。
4.2 三层消费纪律（最关键的一条）
硬约束 ──────────► Rules 只写「必须 / 禁止」+「去哪查」的指针
做法与流程 ──────► Skills 写「怎么查、按什么步骤、输出什么格式」
运行时事实 ──────► MCP 检索 知识库 / 仓库 / 缺陷系统的当前状态
反模式：把领域知识整篇粘进 project_rules.md。 依据第一节：Rules 全量注入、有长度上限、超长先裁项目规则、无冲突检测、长对话遵循度下降。正确做法是 Rules 里只留一句"涉及支付域术语与契约时，先查 domains/payment/，不得凭常识补全"，把内容放在 A1，由 Skill 定义查阅流程、由 MCP 提供检索通道。
检索还有两条必须写进 Skill 的兜底：
- 结果带出处：每个回答标注引用的
knowledge_id，无出处不得作为决策依据； - 未命中就明说：查不到时输出"资产库未覆盖，需人工确认"，禁止用通用常识填充。这是防止"看起来很专业但其实是编的"的唯一有效约束。
4.3 知识也要有测试
glossary 里每个术语配一个反例（容易被误用的近似概念），反例直接变成知识探针的测试用例。每季度跑一次抽样问答，命中率下降就说明是知识结构或 description 出了问题，而不是模型不行。
这一条和 3.3 的规则探针合起来，是本手册最想强调的工程化观点：资产不是写完就沉淀了，资产要像代码一样有测试。 一份没人验证过是否生效的 Rules，和一份没跑过测试的源代码，风险性质是一样的。
五、产物可回看：五环链路与元数据
5.1 先定义"可回看"到底要能回答什么
一次 AI 参与的变更，半年后出事，你要能回答：谁、在什么上下文、按哪一版规范、生成了什么、经谁审、进了哪次提交、后来上线还是回滚了。 答不全，就不叫可回看。
5.2 五环链路
| 环节 | 必留字段 | 载体 | 保留期 | 责任人 |
|---|---|---|---|---|
| ① 意图与计划 | 目标、约束、验收标准、引用的 pack 版本、关联 ADR 编号 | docs/specs/<date>-<topic>.md（Spec / Plan 先落盘，再动代码） | 长期 | 项目 Owner |
| ② 会话过程 | session_id、时间、操作者、模型、装载的 rules/pack 版本、输入摘要 | 会话导出 + 索引表（session ↔ spec ↔ commit） | 中期，索引长期 | 平台工程组 |
| ③ 产物 | 见 5.3 的 front matter | Git 中的文档 / 脚本 / 配置 / 代码 | 长期 | 开发者 |
| ④ 评审与合并 | spec 链接、AI 参与程度、人工审查结论、审查人、验证方式 | PR / MR 模板 | 长期 | Reviewer |
| ⑤ 发布与反馈 | 是否上线、是否回滚、关联缺陷 | 发布系统 / CI 记录 | 长期 | 发布负责人 |
第三篇第六节已经写过"所有 AI 产物必须进 Git、工具内的『我的产物』只当临时视图"。这里补的是串链方式：光有文件还不够，得有能把 ①→⑤ 串起来的键，那就是 spec + session_id + commit。
5.3 产物头部元数据模板
---
artifact_id: ART-2026-1108-003
spec: docs/specs/2026-1108-payment-refund.md
session_id: sess-9f2c1a
generated_by: agent # human | assisted | agent
asset_pack: java-springboot@1.2.0
rules_version: org-baseline@1.3.0
knowledge_refs:
- domains/payment/glossary.md#refund-order
- domains/payment/adr/0007-refund-idempotency.md
reviewer: <name>
review_result: approved-with-changes # approved | approved-with-changes | rejected
commit: <sha>
---
元数据不是形式主义，它是回看索引：出问题时能反查"这次生成当时挂的是哪版红线、引用了哪条后来被废弃的 ADR"。缺字段的 PR，CI 可以直接拒绝合并。
5.4 PR 模板与门禁
## 变更摘要
## 关联的 Spec / 需求 （必填，链接到 docs/specs/）
## AI 参与程度 （无 / 辅助补全 / 主体生成 / 全自动，必填）
## 使用的能力包与版本 （须存在于 catalog.yaml）
## 人工审查结论与审查人 （关键路径要求双人）
## 验证方式与结果 （命令、结果、失败路径）
第三篇阶段 2 已把"AI 生成代码视同开发者本人提交、责任归属写进制度"列为治理前置条件；这套模板就是那条制度的技术落点。门禁检查项：spec 链接可访问、pack 版本在注册表、front matter 必填齐全、AI 参与程度非空、关键路径双人审。
5.5 会话的正确定位：它不是审计依据
必须说破一件事：会话 memory 重建是有损的，而官方 FAQ 也指出长对话里规则遵循度会下降、建议按任务拆分对话。两件事叠起来意味着——
可回看的主体是落盘的 Spec、产物与 PR，不是聊天记录。 会话只承担"过程索引"和争议复盘。
归档策略：会话定期导出 → 抽取 session_id ↔ spec ↔ commit 生成索引 → 原始会话按保留期清理，索引长期保留。把"能回放聊天记录"当成可回看，是最常见的自欺：记录很长、上下文断了、当时的规范版本也无从查证。
六、治理闭环：所有权、版本、发布、度量
6.1 RACI（谁负责什么）
| 事项 | 平台工程组 | 领域 Owner | 项目 Owner | 开发者 | 安全合规 |
|---|---|---|---|---|---|
| A0 基线制定/变更 | R/A | C | C | I | A |
| A1 领域知识 | C | R/A | C | I | I |
| A3 能力包发布 | R/A | C | C | I | C |
| A2 项目 override | C | C | R/A | I | I |
| 产物元数据与 PR 填写 | C（定模板） | I | C | R | I |
| 探针用例与看板 | R/A | C | C | I | C |
| 凭证与 MCP 白名单 | R | I | C | I | A |
6.2 版本与发布流程
- 语义化版本：A0/A3 用
MAJOR.MINOR.PATCH；破坏性变更（如删除一条红线、改 Skill 的输出契约）必须升 MAJOR，并设双跑期（新旧两版并行、探针同时验证）。 - 六步流程：提案 → 影响面评估（列出依赖该资产的项目）→ 三方评审（平台 + 领域 + 安全）→ 1–2 个灰度项目试点 → 探针验证通过 → 发布 + 写 CHANGELOG + 通知拉取。
- 禁止"修改即生效"：
catalog.yaml里status与checksum是唯一生效凭据，本地改文件不算发布。 - 季度复审：清
stale、合并重复规则、下线低命中 Skills、更新review_by。
6.3 度量：关注资产本身是否健康
第三篇阶段 5 已经给了一组工程结果指标（采纳率、一次通过率、缺陷密度、评审返工率、周期时间、Token 成本）。本节补的是资产健康度指标，两者配合才能知道"规范到底有没有在跑"：
| 指标 | 算法 | 健康信号 | 数据来源 |
|---|---|---|---|
| 资产覆盖率 | 已纳管项目 / 在用项目 | 持续上升 | catalog.yaml + 项目声明 |
| 版本漂移率 | .trae 声明版本 ≠ catalog 最新版的项目占比 | 趋近 0 | CI 门禁 |
| 规则探针通过率 | 通过断言的用例 / 总用例 | 基线升级后不下降 | 探针看板 |
| 知识探针命中率 | 答对且带出处的题 / 总题 | 稳定或上升 | 季度抽检 |
| Spec 落盘率 | 关联 spec 的 AI 参与 PR / 全部 AI 参与 PR | 趋近 100% | PR 模板字段 |
| 溯源完整率 | front matter + PR 必填字段齐全的 PR 占比 | 趋近 100% | CI 门禁 |
| Stale 知识占比 | 超 review_by 未复审条目 / 总条目 | 季度复审后归零 | catalog.yaml |
| 资产复用度 | 被 ≥2 个项目引用的 pack / 全部 pack | 识别"人人都建自己的" | requires 依赖图 |
这些指标用于内部趋势观察，阈值请用自己首月的基线来定，不必对照外部数字。
七、六阶段落地路线（L4 子路线，对齐第三篇阶段 3）
| 阶段 | 目标 | 产出 | 退出条件 |
|---|---|---|---|
| 1 · 盘点 | 找齐散落资产 | 个人规则、常用 prompt、在用的 MCP、已有业务文档清单；标出重复与冲突 | 清单有 Owner、有来源 |
| 2 · 立基线 | 只定不可让步的红线 | baseline/ A0 最小集（建议 10 条以内）+ 第一版规则探针 | 探针在干净环境通过 |
| 3 · 建仓与注册表 | 建立单一事实源 | ai-assets 仓库、catalog.yaml、OWNERS、CI 静态门禁 | 两个项目能从仓库同步并校验版本 |
| 4 · 领域结构化 | 跑通一个领域 | 选 1 个高频领域，四类知识各出 1 篇 + 1 个能力包 + 知识探针 | 探针命中且回答带出处 |
| 5 · 闭环 | 打通五环链路 | Spec 前置、front matter、PR 模板、会话归档索引 | 能完整回溯一次真实变更（①→⑤ 全有） |
| 6 · 运营 | 变成常态机制 | 探针看板、季度复审、灰度发布、版本升级流程 | 连续两个季度无未处理 stale |
最重要的一条建议：不要一上来做全量知识库。 先用一个领域、一个项目，把"探针能过 + 能完整回溯一次变更"跑通，再复制到其他领域。全量铺开而验证没跟上，结果是得到一座没人敢信的文档坟场。
八、反模式清单
| # | 反模式 | 症状 | 后果 | 修正 |
|---|---|---|---|---|
| 1 | Wiki 规范直接粘进 Rules | project_rules.md 几千行 | 上下文膨胀、被裁剪、遵循度下降 | Rules 只留红线 + 指针，内容移 A1 |
| 2 | 提交 Git 就宣告统一 | 各人产出仍不一致 | 个人规则/本地覆盖/手动开关绕过基线 | 加合规探针与版本漂移门禁 |
| 3 | 凭证写进 .trae/mcp.json | 配置能跑就提交了 | 凭证随仓库扩散、轮换困难 | mcp.template.json + 环境变量占位 + CI 扫描 |
| 4 | Skill 的 description 写"用于开发相关任务" | 永不触发或到处乱触发 | 按需加载机制失效 | 写清触发场景与不适用场景 |
| 5 | 每个团队自建 pack | 五六个功能近似的技能包 | 版本漂移、无人维护 | 统一注册表 + scope 与 requires |
| 6 | 拿会话记录当审计依据 | "聊天记录里写清楚了" | memory 有损、上下文断、规范版本不可考 | 以 Spec / 产物 / PR 为准，会话只留索引 |
| 7 | 领域知识无 owner / 无 review_by | 半年后没人敢删 | 过期决策被当现行约束 | 强制元数据头 + stale 降权 + 季度复审 |
| 8 | 只建不测 | 规则悄悄失效无人发现 | 治理形同虚设 | 规则探针 + 知识探针进 CI/看板 |
九、可携带性：换工具时，什么还在？
作为长期做 AI 工具资产迁移的视角，收尾只留一个判断标准：
如果明天换掉这个 IDE，哪些东西还在？留下来的才叫资产。
| 层 | 迁移时的表现 | 设计对策 |
|---|---|---|
| 必然留下 | Spec、ADR、领域知识、产物文件、PR 记录 | 纯 Markdown / YAML / OpenAPI，全部进 Git，不依赖任何 IDE 私有格式 |
| 需要适配 | Rules / Skills / Commands | 同为纯文本，但语法、目录、加载优先级随平台变化；catalog.yaml 让它们可按注册表重放，而不是重新发明 |
| 容易丢失 | 会话 memory、自动化任务、面板里的"我的产物"、Local/Cloud 运行环境差异 | 会话只归档不重建；自动化留"可重建清单"（触发条件、prompt、依赖、负责人） |
还有一条官方给出的便利值得用上：项目根目录的 AGENTS.md 是跨工具的通用规则规范，官方文档明确写明在 TRAE 中创建的 AGENTS.md 可被其他支持该规范的 IDE 复用，反之亦然。把 A0 基线同时落一份到根目录的 AGENTS.md，等于给组织红线加了一层原生可携带性——成本几乎为零，换工具时却最省事。
第三篇第六节的四条规范（产物进 Git、Rules/Skills 版本化、自动化留清单、会话定期导出）与迁移四原则（源端只读、写入前先备份、同名冲突保留原文件并告警、全程可回滚）依然适用。本篇只补一条：
catalog.yaml 就是迁移清单。 它记录了每个资产的 id、版本、owner、依赖与来源路径。换平台时按表重放即可；没有它，迁移就退化成"派几个人把散落在几十台机器上的配置重新敲一遍"。
规范不是写给 AI 看的文档，是组织把经验固定下来的方式。工具会换，界面会改，模式会合并——留下来的那套 Spec、契约、决策和验证方法，才是企业真正买到的东西。
数据来源声明
本文涉及产品机制的内容，依据 TRAE 官方文档站（docs.trae.cn、docs.trae.ai 的 Rules、Skills、Commands、MCP Server 等页面）与 TRAE 官方中文社区的规则 FAQ 核实；团队配置与工程实践部分参考了公开的第三方教程、社区分享与厂商接入指南；资产分层、注册表、探针、模板与指标属于本手册的设计建议，并结合本系列前作的方法论与迁移实践整理。
免责声明： 本文为技术实践分享，不构成产品评测结论、采购建议或效果承诺。TRAE 各产品线与地区版本在目录、命令和运行环境上存在差异，产品迭代较快，一切功能、参数、配置方式及涉及的数据均以官方公开资料与实际安装版本为准；文中规则优先级等存在不同公开口径的内容，落地前请自行实测确认。所有目录规范、字段模板、门禁与指标均为建议方案，请在测试环境验证后再用于生产，因照此实施产生的任何结果，作者不承担责任。
