AI写代码为何越写越多坑？从原理到工程实践的人机协作指南

1. 当“什么都用AI”撞上软件研发：口号与血肉之间的差距

最近网上有个话题挺扎眼：一家公司在四个月内裁了三万人，然后转头要求全员“什么都用AI”，结果一线员工吐槽说，现在每天的工作变成了修AI写坏的代码。

这个场景我太熟悉了，几乎每个推行AI编程的公司都会经历这个阶段。管理层看到大模型能写代码，立刻有一种“终于不用养那么多程序员”的错觉；算法工程师看到代码补全工具能自动生成函数，觉得效率翻倍；但实际上到了代码评审和联调阶段，你会发现AI贡献的代码量越大，需要人工返工的量也越大。这不是某个公司的问题，而是整个行业在拥抱AI编程时普遍会踩的坑。

我写这篇文章的目的，不是单纯吐槽“AI不靠谱”，而是想认真聊聊几个核心问题：

• 为什么公司会如此疯狂地推进AI替代？
• 大模型写代码，到底哪里容易出错、为什么错？
• 修AI写坏的代码，为什么比从零写还麻烦？
• 如果一定要用AI辅助研发，什么样的策略才是真正可落地的？

这篇文章适合正在评估AI编程工具的技术负责人、被要求“必须用AI”的一线开发者，以及正在设计研发流程的性能优化工程师。我们先把情绪放一边，用工程视角把这件事拆开看。

你需要先建立一个认知：AI写代码这件事，本质上是“文本生成”，而不是“工程实现”。这两个概念之间的巨大差距，就是所有组织层面冲突的来源。

2. 公司为什么拼命推“ALL IN AI”：降本叙事下的研发效能焦虑

2.1 降本增效的叙事，为什么听起来这么诱人

先说结论：公司要求“什么都用AI”，表面上是技术升级，本质上是财务压力下的降本冲动。裁员三万人是什么概念？哪怕平均一个人一年的人力成本是30万，这也是90亿的支出节省。但裁完员之后业务还要继续跑，产品还要迭代，怎么办？答案自然是“用更少的人做同样的事”，AI编程这时候就成了完美的叙事工具。

用AI写代码，在管理层眼里意味着什么？意味着同样的功能，原来要三个人干一个星期，现在可能一个人带着AI工具三天就搞定。这个数学题做出来太漂亮了，没有人能拒绝。而且大模型迭代速度飞快，从GitHub Copilot到各种国产编码助手，确实都能生成看起来相当完整的代码片段。只要让程序员把这个工具用起来，人头不用补，版本照发，这就是所谓“极限压榨下的效率幻觉”。

我见过不止一个技术管理者在团队里宣布：以后新代码60%以上要由AI生成，否则就是工具使用不到位。这个数字本身就很荒唐，因为代码量从来不等于业务价值。一个五分钟能写完的脚本，和一套需要精心设计的交易系统，两者根本无法用行数去衡量。但KPI一旦定下来，下面的工程师就只能想办法满足指标，至于生成的东西能不能安全生产，反而排到了第二位。

2.2 软件研发不是纯文本生成，而是混乱的长链条工程

这里有一个关键误解：管理者以为软件研发等于“写代码”，但实际上写代码只是整个链路里的一环。真正的研发工作包含需求分析、架构设计、接口定义、数据建模、代码实现、单元测试、集成测试、代码评审、部署发布、线上监控、故障恢复……这一整套流程里，代码实现的时间占比可能只有30%。

用AI替代掉这30%的文本生成部分，看似效率提升不少，但剩下的70%——尤其是需求理解、架构设计、错误处理、性能调优——依然需要人来完成。更麻烦的是，AI生成代码还会给后面的环节增加新负担：因为别人看不懂这段代码在干什么，评审成本变高；因为AI可能引入隐藏的边界问题，测试成本变大；因为代码风格不一致，后续维护成本暴涨。

