1. 当代码80%是AI写的从段子变成日常第一次看到代码80%是AI写的这句话我下意识觉得是营销话术。直到去年年底复盘自己一个中型项目翻了提交记录才发现新增代码里有相当大比例确实是AI先给一版、我再动手改。这不是什么科幻场景就是日常。现在的AI编程工具已经从猜你想写什么进化到能读懂整个项目上下文、能自己拆任务、能跑测试、能根据报错自动回退重写。代码、AI、AI开发这三个词早就从技术圈内的黑话变成了每个开发者绕不开的日常。这篇文章想聊的不是AI会不会取代程序员这种被嚼烂的话题而是更实在的东西当AI真的帮你写了大部分代码这套工作流到底该怎么搭工具怎么选生成出来的代码质量怎么兜底哪些环节必须人工介入以及遇到诡异bug时怎么排查。我自己从最开始的AI补全挺好用到让Agent自己跑一整晚中间踩过的坑不算少有些坑是真的会影响线上稳定性。无论你是刚接触AI编程的新手还是已经在用AI Agent做开发的老手这些经验应该都能对你有用。开头我会先把现状和能力边界说清楚再进入工具选型、实操流程、质量把关和问题排查。需要先声明一点下面提到的工具名称和具体做法都是基于我自己的使用习惯和行业常见实践的总结不是唯一解。不同技术栈、不同团队规模最优方案会差很多你可以把这些当成一张参照地图具体路线还得自己走。2. AI写代码的现状80%这个数字背后到底是什么2.1 AI生成代码的典型场景与能力边界先说清楚AI现在能干什么、干到什么程度。我把它分成三档。第一档是填空,也就是行内补全。你在写一个循环它帮你补完剩下的括号和变量你写了个函数名它把函数体补出来。这一档最成熟几乎零风险因为它只在你光标附近活动不会改动你看不见的地方。基本上所有主流IDE的AI插件都能做到属于无脑开着的级别。第二档是整函数/整文件生成。你描述一个需求比如写一个读取CSV、清洗空值、按日期聚合、输出JSON的函数它给你一版完整实现。这一档就需要你认真读了。它能跑但边界条件、异常处理、性能特征往往不对尤其是涉及业务规则的地方它只能猜。我的经验是这一档能省掉大概60%到70%的敲键盘时间但省不掉思考和审查的时间。第三档是自主Agent。你给它一个任务比如给这个模块加上单元测试覆盖率到80%它会自己读代码、读测试框架配置、写测试、运行、看报错、改、再运行循环到成功或者卡住。这一档最能体现80%代码是AI写的这个说法。但也是风险最高的一档因为它会大范围改动文件而且如果项目的测试本身不可靠它会朝着错误的方向优化。我把这三档的适用场景整理成一张表方便对照档次典型工具形态适用场景人工介入程度风险等级行内补全IDE插件日常编码、样板代码几乎无需极低整函数生成对话式助手新功能原型、脚本、测试必须逐行审中自主AgentAgent工具/终端批量重构、补测试、迁移任务前定规则、结果必审高能力边界这里划一条线AI特别擅长有明确输入输出、有大量公开样例、逻辑相对独立的代码比如工具函数、数据转换、正则、SQL、单元测试骨架。它不擅长依赖隐性业务规则、依赖团队约定、需要权衡取舍的代码比如权限判定、金额计算、状态机流转、并发控制。后者你让它写它也能给你一版看起来很合理的但看起来合理恰恰是最危险的因为review的时候容易滑过去。2.2 为什么占比高不等于能撒手这里要拆一个常见的认知误区。很多人看到AI写了80%的代码第一反应是那程序员是不是要失业了。但真正做过这件事的人知道这个80%的统计口径本身就有讲究。它统计的往往是代码行数而行数和价值不是一回事。举一个我自己的例子。上个季度做一个小工具AI生成的代码大概占了75%。但那75%里绝大多数是数据结构的定义、样板性的getter/setter、JSON序列化、日志埋点、参数校验这些体力活。真正的核心逻辑也就是那个决定业务正确性的判断分支加起来可能就30行全是我自己写的因为这30行错一个条件整个功能就是错的。所以更准确的说法是AI承担了量人负责质和责任。还有一个更现实的问题。AI生成代码的速度太快了快到review会成为整个流程的瓶颈。以前一天写200行review 200行节奏匹配。现在一天生成2000行你还是只能review 200行剩下的1800行怎么办要么加班review要么降低标准。这两条路我都走过结果是加班会累垮降低标准会埋雷。代码80%是AI写的这个现象真正带来的挑战不是写不出来是审不过来。后面第5节会专门讲怎么改review流程。2.3 关于呼吁暂停这件事技术人该怎么看标题里提到有AI公司呼吁暂停AI开发这属于行业层面的讨论不是咱们日常能左右的。但从技术人的角度这件事其实给了一个提醒当工具的能力增长快过我们对它的理解风险就会累积。这个风险不抽象就摆在你我的代码库里。我的态度很简单把注意力放在自己能控制的部分。一是把AI生成的代码当外部贡献者提交的PR来对待该查的查该测的测绝不因为它看起来很顺就放行。二是在团队里建立明确的AI使用规范什么场景可以用Agent自主改代码什么场景必须人工写白纸黑字写清楚。三是保持自己对核心逻辑的手感别让我只会调AI变成现实。这三条做到行业层面怎么吵你都不用慌。3. AI编程工具选型从补全到Agent的演进3.1 代码补全与内联建议类工具怎么选这一档工具是基础盘选型核心看三点延迟、上下文长度、对冷门语言的支持。延迟是第一位的。补全这东西超过200毫秒你就会觉得卡超过500毫秒你直接想关掉。我实测过几款有的在大型项目里因为要扫描大量上下文延迟忽高忽低写代码的节奏全被打乱这种直接pass。上下文长度决定它能不能看懂你正在写的这段代码在项目里的位置短上下文的工具经常给你补一个跟当前类完全不搭的实现反而是干扰。冷门语言的支持也重要。主流语言比如Python、Java、JavaScript各家都做得不错。但如果你写的是Go的某些框架、Rust的宏、或者某家公司的内部DSL工具之间的差距会非常大。选之前一定拿自己项目里最偏的那部分代码试试。提示补全类工具我建议只开行内建议不要开自动应用。有些工具会默认帮你把建议直接写进代码你没看清就回车错误就进去了。手动Tab确认这个动作能挡住相当一部分低级错误。3.2 对话式编程助手的使用姿势对话式助手就是你贴一段代码问它、让它改、让它解释是最容易被用错的一档。很多人把它当搜索引擎用这个报错什么意思这当然可以。但更有价值的用法是把它当结对编程的搭档。我的用法是三步。第一步先让它解释不给方案。把报错和上下文贴过去问你觉得问题可能出在哪给我几个方向这一步是为了防止它直接给你一个看起来对但其实治标不治本的补丁。第二步选定方向后让它给出改动方案但要它说明理由和影响范围。第三步让它把改动写成diff的形式而不是直接给完整文件。diff能让你一眼看到它动了哪几行完整文件你得逐行对比效率差太多。关于提示词这有个经验给约束比给需求更重要。你说写一个排序函数它随便给你一版。你说写一个排序函数输入最多1000个元素不需要考虑内存优化但必须稳定排序不能改变相等元素的相对顺序它给你的东西质量立刻上一个台阶。约束越具体它猜的空间越小出错的概率越低。3.3 Agent式工具威力最大也最需要规矩Agent这一档是最近一年变化最快的。它能自己读文件、写文件、跑命令、看结果、再调整你说一句把这个项目的日志库从A换成B它能自己找所有调用点、改import、改配置、跑测试。用好了能顶一个初级工程师用不好能在半小时内把你的仓库搅乱。我用Agent的第一条规矩是永远在干净的git分支上让它干活。这样它改崩了一条命令回滚心理负担为零你也敢让它尝试更激进的方案。第二条规矩是任务要小。别让它一次改20个文件一次改3到5个文件的规模出问题好定位。第三个规矩是给它明确的验收标准比如改完之后pytest tests/unit必须全绿有了这条它才有反馈信号不然它会自我感觉良好地给你一坨跑不起来的东西。工具选型上我的建议是先固定一套主力的补全工具一套对话助手Agent按需引入。全都上你会被各种快捷键和交互逻辑搞晕反而降低效率。工具是拿来省事的不是拿来收集的。4. AI生成代码的质量问题我踩过的坑4.1 AI代码常见的四类坑我把实际遇到过的问题归了类这四类最典型。第一类看起来对的边界错误。比如一个分页函数它写的offset page * size看着没问题但你的项目约定页码从1开始它按0开始算结果第一页永远拿不到数据。这类错误最阴因为它语法正确、逻辑自洽、跑起来不报错只是结果悄悄错位。第二类假设了不存在的依赖。它给你import pandas as pd你项目根本没装pandas或者它调用了一个你们内部库早就废弃的方法。这类错误在运行时会直接爆相对好抓。第三类性能上的隐形炸弹。它在循环里做网络请求在列表里做O(n)查找在每次调用都重新读一遍大文件。功能是对的数据量小的时候也看不出来等量上来了直接雪崩。这类问题review的时候特别容易漏因为代码读起来没什么问题。第四类安全问题。打印或记录了敏感字段、拼接SQL没做参数化、对外部输入没做校验、错误信息里带了堆栈和路径。这类问题在AI生成的代码里出现频率不低因为它学的是最常见的写法而最常见的写法往往不是最安全的写法。4.2 审查流程怎么改才跟得上生成速度前面说了写的速度快过审的速度这是新的主要矛盾。我的解法是把review拆成两层。第一层是机器先过。静态检查工具、格式化工具、安全扫描工具这些在提交前自动跑把明显的格式问题、明文密钥、未使用变量、可疑依赖全部拦掉。这一层不需要人配置一次长期受益。把机器能判断的东西交给机器能砍掉大概三成的人工review量。第二层是人只看三件事。一是核心逻辑和业务规则这块前面说了AI不可信。二是边界和异常路径就是第4.1节说的第一类坑专门盯着看。三是它引入的新依赖和新模式因为这会改变项目的长期走向必须有人把关。注意别指望让AI审AI来解决全部问题。让AI做第一遍review确实能发现一些疏漏但它和写代码的是同一类模型共有的盲区基本一致它觉得没问题的东西往往就是它写出来的那个盲区。AI review可以当辅助不能当依赖。5. 实操让AI把一个功能模块写出来5.1 需求拆解与提示词设计光讲道理没用说一遍我完整的流程。假设要做一个用户行为日志的聚合统计接口。第一步自己先把需求拆清楚不急着丢给AI。我的拆法是分三层输入是什么原始日志文件按小时切分输出是什么按用户维度的行为计数返回JSON约束是什么单文件最多50万行不能全量载入内存要在30秒内跑完。第二步把拆好的需求再拆成AI能一口吃下的块。我一般拆成四五块数据读取模块、清洗逻辑、聚合逻辑、输出格式化、单元测试。每块单独生成生成完立刻验证这一块不要等全部生成完再一起测那样出了问题得从头查。第三步写提示词。我的提示词模板大致是四段背景这是什么项目、用什么语言、有什么现有约定、任务这一块要做什么、约束性能、内存、异常处理要求、验收怎么算做完了。比如第4块输出格式化我会写把聚合结果转成JSON字段名用下划线风格匹配现有接口数字不要输出成科学计数法时间用ISO8601如果结果为空返回空数组而不是null。约束给到位返工率能降一半。5.2 分步生成与即时验证生成第一块数据读取模块时Agent给我的第一版是直接read()整个文件这违反了我不能全量载入的约束。它为什么会犯这个错因为它默认的写法就是最简单的写法。这时候我不是直接让它重写而是把单文件50万行这个约束重新强调一遍并告诉它分块读取每块10万行。第二版就对了。这里有个技巧报错信息要原样贴回去别自己总结。很多人习惯自己理解报错后转述给AI比如这里好像读文件报错了。这样AI会丢掉大量信息。原样贴包括完整的堆栈和行号它定位问题的准确率高很多。第二块清洗逻辑它写了去空值和去重但没处理时间格式的兼容性我们的日志有几种不同的时间格式混着。这个是我在review的时候发现的因为它默认假设了一种格式。补上约束后重新生成OK。第三块聚合逻辑是核心我自己写了大半让AI补了分组统计的部分。第四块格式化一次过。第五块测试让它按前面几块的接口生成生成完必须真的跑起来不能只看它说测试通过。实测下来它生成的测试里有两成左右是永远通过的假测试比如断言写得特别松或者测的输入根本没触发被测逻辑。5.3 集成与验证所有块生成完集成的时候要特别小心接口对齐。AI生成的不同模块之间参数名、返回结构、异常类型经常对不上因为它每个块是独立生成的没有全局视野。集成这一步我建议人工主导AI辅助。接口对齐这种事人工看一眼就能发现交给AI它得试好几轮。集成完跑端到端测试我一般会准备三类用例正常数据、边界数据空文件、单行文件、超长行、异常数据格式错误的行、编码不对的文件。前两类AI能帮你生成第三类它经常想不全需要你自己根据业务经验补。这三类都过了才算能用。最后一步是压测。前面提到的30秒内跑完这个约束一定要用接近真实大小的数据实测。我吃过亏功能测试全过真数据一跑跑了八分钟原因是有个操作在循环里重复打开文件句柄。这种问题不实测根本发现不了。6. 常见问题速查与排查思路用AI写代码这一路上遇到的问题我整理了一张速查表方便遇到的时候对号入座现象大概率原因排查方向处理办法语法正确但结果不对边界条件假设错误拿最小输入手算一遍人工写核心判断AI写外围运行时报导入错误AI假设了不存在的依赖检查依赖清单补依赖或改实现小数据正常大数据卡死循环内IO或O(n)查找看循环体里有没有重复操作把操作移出循环生成的测试总是通过断言太松或没触发逻辑故意改坏实现看测试是否失败重写断言多个模块接口对不上分块生成缺乏全局视野检查参数名和返回结构人工主导接口定义Agent改崩了仓库任务范围太大看diff涉及多少文件缩小任务用干净分支提示词给得很清楚还是跑偏约束藏在长文本里被忽略把关键约束单独强调约束前置重复强调除了这张表还有几个排查思路值得单独说。一是二分法定位。AI生成的代码出问题不要从头读把它生成的改动切成两半注释掉后半看还出不出问题快速缩小范围。这比逐行读快得多。二是复现优先于理解。先想办法稳定复现问题复现不了的问题没法修。复现之后再加日志、再打断点顺序别反。三是怀疑默认值。AI特别喜欢给默认值默认超时、默认编码、默认时区、默认排序。这些默认值在它训练数据的语境里是对的在你的环境里往往不是。遇到诡异问题先把所有默认值列出来挨个查。7. 关于AI开发这件事几点个人体会用AI写代码用到现在我最大的感受是这件事改变的不是要不要写代码而是写代码的时间花在哪。以前大量时间花在敲键盘和查API文档上现在这部分被AI接管了时间转移到了想清楚需求、设计约束、审查结果、排查问题这些地方。这些恰好是更考验人的部分。所以别被80%这个数字吓到也别被它迷惑。真正决定你产出质量的那部分工作AI还接不住短期内也接不住。它是个效率极高的助手但助手再强拍板的人还是你。我现在的习惯是AI生成的每一行进主干之前我至少要能对着它说清楚这行为什么这么写说不清楚的就先别合。这个标准听起来很严但养成之后反而让整个流程更顺因为你心里有底。后续我打算再多试试Agent在批量重构上的用法目前用得还比较保守。如果有新的踩坑经验再整理出来。你在用AI写代码的时候如果遇到什么邪门问题也可以按第6节的表先自己过一遍大部分情况能对上号。