技巧：大项目迭代，先沙箱后生产
说明： 项目越做越大后，我给 Agent 定了一条铁律：每次迭代升级，必须先在独立沙箱里完成开发和验证，生产代码全程只读；沙箱里调好的参数、装的临时依赖都不进生产，验证达标后才允许正式升级。这样 Agent 可以放开试错，实验代码永远污染不到稳定运行的系统，出问题直接删掉沙箱就行，回滚成本几乎为零。
下面把这套沙箱的完整搭法从零讲清楚，包含一份可以直接复制使用的规则提示词。
一、为什么大型 AI 项目需要沙箱？
用 TRAE 这类 AI IDE 写代码，最大的特点是快：一个需求下去，Agent 几分钟就能改完一串文件。但项目一旦变大，"快"就会带来新的风险：
-
Agent 一次实验性改动可能散落多个文件，想回退时找不全；
-
为某个场景临时调的参数，被顺手写进了全局配置，影响其他功能；
-
"装来试试看"的依赖进了依赖清单，之后没人敢删；
-
新方案还没验证可靠，就直接改了正在稳定运行的旧链路。
传统开发里我们用测试环境、Git 分支解决这些问题；而和 Agent 协作时，更省事的办法是把隔离纪律写成规则，让 Agent 每次自动遵守。规则只需要写一次，之后每一轮迭代它都按这个流程走。
二、第一步：建好两个目录
在项目根目录下建好沙箱目录，结构如下：
your-project/
├── src/ # 生产代码（沙箱期间只读，不许改）
├── temp/
│ ├── scripts/ # 沙箱：放实验脚本
│ └── test_output/ # 沙箱：放测试输出
└── .trae/
└── rules/
└── sandbox.md # 沙箱规则（Agent 自动加载，见第三步）
两个目录的分工：
-
temp/scripts/：所有实验性、一次性的脚本只能写在这里，不允许散进生产源码目录。 -
temp/test_output/：每次测试的产物（输出文件、日志、结果）放这里，每个测试单独建一个子目录，互不干扰。
生产代码和配置目录在沙箱验证期间是只读的——Agent 可以读、可以参考，但不能动。
三、第二步：把隔离规则"喂"给 Agent（完整提示词，可直接复制）
这是整套方法最关键的一步：不要靠口头叮嘱，要写成规则文件。
在 TRAE 中，把下面这段规则保存为项目里的 .trae/rules/sandbox.md，之后每次对话它都会自动生效；你也可以直接把这段内容粘贴到对话开头作为临时约定，效果相同。
# 沙箱测试隔离规则
## 核心原则
所有实验、测试、参数调试必须在沙箱中完成。验证通过之前，不得修改生产代码和配置。
## 目录隔离
1. 实验脚本只能放在 temp/scripts/，不得写入生产源码目录。
2. 测试输出只能放在 temp/test_output/，每个测试使用独立子目录。
3. 沙箱期间，生产代码和配置只读；需要参考时允许读取，禁止修改。
## 开发隔离
4. 验证新方案时，必须新建独立文件，通过参数的新分支值触发，不得改动正在运行的旧链路。
5. 沙箱中为特定场景调试的参数（阈值、容差、灵敏度等）不得回写生产配置，需记录在测试报告中。
6. 沙箱里安装的临时依赖，不写入依赖清单（requirements.txt / package.json 等）；确认长期使用后再补。
## 合并条件（同时满足才能升级生产）
- 沙箱验证达到事先约定的质量标准；
- 不破坏原有功能的任何链路；
- 在主入口的调度配置中注册新方案；
- 合并完成后，清理沙箱中的临时文件，只保留测试报告。
规则文件放好后，你可以随手问 Agent 一句"说下你对沙箱规则的理解"，确认它确实读到了，再开始干活。
四、第三步：日常迭代按这五步走
规则就位后，我每次迭代都是同一个闭环：
1. 提需求，定验收标准 开始前先说清楚这次迭代要解决什么问题、做到什么程度算达标。标准越具体，沙箱验收越好判断。
2. Agent 在沙箱里开发 实验逻辑写成 temp/scripts/ 下的独立脚本；新方案用参数的新分支值触发，老链路一行不动。临时要装的包先装，不进依赖清单。
3. 用真实场景验收 在沙箱里拿真实数据、真实任务跑，结果输出到 temp/test_output/，和现有方案逐项对比，形成一份简单的测试结论。
4. 达标后才升级生产 确认满足合并清单后，再让 Agent 把方案小步落地到生产目录，并在主入口注册。因为验证过、范围清楚，这一步风险很低。
5. 清理沙箱 删掉临时脚本和中间产物，只留测试报告。下一次迭代从一个干净的沙箱重新开始。
整个流程的精髓是：试错的代价被关在了 temp/ 目录里，而稳定系统始终是干净的。
五、最关键的一条：怎么保证规则次次都被落实？
很多人也定过类似规矩，但项目越做规则越乱、流程渐渐形同虚设。我们的沙箱能维持到现在，复盘下来靠的不是自觉，而是六个结构性设计。这部分是我最想分享的经验。
1. 规则"自动注入"，不靠任何人记住
规则必须放在每次对话都会自动加载的位置（TRAE 的 .trae/rules/ 目录），而不是写进普通文档等 Agent 想起来去翻。
我们在另一个项目里踩过这个坑：规则文件被标记成不自动注入，结果"写了等于没写"，十几份规矩里实际生效的没几份。所以定完规则后，做一次验证——让 Agent 复述一遍它理解的规则，确认内容真的进了上下文再开工。
2. 把"闸门"设在生产入口上，而不是事后提醒
沙箱能被精准触发，核心是有一道前置闸：任何对生产代码的改动，动手前必须先回答三个问题——
① 这是生产代码吗？② 用户是否已明确授权？③ 是不是应该先在沙箱验证？ 任何一个答案是"是"或"不确定"，立即停止，先进沙箱。
这道闸直接挡在"改生产"这个动作前面：新想法一来，想动稳定系统就会撞闸，然后被自然引导进沙箱。拦截发生在越界之前，而不是改坏之后再回滚——这是和"规则写在文档里提醒大家注意"最本质的区别。
3. 规则要"机械可执行"，不写道德口号
对比一下两种写法：
-
“注意隔离，小心不要污染生产环境”——Agent 每次理解都可能不一样； -
“实验脚本只能放在 temp/scripts/，新方案必须新建独立文件、用参数的新分支值触发”——路径、动作、条件都是确定的。
凡是给 Agent 的规矩，都要写到"照着做不需要二次判断"的程度。
4. 分层治理、明确优先级，委托子 Agent 也逃不掉
我们的规则分三层，各管一件事，不重复表述：
| 层级 | 管什么 |
|---|---|
| Agent 宪法 | 怎么想：编码前的推理闸、禁止补丁式开发、什么情况必须停下来问 |
| 项目规则 | 怎么做：沙箱目录、隔离条目、合并条件 |
| 用户规则 | 能不能做：没明确授权的改动一律先问 |
层与层之间写明优先级（宪法 > Agent 定义 > 业务规则 > 临时指令），规则冲突时按顺序裁决，而不是看哪份文档"看起来更新"。
还有一个容易漏的点：所有子 Agent 的定义文件里都显式写明"受 Agent 宪法约束"。这样即使把任务委托出去，沙箱纪律一样生效，不会出现"主窗口守规矩、子代理改生产"的漏洞。
5. 规则要有"退出机制"，否则一定越攒越乱
规则和代码一样需要生命周期。我们用四个状态管理每条重大规矩：提案 → 生效 → 否决 / 归档。
-
被否决的方案，保留否决原因，但退出当前规则集，不允许换个名字残留；
-
过时的规矩及时归档，不再占用每次对话的上下文；
-
新增条目前先查重，能改写老条目就不追加副本，禁止"更正："式的补丁条款。
这样项目虽然越来越大，但每次实际生效的规则集始终是小而一致的——规则不乱，靠的不是写得少，而是有进有出。
6. 每条铁律都带着"事故背景"
我们的硬规则几乎都是踩坑后立的，并且把背景直接写在规则开头：某次数据误删后立了文件操作纪律，某次越界改动后立了授权边界。
这不是为了记仇，而是让 Agent 理解为什么有这条规矩。只写做法，它只能机械匹配字面场景；带上事故背景，遇到没见过的新情况，它才能照着原则做出正确判断。
小结
一句话总结：规则的执行靠结构，不靠觉悟——自动注入解决"记不住"，生产入口的闸门解决"忍不住"，分层和退出机制解决"规则乱"。一次搭好，之后每一次迭代都自动走在正轨上。
六、几个新手常见疑问
Q1：小项目也需要这么做吗？ 只要你的项目里已经有"不想被改坏"的稳定代码，就值得。目录和规则十分钟就能建好，之后是零成本复用。
Q2：会不会拖慢开发效率？ 不会。规则只写一次，之后每轮自动生效；它省掉的是事后找改动、回退代码、排查"昨天还好好的今天为什么挂了"的救火时间。
Q3：发现 Agent 偷偷改了生产文件怎么办？ 立即让它撤回改动，并要求对照规则说明越界点。规则放在 .trae/rules/ 下自动加载，比每次口头提醒可靠得多。
Q4：和 Git 分支是什么关系？ 两者是互补的。Git 管的是版本历史和代码回退，沙箱规则管的是 Agent 的行为边界——让越界改动在发生之前就被拦住，而不是发生之后再回滚。
Q5：规则越攒越多怎么办？ 给规则设生命周期：新想法先进"提案"状态，生效后才进自动加载的规则集；被否决和过时的规则及时归档退出，新增前先查重、能合并老条目就不追加副本。规则只进不出，才是越攒越乱的根因。
大型 AI 项目迭代快、链路长，"先沙箱、后生产"这一步，我认为必不可少。规则一次写好，靠结构而不是靠自觉去执行，后面每一次升级都会安心很多。
