【我用 Trae 半年，总结出 6 条让 AI 稳定输出的协作经验，附codex&trae的agents.md】

我用 Trae 半年，总结出 6 条让 AI 稳定输出的协作经验

真正让 AI 编程助手稳定的，不是某一句神奇 prompt，而是你给它足够清楚的上下文、长期规则和验收标准。

前言

这篇文章记录我总结的 6 条经验，以及我最终沉淀下来的两个全局规则文件——分别给 Trae 和 Codex 使用。文章末尾可以直接复制使用。

第六条最重要，但先说结论

先把我认为最重要的一条放在最前面：

不要完全相信它说"完成了"。

Trae或者其他同类型AI编程工具 很擅长说"我已经完成了"，但实际上可能漏掉了验证步骤、改了不该改的文件、或者只是改了表面逻辑但没跑通。

所以我每次任务收尾都会要求它输出一个总结：

请最后给我：
1. 修改了哪些文件
2. 每个文件为什么改
3. 运行了哪些验证
4. 还有哪些没验证
5. 哪些地方需要我人工确认

这个动作很小，但极大减少了"我以为它跑通了，结果没跑通"的情况。

第一条：别一上来就让它写代码

很多人打开 Trae 第一件事就是让它写代码。这在简单任务上没问题，但在论文复现、陌生 repo、课程项目这种场景下，几乎必翻车。

原因很简单：Trae 一开始就带着错误假设开干，后面越改越复杂，最后你要么重来，要么花更多时间 debug。

正确做法是先让它读项目：

先不要修改代码。请先阅读这个项目，告诉我：
1. 项目结构是什么
2. 主要入口在哪里
3. 训练/测试/运行命令分别是什么
4. 哪些文件最可能和当前任务有关
5. 你不确定的地方有哪些

这一步看起来慢，其实很省时间。它能帮你快速理解项目骨架，同时让 Trae 建立正确的上下文，避免后续修改基于错误假设。

第二条：规则文件不要写成项目介绍

Trae 使用 .trae/rules/ 目录下的 .md 文件来注入全局指令。很多人把这些规则文件写成了项目说明书——项目是做什么的、用了什么技术栈。但这其实没什么用。

规则文件更适合写"长期行为规则"，而不是"这次我要你做什么"。

我现在的 Trae 规则文件长这样（精简版）：

## 工作规则
- 默认先阅读相关代码和文档，再开始修改。
- 修改前先说明影响范围。
- 只做和当前任务相关的最小改动。
- 提交前必须运行最小验证。
- 说明用中文，代码、命令、文件名保持英文。
- 不要修改无关文件。

## 实验原则（研究类项目）
实验必须服务于明确假设或决策。
不要为了补齐表格而穷举低价值 ablation。
如果一个方向已经明显无效，先总结证据，再询问是否继续。

复现论文时：先阅读论文和官方 repo，输出核心 idea、
关键公式/模块、一致性、复现最小路径、可能风险点。
确认后再动手。

这个文件的核心作用是约束 Trae 的行为模式，让它在每次任务中默认遵循正确的协作流程。

特别想强调"实验原则"这一条。Trae 有时候会特别喜欢"把实验补完整"，但很多实验只是看起来完整，实际没有信息增益。如果你不做约束，它可能花很多 token 跑一堆没用的 ablation。

第三条：复杂任务一定先 Plan

只要任务超过一个文件，我一定让它先出计划。

先不要写代码。请进入计划模式，帮我设计实现方案：
1. 明确这次要解决的问题
2. 列出会影响哪些模块
3. 拆成 3-7 个步骤
4. 每一步怎么验证
5. 哪些地方最容易出错

等我确认后再开始实现。

这样做的最大好处是：你能提前发现它有没有理解错需求。

很多时候 Trae 写代码前的计划比代码本身更有价值。计划能暴露它对任务的理解偏差，而你只需要花 30 秒扫一眼，就能避免它花 10 分钟写一堆错代码。

确认计划后，再让它小步实现，每步跑验证。这个节奏非常稳。

第四条：研究任务要让它先查证，不要凭印象说

Trae 的知识截止日期是固定的，它"知道"很多论文和开源项目，但它"知道"的内容可能是过时的、错误的、或者混淆了多个版本。

做研究任务时，永远不要让它凭印象直接回答。

比如复现一篇论文，不要直接说"帮我复现"，更好的方式是：

请先阅读论文和官方 repo，不要开始写代码。先输出：
1. 论文核心 idea
2. 关键公式/模块
3. 官方实现和论文描述是否一致
4. 复现最小路径
5. 可能复现不出来的风险点

Trae 很适合做这种"读论文 + 看 repo + 整理实现路径"的工作。前提是你要明确告诉它：先读，先对齐，先列风险，再动手。

