告别低效提示词：3个AI编程工作流实战指南

1. 为什么“工作流”比“提示词”更值得花时间很多人接触 AI 编程的第一反应是去搜“最强提示词”“万能模板”收藏夹里躺了几百条真到写代码的时候还是一条条手动粘贴。我自己也经历过这个阶段后来发现一个很现实的问题提示词解决的是“单次对话质量”而工作流解决的是“重复任务的稳定性”。你不可能每次写单元测试都重新组织一遍语言也不可能每次做代码审查都从头描述项目背景。所谓 AI 编程工作流说白了就是把“什么情况下触发 AI、给它什么上下文、让它按什么格式输出、输出后怎么验证”这一整套动作固定下来。它更像是一条流水线而不是一次灵感迸发。流水线的好处是哪怕某一次模型发挥不稳定你也能通过固定的校验环节把问题拦住而不是等到合并代码时才发现。这篇文章要聊的 3 个工作流分别对应编程中最耗时的三个环节理解陌生代码、生成可测试的实现、以及把重复的审查动作自动化。它们不需要你搭建复杂的 Agent 框架也不需要付费订阅一堆工具用你手头已有的编辑器和命令行就能跑起来。适合已经用过 AI 写代码、但总觉得“时灵时不灵”的开发者也适合想把自己从重复劳动里捞出来的技术负责人。在展开之前先明确一个原则工作流的目标不是让 AI 替你写完全部代码而是让你在每一个需要决策的节点上都能拿到足够干净的输入从而把精力留给真正需要判断力的部分。下面这三个流程都是围绕这个原则设计的。2. 工作流一陌生代码库的“三遍阅读法”2.1 直接让 AI 读整个仓库为什么行不通刚接手一个项目时最自然的想法是把整个仓库丢给 AI让它总结架构。我试过很多次结论是对于超过 20 个文件的项目这种做法基本无效。原因有两个。第一上下文窗口再大也有边界代码之间的调用关系一旦被截断AI 就会开始“脑补”不存在的模块。第二即使窗口装得下模型对大量无关文件的注意力是分散的它给出的总结往往停留在“这是一个基于 XX 框架的项目”这种层面对你真正关心的“订单状态在哪里流转”毫无帮助。所以这个工作流的核心不是“让 AI 读代码”而是“由你控制阅读的粒度和顺序”。我把它叫做三遍阅读法每一遍的目标不同给 AI 的输入也不同。2.2 第一遍只给目录树和入口文件第一遍的目标是建立地图感。你只需要把项目的目录结构用tree -L 2或find . -maxdepth 2 -type d生成和入口文件比如main.py、index.js、Application.java贴给 AI然后问一个非常具体的问题根据这个目录结构和入口文件列出这个项目最可能的三个核心业务模块并说明你判断的依据。注意这里要的是“判断依据”而不是“总结”。因为你需要知道 AI 是从哪些线索推断出来的才能判断它的推断是否靠谱。比如它说“看到order目录下有state_machine.py推测订单状态是核心”这个依据就是可验证的。如果它只是泛泛地说“这是一个电商项目”那说明入口文件给的信息不够你需要补上路由配置或依赖注入的注册文件。这一遍的输出应该是一张手绘级别的草图哪几个模块模块之间大概怎么调用。不要追求精确追求的是“下一步该看哪里”。2.3 第二遍沿着一条调用链深挖有了地图之后第二遍只选一条你最关心的调用链。比如你要改订单退款逻辑那就从退款接口的 Controller 开始一路跟到 Service、Repository把这条链上的文件内容按顺序贴给 AI。这时候的提问要带上明确的约束这是退款接口从入口到数据库的完整调用链。请按执行顺序列出每一步做了什么并标出哪些步骤涉及外部服务调用、哪些步骤有事务边界。这个提问方式的关键在于“按执行顺序”和“标出边界”。AI 在梳理线性流程时表现很好但如果你不要求它标出事务和外部调用它很容易把这些关键信息淹没在流水账里。而事务边界和外部调用恰恰是改代码时最容易出事的地方。我自己的习惯是在这一遍结束后让 AI 输出一个带行号引用的步骤列表。这样我在编辑器里跳转的时候可以直接定位不用再问一遍“你刚才说的那个校验在哪”。2.4 第三遍让 AI 扮演“提问者”而不是“回答者”前两遍都是你在问、AI 在答。第三遍反过来你把前两遍的结论整理成一段简短的描述然后让 AI 针对这段描述提出它认为最可疑的三个点。以下是我对退款流程的理解[你的描述]。请指出这个理解中最可能出错或最不完整的三个地方并说明如果要在代码中验证应该去看哪个文件或哪个函数。这一步的价值在于AI 会去关注那些你因为“想当然”而忽略的细节。比如你可能默认退款是同步的但 AI 会问“有没有异步补偿任务”。你可能默认金额是整数AI 会问“有没有汇率换算”。这些问题不一定都有问题但它们能帮你把隐性的假设显性化。三遍下来你对一个陌生模块的理解深度通常比漫无目的地读一天代码要扎实。而且整个过程你始终在控制输入不会被 AI 的幻觉带偏。2.5 这个工作流里最容易踩的坑第一个坑是目录树给得太深。有人直接把tree的完整输出贴进去几百行目录反而让 AI 抓不住重点。我的经验是两层足够最多三层而且要把node_modules、venv、dist这些目录排除掉。第二个坑是在第二遍时同时跟多条调用链。我试过一次贴三条链结果 AI 把不同链的步骤混在一起输出了一份看似合理但完全错误的流程。后来我改成一次只跟一条效率反而更高。第三个坑是忘记更新上下文。代码是会变的如果你隔了一周再问同一个模块最好重新跑一遍第一遍和第二遍而不是接着上次的对话继续问。模型不会自动知道代码已经改了。3. 工作流二从需求到可运行测试的“契约先行”流程3.1 先写测试还是先写实现AI 时代有了新答案传统 TDD 要求先写测试再写实现但让 AI 直接写实现往往更快。于是很多人变成“AI 写实现人补测试”结果测试只是把实现的行为复述了一遍起不到发现问题的左右。我后来调整了顺序让 AI 先输出接口契约人确认契约再让 AI 分别生成测试和实现。这样测试和实现是独立从契约推导出来的而不是互相抄。所谓契约就是函数的签名、输入输出的类型、边界条件的约定、以及错误码的定义。它不涉及具体算法只描述“这个函数对外承诺什么”。契约一旦定下来测试和实现就有了共同的依据。3.2 契约应该包含哪些字段我通常要求 AI 按固定格式输出契约这样方便后续直接转成代码。一个契约至少包含函数名和参数列表含类型返回值类型和含义可能抛出的异常或返回的错误码边界条件空值、零值、超长输入、并发调用一个最小调用示例举个例子如果需求是“计算订单折扣”契约可能长这样def calculate_discount(order_amount: Decimal, user_level: str, coupon: Optional[Decimal]) - Decimal: 返回折扣后的金额保留两位小数。 user_level: normal | silver | gold coupon: 优惠券面额可为 None 异常: 当 order_amount 0 时抛出 ValueError 边界: coupon 大于 order_amount 时折扣后金额为 0 这个契约里“coupon 大于 order_amount 时折扣后金额为 0”就是一条明确的边界约定。如果没有这条AI 生成的实现可能会返回负数测试也可能漏掉这个场景。3.3 让测试和实现从契约“分叉”契约确认后我会开两个独立的对话。一个对话只给契约要求生成 pytest 或 unittest 测试用例覆盖正常路径、边界条件和异常路径。另一个对话也只给契约要求生成实现。两个对话互不参考这样测试不会“迁就”实现的写法实现也不会“迎合”测试的断言。实测下来这种做法能抓到不少问题。有一次 AI 生成的实现把coupon直接减掉没有做上限判断而独立生成的测试里恰好有一条coupon order_amount的用例一跑就红了。如果我让同一个对话既写实现又写测试它大概率会“记得”自己实现里的处理方式从而写出一个刚好通过的测试。3.4 测试跑通之后还要做什么测试全绿不代表可以合并。我还会做一步“变异检查”手动把实现里的某个条件改反比如把改成然后看测试会不会失败。如果测试仍然通过说明这条测试的断言太弱需要补强。这一步不需要工具手动改一两处关键逻辑就行几分钟的事但能显著提升测试的可信度。另外契约本身也要归档。我习惯把契约放在代码文件顶部的 docstring 里这样下次有人改这个函数第一眼看到的就是它对外承诺的行为而不是直接陷入实现细节。3.5 这个流程对提示词的要求这个工作流对提示词的要求其实很低因为契约已经把该说的都说清楚了。我常用的提示词就两句生成测试时“根据以下契约生成 pytest 测试覆盖正常、边界、异常三类场景不要参考任何实现代码。”生成实现时“根据以下契约生成实现不要引入契约之外的依赖不要处理契约未定义的输入。”关键在“不要参考任何实现代码”和“不要处理契约未定义的输入”这两句约束。前者防止测试迁就实现后者防止实现过度设计。很多 AI 生成的代码之所以难维护就是因为它在契约之外自作主张地加了一堆防御性逻辑而这些逻辑既没有测试覆盖也没有文档说明。4. 工作流三把代码审查变成“可复现的检查清单”4.1 为什么直接让 AI “审查这段代码”效果很差“帮我看看这段代码有没有问题”——这是最常见的用法也是最没用的用法之一。AI 会给你一堆泛泛的建议比如“建议添加错误处理”“建议补充注释”这些建议放在任何代码上都成立对你没有实际帮助。问题不在于 AI 能力不够而在于你没有告诉它“审查的标准是什么”。代码审查本质上是一个对照检查表的过程。资深工程师审查代码时脑子里有一张清单有没有处理空值、有没有资源泄漏、有没有并发问题、命名是否一致、日志是否足够排查问题。AI 需要的是这张清单而不是一句“帮我看看”。4.2 把审查拆成三个独立的检查维度我把审查拆成三个维度每个维度单独跑一次而不是一次问完。这样 AI 的注意力更集中输出也更可操作。维度一正确性。只关注逻辑是否正确忽略风格和性能。提示词可以这样写以下代码的功能是 [一句话描述]。请只从正确性角度审查是否存在边界条件未处理、是否存在逻辑分支遗漏、是否存在类型不匹配。每条问题请给出具体的输入示例说明在什么输入下会出错。要求给出“具体输入示例”是关键。如果 AI 说“可能空指针”但给不出触发空指针的输入那这条建议就可以先放一边。维度二资源与并发。只关注文件句柄、数据库连接、锁、线程池这些资源。提示词以下代码涉及 [数据库/文件/网络] 操作。请只审查资源管理连接是否在所有路径上都被释放、锁的获取和释放是否配对、是否存在死锁风险。请按“问题-位置-建议”的格式输出。维度三可观测性。只关注日志、指标、错误信息。提示词以下代码在生产环境运行。请只审查可观测性关键分支是否有日志、错误信息是否包含足够的排查上下文、是否有敏感信息被写入日志。请指出具体缺少日志的位置。三个维度分开跑每次的输出都短而具体。我通常会把三个维度的结果合并成一张表然后逐条决定是否修改。这样审查就从一个模糊的“感觉”变成了一份可追踪的清单。4.3 把清单固化成模板跑过几次之后你会发现某些检查项在你的项目里反复出现。比如“所有数据库查询必须有超时设置”“所有外部调用必须有重试和熔断”。这时候就可以把这些项目从提示词里抽出来做成一个项目级的审查模板。我的做法是在仓库里放一个review-checklist.md里面按维度列出项目特有的检查项。每次审查时把这份清单和代码一起贴给 AI让它逐项对照。这样新加入的成员也能用同一套标准审查代码而不是靠口口相传。4.4 审查结果怎么处理才不浪费AI 给出的审查意见我一般分三类处理。第一类是确定要改的直接改掉并补测试。第二类是需要讨论的比如“这里要不要加缓存”这类我会记下来在团队同步时提出来。第三类是误报比如 AI 说“可能空指针”但实际调用方已经保证了非空这类我会在清单里补一条说明避免下次再被同样的问题干扰。关键是不要让审查结果停留在聊天记录里。我会把每次审查的结论追加到 PR 的描述里这样合并之后还能追溯“当时为什么这么改”。这比事后翻聊天记录靠谱得多。4.5 这个工作流的边界需要说明的是AI 审查不能替代人工审查尤其是涉及业务语义的部分。比如“这个折扣计算是否符合最新的营销规则”AI 无从判断因为它不知道规则。它能做的是把那些机械性的、清单式的检查项跑一遍让人可以把精力集中在业务逻辑和架构决策上。另外审查的代码片段不宜过长。我的经验是单次不超过 200 行超过就拆成多个文件分别审查。太长的代码会让 AI 的注意力分散输出质量明显下降。5. 三个工作流怎么串起来用单独用其中任何一个都能省下不少时间。但真正让我觉得效率有质变的是把它们串成一条线。假设我接手一个需求给现有的订单模块加一个“超时未支付自动取消”的功能。我会这样走先用工作流一快速理解订单模块的现状。第一遍看目录找到订单相关的文件第二遍沿着“创建订单”的调用链走一遍搞清楚订单状态存在哪里、状态流转由谁触发第三遍让 AI 提问确认有没有现成的定时任务框架、有没有分布式锁。然后用工作流二定义契约。自动取消这个功能契约可能是一个cancel_expired_orders(timeout_minutes: int) - int的函数返回取消的订单数。契约里要写清楚超时时间怎么算、并发调用时会不会重复取消、取消后要不要发通知。契约确认后分别生成测试和实现。最后用工作流三审查实现。重点看正确性时间边界、并发、资源数据库连接、锁、可观测性取消数量有没有打日志。审查通过后合并。这条线走下来从理解到上线中间几乎没有“卡住不知道下一步干什么”的时刻。因为每个环节都有明确的输入和输出AI 只是在每个环节里帮你加速而不是替你决定方向。6. 一些关于工具选择的实在话这三个工作流对工具的要求很低。你可以在 IDE 的 AI 插件里跑也可以在网页端跑甚至用命令行工具把文件内容管道给模型都行。我自己的组合是理解代码时用支持大上下文的对话工具生成测试和实现时用 IDE 插件方便直接写入文件审查时用网页端方便贴清单和长代码。有一点需要提醒不要把工作流和某个特定工具绑定。工具会变模型会升级但“控制输入粒度、分离测试与实现、按维度审查”这些原则是不变的。我见过有人把整套流程写死在某个平台的配置里结果平台一改接口流程就废了。把原则留在脑子里把模板留在仓库里工具只是执行手段。另外关于上下文长度我的经验是宁可分多次给干净的上下文也不要一次给一大堆混杂的内容。模型对上下文的利用效率不是线性的塞得越满关键信息越容易被稀释。三个工作流里反复出现的一个动作就是“裁剪输入”这可能是比任何提示词技巧都更重要的习惯。7. 我踩过的几个印象深刻的坑第一个坑是过度信任 AI 的架构总结。有一次我让 AI 根据目录结构总结一个项目的分层它说得头头是道我直接照着去改代码结果发现它把两个不同模块的职责搞混了。后来我养成了习惯AI 的总结只用来生成“待验证的假设”每一个假设都要在代码里找到对应的证据才算数。第二个坑是契约写得太模糊。有一次契约里只写了“返回折扣后的金额”没写保留几位小数。结果测试和实现分别按不同的精度处理跑起来差了一分钱。这种问题在金额相关的代码里特别致命。从那以后契约里凡是涉及数值的我一定写明精度和舍入规则。第三个坑是审查清单太长。一开始我把能想到的检查项全塞进去结果 AI 的输出变成了一份冗长的报告真正重要的问题反而被淹没了。后来我强制自己每个维度最多留五条检查项只保留那些在这个项目里真正出过问题的。清单短了执行率反而高了。第四个坑是忘记清理对话历史。同一个对话里聊了太多不相关的话题AI 会把之前的上下文带进来给出莫名其妙的建议。现在我每切换一个任务就新开一个对话哪怕只是问一个小问题。8. 怎么判断一个工作流值不值得留下来不是每个工作流都值得长期维护。我判断的标准很简单如果这个流程连续三次帮我省下了超过它维护成本的时间就留下否则就砍掉。维护成本包括写提示词的时间、整理输入的时间、以及处理误报的时间。比如“三遍阅读法”我用了大半年每次接手新模块都能省下至少半天维护成本几乎为零所以一直留着。“契约先行”在业务逻辑复杂的模块里效果很好但在写脚本、做数据清洗这种一次性的任务里就有点重我会根据场景选择用或不用。审查清单则是随着项目演进的每季度回顾一次把不再适用的条目删掉。工作流不是越多越好而是越贴合你当前的项目和习惯越好。别人的流程可以参考但最终一定要按自己的节奏调整。我上面写的这些你完全可以只拿走其中一条用顺了再考虑加第二条。最后分享一个我最近在用的一个小技巧每次跑完一个工作流花两分钟在笔记里记一句“这次哪里卡住了”。攒上十几条之后回头看你会发现自己的卡点其实很集中通常就那么两三个。把这两三个卡点对应的环节优化掉整体效率就会有明显的提升。这比不断尝试新工具、新模型要实在得多。