不只写业务代码：把 AI 用在那些"周边工程"上

一、被忽略的大头

一提"AI 辅助编程"，大家想到的往往是写业务代码。可真到了工作日你会发现，写业务代码可能只占其中一小部分。

剩下的大量时间，花在这些地方：写运维脚本、清洗数据、调一条正则、改 CI 配置、拼一段 SQL、维护构建与部署脚本、写格式转换的胶水代码……

这些"周边工程"有个共同点：琐碎、易错、没人爱写，却又非写不可。 它们不产出功能，却实打实吃掉时间——而它们，恰恰是 AI 最容易被忽略、也最擅长接管的领域。

二、AI 在这些场景里，特别"香"

1. 一次性脚本。
批量改文件名、遍历目录做替换、把一堆日志汇总统计——这类脚本写完就扔，几乎不考虑长期维护。这是个罕见地适合"放手让它写"的场景：一次生成就够，不必纠结优雅。（注意，这是"代打"划算的少数情况——判断标准很简单：用完就丢。）

2. 正则与 DSL。
正则难写、更难读。让它生成，再让它用自然语言解释一遍，最后用几个测试样例验证——比你自己对着符号猜到眼花高效得多。

3. 配置类文件。
CI 流水线、构建配置、容器编排、部署清单——样板多、语法记不住、差一个缩进就报错。让它帮你填，但记得拿官方 schema 或文档校验，别信"看起来对"。

4. SQL 与数据查询。
让它起草查询很省事。但要清醒地知道：它不懂你的真实数据分布和索引情况。 涉及性能的，拿执行计划说话，而不是靠它"感觉"。

5. 胶水代码。
格式转换、字段映射、API 适配——这类"中间件"逻辑机械、易错，交给它正合适。

三、这类场景的独特规则和坑

和写业务代码不同，周边工程有一套自己的讲究：

• 先分清"一次性"还是"长期"。 用完即弃的脚本，尽管让它一次性生成；要长期用的，仍然要按可维护的标准来——该有的结构、注释、边界，一样不能少。
• 副作用是第一风险。 业务代码写错了顶多报个 bug，而脚本常常直接动文件、改数据、碰生产。动错一处，后果可能是不可逆的。
• 安全边界要绷紧。 这类脚本最容易顺手硬编码密钥、连接串；处理真实数据时，脱敏、最小权限、别把敏感信息写进日志。
• 精确性 > 优雅。 它经常是"错一次的代价很大"（删了文件、改错数据）。所以宁可啰嗦，也要加保护。

四、几条能立刻用上的做法

• 让它先讲计划，再动手。 尤其破坏性操作，先看它"打算做什么"，确认方向对了再执行。
• 要求幂等 + dry-run。 能重复安全执行、能先预览影响范围，才敢放它碰真实数据。
• 小步试，再全量。 先在一个文件、一个小范围上验证，跑对了再铺开。
• 关键动作，人手按下确认键。 删除、迁移、生产变更这类不可逆操作，最后那一下就留给自己。

五、几条边界

• 不是所有周边都能交给它。 涉及生产数据、权限变更、合规判定的，按安全红线来——宁可自己来。
• 一次性脚本别过度工程。 用完就丢的东西，不值得为"优雅"多花时间。
• 版本与环境差异，永远要人确认。 命令在 A 系统能跑、在 B 系统报错；正则在这个引擎匹配、换个引擎就不认——这些它常常想当然。

六、结语

写业务代码只是开发工作的一部分，剩下那些"脏活累活"——脚本、配置、数据、正则——恰恰是 AI 回报最高的地方，却最容易被我们忽略。

与其逼着它多写一个功能，不如把这些琐碎的周边交给它。它不嫌枯燥、不怕样板；你省下的，是那些被一点点磨掉的耐心。真正的效率提升，常常藏在这些没人愿意干的角落里。