所以“什么都用AI”的真相是：让一个原本会写代码的人，变成了一个必须审代码、改代码、救代码的人。这就是员工吐槽“现在的工作是修AI写坏的代码”的根源——这不是在偷懒，而是整个流程被扭曲之后，修复成本被人为拉高了。

2.3 “AI替代员工”叙事里的组织风险

还有一个被忽略的点：当管理层把所有期望押注在AI工具上，就相当于把整个研发体系的稳定性押注在外部工具的可靠性上。大模型的能力边界、提示词的质量、工具链的完善程度，这些都是变量。一旦AI生成的代码出现生产事故，团队不仅要背锅，还要在“快速发布”和“可靠性优先”之间来回摇摆，研发文化变得极其撕裂。

在我接触的团队里，推行AI编程最失败的案例都有一个共同特征：没有配套的代码评审门槛，没有定义AI生成代码的验收标准，也没有建立起回滚和灰度机制。团队被逼着用AI，但工程底线没人负责。结果就是线上事故频发，开发者在深夜修一个自己从没见过、AI也说不清楚逻辑的bug，情绪彻底崩溃。

所以说，这个热点的底层情绪，其实不是“讨厌AI”，而是“讨厌在没有配套机制的情况下被强行推上AI这条船”。

3. 大模型写代码，为什么“写得多、错得多”

3.1 从技术原理看：LLM是在“猜下一个token”，不是在“理解项目”

先普及一个基础概念。大语言模型（LLM）生成代码的过程，本质上是在做概率预测：根据前面所有的上下文，预测下一个最有可能出现的字符（token）。它并不像人类程序员那样拥有对项目的全局理解，没有“内存模型”的意识，也没有对运行时状态的判断力。它只是通过海量代码数据的学习，学会了“什么样的代码看起来像正确答案”。

举个例子。你让AI写一个Python函数，用来从用户输入的字符串里提取手机号。AI会立刻给你一段正则表达式，看起来无比专业。但你仔细看会发现，它对“手机号”的定义可能是11位数字，不校验开头是否是1，不处理+86前缀，不处理空格和短横线。这些边界条件在训练数据里确实有，但模型不会主动去追问“你的输入规范是什么”。它会生成一个“平均意义上最可能正确”的答案，而真实项目从来不需要“平均正确”，需要的是“在约定条件下绝对正确”。

这就是“写得多、错得多”的根本原因：AI生成代码的正确率，取决于你的需求描述有多精确；而大多数业务需求，恰恰最难精确描述。

3.2 上下文窗口限制：项目级代码远超出AI的“视野”

现在的模型动辄宣称支持128K甚至200K的上下文窗口，听起来很长，但一个中型项目的代码库可能包含几十万行代码。AI在一次生成中能看到的，只是你当前打开的文件和它根据提示词生成的临时上下文。它看不到项目的整体架构，看不到数据库表结构，看不到接口文档，看不到历史代码风格约定。

这会导致什么？AI会凭空发明一些不存在的函数名、不存在的配置项、不存在的依赖包。它大概率会调用一个看起来合情合理但项目里根本没有的库，然后你在编译时报错，再根据报错去查这个函数到底是什么，最后发现是幻觉，只能自己改回来。我见过最离谱的一次，AI帮团队生成了一段调用内部支付接口的代码，结果参数名拼写错误，而且把金额字段写成了字符串类型。如果不仔细review，这笔订单的钱就会出问题。

所以上下文窗口不是越大越好，而是够不够用的问题。AI写代码最擅长的场景是“独立小函数、模板代码、简单CRUD”，因为这些场景的上下文需求少，模型可以基于token预测给出合理结果。最怕的就是让AI处理跨模块的复杂业务流，它会在看不到完整信息的情况下疯狂补全，最后给你一坨看不懂又没有测试保护的神奇逻辑。

3.3 训练数据的“平庸化”问题：AI生成的代码普遍缺少工程化改良

再深挖一层，大模型学到的代码，大部分是公开代码仓库里的“平均代码”。这些代码不一定是好代码，有很多是历史遗留的烂代码、为了跑通demo凑出来的示例、缺乏异常处理和注释的脚本。

