前几天有个朋友兴冲冲给我看他的“AI编程成果”他让AI写了个爬虫脚本抓某个电商网站的商品数据AI两分钟生成了完整代码他特别得意。结果我一看URL解析用的是另一个网站的规则字段名全靠猜连请求头里的Referer都是从别处抄的。他满脸疑惑“AI写的啊怎么还能错成这样”我回了他一句“不是AI错了是你压根没告诉它你要爬哪个网站、字段从哪来、失败的时候怎么办。”这个场景太典型了。现在AI写代码的门槛低到离谱GitHub Copilot、Claude、Codex这些工具基本是“你说一句它写十句”。但恰恰因为生成速度太快很多人省掉了写代码之前最不该省的那一步——把需求想清楚。你让AI帮你盖楼结果你自己都说不清要盖几层、住几个人、要不要电梯AI当然能给你盖出来只是盖完你大概率想拆。这篇东西想聊的就是怎么在“急着让AI写代码”之前用一套可复用的方法把需求彻底锁死。核心就三个词Grill-Me、BFS、AFK。Grill-Me是需求拷问阶段BFS是需求拆解阶段AFK是异步验证阶段三者合起来形成一个完整的需求闭环。这套流程适合所有用AI辅助写代码的人不管你是独立开发者、团队里的后端还是刚学会用AI写SQL的分析师都应该在你把需求丢给AI之前先把它烤熟了再下锅。1. 别急着让AI写代码先看清“AI加速器”为什么跑偏1.1 代码生成成本趋近于零但需求错误的成本反而变高了有个现象特别反直觉AI让代码生成变得又快又便宜但需求错了的代价却一点没变小甚至更大了。原因很简单。以前是自己搬砖搬得慢你边搬边想边调整错误在早期就暴露了。现在是开着铲车搬砖搬得飞快但如果你地基画错了线铲车飞快的后果不是效率高而是错得更彻底。我见过不少团队原来一个功能要做一周现在AI半小时出代码但接下来的两周全在改需求偏差界面不是用户想要的、逻辑边界不对、异常处理是AI自己脑补的。代码改了三版AI改得不耐烦人也改得怀疑人生。我以前写代码是“边写边想”写到哪想到哪好像也没出过什么大乱子。但用AI之后我发现这套思路完全失效了。AI不会像人一样做一半停下来问你它会非常顺畅地把你的模糊指令“脑补”成一个看似完整的方案。等到你review的时候问题像地雷一样炸开。所以现在我的原则很明确AI生成代码之前必须先把需求变成一份能逐条打勾的清单而不是一句两句话。1.2 “迎合性幻觉”AI不是你肚子里的蛔虫它是你嘴边的应声虫很多人没意识到大模型生成代码时有一种天然的倾向——迎合你的表述。你说“帮我做个导出Excel的功能”它不会问你导出什么格式、多少数据量、按什么规则排序、要不要样式而是会默认挑一个最“常规”的实现全部数据一次性导出列名用数据库字段格式用最简单的xlsx库默认配置。写得特别顺错得也特别顺。这就引出了我在前面提到的“迎合性幻觉”需求越模糊AI越不会让你觉得它写不出来它只会让你觉得“它怎么什么都会”。但这个“会”是它在用一种极其自信的口吻对每一个不确定的细节做假设。更坑的是它不会主动标出来“这里我不确定我替你猜了”。它只会悄悄在代码里写一个# TODO: handle edge cases然后继续往下写。换句话说AI在需求不明确的时候是拿着你的钱替你输钱你还得夸它牌技好。如果你不给它明确的边界、输入输出、验收标准它就会用它的“统计最可能”来补位。所以让AI写代码之前你至少得把那些会导致返工的问题问清楚这正是Grill-Me要做的事。1.3 传统需求分析被跳过不是因为它不重要我知道有人会说“这还用你说需求分析谁不知道啊。”但现实是很多快节奏团队已经把需求分析简化成了口头一句“你帮我做个XX”因为AI让改代码的成本变低了大家本能地觉得“反正可以改”。这个逻辑初看没问题但你仔细算一笔账改代码的成本降低不代表重新对齐需求的沟通成本也降低了。你让AI改五遍每遍它都在一个新的方向上去猜你需要反复看代码、反复测试、反复让它解释“你为什么这么写”。最后你会发现沟通成本全跑到review环节去了白白浪费了AI本来该帮你省出的时间。所以我更愿意把需求澄清的步骤前置让AI生成前就拿到一份无歧义的需求说明书。这不是闲得慌而是把成本从“生成后反复改”转移到了“生成前想清楚”这是整体上收益最大的路径。1.4 一套可靠的需求闭环由三个动作组成我这两年经过很多次试错最后沉淀出一套固定流程就是标题里那三个词Grill-Me用结构化拷问把模糊的需求逼出原形相当于“需求预清洗”。BFS把需求按广度优先展开成一颗“任务树”避免漏模块、避免局部过深。AFK离开键盘、异步评审让AI的每轮输出都有人脑在冷静状态下验收形成闭环。这套流程不是三个孤立步骤而是一个循环Grill-Me澄清出的内容喂给BFS拆解BFS拆出来的任务清单和验收标准交给AI产出代码AFK阶段用验收标准逐条检查发现的问题再回流到Grill-Me启动新一轮澄清。这就是我标题里说的“需求闭环”。2. Grill-Me像烤问一样把模糊需求逼出原形2.1 Grill-Me是什么不是提问是拷问Grill在英文里有两个意思一个是“烤”另一个是“盘问、逼问”。“Grill-Me”这个说法源自我自己的习惯——在让AI干活前先把自己按在椅子上往前烤一遍逼着我把需求里的每一个含糊点都说清楚。名字听起来像开玩笑但它解决的是真实痛点多数人不是没需求而是需求太稀稠度不够直接喂给AI会被兑水。我自己总结下来Grill-Me的核心不是“随便问几个问题”而是用一套固定维度去扫描需求项目任何角落都不放过。这套维度我整理成了九个问题域下面详细说。2.2 九个维度的拷问清单我把每次Grill-Me阶段会问的问题整理成了一张表基本可以直接抄维度关键问题目标层这个东西给谁用的解决什么痛点怎么衡量成功用户层使用者的技术水平如何在什么设备上用操作频率高吗边界层哪些场景明确不做什么情况下停止支持输入输出层输入是什么格式输出是什么格式中间有没有人工干预数据层数据来源哪里数据量级多大有没有隐私或合规要求交互层是纯API、命令行还是要有GUI有多少个页面/命令性能层响应时间要求并发量可容忍的故障时间技术约束现有技术栈部署环境有没有许可证/平台限制验收标准什么算“做完了”谁来验收验收需要怎样的证据这九个维度不是每回都要走全。一些生命周期很短的一次性脚本你只需要问目标、输入输出、验收标准就够了但如果是核心业务模块我建议一个都别漏。2.3 三轮问答的实操节奏你不可能一口气把所有问题问完也千万别在需求方或者你自己的脑子里还没进入状态的时候就开始追问。我推荐的节奏是三轮问答第一轮30分钟粗问只问目标层、用户层、边界层、验收标准。这四类问题决定了整个项目的骨架确认这四件事不会跑偏后面才有意义。第二轮15-20分钟细问带着第一轮的答案去抠输入输出、数据量级、性能要求、技术约束。这一轮解决的是“怎么实现”层面的确定性。第三轮10分钟挑战找一个“反面对手”来质疑需求——可以是团队同事也可以是你自己换个视角。逐条问“这个功能真的需要做吗”“这个边界是不是太大了”“验收标准能不能量化”这一步是逼你把含糊的表述变成可测量的事实。三轮下来如果还是有一些回答是“不知道”那也没关系把“不知道”本身当作一个任务去处理——先调研清楚再开工。最忌讳的是直接拿“不知道”去让AI猜。2.4 让AI当“拷问官”可直接套用的提示词Grill-Me不是只能靠人来做。你完全可以拿AI当“拷问官”帮你把脑子里那个模糊的想法像挤牙膏一样挤干净。我常用的提示词模板长这样你是一名资深需求分析师。我要开发一个工具原始想法如下 【用一到两句话描述你的想法】 请按照以下九个维度逐条向我提问 目标、用户、边界、输入输出、数据、交互、性能、技术约束、验收标准。 每一轮你只问一个问题等我把一个答案补全后你记录下来再问下一个。 当我无法回答某个问题时请你标记为“待调研”并继续下一个问题。 全部问题完成后请把这次拷问的结果整理成一份结构化需求说明书。实测下来AI当拷问官最大的好处是它不会嫌你烦而且它会基于前一轮的回答动态调整后续问题。但有一点要提醒它偶尔会把问题问得过于理想化比如问你“有没有考虑分布式部署”而你明明只是写个本地脚本。这时候你要有自己的判断别被AI带着往复杂了跑。2.5 什么时候该停下来Grill-Me阶段最容易出现的毛病是问过头。需求澄清不是越细越好它有一个投入产出比的拐点。我记得自己有次给一个小工具做Grill-Me花了整整一天把AI生成的“可扩展架构”都考虑进去了结果那工具最后只用了两次。所以我给自己定了一条线**当一个需求的改动风险和生命周期可以被明确评估时就可以停止了。**普通脚本问清楚目标、输入输出、验收标准就收工长生命周期项目要多问数据层、性能层和技术约束风险高、涉及资金或用户隐私的项目还要额外把合规、权限、审计这类问题加进清单。3. BFS 拆解按广度优先展开需求树而不是一头扎进细节3.1 为什么是BFS而不是DFSGrill-Me解决了“需求是什么”的问题接下来要解决“需求拆成什么颗粒度去喂给AI”。这里我用的是算法里的BFS概念——广度优先搜索Breadth-First Search。如果你写过图论相关代码对BFS和DFS都不陌生。BFS是一层层往外扩先把同一层的节点全部遍历完再进入下一层DFS是一路走到底撞墙了再回头。放在需求拆解里BFS的思路是先覆盖所有核心模块再逐一加深每个模块的实际细节而不是像DFS那样揪住第一个模块不放做到一半才发现另一个模块完全没规划。很多人让AI写代码时用的其实是DFS的思路想到登录功能就拼命细化登录的验证码、记住密码、第三方登录……等AI把登录页写得漂漂亮亮你才发现数据层、权限层、日志层全都还没想代码基础架构是塌的。DFS的问题在于AI的注意力是有限的它在局部投入大量token之后对其他模块的覆盖度必然下降最终产出的代码“局部精美、整体残缺”。BFS可以强制你和AI都先看到全局再分别深入。3.2 一棵需求树长什么样以“团队会议纪要工具”为例BFS拆解出来的需求树大概是这样的根节点将团队会议录音/转写文本转换成结构化会议纪要 ├─ 第二层转写文本解析 │ ├─ 第三层识别发言者 │ ├─ 第三层提取发言时间段 │ └─ 第三层分段与去噪 ├─ 第二层纪要内容结构化 │ ├─ 第三层提取会议决议 │ ├─ 第三层提取待办事项 │ │ └─ 第四层待办归属人识别 │ │ └─ 第四层截止时间解析 │ ├─ 第三层生成摘要 │ └─ 第三层格式化Markdown输出 ├─ 第二层任务分发 │ ├─ 第三层按人拆分待办 │ └─ 第三层生成通知内容 └─ 第二层权限与历史版本 ├─ 第三层历史纪要存储 └─ 第三层访问权限控制注意第二层的四个模块是所有需求的基础覆盖必须全部出现第三层开始细化但也没必要一开始就把第四层写得很全。BFS的拆解原则是先把树的每一层列完整再看哪个分支值得加深。3.3 把需求树分批发给AI的正确姿势需求树拆好之后不要一次性全塞给AI生成代码。原因有两个一是上下文窗口有限塞太多内容AI会“遗忘”前面的关键约束二是如果让AI一次性把整棵树都实现出来它会为了“看起来完整”而牺牲质量每个模块都是浅尝辄止。我的做法是分批次第一批把根目标和第二层模块清单发给AI让AI产出项目的整体骨架包括目录结构、关键接口定义、数据模型。这时候目标是打通全局。第二批把其中一个第二层模块连同其第三层子任务单独发给AI做深入实现。一个批次只处理一个子树。第三批前两批完成并验收后再处理下一个子树。这个分批策略本质上就是“BFS的层级化”先全局骨架再局部深入。相比一次梭哈分批的好处是你可以在每一批之间插入人工review把错误阻断在早期。3.4 让AI帮你生成BFS树的提示词模板Grill-Me阶段得到的结构化需求说明可以直接喂给AI让它帮你生成需求树。我用的提示词模板下面是经过澄清后的需求说明书 【粘贴Grill-Me产出的需求说明书】 请你根据这份需求说明书用BFS的思路把它拆解成一棵需求树。 要求 1. 第一层是根目标。 2. 第二层列出所有核心功能模块必须覆盖完整不能遗漏。 3. 第三层开始细化每个模块的具体任务。 4. 只拆解到任务级别不要写代码。 5. 每个叶子节点必须附带一个“验收条件”用一句话描述怎么算完成。 6. 输出格式用缩进或Markdown列表展示树形结构。这一步输出的需求树我会人工做一次裁剪——去掉AI自己脑补出来的、实际需求里不需要的功能。AI特别容易在需求树里顺手加一些“日志系统”“配置中心”之类的东西你要是有节制地保留能省很多不必要的实现成本。3.5 拆分粒度的判断红线需求树拆到多细才算合适我常用的判断标准是**一个叶子节点的工作量应该控制在半天到两天之内并且它必须能被单独验收。**如果一个任务需要三天以上才能完成说明它拆得还不够细如果一个任务五分钟就能完成说明拆过头了合并进去更合理。另外还有一个反直觉的点不要平均用力。技术风险高的部分比如调用第三方API、并发处理、业务价值高的部分比如核心算法模块当然值得拆得更细但那些低风险的CRUD接口留到后面再做也行。BFS的精神是“覆盖完整”不是“每个分支都等深”。4. AFK 机制离开键盘用异步闭环锁死需求边界4.1 AFK到底在说什么AFK是网络游戏里常用的缩写全称是“Away From Keyboard”意思是离开键盘。放在AI编程工作流里我把它扩展成一种机制在AI生成代码和人工反馈之间插入一段物理上和注意力上的“离线时间”让人从连续的编码对话中抽离出来用旁观者视角去评审和验收。为什么需要这么个听起来有点玄的东西因为人在连续跟AI对话时特别容易被AI的节奏带跑。你让它改一行代码它顺手改了另外三处你说“这个改得不对”它立刻道歉并且给出一个新版本。这个循环特别丝滑丝滑到你会忘记自己本来要验证什么——你被卷入了AI的“局部优化”漩涡。4.2 为什么连续编码会“被带偏”我有个特别深刻的教训。有次让AI帮我重构一个函数我盯着屏幕连续改了四轮每轮都觉得“这版差不多了”但第二天重新看代码的时候发现那个函数被AI改成了一坨无比精简但没人能看懂的“聪明代码”而且它偷偷把错误处理逻辑换了个方式我的原始验收条件里有一条“出错时必须保留原始异常信息”它没满足我居然没发现。这就是连续编码的代价你的注意力被近因效应支配每轮只看到AI改了哪里反而看不到总体的需求边界是否被跨越。AFK的意义就是强制打断这种惯性让人退后一步重新用需求树和验收标准来审视代码。4.3 异步反馈闭环的具体玩法AFK不是叫你发呆而是有具体的操作玩法。我常用的几种间隔评审法AI生成代码后先不着急改离开屏幕喝口水、走两圈至少间隔10分钟再回来看。这10分钟能让你从“写代码模式”切到“审代码模式”看问题的角度完全不一样。AI互审法把你的需求树和AI刚生成的代码一起贴给另一个AI实例或者同一个AI的新对话让它扮演“验收官”根据验收条件逐条打分。我实测过AI互审能抓出很多自己没注意到的逻辑漏洞因为AI阅读长文本时比人更耐心。Checklist回流法反馈给主AI的信息不要用聊天式的自然语言而是用一份可勾选的Checklist。比如本次评审结果 - [通过] 输入解析支持TXT格式UTF-8编码 - [未通过] 时间范围过滤必须支持“本周”“上周”两个预设区间 - [未通过] 输出格式要求包含“项目名”字段当前版本缺失 - [新增需求] 如果输入文件为空直接输出提示信息并退出 请根据以上清单逐项修改不要改清单之外的地方。这个做法的好处是限制AI的修改范围避免它顺手改一堆不该动的地方。ChatGPT和Claude这类模型在收到“不要改清单之外的地方”时行为会比自由对话更可控。这条经验我反复验证过很多次。4.4 需求版本递增与闭环回流AFK不仅仅是评审AI的代码它还要完成一个关键动作**把评审中发现的问题回流到需求文档形成需求版本2。**如果你只把反馈直接丢给AI修改那改完这轮下一轮你可能又忘了当初为什么要改。我习惯在项目中维护一个REQUIREMENTS.md文件每次AFK评审后把新增需求、变更的需求、确认不变的需求都更新进这个文件。这样整个团队都有一个“单一事实来源”AI生成的任何代码都可以追溯到需求文档的某个版本。闭环的完整链路是Grill-Me澄清 → BFS拆解 → AI编码 → AFK评审 → 需求更新 → 再次编码。这个循环跑起来之后你会发现需求变更不再是可怕的事情因为它总能被快速追踪和回滚而不会变成一段“只有AI记得为什么这么改”的烂账。4.5 AFK的落地工具清单最后说一下工具层面的搭配。AFK的效果不取决于你用哪个AI写代码而取决于你怎么组织评审和反馈项目文档一个小项目的REQUIREMENTS.md 一个CHECKLIST.md就够了不用上什么重型知识库。代码托管平台GitHub/GitLab的PR review天然支持“人离开代码、异步评审”的工作流让AI在一个分支上干活人工另开时间review这就是最原生的AFK。对话结构给AI的每一轮反馈保持结构化别用口语化的“这个不对”改成“这个模块不满足验收条件X具体原因是……”。5. 一次完整实战从“做个工具”到能交付的代码5.1 原始想法的起点为了让你看清这套流程怎么串起来我拿一个真实的例子走一遍。我个人的需求非常典型每周要写工作周报但聊天的记录分散在微信、企业IM里复制粘贴特别痛苦。所以我最初的原始想法就是一句话“我想做个工具把我的微信聊天记录转成周报这样周一早上能快一点。”就这么一句话如果直接丢给AI它大概率会给你写一个从微信导出聊天记录的爬虫或者塞给你一堆你用不上的网页抓包方案。所以我没有急着让它写代码而是先走Grill-Me。5.2 Grill-Me阶段的问答产出我按三轮回合拷问自己得到的结果大概是这样维度澄清结果目标每周一花10分钟内生成上周工作周报减少手工整理时间用户只有我自己后端工程师懂命令行边界不做图片、语音、视频消息处理不做自动发送周报不处理敏感词输入从聊天工具导出的TXT文件UTF-8编码按天分段输出一份Markdown周报包含本周重点项目、会议、待办、风险数据聊天记录本地存储不涉及隐私泄露问题只处理工作群和本人的消息交互命令行工具输入文件路径输出Markdown文件性能文件大小在10MB以内处理时间3秒内能跑在两年前的MacBook上验收能正确提取出本人发送的与项目相关的消息并按照日期和项目分组输出格式符合模板注意“边界层”里我特意加了“不做图片语音处理”这就是在约束AI不要往无关方向发挥。5.3 BFS阶段的拆解产出拿着上面的澄清结果我让AI生成了一颗需求树人工裁剪后如下根目标本地命令行工具将聊天记录转换成周报 ├─ 第二层聊天记录解析 │ ├─ 第三层识别发送者区分本人/同事 │ ├─ 第三层解析时间戳并按天分组 │ └─ 第三层过滤系统消息和红包消息 ├─ 第二层项目相关消息提取 │ ├─ 第三层基于关键词项目名/会议/延期过滤 │ └─ 第三层按项目名聚类 ├─ 第二层周报编排 │ ├─ 第三层把聚类结果按日期排序 │ ├─ 第三层生成“本周进展/待办/风险”三段落 │ └─ 第三层输出为Markdown格式 └─ 第二层命令行交互 ├─ 第三层接收输入文件路径参数 ├─ 第三层生成输出文件并打印路径 └─ 第三层文件不存在时给出明确报错每个叶子节点都附了验收条件比如“关键词过滤必须能识别至少5个预定义项目关键词”“时间分组同一天的消息必须归到同一天”。跟最初那句话相比这颗需求树已经是完全不同的颗粒度。5.4 给AI编码的输入包我没有一上来就全让AI实现。第一轮我只把根目标和四个第二层模块的名称、每个模块的第三层任务清单发给了AI要求它先产出项目骨架目录结构、模块间接口、数据流。这轮不涉及具体功能只要能跑通一个打印“hello”的框架都行。第二轮我挑出“聊天记录解析”这个第三层子树连同它的验收条件单独发给AI让它实现完整的解析逻辑。第三轮、第四轮再分别处理“项目相关消息提取”和“周报编排”。每轮之间都执行AFK评审把通过的、没通过的做成Checklist回填给AI。5.5 三轮迭代的实测结果实测下来第一轮AI生成的骨架覆盖了全部四个模块但正如预期没有一个模块真正能跑这是BFS设计下很正常的现象。第二轮它把“聊天记录解析”做得不错但我验收时发现“时间戳解析”只支持了2025-01-06 10:30:00这种单一格式而我导出的文件里还有1月6日10:30这种中文格式我把它写进Checklist回填给AI第三轮它就补上了。到第五轮整个工具已经能在Mac上正常跑通处理一份8MB的聊天记录耗时约两秒周报输出符合模板。整个过程大约三个小时其中真正花在改代码上的时间只占一小部分大量时间花在“确认需求边界”“补充验收条件”和“离线评审”上。但结果是这个工具我到现在已经用了快半年几乎没有返工。5.6 一次完整提示词模板参考你可以直接把这个模板存下来每次让AI写代码前填一遍任务请实现【项目名称】。 ## 需求背景 用两三句话说明给谁用、解决什么问题 ## 输入 - 输入文件格式xxx - 数据量级xxx - 环境约束xxx ## 输出 - 输出格式xxx - 质量验收标准 1. xxx 2. xxx ## 明确不做的事 - 不支持xxx - 不处理xxx ## 拆解需求树 BFS格式第二层模块列表 每个模块的第三层任务 叶子节点验收条件 ## 本次实现范围 只实现以上需求树的哪一部分不要越界修改其他模块把这份输入包给AI它会比直接说“帮我做个工具”靠谱太多。我甚至发现AI在收到这种结构化输入之后生成的代码结构也明显更清晰因为它知道边界在哪不靠猜来补全。6. 我踩过的坑需求闭环里最常见的三个失灵场景6.1 坑1Grill-Me问了一堆问题需求方说“我也不知道”Grill-Me阶段最尴尬的场景就是你问了一圈对方或者自己回答“我也不确定”。你感觉像审讯时犯人装死怎么都撬不开。早期的我一遇到这种回答就会硬着头皮继续问最后问出来的要么是空话要么是把“不知道”包装成“你看着办”。后来我换了个思路**“不知道”本身就是一个待办任务而不是一个可以跳过的空档。**谁不知道谁就该去调研清楚再回来。比如做周报工具时你问“导出的聊天记录格式是什么”如果不知道那第一件事是先导出一次看看格式而不是猜。实际上AI也能帮你做调研你可以让AI先查一下“市面上有哪些聊天记录导出格式”拿着调研结果再来反哺需求。把“不知道”转化为“需要调研后确认”的动作Grill-Me才能真正闭环。6.2 坑2需求树太大AI上下文窗口装不下第二常见的失灵场景是把整颗需求树一次丢给AI后它写到第三个模块时忘了第一个模块的约定。这不是模型笨而是上下文窗口和信息密度打架需求树叶子节点一多token占满AI的注意力被稀释。我踩过的一个具体案例是同一个项目里让AI同时实现“用户登录”和“权限管理”两个子树它在第二个子树里直接写死了默认角色根本没引用前面定义好的权限模型。后来我只能回到BFS分批策略**一次只让AI处理一个子树并先在一个总控文档里固定好全局接口约定。**每次发任务时把全局接口约定贴在每批任务的前面提醒AI不要破坏已有的约定。这个操作成本不高但能救回很多返工时间。问题现象根因解决方式AI写到后文忘记前文约定上下文过长注意力稀释分批任务每批只处理一个子树并重申全局接口多个批次之间接口对不上缺少单一事实来源维护REQUIREMENTS.md和INTERFACE.md每批共享AI改A模块殃及B模块聊天式反馈没有边界用Checklist限死修改范围禁止越界修改6.3 坑3AFK评审做着做着就变成了在线聊天理论上AFK要求离线评审但实操中人的定力没有你以为的那么强。我经常碰到这样的场景评审到一半忍不住想“要不我直接改一下试试”于是打开编辑器手动补了一行代码。这一补评审的专注力全没了后面几个模块的验收直接走马观花。后来我把AFK做成了一道物理约束**评审阶段只允许打开需求文档和代码不允许打开编辑器的实时调试模式。**发现问题直接写进Checklist不顺手改。等你把Checklist填完再决定是自己改还是交给AI改。这个小小的流程约束直接把评审质量拉高了一个档次。6.4 哪些场景可以跳过这套流程我必须诚实地讲不是所有代码都要走这套闭环。如果是一次性脚本、原型验证、两周后就要扔掉的Demo你完全可以直接让AI帮你写写得再烂都行。因为这类代码生命周期太短“返工”这个成本根本不存在用Grill-Me和AFK反而是在浪费生命。但一旦代码要进主干仓库、要被别人维护、要在生产环境跑那对不起请老老实实走完这套流程。我见过太多“先快速写出来之后有空再重构”的项目最后那个“有空”从来没来过留下的全是一堆看得懂但不敢动的AI生成代码。6.5 让这套流程不“繁”的小技巧最后分享几个让我坚持用下来的小技巧把Grill-Me的九大维度做成模板每次填写比自己从零组织问题快得多。让AI帮你生成BFS树你来裁剪而不是从零画树。把Checklist存成Markdown文件每次AFK评审后批量更新形成可追溯的历史记录。给自己设一个“每轮AFK至少隔10分钟”的约束哪怕只是去接杯水也能获得更冷静的判断力。我自己现在的固定节奏是每天上午花15到20分钟做Grill-Me和BFS拆解下午让AI按批次写代码傍晚做AFK评审和Checklist回填。坚持了两周之后最直观的感受是每天“跟AI来回扯皮”的时间大大缩短因为需求边界清楚AI的产出不再需要反复横跳。当然这套流程不能保证AI写的代码100%没有bug但它能保证在错误的道路上走得足够慢在正确的道路上走得足够快。这年头AI写代码早就不是什么新鲜事真正拉开差距的是你喂给AI的需求质量是你在按下“生成”之前有没有把问题烤熟、剖开、晾凉。