第五条：做完一个任务就开新会话

长会话很容易积累"旧假设"。

尤其是一个功能改完以后，继续在同一个上下文里做新功能，Trae 可能会带着上一个任务的判断继续思考。你以为它是基于当前上下文做的判断，实际上它被上一个任务的推理污染了。

我的习惯是：

1. 任务收尾时让它输出一句话总结
2. 开启新会话
3. 在新会话里贴上总结
4. 再开始下一个任务

这个动作很小，但明显减少了"旧问题污染新任务"的情况。

沉淀：两个可以直接使用的规则文件

基于以上 6 条经验，我沉淀了两个全局规则文件，分别给 Trae 和 Codex 使用。放进每个新项目的根目录就能生效。

Trae 版本：.trae/rules/project-workflow.md

这是我日常使用 Trae 时挂载的规则文件，放在项目的 .trae/rules/ 目录下即可自动生效。

# 项目协作工作流规则

## 核心原则
你是项目协作者，不是单纯的代码生成器。
所有操作遵循：先理解 → 再计划 → 确认范围 → 小步实现 → 验证 → 总结。

## 一、任务启动：先读再动
收到任何代码任务时，默认第一步是阅读和理解，不要立即修改代码。
执行前先输出：项目结构、主入口、运行命令、相关文件、不确定的地方。
只有当用户明确要求跳过阅读时，才可以省略此步骤。

## 二、复杂任务必须先出计划
如果任务涉及多个文件或模块，必须先进入计划模式。
输出：问题定义、影响模块、3-7个步骤、验证方式、风险点。
等待用户确认计划后，再开始逐步实现。

## 三、修改原则
- 修改前先说明影响范围
- 只做和当前任务相关的最小改动
- 不要修改无关文件
- 提交前必须运行最小验证
- 说明用中文，代码、命令、文件名保持英文

## 四、实验与复现原则
实验必须服务于明确假设或决策。
不要为了补齐表格而穷举低价值 ablation。
如果一个方向已经明显无效，先总结证据，再询问是否继续。
复现论文时：先阅读论文和官方 repo，输出核心 idea、
关键公式/模块、一致性、复现最小路径、风险点。确认后再动手。

## 五、任务收尾
每完成一个任务，输出总结：
修改文件清单、改动原因、已验证项、未验证项、需人工确认项。

## 六、会话管理
任务收尾后用一句话总结任务、文件、状态和下一步。
建议新会话中粘贴此总结，避免旧假设污染新任务。

Codex 版本：AGENTS.md

如果你同时使用 Codex CLI，这个文件放在项目根目录，Codex 会自动读取。

# AGENTS.md

## 工作规则
- 默认先阅读相关代码和文档，再开始修改。
- 修改前先说明影响范围。
- 只做和当前任务相关的最小改动。
- 提交前必须运行最小验证。
- 说明用中文，代码、命令、文件名保持英文。
- 不要修改无关文件。

## 任务流程
1. **先读再动**：收到任务后，先阅读项目结构、入口文件、
   运行命令、相关文件，说明不确定的地方。
2. **复杂任务先计划**：涉及多个文件时，先输出实现计划
   （问题定义、影响模块、步骤拆解、验证方式、风险点），
   等确认后再实现。
3. **小步验证**：每步完成后跑最小验证，确认通过再继续。
4. **收尾总结**：任务完成后输出修改文件清单、改动原因、
   已验证项、未验证项、需人工确认项。

## 实验原则（研究类项目）
实验必须服务于明确假设或决策。
不要为了补齐表格而穷举低价值 ablation。
如果一个方向已经明显无效，先总结证据，再询问是否继续。
复现论文时：先阅读论文和官方 repo，输出核心 idea、
关键公式/模块、一致性、复现最小路径、可能风险点。
确认后再动手。

## 会话管理
每次完成任务后，用一句话总结：刚完成的任务、修改过的文件、
当前状态和下一步注意事项。
建议在新会话中粘贴此总结，再开始下一个任务。

最后

总结一下我的核心认知：

真正让 Trae 稳定的，不是某一句神奇 prompt，而是你给它足够清楚的上下文、长期规则和验收标准。

这 6 条经验帮我从"被 Trae 带偏"变成了"让 Trae 按我的节奏走"。同样的方法论也适用于 Codex——核心逻辑是一致的，只是规则文件的挂载方式不同。

如果你也在用 AI 编程助手做研究或工程，希望这些经验对你有帮助。

欢迎在评论区分享你自己的 AI 协作经验。

参考博文：我用 Codex 做研究后，总结出 6 条有用经验！

标签：AI 编程、Trae、Codex、工作流、研究效率