AI学习这些数据后，生成的代码在风格上会趋于平庸：功能能跑，但缺少防御性编程、缺少性能优化、缺少可扩展设计。比如，它可能直接拼接SQL语句而不是用参数化查询（存在注入风险），可能不使用事务来保证数据一致性，可能不处理时区问题。这些都不是“语法错误”，而是“工程缺陷”。语法错误编译器能帮你查出来，工程缺陷只能靠人来review、靠测试来发现。

对于那些说“AI生成的代码比初级工程师写得好”的人，我部分同意。如果以“能不能跑通”为标准，AI确实比很多初级工程师强，因为它的代码规范性和语法正确性有保障。但如果以“能不能上线生产”为标准，AI生成的代码离资深工程师的水平还差得很远。因为它不理解业务，不理解边界条件，不理解线上复杂环境。

4. 修AI写坏的代码，为什么比从零写更折腾

4.1 认知负荷：你没有生成它的思维模型

程序员之间有一句老话：读代码比写代码难，读别人的代码比读自己的代码难，读AI写的代码则相当于读一个“看起来像人类但思维模式完全不同的外星人”写的代码。

人类写代码时，通常遵循某种思路：先明确输入输出，再处理异常路径，最后考虑边界条件。代码的结构里有逻辑递进，有作者对问题的理解痕迹。而AI生成的代码，它是通过概率预测把token拼起来的，缺乏一致性的思维模型。同一个功能里可能出现三种不同的写法，有的地方用列表推导式，有的地方用for循环；有的地方先判断空值，有的地方直接取下标。你读的时候，需要不断切换理解模式，非常耗费脑力。

修复这种代码时，你还面临一个尴尬的问题：与其理解它、修好它，不如删掉重写。但删掉重写意味着放弃已经被测试覆盖的部分，万一AI生成这段代码时已经被其他模块依赖了，重写带来的风险和成本更大。所以大多数人会选择硬着头皮去修，在“几乎看不明白”的逻辑上打补丁，然后这个补丁成为下一个维护者眼中的“祖传代码”。

4.2 测试与质量门禁的缺失：AI生成了代码，但没有人生成“安全感”

如果AI生成的代码后面跟着完整的单元测试、集成测试，那风险会小很多。但在实际使用中，大部分开发者使用AI生成代码时，根本没有在提示词里要求生成测试用例。工具也没有自动为生成代码补上测试。

你想想这个场景：一个业务函数，AI帮你写了五十行，你没有逐行review就提交了，代码评审也只是走个过场，测试环境跑了一遍发现主流程没问题，就上线了。结果线上数据出现异常，你开始排查。这时候你没有测试去约束行为，只能靠日志和猜测。AI生成的代码没有给你的业务提供“安全感”，而是制造了“不确定性”。

更麻烦的是，AI生成代码过程中，可能会隐式地假设某些状态：比如假设外部系统一定返回200，假设并发环境不会出现，假设数据库不会超时。这些假设在开发环境“恰好正确”，在生产环境“恰好出错”。要排查这类问题，你甚至需要先猜出AI到底做了哪些假设，这种调试过程极其痛苦。

4.3 变更来源不可追溯：AI让代码评审流于形式

我在代码评审时遇到过一个非常典型的场景：一个同事提交的PR里，出现了十几个文件的改动，大部分代码逻辑看起来都“像那么回事”，但问细节他答不上来。一问，原来是AI生成的，他自己都没逐行看。

这件事暴露出一个严重问题：AI编程让代码评审的“信任链”断裂了。传统协作中，提交代码的人需要对代码负责，评审人信任提交人，同时也会审视代码质量。但当代码由AI生成时，提交人自己都不完全理解代码，评审人纵使技术再好，也很难在有限时间内识别出AI藏在代码里的“概率性错误”。

最可怕的是，一旦线上出现问题，你没法通过git blame准确定位责任，因为提交人是AI的使用者，但代码不是他写的。你也没法通过修改历史来理解演进逻辑，因为AI一次生成就是一大坨，没有原子提交的概念。等你急着修线上bug时，眼前就是一片没有上下文、没有解释、没有测试保护的“文本废墟”。

