1. 从“会问”到“能用”V2.0流程要解决的真实问题最近这些年AI编程从一个新鲜概念变成了很多人日常开发的一部分。但我观察到一个非常普遍的现象大多数人和团队试了一圈AI编程之后得出的结论往往是“这东西写点简单的还行真到项目里就废了”。我自己也经历过这个阶段而且一度也差点放弃。先说结论不是模型不够强也不是工具不好用而是我们还在用“问答式”的思路使用AI编程没有把AI编程当成一条需要设计的流水线。问一句、生成一段、复制粘贴这种零散的用法在几十行的小脚本里能跑通一旦进入真实项目上下文断裂、接口对不上、风格不一致、代码越改越乱这些事就像连锁反应一样涌过来。我最早推的V1.0流程就是折在这里。1.1 V1.0踩过的三个坑V1.0那会儿我的流程很简单把需求用自然语言描述一遍扔给AI让它生成代码然后我人工检查有没有明显问题再提交。听起来没毛病实操下来问题很大。第一个坑是上下文不完整。比如我会说“给现有订单模块增加一个导出Excel的功能”AI确实生成了导出代码但它不知道我项目里用的是哪个Excel库、订单数据结构长什么样、导出需要排除哪些字段、大文件怎么处理。结果就是代码语法全对但拿进项目里根本没法用不是字段名对不上就是和现有代码风格格格不入。第二个坑是代码Review阶段被打回。AI生成的代码初看没问题仔细看会发现它喜欢自己发明一些“合理”的封装明明项目里已有util函数它不用非要新写一个明明组里约定用Result返回错误它按自己的理解throw了异常。等Review发现这些问题再回去改来回成本比我自己写还高。第三个坑最隐蔽就是AI生成的补丁和人工改动互相覆盖。同一个文件AI建议改这里我顺手改了那里下次再让AI继续改的时候它的上下文还是旧版本于是重复生成、重复冲突git历史乱成一团。V1.0的失败让我意识到一个关键点AI编程的产出质量不取决于你多会“问”而取决于你有没有一套办法把项目的真实上下文稳定地交给AI并且把AI的产出接到人审、验证、合入这条链路上。1.2 V2.0的三个设计原则迭代到V2.0的时候我给自己定了三条原则整条流程都是围绕它们设计的。第一把任务分解当作核心工作。不再让AI“一次写完整个功能”而是把功能拆成多个可以独立生成、独立验证的小任务一个一个喂给AI。每个小任务的目标足够明确AI的产出质量会高很多出错了也容易定位。第二让AI在完整的上下文里工作。这里的上下文不只是代码片段还包括项目结构说明、接口约定、数据模型、相关文件路径、约束条件。我会花时间把这些信息整理成AI能直接理解的形式而不是指望它从对话里猜。第三用工程手段兜底而不是用信任兜底。AI生成的代码一律当成“外部提交者”的代码来对待要过格式化、要过静态检查、要跑测试、要走Code Review。这套机制先把闸门架好再让AI自由发挥。这三条原则构成了V2.0流程的基础。下面几章我会把每一个环节展开讲清楚包括我使用的工具选型、提示词模板、工程配置和踩过的坑。2. 工具链选型IDE派、API派、Agent派的差异到底在哪关于AI编程工具网上讨论非常多。最常见的说法是“哪款AI编程软件最厉害”但以我自己的经验问“哪个最厉害”不如问“哪种使用方式适合你的项目”。我把现在主流的用法分成三派IDE派、API派、Agent派。三者的本质不是工具强弱而是人和AI的分工方式不同。2.1 三派是怎么工作的IDE派是最普遍的一种代表产品有GitHub Copilot、Cursor、JetBrains AI Assistant等。它们内嵌在编辑器里边写代码边补全也可以选中代码让AI解释、重构、写测试。这套方式上手成本最低交互直观适合日常开发中大量“局部”工作比如补一个方法、写一段测试、优化一段逻辑。API派是指你自己接大模型API把代码库内容、任务说明、历史记录拼成提示词发送出去再把结果收回来处理。像DeepSeek API这类开放接口很多人会拿它来做自动化脚本、批处理工具甚至做一个公司内部的代码助手。API派灵活但需要开发量它最大的价值是可控提示词怎么拼、上下文取哪些内容、结果怎么校验全部由你自己决定。Agent派是近两年增长最快的一类通常被称为AI编程智能体。它们不只是生成代码还会尝试自己去理解仓库结构自己拆解任务、运行命令、跑测试像“程序员实习生”一样去执行任务。典型的产品包括OpenAI Codex agent、Devin以及IDE里的Agent模式。这类工具的优点是自动化程度高缺点是控制难度大跑偏的时候排查成本很高。2.2 选型对比与我的判断标准我自己长期同时用IDE派和API派Agent派在特定任务上会启用。下面这个表格是我自己的评估依据不一定适用于所有人但可以作为参考维度IDE派API派Agent派上手成本最低装插件就能用高需要开发对接中等需要配置运行环境上下文控制编辑器内自动带入但深度有限完全自主控制自主读取仓库但难精确控制适合任务日常编码、补全、单文件修改批处理、自定义流程、家族化代码生成探索性开发、全局重构、测试修复可控性中等最高较低典型成本订阅制为主按token计费技术成本高订阅或平台计费如果团队想快速试点我建议从IDE派开始比如Cursor或Copilot用两周时间聚焦在一个真实模块上感受AI在上下文完整和不完整两种情况下的输出差异。如果你对代码质量有很强的制度化要求比如每次AI生成必须经过固定检查那API派值得投入。你可以自己写一个管道脚本把代码库的索引、任务说明、输出规范全部包装在提示词里然后对AI返回的代码做自动化校验。API派很适合做成团队内部的“私有化AI编程通道”因为它能把团队规范直接烧进提示词。Agent派请务必在低风险任务上试用比如“为某个模块补充单元测试”“更新文档注释”。让它自主拆解任务、跑测试的能力虽然看起来省事但如果代码库本身结构混乱Agent很容易在错误的方向上越走越远。我个人的判断标准很简单越需要逻辑精确的地方越要人工控制上下文API派或IDE派手动指定文件越需要探索性工作的场景越可以用Agent去铺路。最重要的指标不是生成速度而是“返工率”。一款工具如果能让你的返工率从50%降到20%哪怕贵一点都是值的。3. 需求到代码的执行主轴五段式流程的每一段怎么落地这一章是整个V2.0流程的核心。我把从需求到代码合入的过程拆成五段每一段都有明确的目标、产物和检查点。这五段不是AI替代人而是人和AI各自做自己擅长的事再通过工程手段缝合起来。3.1 第一段需求澄清我在V1.0犯的最大错误就是拿模糊需求直接喂AI。现在我的第一段永远是需求澄清且这一段全部由人来完成AI不参与。需求澄清的产物不是一句话而是一份包含边界条件、验收标准、不做什么的简短说明。以“订单模块增加导出Excel功能”为例我要求在动手前至少回答这几个问题导出范围是全部订单还是当前筛选结果数据量大概在什么量级导出的字段清单是什么字段名用中文还是英文是同步导出还是异步导出超过多少行要改成后台任务权限如何控制哪些角色可以导出这个功能和现有导出、报表模块是否重复这些问题的答案直接影响后续的任务拆解和AI生成。需求澄清做到了什么程度算合格我的标准是另一个人只看需求说明不需要再追问我就能把产品逻辑理解清楚。即使这段内容只有几行也要写清楚“是什么—边界—验收标准”。需求澄清不建议跳过还有一个原因AI生成的代码往往在功能主线上表现不错但在边界条件的处理上非常薄弱。如果你自己都没想清楚边界AI更不会帮你补上。3.2 第二段任务拆解与上下文装配需求澄清之后我会把需求拆成若干个可以独立交付的子任务每个子任务控制在200行代码以内。拆解原则是“每个子任务有一个可验证的产出物”比如“实现Excel导出的数据查询方法”“实现导出模板渲染”“实现导出接口的权限校验”。拆解完成后最难的部分来了上下文装配。这是V2.0和V1.0拉开差距的关键环节。我会为每一个子任务准备一个结构化的上下文里面包含任务说明这个子任务要做什么、不做什么相关代码路径涉及哪些文件各文件的作用是什么数据模型与接口约定字段名、类型、返回值、错误处理方式项目风格约束命名规范、文件组织方式、日志规范、异常处理方式验收条件这个子任务完成的标准是什么这套上下文不是每次都从零写而是沉淀成模板。项目级信息数据模型、风格约束我会维护在项目根目录的一个ai_context.md文件里任务级信息在拆解时临时填写。这样既不重复劳动又能保证AI每次面对的都是“知根知底”的精确任务。3.3 第三段分步生成与人工审阅上下文装配完成后开始正式生成代码。这里有一个很重要的技巧不要把整个子任务一次性让AI写而是让AI先给出实现方案人确认方案没问题再让它写具体代码。方案先行能避免AI在错误的思路上浪费大量输出。比如我会这样发提示词请根据下面上下文先给出这个子任务的实现方案。要求列出你将修改的文件、每个文件的核心改动点、涉及的函数签名和异常处理方式。不要写具体实现代码只给方案。确认方案后再开始写代码。这一步的产出是“实现方案”人会审阅方案里的技术选型是否和项目一致。方案通过后再让AI按方案分文件、分步骤生成具体代码。每个文件生成后我会立刻查看并结合需求说明检查而不是等全部生成完再统一审阅。人工审阅的重点不是逐行读代码而是看几个关键点接口是否和项目约定一致异常路径是否处理有没有引入项目不需要的依赖有没有重复造轮子审阅发现问题时我会把问题描述清楚并附上项目里的现有实现要求AI基于项目现状重新修改而不是让它自由发挥。3.4 第四段自动验证与回归AI生成的代码即使通过人工审阅也必须过一遍自动验证。我在项目里配置了一条验证流水线任何一个AI生成的改动都必须在这条流水线里通过才能合入。流水线包括这几个环节代码格式化检查统一格式减少diff噪音。静态检查启用项目现有的lint规则捕获未使用变量、明显的逻辑瑕疵。单元测试跑与该子任务相关的测试用例。类型检查TypeScript项目跑tscPython项目跑mypyJava项目跑编译。构建验证确保改动可以正常构建打包。这条流水线的好处是把“AI代码质量”变成一个客观指标。很多AI生成的代码在功能层面没问题但会悄悄绕过项目中已有的检查规则。如果没有自动验证兜底这些代码会在集成阶段集中爆发。我在实践中还有一个小技巧给AI生成的代码打上一个统一的git commit前缀比如ai: feat(order-export): 实现订单导出数据查询。这样后续如果需要回滚AI相关改动可以用前缀快速过滤出AI产生的提交定位成本低很多。3.5 第五段落库与复盘最后一个环节是对每一段AI协助完成的开发做一次轻量复盘。复盘不要搞得很重回答三个问题就够了这次AI生成的返工率是多少返工的主要原因是什么下次如何在提示词或上下文层面避免同样的问题我会把复盘结论直接追加到项目的ai_context.md里。比如遇到“AI总是自创常量常量名而不是使用项目已有的常量”这类问题就在上下文里补一句“常量定义统一从constants模块引入不要自行定义新常量”。这些沉淀下来的规则会随着使用次数越来越多AI的第一次生成质量也会越来越高。这个“落库与复盘”的环节是V2.0和V1.0最大的区别。V1.0里的AI每次都是“新来的实习生”V2.0里的AI则像是一个不断积累经验的稳定协作者。日积月累这个上下文文件会成为团队在AI编程方面的核心资产。4. 提示词的三套高复用模板与九条隐性规则很多人在聊AI编程提示词的时候喜欢追求“让AI像理解人一样理解我”。但我的经验恰恰相反AI编程提示词的本质不是写作文而是写接口文档。越结构化AI的理解越准产出越稳定。我把自己最常用的提示词沉淀成了三套模板分别应对新功能开发、Bug修复、重构与代码解释。每一套都在多个项目里验证过直接复制改参数就能用。4.1 模板一新功能开发新功能开发的核心是“上下文的完整性”。每次写提示词时我都按这个顺序组织内容任务目标 用两到三句话说明要开发什么功能包含核心业务逻辑 约束条件 1. 不修改哪些文件/模块 2. 必须复用哪些现有函数/组件 3. 禁止引入哪些新依赖 4. 异常处理采用什么策略 现有实现参考 列出相关文件的路径说明每个文件里哪些内容需要参考 数据模型 字段名、类型、关联关系 验收标准 1. 功能行为符合预期 2. 通过单元测试 3. 代码风格与现有项目一致举个例子如果是给订单模块加导出接口提示词会让AI先阅读order_service.py和order_repository.py复用餐位数统计的现有函数禁止引入新的Excel库数据模型按订单表和订单明细表为准验收标准包括权限校验和空数据处理。这样的提示词虽然看起来冗长但AI收到之后几乎不需要猜生成质量非常稳定。4.2 模板二Bug修复Bug修复的提示词和其他场景有本质区别AI必须首先理解Bug的复现条件而不是直接给修复方案。我会用这样一个结构Bug现象 描述用户或测试中观察到的现象 复现步骤 1. 前置条件是什么 2. 操作路径是什么 3. 期望行为 vs 实际行为 代码路径 相关的文件与函数 我的初步排查 我怀疑的原因或者已经排查过但排除的假设 请你 1. 先分析可能的原因 2. 再给出定位方式加日志、写测试等 3. 确认根因后再给修复方案这个模板最重要的价值是强制AI先做分析再动手。我遇到过很多次AI在缺少复现步骤时直接按“最常见错误”去修结果改了无关代码甚至引入了新问题。加上“先定位后修复”的约束之后出错率明显下降。4.3 模板三重构与代码解释重构类任务的核心风险是“改坏已经工作的代码”。我的提示词会让AI优先关注行为保持而不是让它自由优化。重构目标 说明重构想要解决的痛点例如函数过长、重复代码、循环依赖 行为不变性要求 1. 对外接口签名保持不变 2. 返回结果语义保持不变 3. 原有的注释和日志尽量保留 重构步骤 1. 先输出当前代码结构分析 2. 再给出重构方案标注每个步骤的影响范围 3. 每完成一个步骤就输出中间结果等待确认后再继续代码解释类的提示词相对简单重点是设定解释的深度。我会告诉AI“面向刚接手项目的初级开发解释这段代码”它输出的内容会比“请解释这段代码”更通俗、更注重补充背景知识。4.4 九条隐性规则以上模板之外还有九条我总结的通用规则值得单独列出来。AI不确定的东西会编。规则就是允许AI回答“项目里没有找到XXX我基于XXX假设实现”而不是让AI硬造一个接口出来。“不做什么”比“做什么”更重要。提示词里明确写“不要修改配置文件”“不要动数据库迁移脚本”能避免大量无效改动。一条提示词只办一件事。功能生成、测试编写、代码解释分开问混在一起AI容易顾此失彼。给AI“停止条件”。比如“如果发现数据模型的字段不足以支撑这个功能立即停下来告诉我不要自动补充字段”。禁止AI“顺手优化”无关代码。AI在修改一个函数的时候经常会把旁边看着“不顺眼”的代码也改掉。明确要求它“只做任务描述中的改动”。让AI输出“变更影响面”。每次生成完代码都让它列一下改了哪些文件、影响了哪些现有功能。这会让AI在生成时更谨慎。模板里的占位信息要替换干净。把AI的输出直接复制到项目里之前记得去掉那些“请在这里替换为你的项目信息”之类的残留。不完整的信息要及时追认。AI问你要某个函数签名或接口定义时直接补给它不要让它在猜测中将就。这个看似低效实际大大降低返工。定时清理对话上下文。同一个对话内任务过多时前面任务的约束可能污染后面任务的输出。我一般在每个子任务完成后新建对话减少串扰。提示词模板不是一次写好的它们会随着项目的特征而变化。但底层的共性很明显上下文稳、约束清、追问有据、输出有序。能做到这四点手里的工具是哪个反而不那么重要了。5. 把AI产出嵌进真实工程链路git worktree、Code Review与持续验证AI编程除了“生成代码”这个环节之外还非常依赖工程链路的配合。很多翻车事故其实不是AI写错了而是AI改动的代码没有被放进真实工程流程里做约束。这一章讲我如何用git worktree、Code Review和持续验证三个手段把AI产出正式“接进”项目。5.1 为什么AI编程特别适合配合git worktreegit worktree是一个很实用的功能它让你在同一个仓库里同时维护多个工作目录。大多数人不常用它但它在AI编程场景里价值极大。我的工作方式是这样的在开始一个AI协作开发任务之前先基于主干创建一条独立分支并用git worktree add把这个分支放到一个单独的目录里。然后所有AI相关的改动都在这个工作目录里完成主工作目录不受任何影响。命令大致是这样# 在项目仓库目录下 git worktree add ../myproject-ai-feature -b feature/ai-order-export这样做的原因有三个。第一AI生成的代码可能会做很多“试探性”改动包括改配置文件、加依赖、调整目录结构。如果直接在主工作目录里折腾一旦AI跑偏回滚成本非常高。有了独立worktree不管AI怎么折腾主目录都是干净可提交的状态。第二worktree天然对应一个独立分支符合“一个任务一个分支”的工程实践。AI的提交历史可以自由改动最后再通过Review、测试合并回主干。第三worktree可以让多个AI任务并行推进。比如一个任务是导出功能另一个任务是报表优化两个任务各自有独立目录和分支互不干扰避免了多任务共用一个工作区导致的文件冲突。你可能觉得加一层worktree有点多余但我在实际项目中是吃过亏的。有一次我用AI批量修改接口参数AI自动刷新了依赖锁文件导致整个模块在新环境里构建失败排查了很久才找到原因。那之后我严格执行了“AI任务一律独立分支、独立worktree”的规矩再也没出现过这种问题。5.2 Code Review怎么看AI代码AI生成的代码合入之前必须经过人工Code Review。但这里的Review方式和看人写的代码很不一样我总结了几种思维方式。第一重点看“是否过度设计”。AI有一种倾向就是为一个简单需求生成一个远比需求复杂的实现。比如一段几行就能完成的字符串拼接它可能顺手引入一个Builder模式。Review时要盯住的是实现方案是否和需求复杂度匹配而不是方案本身技术含量高不高。第二重点看“是否绕过了项目约定”。AI不熟你的项目约定常常会自己发明处理方式。比如项目里已经统一用自定义异常类AI可能直接抛了RuntimeException。Review时要带着项目约定清单逐项核对发现不符合就直接打回。第三重点看“错误处理是否过度或不足”。AI生成的代码在“正常路径”上通常不错但异常路径处理要么没有要么堆了一堆冗余判断。项目团队要明确统一的错误处理策略如果AI生成的不符合策略能改就改不能改就让它重写。第四Review之后要留记录。V2.0流程里我会在PR描述里附上这个任务使用的提示词摘要、AI自己声明的影响范围和变更文件列表。后续讨论时这些记录能帮助理解设计意图也可以复盘哪里出了问题。5.3 持续验证在CI里怎么落地人工Review解决“该不该这么改”的问题持续验证解决“改了之后会不会坏”的问题。我在team里给AI协助开发增加了单独的CI流水线配置核心跟前面说的验证流水线一致但有几个额外的固化检查。禁止直接push主干所有AI相关代码必须走PR合入。PR必须通过自动化静态检查和单元测试才允许人工Review。锁定依赖文件在AI任务中不允许静默修改凡是依赖变更都要在PR描述里明确说明原因。启用git diff的“白名单”策略如果AI改动了流水线配置文件、部署脚本、安全相关文件自动挂起并要求人工确认。这些规则可以通过GitHub Actions、GitLab CI等平台实现。虽然前期配置有成本但一旦跑起来你会明显感觉到AI生成的代码在下沉到主干之前已经从“不信任区”进入“可验证区”。这也是一个团队能不能放心用AI编程的分水岭靠人盯还是靠机制盯长期效果完全不同。6. 边界感哪些场景别指望AI哪些坑我替你踩过讲完流程和工具最后想聊聊AI编程的边界。网上有很多AI编程“无所不能”的宣传但真实工程里有些场景AI给不了你想要的效率甚至可能把你带进坑里。6.1 我遇到的幻觉与错误输出AI编程最常见的幻觉集中在三个地方。第一是API签名幻觉。AI经常根据训练数据里的旧版API生成调用代码但项目里的实际版本可能已经变了。解决方式是提示词里强制要求AI“先查看当前代码库里实际的函数定义再进行调用”并且让静态类型检查和编译来兜底。第二是依赖版本幻觉。AI会推荐一些它认为“很新”或“很流行”的依赖但实际项目可能已经锁定了版本甚至不方便新增依赖。我遇到过AI在提示词里已经写了“不要新增依赖”的情况下还是偷偷在import里引了一个未安装的包。所以每次Review时都要盯依赖变更。第三是算法细节幻觉。如果某个功能涉及精确的公式、协议或者业务规则AI生成的结果非常容易出错。比如财务计算、加密协议、特定行业的字段映射这些场景下AI更像是一个“编故事的人”而不是“按标准执行的人”。我的建议是凡是规则可以用用例明确表达的先用测试用例锁定行为再让AI写实现比让它直接从需求描述推导要可靠得多。6.2 PLC、FPGA等场景AI的辅助与禁区最近很多人讨论AI编程在PLC、FPGA这类工控和硬件场景的应用我也有关注。这类场景的特点是开发环境封闭、硬件资源受限、安全等级要求高、调试手段有限。AI在这些领域不是不能用但使用方式很讲究。以PLC编程为例AI可以做很多事情比如根据功能描述生成结构化文本ST程序框架、把一段梯形图逻辑翻译成ST语言、帮助理解现有程序块之间的调用关系、生成PLC程序模块的单元测试框架。这些辅助工作能提升初期的框架搭建效率。但要非常留意的禁区是涉及安全联锁、急停逻辑、设备保护相关的代码绝对不能让AI直接产出并投入使用。这类逻辑的安全性是靠严格的规范、仿真验证和现场测试来保证的AI生成的代码即使“看起来逻辑正确”也不能替代验证流程。FPGA类似寄存器级控制、时序约束这类高敏感代码AI更适合做“注释生成者”或“代码解释者”而不是“实现者”。在这个领域我强烈建议把AI定位成一个“熟悉文档和框架的助手”让它帮你写框架、写测试、写注释但把核心控制逻辑的决策权牢牢留在有经验的工程师手里。换句话说越是靠近物理世界的代码越要保守。6.3 团队引入AI编程时人该守住哪些责任最后说一点团队管理层面的体会。AI编程工具是生产力工具但团队的稳定交付最终还是靠人的决策。人在AI协作中的责任至少有三块一是负责需求拆解和验收标准这是AI无法替代的二是负责技术决策包括技术选型、架构设计、异常策略这些都和人相关三是负责对AI产出进行最终的判断AI可以给你一个“看起来正确”的方案但你是否能发现其中隐藏的边界问题决定这个方案能不能上线。我在团队里经常说一句话AI是很好的执行者但一定不是合格的质量负责人。质量负责人一定是人而且是知道为什么这么写、能说清楚取舍逻辑的人。V2.0流程运行到现在最大的变化是团队的“返工文化”变了。以前让AI写代码改代码的时间比写代码还长现在我们把更多时间花在需求澄清和上下文准备上AI的一次性通过率明显提升。省下来的时间没有用来摸鱼而是留给真正需要人去思考的问题产品逻辑是否合理架构是否支持未来扩展哪些技术债要还、哪些可以留。最后分享一个我沿用至今的小习惯每次AI完成一个子任务我都会让它顺带输出一份“变更说明”内容包括改了哪些文件、每个文件改了什么、存在哪些已知限制。这份说明我会直接贴到PR描述里。刚开始觉得多此一举后来发现它帮了大忙——一周后回头看代码时这份记录能快速还原当时的决策比翻垃圾的聊天记录高效太多。这一点建议你也试试。