1. 从“能跑就行”到“稳定复现”为什么需要一套完整的AI编程流程先聊点实在的。我接触AI编程至少两年了从最早拿ChatGPT写点正则表达式、SQL查询到后来用Cursor、Windsurf这类AI原生IDE做完整的小型项目最深的体会是AI写代码的能力确实在飞速进化但真正卡住大多数人的从来不是“AI写不出代码”而是“你没有一个可复用的流程去驾驭它”。什么意思呢举个例子。很多人拿到一个需求第一反应是打开对话窗口把需求一句话甩给AI然后等着它输出一堆代码。运气好的时候AI给出来的东西能跑运气不好的时候AI给你编造一个不存在的API或者它自己写了个bug但它不知道你还傻乎乎地复制粘贴进项目里结果编译报错、运行崩溃来回折腾一下午。然后你就得出一个结论“AI写代码不行。”这是AI不行吗不是。是你没有流程。传统开发里我们讲“需求分析—方案设计—编码—测试—部署—维护”每一步都有明确交付物。AI编程时代这套流程不但没消失反而更重要了。只是我们需要把流程里“人做的事情”和“AI做的事情”重新切分清楚再把两者接起来。我花了大半年时间把我自己的项目实践、踩过的坑、看过的各种经验贴整理成了一套“AI编程完整工作流程”版本号写到v2.0就是因为我确实迭代过一版。v1.0的时候我的流程是“写提示词→生成代码→报错→改提示词→再生成”基本是打地鼠。v2.0的核心变化是在任何一行代码生成之前先做好任务切片、上下文准备、验收标准定义。这一套折腾下来AI生成代码的一次通过率提升非常明显返工成本直线下降。这篇文章就是要把这套v2.0流程完整拆开。它适合谁适合作战在一线的开发者无论你是用C写游戏小项目、用Python做数据分析脚本、用Java写业务接口还是刚接触AI编程没多久的初学者只要你不想再被AI“坑”想把AI真正变成生产力工具这篇文章都值得你花二十分钟看完。2. 任务切片AI编程的第一原则是“一次只做一件小事”2.1 为什么AI在复杂任务上容易翻车先说一个现象。现在的对话式AI确实具备很强大的上下文能力动辄几十万字上下文窗口但这不代表它能从头到尾维护一个大型工程的一致性。很多人让AI“写一个完整的电商系统”你觉得AI真的会给你一个能部署的电商系统吗实际上它会给你拼凑一个极为粗糙的骨架表结构是乱想的接口没考虑鉴权事务边界是错的甚至目录结构都没对齐你本地的技术栈版本。回头分析一下这背后的原因并不神秘。AI模型本质上是下一个词的预测器它的每一段输出都基于当前上下文和概率分布。任务越大它的推理链条越长早期输出的小错误会在后期被反复引用、放大。就像人写长篇小说开头埋了一个坑到后面要么忘了填要么强行圆回来圆不回来就崩了。AI也一样长输出往往在前面定义了一个变量名的含义写到最后自己都忘了。所以我在v2.0流程里把“任务切片”放在了最优先的位置。**任何需求到了写提示词之前必须先拆成若干个可独立验收的任务单元。**每个单元要小到AI能在一次对话窗口里相对稳定地生成完并且你能明确判断它对还是不对。2.2 切片的具体方法按“垂直切分”而不是“水平切分”切片不是拍脑袋乱砍。我推荐的做法是按“功能纵向切片”拆分而不是按“代码层次横向拆分”。举个实际的例子。我要做一个“图书管理系统的借书接口”。横向拆分的意思是任务A写数据库表结构任务B写ORM模型任务C写Service层逻辑任务D写Controller接口任务E写测试用例这种拆法符合人的分工习惯但不适合AI。因为AI在写Controller的时候需要知道表结构字段名、Service方法的签名如果表结构是你之前在别的任务里生成的此时上下文已经不在对话窗口里了。你只能把之前的代码复制粘贴进来。一旦表结构后面改了你所有下游任务的上下文全都失效返工成本爆炸。垂直切片的意思是按“一个完整功能从入口到出口”来拆任务A实现“用户查询图书列表”的完整链路包括表结构持久化、查询逻辑、API接口、返回JSON格式任务B实现“用户借书”的完整链路包括事务、库存扣减、借书记录写入、异常处理任务C实现“用户还书”的完整链路每条链路都是一个可运行、可验证的小功能。AI生成完毕后你可以立刻编译/运行/点击验证。任务之间如果需要共享表结构或公共工具类那就先把那部分提取出来作为“基础任务”先行完成。我自己的经验是单个AI任务的代码量控制在200行以内比较好复杂一点的也不建议超过400行。超过这个量级AI的错误率会显著上升而且排查问题的成本也开始超过它的生成收益。这个阈值不是一个精确的数字但我建议你把它当作自己任务切片的参考标尺。2.3 任务切片的产物一个明确的“任务卡片”切片之后每个任务要形成一张“任务卡片”里面包含五个要素任务目标一句话说清楚要什么功能包括输入、输出、核心效果依赖上下文需要读取哪些已有文件、哪些接口定义、哪些数据表字段技术约束语言、框架版本、编码规范、必须使用的工具类验收标准用什么样的方式验证这个任务完成了是运行一个命令还是打开网页点一下还是跑一条测试用例禁止事项绝对不能做什么比如“不要改数据库现有表结构”“不要引入新依赖”这个任务卡片是写提示词的基础。它不是给别人看的文档而是给你自己梳理思路用的。很多时候你把这个卡片写清楚问题就已经解决了一半——因为AI犯错的很大一部分根源是你自己根本没说清楚你想要什么。提示任务切片这个动作别让AI来做。虽然有些AI工具支持“自动拆解任务”但我还是建议人工先拆一遍。只有你自己理解了任务的边界和依赖关系你才能在后续步骤中判断AI生成的结果是否正确。AI帮你拆你还要反过来验证它拆得对不对省不了多少事。3. 上下文构建让AI“站在你的代码库里”说话3.1 上下文质量决定生成质量如果你用过多个AI编程工具你可能会发现一个奇怪的现象同一个模型在不同的工具里表现水平似乎不一样。Cursor里表现好的模型放到一个普通聊天网页里可能写出来的代码质量就差很多。这很大程度不是模型变笨了而是工具的“上下文构建能力”不同。Cursor这类工具会把你当前打开的文件、相关文件索引、最近修改记录、项目配置文件拼装成一段上下文一起发给模型。你的项目背景越丰富模型对任务的误解就越少。我见过太多人在“AI编程”上吃亏就是因为他们在拿裸模型硬写代码没有把项目结构告诉AI没有把相关代码放进去没有说明依赖版本就凭一句“帮我写一个登录接口”AI当然只能给你一个从零开始的、假设了一堆不存在的依赖的“玩具代码”。所以在v2.0流程中上下文构建被提到了跟任务切片同等重要的位置。你得主动告诉AI“你的任务是在什么环境下执行的”。3.2 手动构建上下文的三类内容如果你用的是普通的AI聊天窗口没有深度集成代码库你需要手动把三类信息塞进对话第一类项目级信息项目是什么、用的什么技术栈、目录结构什么样子、关键依赖的版本。这部分不用说太多两三段话就够了。它主要是让AI的输出在“技术选型”层面不跑偏。比如你的项目是Spring Boot 2.7 MyBatis-PlusAI就不会给你生成Spring Cloud微服务风格的代码。第二类文件级信息你正在写/改的那个文件以及它直接依赖的相邻文件的代码。比如你要写一个Service的实现类那你至少要把对应的Entity、Mapper接口、Controller方法签名、前端传来的参数结构贴进去。为什么因为AI写实现类的时候如果你已经把Mapper接口的方法签名给它看了它就不会瞎编一个不存在的方法如果你把Entity字段都给它了它写属性映射的时候就不会把userName写成name。第三类语义级信息这个任务的背景目的。它不只是“写一个方法”而是“在用户注册时对手机号做格式校验校验规则是大陆11位开头1第二位3-9”。你光说“校验手机号”AI默认会用宽松的1[3-9]\d{9}还算好但如果想加密校验规则你不说它就不知道。这三类信息怎么组织到提示词里我建议按固定模板来【项目背景】 这是一个基于XX框架的XX系统技术栈为XX。项目目录结构如下... 【当前任务】 我要实现【具体功能描述】核心目标是...输入是...输出是... 【相关代码上下文】 以下是当前项目中的相关文件片段 - Entity.java 的字段定义... - Mapper.java 的方法签名... - 当前要写的文件是... 【约束条件】 - 使用XX版本语法 - 不要引入额外依赖 - 保持与现有代码风格一致 【验收标准】 生成代码后我会运行XX命令/访问XX页面预期看到XX效果。这个模板不是死的你可以按需增删。但核心逻辑是一致的在让AI写代码之前先让它“掌握”足够多的背景信息。3.3 工具内置的上下文比手动贴代码强在哪如果你用的是Cursor、Windsurf、VS Code Copilot这类深度集成IDE的工具很多上下文构建工作可以由工具自动完成。比如Cursor的Codebase、File引用#全局搜索符号它能把你指定的文件内容直接嵌入提示词。这些工具在“找相关代码”这一步上确实是优势。但即便是这样另一部分工作还是需要你做你要明确指出“需要AI读取哪些文件”。工具能帮你把文件内容拉进上下文但它不知道你这次任务依赖的是哪几个文件。我看到过不少人在Cursor里对着整个代码库说“帮我改一下登录逻辑”然后AI自作主张读了一堆无关文件生成的改动方案又臭又长。正确做法是用精确引用登录相关的Controller、Service、Mapper文件限定AI只在相关范围内思考。顺带说一句很多人在多文件项目里不习惯贴上下文总觉得“AI聊天框里一堆代码看着乱”。我的经验是乱一点没关系上下文里的代码不是给你看的是给模型“喂”的规则。你只需要保证你贴的东西是准确的、完整的、最新的就行。乱不是问题旧和假才是致命的。3.4 上下文一致性的维护一个容易被忽略的坑是上下文会和实时代码脱节。你在对话开始的时候贴了一份UserService.java然后你手动改了这份文件再让AI继续生成代码它脑子里记的还是旧版本的代码。轻则生成的代码跟你的现状不匹配重则它基于一个你已经删掉的方法继续调用直接编译失败。所以我的习惯是每次开启一个新任务重新贴一遍最新代码。别偷懒用上一次对话里的历史内容。更好的做法是一个任务开一个对话窗口任务结束就把窗口归档下一个任务重新构建上下文。这也是为什么任务切片重要——因为每个任务本身就是一个独立的、可以在新对话里完成的单元。4. 提示词工程不是玄学是结构化沟通4.1 别再迷信“魔法提示词”网上流传着各种“AI编程提示词大全”“万能咒语”说实话我看过不少有用的内容占比例不大。提示词的本质是你在跟一个“懂很多但你不知道它此刻懂多少”的模型进行沟通。它的核心技巧不是某个神秘关键词而是信息完整性和结构清晰度。打个比方。你让一个新来的实习生写个模块你会怎么交代你肯定会说清楚背景是什么、要做什么、不要动什么、这个模块跟旁边的模块怎么对接、完成后你怎么验收。你对AI也应该这么说话。很多人对AI的态度反而敷衍得多——“帮我写个注册接口”没了。这不叫提示词工程这叫许愿。4.2 一套可以直接复用的提示词模板下面这个模板是我在实践中逐步打磨出来的不敢说适用所有场景但对于“写一个新文件”“实现一个功能方法”“修改一段逻辑”这类编程任务它足够可靠请帮我实现以下功能 【任务】在用户管理模块中新增修改用户状态接口。 1. 接口路径PATCH /api/users/{id}/status 2. 请求体{status: 0}0表示禁用1表示启用。 3. 校验逻辑当前用户必须为管理员且不能修改自己的状态。 4. 返回格式{code: 0, message: success, data: null} 【项目上下文】 - 框架Spring Boot 2.7.9 MyBatis-Plus 3.5.3 - 现有Controller... - 现有Service接口... - 现有Service实现... - User实体字段... - 统一返回类Result的定义... 【约束】 - 使用MyBatis-Plus的LambdaQueryWrapper来查询用户。 - 不要使用全局异常处理外的自定义异常。 - 管理员权限校验请复用AuthUtils.checkAdmin()方法。 - 不要删除或改动其他已有方法。 【验收标准】 - 编译通过。 - 使用IDEA Test REST API发送请求管理员可修改他人状态非管理员返回403。 - 修改自己的状态时无论是否管理员均返回业务错误码40001。 【输出要求】 - 只输出代码不要解释。 - 改动涉及的文件请列出文件路径。这个模板里面没有一句废话。“输出要求”这个部分也很重要很多AI默认会给你写一堆解释虽然有参考价值但你要是复制代码还得从解释里挑效率反而低。你需要的是“确定性输出”直接拿代码走人。4.3 提示词中的“负面约束”我强烈建议在提示词里加一个“约束/禁止事项”的段落。负面约束的价值在于它能把AI引向你自己项目里特定的“暗规矩”——这些规矩代码里看不出来只有你在这个项目里待久了才知道。举几个真实例子“不要使用Lombok的Builder”因为你们项目团队约定不用Builder模式的链式赋值“不要用Java Stream的Parallel Stream”因为你们线上出现过线程池问题“日期格式化使用yyyy-MM-dd HH:mm:ss不要用yyyy-MM-dd’T’HH:mm:ss”“不要写service层包装的脏代码直接返回Result”这些约束是代码库之外的“项目宪法”。你不告诉AI它就按它的统计默认值来大概率跟你项目的真实风格对不上。4.4 多轮对话的修正技巧一次生成的代码很少有完全符合预期的。这时候别急着把结果往项目里塞也别闷头改。你有两个选择一是在当前对话窗口继续跟AI对话修正二是开新窗口重写。我的经验是如果仅仅是小问题变量命名、缺少注释、格式不对在当前窗口继续聊如果是结构性错误整体思路不对、接口设计不合预期、某个核心逻辑写错了那别浪费时间开新窗口重写上下文再来一次。在多轮修正的时候注意一个策略指出问题的时候带上“期望值”。不要只说“这个不对”要加一句“我认为正确的是xxx”。比如“这里不需要用Integer应该用Long因为数据库主键是bigint”。你给的信息越具体AI下一次修正就越有方向。它的生成质量高度依赖你给的反馈信号信号模糊它就只能在错误方向上尽力修补。这一节怎么说呢提示词工程谈不上什么高深学问它更像一个“需求沟通技巧”在新的交互媒介上的延伸。你平时跟同事怎么把一个需求聊明白你就怎么跟AI聊再加上一点结构化的表达习惯。理解了这一点你根本不需要背提示词模板。5. 实现与验证生成只是开始“看得见的验收”才算完成5.1 AI生成代码后你至少要做四层检查我见过很多人AI生成代码之后看一眼觉得“挺像那么回事”就直接复制保存了。这种行为是比较危险的。AI生成的代码是需要经过人工检查的而且不是“泛读”是带着具体目标的核对。我自己的检查清单有四层第一层编译层。不管什么语言第一时间编译或者至少让IDE做语义分析。Java项目跑mvn compile或gradle buildPython项目至少python -m py_compile前端项目跑npm run build。编译过了说明至少没有语法错误和类型错误这关过不去的代码神仙来了也白搭。第二层逻辑层。逐行走读一遍关键逻辑。重点看三件事边界条件有没有处理、异常路径有没有兜底、状态变化符不符合业务预期。别信AI写的注释——它经常把自己的意图写得比实现还美丽但实际上代码跑的是另一回事。第三层集成层。AI生成的代码通常是在你给它的那段上下文里“看起来没问题”但一旦跟真实项目里的其他模块对接问题就暴露了方法名对不上、参数类型不一致、依赖缺失。这一层验证通常需要你真正把代码放进项目里然后调用一次看结果。第四层回来看看。在整体项目跑起来之后回到AI生成代码的位置向AI提问“你生成的代码把XXX方法的调用路径链路列出来”“这个分支在什么情况下会走”。让AI自己解释一遍它的代码这其实是很好的逻辑自检。如果AI解释得含糊不清说明这段代码的真伪存疑。5.2 能跑不等于正确功能的可观测性这一步是很多人忽视的。AI生成的代码“能跑起来”不代表“逻辑正确”。你接了一个登录接口POST一下返回200你就觉得OK了回头看看密码校验了吗用户名存在吗错误密码返回了什么还有并发登录、账号锁定状态、登录日志写入……这些你可能写一个简单接口用例都触发不到。所以我在流程里加了一个“验收标准要做到可观测”的要求。拿前面的“修改用户状态”接口举例你不能只看返回code0就通过你得真的去数据库里查一下user_status字段是否变了你得用一个非管理员token调一下确认返回403你还得用自己的账号试一下确认返回40001。每一个验收点都要有明确的观测动作。这就要求你在写任务卡片的时候就要把验收标准定义到“可操作”的粒度而不是写“功能正常”这种废话。有些朋友可能觉得这一步啰嗦但正是这一步能大幅减少线上回归的坑。与其事后花两个小时在线上查一个奇怪的bug不如在生成这一步花五分钟做一下验证。5.3 人工介入的时机流程里还有一个高频问题AI生成代码后我应该亲自改多少我的原则是核心逻辑必须人工把关模板化代码可以交给AI全权处理。什么是模板化代码比如一个简单的CRUD接口Controller、Service、Mapper的骨架这类代码的套路性极强AI生成基本靠谱你改反而容易引入低级错误。什么是核心逻辑比如多表联动的事务处理、需要严格幂等的操作、涉及金额字段的校验、状态机的流转判断这些代码里任何一个细节错了都可能产生线上事故。我建议这类逻辑不要直接信任AI的第一版输出至少要自己走读一遍逻辑并且用测试用例去实测。也许你会说“既然核心逻辑还得我看那AI编程岂不是很鸡肋”我不这么认为。**AI帮你省掉了80%的机械编码时间剩下20%的核心逻辑你有了更多时间去精雕细琢。**以前一个接口写下来要一小时现在AI给你10分钟出稿你花20分钟精修逻辑总共半小时怎么算都是赚了。6. 调试与排错别跟AI“拉扯”用证据链驱动机器人6.1 AI代码报错先别急着把报错贴回去AI生成代码跑起来报错你的第一反应是什么很多人直接CtrlC复制报错信息粘到对话窗口问AI“怎么修”。如果这个流程能解决所有问题那世界上的bug早就消失了。事实是如果你只贴报错信息AI顶多给你一个“可能的原因”列表和对应的“修复尝试”——这会变成一场低效的试错循环你改它跑跑了又错又贴回去再改。不是说这么做完全不能解决而是解决问题的概率不够高而且你什么都没有学会。我推荐的方法是先按传统调试思路把问题定位出证据再带着证据去问AI。比如Java的堆栈异常你应该先看异常类型和栈顶信息判断是空指针、类型转换、还是数据库约束冲突。如果是数据库问题把SQL日志拉出来如果是前端问题打开控制台看网络请求的状态码和响应体。总之先自己定位出“究竟哪一行代码触发了错误”再把这个证据和对应的代码片段一起丢给AI。6.2 一个实际调试案例MyBatis-Plus分页失效问题说个具体案例。我之前在项目里让AI生成一个分页查询接口AI用的是MyBatis-Plus的Page对象配合分页插件。代码生成后本地一跑返回结果是全表数据分页完全没生效。我当时没有直接把报错贴给AI——因为这个场景没有报错只是结果不对。我做了什么我先打开控制台看SQL日志发现SQL语句里面压根没有LIMIT关键字也就是说分页插件没生效。于是我自己先查了一下配置发现项目里没有注册MybatisPlusInterceptor这个Bean。原因找到了是配置缺失不是AI生成的代码有错。然后我带着这个发现问AI“项目中缺少MybatisPlusInterceptor Bean导致分页SQL没有LIMIT请给出注册方式注意不要与现有MyBatis配置冲突。”AI很快就给出了正确的配置代码。全程浪费不到五分钟。如果我不去定位直接把“分页没生效”丢给AIAI可能会怀疑是Page参数传错、持久层方法写错、前端参数没传对……来回排查好几轮还不一定对。6.3 另外一种思路让AI当“代码评审员”而不是“代码生成器”调试阶段除了让AI直接修代码我还会让AI做另一种事情代码审查。经常是代码逻辑没问题但就是跟项目里其他部分集成时出了问题。这种问题让AI“重写”往往越改越乱让AI“解释”反而能更快暴露盲点。比如提示词这么写以下是我写的一段代码实现了XXX功能。 但是我发现它跟YYY模块集成时在某些情况下会抛出ZZZ异常。 请以资深研发的身份逐行审查这段代码指出所有可能导致ZZZ异常的地方并解释为什么。 不要直接给出修改后的代码先列出可能原因清单。这种模式能发挥AI“读代码”的长处。它的知识面广能识别出很多你自己根本没意识到的边界场景。等你拿到了可能原因清单再结合自己掌握的业务情况锁定真正的问题点最后再让AI给出修复代码。这个过程比我前面说的“报错贴回去式调试”要高效得多。6.4 建立“错误模式”笔记最后一节聊一个长效习惯。调试过程中你会积累很多AI编程特有的错误模式——比如“它喜欢用Java 17的语法但你项目是Java 8”“它在写TypeScript时总是漏掉async/await”“它在生成SQL时默认用!判断空值结果导致索引失效”。这些问题第一次遇到你会觉得郁闷但第二次第三次遇到那就是纯赚了。我的做法是维护一个简单的Markdown笔记按语言/框架分类记录“AI在什么场景下容易生成什么错误”“我怎么在提示词里提前规避”。例如场景AI常见错误预防方式排查方式Java日期处理直接new SimpleDateFormat约束必须使用DateTimeFormatter代码审查时搜SimpleDateFormatPython异常裸捕获或直接吞掉异常约束保留异常上下文代码审查时看except块SQL空值判断!会导致NULL记录被过滤提示词明确空值语义看执行计划这个表格看着不起眼但累积到一定量之后你的AI编程效率会再上一个台阶因为很多坑根本还没发生就被你的提示词提前“垫”掉了。7. 版本管理与回滚AI编程时代的代码保鲜术7.1 为什么AI编程背景下版本管理更关键以前写代码是你自己一个字一个字敲的代码的演进脉络在你脑子里。现在写代码你的代码可能是AI一次性生成的可能是AI再修改的也可能是你把AI生成的代码逻辑跟自己的理解混在一起改出来的。代码不是你写的你对它的熟悉程度天然就低一层。这种情况下版本管理的作用就从“记录历史”升级为“安全网”。我强烈建议任何一次AI生成/修改代码第一步就是创建一个新的分支或者至少对当前状态打一个tag。为什么因为AI的第一次生成大概率不是最终答案你需要一个低成本甚至无成本回到起点的能力。如果你直接在主干上把AI生成的代码覆盖掉原来能跑的代码然后发现AI生成的东西有严重问题你想回退都不方便。7.2 我的提交习惯颗粒度小信息量多我自己的习惯是每个AI任务完成后做一次独立的Git提交。提交信息里写清楚“本次由AI实现了什么功能”“验证了哪些验收点”。这个习惯有几个好处一是方便回滚。每个任务对应一次提交哪个任务出了问题直接git revert那一条就行不会牵扯到其他无关改动。二是方便审查。代码评审的时候按提交看差异逻辑清晰不会出现一个提交里混杂着十几个无关改动的情况。第三个好处是提交信息本身构成了一个“AI驱动开发”的日志。三个月后你想复盘当时为什么那么设计翻一下提交历史就清楚了。若没有这个习惯你看着一段AI生成的代码大概率回忆不起来它为什么长这样。7.3 大改前的“快照”操作还有一种场景你要让AI做一个跨多个文件的较大改动比如重构一个模块的接口设计。这个时候光靠Git提交可能还不够因为你改到一半发现方向不对你可能想回到的是改动之前的某个状态。Git分支可以做到但我更习惯在动手前直接复制一份关键文件的备份放进一个_bak目录改完没问题再删掉。听起来土但关键时刻能救命——尤其在你的项目还没有完整纳入版本控制的时候。8. 常见问题排查与速查表这个章节我把自己在实践AI编程过程中遇到的典型问题和对应的解决思路整理成了一张速查表方便你日常遇到了直接照着排查。问题现象大概率原因排查思路解决参考AI生成的代码编译报错报错位置是它自己虚构的API上下文里没提供真实API定义检查提示词里是否包含相关文件内容补充真实代码片段后重新生成代码能编译但运行结果不符合预期提示词里验收标准太模糊先自己复现一次记录具体输出把“预期输出”补充到提示词让AI修正提示词写了“不要用X”AI还是用了X负面约束不够具体或上下文优先级更高检查是否在上下文里有X的示例代码用禁止项在输出要求中单独声明修改一处破坏了另一处已有功能垂直切片没切好任务粒度太大查看Git提交定位哪次改动引入回滚后拆分为更细的任务重做AI连续多轮修改仍然跑不通上下文已经错乱修修补补没有意义停止当前对话开新对话重建上下文重新生成多文件协作修改时AI只改了部分文件任务提示里没列明涉及的文件清单检查输出文件列表明确列出所有需要修改的文件路径分页/事务/权限这些框架级功能失效缺少框架配置或拦截器看日志确认是否生效让AI补齐配置代码代码风格跟项目其他模块不一致项目CODE_STYLE没有写进提示词找一份已存在的风格参考代码把参考代码片段贴进上下文除了表里的内容还有几个话想多说一句第一永远不要在生产环境直接测试AI生成代码。你至少要在本地开发环境、测试环境各跑一遍确认没有问题再上生产。这条不是AI编程时代的新规矩而是传统开发就有的红线在AI编程时代更需要强调。第二AI生成代码的时间依赖上下文长度。如果你贴了太多无关文件AI生成速度会变慢而且可能被无关代码干扰。上下文构建不是堆料越多越好要克制只贴本次任务相关的。第三关注你使用的AI工具本身的版本迭代。无论你用的是开源模型本地部署还是商业AI编程IDE定期更新是必要的。新版本通常意味着更强的代码生成能力、更好的上下文理解。我就见过有人一直用某个旧版Claude模型生成SQL时老犯同一个错误升级之后概率大幅度下降。9. 收尾还想说的几句实在话这套工作流v2.0从任务切片、上下文构建、提示词模板到代码验收、调试排错、版本管理核心其实就一句话把AI当成一个能力很强、但需要明确指令和严格验收的“远程协作者”。你对协作流程的控制力决定了AI编程的上限。我个人在实际操作中最受用的一个改变是不再抱怨AI写代码“不靠谱”而是开始反思自己有没有把靠谱的前提条件给它。大多数时候答案是没有——任务没拆小、上下文没喂足、验收标准没定清。等你把这些补齐了AI编程的体验会好非常多。最后再分享一个小技巧。当你要开始一个比较大的项目时别直接开始写代码。先去把整个需求手工拆成一份“任务卡片清单”每个卡片都可以对应到一次独立的AI对话。然后你只需要一个任务一个任务地执行构建上下文→写提示词→生成→验证→提交。这个过程看起来没有“让AI一口气写一个完整项目”那么炫酷但它稳定、可控、可复现。而且随着你做的项目越来越多你会发现这套流程本身也可以被沉淀成你团队里的“AI编程规范”——到了那一步你就不会再来回折腾提示词了而是像流水线一样交付代码了。
AI编程实战指南：从任务切片到提示词工程的完整工作流
1. 从“能跑就行”到“稳定复现”为什么需要一套完整的AI编程流程先聊点实在的。我接触AI编程至少两年了从最早拿ChatGPT写点正则表达式、SQL查询到后来用Cursor、Windsurf这类AI原生IDE做完整的小型项目最深的体会是AI写代码的能力确实在飞速进化但真正卡住大多数人的从来不是“AI写不出代码”而是“你没有一个可复用的流程去驾驭它”。什么意思呢举个例子。很多人拿到一个需求第一反应是打开对话窗口把需求一句话甩给AI然后等着它输出一堆代码。运气好的时候AI给出来的东西能跑运气不好的时候AI给你编造一个不存在的API或者它自己写了个bug但它不知道你还傻乎乎地复制粘贴进项目里结果编译报错、运行崩溃来回折腾一下午。然后你就得出一个结论“AI写代码不行。”这是AI不行吗不是。是你没有流程。传统开发里我们讲“需求分析—方案设计—编码—测试—部署—维护”每一步都有明确交付物。AI编程时代这套流程不但没消失反而更重要了。只是我们需要把流程里“人做的事情”和“AI做的事情”重新切分清楚再把两者接起来。我花了大半年时间把我自己的项目实践、踩过的坑、看过的各种经验贴整理成了一套“AI编程完整工作流程”版本号写到v2.0就是因为我确实迭代过一版。v1.0的时候我的流程是“写提示词→生成代码→报错→改提示词→再生成”基本是打地鼠。v2.0的核心变化是在任何一行代码生成之前先做好任务切片、上下文准备、验收标准定义。这一套折腾下来AI生成代码的一次通过率提升非常明显返工成本直线下降。这篇文章就是要把这套v2.0流程完整拆开。它适合谁适合作战在一线的开发者无论你是用C写游戏小项目、用Python做数据分析脚本、用Java写业务接口还是刚接触AI编程没多久的初学者只要你不想再被AI“坑”想把AI真正变成生产力工具这篇文章都值得你花二十分钟看完。2. 任务切片AI编程的第一原则是“一次只做一件小事”2.1 为什么AI在复杂任务上容易翻车先说一个现象。现在的对话式AI确实具备很强大的上下文能力动辄几十万字上下文窗口但这不代表它能从头到尾维护一个大型工程的一致性。很多人让AI“写一个完整的电商系统”你觉得AI真的会给你一个能部署的电商系统吗实际上它会给你拼凑一个极为粗糙的骨架表结构是乱想的接口没考虑鉴权事务边界是错的甚至目录结构都没对齐你本地的技术栈版本。回头分析一下这背后的原因并不神秘。AI模型本质上是下一个词的预测器它的每一段输出都基于当前上下文和概率分布。任务越大它的推理链条越长早期输出的小错误会在后期被反复引用、放大。就像人写长篇小说开头埋了一个坑到后面要么忘了填要么强行圆回来圆不回来就崩了。AI也一样长输出往往在前面定义了一个变量名的含义写到最后自己都忘了。所以我在v2.0流程里把“任务切片”放在了最优先的位置。**任何需求到了写提示词之前必须先拆成若干个可独立验收的任务单元。**每个单元要小到AI能在一次对话窗口里相对稳定地生成完并且你能明确判断它对还是不对。2.2 切片的具体方法按“垂直切分”而不是“水平切分”切片不是拍脑袋乱砍。我推荐的做法是按“功能纵向切片”拆分而不是按“代码层次横向拆分”。举个实际的例子。我要做一个“图书管理系统的借书接口”。横向拆分的意思是任务A写数据库表结构任务B写ORM模型任务C写Service层逻辑任务D写Controller接口任务E写测试用例这种拆法符合人的分工习惯但不适合AI。因为AI在写Controller的时候需要知道表结构字段名、Service方法的签名如果表结构是你之前在别的任务里生成的此时上下文已经不在对话窗口里了。你只能把之前的代码复制粘贴进来。一旦表结构后面改了你所有下游任务的上下文全都失效返工成本爆炸。垂直切片的意思是按“一个完整功能从入口到出口”来拆任务A实现“用户查询图书列表”的完整链路包括表结构持久化、查询逻辑、API接口、返回JSON格式任务B实现“用户借书”的完整链路包括事务、库存扣减、借书记录写入、异常处理任务C实现“用户还书”的完整链路每条链路都是一个可运行、可验证的小功能。AI生成完毕后你可以立刻编译/运行/点击验证。任务之间如果需要共享表结构或公共工具类那就先把那部分提取出来作为“基础任务”先行完成。我自己的经验是单个AI任务的代码量控制在200行以内比较好复杂一点的也不建议超过400行。超过这个量级AI的错误率会显著上升而且排查问题的成本也开始超过它的生成收益。这个阈值不是一个精确的数字但我建议你把它当作自己任务切片的参考标尺。2.3 任务切片的产物一个明确的“任务卡片”切片之后每个任务要形成一张“任务卡片”里面包含五个要素任务目标一句话说清楚要什么功能包括输入、输出、核心效果依赖上下文需要读取哪些已有文件、哪些接口定义、哪些数据表字段技术约束语言、框架版本、编码规范、必须使用的工具类验收标准用什么样的方式验证这个任务完成了是运行一个命令还是打开网页点一下还是跑一条测试用例禁止事项绝对不能做什么比如“不要改数据库现有表结构”“不要引入新依赖”这个任务卡片是写提示词的基础。它不是给别人看的文档而是给你自己梳理思路用的。很多时候你把这个卡片写清楚问题就已经解决了一半——因为AI犯错的很大一部分根源是你自己根本没说清楚你想要什么。提示任务切片这个动作别让AI来做。虽然有些AI工具支持“自动拆解任务”但我还是建议人工先拆一遍。只有你自己理解了任务的边界和依赖关系你才能在后续步骤中判断AI生成的结果是否正确。AI帮你拆你还要反过来验证它拆得对不对省不了多少事。3. 上下文构建让AI“站在你的代码库里”说话3.1 上下文质量决定生成质量如果你用过多个AI编程工具你可能会发现一个奇怪的现象同一个模型在不同的工具里表现水平似乎不一样。Cursor里表现好的模型放到一个普通聊天网页里可能写出来的代码质量就差很多。这很大程度不是模型变笨了而是工具的“上下文构建能力”不同。Cursor这类工具会把你当前打开的文件、相关文件索引、最近修改记录、项目配置文件拼装成一段上下文一起发给模型。你的项目背景越丰富模型对任务的误解就越少。我见过太多人在“AI编程”上吃亏就是因为他们在拿裸模型硬写代码没有把项目结构告诉AI没有把相关代码放进去没有说明依赖版本就凭一句“帮我写一个登录接口”AI当然只能给你一个从零开始的、假设了一堆不存在的依赖的“玩具代码”。所以在v2.0流程中上下文构建被提到了跟任务切片同等重要的位置。你得主动告诉AI“你的任务是在什么环境下执行的”。3.2 手动构建上下文的三类内容如果你用的是普通的AI聊天窗口没有深度集成代码库你需要手动把三类信息塞进对话第一类项目级信息项目是什么、用的什么技术栈、目录结构什么样子、关键依赖的版本。这部分不用说太多两三段话就够了。它主要是让AI的输出在“技术选型”层面不跑偏。比如你的项目是Spring Boot 2.7 MyBatis-PlusAI就不会给你生成Spring Cloud微服务风格的代码。第二类文件级信息你正在写/改的那个文件以及它直接依赖的相邻文件的代码。比如你要写一个Service的实现类那你至少要把对应的Entity、Mapper接口、Controller方法签名、前端传来的参数结构贴进去。为什么因为AI写实现类的时候如果你已经把Mapper接口的方法签名给它看了它就不会瞎编一个不存在的方法如果你把Entity字段都给它了它写属性映射的时候就不会把userName写成name。第三类语义级信息这个任务的背景目的。它不只是“写一个方法”而是“在用户注册时对手机号做格式校验校验规则是大陆11位开头1第二位3-9”。你光说“校验手机号”AI默认会用宽松的1[3-9]\d{9}还算好但如果想加密校验规则你不说它就不知道。这三类信息怎么组织到提示词里我建议按固定模板来【项目背景】 这是一个基于XX框架的XX系统技术栈为XX。项目目录结构如下... 【当前任务】 我要实现【具体功能描述】核心目标是...输入是...输出是... 【相关代码上下文】 以下是当前项目中的相关文件片段 - Entity.java 的字段定义... - Mapper.java 的方法签名... - 当前要写的文件是... 【约束条件】 - 使用XX版本语法 - 不要引入额外依赖 - 保持与现有代码风格一致 【验收标准】 生成代码后我会运行XX命令/访问XX页面预期看到XX效果。这个模板不是死的你可以按需增删。但核心逻辑是一致的在让AI写代码之前先让它“掌握”足够多的背景信息。3.3 工具内置的上下文比手动贴代码强在哪如果你用的是Cursor、Windsurf、VS Code Copilot这类深度集成IDE的工具很多上下文构建工作可以由工具自动完成。比如Cursor的Codebase、File引用#全局搜索符号它能把你指定的文件内容直接嵌入提示词。这些工具在“找相关代码”这一步上确实是优势。但即便是这样另一部分工作还是需要你做你要明确指出“需要AI读取哪些文件”。工具能帮你把文件内容拉进上下文但它不知道你这次任务依赖的是哪几个文件。我看到过不少人在Cursor里对着整个代码库说“帮我改一下登录逻辑”然后AI自作主张读了一堆无关文件生成的改动方案又臭又长。正确做法是用精确引用登录相关的Controller、Service、Mapper文件限定AI只在相关范围内思考。顺带说一句很多人在多文件项目里不习惯贴上下文总觉得“AI聊天框里一堆代码看着乱”。我的经验是乱一点没关系上下文里的代码不是给你看的是给模型“喂”的规则。你只需要保证你贴的东西是准确的、完整的、最新的就行。乱不是问题旧和假才是致命的。3.4 上下文一致性的维护一个容易被忽略的坑是上下文会和实时代码脱节。你在对话开始的时候贴了一份UserService.java然后你手动改了这份文件再让AI继续生成代码它脑子里记的还是旧版本的代码。轻则生成的代码跟你的现状不匹配重则它基于一个你已经删掉的方法继续调用直接编译失败。所以我的习惯是每次开启一个新任务重新贴一遍最新代码。别偷懒用上一次对话里的历史内容。更好的做法是一个任务开一个对话窗口任务结束就把窗口归档下一个任务重新构建上下文。这也是为什么任务切片重要——因为每个任务本身就是一个独立的、可以在新对话里完成的单元。4. 提示词工程不是玄学是结构化沟通4.1 别再迷信“魔法提示词”网上流传着各种“AI编程提示词大全”“万能咒语”说实话我看过不少有用的内容占比例不大。提示词的本质是你在跟一个“懂很多但你不知道它此刻懂多少”的模型进行沟通。它的核心技巧不是某个神秘关键词而是信息完整性和结构清晰度。打个比方。你让一个新来的实习生写个模块你会怎么交代你肯定会说清楚背景是什么、要做什么、不要动什么、这个模块跟旁边的模块怎么对接、完成后你怎么验收。你对AI也应该这么说话。很多人对AI的态度反而敷衍得多——“帮我写个注册接口”没了。这不叫提示词工程这叫许愿。4.2 一套可以直接复用的提示词模板下面这个模板是我在实践中逐步打磨出来的不敢说适用所有场景但对于“写一个新文件”“实现一个功能方法”“修改一段逻辑”这类编程任务它足够可靠请帮我实现以下功能 【任务】在用户管理模块中新增修改用户状态接口。 1. 接口路径PATCH /api/users/{id}/status 2. 请求体{status: 0}0表示禁用1表示启用。 3. 校验逻辑当前用户必须为管理员且不能修改自己的状态。 4. 返回格式{code: 0, message: success, data: null} 【项目上下文】 - 框架Spring Boot 2.7.9 MyBatis-Plus 3.5.3 - 现有Controller... - 现有Service接口... - 现有Service实现... - User实体字段... - 统一返回类Result的定义... 【约束】 - 使用MyBatis-Plus的LambdaQueryWrapper来查询用户。 - 不要使用全局异常处理外的自定义异常。 - 管理员权限校验请复用AuthUtils.checkAdmin()方法。 - 不要删除或改动其他已有方法。 【验收标准】 - 编译通过。 - 使用IDEA Test REST API发送请求管理员可修改他人状态非管理员返回403。 - 修改自己的状态时无论是否管理员均返回业务错误码40001。 【输出要求】 - 只输出代码不要解释。 - 改动涉及的文件请列出文件路径。这个模板里面没有一句废话。“输出要求”这个部分也很重要很多AI默认会给你写一堆解释虽然有参考价值但你要是复制代码还得从解释里挑效率反而低。你需要的是“确定性输出”直接拿代码走人。4.3 提示词中的“负面约束”我强烈建议在提示词里加一个“约束/禁止事项”的段落。负面约束的价值在于它能把AI引向你自己项目里特定的“暗规矩”——这些规矩代码里看不出来只有你在这个项目里待久了才知道。举几个真实例子“不要使用Lombok的Builder”因为你们项目团队约定不用Builder模式的链式赋值“不要用Java Stream的Parallel Stream”因为你们线上出现过线程池问题“日期格式化使用yyyy-MM-dd HH:mm:ss不要用yyyy-MM-dd’T’HH:mm:ss”“不要写service层包装的脏代码直接返回Result”这些约束是代码库之外的“项目宪法”。你不告诉AI它就按它的统计默认值来大概率跟你项目的真实风格对不上。4.4 多轮对话的修正技巧一次生成的代码很少有完全符合预期的。这时候别急着把结果往项目里塞也别闷头改。你有两个选择一是在当前对话窗口继续跟AI对话修正二是开新窗口重写。我的经验是如果仅仅是小问题变量命名、缺少注释、格式不对在当前窗口继续聊如果是结构性错误整体思路不对、接口设计不合预期、某个核心逻辑写错了那别浪费时间开新窗口重写上下文再来一次。在多轮修正的时候注意一个策略指出问题的时候带上“期望值”。不要只说“这个不对”要加一句“我认为正确的是xxx”。比如“这里不需要用Integer应该用Long因为数据库主键是bigint”。你给的信息越具体AI下一次修正就越有方向。它的生成质量高度依赖你给的反馈信号信号模糊它就只能在错误方向上尽力修补。这一节怎么说呢提示词工程谈不上什么高深学问它更像一个“需求沟通技巧”在新的交互媒介上的延伸。你平时跟同事怎么把一个需求聊明白你就怎么跟AI聊再加上一点结构化的表达习惯。理解了这一点你根本不需要背提示词模板。5. 实现与验证生成只是开始“看得见的验收”才算完成5.1 AI生成代码后你至少要做四层检查我见过很多人AI生成代码之后看一眼觉得“挺像那么回事”就直接复制保存了。这种行为是比较危险的。AI生成的代码是需要经过人工检查的而且不是“泛读”是带着具体目标的核对。我自己的检查清单有四层第一层编译层。不管什么语言第一时间编译或者至少让IDE做语义分析。Java项目跑mvn compile或gradle buildPython项目至少python -m py_compile前端项目跑npm run build。编译过了说明至少没有语法错误和类型错误这关过不去的代码神仙来了也白搭。第二层逻辑层。逐行走读一遍关键逻辑。重点看三件事边界条件有没有处理、异常路径有没有兜底、状态变化符不符合业务预期。别信AI写的注释——它经常把自己的意图写得比实现还美丽但实际上代码跑的是另一回事。第三层集成层。AI生成的代码通常是在你给它的那段上下文里“看起来没问题”但一旦跟真实项目里的其他模块对接问题就暴露了方法名对不上、参数类型不一致、依赖缺失。这一层验证通常需要你真正把代码放进项目里然后调用一次看结果。第四层回来看看。在整体项目跑起来之后回到AI生成代码的位置向AI提问“你生成的代码把XXX方法的调用路径链路列出来”“这个分支在什么情况下会走”。让AI自己解释一遍它的代码这其实是很好的逻辑自检。如果AI解释得含糊不清说明这段代码的真伪存疑。5.2 能跑不等于正确功能的可观测性这一步是很多人忽视的。AI生成的代码“能跑起来”不代表“逻辑正确”。你接了一个登录接口POST一下返回200你就觉得OK了回头看看密码校验了吗用户名存在吗错误密码返回了什么还有并发登录、账号锁定状态、登录日志写入……这些你可能写一个简单接口用例都触发不到。所以我在流程里加了一个“验收标准要做到可观测”的要求。拿前面的“修改用户状态”接口举例你不能只看返回code0就通过你得真的去数据库里查一下user_status字段是否变了你得用一个非管理员token调一下确认返回403你还得用自己的账号试一下确认返回40001。每一个验收点都要有明确的观测动作。这就要求你在写任务卡片的时候就要把验收标准定义到“可操作”的粒度而不是写“功能正常”这种废话。有些朋友可能觉得这一步啰嗦但正是这一步能大幅减少线上回归的坑。与其事后花两个小时在线上查一个奇怪的bug不如在生成这一步花五分钟做一下验证。5.3 人工介入的时机流程里还有一个高频问题AI生成代码后我应该亲自改多少我的原则是核心逻辑必须人工把关模板化代码可以交给AI全权处理。什么是模板化代码比如一个简单的CRUD接口Controller、Service、Mapper的骨架这类代码的套路性极强AI生成基本靠谱你改反而容易引入低级错误。什么是核心逻辑比如多表联动的事务处理、需要严格幂等的操作、涉及金额字段的校验、状态机的流转判断这些代码里任何一个细节错了都可能产生线上事故。我建议这类逻辑不要直接信任AI的第一版输出至少要自己走读一遍逻辑并且用测试用例去实测。也许你会说“既然核心逻辑还得我看那AI编程岂不是很鸡肋”我不这么认为。**AI帮你省掉了80%的机械编码时间剩下20%的核心逻辑你有了更多时间去精雕细琢。**以前一个接口写下来要一小时现在AI给你10分钟出稿你花20分钟精修逻辑总共半小时怎么算都是赚了。6. 调试与排错别跟AI“拉扯”用证据链驱动机器人6.1 AI代码报错先别急着把报错贴回去AI生成代码跑起来报错你的第一反应是什么很多人直接CtrlC复制报错信息粘到对话窗口问AI“怎么修”。如果这个流程能解决所有问题那世界上的bug早就消失了。事实是如果你只贴报错信息AI顶多给你一个“可能的原因”列表和对应的“修复尝试”——这会变成一场低效的试错循环你改它跑跑了又错又贴回去再改。不是说这么做完全不能解决而是解决问题的概率不够高而且你什么都没有学会。我推荐的方法是先按传统调试思路把问题定位出证据再带着证据去问AI。比如Java的堆栈异常你应该先看异常类型和栈顶信息判断是空指针、类型转换、还是数据库约束冲突。如果是数据库问题把SQL日志拉出来如果是前端问题打开控制台看网络请求的状态码和响应体。总之先自己定位出“究竟哪一行代码触发了错误”再把这个证据和对应的代码片段一起丢给AI。6.2 一个实际调试案例MyBatis-Plus分页失效问题说个具体案例。我之前在项目里让AI生成一个分页查询接口AI用的是MyBatis-Plus的Page对象配合分页插件。代码生成后本地一跑返回结果是全表数据分页完全没生效。我当时没有直接把报错贴给AI——因为这个场景没有报错只是结果不对。我做了什么我先打开控制台看SQL日志发现SQL语句里面压根没有LIMIT关键字也就是说分页插件没生效。于是我自己先查了一下配置发现项目里没有注册MybatisPlusInterceptor这个Bean。原因找到了是配置缺失不是AI生成的代码有错。然后我带着这个发现问AI“项目中缺少MybatisPlusInterceptor Bean导致分页SQL没有LIMIT请给出注册方式注意不要与现有MyBatis配置冲突。”AI很快就给出了正确的配置代码。全程浪费不到五分钟。如果我不去定位直接把“分页没生效”丢给AIAI可能会怀疑是Page参数传错、持久层方法写错、前端参数没传对……来回排查好几轮还不一定对。6.3 另外一种思路让AI当“代码评审员”而不是“代码生成器”调试阶段除了让AI直接修代码我还会让AI做另一种事情代码审查。经常是代码逻辑没问题但就是跟项目里其他部分集成时出了问题。这种问题让AI“重写”往往越改越乱让AI“解释”反而能更快暴露盲点。比如提示词这么写以下是我写的一段代码实现了XXX功能。 但是我发现它跟YYY模块集成时在某些情况下会抛出ZZZ异常。 请以资深研发的身份逐行审查这段代码指出所有可能导致ZZZ异常的地方并解释为什么。 不要直接给出修改后的代码先列出可能原因清单。这种模式能发挥AI“读代码”的长处。它的知识面广能识别出很多你自己根本没意识到的边界场景。等你拿到了可能原因清单再结合自己掌握的业务情况锁定真正的问题点最后再让AI给出修复代码。这个过程比我前面说的“报错贴回去式调试”要高效得多。6.4 建立“错误模式”笔记最后一节聊一个长效习惯。调试过程中你会积累很多AI编程特有的错误模式——比如“它喜欢用Java 17的语法但你项目是Java 8”“它在写TypeScript时总是漏掉async/await”“它在生成SQL时默认用!判断空值结果导致索引失效”。这些问题第一次遇到你会觉得郁闷但第二次第三次遇到那就是纯赚了。我的做法是维护一个简单的Markdown笔记按语言/框架分类记录“AI在什么场景下容易生成什么错误”“我怎么在提示词里提前规避”。例如场景AI常见错误预防方式排查方式Java日期处理直接new SimpleDateFormat约束必须使用DateTimeFormatter代码审查时搜SimpleDateFormatPython异常裸捕获或直接吞掉异常约束保留异常上下文代码审查时看except块SQL空值判断!会导致NULL记录被过滤提示词明确空值语义看执行计划这个表格看着不起眼但累积到一定量之后你的AI编程效率会再上一个台阶因为很多坑根本还没发生就被你的提示词提前“垫”掉了。7. 版本管理与回滚AI编程时代的代码保鲜术7.1 为什么AI编程背景下版本管理更关键以前写代码是你自己一个字一个字敲的代码的演进脉络在你脑子里。现在写代码你的代码可能是AI一次性生成的可能是AI再修改的也可能是你把AI生成的代码逻辑跟自己的理解混在一起改出来的。代码不是你写的你对它的熟悉程度天然就低一层。这种情况下版本管理的作用就从“记录历史”升级为“安全网”。我强烈建议任何一次AI生成/修改代码第一步就是创建一个新的分支或者至少对当前状态打一个tag。为什么因为AI的第一次生成大概率不是最终答案你需要一个低成本甚至无成本回到起点的能力。如果你直接在主干上把AI生成的代码覆盖掉原来能跑的代码然后发现AI生成的东西有严重问题你想回退都不方便。7.2 我的提交习惯颗粒度小信息量多我自己的习惯是每个AI任务完成后做一次独立的Git提交。提交信息里写清楚“本次由AI实现了什么功能”“验证了哪些验收点”。这个习惯有几个好处一是方便回滚。每个任务对应一次提交哪个任务出了问题直接git revert那一条就行不会牵扯到其他无关改动。二是方便审查。代码评审的时候按提交看差异逻辑清晰不会出现一个提交里混杂着十几个无关改动的情况。第三个好处是提交信息本身构成了一个“AI驱动开发”的日志。三个月后你想复盘当时为什么那么设计翻一下提交历史就清楚了。若没有这个习惯你看着一段AI生成的代码大概率回忆不起来它为什么长这样。7.3 大改前的“快照”操作还有一种场景你要让AI做一个跨多个文件的较大改动比如重构一个模块的接口设计。这个时候光靠Git提交可能还不够因为你改到一半发现方向不对你可能想回到的是改动之前的某个状态。Git分支可以做到但我更习惯在动手前直接复制一份关键文件的备份放进一个_bak目录改完没问题再删掉。听起来土但关键时刻能救命——尤其在你的项目还没有完整纳入版本控制的时候。8. 常见问题排查与速查表这个章节我把自己在实践AI编程过程中遇到的典型问题和对应的解决思路整理成了一张速查表方便你日常遇到了直接照着排查。问题现象大概率原因排查思路解决参考AI生成的代码编译报错报错位置是它自己虚构的API上下文里没提供真实API定义检查提示词里是否包含相关文件内容补充真实代码片段后重新生成代码能编译但运行结果不符合预期提示词里验收标准太模糊先自己复现一次记录具体输出把“预期输出”补充到提示词让AI修正提示词写了“不要用X”AI还是用了X负面约束不够具体或上下文优先级更高检查是否在上下文里有X的示例代码用禁止项在输出要求中单独声明修改一处破坏了另一处已有功能垂直切片没切好任务粒度太大查看Git提交定位哪次改动引入回滚后拆分为更细的任务重做AI连续多轮修改仍然跑不通上下文已经错乱修修补补没有意义停止当前对话开新对话重建上下文重新生成多文件协作修改时AI只改了部分文件任务提示里没列明涉及的文件清单检查输出文件列表明确列出所有需要修改的文件路径分页/事务/权限这些框架级功能失效缺少框架配置或拦截器看日志确认是否生效让AI补齐配置代码代码风格跟项目其他模块不一致项目CODE_STYLE没有写进提示词找一份已存在的风格参考代码把参考代码片段贴进上下文除了表里的内容还有几个话想多说一句第一永远不要在生产环境直接测试AI生成代码。你至少要在本地开发环境、测试环境各跑一遍确认没有问题再上生产。这条不是AI编程时代的新规矩而是传统开发就有的红线在AI编程时代更需要强调。第二AI生成代码的时间依赖上下文长度。如果你贴了太多无关文件AI生成速度会变慢而且可能被无关代码干扰。上下文构建不是堆料越多越好要克制只贴本次任务相关的。第三关注你使用的AI工具本身的版本迭代。无论你用的是开源模型本地部署还是商业AI编程IDE定期更新是必要的。新版本通常意味着更强的代码生成能力、更好的上下文理解。我就见过有人一直用某个旧版Claude模型生成SQL时老犯同一个错误升级之后概率大幅度下降。9. 收尾还想说的几句实在话这套工作流v2.0从任务切片、上下文构建、提示词模板到代码验收、调试排错、版本管理核心其实就一句话把AI当成一个能力很强、但需要明确指令和严格验收的“远程协作者”。你对协作流程的控制力决定了AI编程的上限。我个人在实际操作中最受用的一个改变是不再抱怨AI写代码“不靠谱”而是开始反思自己有没有把靠谱的前提条件给它。大多数时候答案是没有——任务没拆小、上下文没喂足、验收标准没定清。等你把这些补齐了AI编程的体验会好非常多。最后再分享一个小技巧。当你要开始一个比较大的项目时别直接开始写代码。先去把整个需求手工拆成一份“任务卡片清单”每个卡片都可以对应到一次独立的AI对话。然后你只需要一个任务一个任务地执行构建上下文→写提示词→生成→验证→提交。这个过程看起来没有“让AI一口气写一个完整项目”那么炫酷但它稳定、可控、可复现。而且随着你做的项目越来越多你会发现这套流程本身也可以被沉淀成你团队里的“AI编程规范”——到了那一步你就不会再来回折腾提示词了而是像流水线一样交付代码了。