4.4 情绪消耗：开发者士气在“修AI的屁股”中迅速崩溃

最后聊一个容易被技术讨论忽略的维度：情绪。工程研发的核心资产是人，人的状态直接影响产出。当一个开发者的主要工作从“创造性地解决问题”变成“给AI擦屁股”，他会迅速产生倦怠感。因为他失去了对工作的掌控感，失去了技术成长的正反馈，也看不到自己代码里“值得骄傲的部分”。

我看到很多团队推行AI编程推行了三个季度，效率没上去，离职率倒是上去了。这不是AI工具不好，而是组织没有设计好角色转变。人不是机器，不可能无限容忍“每天清除一堆不属于我的垃圾”。

5. “让AI全干”是伪命题，但“让AI干活”是真的

5.1 AI擅长的场景和不擅长的场景，要有一条清晰分界线

聊完问题，总得给点建设性方法。先泼一盆冷水：不要幻想AI能完全替你做研发，那是伪命题；但也不要因为修AI代码的痛苦就废弃AI，那是因噎废食。关键是要划一条清晰的分界线，知道哪些活可以放心交给AI，哪些活绝对不要让AI擅自发挥。

根据我的实践，我将AI编码的能力边界总结如下：

这个表格没法穷举所有场景，但它能帮你建立第一步判断：凡是“目标明确、输出形式稳定、上下文清晰”的任务，AI可靠；凡是“充满隐含条件、需要大量业务知识、没有明确验收标准”的任务，别让AI自由发挥。

5.2 人机协作的正确姿势：AI负责“完成”，人负责“把关”

在团队实践上，我倾向的模式是“AI负责草稿、人负责定稿”。具体来说，就是让AI生成代码的一个“可行初稿”，然后开发者像对待一个不太靠谱的同事提交的PR一样去review它、改它、测试它。这里有一个关键心态：AI生成的代码只是候选方案，不是最终代码，你的工作不是被动接受，而是主动控制质量。

实际步骤可以这样落地：

1. 在IDE里使用AI生成代码时，明确要求AI“只生成函数体，不生成业务决策”；或者在prompt里指定输入输出、错误处理方式和风格约束。
2. 生成后，第一件事不是debug，而是先做静态阅读。重点检查：是否有对空值的判断？是否有异常捕获？是否有边界条件处理？是否使用了项目中已有的工具类而不是凭空造轮子？
3. 对涉及金额、权限、用户数据的代码，强制要求开发者自己重写核心部分，AI只能生成外围辅助代码。
4. 在提交代码前，把AI生成的部分单独标记出来，让代码评审人重点看这些地方。
5. 给AI生成代码配上对应的单元测试，如果AI不写测试，你就自己写，否则宁可不要这段代码。

这套流程看起来更重，但它能把AI编程的“效率收益”和“质量风险”分开管理。你享受了AI快速生成初稿的效率，同时用人脑补齐了AI欠缺的工程守护。

5.3 组织层面：管理层应该考核什么指标，而不是考核代码生成比例

如果你是一个技术管理者，请注意一点：不要考核“AI代码占比”这类过程指标，要考核“需求交付周期”“线上缺陷率”“架构健康度”这类结果指标。前者只会逼着团队“表演使用AI”，后者才能真正引导团队找到AI合适的位置。

我还建议给团队留一个“无AI日”或者“无AI模块”。任何一个项目里，至少要有一块核心业务逻辑是完全由人类开发者自己写的，保持对代码手感、对技术判断力的基本训练。AI是辅助工具，不是替代大脑；如果你连核心模块都让AI写，团队的技术能力会迅速退化，到时候AI一旦不可用或者出问题，整个团队连修复它都做不到。

5.4 用工程文化兜底：让AI成为员工的朋友，而不是他们的敌人

