我大概是去年年初才开始系统性把 AI 编程塞进日常开发流程里的当时也就是拿 Copilot 补全代码、偷懒写点正则。但用着用着发现一个问题AI 单点辅助和 AI 贯穿整个开发流程效率差距不是一倍两倍而是完全不同的两种工作方式。后来我把自己踩坑总结出来的这套东西整理成了“AI 编程完整工作流程”现在迭代到了 v2.0。这篇文章就是把 v2.0 从头到尾拆开讲一遍包括工具选型、需求拆解、提示词怎么写、代码怎么审查、报错怎么排查还有一些文档里根本不会写的隐性成本。适合那些已经在用 AI 写代码但总觉得“差点意思”的开发者也适合刚准备入坑、想一步到位搭好流程的新手。1. 准备工作先把流程跑通的三个前提1.1 工具不是越多越好先定一条主线现在 AI 编程工具多得有点眼花缭乱界面长得都差不多功能听起来也都差不多。我身边不少朋友是“全家桶用户”编辑器里装三个补全插件命令行再挂两个 Agent浏览器里还开着一个对话网页。结果真正写代码的时候光切换工具就耗掉一半注意力。我的建议是先明确自己的开发主线然后只留一条 AI 链路。如果你主力在 VS Code 或 JetBrains 系那就以编辑器内嵌的 AI 为主对话页面作为补充如果你习惯命令行工作流那可以用终端里的 Agent 工具处理跨文件重构、批量修改这类脏活。我用下来比较顺手的一套组合是场景工具定位我的常用选择编辑器内补全写代码时的即时建议处理样板代码、重复逻辑Cursor 或 Copilot对话式需求拆解讨论方案、生成提示词、解释报错、写测试用例网页版对话模型Agent 自动化跨文件重构、批量修改、跑测试并自动修复支持终端操作的 Agent 类工具代码审查辅助静态检查、安全隐患、边界条件提醒集成在 CI 里的 AI 审查注意这里强调的是“一条主线”不是“只用一个工具”。AI 编程工具各有各的长处但没必要在同一个环节叠三四个。主线确定之后其他工具全是支线需要的时候再调出来。1.2 把仓库变成 AI 的“工作上下文”AI 对话模型有个通病你给它一段零散的代码它只能基于这段代码猜上下文。如果猜错了方向后面所有生成结果都会跑偏。这个问题的解法不是靠模型进步而是靠你把项目背景主动喂给它。我在每个项目根目录下都会维护一个AGENTS.md文件有些工具叫CLAUDE.md有些叫项目规则文件本质一样。里面写清楚几件事项目技术栈和版本比如“React 18 TypeScript 5 Vite后端是 Node.js 22 Express”。目录结构说明不是简单列目录而是讲清楚“src/components放通用组件src/services放 API 调用业务页面在src/pages”。代码风格约定命名规范、组件写法、状态管理方式、错误处理习惯。常用命令启动、测试、构建、lint 分别是哪几条命令。这个文件写完之后每次让 AI 干活时我在提示词里加一句“先读项目根目录的 AGENTS.md然后基于里面的规范完成任务”。AI 的输出质量会有肉眼可见的提升因为它不再是在“盲猜”你的项目了。1.3 给 AI 一个“可控的执行环境”很多人让 AI 改代码的场景是这样的直接在对话里丢一句“帮我改一下登录逻辑”AI 哗啦给出一大段代码你复制粘贴替换掉原有函数一编译炸了——因为它没看到你接口返回的字段格式是{ code, data, message }而不是{ code, data }。这类问题的根源是你没有给 AI 一个可控的执行环境。所谓可控指的是三件事版本控制前提下操作所有 AI 生成的代码先进分支不要直接在主干上改。至少你随时能git diff看它动了什么能git checkout回滚。明确改动范围提示词里写清楚“只改src/utils/format.ts文件里的formatTime函数其他文件不要动”。AI 默认倾向于多做一点尤其是 Agent 类工具喜欢顺手帮你“优化”别的文件。限制范围能省掉大量 review 成本。提供验证手段告诉 AI 项目怎么跑测试、怎么 lint让它完成改动后自己跑一遍验证。这三点是后续所有流程的地基。地基没打牢后面提示词写得再漂亮也没用。2. 需求拆解提示词前必须完成的功课2.1 用最短时间把需求翻译成“任务清单”我见过最多的 AI 编程翻车现场不是因为 AI 弱而是因为需求本身是模糊的。举个例子你让 AI“加一个登录页”这个需求听起来很明确对吧但仔细想里面有大量未定义的东西登录方式是什么账号密码还是手机验证码登录成功后跳哪里错误提示怎么展示有没有第三方登录这些问题如果不在写提示词之前想清楚AI 就会自由发挥然后你就要在 review 时花十倍时间打补丁。我自己的习惯是接一个需求后先花五到十分钟把需求拆成“可验证的任务清单”。拆法不是靠拍脑袋而是问自己三个问题这个功能的使用者是“谁”是普通用户还是管理员决策逻辑是否涉及角色区分正常情况下操作路径是怎样的从入口到完成经过哪些页面和接口异常情况下怎么处理比如网络超时、接口报错、权限不足、输入不合法各是什么表现把这三个问题的答案写下来需求就从一句话变成了一份任务清单。这时候你再把任务清单交给 AI它产出的代码天然就是可验收的。顺便说一句这份任务清单同时也是你后续写测试用例的素材一鱼两吃。2.2 提示词模板我实测下来最稳的三段式网上关于提示词技巧的文章很多什么角色扮演、思维链、反面提示花样不少。但落到编程场景我试下来最稳定的是三段式结构上下文 任务 约束。缺一段结果都会跑偏。下面这个模板是我现在每天都在用的直接抄作业就行我在维护一个 [技术栈描述] 项目项目规范见根目录 AGENTS.md。 任务 实现“用户登录功能”具体需求 1. 登录方式手机号 密码密码使用 MD5 加盐存储注意仅演示用生产环境建议改用 bcrypt 2. 登录成功后跳转到首页并在顶部导航栏显示用户名 3. 登录失败时在表单下方显示后端返回的错误信息 4. 前端使用 Element Plus 表单组件后端接口是 POST /api/login请求参数格式为 { phone, password }响应格式为 { code, data, message }code 为 0 表示成功 约束 1. 只修改 src/pages/Login.vue 和 src/api/auth.ts 这两个文件 2. 不要改后端代码 3. 完成后运行 npm run lint 确保通过 4. 如果某个接口参数不确定先说明你的疑问不要假设留意这段提示词的几个细节第一上下文部分明确指定了要读项目规范第二任务部分每一项都是可验证的——登录方式、跳转逻辑、错误处理、接口细节全部定义清楚第三约束部分用“只修改”“不要”这种强限定词锁定了改动范围。这三段缺一不可。2.3 上下文怎么喂喂多少给 AI 喂代码上下文最怕两个极端一个是不给AI 凭空发挥另一个是给太多一段几千行的文件整个贴进对话AI 的处理能力反而被冗余信息拖垮。我自己的参考标准是这样的改单个函数贴出函数所在的整个文件就够了但前提是文件不要超过两三百行。如果文件特别长先手动截取函数定义附近的前后几十行再补充依赖的接口定义。跨文件改动不要贴所有文件而是先在提示词里说明“我给你列一下关键文件的路径和职责需要看具体内容时我再贴给你”。Agent 类工具可以直接告诉它去读哪些文件对话式模型就需要手动分步投喂。报错信息贴完整的堆栈信息通常几行到几十行反而比贴代码更有效。AI 能从堆栈里定位到出错位置和调用链。需求上游信息比如接口文档、设计稿描述能说清楚就提前说清楚。不要等到 AI 生成了错误方案再纠正那等于多走一轮完整返工。还有个很多人都不知道的技巧AI 的工作记忆是有限的不要在一轮对话里塞进去几十个需求点。宁可把一个大任务拆成三五个子任务分轮对话去完成每一轮只聚焦一件事。这样不仅每个步骤的输出质量更高而且出问题时你能精确知道是哪一个环节跑偏了。3. 实操过程从 0 到 1 跑完一个功能模块3.1 起步让 AI 先出“方案草稿”而不是直接写码刚用 AI 编程的人最容易犯的错是上来就甩一句“帮我写一个 xxx”AI 也真就哗啦啦生成几百行。但大概率不符合预期然后开始来回打补丁一轮、两轮、三轮最后你对 AI 的信任度直接清零。我的做法是反过来的第一个提示词永远不要求写代码只要求出方案。比如上面那个登录功能我会先发不想直接写代码先告诉我实现“手机号 密码登录”的最优方案。从这几个角度说明 1. 前后端交互的数据格式设计 2. 前端表单校验逻辑放在哪层 3. 登录成功后的状态管理和路由跳转怎么组织 4. 这个功能可能涉及的安全风险点比如密码传输、暴力破解为什么先要方案因为代码是方案的具象表达。方案本身错了代码再怎么修都是错的。而让 AI 先出方案你有机会在“成本最低”的阶段纠正方向——这时候你只是读了几百字描述还没看到几百行代码。而且 AI 的方案里经常能给出的额外收获是“安全风险点”这类你没主动问但确实重要的提醒。拿到方案后你逐条确认、修正最后再追加一句“按我们讨论的方案开始写代码”。这时候 AI 的输出就是建立在对齐共识之上的返工概率大幅下降。整套过程花了不到五分钟但省下来的排查时间可能是半小时起步。3.2 增量实现一次只改一件事方案确认后进入编码阶段这个阶段最重要的原则是一次只改一件事。举个例子你要实现“用户列表”页面里面包括表格展示、搜索筛选、分页、新增用户弹窗。如果一个提示词全塞给 AI它的注意力会被分散东错一块西错一块。我的做法是拆成四轮第一轮搭建组件骨架和表格展示后端接口只联通用的列表查询。第二轮加搜索筛选逻辑改接口参数和表格数据刷新。第三轮实现分页处理页码切换时的数据请求和 loading 状态。第四轮做新增用户弹窗包括表单校验和提交逻辑。每一轮之间的衔接靠上下文也就是把上一轮生成的代码反馈给 AI然后说“在此基础上继续加 xx”。这样做的另一个好处是每一轮结束后你都可以做一次 review如果第三轮出了问题你只需要回滚到第二轮的状态而不会把整个页面的代码全部打回重来。这里还有个小细节每一轮完成后我都会要求 AI“用一句话说明这个改动会影响哪些现有功能”。这个要求迫使 AI 主动检查改动的影响面。很多问题就是在这一步被提前发现的比如增量改动误伤了其他复用组件、改了公共函数却没检查调用方。3.3 代码审查AI 写完不代表完事AI 生成的代码能不能直接上线我的答案是看场景。但有一个底线原则——AI 写的代码必须经过和你自己写的代码同等标准的审查。AI 不是免检通道它只是一个生成速度极快的“实习生”而且这个实习生有时候会自信地给出完全错误的实现。我审查 AI 代码时有一套自己的清单分享出来边界条件数组为空、对象为 undefined、字符串超长、数字为零这些情况处理了吗异常处理接口报错、网络超时、用户取消操作有没有兜底逻辑安全合规有没有把用户输入直接拼进 SQL 或 HTML有没有在前端暴露密钥性能隐患有没有在循环里发请求有没有不必要的全表渲染样式约定代码风格是否跟项目一致组件拆分粒度是否合理别过度设计AI 特别喜欢顺手引入设计模式、工具函数、类型抽象。能用十行写清楚的它可能给你抽象出三个文件。有一次我让 AI 实现一个“导出 Excel”的功能它生成的代码拿出来的结果是完全正确的。但审查的时候我发现它把整个第三方库的完整对象都引入进来了打包体积直接增加了两百多 KB。功能是好的但代价不合理。这种问题不靠审查环节根本发现不了。3.4 调试与测试利用 AI 反向生成测试代码写完了、审查过了接下来是调试和测试环节。这个环节 AI 的效率优势同样明显但用法和写业务代码时不太一样。先说调试。以前遇到底层报错我的路径是看堆栈、猜原因、加日志、重启、再看堆栈。现在我用一套更快的路径把完整报错信息 相关代码片段 我已经尝试过的排查手段一起丢给 AI然后问“根据这些信息最可能的三个原因是什么按可能性排序”。AI 会给出一个概率排序的排查清单我从第一个开始验证。这套方法特别适合那些“看起来玄学”的问题——比如某个组件只在生产环境渲染异常、某个接口在特定机型的浏览器上才报错。AI 凭借训练时见过的大量相似案例给出的方向往往比我闷头查一个小时还要快。再说测试。让 AI 帮你写测试用例不是让它简单炫技而是有实际价值的因为它熟知你刚让它实现的逻辑写起单测来上下文几乎是零成本。但注意别让 AI 给你写出“为了测试而测试”的垃圾用例。重要的做法是告诉它“针对这个函数列出你认为最关键的五组边界测试数据并说明为什么这五组值得测”。它会说出一番道理你再决定接受还是调整。有了这层讨论测试的有效性远高于直接让 AI “generate tests”。4. 常见问题与排查技巧实录4.1 五大高频翻车现场这是我用 AI 编程半年多以来遇到最多的五类问题几乎占了失败案例的九成。整理成一张速查表遇事可以对着看症状根本原因解决办法AI 生成的代码引用了不存在的 API模型幻觉基于相似语法自动补全要求 AI 先列出将使用的 API 及出处再用grep验证改 A 功能 B 功能跟着崩AI 在实现时不自觉修改了周边代码明确限定“只改指定文件/函数”启用 git diff 审查改动面提示词里写了需求但生成结果丢三落四需求点太多AI 注意力分散拆分成子任务一次只聚焦一个需求点AI 在循环里发请求接口被打挂AI 没意识到异步操作的代价审查时专门检查网络请求的位置要求 AI 写出请求触发时机和频率对话超过若干轮后 AI 开始“失忆”上下文窗口被压缩早期信息被截断换新对话把关键需求和已定方案重新精简投喂一次这张表里的每一条我都在真实项目里吃过亏。尤其是第一条AI 幻觉 API初看无所谓因为编译时代理会报错但如果你用的是动态语言或者配置类代码它会在运行时才炸出来。4.2 怎么判断 AI“编”了一个不存在的 API这一节单独拿出来写是因为它太隐蔽了。AI 生成代码时有时会非常自然地写出来一个“看起来合理”但实际不存在的库函数或配置项。比如我之前让 AI 帮我写一个 Node.js 的文件上传处理它给我用了一个upload.verify()方法。我第一眼觉得没问题翻库文档才发现根本没这个方法它把另一个库的心智模型嫁接过来了。排查此类问题的办法是稳准狠的“三步验证法”命令验证对于后端 API直接在命令行里执行grep -r function verify node_modules/xxx/或grep -r verify node_modules/xxx/看是否存在。文档验证对于不熟悉的库让 AI 先给出“这个方法来自哪个库的哪个版本”然后自己翻一下官方文档确认。运行时验证最保险的方式写一行最小调用代码实际跑一遍。尤其在 TypeScript 项目里如果类型定义和实际实现不一致即使编译过也可能在运行时掉链子。这个习惯养成之后AI 生成的代码里引用新 API 时我会本能地去确认它的存在。这不是不信任 AI而是对生产代码负责。4.3 提示词反复无效时换一种问法有时候同一个需求换了好几种提示词AI 的回复就是不合预期。这时候很多人会来回来去微调措辞但效果不大。我的经验是当提示词在“同一个思维框架下”反复调整无效时赶紧换框架。具体的换法有几种从“告诉我怎么做”换成“给我几个可选方案并分别列出优缺点”。这两种问法让 AI 输出的信息组织方式完全不同。从“实现这个功能”换成“告诉我实现这个功能时最容易犯的错误是什么”。AI 会退一步审视野代码给出的答案可能直接帮你避雷。从“写代码”换成“先口头描述这个功能的关键逻辑用伪代码写”。半代码的描述方式能让 AI 更专注在算法流程上少去管语法细节。有一次我要实现一个“多条件组合筛选”功能直接让 AI 写代码它给出来的方案不是循环嵌套就是重写一堆判断逻辑怎么调都不合适。后来我换了个问法“这个场景下筛选条件的组合爆炸问题业界常用的几种方案是什么”它立刻给出了动态查询构建器、索引映射、规则引擎等好几种思路我选了最适合项目体量的一种再让它基于这个方向写代码一次通过。5. 隐性成本与自我成长AI 编程真正的门槛5.1 别让 AI 替你背锅也要防止“过度重构”AI 编程最大的隐性成本不是工具订阅费而是责任转移的幻觉。有些开发者让 AI 写完代码往上一挂出 bug 了跟团队说“AI 写的”。我在团队里对这种行为很警惕。AI 只是一个输出工具验收权在你手上。你真的阅读过、理解过、验证过这段代码它才算“你写的”没有这步它只是“你提交的”。反过来还有一类问题叫“过度重构”。我见过不少开发者本来能跑的代码因为觉得“AI 能优化”就让 AI 重构一把结果引入一堆抽象层、设计模式和提前优化代码变得复杂难读。我的原则是线上跑得好好的代码没有度量数据支撑不要为了“让 AI 优化”而优化。重构的前提是有明确的痛点性能、可维护性、扩展性和可验证的改进指标。否则AI 这个实习生很容易把一栋安全的老房子重建成一栋现代主义危楼。5.2 把 AI 对话沉淀成自己的“小抄库”我现在除了代码仓库之外还维护了一个“提示词小抄库”。每次我在 AI 对话中得到一份特别好的回复、一套特别顺的提示词结构我都会摘录下来按场景分类存起来。这个小抄库不是给别人用的是给我自己积累的可复用资产。因为 AI 编程的场景高度重复——写接口、调字段、查报错、写测试、做代码审查——同样的提示词模板可以反复套用。而且慢慢你会发现你记录下来的不只是提示词还有你对这个项目的理解、对技术方案的取舍记录。这些笔记既是 AI 编程的工作流产物也是你自己的知识资产。我建议至少每周花十分钟回看一下这一周跟 AI 的对话记录把有价值的部分沉淀下来。长期积累下来你的成长曲线会比单纯埋头写代码快得多。5.3 什么时候不用 AIAI 编程流程跑通之后反而要清醒地认识到它不是所有场景都适用。我从实战中总结了几类不要用 AI 的场景架构级决策系统拆分、技术栈选型、数据模型设计这类决策靠的是对业务深度理解和对长期演进的判断AI 可以当讨论对象但不能当决策者。性能瓶颈优化AI 的优化建议往往是“看起来更高效”的写法但真正定位性能问题需要的是 profiling 工具和数据支撑。盲从 AI 的优化建议可能把热点问题修到没热点的位置。安全敏感改动涉及鉴权、脱敏、加密、支付等安全核心逻辑的改动我会保持手写和逐行审查不用 AI 自动生成。安全是信任问题不能外包。你不懂的业务领域如果某个需求背后的业务逻辑你自己都没理解AI 生成的代码大概率是合理但错误的。先搞懂业务再让 AI 提速。这套“什么时候不用 AI”的判断和“什么时候用 AI”同样重要。它会决定你在长期职业发展里是成为“会工具的工程师”还是“被工具替代的工程师”。我个人倾向于把 AI 当作一个超级实习生能独立完成大部分执行任务但你才是那个需要做判断、做取舍、做定海神针的人。最后再说一个实操里的小经验把流程跑顺之后别再频繁更换工具链。AI 编程领域每个月都在出新工具稳定下来用熟一套流程比什么都追要强得多。我 v2.0 这套东西用到现在核心环节没有大改过只是不断在提示词模板和审查清单里加新的案例。流程是你和 AI 之间的默契默契需要时间磨合。给彼此一点时间你会发现 AI 编程的产出量不只是“写代码变快了”而是整个需求的交付过程都变了——从一个人对着需求死磕变成一个带着高效助手快速推进项目的团队。