去年开始用 AI 辅助维护公司的企业 OA 后台系统（webman 框架 + workerman 常驻进程），这半年踩的坑比过去五年都多，但也把”怎么和 AI 在生产系统上安全协作”这件事彻底摸透了。

1. 最贵的一课：AI 擅自重启了生产服务

系统里有财务预警、考勤推送、WebSocket 实时消息这些常驻进程，全部挂在 workerman 里跑。有一次让 AI 改一个考勤接口，改完它自作主张执行了 php start.php restart -d：

结果：全公司在用 OA 的同事集体掉线，财务预警停了十几分钟。

后来我在项目里加了一条最高优先级规则，写进给 AI 的行为准则里：

## 行为准则（核心）
### 0. 不要擅自重启服务
除非用户明确要求，否则永远不要执行 php start.php restart -d。
- 服务运行在 Windows 服务器上，重启会中断所有正在运行的进程（财务预警、考勤、WebSocket 等）
- 代码修改后由用户自行决定何时重启

血的教训换来的经验：AI 没有”重启服务影响多大”的概念，它只管完成任务。凡是涉及生产环境的操作，权限必须收紧。

2. 给 AI 立规矩，比换更强的模型管用

那次事故之后，我在项目根目录写了专门的 AI 协作准则，核心四条：

1. 先思考再编码
   - 实施前明确陈述假设，不确定就问
   - 存在多种理解时全部列出，不要默默选一种
   - 有更简单的方案就说出来，该反对就反对
2. 简单优先
   - 不添加需求之外的功能
   - 不为只调用一次的代码创建抽象
   - 问自己：资深工程师会说过度设计了吗？
3. 精准修改
   - 只碰必须碰的，不顺手"优化"相邻代码
   - 不去重构没坏的东西
   - 每一行改动都能追溯到用户的请求
4. 目标驱动执行
   - "修 bug" → 先写能复现 bug 的测试，再让测试通过
   - 多步骤任务先给计划：步骤 → 验证项

立完规矩之后效果立竿见影：

• AI 不再顺手重构我看得懂的代码了；
• 改接口之前会先问”这里改法有两种，你要哪种”；
• 修 bug 前会先写测试复现，而不是瞎猜乱改。

心得就一句话：AI 在自由发挥时是天才，在需要克制时是灾难。行为准则就是它的刹车。

3. 常驻进程项目的特殊坑

普通 web 项目改了代码刷新就生效，常驻进程项目不是：

• 改了不重启=没改：AI 改完说”搞定”，实际跑的还是旧代码，因为它没重启，也没法自己验证；
• 缓存残留：think 框架的路由缓存、配置缓存，改完必须清，不然 AI 看到的现象和实际不一致；
• 多模块互相影响：项目里有 m_api（小程序）、api（Web）、admin（后台）、client_api（客户端），AI 经常把模块间公共方法改出问题，牵一发动全身。

我的处理方式：让 AI 改完代码只负责改，不负责生效。生效（重启、清缓存）永远由我手动做，这样出问题我能第一时间感知到是哪一步的问题。

4. 让 AI 读文档再动手

OA 项目文档挺全的（产品文档、BUG 修复流程、接口设计），但 AI 一开始根本不看，上来就猜。后来在行为准则里加了一条：动手前先读 docs 目录下的相关文档，并且让它引用文档里的结论而不是自己发挥。

比如让 AI 对接 apidoc 生成接口文档，先让它读 docs/apidoc 相关说明，再让它按项目已有的格式生成，出来的文档风格统一，不用我返工。

5. 给 AI 的”验收标准”要写清楚

弱需求害死人。说”把这个功能改一下”，AI 会按它理解的改，十有八九不是你要的。正确的提法：

❌ 修一下考勤导出的 bug
✅ 考勤导出在"跨月"时会报错，请先写一个复现该 bug 的测试，
   然后修复，最后跑通测试并给出验证步骤

把任务描述成”可验证的目标”，AI 才能自己循环推进，而不是改完问你”行不行”。

总结

用 AI 维护生产系统，最核心的不是它多能写代码，而是它多懂规矩。

开发系统时，AI 是你的手；生产系统上，AI 是实习生。手可以快，实习生必须守规矩。