最近总有人问我AI时代做技术到底该怎么学、怎么干特别是“AI Coding”这个词越来越热之后。我看了不少人的状态要么是拿着AI当高级搜索引擎用遇到问题问一句、复制一段代码贴上去要么是彻底放飞让AI从头写到尾自己连代码跑起来逻辑对不对都说不清。这两种我都不太认同。AI Coding这个事儿表面上是用AI写代码本质上是把开发流程里那些重复、琐碎、容易出错的环节交给机器让自己腾出手来做真正的设计、判断和决策。这篇文章我会结合自己实际跑过的项目把从需求拆解、提示词组织、Agent协作、代码审查到团队落地这套玩法掰开揉碎讲清楚适合正在用AI提效、但又觉得效果不稳的开发者也适合想在公司里推AI编程、但不知道怎么定规范的技术管理者。我会尽量说人话把背后的原理和判断依据也讲明白不是丢给你几个现成提示词就完事。1. AI Coding的本质变化从“问答案”到“定规格”先说一个我观察到的现象。很多人在用AI写代码的时候习惯性把它当成一个“懂行的实习生”上来就问“帮我写个登录功能”“这个报错怎么解决”。这种用法不是不行但它发挥出来的效率可能只有AI真正能力的十分之一。问题出在哪儿出在交互方式上。你给AI的指令越模糊它回给你的代码就越泛泛你需要修改和调试的时间反而比从头写还长典型的“41点复杂度转移”——你省了打字的时间却把精力烧在了排查AI想当然挖的坑里。1.1 vibe coding的兴起与边界热词榜上有个词叫“vibe coding”意思是凭感觉、凭氛围写代码想到什么就让AI马上生成什么不纠结底层细节。这个方式对原型验证、个人小工具、一次性脚本特别友好我自己就经常用这种方式快速搭出一些验证性的Demo。但你要说拿它去支撑核心业务我是不太放心的。原因很简单vibe coding缺少对约束条件的显式管理。你让AI自由发挥的时候它可能默认了一个你根本没想到的技术栈或者埋了一个你没意识到的性能隐患。等代码量上来你再想回头修成本就非常高了。这里不是说vibe coding不好而是要给它划定边界。我的经验是三条一代码的生命周期不超过一个月二不涉及复杂的权限和数据一致性三出了问题不会影响线上业务。这三个条件都满足你就放心大胆地vibe coding效率真能起飞。但凡有一条不满足我建议你还是直接进入更可控的流程。1.2 从vibe coding到spec-driven的关键一步最近圈子里聊得比较多的另一个概念是“spec-driven development”我自己理解下来本质就是“先定规格再让AI写实现”。这跟建筑行业很像——你不可能让施工队边设计边盖楼大概率盖到一半就塌。写代码也是一样你让AI“盖楼”至少要给它一张图纸这个图纸就是spec。我做项目的时候已经习惯先把需求转成一个结构化的规格说明包括目标、输入输出、边界条件、验收标准、禁止事项。做完这一步AI的发挥空间就被框在了安全的范围内它的代码质量会明显稳定很多。有朋友问我说这样是不是就把AI变成了无脑打字机恰恰相反spec写作本身就是最高级的AI编程能力因为你要把模糊的人类需求翻译成机器能理解、能执行的精确语言。这比写一行代码本身难得多也值钱得多。1.3 AI Agent带来的协作角色改变再往前一步就是现在越来越成熟的AI Agent比如Codex、Claude Code、Cursor的Agent模式等。Agent和普通对话的最大区别是它不再是你一句我一句的问答而是你给它一个目标、一些权限和约束它会自己去读项目、改代码、跑测试、修bug像一个真正的工程师一样独立推进任务。这个改变是非常本质的。以前你得把每个步骤都拆碎了喂给AI现在你只需要给出高质量的目标和边界它就能自己执行。但注意权限越大、责任越大。Agent拿到的权限不仅要受限于项目范围还要受限于你设定的计划和验收标准。我在实际使用中一旦发现Agent开始“发挥创意”做需求之外的事就会立刻收敛对话重新审查它在干什么。没有规格约束的Agent本质上就是没有刹车的高速跑车。2. 做好AI Coding的核心工作流从需求到验收讲了这么多概念下面落到实操层面。我现在做AI Coding项目基本跑一套固定的工作流整个流程走顺了之后效率提升至少是翻倍的。这套工作流就四步需求写清、任务拆细、提示词到位、验收把关。2.1 第一步把模糊需求变成结构化规格说明AI编程和人类协作最大的不同在于AI不会主动问你“需求不明确的地方在哪”。如果你自己不整理清楚它就会自己脑补脑补出来的东西大概率不是你要的。所以我的第一步永远是写一份规格说明哪怕内部用、不对外发布也要写。具体的格式可以参考下面这个模板功能名称批量导入用户 目标支持管理员通过CSV文件批量创建账号并在导入结束后反馈成功/失败明细 输入CSV文件字段用户名、邮箱、所属部门、当前操作者身份 输出导入结果汇总页包含成功条数、失败条数、错误原因列表 边界条件单次导入不超过5000条重复用户名直接跳过并标记文件体积不超过2MB 验收标准1) 错误数据不能入库2) 存在已建账号时不能重复创建3) 页面必须显示每条失败原因 禁止事项不做实时进度条不支持异步任务队列不允许更改已有用户权限你看这些东西其实不需要写多长但每一项都非常关键。AI拿到了这个规格以后它生成第一版代码的通过率会从三成直接提高到七八成。这个环节是AI Coding里最关键、也最容易被忽视的。2.2 第二步任务拆解别让AI一口吃个胖子很多人在让AI开发功能的时候喜欢一次性把需求全丢过去比如“帮我写一个完整的订单管理系统”。这个做法的问题在于AI的上下文窗口虽然越来越大但它在一个超长任务里往往顾此失彼前面的决策会影响后面的代码质量出现逻辑不自洽的概率非常高。我实际操作下来最稳妥的方法是把任务拆成独立的、可验证的小步骤一次只让AI搞定一个模块。比如订单管理系统我会拆成数据库表结构设计、订单创建接口、订单列表查询、订单详情、状态流转逻辑、权限控制。每一个小步骤都是独立的交付物做完一个、验证一个、确认无误了再进行下一个。这样做的好处是问题可以尽早暴露你也能在每一个小回合里及时纠偏而不是等AI写完几千行代码以后你再面对一个根本没法定位问题的烂摊子。2.3 第三步写好提示词让AI明白你的“上下文”网上有很多所谓的“AI编程提示词大全”我看了不少但实际用下来真正好用的提示词往往不需要太长而是需要包含足够多的上下文信息。AI之所以写出让你不满意的代码很多时候不是它能力不行而是它不知道你的项目背景、技术栈版本、编码规范、已有的依赖库。我现在写提示词有一个固定套路背景这是一个基于Spring Boot 3.x Vue 3的内部管理系统数据库用MySQL 8.0前端UI组件库是Element Plus已集成统一登录。 任务实现用户管理的批量导入功能 要求1) 后端使用EasyExcel解析CSV2) 数据校验不通过时跳过该行并记录错误信息3) 导入结果返回给前端展示4) 遵循项目现有代码风格和异常处理规范 输出请先给出实现方案和涉及的类列表确认无误后分文件实现看到这里的共同点了没有背景、任务、要求、输出方式全都在给AI划定边界。特别是最后一句“先给出实现方案确认无误后分文件实现”这句话能帮你拦住一大半AI自作主张的运行逻辑。好的提示词不是让AI猜你想要什么而是把不确定性尽量压缩到最低。2.4 第四步建立验收机制别让AI自编自导我在这件事上吃过大亏所以现在非常坚持AI写出来的代码必须有验收机制而且验收不能靠AI自己说自己写完了就结束了。你把验证门槛交给测试用例和编译结果而不是AI的“我觉得”。具体来说我会做三件事。第一让AI在交付代码的同时给出对应的单元测试测试必须覆盖核心逻辑和边界条件第二跑一遍完整的构建流程包括编译、测试、静态检查任何一项过不去都直接打回第三我自己会快速用几个典型场景调一下接口或页面确认实际行为和预期一致。这三步做完AI代码的交付质量才基本可以放心。在AI编程的模式下代码审查者的角色比写代码的人还重要因为写代码的是AI而判断“写得对不对、值不值得合入”的只能是你。3. 实操过程用AI Coding完整实现一个批量导入功能下面我拿一个真实项目里的模块来完整走一遍流程这个模块是给内部运营系统增加一个“批量导入用户”的功能。这个项目我前后花了两天其中真正动手写代码的时间大概只有半天剩下的时间全在梳理需求、做验证和修细节。这个过程能比较直观地展示AI Coding的完整玩法。3.1 写spec画清楚边界开发之前我先写了前面提到的那份结构化规格说明。其中在边界条件上我特别加了一条“重复用户名直接跳过并标记”这是因为这个系统已经有一部分存量账号如果不提前说清楚AI很可能会默认插入数据时直接报错那样运营同学用起来就会非常痛苦。规格说明里的每一条边界都等于是在给AI铺路让它不要在你不关心的方向上浪费时间。写完之后我会把spec贴在对话最开始的位置并且要求在之后的每一轮回复里AI都必须基于这份spec来回答问题。如果发现AI的行为偏离了spec我会指出具体偏离点要求它改回来。这一步非常关键它相当于在AI的每一次回复里都放了一个“锚点”极大降低了越聊越偏的概率。3.2 拆任务按模块逐个击破这份spec落到后端我把它拆成三个任务第一个是接收CSV文件并完成数据解析第二个是数据校验与去重逻辑第三个是数据库写入与结果汇总。前端的部分拆成两个任务上传组件和结果展示。任务拆好之后我每个任务开一个新的对话防止上一个任务的代码污染下一个任务的上下文。每个对话里我都先粘贴spec中相关的部分再单独描述本次任务的目标比如第一个后端任务我写的是“基于spec中批量导入的功能描述实现CSV文件上传接口负责解析并将数据以结构化列表形式返回文件读取限制为2MB解析失败要返回清晰错误信息”。AI拿到这个任务之后先给出了自己打算用的类结构和依赖清单我看了一下和项目现有技术栈匹配就让它继续实现。整个过程对话来回大概十轮以内核心代码就出来了。3.3 让AI生成测试交叉验证逻辑代码写完之后我没有直接看实现细节而是先让它给核心逻辑写单元测试。我特别要求测试用例必须覆盖几个场景正常导入、存在重复用户名、CSV缺少必填字段、文件超过大小限制。这一步的主要用意是交叉验证——如果AI写的测试用例自己都跑不过那实现逻辑大概率有问题如果测试全过那至少说明基本行为是符合预期的。实际跑下来第一轮测试确实暴露了问题AI在解析CSV的时候没有处理UTF-8 BOM头导致第一行第一列的数据出现了一个不可见字符。这个测试用例一写出来马上就把问题暴露了。修了一个小版本之后测试全部通过。这个事情也侧面说明了一个观点让AI写测试不是形式主义它是检验AI实现是否符合规格的低成本手段比自己一行行去审查代码高效得多。3.4 集成与手工验证别忘了“人眼”自动化测试通过以后我没有急于合入代码而是把前后端都跑起来手工操作了一遍完整的流程。上传了一个二十行的CSV里面有正常数据、重复数据和一个格式错误的数据最后页面展示出来的结果和约定的一致五条成功、一条重复被跳过、一条失败并标注了原因。确认没问题之后我才把这段AI生成的代码经过自己的理解、整理、微调后合入主分支。这里有个细节想多说一句手工验证AI生成的代码这一步千万别省。哪怕测试覆盖率再高、跑得再绿你也要亲眼看一下它处理真实数据时的样子。因为AI可能会生成符合逻辑但并不符合产品体验的代码比如错误提示语写得像技术日志或者成功页面上少了运营同学想看到的“本次操作人”信息。这些需求层面的软指标测试覆盖不了只有人的真实使用才能发现。4. 常见问题与排查技巧实录AI编程用多了坑也踩了不少。我把自己遇到频率最高的几个问题整理成了一份速查表每个问题都附上排查思路希望对正在入坑的朋友有帮助。问题现象根因分析排查思路与解决建议AI生成了根本不存在的API调用大模型幻觉它把训练数据里见过的API硬编出来了别只看代码先跑构建。编译报错时优先去查官方文档确认API是否真实存在然后给AI贴上正确的文档链接再让它改越聊越偏改了一个功能另一个就坏上下文过长导致AI丢失早期约束每个独立任务开一个新会话把spec重新贴在开头。也可以在关键节点让AI总结当前状态和已确认决策代码过度设计加了一堆抽象层AI追求“标准答案”喜欢套用设计模式在spec里明确“禁止引入额外抽象按最简单可运行的方式实现”审查时发现多余代码直接要求删除测试全过但实际使用有bug测试用例和实现逻辑同源带着同样的盲区手工补充至少一个真实场景测试特别是数据量较大、输入格式怪异的情况。测试代码要自己手动改几个边界值别完全信任AI生成AI大幅改动已有代码diff看得头疼Agent在执行时把相邻文件顺带“优化”了每次改动前明确要求“只修改与本次任务相关的文件和函数不做无关重构”合入前逐文件查看diff不理解的改动一律还原敏感信息被AI请求到本地服务之外团队未做代码脱敏或使用了云端AI服务敏感项目建议内部私有化部署模型日常开发不贴密钥、token串、线上库连接串给AI工具这个问题清单可能没法覆盖你遇到的所有情况但核心思路是通用的AI代码出问题先怀疑上下文和约束再怀疑工具的默认行为最后才怀疑它的能力上限。很多时候不是AI写不出正确代码而是你没有告诉它“什么不能做”。4.1 关于“AI生成代码看不懂要不要学基础”的老问题网上有不少新手在问既然AI都能写代码了我还要不要死磕数据结构、算法、网络协议这些东西我的态度很明确要学而且要学得更扎实。理由只有一条AI时代纯粹从零写代码的能力被稀释了但判断代码好坏的能力变得无比值钱。你让AI写了1000行代码里面有没有隐藏的并发问题有没有跨域配置漏掉的安全策略有没有数据库查询慢到需要优化的索引缺失问题这些问题靠什么判断靠的就是基础功底。你让AI给你生成一个聊天机器人的WebSocket服务如果你自己不理解连接生命周期、心跳机制、异常断连处理你连它写的代码问题在哪里都看不出来。所以“小林coding八股”这类内容我看不但没过时反而变成了AI时代技术人区分段位的关键。区别在于以前你把这些东西背下来是为了面试现在你把这些东西吃透是为了能用人类判断力给AI的输出做质量把关。4.2 别盲目追求“降AI率”重点在理解和掌控热词里还有一个东西叫“降AI率工具”听说是用来降低文章或代码被识别为AI生成的概率让输出看起来更像人写的。我对这类工具的态度很简单不建议碰尤其是在代码审查和学术场景里。AI编程的核心价值是提升效率和质量不是让AI伪装成人再骗过另一个AI。你越是依赖这类工具就越会降低自己对代码的掌控力。代码仓库里的每段内容你都应该能解释清楚来龙去脉一旦做不到这一点后续维护和排障都会变成灾难。我自己现在会在AI生成的代码里做一些重构和重命名不是为了让代码看起来更像人写的而是让代码结构更贴合项目里已有的风格。这个重构的过程恰恰就是我对代码完成理解和掌控的过程。所以别总想着怎么骗过审查工具多花点时间把AI输出的代码读一遍、改一遍比什么“降AI率”都有效。5. 整个团队怎么用AI Coding提效个人用AI写代码是一回事团队或者公司层面怎么把AI Coding变成稳定的生产力是另一件更有挑战的事。我参与过几个团队从“禁止用AI”到“全员用AI”的转变过程踩过的坑比个人使用多得多核心不是工具选型而是规范和流程的建设。5.1 沉淀团队的spec模板和提示词资产很多团队买了AI工具的账号发给开发以为这样就完成AI化转型了实际效率并没有提升多少。原因很扎心团队里的每个人都在用自己的方式跟AI沟通有的人讲得很清楚有的人很模糊最后代码质量天差地别互相看对方的代码都想骂人。要解决这个问题比较好的做法是把个人经验变成团队资产。我建议整理一份内部使用的《AI Coding协作规范》里面至少包含三块spec模板前文那种团队内部按业务调整、提示词基础框架、常见的验收清单。这份规范不用一开始就做到完美先在两三个项目里跑起来收集问题再迭代。我见过最好的做法是每个项目结束后由负责人挑出三个“AI用得高光”和三个“AI坑到大家”的案例更新进规范里慢慢这个规范就会变成团队最强的新人培训手册。5.2 coding plan和任务粒度的管理价值热词里有个词叫“coding plan”我理解下来就是给一次开发任务制定详细的执行计划然后让AI按计划执行。这跟我前面说的任务拆解其实是同一件事但放到团队协作里它的价值会被放大。原因在于一个中型功能可能涉及前端、后端、数据库、权限等多个模块如果你不先在plan阶段把这些模块都识别出来AI在实现的时候就会反复改接口定义、改数据结构浪费大量时间。我的做法是在项目启动前先用一个多小时做全局拆解生成一份coded plan文档里面列清楚每个任务涉及的文件、依赖关系、验收标准、预计耗时。之后AI Coding的过程基本是“按图索骥”每完成一块就在plan文档里打勾。团队协作的时候这份plan还能当进度看板用管理员扫一眼就知道当前卡在哪个环节、需要哪些代码评审。5.3 AI Coding时代的人才观与岗位变化AI对技术团队的影响不仅是工具层面还有岗位结构层面。以前团队里需要大量的初阶执行型开发者写业务代码现在这部分工作被AI大量承接了。但同时一个新的岗位角色在快速浮现负责做需求分析、规格设计、AI代码审查和技术决策的“AI编程师”。我招人的时候现在会把考察重点放在几个维度给一个模糊需求能不能快速写清结构化spec拿到AI生成的代码能不能迅速定位可疑逻辑遇到越写越偏的情况能不能通过调整约束把AI拉回正轨。这几项能力都比“手写一段快排”更能反映一个人在AI时代的技术生产力。如果你是一个初级开发者也别焦虑。你现在最好的策略不是跟AI比写代码速度而是利用AI这个“免费助教”大量阅读、审查、修改它生成的代码把项目经验快速积累起来。这个学习速度比传统时代快太多了关键是看你有没有这个意识。6. 几个容易被忽略的实操细节最后分享几个我自己在真实项目里摸索出来的细节都是小事但每一个都直接影响AI Coding的体验和产出质量。6.1 给AI配置“项目记忆库”AI对话最大的痛点是它不记得之前的决定。我现在的做法是在项目根目录放一个ai_context.md文件里面记录项目技术栈、目录结构、模块说明、常见约定和目前踩过的坑。每次新开AI对话第一件事就是把这份文件做喂给AI相当于在它的短期记忆之外建立了一个长期记忆库。大模型实验室在这套方法的早期效果都非常惊讶说“好像换了个AI在工作”其实就是上下文质量的区别。6.2 用批处理方式处理多文件改动AI在跑Agent模式的时候经常一次改动多个文件而且会自动生成一些临时文件或者日志文件。我建议在让Agent动手之前先设置好.gitignore并且把改动范围限制在指定目录。每次Agent跑完先看一眼git status如果出现了不该出现的文件或目录第一时间要求它解释并清理。这些细节看起不起眼但能让你的代码仓库保持干净后续review的体验会好很多。6.3 学会“教AI你的公司业务规则”通用的AI模型不懂你公司的具体业务规则比如“一个订单只能有一个待发货状态”“管理员账号不能被停用”“金额计算保留两位小数”。这些规则如果只是在你的脑子里而没喂给AI它生成的代码就会在这些细节上出bug。我现在写spec的时候会额外加一节“业务规则”把凡是人肉判断过一遍的规则全部写进去宁可多写几条也不要让AI瞎猜。这个问题在业务系统开发里尤其常见而且光靠测试用例往往发现不了等上线后被运营发现了才是真麻烦。6.4 建立AI代码的质量门槛不是所有代码都能合入团队里推行AI Coding的时候一定要在Code Review环节给AI代码设一道和人类代码一样的门槛。AI代码不是“特殊代码”质量要求不能降低review的人不能用“AI写的就凑合吧”的心态放水。我见过的团队里有一个不成文的规矩AI生成的代码如果review发现问题会打回给原作者也就是那个用AI的人修改并且要求在提交说明里写清楚“这是AI生成的代码我人工check了XX逻辑符合要求”。这个仪式感看起来多余但很好地保证了每一个人对AI生成代码负责的意识。回到最开始说的那句话AI Coding真正难的从来不是让AI写出代码而是你能不能让AI在你划定的边界内写出可靠、可控、可维护的代码。从我自己的经验来看这个能力是可以通过刻意练习越来越强的。我现在每个新项目都会花时间打磨spec模板和提示词风格每踩一个坑就把它记进团队规范里几个月下来AI产出的初版代码合格率已经高了很多我自己的时间也从写代码逐步转向了做设计、审代码和思考业务。建议你现在就试一下找一个这周要做的重复性开发任务先憋住别动手写代码花二十分钟写一份spec然后把实现工作交给AI亲自看看交付质量和耗时有没有质的变化。