开头我先讲一个让人血压升高的场景你把需求栏里那段话复制给 AI让它写个功能它不到一分钟就甩出几百行代码你心里想“AI 写代码真方便”结果一跑报错改了半小时业务场景又对不上最后你发现它很听话地把你那句模糊描述里的坑全部填上了。问题从来不在 AI而在我们跳过了需求澄清直接让它“动工”。我越来越确信在真正把活儿交给 AI 之前得先建立一套可靠的需求闭环这套闭环我用三个奇怪的关键词来命名Grill-Me、BFS、AFK。Grill-Me 负责把模糊需求拷问到清晰BFS 负责把任务按广度优先展开避免漏场景AFK 负责让每一次 AI 产出都有确认和留档。这套方法适合所有被 AI 生成代码坑过的工程师也适合正在带队用 AI Agent 做项目、想摆脱“AI 码农碰运气写代码”状态的人。1. 为什么“别急着让 AI 写代码”瓶颈不在编码在需求1.1 AI 不会主动理解业务它只会顺着描述“圆谎”很多人对 AI 写代码有个误解以为它像资深工程师一样会先问你“业务背景是什么”“异常情况怎么处理”。实际上绝大多数生成式 AI 的底层行为是根据你输入的上下文计算最可能出现的下一个 token然后一路接下去直到拼出一个看起来像完整程序的文本。它没有“理解”你的业务它只是在做概率与模式匹配。所以当你喂给它的是一句含糊其辞的需求比如“帮我写个订单导出的功能”它大概率会给你一段能用 console 打印 CSV 的代码。它不会问是运营每天手动导出还是定时任务生成导出之后要发邮件吗要按什么维度汇总要不要历史快照这些你没说它就不会知道但它不会承认自己不知道而是非常自信地给出一个“看起来完全合理”的答案。这就是我所说的“圆谎”AI 会把你的模糊描述自动脑补成一个具体的、可运行的实现但这个实现很可能和真实业务相去甚远。再用生活里订餐类比你跟 AI 说“我要吃饭”它给你端上来一碗标准模板面但你真实需求可能是“三个人、晚上七点、不吃辣、预算一百五、有包间最好”。可惜你什么都没说最后只能对着那碗面干瞪眼。需求输入的精度基本决定了 AI 输出代码的有效性。1.2 需求阶段错 1 小时实现阶段要还 1 天我这几年的一个直观体会是返工成本在需求阶段最低越往后面越贵。在需求还没写清楚的时候多花一小时去追问最多就是晚点开始动工但如果等 AI 把代码写出来、甚至已经跑通主流程之后再发现方向错了那要改的往往是整块逻辑连带测试、文档、联调一起重来。我以前带过一个内部小项目让 AI 写四十多个接口团队当时特别兴奋觉得生产力拉满。结果需求评审时发现最初对“报表是要即时生成还是要历史快照可回测”这个问题没有确认导致十几个接口的底层数据组织方式全错。那一次返工让我明白AI 写代码本身不慢慢的是“方向错了之后的重写”。业界常说缺陷在需求阶段发现修复成本是 1 倍到了编码阶段可能变成 3 到 6 倍到测试阶段甚至更高。这个数字未必精准但方向没问题。所以我不反对用 AI 加速开发我反对的是把 AI 当成“需求理解器”。AI 最强大的地方是把你已经想清楚的东西快速落地而不是替你想清楚。你把需求收敛得越干净AI 写代码的体验越接近“降维打击”你要是偷懒不做需求澄清AI 写代码时爽的那一下迟早变成返工时加倍的痛。1.3 AI 的正确位置人想清楚AI 快落地把 AI 摆到什么位置决定你的项目是起飞还是翻车。我的做法是把 AI 当成一个“执行能力很强、但不会主动问业务的新人”而不是“全知全能的高级工程师”。你已经拍板了具体方案它负责在半小时内把第一版实现堆出来这个过程非常高效。它不擅长的是替你在业务迷雾里做决策。我见过不少同事抱怨“写代码速度慢怎么办”其实拆开来看他们的慢多半不是敲键盘慢而是需求没理清时反复改 AI 生成的代码。今天让 AI 按 A 理解写明天发现 B 才是真实需求后天又发现还要兼容 C 数据源。来回几次之后效率反而比手写还低。反过来如果先花时间把需求闭环做扎实AI 承担“从明确规格到可用代码”这一段速度会非常惊人。这也引出了这套方法论的核心顺序先 Grill-Me把需求问透再 BFS把场景摊开然后 AFK把确认循环跑起来。顺序不能乱乱了你得到的就是一个“速度很快但方向随机”的 AI 编程体验。2. Grill-Me用拷问式提问把需求“烤熟”2.1 Grill-Me 是什么先找个人把需求方“烤”一遍Grill 这个词在英语里既是烧烤架也是“严加盘问”。给这套方法起名 Grill-Me就是想表达一种状态在让 AI 动手写代码之前先用一连串不太好回答的问题把需求方和自己都“烤”到没有模糊空间为止。具体执行起来就是找一个安静的时段约上需求方或者至少拉上项目里最了解业务的人然后照着问题清单一条条过。你可能会觉得这不就是需求评审吗对它本质上就是需求评审但 Grill-Me 更强调“提问的强度和密度”。普通评审经常问一两个大方向就散了Grill-Me 不同它要求每个功能点都必须回答清楚谁在用、什么场景、解决什么痛点、怎样算完成。有一个很实用的经验不要指望一轮就烤完。需求这东西往往是你越往下挖越发现自己还有没问到的角落。比如用户说“要一个用户反馈功能”你以为就是“表单 存库 列表展示”。你多问一句“用户反馈之后你们运营怎么处理”才意识到还要有状态流转、通知提醒、分类标签、超时升级。你若又问“反馈里能不能带截图”又会牵扯到上传组件、文件大小限制、存储范围。所以 Grill-Me 本质是一个迭代收敛过程第一轮问出大体边界第二轮把边界里的细节钉死。2.2 我常用的三组 Grill-Me 必问清单我不会每次都重新发明问题而是固定用下面三组问题做底子。你可以直接抄去用基本上覆盖了需求澄清 80% 的坑。第一组是边界与用户问题。核心是搞清楚“谁在什么情况下用”这功能给谁用是新用户还是老用户使用频率高不高是每天打开还是偶尔一次有没有特定设备要求如果不用这个功能对用户有什么损失这些问题能帮你把用户的画像和使用场景钉住。很多时候需求方说“做一个智能推荐”追问下来才发现其实只是想给特定会员做一批人工精选商品根本不是要算法。第二组是价值与验收问题。核心是“做完之后怎么证明它做完了”这个功能上线后用户能得到什么哪个指标能看出它发挥价值你判断做对的标准是什么如果资源紧张只能做一半哪一部分可以先交付这些问题会逼着需求方把“完成”翻译成可检查的验收动作而不是停留在形容词层面。有次需求方说“要做得流畅一点”我追问“流畅的定义是什么”最终定义成“首屏 2 秒内出数据滚动不丢帧”这就变得可执行了。第三组是约束与禁忌问题。核心是“哪些不能碰”有没有绝对不能动的东西老的存量数据要兼容吗性能上有没有底线权限上有没有要求有没有合规红线这些问题往往最容易被忽略却也最致命。你让 AI 写了一个批量删除功能需求说“能删就行”结果没确认“只能删自己创建的记录”AI 写出来的代码就是把整张表的数据全清了。这类事故不是 AI 的锅是烤箱没预热就扔食材。2.3 把“烤问”结果变成 AI 看得懂的需求卡Grill-Me 问了半天不能只在会议上痛快一下就结束必须把结论落成文字最好是 AI 能直接消费的短文本。我不建议写大篇幅的需求文档那会拖慢节奏也容易让团队进入“写文档交差”的应付状态。我更推荐一张“需求卡”几百字以内包含角色、输入、处理、输出、异常、验收标准这几块。举个实例。某项目原需求是“做个用户反馈功能用户能提交意见后台能看”。经过 Grill-Me 之后需求卡变成了角色登录用户、运营管理员。输入用户选择反馈类型bug/建议/投诉填写文字内容可附带一张最多 5MB 的图片。处理提交后生成工单状态为“待处理”运营认领后变“处理中”回复后变“已关闭”超过 48 小时没人认领自动升级提醒。输出用户端能看到处理状态和回复内容运营端能看到列表、筛选和回复入口。异常图片上传失败时不允许提交工单关闭后用户不能再回复。验收用户成功提交后 10 秒内能在列表看到工单运营回复后用户端 5 秒内可见。把这样的需求卡丢给 AI写出来的代码质量完全不一样。它不需要脑补只需要照着翻译成实现。我实测下来这种几百字的需求卡对 AI 编程提示词的价值比你在提示词里写“请你当一个资深工程师”有用得多。顺便说一句Grill-Me 里 AI 也不是只能被动接收你完全可以把上面三组问题丢给 AI让它扮演一个刁钻的产品经理帮你生成你没想过的边角问题。这时候 AI 的角色是“提问外挂”而不是“代码苦力”。3. BFS用广度优先把需求和任务摊开别让 AI 掉进“看起来对的”坑3.1 从“深度优先的手痒”到“广度优先的扫雷”人拿到需求后的自然倾向是什么是立刻找一条主线比如“登录注册”这个功能马上就想到“用户输入账号密码校验通过进入首页”然后一头扎进去让 AI 把这条链路写出来。我把这种习惯叫“深度优先手痒”主路径跑通了人就兴奋了觉得自己已经做完了百分之八十。但在真实工程里主线只是水面上的浮标水下全是分支和边界。BFS也就是广度优先搜索是图论里的经典遍历算法核心是按层推进先把当前层的所有节点访问完再进入下一层。我把它借用到需求梳理上理由很简单需求之间往往不是一条直线而是一张网有节点、有连线、有依赖。用深度优先去遍历这张网你会漏掉大量分支用广度优先逐层扫过去才能保证“该看的地方都看过”。你可以把 BFS 式需求梳理理解成扫雷下一铲子之前先把整片区域可能埋雷的位置都标出来再逐块小心排除。这样 AI 写出来的代码至少不会在边界条件上给你来一记“意外惊喜”。我们部门的几个项目里凡是“主流程能跑但一上线就崩”的回去复盘几乎都是 BFS 这一层没做扎实只写了“用户注册成功怎么办”没写“手机号已注册”“验证码错误”“接口超时”“重复提交”这些分支。3.2 BFS 需求梳理的三步操作列结果、找依赖、查连线具体操作我建议分三步走。第一步把所有用户能感知到的结果列出来这是整张需求图的“第零层”或“第一层”。不要急着写实现细节只问一个问题这个系统上线后用户能做什么、能看到什么。比如做一个“每周自动生成销售报表并邮件发送”的功能第一层节点至少有销售数据汇总、报表生成、邮件发送、发送历史记录、失败告警。第二步对每个结果问“达成它需要哪些前置条件”这就是进入下一层。比如“邮件发送”依赖收件人配置、SMTP 服务、发件人身份“报表生成”依赖数据仓库权限、汇总逻辑、展示模板。每追问一次就往下展开一层。一般展开两到三层就够了再深就变成详细设计文档会拖慢整体节奏。第三步检查节点之间的连线。有没有孤立节点比如“销售数据汇总”如果根本连不到“订单数据源”这个节点就是悬空的。有没有环A 依赖 B、B 又依赖 A这种循环依赖要在设计阶段就打掉。有没有权责不清的边比如“邮件发送”到底由报表服务触发还是由定时任务调度器触发需求卡里没写清AI 就会自由发挥。你在这一步把连线理顺等于提前替 AI 做了架构约束。3.3 BFS 展开时最爱漏的三类洞以及怎么堵使用 BFS 梳理需求时我总结出三类高发漏点。第一类是输入缺失需求只说“要生成报表”没说数据从哪来AI 就会很自然地写一个假数据源或者空数组。别笑这事真发生过AI 生成的神奇报表看起来图表齐全实际数据全是内置死的。第二类是中间态与异常分支“定时任务跑挂了怎么办”是频率最高的问题。需求方说“每天早上九点发报表”那 9 点整服务器宕机了这个任务还补不补要不要重试重试几次失败了告警给谁这些 BFS 清单上一个都不能少。第三类是权限与边界谁能看这张报表销售团队看自己的还是看全公司的邮件发送出去之后被人转发了怎么办这些听起来是业务问题但它们直接决定 AI 生成的代码里要写多少权限校验和审计逻辑。堵住这三类洞最好的办法就是把 BFS 展开结果变成一张可勾选的清单并且在进入编码前逐项打钩。比如下面这个简化版主链路定时触发 → 拉取数据 → 生成报表 → 发送邮件 → 记录日志异常链路数据拉取失败 → 重试 3 次 → 失败发告警到管理员边界链路收件人列表为空 → 跳过发送写日志邮件发送被反垃圾拦截 → 等待投递回执超时标记失败权限链路只有管理员能修改收件人列表销售组长只能看本组数据清单打不满我就拒绝让 AI 开始写。这不是流程洁癖是因为我清楚AI 不会替你发现这些遗漏它只会沿着你给的主线把所有没钉死的分支都变成“默认行为”而默认行为大概率不是业务想要的。4. AFKAsk-Feedback-Keep让 AI 的每一步都有验证回执4.1 AFK 是我在“人机协作”里的节奏定义问、反馈、留档Grill-Me 把需求问透了BFS 把场景摊开了接下来就要进入和 AI 的协作循环了。这个循环我称之为 AFK三个字母分别是 Ask、Feedback、Keep。Ask 是在动手之前先开口问清楚Feedback 是把 AI 的产出拿回给人做确认Keep 是把确认过的结论和改动永久留档。这一套合起来就是在 AI 写代码这件事上建立一个带反馈回执的闭环。标题里之所以用 AFK还有一个双关意思它本来是“Away From Keyboard”离开键盘。我越来越发现解決 AI 生成代码不准的问题很多时候不是坐在键盘前猛调提示词而是离开屏幕去找人问一句“这个状态到底谁触发”很多困惑问完人就消失了。所以 AFK 也提醒我们别一直埋头跟 AI 对话适时离开键盘去和真实业务碰撞反而更快。为什么需要这个循环因为 AI 生成内容的置信度再高也只能是“候选方案”不是“已验收方案”。尤其在业务逻辑复杂的场景AI 非常容易写出“局部正确、整体错误”的代码——语法没问题模块划分没问题但某个状态流转完全不符合业务。只有靠人来做 Feedback用 BFS 清单和 Grill-Me 需求卡去对照才能把这种错误揪出来。4.2 实操每个里程碑跑三轮 AFK而不是只跑一次我建议不是等 AI 全写完了再做一次反馈而是分里程碑跑三轮。第一轮在 AI 给出实现方案或者伪代码时人就介入做逻辑走查只看思路不看语法。你要检查的是它打算怎么拆模块、数据从哪来、异常怎么处理。这一轮发现问题改提示词的成本最低。第二轮AI 产出完整代码或关键代码块后人按 BFS 清单和验收标准逐项跑测试。不要只看“主流程能不能通”要把每一个分支节点都验证。比如“邮件发送失败”这个分支配置一个错误的 SMTP 地址看它是不是真的走了告警逻辑。AI 写代码有一个特点如果你不测它它永远觉得自己很完美。第三轮把改好并通过验证的版本和需求文档对照一遍同步更新 Keep 档案。这轮的意义是归档这次代码为什么这么写当时确认了哪些取舍下次再让 AI 改这个功能直接把 Keep 档案丢给它它就不会再把“已确认的边界”推翻重来。三轮下来每一个需求变更都经过“问清楚 → 验清楚 → 存清楚”的循环需求闭环才算真正闭合。4.3 Keep 档案怎么写才不累以及它对 AI 编程的复利效应很多团队听到“留档”就头疼怕变成写文档写到手断。我的经验是坚决不做冗长记录只在变更时写而且只写五样东西一句话需求、Grill-Me 的结论要点、BFS 确认过的场景清单、代码位置或实现说明、已知取舍。下面是一个简化的 Keep 档案示例一句话需求每周一上午 9 点向运营组邮箱发送上周销售汇总报表。Grill-Me 结论收件人固定为指定邮箱组报表统计维度按产品线分组不做历史回测。BFS 场景主链路、数据拉取失败重试、邮件投递失败告警、收件人为空跳过。实现说明代码在 service/report_weekly.py由 cron 触发使用 SMTP 服务发送。已知取舍不处理跨时区问题所有时间统一使用服务器本地时区。你看一共就几行。但它的复利效应非常明显下次需求变更时你把这段 Keep 档案连同一个新问题丢给 AI它的回答会稳很多因为 AI 终于有了上下文锚点不需要靠猜。我甚至会把 Keep 档案当作 AI 编程提示词的基础模板先贴档案再贴新的变更要求这个习惯让 AI 生成代码的一次通过率提高不少。说到底AFK 不是给 AI 上枷锁而是给人类自己提个醒我们才是要对结果负责的人。AI 提供速度人提供方向而 AFK 就是保证方向和速度不跑偏的校准机制。5. 常见问题与排查实录这套流程真正落地时会遇到的坎5.1 需求方说“你不用问AI 都知道”怎么办推行 Grill-Me 时最常碰见的抗拒就是需求方说“这有什么好问的你直接把需求丢给 AI它能理解”。这种时候你别硬顶把提问变成选择题就好。比如不要说“你确认一下报表需不需要历史数据”而是问“报表这里有两个选项A 是只展示本周数据B 是支持选任意时间范围回看你选哪个”。需求方在选择题上的配合度远高于开放式问答。我踩过的坑是有一次没坚持问“报表要不要支持回测”结果 AI 按纯实时方式实现后来运营想追溯上周为什么数据异常发现根本无据可查只好全部重写。从那以后我对“这个不用管”保持高度警惕越是被说“不用管”的点越要问到底。5.2 BFS 清单都打钩了AI 写出来还是不对这类问题排查下来根源往往不是清单漏了而是清单上的节点写得太抽象。比如你写“邮件能正确发送”AI 认为只要调用 smtplib 发出去就算正确但你的真实意图是“必须收到邮件服务商的投递回执并且在失败时保留草稿、触发告警”。这两种验收标准写出来的代码天差地别。所以我后来强迫自己把 BFS 节点改成“可观察的事件”而不是名词。不是写“邮件发送”而是写“邮件送达后返回投递状态投递失败时草稿存留并通知管理员”。名词只能描述状态事件才能定义验证动作。需求卡里每一个节点都应该能在测试中明确判断对错。5.3 AFK 循环太慢团队说“流程绑架开发”AFK 确实是会增加一些步骤所以做的时候要分轻重。大功能、高风险模块完整走三轮小改动、纯样式调整只做 Ask 和快速 Feedback 就行。比如改个按钮文案你问一句“改哪里的按钮、文案是什么、影响哪些页面”就完了完全不用写 Keep 档案。团队真正反感的是不分场景、一律走全套流程。灵活性很重要AFK 的目的是承接需求和验证结果不是制造无意义的负担。还有一个新趋势就是 AI Agent 越来越普及很多人希望整个需求闭环直接交给 AI 智能体去执行。我的观点是即便 Agent 能自动调用工具、自动写代码跑测试人也应该在“需求方向”和“验收规则”这两个环节保留话语权。Agent 可以帮你执行 BFS 检查可以帮你整理 Grill-Me 问题清单甚至能自动生成 Keep 草稿但“什么是对”这个判断必须有人拍板。需求闭环不是用来约束 AI 的它是保证 AI 始终做有价值的事情的护栏。写在最后我实际用下来的几个体会这套“Grill-Me、BFS、AFK”组合拳听起来像三个很酷的术语实际执行起来没有那么复杂核心就一句话在 AI 写代码之前把需求从模糊变成清晰从直觉变成可验证清单然后让 AI 的每一次输出都经过人的确认并留下记录。我个人最大的一个体会是真正省下的时间并不来自 AI 生成代码那一下而是来自“想清楚之后再让 AI 动手”这一步。之前我总觉得写代码慢是速度问题后来发现大部分浪费都出在“需求没有闭环就贸然编码”上。最后分享一个小技巧也是我几乎每天在用的每次让 AI 写代码之前别急着粘贴原始需求先把 Grill-Me 结论和 BFS 清单整理成一段“任务卡”放进新对话的最前面。你不需要用什么花哨提示词就是把角色、输入、处理、输出、异常、验收标准写清楚然后再说“请基于以上需求实现”。实测下来AI 的返工次数会大幅下降那个“看起来对但实际跑不通”的情况会少很多。祝你也早日把 AI 写代码从碰运气变成真正的工程能力。