AI 在程序员协作中的不足，以及程序员该往哪走

AI 写代码现在确实快。给它一个清晰需求，几秒钟就出来一大段能跑的代码。但用得越久，越会发现一个反差：写代码变快了，交付一个可靠的系统却没有变快多少。因为瓶颈从"敲代码"转移到了"判断、验证和负责"上，而这些恰恰是 AI 目前最弱的地方。

这篇不说 AI 能做什么，专门讲它在程序员协作中还不足的地方，以及在这个背景下，程序员该往哪个方向使劲。

一、AI 在协作开发中的不足

AI 每次对话基本是"重新读一遍代码"来理解项目，没有跨会话的持续记忆。项目一大，它就只看到当前打开的几个文件，非常容易改了 A 处、破坏了 B 处的不变量。跨模块的一致性、全局约束的维护，是它最明显的短板。

需求越不清晰，AI 越不会停下来问，而是按通用理解补全，然后自信地做下去。结果常常是方向就错了，返工成本比手写还高。它不理解你们团队的黑话、历史约定和隐含前提。

它能写出某个函数内正确的代码，但缺乏系统级取舍：要么过度设计，为一个需求引入一堆抽象；要么该抽象时到处复制粘贴。分层、边界、扩展点这些判断，仍然主要靠人。

它会编造不存在的 API、包名、配置项和版本号，而且说得非常肯定。知识有截止时间，对新框架的行为可能过时。新手最难分辨的就是这种"自信的错误"。

调试的本质是观察运行时，而 AI 大多只能看着代码猜。竞态条件、内存泄漏、只在生产出现、和环境强相关的问题，它帮助有限。它写的测试有时"能过，但没测到关键点"。

它容易写出有漏洞的代码：SQL 注入、越权、密钥硬编码、权限过宽。因为它没有真正的威胁视角和业务安全边界意识。安全审查必须由人兜底。

"我们为什么这么做""这块为什么不能用某个方案"，这类靠口口相传的知识，AI 拿不到，也不背历史包袱，所以方案常常"技术上对、业务上不合适"。

命名、抽象层次、代码风格的一致性时好时坏。它默认追求"先让它工作"，长期可维护性需要人把关。

最终还是人签字、上线、背锅。AI 不对线上事故负责，也无法做产品取舍。它只是放大器，不是责任人。

把上面几条收拢，会发现生成代码反而不是瓶颈了，新的瓶颈是：

一句话：AI 把"实现"变便宜了，于是"判断"和"验证"变得更贵。

这是 ROI 最高的能力。能不能把模糊需求拆成有边界、有验收标准的任务，直接决定 AI 产出质量。学会写清晰的规格：输入输出、边界条件、失败处理、验收方式。

当实现层被 AI 承包，人的价值上移到了"怎么切分系统"。多练数据模型设计、模块边界、抽象时机、可扩展性，形成自己的设计品味。

你不再是"写代码的人",而是"审代码的人"。要能快速识别 AI 产出的坑：边界没处理、异常吞掉、安全隐患、隐藏的性能问题、测试没测到点。读代码、判断对错，比写代码更重要了。

越是 AI 搞不定的疑难问题，越值钱。深入理解运行时、并发、内存、操作系统、网络，才能在它束手无策时顶上。

把安全内化成习惯：权限最小化、输入校验、密钥管理、依赖审计。AI 生成的代码默认要按"可疑"来处理。

技术会越来越平权，懂业务、懂用户、懂行业才是护城河。知道"什么值得做"，比"怎么做"更难被替代。

把 AI 纳入工程约束：CI/CD、静态检查、测试覆盖率、代码规范、可观测性。让工具帮你在规模化产出时守住底线。

不轻信任何输出（包括 AI 和自己的直觉），凡事验证。控制实验、回滚方案、灰度发布，这些习惯在 AI 时代更关键。

一个更现实的判断：纯"翻译需求成 CRUD"的岗位会被持续压缩；而能定义问题、做架构取舍、守住质量和安全、扛住疑难问题、把 AI 编排进工程体系的人，价值反而会上升。