开头我先讲一个让人血压升高的场景：你把需求栏里那段话复制给 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. AFK：Ask-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 写代码，从碰运气变成真正的工程能力。
