AI 编程工具这两年迭代得飞快但真正拉开效率差距的往往不是模型本身而是你有没有一套固定的工作流。我见过太多人把 AI 当搜索引擎用问一句答一句结果一天下来代码没写几行聊天记录倒是攒了几百条。也见过一些老手同样是用 AI人家一天能顶三天区别就在于他们把重复动作固化成了流程。这篇要聊的 3 个工作流就是我自己在真实项目里反复打磨、现在几乎每天都在用的东西。它们分别解决三类高频场景读陌生代码、写新功能、改遗留 bug。每个工作流都能直接抄作业不需要额外装什么重型工具一个编辑器加一个对话窗口就能跑起来。先说清楚适用人群如果你已经会用 AI 补全代码但总觉得差点意思产出质量忽高忽低那这篇对你最有用。如果你是完全新手也能看懂因为我会把每一步为什么这么做讲透。全文不涉及任何特定平台绑定思路是通用的你换成自己顺手的工具照样成立。1. 为什么随手问 AI永远做不成稳定产出1.1 单轮对话的致命缺陷上下文是碎的大部分人用 AI 编程的默认姿势是遇到问题打开对话框描述一下等答案复制粘贴跑不通再追问。这个模式在简单场景下没问题比如写个 Python 函数求长方体体积这种一轮就能搞定。但一旦进入真实项目问题就来了。真实项目里的任务几乎都不是孤立的。你要改一个函数得知道它被谁调用、依赖哪些模块、有没有隐藏的副作用。这些信息散落在几十个文件里而你单轮对话时只丢了其中一小块给 AI它只能基于这一小块猜。猜对了是运气猜错了你还得来回解释解释的过程又消耗你的注意力。我统计过自己早期的使用记录平均一个稍复杂的改动要来回七八轮其中至少三轮是在补上下文而不是在解决问题。更麻烦的是单轮对话没有记忆沉淀。今天你教会了 AI 这个项目的命名规范明天开新对话它又忘了。你等于每天都在重复做同样的入职培训这本身就是巨大的浪费。1.2 工作流的本质把补上下文这件事前置并标准化工作流要解决的核心问题就是把那些你每次都要重复解释的东西提前准备好、结构化让 AI 一上来就拿到完整信息。这跟带新人的逻辑一模一样你不会让新人直接上手改核心代码而是先给他一份项目说明、一份代码规范、一份架构图然后再派活。我后来想明白一个道理AI 的能力上限其实很高真正拖后腿的是你喂给它的信息质量。同样一个模型你给它一段孤立的代码和给它这段代码 调用链 相关测试 项目规范产出的质量能差出一个数量级。工作流的价值就是保证每次喂进去的信息都是高质量的、结构化的、可复用的。1.3 三个工作流分别对应哪三类高频场景我把自己日常的 AI 编程任务归了归类发现 80% 的时间花在三件事上场景典型任务痛点对应工作流读代码接手陌生模块、排查调用关系信息量大人工读太慢工作流一结构化代码导读写功能新增接口、补测试、写工具函数产出不稳定风格不统一工作流二约束式生成改 bug定位问题、修复、验证容易改出新问题工作流三闭环修复这三个工作流不是孤立的实际用的时候经常串起来。比如接手一个陌生模块先用工作流一读懂再用工作流二加功能最后用工作流三修 bug。下面逐个拆。2. 工作流一结构化代码导读把陌生模块读成一张地图2.1 先别急着让 AI 解释代码先让它画结构新手拿到陌生代码第一反应往往是选中一段问这段代码什么意思。这个做法效率极低因为代码的含义高度依赖它在整体中的位置。正确的第一步是让 AI 帮你梳理结构而不是解释细节。我的做法是把模块的目录结构、入口文件、核心类/函数的签名先丢给 AI让它输出一张地图。具体来说我会准备三样东西目录树用tree命令或编辑器的文件列表导出入口文件内容通常是 main、index、app 这类核心接口的签名列表函数名、参数、返回值不用函数体然后给 AI 的指令是这样的这是一个项目的目录结构和入口文件。请帮我梳理 1. 这个模块的核心职责是什么 2. 主要的调用链路是怎样的从入口到核心逻辑 3. 哪些文件是核心哪些是辅助 4. 如果我要改某个功能最可能涉及哪几个文件 不要解释具体代码实现只讲结构和关系。这个指令的关键在于最后一句不要解释具体代码实现。不加这句AI 很容易一头扎进细节给你讲一堆语法。加了这句它会聚焦在结构上产出的是你真正需要的全局视角。2.2 用提问链逐层下钻而不是一次性问完拿到结构地图后不要指望 AI 一次就把所有细节讲清楚。我的经验是逐层下钻每一层只问一个问题而且后一个问题基于前一个的答案来问。这样做的原因是AI 的上下文窗口有限一次性塞太多细节反而会稀释重点。一个典型的提问链是这样的第一层这个模块的核心职责是什么拿到全局定位第二层从入口到核心逻辑调用链经过哪几个关键函数拿到主干第三层这个关键函数processOrder的输入输出分别是什么有哪些边界情况拿到细节第四层如果我要在这个函数里加一个校验应该加在哪一步会不会影响其他调用方拿到改动影响面每一层的问题都建立在上一个答案的基础上这样 AI 始终在正确的上下文里工作。实测下来四层提问基本能把一个中等复杂度的模块摸清楚比人工读代码快三到五倍。2.3 让 AI 输出改动影响面清单这是最值钱的一步读代码的最终目的通常是为了改代码。所以在导读的最后我一定会让 AI 输出一份改动影响面清单。指令大概是这样假设我要修改 [某个函数/某个行为]请列出 1. 直接调用这个函数的地方有哪些 2. 间接依赖这个行为的地方有哪些 3. 有没有测试覆盖这些调用点 4. 修改后最可能出问题的地方是哪里这份清单的价值在于它把改代码这件事从凭感觉变成了有依据。我踩过太多次坑改了一个看起来无关紧要的函数结果某个角落的定时任务挂了。后来养成习惯每次改动前先让 AI 列影响面虽然不能保证 100% 覆盖但能挡掉大部分低级失误。提示让 AI 列影响面时一定要把相关的调用文件内容也喂给它否则它只能靠猜。如果项目大至少把直接调用方的文件给它。2.4 导读工作流的实操心得这个工作流我用了大半年有几个心得值得分享。第一目录树不要给全量。大项目的目录树动辄几千行全丢给 AI 是浪费。我的做法是只给到核心模块的两到三层辅助目录直接折叠。AI 需要的是结构感不是完整性。第二接口签名比函数体更重要。很多人喜欢把整个文件丢给 AI其实函数体里大量是实现细节对理解结构帮助不大反而占上下文。只给签名AI 反而能更快抓住重点。第三导读结果要落盘。我会把 AI 输出的结构地图和影响面清单存成一个 markdown 文件放在项目根目录。下次再问相关问题直接把这个文件一起喂进去省得重新梳理。这个习惯让我的上下文准备时间从每次十几分钟降到了两三分钟。3. 工作流二约束式生成让 AI 写出的代码能直接用3.1 为什么 AI 写的代码总是差一点用 AI 生成代码最常见的抱怨是能跑但不能用。具体表现是命名风格跟项目不一致、错误处理方式不对、日志格式不统一、没有按项目的分层规范来。这些问题不是 AI 能力不行而是你没告诉它项目的规矩。我早期也吃过这个亏。让 AI 写一个接口它给我返回了一个能跑的版本但错误处理用的是抛异常而我们项目统一用返回错误码。结果我还得手动改一遍改的时间比自己写还长。后来我意识到问题出在我把 AI 当成了代码生成器而不是需要入职培训的新同事。3.2 准备一份项目约束卡一次准备长期复用解决思路很简单把项目的编码规范、命名习惯、错误处理方式、日志格式这些约束整理成一份文档每次生成代码前先喂给 AI。我管它叫项目约束卡。一份合格的约束卡大概包含这些内容命名规范类名、函数名、变量名、常量的命名风格错误处理用异常还是错误码错误信息怎么组织日志规范用什么日志库日志级别怎么分关键节点打什么日志分层规范controller/service/dao 各层职责不允许跨层调用依赖规范哪些工具库是项目允许的哪些禁止引入测试规范单测框架、断言风格、mock 方式这份卡不用写得多漂亮关键是准确。我自己的约束卡就一页 markdown但每次生成代码前都会带上产出质量立刻不一样。3.3 生成指令的黄金结构角色 约束 输入 输出格式有了约束卡接下来是生成指令的写法。我总结了一个黄金结构四段式【角色】你是一个熟悉 [项目技术栈] 的资深工程师。 【约束】严格遵守以下项目规范[粘贴约束卡] 【输入】现有代码/接口定义/数据结构[粘贴相关内容] 【输出】请生成 [具体功能]要求 - 只输出代码不要解释 - 包含必要的错误处理和日志 - 如果涉及数据库操作用项目现有的 DAO 层这个结构的关键在于输出格式那一段。明确告诉 AI 你要什么、不要什么能省掉大量来回。比如只输出代码不要解释这一句能让你直接复制粘贴不用手动删掉一堆废话。3.4 一个真实例子给订单模块加一个取消接口拿一个具体例子走一遍。假设我要给订单模块加一个取消订单的接口项目是 Java Spring Boot约束卡里写了错误处理用统一返回体、日志用 slf4j、DAO 层已经封装好。我的指令是这样组织的【角色】你是一个熟悉 Spring Boot 的资深后端工程师。 【约束】 - 统一返回体 ResultT成功用 Result.success(data)失败用 Result.fail(code, msg) - 日志用 slf4j关键节点打 info异常打 error - 数据库操作走 OrderDao不要直接写 SQL - 方法命名用驼峰接口路径用 kebab-case 【输入】 OrderDao 已有方法findById(Long id), updateStatus(Long id, Integer status) 订单状态枚举1-待支付 2-已支付 3-已取消 4-已完成 【输出】 请生成 OrderService.cancelOrder(Long orderId) 方法和对应的 Controller 接口要求 - 只输出代码 - 校验订单存在、状态允许取消 - 取消成功后打 info 日志 - 异常情况返回对应的错误码AI 拿到这个指令产出的代码基本可以直接用。我实测过加上约束卡之后生成代码的可用率从大概三成提升到了八成以上剩下的两成主要是业务逻辑需要微调不是规范问题。3.5 生成之后的自检三问代码生成出来别急着用先做三个自检命名和项目一致吗——扫一眼类名、方法名、变量名有没有突兀的错误处理符合规范吗——重点看异常分支AI 最容易在这里偷懒有没有引入项目不允许的依赖——AI 有时会自作主张用一些新库要检查 import这三问花不了两分钟但能挡掉大部分看起来能用实际埋雷的代码。我有个同事就是没做自检AI 生成的代码里用了一个项目没引入的库本地跑通了一提交 CI 就挂了排查了半天。注意约束卡不是写完就一劳永逸的。项目规范会变每次规范更新后记得同步更新约束卡否则 AI 会按老规矩生成反而制造不一致。4. 工作流三闭环修复改 bug 不再改出新 bug4.1 直接让 AI 修 bug 为什么容易翻车遇到 bug很多人的做法是把报错信息往 AI 一丢说帮我修。这个做法在简单场景下能用但在真实项目里经常翻车。原因是 AI 只看到了报错没看到上下文它给出的修复往往是让报错消失而不是让逻辑正确。我踩过最典型的一次一个空指针报错AI 建议加个判空返回默认值。我照做了报错确实没了但业务逻辑变成了数据缺失时静默返回空导致下游拿到空数据继续跑最后在更远的地方出了更严重的问题。那次之后我就明白修 bug 必须闭环不能只看报错。4.2 闭环修复的四步法复现、定位、修复、验证我的闭环修复工作流分四步每一步都有明确的产出。第一步复现。先让 AI 帮你把 bug 复现出来。指令是这是报错信息和相关代码请帮我写出一个能稳定复现这个问题的测试用例。 有了复现用例后面所有验证都有依据。第二步定位。让 AI 分析根因而不是直接给修复方案。指令是请分析这个 bug 的根本原因列出所有可能的原因并说明每个原因如何验证。 这一步的关键是列出所有可能避免 AI 只给一个它最先想到的答案。第三步修复。确认根因后再让 AI 给修复方案。指令是根因是 X请给出修复方案要求不改变现有对外行为并说明修复可能影响哪些调用方。第四步验证。用第一步的复现用例验证修复同时让 AI 补充边界测试。指令是请补充这个修复相关的边界测试用例覆盖空值、极值、并发等场景。这四步走下来修 bug 从碰运气变成了有流程。我统计过用这个流程之后同一个 bug 反复出现的概率下降了很多因为根因被真正解决了而不是被掩盖了。4.3 让 AI 解释为什么这样改而不是只给代码闭环修复里有一个容易被忽略的点让 AI 解释修复的理由。很多人只要代码不要解释结果下次遇到类似问题还是不会。我的习惯是每次修复后追问一句请解释这个修复为什么能解决问题以及如果不这样改会怎样。这个追问的价值在于它逼着 AI 把推理过程说出来你能借此判断它的修复是不是真的靠谱。如果 AI 解释得含糊其辞那大概率它自己也没想清楚这个修复就得打个问号。4.4 修复后的回归清单别让老功能背锅修完 bug还有一步不能省回归检查。AI 修复一个地方很可能影响另一个地方。我会让 AI 输出一份回归清单请列出这次修复可能影响的功能点以及每个功能点应该怎么验证。拿到清单后挑关键的手动跑一遍或者补成自动化测试。这一步看起来麻烦但比线上出事故强太多。我有一次修一个缓存相关的 bugAI 的修复影响了缓存过期策略幸好回归时发现了不然上线后缓存雪崩后果不堪设想。4.5 三个工作流怎么串起来用单独用某一个工作流已经能提效串起来用效果更好。我日常的典型流程是这样的接手一个新需求先用工作流一读懂相关模块产出结构地图和影响面清单然后用工作流二带着约束卡生成新功能代码自测时发现 bug切到工作流三闭环修复修完再回到工作流二补测试。整个过程上下文是连续的AI 不用反复重新入职。这套流程跑顺之后我最大的感受是AI 编程的效率瓶颈从来不在模型而在你有没有把怎么用这件事标准化。工具会一直变但工作流的思路是稳定的。5. 把工作流固化成习惯的几个关键动作5.1 建一个上下文仓库别每次从零开始工作流能不能坚持用关键在于准备成本够不够低。如果每次都要重新整理目录树、重新写约束卡没人能坚持。我的做法是建一个上下文仓库就是一个项目根目录下的文件夹里面固定放几样东西structure.md模块结构地图工作流一的产出constraints.md项目约束卡工作流二的核心impact.md改动影响面清单随改动更新bugs.md历史 bug 和修复记录工作流三的沉淀这个仓库跟着项目走每次用 AI 前先把它喂进去准备时间从十几分钟降到一两分钟。而且随着时间积累这个仓库本身就成了项目的活文档新人来了直接看这个就能快速上手。5.2 给每个工作流配一个指令模板指令模板是另一个降本增效的关键。我把三个工作流的核心指令都存成了模板用的时候改几个变量就行。比如工作流二的生成指令模板【角色】你是熟悉 {技术栈} 的资深工程师。 【约束】{粘贴 constraints.md} 【输入】{粘贴相关代码} 【输出】请生成 {功能描述}要求{具体要求}模板不用多复杂关键是固定下来。固定之后你的注意力就从怎么问转移到了问什么效率自然上去。5.3 定期复盘哪些工作流真正省了时间工作流不是定下来就不管的得定期复盘。我的习惯是每个月花半小时回顾一下这个月用 AI 编程的记录问自己三个问题哪个工作流用得最多为什么哪个工作流经常被跳过是不是设计得太重有没有新的高频场景需要补一个工作流复盘的目的不是追求完美而是让工作流始终贴合你的实际工作。我最早的工作流有五个步骤后来发现其中两个几乎用不上砍掉之后反而更容易坚持。5.4 一个容易忽略的细节控制单次上下文规模最后分享一个实操细节。AI 的上下文窗口虽然越来越大但不是塞得越多越好。塞太多重点会被稀释AI 反而抓不住关键。我的经验是单次对话的上下文控制在刚好够用的程度结构导读给目录加签名生成代码给约束卡加相关文件修 bug 给报错加调用链。宁可多开几轮对话也不要一次性塞爆。这个度需要自己摸索但有个简单的判断标准如果 AI 的回答开始变得笼统、抓不住重点那大概率是上下文塞太多了该拆了。这套东西说到底就一句话把 AI 当同事带而不是当工具用。同事需要背景、需要规范、需要反馈AI 也一样。你把这三样给足了它的产出自然就稳了。