最后，说说文化层面。AI编程推行失败的另一个重要原因，是没有给员工“安全感”。当公司把AI和裁员放在一起讲，员工心里当然会抵触。你换了谁都会想：我为什么要好好教AI干活？我教完它，它是不是就把我替了？

我见过推行得比较成功的团队，有一个共同特点：管理层明确说出了这句话——“AI不会替代你们，但会用AI的人会替代不会用AI的人”。同时他们没有因为引进了AI而消减人头，而是用省出来的时间让开发者去做更有价值的技术改进、架构升级和技术创新。

在这种环境下，开发者的心态不是防御性的，而是主动去研究怎么把AI用好。你让AI帮你写100个样板文件，自己专心设计一套异常处理方案，最后成果和成就感都属于你。等公司真的需要缩减人力时，你也是那个“能管理AI + 能兜底救火”的人，价值反而更高。

6. 我从一堆AI事故里攒下的几条工程规则

最后分享几条我自己的实操经验，都是从真实的“AI事故”里总结出来的，希望对你有用。

第一条规则：涉及金钱、权限、隐私的代码，永远不让AI自主生成。

这类代码的逻辑哪怕再简单，也都要自己动手写，AI可以帮你查API文档、帮忙搭测试骨架，但核心的金额计算、权限判断、数据脱敏逻辑必须逐行是自己的判断。原因很简单：一旦出问题，责任方只能是你，而AI不会替你背锅。

第二条规则：AI生成的代码，必须走评审，而且评审人有否决权。

如果你团队里文化比较生硬，可以把这个规则包装成“所有代码一律评审”，不点名AI生成。但实际操作上，评审人要学会识别AI代码的痕迹，多追问几个“为什么这里要这样做”。只要有一次发现AI生成代码的严重问题，整个团队的警觉性就会提高。

第三条规则：保留“撤销AI”的能力。

每次用AI生成代码后，第一件事是提交一个带标签的commit（比如“feat: AI-generated skeleton”），然后在此基础上再改。这样一旦后面发现AI生成的底座有问题，还能一键回滚到人工版本。很多团队没有这个习惯，结果AI代码悄无声息地混进了大PR，想回滚都找不到边界。

第四条规则：在prompt里强制要求AI写测试和边界检查。

虽然AI写测试用例的质量不高，但让它生成了，你至少能在此基础上完善。如果你不让它写，十有八九它会默认你不关注测试，直接给你纯业务实现代码。一个简单但有效的提示词模板是这样的：

code复制请生成一个Python函数，用于解析用户输入的订单信息。
要求：
- 输入可能包含空字符串和非法字符，需要做健壮性处理；
- 函数必须附带单元测试用例，覆盖正常、异常、边界三种情况；
- 不要使用任何项目之外的新依赖；
- 代码风格遵循现有项目约定。

这个提示词看着简单，但实际效果天差地别。AI会因为它性能上偏向完成“完整任务”，主动帮你考虑边界处理和测试。你可能仍然要改一部分，但至少你不用从头开始纠结。

第五条规则：永远不要把AI当成“外包团队”。

外包团队你还能提需求、改bug、催进度，AI连“改bug”得出的结果都可能和原来完全不一样，而且它不理解你的业务背景。我见过很多工程师把AI当成一个“随叫随到的外包”，让它实现整个模块，然后自己只做集成，结果被坑得很惨。真正把AI用好的人，是把AI当成一个“开挂的键盘”，快速补充代码量，但所有设计决策、所有关键判断都在自己手里。

我自己这几年用AI编程的最大体会是：技术工具从来不会自动产生价值，只有在良好工程体系里才能放大价值。AI编程也不例外。它可以在你思路清晰的时候帮你把想法快速变成代码，但它没法替你想清楚这个功能到底该怎么设计、边界在哪里、风险有多大。

如果你现在正处在“被要求用AI，但天天修AI的bug”的状态，我的建议不是消极抵抗，而是主动掌握规则。不要仅仅因为公司说“什么都用AI”，就把自己的技术判断力交给了概率模型。把AI当工具，把你自己当成最后的工程守护者——这既是职业素养，也是在这个时代活下去的核心能力。