1. 这件事到底在说什么从一条新闻拆出三层信息先把事实摆清楚。有一家做AI的公司公开表示自家代码库里大约80%的代码是AI写的同时这家公司又站出来呼吁“暂停AI开发”。这两句话放在一起本身就构成了一个巨大的张力一边是AI编程工具已经把生产力拉到了这个程度另一边是造工具的人自己开始踩刹车。很多人看到这条消息的第一反应是“作秀”“营销”“又要监管别人不监管自己”。但如果只停在这个层面就浪费了这条新闻真正的信息量。我更愿意把它拆成三层来看。第一层是工程事实层80%的代码由AI生成这个数字意味着什么它意味着在这家公司的日常研发流程里AI已经不是“辅助补全”的角色而是主力写手。人类工程师的工作重心从“写代码”转移到了“审代码、定架构、写测试、做决策”。第二层是能力演进层为什么偏偏是现在喊停关键词里有一个很扎眼的词——递归自我改进。当AI能写代码而AI本身又是代码构成的那么“AI改进AI”的闭环就具备了物理基础。80%这个数字正是这个闭环开始转动的信号。第三层是行业博弈层呼吁暂停这件事从来不只是技术问题。谁呼吁、呼吁什么、呼吁的同时自己在做什么这三件事要分开看。历史上每一次“暂停某技术”的公开信背后都夹杂着竞争节奏、人才争夺、话语权卡位。我写这篇东西不是要复述新闻而是想把这条新闻背后的技术现实讲透AI编程工具现在到底能做到什么程度所谓“80%代码是AI写的”在工程上是怎么实现的递归自我改进离我们还有多远以及作为一个普通开发者你现在应该怎么用这些工具、怎么防坑。适合谁看正在用或准备用AI编程工具的开发者、技术团队负责人、对AI能力边界好奇的产品和运营同学。不需要你是算法专家但需要你对“写代码”这件事有基本概念。2. 80%代码由AI生成工程上是怎么做到的2.1 先搞清楚“AI写的代码”到底指什么“80%的代码是AI写的”这句话如果不加限定很容易被误读。它绝不是说“AI独立完成了80%的软件系统”。真实情况通常是这样的在一个成熟的AI编程工作流里代码的产生方式被拆成了若干环节AI在其中承担了大部分字符级产出。具体来说AI参与的代码产出大致分这么几类行内补全你敲一个函数名AI把整个函数体补出来。这是最基础的一层类似早期的代码补全但现在的模型能补出几十行带业务逻辑的代码。对话式生成你用自然语言描述需求AI生成一整段模块代码你复制粘贴或让它直接写入文件。多文件编辑AI根据一个任务描述同时修改多个文件包括新增文件、修改引用、更新配置。这是当前AI编程工具的核心能力。测试与修复AI根据报错信息自动定位问题并给出修复补丁或者根据现有代码反向生成单元测试。所谓80%大概率是把上述所有环节产生的代码行数加总再除以总提交行数得到的比例。这个统计口径本身有水分——比如AI生成的代码被人类改了三遍才合并算谁的但即便打个对折40%的代码由AI产出也已经是一个质变的数字。2.2 支撑这个比例的三个技术支点要让AI稳定产出可用代码光有一个会聊天的模型是不够的。背后至少有三个技术支点在撑着。第一个支点是长上下文与代码库索引。早期的AI编程工具只能看到你当前打开的文件稍微跨个文件就抓瞎。现在的工具会把整个代码仓库做向量化索引AI在生成代码前能检索到相关的类型定义、工具函数、调用约定。这就是为什么现在的AI能写出“符合本项目风格”的代码而不是一段放之四海皆准但跑不起来的样板。第二个支点是工具调用能力。也就是常说的Agent能力。AI不只是生成文本它还能调用“读文件”“写文件”“执行命令”“跑测试”这些工具。一个任务交给它它会自己规划先读哪些文件了解上下文再改哪些文件改完跑一下测试测试挂了再回来改。这个循环一旦跑通AI就从“打字员”变成了“能自己干活的初级工程师”。第三个支点是验证闭环。这是最容易被忽略但最关键的一环。AI写的代码能不能用不取决于它写得多漂亮而取决于有没有东西能验证它。类型检查、单元测试、集成测试、lint规则这些构成了一个自动化的“验收网”。有了这张网人类工程师才敢放手让AI写80%的代码——因为写错了会被网拦住。提示如果你所在的团队想提升AI代码占比优先投入的不是买更贵的模型而是把测试覆盖率和类型检查做扎实。验证网越密你敢交给AI的活就越多。2.3 为什么是“这家公司”先达到80%这里有个很现实的逻辑越是自己造模型的公司越有条件把AI编程用到极致。原因不复杂。第一他们有模型的第一手访问权能用上还没对外发布的能力延迟低、额度足、可以随便试。第二他们的工程师本身就是模型的使用者和反馈者工具迭代和工程实践是同步进行的。第三内部有强动机去证明“我们的模型真的能写代码”这既是产品验证也是对外宣传的素材。所以80%这个数字与其说是行业普遍水平不如说是“头部自研团队最激进工作流”的上限值。普通团队现在能稳定做到30%到50%已经算用得很好了。看到80%不用焦虑但要理解它代表的方向。3. 递归自我改进为什么“暂停”的呼声出现在这个节点3.1 用大白话解释递归自我改进递归自我改进这个词听起来很唬人拆开看其实很朴素AI系统被用来改进AI系统本身改进后的AI又去改进下一代如此循环。打个比方。假设你有一个会修车的学徒。一开始他只会换轮胎你教他怎么换发动机。学会之后他不仅能修车还能反过来教你新的修车方法甚至自己琢磨出你没教过的技巧。再往后他修车的水平超过了你开始自己带徒弟、自己改进工具。这个学徒的成长速度就不再受你的教学速度限制了。AI编程就是那个“学徒开始修发动机”的时刻。当AI能写代码而AI模型本身就是代码训练出来的那么用AI去优化训练代码、优化数据管线、优化模型结构就成了一条现实路径。这条路径一旦跑通迭代速度可能从“人类主导的月级”压缩到“AI主导的周级甚至天级”。3.2 80%这个数字为什么是信号弹单独看“AI写了80%的代码”它只是一个生产力指标。但把它和“递归自我改进”放在一起性质就变了。如果一家公司80%的代码是AI写的那么这家公司改进自己AI系统的代码也有80%是AI写的。这意味着AI系统迭代的主要执行者已经从人类变成了AI。人类退到了“定目标、做验收、踩刹车”的位置。这个位置重不重要非常重要。但它的瓶颈不再是“人手够不够”而是“判断力够不够、验证能力够不够、决策速度够不够”。当执行环节被AI大幅加速后整个系统的节奏就被人类的判断环节卡住了。而呼吁暂停本质上就是在说执行速度已经超过了我们判断和验证的速度这个错配是风险来源。3.3 呼吁暂停的三种真实动机我不想把这件事简单归结为“好人”或“作秀”。现实中公开呼吁暂停通常同时包含三种动机它们并不互斥。动机一真诚的安全担忧。这是最直接的一层。当团队内部亲眼看到AI迭代速度的曲线会比外部任何人更早感受到“失控感”。这种担忧是真实的哪怕表达方式带有公关色彩。动机二竞争节奏的调节。呼吁暂停是一种软性的节奏控制。如果全行业都慢下来对领先者未必是坏事——它可以把已经建立的工程优势固化下来把安全研究补上。而对追赶者来说被呼吁“暂停”则可能意味着错失窗口。动机三话语权与标准制定。谁定义了“安全AI”的标准谁就在下一阶段的竞争中占据道义和规则的高地。呼吁暂停的同时发布安全框架、威胁报告这套组合拳本身就是标准制定的一部分。理解这三层动机不是为了犬儒地否定安全担忧而是为了让你在看待任何“行业呼吁”时都能同时看到技术、竞争和话语权三条线。4. 普通开发者现在该怎么用AI编程工具4.1 工具选型别追最贵的追最顺手的市面上的AI编程工具大致分三类选型逻辑完全不同。类型代表形态适合场景主要成本编辑器内补全行内建议、函数级补全日常写业务代码、补样板订阅费低学习成本几乎为零对话式助手侧边栏聊天、选中代码提问理解陌生代码、写测试、重构需要学会提问效果波动大命令行Agent终端里跑任务、多文件编辑批量改造、脚手架搭建、修bug学习曲线陡需要验证网兜底我的建议是从编辑器内补全开始用顺了再上Agent。很多人一上来就折腾命令行Agent结果因为不会写任务描述、没有测试兜底被AI改得一团糟最后得出“AI编程不靠谱”的结论。这不是工具的问题是上手顺序的问题。选型时重点看三个指标一是上下文理解范围能不能跨文件二是响应延迟补全超过一秒就打断心流三是是否支持你的技术栈有些工具对主流语言支持好对小众框架就一般。4.2 提问方式决定产出质量AI编程工具用得好不好八成取决于你怎么描述任务。我踩过的坑基本都集中在“说得太笼统”。对比一下两种说法差的说法“帮我优化这个函数。”好的说法“这个函数处理用户订单现在的问题是当订单项超过100条时循环里每次都查数据库。请改成先批量查出所有商品再用字典映射保持返回结构不变。”第二种说法里包含了业务背景、当前问题、期望方案、约束条件。AI拿到这些信息产出的代码基本能直接用。第一种说法AI只能猜猜错是常态。再进阶一点可以给AI设定角色和验收标准“你是一个熟悉本项目规范的工程师改完后要保证现有单元测试全部通过不要引入新的依赖。”这句话能显著降低AI乱加库、乱改接口的概率。4.3 验证网让AI敢写的前提前面反复提到验证网这里具体说说怎么搭。最小可用的验证网包括三层类型检查静态类型语言天然有优势动态类型语言至少上lint和类型注解检查。单元测试核心业务逻辑必须有测试覆盖AI改完跑一遍红了就回滚。集成测试跨模块的调用链要有端到端测试防止AI改了一个文件、崩了另一个模块。这三层不需要一次到位。我的经验是先把单元测试覆盖率提到关键路径全覆盖AI编程的可用性就会有质的提升。因为大部分AI引入的bug都是逻辑错误单元测试能拦住其中很大一部分。注意不要让AI同时改代码和改测试。如果AI既写实现又写测试它可能写出“刚好通过自己测试”的代码而不是正确的代码。测试最好由人类写或者至少由人类review。5. 实操搭一套能跑通的AI编程工作流5.1 环境准备与基础配置假设你用的是主流的编辑器加AI插件组合下面是一套我实测下来比较稳的配置思路。第一步把项目的基础检查命令固化下来。在项目根目录放一个脚本比如check.sh里面依次跑格式化、lint、类型检查、单元测试。这个脚本是后面所有AI工作流的“验收按钮”。#!/bin/bash set -e echo 格式化 npx prettier --write src/**/*.{ts,tsx} echo Lint npx eslint src --ext .ts,.tsx echo 类型检查 npx tsc --noEmit echo 单元测试 npx jest --silent echo 全部通过第二步给AI工具配置项目级的规则文件。大多数工具支持一个类似.ai-rules或项目说明的文件把你团队的编码约定写进去命名风格、目录结构、错误处理方式、禁止使用的库。这个文件相当于给AI的“员工手册”写一次省很多事。第三步配置好版本控制的分支策略。AI改代码要在一个独立分支上做改完跑check.sh通过了再合并。永远不要让AI直接改主分支。5.2 一个完整的任务执行流程拿一个真实场景举例给现有API增加一个“按标签筛选”的查询参数。第一步人类写任务描述。不要直接让AI动手先让它读代码、给方案。描述里写清楚涉及哪个接口、参数叫什么、筛选逻辑是什么、返回结构变不变、要不要分页。第二步让AI先输出计划。让它列出打算改哪些文件、每个文件改什么。这一步是低成本的纠错机会方案错了改方案比改代码便宜得多。第三步AI执行修改。确认计划后让它逐个文件改。改的过程中盯着diff看尤其是它有没有顺手改掉不该改的东西。第四步跑验证。执行check.sh。如果挂了把报错原样贴给AI让它修。修两轮还不过就回滚自己上手或者重新描述任务。第五步人类review。重点看三样边界条件处理、错误处理、有没有引入隐藏的性能问题。AI写的代码在“正常路径”上通常没问题坑往往在异常路径。这套流程跑熟之后一个中等复杂度的需求从描述到合并大概十几分钟其中人类真正动手的时间不到三分之一。5.3 参数与提示词的具体写法关于提示词我总结了一个可复用的模板结构背景这个模块是做什么的当前有什么问题 目标这次要达成什么验收标准是什么 约束不能改什么必须保持什么不变 参考相关的文件路径、类型定义、已有实现把这四段写清楚AI的产出质量会稳定很多。尤其是“约束”这一段很多人不写结果AI为了完成任务把接口签名改了引发一连串连锁修改。还有一个技巧让AI先复述任务再动手。在提示词末尾加一句“先复述你对任务的理解确认后再开始改”。这一步能过滤掉相当一部分理解偏差。6. 常见问题与排查技巧实录6.1 AI改完代码跑不起来怎么快速定位这是最高频的问题。我的排查顺序是固定的先看报错类型。语法错误通常是AI漏了括号或引号直接让它修。类型错误往往是它没读到相关类型定义把类型文件路径贴给它。运行时错误最麻烦需要看堆栈。看diff范围。如果AI改了五个文件先怀疑它改多了。把改动范围缩到最小逐个文件回滚测试。看是不是环境问题。有时候代码没问题是依赖没装、缓存没清。先跑一遍干净安装再判断。一个反直觉的经验AI改完跑不起来八成不是它写错了而是它没看到足够的上下文。与其让它反复修不如把相关文件、类型、调用方一次性喂给它。6.2 AI写的代码“看起来对但实际有坑”这类问题最危险因为测试可能都过。常见的坑有这么几种边界条件空数组、null、超长字符串、并发调用AI经常只处理正常路径。错误吞掉AI喜欢写try/catch然后什么都不做或者只打日志不抛错。性能陷阱循环里查数据库、嵌套循环、没加索引的查询AI不会主动优化。隐式依赖AI可能引入一个你没注意到的全局状态或单例。对付这些坑我的做法是在review清单里固定几条每个新增的catch块都要问“这里吞掉错误合理吗”每个循环都要问“数据量大了会怎样”每个新依赖都要问“非加不可吗”。6.3 常见问题速查表现象可能原因处理方式AI反复改同一个错上下文不足或任务描述有歧义补充相关文件重写任务描述改完测试全红改动范围过大回滚拆成小任务逐个做代码能跑但风格不符缺少项目规则文件补.ai-rules把约定写进去AI引入新依赖没在约束里禁止提示词里明确“不新增依赖”补全延迟高项目太大或索引未建好缩小索引范围排除构建产物生成的代码有安全风险缺少安全审查环节敏感操作必须人工review6.4 几条踩坑换来的经验经验一AI擅长“有先例的活”不擅长“没先例的活”。如果项目里已经有类似的实现让AI照着写成功率极高。如果是全新的架构设计AI给的方案往往似是而非这时候人类要先定框架。经验二把大任务拆成小任务是使用AI编程最重要的技能。一个“重构用户模块”的任务丢给AI结果一定失控。拆成“把用户查询抽成独立函数”“给这个函数加缓存”“补上单元测试”三个小任务每个都能稳稳完成。经验三AI写的代码注释往往比代码本身更值得看。它会在注释里暴露自己的假设。如果注释里写的假设和你的业务不符代码大概率有问题。经验四不要用AI去改你不理解的代码。这是安全底线。你不理解就无法判断AI改得对不对验证网也兜不住认知盲区。7. 关于“暂停”这件事一个从业者的个人判断回到最开始那条新闻。80%的代码由AI写然后呼吁暂停这两件事放在一起我认为它传递的核心信息不是“AI要失控了”而是**“执行速度已经跑到了判断速度前面”**。作为一个每天用AI编程工具的人我的真实体感是工具确实强强到能明显改变工作节奏。但“强”和“危险”之间还有很长的距离。真正需要警惕的不是AI会写代码而是当AI写代码的速度远超人类审查速度时那些没被审查到的代码会累积成什么样的系统。对普通开发者来说这件事的实用启示很朴素把验证能力当成核心竞争力来建设。谁能更快、更准地判断AI产出的对错谁就能在AI编程时代拿到更大的杠杆。写代码这件事正在被工具接管但判断代码好坏这件事短期内还是人的活。我个人的做法是每引入一个新的AI工作流先花时间把对应的验证手段补齐再逐步放权。放权的节奏取决于验证网的密度而不是取决于工具宣传的能力上限。这个原则我觉得比任何“暂停”或“加速”的口号都更值得参考。 AI编程工具实战：80%代码由AI生成，递归自我改进与验证网建设
1. 这件事到底在说什么从一条新闻拆出三层信息先把事实摆清楚。有一家做AI的公司公开表示自家代码库里大约80%的代码是AI写的同时这家公司又站出来呼吁“暂停AI开发”。这两句话放在一起本身就构成了一个巨大的张力一边是AI编程工具已经把生产力拉到了这个程度另一边是造工具的人自己开始踩刹车。很多人看到这条消息的第一反应是“作秀”“营销”“又要监管别人不监管自己”。但如果只停在这个层面就浪费了这条新闻真正的信息量。我更愿意把它拆成三层来看。第一层是工程事实层80%的代码由AI生成这个数字意味着什么它意味着在这家公司的日常研发流程里AI已经不是“辅助补全”的角色而是主力写手。人类工程师的工作重心从“写代码”转移到了“审代码、定架构、写测试、做决策”。第二层是能力演进层为什么偏偏是现在喊停关键词里有一个很扎眼的词——递归自我改进。当AI能写代码而AI本身又是代码构成的那么“AI改进AI”的闭环就具备了物理基础。80%这个数字正是这个闭环开始转动的信号。第三层是行业博弈层呼吁暂停这件事从来不只是技术问题。谁呼吁、呼吁什么、呼吁的同时自己在做什么这三件事要分开看。历史上每一次“暂停某技术”的公开信背后都夹杂着竞争节奏、人才争夺、话语权卡位。我写这篇东西不是要复述新闻而是想把这条新闻背后的技术现实讲透AI编程工具现在到底能做到什么程度所谓“80%代码是AI写的”在工程上是怎么实现的递归自我改进离我们还有多远以及作为一个普通开发者你现在应该怎么用这些工具、怎么防坑。适合谁看正在用或准备用AI编程工具的开发者、技术团队负责人、对AI能力边界好奇的产品和运营同学。不需要你是算法专家但需要你对“写代码”这件事有基本概念。2. 80%代码由AI生成工程上是怎么做到的2.1 先搞清楚“AI写的代码”到底指什么“80%的代码是AI写的”这句话如果不加限定很容易被误读。它绝不是说“AI独立完成了80%的软件系统”。真实情况通常是这样的在一个成熟的AI编程工作流里代码的产生方式被拆成了若干环节AI在其中承担了大部分字符级产出。具体来说AI参与的代码产出大致分这么几类行内补全你敲一个函数名AI把整个函数体补出来。这是最基础的一层类似早期的代码补全但现在的模型能补出几十行带业务逻辑的代码。对话式生成你用自然语言描述需求AI生成一整段模块代码你复制粘贴或让它直接写入文件。多文件编辑AI根据一个任务描述同时修改多个文件包括新增文件、修改引用、更新配置。这是当前AI编程工具的核心能力。测试与修复AI根据报错信息自动定位问题并给出修复补丁或者根据现有代码反向生成单元测试。所谓80%大概率是把上述所有环节产生的代码行数加总再除以总提交行数得到的比例。这个统计口径本身有水分——比如AI生成的代码被人类改了三遍才合并算谁的但即便打个对折40%的代码由AI产出也已经是一个质变的数字。2.2 支撑这个比例的三个技术支点要让AI稳定产出可用代码光有一个会聊天的模型是不够的。背后至少有三个技术支点在撑着。第一个支点是长上下文与代码库索引。早期的AI编程工具只能看到你当前打开的文件稍微跨个文件就抓瞎。现在的工具会把整个代码仓库做向量化索引AI在生成代码前能检索到相关的类型定义、工具函数、调用约定。这就是为什么现在的AI能写出“符合本项目风格”的代码而不是一段放之四海皆准但跑不起来的样板。第二个支点是工具调用能力。也就是常说的Agent能力。AI不只是生成文本它还能调用“读文件”“写文件”“执行命令”“跑测试”这些工具。一个任务交给它它会自己规划先读哪些文件了解上下文再改哪些文件改完跑一下测试测试挂了再回来改。这个循环一旦跑通AI就从“打字员”变成了“能自己干活的初级工程师”。第三个支点是验证闭环。这是最容易被忽略但最关键的一环。AI写的代码能不能用不取决于它写得多漂亮而取决于有没有东西能验证它。类型检查、单元测试、集成测试、lint规则这些构成了一个自动化的“验收网”。有了这张网人类工程师才敢放手让AI写80%的代码——因为写错了会被网拦住。提示如果你所在的团队想提升AI代码占比优先投入的不是买更贵的模型而是把测试覆盖率和类型检查做扎实。验证网越密你敢交给AI的活就越多。2.3 为什么是“这家公司”先达到80%这里有个很现实的逻辑越是自己造模型的公司越有条件把AI编程用到极致。原因不复杂。第一他们有模型的第一手访问权能用上还没对外发布的能力延迟低、额度足、可以随便试。第二他们的工程师本身就是模型的使用者和反馈者工具迭代和工程实践是同步进行的。第三内部有强动机去证明“我们的模型真的能写代码”这既是产品验证也是对外宣传的素材。所以80%这个数字与其说是行业普遍水平不如说是“头部自研团队最激进工作流”的上限值。普通团队现在能稳定做到30%到50%已经算用得很好了。看到80%不用焦虑但要理解它代表的方向。3. 递归自我改进为什么“暂停”的呼声出现在这个节点3.1 用大白话解释递归自我改进递归自我改进这个词听起来很唬人拆开看其实很朴素AI系统被用来改进AI系统本身改进后的AI又去改进下一代如此循环。打个比方。假设你有一个会修车的学徒。一开始他只会换轮胎你教他怎么换发动机。学会之后他不仅能修车还能反过来教你新的修车方法甚至自己琢磨出你没教过的技巧。再往后他修车的水平超过了你开始自己带徒弟、自己改进工具。这个学徒的成长速度就不再受你的教学速度限制了。AI编程就是那个“学徒开始修发动机”的时刻。当AI能写代码而AI模型本身就是代码训练出来的那么用AI去优化训练代码、优化数据管线、优化模型结构就成了一条现实路径。这条路径一旦跑通迭代速度可能从“人类主导的月级”压缩到“AI主导的周级甚至天级”。3.2 80%这个数字为什么是信号弹单独看“AI写了80%的代码”它只是一个生产力指标。但把它和“递归自我改进”放在一起性质就变了。如果一家公司80%的代码是AI写的那么这家公司改进自己AI系统的代码也有80%是AI写的。这意味着AI系统迭代的主要执行者已经从人类变成了AI。人类退到了“定目标、做验收、踩刹车”的位置。这个位置重不重要非常重要。但它的瓶颈不再是“人手够不够”而是“判断力够不够、验证能力够不够、决策速度够不够”。当执行环节被AI大幅加速后整个系统的节奏就被人类的判断环节卡住了。而呼吁暂停本质上就是在说执行速度已经超过了我们判断和验证的速度这个错配是风险来源。3.3 呼吁暂停的三种真实动机我不想把这件事简单归结为“好人”或“作秀”。现实中公开呼吁暂停通常同时包含三种动机它们并不互斥。动机一真诚的安全担忧。这是最直接的一层。当团队内部亲眼看到AI迭代速度的曲线会比外部任何人更早感受到“失控感”。这种担忧是真实的哪怕表达方式带有公关色彩。动机二竞争节奏的调节。呼吁暂停是一种软性的节奏控制。如果全行业都慢下来对领先者未必是坏事——它可以把已经建立的工程优势固化下来把安全研究补上。而对追赶者来说被呼吁“暂停”则可能意味着错失窗口。动机三话语权与标准制定。谁定义了“安全AI”的标准谁就在下一阶段的竞争中占据道义和规则的高地。呼吁暂停的同时发布安全框架、威胁报告这套组合拳本身就是标准制定的一部分。理解这三层动机不是为了犬儒地否定安全担忧而是为了让你在看待任何“行业呼吁”时都能同时看到技术、竞争和话语权三条线。4. 普通开发者现在该怎么用AI编程工具4.1 工具选型别追最贵的追最顺手的市面上的AI编程工具大致分三类选型逻辑完全不同。类型代表形态适合场景主要成本编辑器内补全行内建议、函数级补全日常写业务代码、补样板订阅费低学习成本几乎为零对话式助手侧边栏聊天、选中代码提问理解陌生代码、写测试、重构需要学会提问效果波动大命令行Agent终端里跑任务、多文件编辑批量改造、脚手架搭建、修bug学习曲线陡需要验证网兜底我的建议是从编辑器内补全开始用顺了再上Agent。很多人一上来就折腾命令行Agent结果因为不会写任务描述、没有测试兜底被AI改得一团糟最后得出“AI编程不靠谱”的结论。这不是工具的问题是上手顺序的问题。选型时重点看三个指标一是上下文理解范围能不能跨文件二是响应延迟补全超过一秒就打断心流三是是否支持你的技术栈有些工具对主流语言支持好对小众框架就一般。4.2 提问方式决定产出质量AI编程工具用得好不好八成取决于你怎么描述任务。我踩过的坑基本都集中在“说得太笼统”。对比一下两种说法差的说法“帮我优化这个函数。”好的说法“这个函数处理用户订单现在的问题是当订单项超过100条时循环里每次都查数据库。请改成先批量查出所有商品再用字典映射保持返回结构不变。”第二种说法里包含了业务背景、当前问题、期望方案、约束条件。AI拿到这些信息产出的代码基本能直接用。第一种说法AI只能猜猜错是常态。再进阶一点可以给AI设定角色和验收标准“你是一个熟悉本项目规范的工程师改完后要保证现有单元测试全部通过不要引入新的依赖。”这句话能显著降低AI乱加库、乱改接口的概率。4.3 验证网让AI敢写的前提前面反复提到验证网这里具体说说怎么搭。最小可用的验证网包括三层类型检查静态类型语言天然有优势动态类型语言至少上lint和类型注解检查。单元测试核心业务逻辑必须有测试覆盖AI改完跑一遍红了就回滚。集成测试跨模块的调用链要有端到端测试防止AI改了一个文件、崩了另一个模块。这三层不需要一次到位。我的经验是先把单元测试覆盖率提到关键路径全覆盖AI编程的可用性就会有质的提升。因为大部分AI引入的bug都是逻辑错误单元测试能拦住其中很大一部分。注意不要让AI同时改代码和改测试。如果AI既写实现又写测试它可能写出“刚好通过自己测试”的代码而不是正确的代码。测试最好由人类写或者至少由人类review。5. 实操搭一套能跑通的AI编程工作流5.1 环境准备与基础配置假设你用的是主流的编辑器加AI插件组合下面是一套我实测下来比较稳的配置思路。第一步把项目的基础检查命令固化下来。在项目根目录放一个脚本比如check.sh里面依次跑格式化、lint、类型检查、单元测试。这个脚本是后面所有AI工作流的“验收按钮”。#!/bin/bash set -e echo 格式化 npx prettier --write src/**/*.{ts,tsx} echo Lint npx eslint src --ext .ts,.tsx echo 类型检查 npx tsc --noEmit echo 单元测试 npx jest --silent echo 全部通过第二步给AI工具配置项目级的规则文件。大多数工具支持一个类似.ai-rules或项目说明的文件把你团队的编码约定写进去命名风格、目录结构、错误处理方式、禁止使用的库。这个文件相当于给AI的“员工手册”写一次省很多事。第三步配置好版本控制的分支策略。AI改代码要在一个独立分支上做改完跑check.sh通过了再合并。永远不要让AI直接改主分支。5.2 一个完整的任务执行流程拿一个真实场景举例给现有API增加一个“按标签筛选”的查询参数。第一步人类写任务描述。不要直接让AI动手先让它读代码、给方案。描述里写清楚涉及哪个接口、参数叫什么、筛选逻辑是什么、返回结构变不变、要不要分页。第二步让AI先输出计划。让它列出打算改哪些文件、每个文件改什么。这一步是低成本的纠错机会方案错了改方案比改代码便宜得多。第三步AI执行修改。确认计划后让它逐个文件改。改的过程中盯着diff看尤其是它有没有顺手改掉不该改的东西。第四步跑验证。执行check.sh。如果挂了把报错原样贴给AI让它修。修两轮还不过就回滚自己上手或者重新描述任务。第五步人类review。重点看三样边界条件处理、错误处理、有没有引入隐藏的性能问题。AI写的代码在“正常路径”上通常没问题坑往往在异常路径。这套流程跑熟之后一个中等复杂度的需求从描述到合并大概十几分钟其中人类真正动手的时间不到三分之一。5.3 参数与提示词的具体写法关于提示词我总结了一个可复用的模板结构背景这个模块是做什么的当前有什么问题 目标这次要达成什么验收标准是什么 约束不能改什么必须保持什么不变 参考相关的文件路径、类型定义、已有实现把这四段写清楚AI的产出质量会稳定很多。尤其是“约束”这一段很多人不写结果AI为了完成任务把接口签名改了引发一连串连锁修改。还有一个技巧让AI先复述任务再动手。在提示词末尾加一句“先复述你对任务的理解确认后再开始改”。这一步能过滤掉相当一部分理解偏差。6. 常见问题与排查技巧实录6.1 AI改完代码跑不起来怎么快速定位这是最高频的问题。我的排查顺序是固定的先看报错类型。语法错误通常是AI漏了括号或引号直接让它修。类型错误往往是它没读到相关类型定义把类型文件路径贴给它。运行时错误最麻烦需要看堆栈。看diff范围。如果AI改了五个文件先怀疑它改多了。把改动范围缩到最小逐个文件回滚测试。看是不是环境问题。有时候代码没问题是依赖没装、缓存没清。先跑一遍干净安装再判断。一个反直觉的经验AI改完跑不起来八成不是它写错了而是它没看到足够的上下文。与其让它反复修不如把相关文件、类型、调用方一次性喂给它。6.2 AI写的代码“看起来对但实际有坑”这类问题最危险因为测试可能都过。常见的坑有这么几种边界条件空数组、null、超长字符串、并发调用AI经常只处理正常路径。错误吞掉AI喜欢写try/catch然后什么都不做或者只打日志不抛错。性能陷阱循环里查数据库、嵌套循环、没加索引的查询AI不会主动优化。隐式依赖AI可能引入一个你没注意到的全局状态或单例。对付这些坑我的做法是在review清单里固定几条每个新增的catch块都要问“这里吞掉错误合理吗”每个循环都要问“数据量大了会怎样”每个新依赖都要问“非加不可吗”。6.3 常见问题速查表现象可能原因处理方式AI反复改同一个错上下文不足或任务描述有歧义补充相关文件重写任务描述改完测试全红改动范围过大回滚拆成小任务逐个做代码能跑但风格不符缺少项目规则文件补.ai-rules把约定写进去AI引入新依赖没在约束里禁止提示词里明确“不新增依赖”补全延迟高项目太大或索引未建好缩小索引范围排除构建产物生成的代码有安全风险缺少安全审查环节敏感操作必须人工review6.4 几条踩坑换来的经验经验一AI擅长“有先例的活”不擅长“没先例的活”。如果项目里已经有类似的实现让AI照着写成功率极高。如果是全新的架构设计AI给的方案往往似是而非这时候人类要先定框架。经验二把大任务拆成小任务是使用AI编程最重要的技能。一个“重构用户模块”的任务丢给AI结果一定失控。拆成“把用户查询抽成独立函数”“给这个函数加缓存”“补上单元测试”三个小任务每个都能稳稳完成。经验三AI写的代码注释往往比代码本身更值得看。它会在注释里暴露自己的假设。如果注释里写的假设和你的业务不符代码大概率有问题。经验四不要用AI去改你不理解的代码。这是安全底线。你不理解就无法判断AI改得对不对验证网也兜不住认知盲区。7. 关于“暂停”这件事一个从业者的个人判断回到最开始那条新闻。80%的代码由AI写然后呼吁暂停这两件事放在一起我认为它传递的核心信息不是“AI要失控了”而是**“执行速度已经跑到了判断速度前面”**。作为一个每天用AI编程工具的人我的真实体感是工具确实强强到能明显改变工作节奏。但“强”和“危险”之间还有很长的距离。真正需要警惕的不是AI会写代码而是当AI写代码的速度远超人类审查速度时那些没被审查到的代码会累积成什么样的系统。对普通开发者来说这件事的实用启示很朴素把验证能力当成核心竞争力来建设。谁能更快、更准地判断AI产出的对错谁就能在AI编程时代拿到更大的杠杆。写代码这件事正在被工具接管但判断代码好坏这件事短期内还是人的活。我个人的做法是每引入一个新的AI工作流先花时间把对应的验证手段补齐再逐步放权。放权的节奏取决于验证网的密度而不是取决于工具宣传的能力上限。这个原则我觉得比任何“暂停”或“加速”的口号都更值得参考。