这是一个虚构但很典型的案例：小吴是一位负责服务器、发布流水线、监控告警和故障处理的运维或 SRE，最近手头在忙“完成两台数据库服务器的磁盘扩容”，同时还要准备“推进日志集中采集”。这次小吴需要整理一份给技术负责人的变更方案，决定试试 IDE 中的 AI 编程协作。

背景

对小吴来说，告警多、脚本杂、变更文档和故障复盘写起来费时，夜间排障时更需要快速理清思路。偏偏这次还遇到一个变数：机房网络计划维护，可能影响夜间批处理任务。变更方案需要尽快交给技术负责人，时间并不宽裕。

第一次尝试：问题出在哪

小吴一开始只写了一句话：

帮我写一份关于“把发布流程迁移到容器化部署”的变更方案。

结果 AI 给出的内容四平八稳却用不上。复盘下来，主要有两个问题：

  • 不看就接受生成的代码。
  • 跳过测试直接提交。

改进后的提示词

小吴按照 AI 编程助手的思路重写了提示词，核心是在任务开始前说明目标、约束和相关文件：

背景：我们的项目是把发布流程迁移到容器化部署相关的服务，使用[语言/框架]。
任务：在[文件路径]中新增一个函数，实现[功能描述]。
约束：
- 遵循项目现有的命名和错误处理方式；
- 不引入新的第三方依赖；
- 输入为空或格式错误时返回明确的错误信息。
请先说明你的实现思路和需要修改的文件，等我确认后再写代码，并附上对应的单元测试。

结果（示意）

下面的效果为虚构演示，用来说明这类改进通常带来的变化：

示例（虚构）：一位后端开发让编程助手为一个旧模块补充参数校验。助手先列出需要修改的三个函数和校验规则，确认后生成代码和测试。运行测试时有一个用例失败，助手分析出是旧代码对空字符串的处理不一致，开发者决定保留旧行为并调整了测试。

拿到结果后，小吴没有直接转发，而是先检查关键事实和数字，再补上 AI 不知道的背景。

复盘：这次用到的方法

  • 让 AI 先给出修改计划，确认后再生成代码。
  • 逐段审阅生成的代码，理解每一处修改。
  • 运行测试和代码检查工具，确认没有引入问题。
  • 逐段审阅，理解每一处修改后再接受。

之后小吴发现，同样的方法也适用于另一类场景：重构、重命名、拆分函数等机械性修改。

复盘时小吴还想到一个问题：AI 改错了怎么办？答案是：使用版本控制，小步提交，出错时可以快速回滚。

给运维工程师的提醒

让 AI 写的命令先在测试环境执行，并要求它说明每个参数的作用。涉及删除、重启、改权限的命令，必须先确认影响范围并做好回滚准备，不能照抄执行。另外，对话里不要出现服务器 IP、账号口令、证书私钥和内部拓扑。

一个额外的小技巧：出错时把完整报错和相关代码一起提供，定位更快。

如果你也是运维工程师

可以先从“处理 2 起磁盘告警和 1 起证书过期隐患”或“清理无主的云资源”这样的小任务开始练习 AI 编程助手，熟练之后再用到变更方案这类更正式的材料上。每次记录一下哪句提示词最管用，慢慢就有了自己的模板。

相关阅读