AI 辅助编程的真实边界：我在哪些环节用它，哪些坚决不用

#背景

"AI 能不能替代程序员"是个讨论不出结果的问题。更有用的问题是：在当前能力下，哪些环节交给它，哪些必须自己来。

以下结论来自一个真实项目：一个零依赖 PHP 框架 + Vue 3 后台，约半年持续开发，AI 参与了绝大部分编码过程。

#收益最大的四类工作

#1. 脚手架与重复结构

CRUD 控制器、表单字段、迁移文件、后台列表页——这类代码形态固定、判断点少，AI 写得比人快且不容易漏字段。

关键是先给出规范：项目里有现成的相似实现，就贴给它作为模板。没有模板时它会"自由发挥"，风格立刻发散。

#2. 测试与边界用例

让 AI 写测试的正确姿势不是"给这段代码写测试"，而是：

这是我们的测试风格（贴 2 个用例），给 X 功能补上用例，重点覆盖：空输入、超长输入、权限不足、并发条件。

它很擅长列边界情况——比我更容易想到"没权限的用户会怎样"这类我下意识假设不会发生的情况。

#3. 正则、转换脚本、一次性工具

解析日志、批量改数据、格式转换。这些代码写完就丢，正确性靠"跑一遍看结果"验证，非常适合交给它。

#4. 文档与命名

把实现反向写成文档、给变量起名、把散落的注释整理成段落。这活人做得痛苦、AI 做得不错。

#必须自己写的四类

#1. 安全边界

鉴权、CSRF、CSP、密码策略、XSS 过滤——不能用"看起来对"的实现。AI 给的方案常常是"能跑但漏一处"：比如转义了 < 却没处理属性里的引号。

这类代码我自己写，然后让 AI 帮忙找漏洞（"这个转义还有哪些绕过方式"），而不是让它写。

#2. 数据一致性与事务

"下单扣库存"这种逻辑，AI 很容易写出先查再改的竞态版本。并发场景超出它的"常识范围"——除非你把并发条件明确写进提示词，而恰恰是"你没想到要写"的那些条件最危险。

#3. 性能关键路径

首页渲染、列表查询、循环里的查询——AI 倾向于"能实现就行"。要它给优化方案，得先把瓶颈数据（QPS、单页查询次数）喂给它。没有数据时它的建议多是泛泛而谈。

#4. 没人看得懂的实现

如果一段代码你读两遍还不确定为什么对，就不该合进去。"AI 写的"不是免责声明：线上出问题时，值班的是你，不是模型。

#协作流程

需求 → 我写清"输入/输出/边界/风格模板"
     → AI 出实现
     → 我逐行读，重点看：错误处理、边界、命名是否符合项目惯例
     → 跑测试与 lint（php vabora check / test）
     → 有测试覆盖不到的地方，补测试再合

三条硬规则：

1. 一次只让它改一处，改动越大越难看懂；
2. 不许"顺手重构"：让它改 A 就不要动 B，否则 review 成本爆炸；
3. 所有产出都要过 lint 与测试：本项目里 php vabora check（禁 @、禁弃用函数、语法检查）挡住了不少"看着漂亮"的代码。

#结果

• 编码速度大约提升 2~3 倍，主要体现在脚手架、测试与文档上；
• 更重要的变化是测试覆盖率上升：以前"来不及写测试"的部分现在有了；
• 缺陷分布没变好也没变坏——线上问题仍然集中在"边界与并发"，而这两块本来就该自己写。

#取舍

• 不用 AI 直接改数据库结构：迁移脚本我自己写，AI 只做语法检查；
• 不让 AI 提交代码：提交信息、分支、回滚决策是人负责的事；
• 不接受"重写成另一个风格"的建议：一致性比"更优雅"重要，混进两套风格后维护成本会指数上升。