上个月一个朋友找我诉苦说团队买了AI编程工具的会员用了一个月代码量没少写反而多了一堆“看起来对但跑起来错”的东西。我让他打开编辑器把平时怎么用AI的完整走一遍给我看结果就是经典三连需求贴一句AI吐一段报错再贴回去。我当时就说这不是AI编程这是把AI当成一个脾气不好的代码生成器。真正值钱的从来不是某一句提示词而是把写代码这件事拆成固定的工作流——每步干什么、用什么模板、人在哪里兜底全部提前定好。这篇文章分享一下我自己沉淀下来、能直接复用的三套AI编程工作流需求澄清三段式、代码审查闭环、Bug根因四步法。每套都附提示词模板和完整实例你拿去就能用不用再自己从零摸索。1. 先聊聊我踩过的AI编程弯路以及为什么工作流能让效果翻倍先说反面教材。我早期用AI编程效率低到怀疑是智商问题。后来复盘发现问题不在模型在用法。有三件事我建议所有刚开始用AI编程的人都先对照一下中一条的话下面三套工作流就是给你准备的。1.1 误区一把AI当成搜索引擎而不是结对程序员大多数人用AI是问一句答一句“帮我写个函数”“这个报错什么意思”。这种用法有两个问题。第一AI在断断续续的临时对话里每轮都在猜你完整的上下文它会默认你没提过的约束都不存在。第二你没有给它完整的输入、边界和验收标准它只能玩概率生成生成的结果自然充满了“看起来很合理但实际没法用”的代码。真正稳定的用法是把它当成一个24小时在线的结对程序员。你要给它任务书、给它约束、给它验收标准它才能稳定输出。这个认知不转变后面所有工作流都用不起来。1.2 误区二提示词即兴发挥无法沉淀复用另一个常见问题是提示词每次都现写。今天这版写得好明天换个写法效果就飘。同一个需求上午让AI写出来的代码和下午让AI写出来的代码风格和质量能差一大截。好的提示词应该有固定结构角色、任务、约束、输出格式。结构本身不难难的是把它沉淀下来变成自己的模板库。后面我分享的三套工作流核心就是三套可以反复使用的提示词模板而不是零散的灵光一现。模板的意义在于你把踩过的坑修进模板里下次就不会再犯。1.3 误区三缺少验证环节把“自信”当“正确”AI最大的迷惑性在于表达非常自信。你问它这个Bug修好没有它说修好了实际上只是把报错吞掉了你说“这段代码帮我看看有没有问题”它一口气列了五六个建议你信以为真结果它把本来没问题的代码改坏了。所以不管多强的模型输出都必须经过验证。具体怎么操作让AI自己列出测试用例让它给验证步骤然后人工至少跑一遍。我见过太多代码评审里“AI说没问题就合了”然后线上出事的案例。验证是工作流里必不可少的一环不是可选项。有了这三条教训打底下面每套工作流的设计里都会出现一个共同的词兜底。2. 工作流一需求澄清-方案设计-代码落地三段式2.1 这套工作流要解决的核心痛点开发中最常见的场景是“需求一句话”。产品经理说“加个导出功能”你追问细节他说“很简单的就是导出Excel”。真到写代码才发现哪些字段什么格式多大数据量要不要异步要不要权限全都没定。如果你把这种模糊需求直接丢给AI等于让AI替你做产品经理它只能猜。猜完之后代码自然不能跑然后你就在“报错-改代码-再报错”的循环里出不来了。所以我总结了一个三段式工作流先让AI当需求分析师再当架构师最后才当程序员。核心逻辑是把AI擅长的三个能力拆开用。它在结构化对话里最稳所以第一步先把需求问清楚第二步把方案定了边界和接口明确出来第三步再让它写代码这时候它写得又快又稳。2.2 三段式提示词模板可直接复制第一段需求澄清。这一段让AI先提出问题而不是直接写代码你现在是一个资深技术负责人。我接下来会给你一个初始需求请你 1. 先列出我需要跟你确认的问题清单不少于6条覆盖输入输出、边界条件、异常处理、性能要求、部署环境等维度 2. 基于最常见的假设用一段话给出初始技术方案 3. 在我确认之前不要写任何完整代码 我的初始需求是在这里粘贴需求第二段等你把问题回答了再让AI出技术方案基于我在上一轮的回答请你输出一份完整技术方案包含 1. 模块划分与职责 2. 核心数据结构和接口定义 3. 关键流程说明用自然语言或者伪代码不要写完整实现 4. 边界情况与风险点清单 5. 测试策略至少3个关键测试场景 如果方案中还有不明确的地方请标注出来不要替我做假设第三段方案你确认没问题了最后才让它写代码请严格按照上面的技术方案实现完整代码。要求 1. 每个关键函数写清晰注释尤其标注容易出错的地方 2. 提供可直接运行的入口 3. 包含至少两个单元测试用例覆盖正常路径和边界路径 4. 运行时打印关键操作日志便于排查 5. 如果实现过程中发现方案有遗漏用TODO标记不要擅自扩大改动范围三段可以合并成一次对话让AI按顺序执行也可以分三次追问。我最开始是分三次问后来发现直接在同一个会话里说“按顺序执行三步”模型也能处理得不错。2.3 完整实例从一句话需求到能跑的日志清理脚本来一个实际例子。假设需求是写个脚本把服务器上超过30天的日志删掉。用老式问法AI大概率给你一个os.walk加os.remove的脚本十行左右看起来能用但一堆问题日志路径写死、没有参数、误删目录、没有备份、没有运行日志。出了问题你连它删了什么都不知道。用三段式跑一遍。第一轮AI会列出一堆问题我挑几个有代表性的日志目录是脚本参数还是写死在配置里判断“超过30天”依据的是文件修改时间还是文件名里的日期需要递归处理子目录吗文件后缀是限定.log还是全部删除之前要不要dry-run试运行支持执行后需要打印摘要吗要不要写删除操作日志说实话大多数人手动写这种脚本的时候根本不会想全这些问题。第二轮AI给方案主函数负责参数解析清理模块负责扫描用pathlib的rglob做递归匹配过期判断用文件mtime和截止时间比较dry-run模式下只打印不删除。第三轮代码落地的效果大概是这个样子import argparse import logging from datetime import datetime, timedelta from pathlib import Path logging.basicConfig(levellogging.INFO, format%(asctime)s %(levelname)s %(message)s) def parse_args(): parser argparse.ArgumentParser(description清理过期日志文件) parser.add_argument(--logdir, requiredTrue, help日志目录) parser.add_argument(--days, typeint, default30, help保留天数) parser.add_argument(--pattern, default*.log, help文件匹配模式) parser.add_argument(--dry-run, actionstore_true, help只打印不删除) return parser.parse_args() def clean(directory: Path, days: int, pattern: str, dry_run: bool) - int: cutoff datetime.now() - timedelta(daysdays) removed 0 for file in directory.rglob(pattern): mtime datetime.fromtimestamp(file.stat().st_mtime) if mtime cutoff: if not dry_run: file.unlink() logging.info(%s %s, 删除 if not dry_run else 模拟删除, file) removed 1 return removed def main(): args parse_args() root Path(args.logdir).resolve() if not root.is_dir(): raise SystemExit(f目录不存在: {root}) removed clean(root, args.days, args.pattern, args.dry_run) logging.info(共处理 %d 个文件, removed) if __name__ __main__: main()说实话这段代码放到真实业务里也够用尤其dry-run和日志这两点是很多人手动写的脚本根本没有的。2.4 实测心得时间花在哪里最划算三套工作流里我最推荐先抄这套。最开始我用它感觉明显“变慢了”因为多了澄清和方案两个环节催着AI跑的那股劲没了。但把整个任务从开始到测试通过的耗时拉通看原来直接写大概要半天现在一小时出头就完事而且更稳。时间不是花在编码上是花在把问题想清楚上。这套工作流几乎覆盖日常60%的开发任务新接口、工具脚本、数据处理、页面功能。只要需求有一点模糊先走一遍澄清成本极低收益很高。3. 工作流二变更影响分析-自动审查-修复闭环3.1 审查类任务的正确打开方式第二个被验证可复用的工作流是代码审查。这里的场景不光是PR自审也包括接盘遗产代码或者在改别人代码之前先摸一遍风险。有人直接把一堆代码甩给AI说“帮我看看有什么问题”得到的答案通常非常泛。它可能会说“这个函数有点长建议拆一下”或者干脆给你推荐一整套重构方案。这不算错但覆盖不了“能不能上线”这个核心诉求。我更推荐的做法是让AI按固定的检查清单逐项扫描。人把多年踩坑经验编码成清单AI负责高效执行。这样既发挥了AI擅长模式匹配和穷举的优点也保留了人对业务语义的判断。3.2 审查提示词模板含五个检查维度请你以资深Code Reviewer的身份审查下面这段代码。不要泛泛评论严格按以下清单逐项检查 A 正确性空指针/越界/死循环/并发安全/幂等性 B 健壮性异常处理/资源释放/重试机制/默认值合理性 C 可维护性命名是否准确/函数复杂度/重复逻辑 D 性能不必要的循环/内存增长/频繁IO E 安全注入/越权/敏感信息泄露如果相关 输出要求 1. 按严重程度从高到低列出问题每条包含行号、触发场景、问题原因 2. 每个高优先级问题给出最小改动的修复建议 3. 如果某维度没有问题明确写“该维度未发现问题”不要编造 4. 最后用一句话总结是否可以合入/上线 代码在这里这个模板的关键在于“不要编造”和“每个维度都要输出”。前者压制幻觉后者逼它真去一行行看而不是扫一眼给个感觉。3.3 复现示例让AI揪出遍历删除的经典Bug举个例子。有个函数负责把列表里前缀为tmp_的项删掉def remove_temp_items(items): for item in items: if item.startswith(tmp_): items.remove(item) return items如果用老式问法“帮我看看这段代码哪里不对”AI通常也能说“遍历的同时修改列表会导致跳过元素建议用列表推导式”。这个回答方向没错但信息量不够。用上面的清单模板AI输出的结构会完整得多。正确性维度会直接给出触发场景比如传入[tmp_a, keep, tmp_b]时删掉tmp_a后列表前移keep被直接跳过换成[tmp_a, tmp_b, keep]时删掉tmp_a后走到第二项tmp_b被跳过了。健壮性维度会建议先复制一份再遍历或者倒序删除。可维护性维度会说列表推导式更清晰。拿到这种输出你只需要花十几秒确认一下就知道该怎么修。3.4 实测心得AI审查的盲区在哪里这套工作流跑了一段时间后我得出了几个很实用的结论。第一AI对逻辑正确性和健壮性的检查命中率相当高但代价是偶尔会把对的代码说成有问题。我的解决办法是加那条“每个维度都要明确输出未发现问题”的指令加了之后误报率明显下降。第二AI对业务语义是瞎的。你让它审“这个利率计算公式是否匹配现行规则”它根本判断不了因为规则不在代码里。所以审查之前我会手动补充一条业务约束给AI“这个函数在并发场景下最多同时两个线程调用请按这个前提审查。”附加了上下文之后审查质量会再上一个台阶。第三AI审查不能替代人工review但可以替代人工review前的第一遍粗看。人省下来的时间去看架构、看业务、看设计分工更合理。4. 工作流三报错-根因-修复-验证四步闭环4.1 为什么不能直接让AI“修一下”第三个工作流是我日常使用频率最高的排错。这个场景非常容易走偏因为AI有很强的“修复冲动”。你只要贴一行报错它立刻给你一个改动方案。但多数时候它给的方案是把症状消掉而不是把病根治好。我印象很深的一次生产环境上报了一个list index out of range我顺手把整段代码贴给AI它立刻说“在访问前加一个if判断”。加上之后确实不崩了但多跑几天发现漏了一整批数据。后来一查根因是上游列表拼接时多了一条分隔符导致某一次索引访问越界。正确修法在拼接逻辑那边而不是在读取端打补丁。所以我现在强制自己走四步报错、根因、修复、验证。顺序不能乱。4.2 四步提示词模板先根因后修复我给你一段报错和代码请严格按下面的顺序回答不要跳步 1. 根因链分析从入口数据开始逐步描述代码是如何一步步走到这个异常的指出真正的根因 2. 影响评估哪些输入、哪些调用路径会触发影响范围多大 3. 最小修复方案给出改动最小的修复方式不要引入新依赖不要大规模重构 4. 验证方案列出修复后必须执行的验证步骤或测试用例证明问题真的被修复 如果信息不足以完成判断明确说“信息不足”并列出你还需要的3项信息。禁止猜测。 报错信息 相关代码 输入数据/日志这个模板最关键的一点是把“信息不足就提问”写进去了AI就不会在只有半行堆栈的时候编故事。4.3 复现示例从AttributeError一路追到数据清洗看一个很简单但非常典型的例子def gen_report_line(user): return { username: user.get(name).upper(), email: user.get(email, ) }报错File report.py, line 3, in gen_report_line username: user.get(name).upper(), AttributeError: NoneType object has no attribute upper用老式问法AI大概率会直接在username那行包一个or 然后代码不崩了但语义变了name缺失时输出空字符串。而业务要求是name缺失的行要标记告警空着就会静默漏数据。用四步模板AI会这样输出根因链user.get(name)返回None说明调用方传入的user记录里没有name字段或name字段本身是None上层采集逻辑没有在入库时清洗空值。影响评估所有name缺失的用户记录都会触发异常导致整个报表生成失败影响范围不是单行是整批任务。最小修复方案在数据入口清洗name为空时统一填充unknown并记录告警日志展示层做一层防御性兜底。验证方案构造三个样本——有name、name为None、字典缺少name键分别跑一次断言输出字段类型合法。这个例子很小但能清楚说明为什么“先根因后修复”不是为了仪式感而是避免你在错误的地方打补丁。4.4 实测心得喂给AI的上下文必须包含哪些内容排错效果好不好七成取决于上下文不在模型。我总结了一个最小上下文清单完整报错堆栈不要只贴最后一行触发场景哪个接口、什么入参、大概多少数据量相关代码片段最好带函数签名和调用点期望行为这一段本来应该做什么有一次我把这四样都给全AI不仅定位到根因还补了一句“这个问题在某些语言版本下表现会不一样”这个提醒是我完全没考虑到的。另外一个小技巧如果AI连续两次给不出靠谱根因不要继续追问而是主动补数据样本。很多时候缺的就是一个看起来无关的数据有了它根因一下就清楚了。5. 把三套工作流沉淀成可复用的个人资产5.1 用轻量笔记建提示词资产库三套工作流如果只是看完就扔价值就没了。我的习惯是用一个Markdown文件把它们沉淀下来字段包括适用场景、模板、使用心得、翻车案例。每次实际使用中发现问题就回去改模板。提示词和代码一样需要版本管理。这个仓库不用多复杂一个私有git仓库加一个README就够。按“需求开发”“代码审查”“Bug排查”三个分类建目录每个模板保留一版最新的旁边写清楚“上次在哪次任务里翻车加了哪一句约束修复”。到年底你会发现所谓经验不过是这些模板迭代的记录。5.2 多AI协作方案、实现、审查分工还有一个能提升效果上限的技巧多AI协作而不是把宝押在一个模型上。具体分工可以这样理解阶段建议操作关注点需求澄清与方案设计用一个模型专注把边界和接口问清楚约束完整、方案可落地代码落地换一个模型写实现代码风格、注释、可读性代码审查与挑刺换一个模型或新会话重新看一遍逻辑漏洞、边界遗漏、误判原因是模型各有擅长的会话风格。同一个模型设计方案之后让它实现容易顺着方案往下写自己方案里的坑自己看不见。换一个模型带着“挑刺”的心态去审查更容易发现思路层面的问题。这个操作不需要任何复杂框架手动切换就行但效果非常明显。5.3 进阶方向从手动模板到Agent化编排如果你的工作流已经跑稳了想进一步提效可以考虑把这些手动流程做成可编排的自动化工作流。Dify、Coze这类平台都支持把多轮提示词串联成可视化流程配上团队知识库比如编码规范、历史事故复盘能让整个团队共享同一套AI编程方法。不过我个人的建议是先把手动的三套工作流跑熟再上自动化。原因是自动化只是把流程固化如果流程本身还没定型你固化的只是混乱。手动跑一阵子你自然会知道哪个环节最浪费时间、哪个环节最容易出错那时候再做工具化才是有的放矢。最后再分享一个我一直坚持的小习惯每次AI给出高质量输出我会顺手把当时的完整提示词存进对应的模板文件里标注清楚这次任务的特点。这比收藏一堆文章有用多了因为这些模板是你自己踩出来的路。希望这三套工作流能让你少走一点我走过的弯路。