先说结论
AI编程目前值得信任的程度，可以按一条线画分界：越贴近模型训练数据分布的部分，可信度越高；越贴近你仓库里局部约束的部分，可信度越低。到2026年，很多团队的日常从“要不要用AI写代码”变成了“AI写了，但该怎么验收”。如果还拿“能跑通demo”来定义“代码通过”，排障与代码维护会为这个判断买单。
主流AI编程工具能力分层与选型
需要先分清你用的是哪一层能力，否则“AI编程效果好不好”没法定标准：
| 工具形态 | 代表 | 工程上下文 | 典型风险 |
|---|---|---|---|
| 会话补全 | GitHub Copilot、通义灵码 | 当前打开的文件和光标附近 | 生成的代码贴着光标走，不熟悉项目远近约束 |
| AI原生编辑器 | Cursor | 已索引的整个工程目录 | 能编译，但对运行时约定理解不足 |
| 任务级代理 | GitHub Copilot Workspace 等按Issue工作的产品 | 仓库语义与Issue描述 | 模型会自行脑补缺失的业务步骤 |
横向对比时不要先比补全速度，先问三个更硬的问题：代码要离开内网吗？有没有人能把AI给的结果改得动？现有工程里哪些约束是写不进IDE索引的？第三个问题决定了你会踩什么样的坑。
真实项目中的“假通过”：编译过了、测试过了，不等于能合并
如果你拿一个公开的电商demo，把表结构一贴，AI可以生成一整套后台和前端，五六分钟内跑通。但当你把这套代码合入已有登录鉴权的单体服务，问题开始出现：session体系不一致、权限控制没有走统一入口、部分SQL依赖固定字符串拼接。
这种现象在真实项目里很普遍。原因不复杂：模型学到的代码大多来自完整的可运行开源项目，而真实业务系统的判断依据散落在几十个文件里。站在diff的角度看，AI并不知道这些约束存在。
几类反复出现的问题值得写进团队的Code Review清单：
- AI写HTTP调用时只补成功路径。fetch缺少超时、缺少状态码判断，直接取返回字段就开始渲染。
- 数据库跨表操作不处理事务边界。你的项目要求统一事务对象，AI单独生成的方法并不会主动遵守。
- 依赖版本来自训练记忆，不是项目lockfile。补全出来的调用代码能运行，是因为它假设你可以安装一个未必存在的旧版本包。
- AI生成的测试和实现互相“洗白”。按实现逻辑去设计输入和期望值，实现里写错的字段，测试里也会跟着写错。测试越全，错误反而被保护得越好。
Code Review的变化：AI先做机械检查，人盯业务意图
代码评审中最消耗人的部分已经能被AI处理：import是否干净、空值是否处理、资源是否释放、异常是否被吞掉。这类意见提得快，也不会带情绪。真正被节省下来的人工时间，应该用在一件机器做不好的事上：确认这次改动的前提是否成立。
AI可以严格按你的要求加上所有错误处理，但它无法判断：为了一个新用户角色去改权限模型，值不值得破坏现有过滤链路。
一个可复用的做法，是在仓库根目录维护一份REVIEW_GUIDE.md，写清这个项目不允许出现的写法（字符串拼SQL、绕过审计日志、接口入口不做参数白名单等），让AI提交PR前先自检。之后人工评审的阶段从逐行读代码，变成阅读机器生成的改动摘要，再回答两个问题：要解决的问题是不是真问题？改动的边界有没有意外影响？
这对中小开发者团队尤其明显。以前只有一两个资深reviewer、别人不敢碰的仓库，多了个不睡觉的初级reviewer，审代码的阻塞感会降下来。但合并权限仍然需要留在真实的人手里，AI不会为线上事故背责任。
人机协同的工作流配置清单
把AI当成执行很快但方向感弱的合作者，下面几条可以减少返工。
- 动代码前先写可验证的需求：输入范围、非法输入处理、调用方、是否允许重复执行。
- 生成之后先读diff再运行。没有看过的改动不要直接点批准。
- 每次改动补一个负面测试：输入什么数据时，这段逻辑应该拒绝？AI通常不会主动写。
- 要求AI把涉及的依赖写进lockfile，而不是零散躺在说明文档里。
- AI生成的测试只能作为回归基线，不能作为边界证据。人要补至少两个自己设计的边界用例。
- 注释让AI解释理由，而不是复述做了什么。
初级和中级开发者的曲线正在重新分层
AI对开发者工种的影响并没那么戏剧化。它把“会写很多代码的人”和“判断该不该写这些代码的人”之间那条线画得更清楚了。
初中级开发者会先吃到红利。以前只能眼高手低地读大项目，现在AI可以把每一段陌生代码解释给你听，随时给出行内常见写法。代价是，当你习惯让AI把复杂问题平坦化之后，线上故障时拆解根因的机会也在减少。所以我更建议初中级开发者把AI当解释器用，在多轮追问里搞懂它为什么这样写，而不是只取走补全结果。
到了中级以后，核心能力开始从写代码技巧转向制定约束。让AI在两三种实现里选，不如你自己先定下哪条边界不该跨。代码评审、架构维护、生产事故复盘，这些工作的分量会明显超过产出代码量。
下周就能做的检查
和AI共建项目时，与其数它每天贡献多少行代码，不如把验收题换成这样一个：这段改动在超时、重试、权限丢失、重复调用、旧数据兼容这几种情况下，会发生什么？
如果答案含糊，先不要改注释补文档，让AI写一个失败测试来复现那个场景，再回去改实现。这条规则能挡住相当一部分“测试通过但上线翻车”的AI代码。