TraeCode 知识库
TraeCode 区分 Rules、Skills 和 MCP：规则常驻对话上下文，Skill 在调用时按需加载，MCP 提供可调用工具。Busabase 保存这些指令背后的已审核材料与决策，不把工具接通当作知识可信。
缺失的一层
Skill 规定方法，MCP 提供工具
把测试标准写成 Skill 能减少重复说明，却不能保证每次结果都符合标准。先分清约定、工具和证据，才知道团队究竟在接受什么。
从提议到正式知识
让下一次任务从已接受的知识开始
读取适用的正式记录
先核对来源日期与适用范围，再把与任务有关的正式知识交给 Agent。
带证据提出更新
将新发现整理成字段级改动，附上来源、执行版本和未解决事项，提交 ChangeRequest。
审核具体差异
审核人检查改动与证据，要求修改、批准或拒绝。批准后再由有权限的角色合并。
复用已接受的结论
后续成员与 Agent 读取合并后的状态；主张有变化时提出新修订，保留历史。
值得沉淀的内容
记录“哪些页面通过了什么检查”，而不是“测试成功”
示例：桌面端两页通过，但手机端尚未执行。正式结论必须保留这个边界；不把一次工具调用成功扩写为整站验收完成。以下字段是建议设计。
范围与方法
发布提交、页面、视口和 Skill 修订；明确已覆盖与未覆盖检查。
执行证据
测试输出、截图或报告链接、运行时间与 MCP 工具信息。原始产物仍留在测试系统。
结果与例外
通过项、失败项、已接受例外及理由；无证据的检查标为待验收。
审核与更新
负责人、决定、后续任务和复测条件。新版本或标准改变时提出更新，而不沿用旧验收。
选择正确的知识层
Rule、Skill、工具与测试结论，各自有不同归属
把测试标准写成 Skill 能减少重复说明，却不能保证每次结果都符合标准。先分清约定、工具和证据，才知道团队究竟在接受什么。
| 知识层 | 最适合保存 | 可信依据 |
|---|---|---|
| Rules 与 Skills | 规则承载持续适用的行为指导，Skill 承载按需执行的方法。它们留在原配置或仓库中，版本化管理，不承担当前验收状态。 | Rules 与 Skills |
| MCP 与测试产物 | MCP 配置负责提供工具，测试报告负责说明发生了什么。工具返回成功不是测试范围完整，也不是缺陷已经关闭。 | MCP 与测试产物 |
| 已接受的测试结论 | Busabase 保存测试范围、例外与负责人，让下游成员查询哪些页面或版本已验收，而不用猜测一段聊天的最终状态。 | 审核人检查改动与证据，要求修改、批准或拒绝。批准后再由有权限的角色合并。 |
| Busabase | 示例：桌面端两页通过，但手机端尚未执行。正式结论必须保留这个边界；不把一次工具调用成功扩写为整站验收完成。以下字段是建议设计。 | 后续成员与 Agent 读取合并后的状态；主张有变化时提出新修订，保留历史。 |
适用性判断
多方复用验收结论时有价值，纯工具配置不需要再入库
适合共享审核
适合：测试结果被产品、工程和发布人员共同使用；标准变化需要追踪受影响范围；多名 Agent 的报告需要一项明确的最终决定。
用更简单的工具
不适合：只有一次本地测试、临时调试对话、完整 Skill 副本或 MCP 配置备份。若现有测试系统已管理验收状态，优先引用，不另造重复记录。
TraeCode 知识库 · 常见问题
Rule 与 Skill 的加载方式一样吗？
不一样。官方说明规则完整加载，Skill 在实际调用时按需加载。
MCP Server 会自动提供团队方法吗？
不会。MCP 提供工具，Skill 承载特定任务的指令和约定。
启用 Server 就等于认可返回数据吗？
不是。先核对工具访问和目标空间，再审核证据后接受记录改动。
修改 Skill 后，已通过的测试还有效吗？
检查改动是否影响原覆盖范围和验收标准。保留旧 Skill 版本与证据，对受影响范围安排复测并提出记录更新。
应把测试截图和报告全部复制到 Busabase 吗？
不需要。保留能定位原始产物的链接与必要结果。正式记录应能说明范围、证据和决定，不替代整个测试系统。
从一条经过审核的记录开始
让下一次任务读取有来源、有负责人的知识
先选择一个需要团队复用的结果，定义最小记录与审核人，再通过接入指南验证访问和提议权限。