1. 问题到底出在哪AI 写代码效率反降的四个真相先说一个我观察了很久的现象。身边不少同行包括我自己带过的一些新人刚接触 AI 辅助编程那阵子兴奋得不行觉得从此写代码就是“说人话、出代码”。结果用了两三个月回头一算账发现一个功能模块的交付时间跟以前手写差不多甚至更慢。有人就得出结论AI 写代码是噱头效率还不如自己敲。这个结论下得太快了。我自己的体感是AI 写代码的效率不是线性提升的它更像一个放大器——你原本工程能力扎实它能把你放大到两三倍你原本流程混乱、需求模糊、不做验证它会把你的混乱同样放大最后产出比手写还差。所以问题不在“AI 行不行”而在“你用 AI 的方式对不对”。这篇文章我想把这件事彻底拆开讲。核心围绕四个层面需求表达的精度、上下文供给的质量、验证闭环的缺失、以及任务切分的粒度。这四个点几乎覆盖了所有“用 AI 写代码反而变慢”的场景。我会结合自己踩过的坑给出可直接抄作业的操作方法包括提示词结构、上下文组织方式、验证流程和任务拆分模板。不管你是刚上手 AI 编程的新人还是已经用了一段时间但感觉没提效的老手都能从里面找到对得上的问题。先给一个我自己的结论AI 写代码的效率瓶颈八成不在模型能力而在使用者的工程习惯。下面逐条拆。2. 需求表达精度你说的是“做个登录”AI 听到的是“随便做个登录”2.1 模糊需求是效率杀手我见过最典型的场景是这样的。某开发者打开 AI 对话框输入一句“帮我写一个用户登录功能”然后 AI 哗啦啦输出两百行代码包含表单、校验、接口调用、状态管理。看起来挺全但一跑就报错因为技术栈不对——项目用的是某个特定框架的组合式写法AI 默认给的是另一套写法。于是开始来回改改了三轮时间已经过去四十分钟手写可能二十分钟就搞定了。问题出在哪出在“登录功能”这四个字承载的信息量太低了。对 AI 来说它不知道你的技术栈、你的目录结构、你的接口约定、你的错误处理规范、你的状态管理方案。它只能按“最常见”的默认方案来猜。猜对了是运气猜错了就是返工。我后来总结出一个规律你给 AI 的信息量决定了它第一次输出的可用度。信息量不足它就只能给你一个“平均答案”而平均答案对你的具体项目来说往往就是错的。2.2 把需求写成“可执行规格”的四个要素那怎么才算信息量够我的做法是把需求拆成四个要素缺一不可技术栈与版本框架、语言、关键依赖的版本号。版本很重要同一个框架不同大版本的 API 差异可能很大不写清楚 AI 很容易给过时写法。输入与输出这个功能接收什么、返回什么数据结构长什么样。最好直接给一个示例数据。边界与异常空值怎么处理、超时怎么办、权限不足返回什么。这些是 AI 最容易忽略、也最容易在联调时爆雷的地方。约束条件代码风格、命名规范、不能引入哪些依赖、性能要求。我举个对比。模糊版是“写个登录功能”。规格版是这样技术栈某前端框架 3.x 组合式 API 某状态管理库 功能用户登录 输入{ username: string, password: string } 输出成功返回 { token, userInfo }失败返回 { code, message } 异常用户名密码为空时前端拦截接口 401 时提示“账号或密码错误” 约束不引入新的表单校验库用现有工具函数请求统一走项目封装的 request 方法你看同样一个登录功能第二种写法 AI 一次就能给出八九不离十的代码剩下的是微调。第一种写法你得来回问三四轮。这三四轮的时间就是被浪费掉的效率。2.3 一个反直觉的经验先写注释再让 AI 填代码我还有一个习惯可能跟很多人相反我不让 AI 从零生成而是先自己把函数签名和关键注释写好再让 AI 填充实现。比如我要写一个数据清洗函数我会先写def clean_user_records(records: list[dict]) - list[dict]: 清洗用户记录 1. 去除 user_id 为空的记录 2. 手机号统一去掉空格和横线 3. 邮箱统一转小写 4. 按 user_id 去重保留最后一条 # 让 AI 在这里填充这样做的好处是需求表达的责任在我代码实现的责任在 AI。我负责把“做什么”说清楚AI 负责“怎么做”。边界清晰返工率大幅下降。实测下来这种“注释驱动”的方式比直接描述需求快至少百分之三十因为注释本身就是结构化的规格说明AI 理解起来几乎没有歧义。注意注释里不要写“处理一下数据”这种废话要写清楚每一步的具体规则。规则越具体AI 输出越准。3. 上下文供给AI 不是读心术你得把项目“喂”给它3.1 为什么 AI 总写出“风格不对”的代码第二个大坑是上下文缺失。很多人用 AI 是在一个空白对话框里进行的AI 对你的项目一无所知。它不知道你的工具函数放在哪、你的请求封装长什么样、你的组件命名习惯是什么。于是它只能按通用写法来结果就是“能跑但跟项目格格不入”。我踩过最惨的一次是让 AI 写一个列表页。它给了一个完整的组件里面自己封装了一套请求逻辑。但我们项目早就有统一的请求封装还带了拦截器和错误提示。AI 那套代码一进去等于在项目里开了个“法外之地”后面维护的人一看就头大。最后我花的时间不是写代码而是把 AI 的代码“翻译”成项目风格。这件事让我意识到AI 的效率损失很大一部分发生在“代码风格对齐”这个环节。而这个环节本可以避免只要你把项目上下文喂给 AI。3.2 三种上下文供给方式按场景选我目前常用的有三种方式各有适用场景方式做法适用场景效率粘贴关键文件把相关的工具函数、类型定义、请求封装直接贴进对话单次任务改动范围小中项目规则文件在项目根目录放一个规则说明文件AI 工具自动读取长期项目多人协作高检索增强让 AI 工具索引整个代码库按需检索相关代码大型项目跨模块改动高第一种最直接但每次都要手动贴适合临时用。第二种是我最推荐的很多 AI 编程工具都支持读取项目根目录的规则文件你只要把技术栈、目录结构、命名规范、常用工具写进去之后每次对话 AI 都会自动带上这些信息。第三种适合代码库很大的情况靠工具自动检索不用你操心。我自己的项目里规则文件大概长这样# 项目规则 ## 技术栈 - 前端某框架 3.x 某状态管理库 某 UI 库 - 请求统一使用 src/utils/request 封装 - 类型所有接口返回类型定义在 src/types 目录 ## 命名规范 - 组件文件用大驼峰工具函数用小驼峰 - 常量全大写下划线分隔 ## 禁止事项 - 不引入新的请求库 - 不在组件内直接写 fetch - 不写 any 类型这份文件不到三十行但它让 AI 的输出质量提升了一个档次。因为 AI 知道了“边界”在哪就不会乱来。3.3 上下文不是越多越好要给“相关”的这里有个误区要提醒上下文不是塞得越多越好。我有段时间把整个项目的关键文件都贴给 AI结果它反而抓不住重点输出变得又长又杂。后来我改成“只给跟当前任务相关的文件”效果立刻好转。判断标准很简单如果这个文件的内容会影响当前任务的实现方式就给不影响就不给。比如你写一个表单组件那类型定义、校验工具、UI 库用法要给但路由配置、状态管理的其他模块就不用给。给多了是噪音给少了是缺失这个度需要练几次才能拿捏准。4. 验证闭环AI 说“完成了”不代表真的完成了4.1 最危险的幻觉AI 的自信AI 有个特点它输出代码的时候语气特别自信动不动就说“这个实现已经考虑了所有边界情况”。但实际上它可能漏了空值判断可能把异步写成了同步可能引用了不存在的变量。如果你不验证就直接用那这些坑迟早会在联调或者上线时爆出来。我见过一个真实案例。某开发者让 AI 写一个分页查询AI 给了一段看起来很完整的代码包含页码计算、边界处理。开发者扫了一眼觉得没问题直接提交。结果测试的时候发现当总数为零时页码计算会返回负数导致接口报错。这个 bug 手写的时候可能也会犯但手写的人因为是自己一行行敲的脑子里有过程反而容易发现。AI 给的代码是“黑盒”出来的你不验证就等于把风险直接吞下去了。4.2 建立“生成-验证-修正”的闭环我的做法是AI 每给一段代码我必须走完三步才算完静态检查先看有没有明显的语法错误、未定义变量、类型不匹配。这一步靠肉眼加编辑器的提示。单元验证针对核心逻辑写几个测试用例尤其是边界情况。空值、零值、超长输入、并发场景都要覆盖。集成验证把代码放进项目里跑一遍看跟现有模块的交互是否正常。这三步听起来麻烦但实际做起来很快。而且它带来的收益是巨大的你省下的不是写代码的时间而是调试和返工的时间。我算过一笔账一段 AI 生成的代码如果不验证直接用平均要花一点五倍的时间去修 bug如果走完验证闭环修 bug 的时间能压到零点三倍。哪个划算一目了然。4.3 让 AI 自己写测试但你要审测试有个提效技巧让 AI 顺便把测试也写了。比如你让它写一个函数可以追加一句“同时给出覆盖边界情况的单元测试”。这样你拿到的不只是实现还有验证手段。但这里有个坑AI 写的测试可能跟实现一样有盲区。它可能只测了正常路径没测异常路径或者测试断言写得太宽松什么都通过。所以测试代码你必须自己审一遍重点看它有没有覆盖你关心的边界。我一般会追问一句“如果输入为空数组这个测试会通过吗”逼着 AI 把边界补全。提示验证闭环里最容易被跳过的是“集成验证”。很多人觉得单元测试过了就行但实际项目里模块之间的交互才是 bug 重灾区。别省这一步。5. 任务切分粒度大任务交给 AI等于让它猜谜5.1 为什么“帮我重构这个模块”是个坏指令我早期犯过一个错就是给 AI 下大任务。比如“帮我重构这个用户模块提升可维护性”。AI 收到这种指令会输出一大堆改动但改完之后你根本不知道它动了哪些地方也不敢直接用。最后要么全部推翻重来要么花大量时间逐行 review效率反而更低。问题在于大任务的约束条件太多AI 无法同时满足。重构一个模块涉及命名、拆分、依赖调整、接口兼容每一项都有多种选择。AI 只能按它的理解来而它的理解大概率跟你的预期不一致。5.2 把任务切到“一次对话能完成”的粒度我现在的原则是一个任务一次对话一个明确的产出。具体怎么切我总结了一个“三问法”这个任务能不能用一句话说清楚输入和输出这个任务的改动范围能不能控制在一个文件或一个函数内这个任务完成后我能不能用几个测试用例验证三个问题都是“是”那这个粒度就合适。有一个是“否”就继续切。举个例子。“重构用户模块”太大切成“把用户模块里的手机号校验逻辑抽成一个独立函数”就合适了。前者 AI 会给你一堆改动后者 AI 给你一个函数加几行调用清晰可控。5.3 切分之后用“流水线”串起来切分不是目的串起来才是。我的做法是把大任务拆成一条流水线每个环节交给 AI 做一小步我自己做衔接和验证。比如开发一个完整的列表页我会拆成定义数据类型AI 生成我审写请求函数AI 生成我审写列表组件骨架AI 生成我审接入请求和状态AI 生成我审处理加载和错误状态AI 生成我审写测试AI 生成我审每一步都是小任务AI 输出快我验证也快。整条流水线走下来比让 AI 一次性生成整个页面要稳得多也快得多。因为每一步的产出都是可验证的不会到最后才发现方向错了。6. 工具选型与协作模式别把 AI 当打字机要当结对伙伴6.1 不同工具的定位不一样市面上的 AI 编程工具大致分三类定位完全不同对话式工具适合讨论方案、解释代码、生成片段。优势是灵活劣势是上下文要手动管理。编辑器内联工具适合在写代码时实时补全、局部修改。优势是上下文自动带上劣势是只能做小改动。智能体式工具适合执行多步骤任务比如“把这个功能实现并跑通测试”。优势是自动化程度高劣势是需要清晰的指令和验证机制。我的用法是三者结合方案讨论用对话式日常编码用内联式重复性任务用智能体式。比如我要设计一个数据结构先跟对话式工具聊清楚然后在编辑器里用内联工具写具体代码最后用智能体工具批量补测试。各司其职效率最高。6.2 协作模式你负责“判断”AI 负责“产出”用久了会发现AI 编程的本质是把“执行”外包出去把“判断”留给自己。AI 能快速产出代码但它不知道这段代码在你的项目里合不合适、有没有隐患、符不符合业务预期。这些判断必须你来做。所以高效的协作模式是你定义问题、给约束、做验证AI 生成方案、写实现、补测试。你越清楚自己要什么AI 越能帮上忙。你越模糊AI 越容易跑偏。这跟带新人的逻辑一模一样——你不能指望一个新人猜出你的心思你得把要求说清楚。6.3 一个提效细节让 AI 解释它自己的代码我有个习惯AI 给出代码后会追加一句“解释这段代码的关键逻辑和潜在风险”。这一步有两个好处一是逼 AI 自己 review 一遍有时候它解释着解释着就发现自己的 bug 了二是帮我快速理解代码尤其是它用了我不熟悉的写法时。实测下来这个习惯能提前拦下不少问题。有一次 AI 写了一段异步逻辑解释的时候说“这里假设请求一定成功”我立刻意识到它没处理失败情况当场补上。如果我不问这个假设就会一直藏着直到线上出问题。7. 常见问题速查与避坑清单7.1 高频问题对照表问题现象根本原因解决方向AI 代码跑不起来技术栈或版本没说清补充技术栈、版本、依赖信息代码风格跟项目不符缺少项目上下文提供规则文件或相关文件改了几轮还是不对需求表达太模糊用四要素重写需求上线后才发现 bug跳过验证闭环补单元测试和集成验证大改动不敢用任务粒度太大拆成小任务逐个验证AI 反复给错方案上下文有噪音或缺失精简上下文只给相关的7.2 我踩过的三个坑第一个坑过度信任 AI 的“完成”声明。早期我让 AI 写代码它说“已完成”我就直接用。结果发现它经常漏掉异常处理。后来我养成习惯不管它说得多肯定我都要自己跑一遍边界用例。第二个坑上下文给太多。有次我把整个项目的十几个文件贴进去AI 输出变得又长又乱还引用了不相关的模块。后来我学会只给当前任务相关的文件输出立刻清爽了。第三个坑任务切太细。有段时间我矫枉过正把任务切得特别碎结果每次对话都要重新交代上下文反而更慢。后来找到平衡点一个任务对应一个明确的产出上下文能复用就复用。7.3 一份可直接抄的检查清单每次用 AI 写代码前我会快速过一遍这个清单技术栈和版本写清楚了吗输入输出和数据结构给了吗边界和异常情况说明了吗项目规则文件在吗相关文件贴了吗任务粒度是不是一次对话能完成拿到代码后验证三步走了吗这六个问题基本覆盖了 AI 编程效率的所有关键点。养成习惯之后你会发现 AI 的输出质量稳定很多返工率大幅下降。8. 我个人的实操体会说到底AI 写代码效率不如手写绝大多数时候不是 AI 的问题是使用方式的问题。我自己从“用 AI 反而更慢”到“用 AI 稳定提效”中间隔的就是上面这些习惯的养成。最大的转变发生在我不再把 AI 当“打字机”而是当“结对伙伴”之后。打字机是你给它什么它打什么结对伙伴是你们一起把事做成。你要给它清晰的规格、足够的上下文、明确的验证标准它才能发挥出真正的价值。还有一个体会是AI 时代工程能力的重要性不降反升。因为 AI 能快速产出代码所以“判断代码好不好”的能力变得更关键。你越懂工程越能驾驭 AI你越不懂越容易被 AI 带偏。这跟开车一样车越快对驾驶员的要求越高而不是越低。最后分享一个小技巧每次用 AI 完成一个任务后花两分钟复盘一下这次哪里卡住了。是需求没说清还是上下文没给够还是验证没做。把卡点记下来下次避开。坚持一段时间你会发现自己用 AI 的效率曲线是往上走的而不是原地打转。 
长河君 · 2026/10/13 4:56:04 · 阅读 1.2k AI写代码效率反降？四个工程习惯决定提效成败
1. 问题到底出在哪AI 写代码效率反降的四个真相先说一个我观察了很久的现象。身边不少同行包括我自己带过的一些新人刚接触 AI 辅助编程那阵子兴奋得不行觉得从此写代码就是“说人话、出代码”。结果用了两三个月回头一算账发现一个功能模块的交付时间跟以前手写差不多甚至更慢。有人就得出结论AI 写代码是噱头效率还不如自己敲。这个结论下得太快了。我自己的体感是AI 写代码的效率不是线性提升的它更像一个放大器——你原本工程能力扎实它能把你放大到两三倍你原本流程混乱、需求模糊、不做验证它会把你的混乱同样放大最后产出比手写还差。所以问题不在“AI 行不行”而在“你用 AI 的方式对不对”。这篇文章我想把这件事彻底拆开讲。核心围绕四个层面需求表达的精度、上下文供给的质量、验证闭环的缺失、以及任务切分的粒度。这四个点几乎覆盖了所有“用 AI 写代码反而变慢”的场景。我会结合自己踩过的坑给出可直接抄作业的操作方法包括提示词结构、上下文组织方式、验证流程和任务拆分模板。不管你是刚上手 AI 编程的新人还是已经用了一段时间但感觉没提效的老手都能从里面找到对得上的问题。先给一个我自己的结论AI 写代码的效率瓶颈八成不在模型能力而在使用者的工程习惯。下面逐条拆。2. 需求表达精度你说的是“做个登录”AI 听到的是“随便做个登录”2.1 模糊需求是效率杀手我见过最典型的场景是这样的。某开发者打开 AI 对话框输入一句“帮我写一个用户登录功能”然后 AI 哗啦啦输出两百行代码包含表单、校验、接口调用、状态管理。看起来挺全但一跑就报错因为技术栈不对——项目用的是某个特定框架的组合式写法AI 默认给的是另一套写法。于是开始来回改改了三轮时间已经过去四十分钟手写可能二十分钟就搞定了。问题出在哪出在“登录功能”这四个字承载的信息量太低了。对 AI 来说它不知道你的技术栈、你的目录结构、你的接口约定、你的错误处理规范、你的状态管理方案。它只能按“最常见”的默认方案来猜。猜对了是运气猜错了就是返工。我后来总结出一个规律你给 AI 的信息量决定了它第一次输出的可用度。信息量不足它就只能给你一个“平均答案”而平均答案对你的具体项目来说往往就是错的。2.2 把需求写成“可执行规格”的四个要素那怎么才算信息量够我的做法是把需求拆成四个要素缺一不可技术栈与版本框架、语言、关键依赖的版本号。版本很重要同一个框架不同大版本的 API 差异可能很大不写清楚 AI 很容易给过时写法。输入与输出这个功能接收什么、返回什么数据结构长什么样。最好直接给一个示例数据。边界与异常空值怎么处理、超时怎么办、权限不足返回什么。这些是 AI 最容易忽略、也最容易在联调时爆雷的地方。约束条件代码风格、命名规范、不能引入哪些依赖、性能要求。我举个对比。模糊版是“写个登录功能”。规格版是这样技术栈某前端框架 3.x 组合式 API 某状态管理库 功能用户登录 输入{ username: string, password: string } 输出成功返回 { token, userInfo }失败返回 { code, message } 异常用户名密码为空时前端拦截接口 401 时提示“账号或密码错误” 约束不引入新的表单校验库用现有工具函数请求统一走项目封装的 request 方法你看同样一个登录功能第二种写法 AI 一次就能给出八九不离十的代码剩下的是微调。第一种写法你得来回问三四轮。这三四轮的时间就是被浪费掉的效率。2.3 一个反直觉的经验先写注释再让 AI 填代码我还有一个习惯可能跟很多人相反我不让 AI 从零生成而是先自己把函数签名和关键注释写好再让 AI 填充实现。比如我要写一个数据清洗函数我会先写def clean_user_records(records: list[dict]) - list[dict]: 清洗用户记录 1. 去除 user_id 为空的记录 2. 手机号统一去掉空格和横线 3. 邮箱统一转小写 4. 按 user_id 去重保留最后一条 # 让 AI 在这里填充这样做的好处是需求表达的责任在我代码实现的责任在 AI。我负责把“做什么”说清楚AI 负责“怎么做”。边界清晰返工率大幅下降。实测下来这种“注释驱动”的方式比直接描述需求快至少百分之三十因为注释本身就是结构化的规格说明AI 理解起来几乎没有歧义。注意注释里不要写“处理一下数据”这种废话要写清楚每一步的具体规则。规则越具体AI 输出越准。3. 上下文供给AI 不是读心术你得把项目“喂”给它3.1 为什么 AI 总写出“风格不对”的代码第二个大坑是上下文缺失。很多人用 AI 是在一个空白对话框里进行的AI 对你的项目一无所知。它不知道你的工具函数放在哪、你的请求封装长什么样、你的组件命名习惯是什么。于是它只能按通用写法来结果就是“能跑但跟项目格格不入”。我踩过最惨的一次是让 AI 写一个列表页。它给了一个完整的组件里面自己封装了一套请求逻辑。但我们项目早就有统一的请求封装还带了拦截器和错误提示。AI 那套代码一进去等于在项目里开了个“法外之地”后面维护的人一看就头大。最后我花的时间不是写代码而是把 AI 的代码“翻译”成项目风格。这件事让我意识到AI 的效率损失很大一部分发生在“代码风格对齐”这个环节。而这个环节本可以避免只要你把项目上下文喂给 AI。3.2 三种上下文供给方式按场景选我目前常用的有三种方式各有适用场景方式做法适用场景效率粘贴关键文件把相关的工具函数、类型定义、请求封装直接贴进对话单次任务改动范围小中项目规则文件在项目根目录放一个规则说明文件AI 工具自动读取长期项目多人协作高检索增强让 AI 工具索引整个代码库按需检索相关代码大型项目跨模块改动高第一种最直接但每次都要手动贴适合临时用。第二种是我最推荐的很多 AI 编程工具都支持读取项目根目录的规则文件你只要把技术栈、目录结构、命名规范、常用工具写进去之后每次对话 AI 都会自动带上这些信息。第三种适合代码库很大的情况靠工具自动检索不用你操心。我自己的项目里规则文件大概长这样# 项目规则 ## 技术栈 - 前端某框架 3.x 某状态管理库 某 UI 库 - 请求统一使用 src/utils/request 封装 - 类型所有接口返回类型定义在 src/types 目录 ## 命名规范 - 组件文件用大驼峰工具函数用小驼峰 - 常量全大写下划线分隔 ## 禁止事项 - 不引入新的请求库 - 不在组件内直接写 fetch - 不写 any 类型这份文件不到三十行但它让 AI 的输出质量提升了一个档次。因为 AI 知道了“边界”在哪就不会乱来。3.3 上下文不是越多越好要给“相关”的这里有个误区要提醒上下文不是塞得越多越好。我有段时间把整个项目的关键文件都贴给 AI结果它反而抓不住重点输出变得又长又杂。后来我改成“只给跟当前任务相关的文件”效果立刻好转。判断标准很简单如果这个文件的内容会影响当前任务的实现方式就给不影响就不给。比如你写一个表单组件那类型定义、校验工具、UI 库用法要给但路由配置、状态管理的其他模块就不用给。给多了是噪音给少了是缺失这个度需要练几次才能拿捏准。4. 验证闭环AI 说“完成了”不代表真的完成了4.1 最危险的幻觉AI 的自信AI 有个特点它输出代码的时候语气特别自信动不动就说“这个实现已经考虑了所有边界情况”。但实际上它可能漏了空值判断可能把异步写成了同步可能引用了不存在的变量。如果你不验证就直接用那这些坑迟早会在联调或者上线时爆出来。我见过一个真实案例。某开发者让 AI 写一个分页查询AI 给了一段看起来很完整的代码包含页码计算、边界处理。开发者扫了一眼觉得没问题直接提交。结果测试的时候发现当总数为零时页码计算会返回负数导致接口报错。这个 bug 手写的时候可能也会犯但手写的人因为是自己一行行敲的脑子里有过程反而容易发现。AI 给的代码是“黑盒”出来的你不验证就等于把风险直接吞下去了。4.2 建立“生成-验证-修正”的闭环我的做法是AI 每给一段代码我必须走完三步才算完静态检查先看有没有明显的语法错误、未定义变量、类型不匹配。这一步靠肉眼加编辑器的提示。单元验证针对核心逻辑写几个测试用例尤其是边界情况。空值、零值、超长输入、并发场景都要覆盖。集成验证把代码放进项目里跑一遍看跟现有模块的交互是否正常。这三步听起来麻烦但实际做起来很快。而且它带来的收益是巨大的你省下的不是写代码的时间而是调试和返工的时间。我算过一笔账一段 AI 生成的代码如果不验证直接用平均要花一点五倍的时间去修 bug如果走完验证闭环修 bug 的时间能压到零点三倍。哪个划算一目了然。4.3 让 AI 自己写测试但你要审测试有个提效技巧让 AI 顺便把测试也写了。比如你让它写一个函数可以追加一句“同时给出覆盖边界情况的单元测试”。这样你拿到的不只是实现还有验证手段。但这里有个坑AI 写的测试可能跟实现一样有盲区。它可能只测了正常路径没测异常路径或者测试断言写得太宽松什么都通过。所以测试代码你必须自己审一遍重点看它有没有覆盖你关心的边界。我一般会追问一句“如果输入为空数组这个测试会通过吗”逼着 AI 把边界补全。提示验证闭环里最容易被跳过的是“集成验证”。很多人觉得单元测试过了就行但实际项目里模块之间的交互才是 bug 重灾区。别省这一步。5. 任务切分粒度大任务交给 AI等于让它猜谜5.1 为什么“帮我重构这个模块”是个坏指令我早期犯过一个错就是给 AI 下大任务。比如“帮我重构这个用户模块提升可维护性”。AI 收到这种指令会输出一大堆改动但改完之后你根本不知道它动了哪些地方也不敢直接用。最后要么全部推翻重来要么花大量时间逐行 review效率反而更低。问题在于大任务的约束条件太多AI 无法同时满足。重构一个模块涉及命名、拆分、依赖调整、接口兼容每一项都有多种选择。AI 只能按它的理解来而它的理解大概率跟你的预期不一致。5.2 把任务切到“一次对话能完成”的粒度我现在的原则是一个任务一次对话一个明确的产出。具体怎么切我总结了一个“三问法”这个任务能不能用一句话说清楚输入和输出这个任务的改动范围能不能控制在一个文件或一个函数内这个任务完成后我能不能用几个测试用例验证三个问题都是“是”那这个粒度就合适。有一个是“否”就继续切。举个例子。“重构用户模块”太大切成“把用户模块里的手机号校验逻辑抽成一个独立函数”就合适了。前者 AI 会给你一堆改动后者 AI 给你一个函数加几行调用清晰可控。5.3 切分之后用“流水线”串起来切分不是目的串起来才是。我的做法是把大任务拆成一条流水线每个环节交给 AI 做一小步我自己做衔接和验证。比如开发一个完整的列表页我会拆成定义数据类型AI 生成我审写请求函数AI 生成我审写列表组件骨架AI 生成我审接入请求和状态AI 生成我审处理加载和错误状态AI 生成我审写测试AI 生成我审每一步都是小任务AI 输出快我验证也快。整条流水线走下来比让 AI 一次性生成整个页面要稳得多也快得多。因为每一步的产出都是可验证的不会到最后才发现方向错了。6. 工具选型与协作模式别把 AI 当打字机要当结对伙伴6.1 不同工具的定位不一样市面上的 AI 编程工具大致分三类定位完全不同对话式工具适合讨论方案、解释代码、生成片段。优势是灵活劣势是上下文要手动管理。编辑器内联工具适合在写代码时实时补全、局部修改。优势是上下文自动带上劣势是只能做小改动。智能体式工具适合执行多步骤任务比如“把这个功能实现并跑通测试”。优势是自动化程度高劣势是需要清晰的指令和验证机制。我的用法是三者结合方案讨论用对话式日常编码用内联式重复性任务用智能体式。比如我要设计一个数据结构先跟对话式工具聊清楚然后在编辑器里用内联工具写具体代码最后用智能体工具批量补测试。各司其职效率最高。6.2 协作模式你负责“判断”AI 负责“产出”用久了会发现AI 编程的本质是把“执行”外包出去把“判断”留给自己。AI 能快速产出代码但它不知道这段代码在你的项目里合不合适、有没有隐患、符不符合业务预期。这些判断必须你来做。所以高效的协作模式是你定义问题、给约束、做验证AI 生成方案、写实现、补测试。你越清楚自己要什么AI 越能帮上忙。你越模糊AI 越容易跑偏。这跟带新人的逻辑一模一样——你不能指望一个新人猜出你的心思你得把要求说清楚。6.3 一个提效细节让 AI 解释它自己的代码我有个习惯AI 给出代码后会追加一句“解释这段代码的关键逻辑和潜在风险”。这一步有两个好处一是逼 AI 自己 review 一遍有时候它解释着解释着就发现自己的 bug 了二是帮我快速理解代码尤其是它用了我不熟悉的写法时。实测下来这个习惯能提前拦下不少问题。有一次 AI 写了一段异步逻辑解释的时候说“这里假设请求一定成功”我立刻意识到它没处理失败情况当场补上。如果我不问这个假设就会一直藏着直到线上出问题。7. 常见问题速查与避坑清单7.1 高频问题对照表问题现象根本原因解决方向AI 代码跑不起来技术栈或版本没说清补充技术栈、版本、依赖信息代码风格跟项目不符缺少项目上下文提供规则文件或相关文件改了几轮还是不对需求表达太模糊用四要素重写需求上线后才发现 bug跳过验证闭环补单元测试和集成验证大改动不敢用任务粒度太大拆成小任务逐个验证AI 反复给错方案上下文有噪音或缺失精简上下文只给相关的7.2 我踩过的三个坑第一个坑过度信任 AI 的“完成”声明。早期我让 AI 写代码它说“已完成”我就直接用。结果发现它经常漏掉异常处理。后来我养成习惯不管它说得多肯定我都要自己跑一遍边界用例。第二个坑上下文给太多。有次我把整个项目的十几个文件贴进去AI 输出变得又长又乱还引用了不相关的模块。后来我学会只给当前任务相关的文件输出立刻清爽了。第三个坑任务切太细。有段时间我矫枉过正把任务切得特别碎结果每次对话都要重新交代上下文反而更慢。后来找到平衡点一个任务对应一个明确的产出上下文能复用就复用。7.3 一份可直接抄的检查清单每次用 AI 写代码前我会快速过一遍这个清单技术栈和版本写清楚了吗输入输出和数据结构给了吗边界和异常情况说明了吗项目规则文件在吗相关文件贴了吗任务粒度是不是一次对话能完成拿到代码后验证三步走了吗这六个问题基本覆盖了 AI 编程效率的所有关键点。养成习惯之后你会发现 AI 的输出质量稳定很多返工率大幅下降。8. 我个人的实操体会说到底AI 写代码效率不如手写绝大多数时候不是 AI 的问题是使用方式的问题。我自己从“用 AI 反而更慢”到“用 AI 稳定提效”中间隔的就是上面这些习惯的养成。最大的转变发生在我不再把 AI 当“打字机”而是当“结对伙伴”之后。打字机是你给它什么它打什么结对伙伴是你们一起把事做成。你要给它清晰的规格、足够的上下文、明确的验证标准它才能发挥出真正的价值。还有一个体会是AI 时代工程能力的重要性不降反升。因为 AI 能快速产出代码所以“判断代码好不好”的能力变得更关键。你越懂工程越能驾驭 AI你越不懂越容易被 AI 带偏。这跟开车一样车越快对驾驶员的要求越高而不是越低。最后分享一个小技巧每次用 AI 完成一个任务后花两分钟复盘一下这次哪里卡住了。是需求没说清还是上下文没给够还是验证没做。把卡点记下来下次避开。坚持一段时间你会发现自己用 AI 的效率曲线是往上走的而不是原地打转。