1. 为什么“AI 编程完整工作流程”值得单独拎出来讲我大概是从前年开始把 AI 工具真正嵌进日常编码里的。最开始那半年说实话效率提升非常有限——不是 AI 不行是我用错了方式。那时候我的做法很原始遇到一个报错复制粘贴到对话框里问一句“这啥问题”得到一段解释再自己回去改。这种用法本质上只是把搜索引擎换了个壳根本没碰到“工作流程”这四个字。后来我慢慢意识到AI 编程的核心不是“问问题”而是“设计流程”。一个完整的 AI 编程工作流程应该覆盖从需求理解、方案设计、代码生成、调试排错、测试验证到文档沉淀的全链路而不是零散地在某个环节用一下。这也是我把这套东西整理成 v2.0 的原因——v1.0 是我自己摸索的零散技巧v2.0 是我在多个真实项目里跑通、踩坑、修正之后沉淀下来的稳定流程。这篇文章适合几类人看一是刚接触 AI 编程、还在“复制粘贴问问题”阶段的朋友二是已经用了一段时间但感觉效率提升不明显、想系统化的人三是团队里想把 AI 工具引入协作流程、但不知道怎么落地的技术负责人。我会把每个环节的为什么这么做、具体怎么做、容易踩什么坑都讲清楚你照着抄作业就行。需要先说明一点这套流程不绑定任何特定工具。市面上 AI 编程工具更新极快今天好用的明天可能就换了但流程本身是稳定的。你用什么模型、什么插件、什么 IDE都可以套进这个框架里。2. 整体流程设计与核心思路拆解2.1 从“单点提问”到“全链路流程”的思维转变大部分人用 AI 编程效率低根本原因在于把 AI 当成了一个“问答机器”而不是“协作伙伴”。问答机器是你问一句它答一句你得自己想清楚每一步该问什么协作伙伴是你给它足够的上下文它能帮你把一整段工作推进下去。我举个具体例子。假设你要写一个数据处理的脚本把一批 CSV 文件清洗后入库。单点提问的方式是先问“怎么读 CSV”再问“怎么处理空值”再问“怎么连数据库”每一步都要你自己串联。而流程化的方式是你先把需求、数据结构、目标库表、约束条件一次性交代清楚让 AI 给出一个完整的方案框架你再逐段审查和调整。这两种方式的效率差距在简单任务上可能不明显但在稍微复杂一点的任务上差距是数量级的。因为单点提问的瓶颈在你自己——你得知道下一步该问什么而流程化协作的瓶颈在审查——你只需要判断 AI 给的东西对不对。2.2 流程的六个核心阶段我把完整流程拆成六个阶段每个阶段有明确的输入、输出和验收标准阶段核心任务输入输出验收标准需求澄清把模糊需求变成明确规格一句话需求结构化需求文档能说清楚输入输出和边界方案设计确定技术选型和架构需求文档方案说明接口定义关键决策有理由代码生成分模块产出可运行代码方案接口代码文件能跑通基本路径调试排错定位并修复问题报错代码修复后的代码问题根因明确测试验证覆盖边界和异常代码需求测试用例结果边界情况有覆盖文档沉淀记录决策和用法全过程注释说明文档别人能看懂这六个阶段不是线性的实际工作中会来回跳。比如调试阶段发现方案有问题要回到方案设计测试阶段发现需求理解偏了要回到需求澄清。但每个阶段的存在是必要的跳过任何一个都会在后面付出代价。2.3 为什么强调“上下文工程”而不是“提示词技巧”网上讲 AI 编程的内容大部分在讲“提示词技巧”——什么角色扮演、什么思维链、什么少样本示例。这些有用但它们是战术层面的东西。真正决定 AI 编程效果的是战略层面的上下文工程。什么叫上下文工程简单说就是在正确的时间把正确的信息以正确的形式喂给 AI。这里面有三个关键点第一是信息完整性。AI 不知道你的项目背景、代码规范、历史决策你不说它就瞎猜。我见过太多人抱怨 AI 生成的代码“不符合项目风格”一问才知道他从来没告诉过 AI 项目用什么风格。第二是信息相关性。上下文不是越多越好。你把整个项目几万行代码全塞进去AI 反而抓不住重点。正确做法是只给当前任务相关的文件、接口、数据结构。第三是信息结构化。同样一段需求你用大白话描述和用结构化格式描述AI 的理解准确率差很多。我习惯用“背景-目标-约束-验收”四段式来描述需求后面会详细讲。2.4 工具选型的底层逻辑工具选型这块我不推荐具体产品因为更新太快但我可以给你一套选型逻辑你自己套看上下文窗口能塞多少代码进去直接决定你能做多复杂的任务。窗口小的工具只适合单文件小任务。看是否支持项目级索引能不能理解整个项目的结构而不是只看当前文件。这个能力对中大型项目是刚需。看是否支持多轮迭代能不能在对话中持续修改而不是每次都要重新描述需求。看是否可集成到现有工作流能不能在你常用的编辑器里直接用而不是切来切去。看数据安全策略代码是不是会被用于训练有没有本地部署选项。这个对企业项目是硬指标。我自己的做法是分层使用日常小任务用集成在编辑器里的轻量工具复杂重构用支持项目级理解的重型工具敏感代码用本地部署的方案。不要指望一个工具打天下。3. 核心细节解析与实操要点3.1 需求澄清阶段把“一句话”变成“可执行规格”这是整个流程里最容易被跳过、但最重要的一步。大部分人拿到需求就直接让 AI 写代码结果写出来的东西方向就偏了返工成本极高。我的做法是先自己把需求想清楚再让 AI 帮我补全盲区。具体分三步第一步用“背景-目标-约束-验收”四段式写出初版需求。比如“我要写一个日志分析脚本”这种一句话需求展开成背景服务器每天产生约 2GB 的 Nginx 访问日志需要统计 PV/UV 和 Top 10 接口目标输入日志文件路径输出统计结果到 CSV约束单机运行内存不超过 2GB处理时间不超过 5 分钟验收给定样例日志输出结果与手工统计一致第二步把这份初版需求丢给 AI让它反问我“基于这份需求你觉得还有哪些信息是缺失的”这一步非常关键AI 经常会问出我没想到的点比如“日志格式是否固定”“是否需要处理压缩文件”“时区怎么处理”。第三步根据 AI 的追问补全需求形成最终规格。这时候再进入方案设计阶段。注意这一步不要省。我统计过花 10 分钟做需求澄清平均能省下 1 小时以上的返工时间。尤其是涉及数据处理、接口对接这类任务需求模糊的代价极高。3.2 方案设计阶段让 AI 给方案但决策权在你需求清楚之后不要直接让 AI 写代码先让它给方案。我的提示词模板大概是这样的基于以下需求给出 2-3 个技术方案每个方案说明 1. 核心思路 2. 关键依赖 3. 优点和缺点 4. 适用场景 不要写代码只给方案对比。 需求[粘贴需求规格]为什么要 2-3 个方案因为 AI 给的第一个方案往往不是最优的多给几个能让你有对比。而且对比的过程本身就是你在学习——你能看到不同方案的取舍逻辑。拿到方案后你要做的是决策而不是让 AI 替你决策。决策依据包括团队技术栈熟悉度、维护成本、性能要求、依赖的稳定性。这些 AI 不知道只有你知道。决策完之后让 AI 把选定方案细化成接口定义。比如函数签名、输入输出格式、错误码。这一步是把方案变成“可编码规格”的关键。接口定清楚了后面生成代码就是水到渠成的事。3.3 代码生成阶段分模块、给示例、要注释代码生成阶段最容易犯的错是“一次性让 AI 写一大坨”。我的经验是分模块生成每个模块控制在 100-200 行以内。原因有两个一是 AI 在长代码里容易前后不一致二是短代码你审查起来快。生成每个模块时我会在提示词里带上三样东西接口定义这个模块的输入输出是什么代码风格示例从项目里挑一段风格标准的代码贴进去让 AI 照着写注释要求关键逻辑要有注释复杂算法要说明思路代码风格示例这一条特别重要。你不给示例AI 就按它的默认风格写可能是驼峰命名、可能是下划线命名可能用 tab 可能用空格。给了示例生成出来的代码基本能直接融入项目。实操心得我习惯在项目根目录放一个STYLE.md里面写清楚命名规范、注释规范、错误处理规范。每次让 AI 生成代码时把这个文件内容贴进提示词。这样生成的代码风格一致性非常高几乎不需要手动调整。3.4 调试排错阶段给足信息别只给报错调试是 AI 最能发挥价值的环节但很多人用不好。常见错误是只把报错信息贴过去问“怎么解决”。AI 只能瞎猜给出的方案经常不对症。正确的做法是给四样东西完整报错信息包括堆栈跟踪不要只给最后一行相关代码出错函数及其调用链不要只给一行运行环境语言版本、依赖版本、操作系统已尝试的方案你试过什么结果如何这四样给全AI 的定位准确率能到 80% 以上。如果还是不对再补充“这个报错在什么操作下触发”“之前是否正常”。还有一个技巧让 AI 先解释报错再给修复方案。因为有些报错是表象根因在别处。让 AI 解释一遍你能判断它是否真的理解了问题。3.5 测试验证阶段让 AI 帮你找边界测试这块AI 的价值在于穷举边界情况。人写测试容易漏因为人会下意识避开自己没想到的情况。AI 没有这个心理负担你让它列边界它能列出一堆。我的做法是把需求和代码一起给 AI让它输出测试用例清单包括正常路径、边界值、异常输入、并发场景。然后我从中挑选真正重要的让它生成测试代码。注意AI 生成的测试用例不能全信。它有时候会编造一些不存在的边界或者对业务逻辑理解有偏差。你要做的是审查用例的合理性而不是直接跑。3.6 文档沉淀阶段边做边记别事后补文档这块我的原则是边做边记。每个阶段结束时让 AI 把这一阶段的决策和产出整理成简短记录。比如方案设计阶段结束让它输出“方案决策记录”包含选了什么、为什么选、放弃了什么。这些记录积累起来就是项目的技术文档。事后补文档的痛苦相信大家都体验过——细节全忘了只能写些空话。边做边记文档是自然长出来的。4. 实操过程与核心环节实现4.1 一个完整案例从需求到交付的全流程我拿一个真实做过的小项目来演示一个把 Markdown 文件批量转成带样式的 HTML 的命令行工具。这个项目不大但六个阶段都能覆盖到。需求澄清阶段。原始需求是“把 md 转成 html”。我展开成四段式背景有一批技术文档是 Markdown 格式需要发布到内部网站网站只接受 HTML目标命令行工具输入目录输出同结构的 HTML 目录约束支持代码高亮、表格、图片相对路径转换单文件处理时间小于 1 秒验收给定 10 个样例 md 文件输出 HTML 在浏览器中渲染正确然后让 AI 反问它问出了几个我没想到的点图片路径怎么处理复制还是引用、是否需要生成目录、代码块语言标识缺失怎么办。补全后形成最终规格。方案设计阶段。让 AI 给方案它给了三个用现成的 markdown 库、自己写解析器、调用外部服务。我选了第一个理由是成熟稳定、依赖少。然后让它细化接口输入源目录路径、目标目录路径、配置对象 输出处理成功数、失败数、失败文件列表 错误码目录不存在、无写权限、文件解析失败代码生成阶段。分三个模块生成目录遍历模块、单文件转换模块、命令行入口模块。每个模块生成时都贴了项目的代码风格示例。生成出来的代码基本能直接用只改了几处细节。调试排错阶段。遇到一个问题是代码高亮库的版本冲突报错信息很长。我把完整堆栈、相关代码、依赖版本一起给 AI它定位到是某个间接依赖版本不兼容给出了锁定版本的方案。这个问题如果只贴最后一行报错AI 大概率会往错误方向猜。测试验证阶段。让 AI 列边界空目录、超大文件、特殊字符文件名、图片路径不存在、代码块语言未识别。挑了几个重要的生成测试代码跑下来发现图片路径不存在时程序会崩溃补了异常处理。文档沉淀阶段。每个阶段结束让 AI 整理记录最后拼成 README。整个过程下来文档是自然产出的没有额外花时间。4.2 关键参数的选择与计算过程在 AI 编程流程里有几个参数需要你根据实际情况计算和选择不能拍脑袋。上下文窗口的分配。假设你用的工具上下文窗口是 128K token你不能全用来塞代码。我的分配比例大概是系统提示和规范占 10%需求规格占 15%相关代码占 50%对话历史占 25%。代码部分要精选只放当前任务相关的文件。分模块的粒度。模块多大合适我的经验值是单个模块的代码量控制在 AI 上下文窗口的 5%-10%。比如 128K 窗口单模块代码控制在 6K-12K token大概 200-400 行。这个粒度下AI 能保持前后一致你审查起来也不累。迭代轮次的控制。同一个问题如果 AI 连续三轮都没解决不要再继续问。停下来重新组织上下文或者换个思路。我踩过的坑是一个问题问了七八轮越问越乱最后发现是初始上下文给错了。三轮不解决就重置这是我的硬规则。4.3 实操现场一次真实的调试记录我记录一次真实的调试过程让你感受一下流程怎么跑。问题是一个 Python 脚本在处理大文件时内存溢出。我按四样信息组织报错MemoryError堆栈指向readlines()调用代码读取文件后逐行处理但用了readlines()一次性读入环境Python 3.10文件约 3GB机器内存 8GB已尝试调大内存限制无效AI 的解释是readlines()会把整个文件读进内存3GB 文件加上处理开销超过 8GB。修复方案是改成逐行迭代for line in file内存占用降到常数级。这个案例说明一个点报错信息要包含触发位置。如果我只贴MemoryErrorAI 可能猜是数据结构问题、递归问题、缓存问题方向就偏了。给了堆栈直接定位到readlines()。4.4 流程落地的检查清单每次启动一个新任务我会过一遍这个清单[ ] 需求是否展开成四段式是否有验收标准[ ] 是否让 AI 反问过盲区[ ] 是否对比过至少两个方案[ ] 接口定义是否明确到可以直接编码[ ] 代码风格示例是否已准备[ ] 模块粒度是否控制在 200-400 行[ ] 调试时是否给全四样信息[ ] 测试是否覆盖了边界和异常[ ] 每个阶段的决策是否已记录这个清单看起来繁琐但跑熟之后就是肌肉记忆每个任务多花几分钟省下的是几小时的返工。5. 常见问题与排查技巧实录5.1 AI 生成的代码“看起来对但跑不通”怎么办这是最高频的问题。原因通常是上下文缺失或版本不匹配。排查顺序第一检查依赖版本。AI 的训练数据有时间截止点它可能用了新版本才有的 API或者用了已废弃的写法。让它明确说明“这段代码依赖哪个版本”。第二检查隐式假设。AI 可能假设了某个全局变量存在、某个配置已加载、某个文件已创建。让它列出“这段代码运行前需要满足哪些前提”。第三检查边界条件。AI 生成的代码经常在正常路径下没问题一到边界就崩。让它自己列出“这段代码在什么情况下会失败”。5.2 AI 反复给错误方案怎么破连续三轮不对立刻停。我的处理流程是重新组织上下文把之前没给的信息补上换一个角度描述问题比如从“怎么实现”换成“为什么现在的实现不行”如果还不行让 AI 列出“所有可能的失败原因”你逐个排除最后手段自己先写一个最小可复现示例再让 AI 基于示例分析实操心得AI 反复给错方案90% 的情况是上下文有问题不是 AI 能力问题。与其在对话里反复纠正不如退出来重新组织输入。5.3 常见问题速查表问题现象可能原因排查方向解决技巧代码风格不一致未提供风格示例检查提示词是否含风格参考项目根目录放 STYLE.md生成的代码跑不通依赖版本不匹配确认语言和库版本让 AI 明确标注版本要求方案方向偏了需求描述模糊回看四段式需求让 AI 反问补全盲区调试越调越乱上下文过载检查对话轮次三轮不解决就重置测试覆盖不全未列边界清单让 AI 穷举边界人工审查用例合理性文档写不出来未边做边记检查阶段记录每阶段结束让 AI 整理5.4 几个我踩过的坑坑一过度信任 AI 的自信语气。AI 说“这样写肯定没问题”的时候往往就是有问题的时候。它的自信和正确率没有相关性。我的做法是不管它多自信关键代码必须自己跑一遍。坑二把 AI 当搜索引擎用。早期我遇到问题就问 AI得到答案就用从不深究。后来发现同样的问题换个场景又不会了。现在我要求 AI 解释“为什么这样解决”理解了原理才能举一反三。坑三忽略 AI 的“幻觉依赖”。AI 有时候会引用一些不存在的库、函数、参数。它说得头头是道你一查文档发现根本没这东西。所以任何 AI 提到的 API用之前必须查官方文档确认。坑四上下文给太多。有段时间我追求“信息完整”把整个项目代码都塞进去结果 AI 反而抓不住重点生成的代码引用了不相关的模块。后来学会只给相关文件效果反而更好。坑五不做版本控制。AI 生成的代码改动大如果不做版本控制改错了想回退都难。我的习惯是每次让 AI 大改之前先提交一次。这样出问题可以随时回退。5.5 提升效果的两个进阶技巧技巧一让 AI 扮演审查者。代码生成完之后新开一个对话把代码贴进去让它以“严格的代码审查者”身份挑毛病。这个视角切换能发现很多生成时忽略的问题。技巧二建立个人提示词库。把常用的提示词模板需求澄清、方案对比、代码生成、调试排错整理成文件每次用的时候直接调用。这样既省时间又保证质量稳定。我现在的提示词库有二十多个模板覆盖了大部分日常场景。6. 流程的扩展与个人体会6.1 从个人流程到团队协作这套流程在个人用没问题但团队协作需要额外考虑几点。一是提示词和规范的共享团队要有统一的 STYLE.md 和提示词模板否则每个人生成的代码风格各异。二是决策记录的归档AI 参与的决策要记录在案方便追溯。三是代码审查的加强AI 生成的代码审查要更严格重点看逻辑正确性和边界处理。我们团队现在的做法是每个项目建一个ai-decisions目录记录所有 AI 参与的关键决策和方案对比。新人接手时看这个目录就能理解项目的来龙去脉。6.2 流程会变但原则不变AI 工具半年一小变、一年一大变今天这套流程里的具体操作明年可能就过时了。但有几个原则是稳定的上下文比提示词重要、审查比生成重要、流程比工具重要。抓住这几个原则工具怎么变你都能快速适应。6.3 我个人的一点体会用 AI 编程这两年我最大的感受是AI 放大了你的能力也放大了你的问题。你思路清晰它让你快十倍你思路混乱它让你乱十倍。所以与其花时间研究“怎么让 AI 更聪明”不如花时间研究“怎么让自己想得更清楚”。这套 v2.0 流程本质上不是教你怎么用 AI而是教你怎么把工作拆解成 AI 能接住的粒度。拆解能力才是核心AI 只是执行者。你把需求想清楚、把接口定明白、把边界列完整AI 自然能帮你把活干漂亮。最后分享一个小习惯我每天结束工作前会花五分钟让 AI 把当天的关键决策和踩坑记录整理成一段话存进项目笔记。这个习惯坚持了半年现在我的项目笔记已经成了团队里最受欢迎的资料。文档这东西边做边记不累事后补才要命。