先说我最近的一个真实感受。
我接了个内部工具的小需求，功能不复杂，就是一个数据清洗脚本，从几个 CSV 里读取记录，按规则去重、补全字段、输出报告。老规矩，我先把这个需求拆成四五个子任务，扔给 AI 写第一版。大概十分钟左右，它把 90% 的代码都写完了：文件读取、字段映射、去重逻辑、统计聚合，甚至把注释都写得整整齐齐。我一度觉得今天能准点下班。
然后剩下的 10%——准确说是那 10% 里真正要命的部分——花了我整整一个下午。
问题出在一个特别不起眼的地方：数据源里某个字段的编码不统一，有的是 UTF-8，有的是 GBK，还有几条记录里的时间格式是“2024/1/5”，而另外几千条是“2024-01-05”。AI 生成的正则、格式化代码在干净数据上跑得飞快，一碰到这些脏数据就直接崩。我一边修一边想了个问题：如果 AI 真的把 90% 的代码都写完了，那我这个工程师下午在干嘛？答案很扎心：我在干那 10% 里最贵的事——理解业务真实约束、定义边界条件、设计容错策略、验证生成代码的正确性。
这篇文章就想聊聊这件事。围绕“AI 写完 90% 的代码后，工程师的核心价值在哪里”这个话题，结合我最近几个月用 AI 写代码、带团队、做代码审查的实际经验，把这笔账算清楚。
1. 先搞清楚：AI到底把哪90%写完了？
1.1 AI最擅长的三类代码
先说结论：AI 确实能写 90% 的代码，但这里说的“代码”，指的是结构化程度高、语义清晰、模式成熟的那部分代码。我大致归了三类，你可以对照自己的项目看看。
第一类是样板代码（boilerplate）。配置文件的读写、HTTP 客户端的封装、数据库连接池初始化、DTO 与实体类的转换，这类代码几乎没有业务逻辑，纯粹是“照着规范填表格”。AI 见过的样本量极大，写出来的东西往往比新手还规范，连命名风格都跟你项目的既有代码保持一致。比如你用 Spring Boot，让它生成一个标准的 RestController，它连异常处理的注解都给你带上。
第二类是算法与数据处理代码。排序、查找、字符串处理、日期格式化、简单的状态机，这些是 AI 的老本行。因为算法题的训练语料极其丰富，AI 对“用 Python 实现快速排序”这种指令几乎不会出错。我经常让它写一些一次性数据分析脚本，比如从日志里提取 URL 参数、统计接口响应时间的 P99，这种活儿以前要翻文档查库，现在直接描述需求就能拿到可运行代码。
第三类是 CRUD 业务代码。单表增删改查、简单的权限校验、常规的分页查询，这类代码在 GitHub 和企业内部仓库里太常见了，AI 已经学到了无数种写法。你说“给我写一个用户管理的 REST 接口，字段有用户名、邮箱、状态”，它能给你输出一套包括 Controller、Service、Mapper 在内的完整链路，甚至帮你把参数校验注解都加上。
这三类代码加起来，确实能占到很多业务项目里 80% 到 90% 的行数。
1.2 那10%为什么总卡住？
但这三类代码有个共同特点：它们的前提假设是“需求是确定的”。而现实中，需求的不确定性恰恰集中在剩下的 10% 里。
我举个经典的例子。你让 AI 写一个“把用户输入的电话号码格式化”的函数。它大概率会给你一个正则，把 11 位手机号变成 138-1234-5678 这种格式。第一版跑通了，你觉得挺满意。然后测试同学拿来一条数据：“+86 138-1234-5678”，你的函数崩了。接着又拿来一条：“021-12345678 转 8000 找张工”，你的函数也崩了。
这能怪 AI 吗？不能。因为你在让它写代码的时候，根本没有把这些“脏数据”作为输入约束提给它。而这些脏数据、边界情况、异常分支、兼容性要求、历史包袱——它们从来不在“明确需求”里，它们藏在真实世界的角落里。一个没有摸过线上数据、没有跟产品经理吵过架、没有背过线上故障的 AI，它靠什么知道这些约束？它只能靠猜。而猜出来的东西，看起来往往很合理，实际上处处是坑。
所以我把那 10% 定义为：需求澄清、边界定义、异常处理、兼容性设计、非功能需求落地。这些内容占总代码行数可能确实只有 10%，但占整个项目的成本远不止 10%，通常达到一半以上。
2. 剩下的10%，是工程师价值的第一块试金石
2.1 需求翻译：从“人话”到“代码约束”
我在团队里经常说一句话：AI 是个超强的翻译器，但你得先把德语翻译成英语，它才能给你翻译成中文。这里的“德语”是业务方的模糊表述，“英语”是技术约束，“中文”是代码。
具体来说，产品经理说“这个列表要支持筛选”，这句话离代码十万八千里。你要跟产品确认：筛选是前端本地过滤还是后端查询？多条件之间是 AND 还是 OR？筛选条件是模糊匹配还是精确匹配？要不要支持组合排序？筛选状态下分页怎么处理？这些确认完之后，你才能给 AI 下提示词。
我最近做一个后台管理系统，有个需求是“导出报表，数据量可能比较大”。我把这个需求扔给 AI，它给了我一个同步导出的实现，逻辑倒没错。但我知道线上环境有网关超时限制，超过 30 秒的请求会被切断。这个信息 AI 是不可能知道的，除非你明确告诉它。最后我让 AI 把方案改成异步导出：先生成任务、后台处理、完成后发通知，前端轮询下载。
这就是我说的“需求翻译”能力。AI 能写的“代码”，是已经翻译成技术语言之后的代码；而“从业务语言到技术语言”的翻译过程，目前依然得靠人。这个过程包含了对业务规则的理解、对技术架构的考量、对非功能需求的权衡，它不显眼，但直接决定代码质量。
2.2 边界与异常：AI最容易“想当然”的地方
如果说需求翻译是价值的第一关，那么边界与异常处理就是第二关，也是最容易暴露 AI 短板的地方。
AI 生成代码的一个典型特征是“假设输入是合法的”。它默认用户不会传空字符串，默认数据库不会返回 null，默认文件一定存在，默认网络请求一定会成功。看起来每个假设都很合理，但连在一起就是事故现场。
我记得有一次让 AI 写一个文件上传接口，它用了 MultipartFile 接收文件，然后直接调 getOriginalFilename() 取文件名。代码跑起来没问题，直到有一天线上有人传了一个中文文件名的文件，页面直接 500。查了一下，是因为服务器默认编码不是 UTF-8，文件名乱码了。你说这是 AI 的锅吗？从代码逻辑看，它写得很标准；从生产环境看，它少了一个编码转换处理。
还有一次，AI 写了一个批量导入的接口，在 for 循环里对每条数据调了一次数据库查询，用来判断记录是否已存在。小数据量没问题，导入一万条的时候，接口响应时间是分钟级。AI 不会知道你的数据量会到一万条，它只会按“最标准的写法”来实现功能，性能优化要靠人去判断。
所以我的习惯是：拿到 AI 代码后，先读一遍所有的方法入口和返回分支，逐个问三个问题——输入为空会怎样？输入不合法会怎样？并发场景下会怎样？这三个问题问完，你就能找到 AI 代码里八成以上的隐患。
2.3 安全、合规与性能：AI看不见的约束
很多人以为 AI 写的代码在安全方面“应该没问题”，毕竟它学了很多最佳实践。但实际上，AI 生成代码的安全问题，恰恰是最隐蔽的。
举个例子，AI 写 SQL 查询时，最喜欢用字符串拼接。因为在它的训练语料里，这种写法最常见。但你如果在业务代码里不加处理地用它生成的查询，SQL 注入漏洞就这么来了。你必须明确告诉它“用 PreparedStatement 参数化查询”，它才会纠正自己。另一个高频问题是不安全的反序列化、硬编码的密钥、缺失的鉴权校验。这些不是 AI 不会写，而是它不知道你的安全基线是什么，也不知道你的代码会暴露在什么网络环境下。
性能方面也是同理。AI 默认你的数据量是百级别、千级别，所以它生成双层 for 循环毫无心理负担。但你的业务可能是十万级用户、亿级数据量。这些都是写代码之前就要清楚的约束。我见过有人直接用 AI 生成的代码上了生产环境，结果一个报表查询把数据库连接池打满，差点拖垮整条业务链路。
这些看不见的约束，决定了 AI 写出来的“正确答案”在你这里是不是真的正确。而知道这些约束、并且有能力把这些约束转成技术方案的人，就是工程师。
3. 工程师的核心价值：从“写代码的人”变成“对代码负责的人”
3.1 架构决策：AI能写模块，不能定边界
说到这，其实答案已经浮出水面了。AI 时代，工程师的核心价值不再是“怎么写代码”，而是“写什么代码、为什么写、写完之后如何保证它可靠”。
这里最典型的就是架构设计。AI 可以帮你生成一个微服务模块的完整代码骨架，但“要不要拆微服务”“模块之间如何通信”“数据一致性怎么保证”“缓存和数据库的取舍”这些问题，AI 给不了答案，因为它没有你的业务上下文，也没有你的团队技术栈约束，更不知道你的系统未来三年会怎么演进。
我去年做一个数据中台项目，技术选型时团队讨论了很久：是用 Flink 做实时计算，还是用 Spark 做批处理，还是先用 Kafka 做削峰、后续再演进？这些决策背后是对团队的熟悉度、对运维能力的评估、对业务增长预期的判断。AI 可以帮你查 Flink 和 Spark 的对比文档，可以帮你生成两套方案的 demo 代码，但“选哪个”这个决定，必然要人来承担。
架构决策的本质是在不确定性中做取舍，而取舍的依据是大量无法量化的经验与直觉。这些东西你没法写进提示词里。
3.2 代码审查：把“能跑”变成“能上线”
以前我们做代码审查，重点是看逻辑对不对、命名规范不规范。现在做代码审查，重点变成了审查 AI 生成代码的合理性。
这里说的合理性，包括几个层面。第一，逻辑正确性：AI 写的算法在标准输入下是否输出正确结果？第二，边界完备性：异常分支是否处理完整？有没有潜在的 null 指针？第三，性能可靠性：复杂度是否在可接受范围内？有没有隐藏的全表扫描？第四，安全性：有没有 SQL 注入、越权访问、敏感信息泄露？第五，可维护性：命名是否清晰？结构是否易于后续扩展？
说白了，代码审查的角色正在变得越来越重要，因为 AI 给了你一个“看起来能用”的初稿，而你要负责把它变成“真正能上线”的代码。这个过程需要大量经验积累——你要见过线上故障才能对边界条件敏感，你要做过性能调优才能一眼看出 O(n^2) 的隐患，你要背过安全漏洞的锅才能在审查时多问一句“这个接口有没有做鉴权”。
我经常跟年轻同事说：AI 让你的编码速度提高了三倍，但你的代码审查能力如果没跟上，这三倍速度只会让你的故障也来得快三倍。
3.3 风险判断：知道什么时候不能信AI
这个点我想单独拿出来说，因为它是 AI 时代最容易被忽视的能力——判断力。
AI 写的代码，最大的风险不是它写错了，而是它看起来全对。格式工整、注释规范、函数命名合理，甚至测试用例都写了几个。但它可能在核心业务逻辑上犯了方向性错误，而且这种错误极其难发现，因为代码本身是可运行的。
我有一次让 AI 写一个优惠券核销的服务，逻辑是“用户下单时，如果使用优惠券，则校验券的有效性，并扣减”。AI 给出的实现流程是：先校验、再扣减、再下单。从表面看没毛病。但我们的业务规则是“下单动作和扣减动作必须在同一事务里，否则用户如果下单失败，优惠券却扣掉了”。AI 不会知道这个业务约束，因为我没有把事务边界的需求放进提示词里，它就按最常规的顺序写了。
这个例子说明什么？说明判断“什么能放心交给 AI、什么必须人来兜底”这件事本身，是现在最值钱的能力。哪些模块可以 AI 直接生成、哪些逻辑必须要人逐行 review、哪些核心链路写完还要加测试用例和监控报警——这些决策直接决定故障发生的概率。
4. 实操：我现在的AI协作工作流
4.1 高质量提示词的三个关键要素
理论聊完了，说点实操。既然 AI 能把 90% 的代码写完，那怎么让这 90% 尽量少返工？我的经验是，花在提示词上的时间，省下来的一定是几倍的修 bug 时间。
先拆解一下我常用的提示词结构。第一，角色与背景：告诉 AI 你是资深工程师，项目用的语言、框架、数据库分别是什么。这能让它输出更符合项目风格的代码。第二，功能描述：用列表明确写出要实现的函数、输入输出、处理逻辑。第三，约束条件：把边界情况、异常处理、性能要求、安全要求逐条列出来。这里特别提到安全——你写“查询用户订单，支持按时间筛选”，和写“查询用户订单，支持按时间筛选，注意使用参数化查询防止 SQL 注入，订单量可能达到百万级，避免全表扫描”，AI 给你的代码质量是两个层级。
我最近在用 Spring AI 做内部知识库系统，需要 AI 生成一个召回结果的排序模块。我给它的提示词模式是：
你是一名资深的 Java 后端工程师，项目使用 Spring Boot 3.2 + MyBatis-Plus + MySQL 8.0。 现在需要实现以下功能： 1. 从 Redis 中读取用户的历史交互记录 2. 根据交互记录中的关键词权重，对候选文档列表进行排序 3. 支持按时间衰减因子调整排序分数 约束条件： - 用户历史记录可能为空，返回原始列表顺序 - 候选文档数量可能在 1 到 500 之间，注意性能 - 时间衰减因子使用对数衰减，避免除零 要求：输出完整的 service 实现方法，包含中文注释。你看，背景、功能、约束都说清楚了，它生成的基本能直接进入 review 环节，而不是推倒重来。
4.2 验证AI代码的标准动作
拿到 AI 代码后，我有一套固定的验证流程，分享给你参考。
第一，静态走读。不急着运行，先按函数入口到出口的顺序读一遍，重点看类型是否匹配、空值是否处理、事务边界是否合理、资源是否释放。这一步能过滤掉一半以上的低级问题。
第二，边界用例测试。构造空输入、超长输入、特殊字符、并发调用等场景，跑一遍看会不会崩。很多 AI 生成的代码在正常路径上完美无缺，一到异常路径就原形毕露，所以边界测试尤其重要。
第三，代码诊断插件辅助。我现在用的 IDE 里装了静态检查插件，它可以自动标出潜在的 bug、性能隐患和代码坏味道，算是有个机器助理帮忙做第一轮审查。类和方法的圈复杂度、重复代码、未使用的变量，这些插件都能秒级发现，省了不少事。
第四，最小化上线验证。核心模块先加监控、加日志，灰度发布。线上环境的数据分布和测试环境完全不同，AI 代码里多少会有些隐蔽问题，只有灰度环境能帮你兜住。
4.3 工具链搭配：AI不是孤岛
最后聊一下工具链。AI 写代码不是孤立的事，它需要一套配套工具才能发挥最大价值。
我现在本地的搭配是：IDE 里装 AI 编程插件，用来生成代码和解释片段；用 Copilot 做行内补全；用 ChatGPT 或本地部署的开源模型做方案讨论；配一个代码诊断插件做静态分析。几个工具各司其职，效果比单一工具好很多。
再就是本地部署大模型这个方向。有些团队的代码涉及敏感信息，不能直接发给云端 AI 服务，这时候本地部署开源模型就很有必要。我用 Ollama 跑 7B 级别的模型，虽然能力跟云端顶级模型有差距，但胜在安全可控，写写脚本、做做代码解释完全够用。我记得有次帮一个金融客户做项目，代码完全不能出内网，我们就搭了一套本地模型做辅助开发，配合预置的提示词模板，效率虽然不像云端那么极致，但已经比纯手工快多了。
还有一个值得说的是 AI Agent。我最近在尝试把一个完整的开发任务（读需求文档 → 生成代码 → 写单测 → 跑测试 → 修复失败用例）交给 Agent 全流程跑，效果比单轮对话好很多。因为它能自己迭代，发现测试不过会自己去看日志改代码，相当于有了个能闭环的初级开发。但你千万别以为这就省心了——Agent 跑完，你需要审查的量反而更大了，因为它会“自信地”写出很多表面合理但实际有问题的代码。
5. 常见问题与踩坑实录
5.1 “看似正确”的代码比明显错误的代码更危险
这个坑我踩得最深，值得放在第一位说。
AI 生成的代码通常语法完全正确，命名清晰，注释到位，甚至能通过编译。问题不在正确性上，而在意图匹配度上——它理解的需求可能是错的，或者它选择的实现路径不是最优的。
举个例子，有次我让 AI 写一个快速排序的 C 语言实现，它洋洋洒洒写了二十几行，逻辑看着也没问题。但我在代码审查时发现，它对包含大量重复元素的数组性能极差，因为在分区时没有做三路切分。如果数据源是用户 ID 这种几乎不重复的，这代码没问题；如果是年龄、评分这种重复度高的字段，性能直接退化到 O(n^2)。这种问题，如果只看“代码能跑”，你是发现不了的。
所以我的经验是：“能跑”的评价标准太低了。你要看的是——它理解了业务意图吗？它的算法复杂度适合实际数据分布吗？它选择的库或 API 是否是最佳实践？这些都是 AI 给不了答案、只能靠人来判断的地方。
5.2 测试代码被“放水”了
这个坑我也是近期才注意到。AI 写单测的时候，特别喜欢写“happy path”测试——输入正常数据，断言正常结果。边界条件、异常路径、非法输入的测试用例，它很少主动生成。
更要命的是，AI 生成的测试代码可能和你被测代码用的是同一套“思维模型”，所以它很容易写出“自己验证自己”的测试。比如它写了一个 add 函数，测试用例断言 add(2,3) == 5，表面看没毛病，但如果你期望的是加法，它写的可能是字符串拼接，那测试跟着就错了。
我的做法是：让 AI 写测试时，明确要求它“以破坏者视角编写测试，覆盖空值、边界值、非法输入、并发场景”，然后我会抽查几个用例，故意改坏源代码，看测试能不能测出来。这个“变异测试”的技巧虽然土，但极其有效。
5.3 环境依赖：AI不知道你的环境有多“脏”
这个坑出现率极高。AI 写代码时默认你的环境是“干净的”——依赖版本兼容、配置文件齐全、环境变量已经设置好。但实际项目里，遗留系统的环境问题才是家常便饭。
我碰到最典型的一次，是在一个老项目里让 AI 加一个功能，结果它 import 了一个新版库的 API，项目用的还是旧版本，编译直接报“找不到符号”。还有一次，AI 生成的代码用到了 Java 15 的语法特性，而生产环境是 Java 11，一上线就崩了。你得在提示词里明确写清楚技术栈版本，甚至把 pom.xml 或 requirements.txt 的关键部分贴给它，才能减少这类问题。
另外，Windows 环境下跑 AI 生成的脚本也常有编码坑。比如它生成的脚本用 UTF-8 读 CSV，但你的 CSV 是 GBK 编码，在 Windows 的默认 CMD 下跑直接乱码。这种问题在 AI 看来根本不存在，因为它不知道你的操作系统和文件编码。碰到了别慌，按照“输出什么格式→代码用什么格式读→系统用什么格式处理”这个链条逐个排查即可。
5.4 基础能力退化的风险
最后说一个关于工程师自身的问题，不是技术问题，但比技术问题更值得警惕。
我在带人的时候发现，有些同事依赖 AI 写代码之后，自己的代码阅读能力和调试能力有明显退化。以前遇到 bug，会先读代码、理逻辑、定位问题；现在习惯性地把报错扔给 AI，让 AI 分析。一旦 AI 给出的分析不对，他们就卡住了，因为他们已经失去了在没有 AI 的情况下独立排查问题的能力。
这里我给的建议是：重要模块的核心逻辑，不要用 AI；遇到 AI 代码的问题，先自己读了再问 AI。我给自己定的规矩是，每天早上花二十分钟读一段 AI 生成的代码，不看注释，尝试自己理解它干了什么。这个过程看着慢，但能保证你在 AI 时代依然保持“能兜底”的核心能力。
再就是：AI 生成的代码，一定要亲自跑。已经强调过很多次，但这是最容易被忽略的。很多人在 IDE 里“看起来没问题”就直接提交了，结果一运行全是问题。代码跑的通，才有讨论价值的资格。
最后分享一个我的判断标准
回到最开始那个问题：AI 写完 90% 的代码后，工程师的核心价值在哪里？说了这么多，我的答案是：在剩余 10% 的代码里，以及决定那 10% 是什么的判断力上。
如果只会写代码，AI 确实能替代你很大一部分工作；但如果你懂业务、懂架构、懂数据、懂运维、懂安全、懂代码审查，AI 在你手里就只是一支更快、更强的笔，而那个“决定写什么、为什么写、如何保证不写错”的人，永远是你自己。
我自己现在的习惯是：拿到需求先不急着打开 IDE，先花时间想清楚边界、异常、性能、安全这四件事，把约束条件写成清单，然后才让 AI 开工。看起来“不高效”，但实测下来，这样做的综合效率反而是最高的——因为 AI 帮你节省的时间，全部花在了真正需要人来做的地方。
至于 AI 会不会有一天能连那 10% 也搞定？我也说不准。但我知道的是，在那一天真正到来之前，判断力、责任心和兜底能力，依然是一个工程师最值钱的东西。等技术真的到了那一天，我们这批人如果能提前把这些能力修炼好，也一定会有新的位置在等着。
