Codex × Grill Me：让AI写代码前先“拷问”需求，避免翻车

给 Codex 扔一句“帮我写个导出功能”然后看它埋头干了半小时交出来一个连字段名都对不上的东西——这种场景我猜你不陌生。问题不在于 Codex 蠢也不在于你运气差而在于绝大多数人把 AI 编程工具当成了一个“你说什么它做什么”的搜索引擎忘了 AI 本质上是个“擅长把模糊需求做出来也擅长把模糊需求做歪”的家伙。我试过各种办法来规避这个问题直到我在开发者社区里看到一个叫 Grill Me 的小工具思路才意识到解法根本不在代码阶段而在编码开始之前让 AI 先反过来拷问你的需求胃口再大的需求也得先过一遍审问名单等它把该问的都问完了你这边几千字的开发任务简报也成型了。今天就把这套“Codex × Grill Me”的组合拳从头到尾拆给你看包括它为什么有效、怎么落地、以及我在真实项目里踩过的那些坑。1. 先想清楚一件事AI 写代码翻车多半是需求没说人话1.1 模糊需求是怎么把 Codex 带沟里的先看一个我上周真实遇到的需求原话只有一句“帮我在后台加个导出 Excel 的功能。”听起来很简单对吧但这句话到了 Codex 手里会变成无数个问题导出哪张表是整张表还是筛选后的结果Excel 要 xlsx 还是兼容老版本的 xls字段名跟接口返回的一致还是跟数据库列名一致权限上谁允许导出导出大文件是同步等结果还是后台异步生成导出失败要不要给用户提示这些问题的答案你脑子里可能多少有点想法但在初始提示词里一个都没写。Codex 只能靠“合理猜测”替你做决定而它的合理猜测大概率跟你的想法是两回事——因为代码这东西差一个字段都叫跑偏差一个格式更是直接完蛋。更麻烦的是大多数 AI 编程工具都有一种“顺杆爬”的特性你给了它一个不完整的方向它不会停下来问你而是会把所有未知量默认为最常见、最通用的那套方案。你要的是一个内网管理系统里的用户清单导出它可能给你默认成公开数据接口的导出你要的是增量数据带时间戳的导出它可能按全量快照来写。这不是模型能力不行而是它的训练目标就是“尽可能完成你给的指令”而不是“识别出你没有说清楚的事”。指望 AI 自己发现问题、主动确认在目前这个阶段依然不现实。1.2 Grill Me 的思路把“免责式追问”变成第一道工序社区里有一个流传度很高的思路叫 Grill Me直译过来就是“拷问我”。它其实不是某个特定产品而更像一套提示词策略加交互流程在你自己写的提示词里先明确告诉 AI“在动手做任何事之前你必须先以审问者的身份向我提问题”然后给它定义好提问的方向——比如业务目标、用户场景、边界条件、性能要求、技术约束、验收标准。AI 会基于这个“帽子”持续向你追问直到把需求里的坑几乎全部挖干净才进入真正的编码环节。我最初对这玩意的第一反应是不屑多问几轮问题不就是让模型多消耗几个 token 的仪式感吗但实测之后发现效果天差地别。一个被完整拷问过的需求交给 Codex 之后第一版可用的概率从我印象里的“三版里面能有一版勉强能跑”直接提升到“一次过 lint、二次过测试场景”。原因其实很好理解AI 编程工具最怕的不是程序员手写逻辑而是它得在巨大的不确定性里替你脑补。Grill Me 的整个流程本质上就是把“脑补空间”压缩到最小把本来该由你拍板的决策或者你压根不知道要做出的决策在动手前全部摆到台面上。而且 Grill Me 还有一个隐藏价值它能倒逼你说出你以为自己想清楚、其实根本没想过的东西。比如我那次“导出 Excel”被 AI 追问到“导出任务如果超过 10 万行怎么办”的时候我才意识到这个后台已经积累了三年数据一套默认的同步导出方案在真实数据量下面根本跑不动。这个坑要是等 Codex 写完再发现回头改的代价就不是几轮对话能兜住的了。2. Grill Me 到底是个什么东西原理、构成与为什么会有效2.1 工作流程拆解严格来说Grill Me 不是一个需要安装的软件而是一套可以被塞进任意支持多轮对话的 AI 工具里的“角色设定 提问协议”。我第一次拿到这个思路时把它的 message 拆开看过结构大概分四层角色声明告诉模型你现在是“需求拷问官”你的任务不是写代码而是把用户的含糊表述逼成清晰规格。提问范围定义列出必问的领域比如业务目标、非功能需求、现有系统约束、验收标准等。交互规则一次只问一个问题不要连环炮轰也别在拷问阶段就开始提解决方案。出口条件当所有关键维度都被覆盖后汇总一份结构化的需求确认书。这套东西放在 Codex 里怎么配合一个很自然的工作流就是分两个会话第一个会话里你贴入 Grill Me 的提示词然后扮演“被审问者”让 AI 一个问题一个问题地“烤”你等拷问回合结束你会得到一份完整的规格书。这份规格书再作为第二个会话的输入直接交给 Codex 去实现。两个会话之间是彼此隔离的好处是 Codex 不会在实现阶段反复被“你到底要什么”打断你的上下文也干干净净不会把一长串追问历史白白塞进实现窗口里。2.2 提问模板的底层逻辑封闭问题保底线开放问题挖边界如果你只是复制一份 Grill Me 的提示词然后坐等被问可能会发现第一批问题质量还行但越到后面越像是在凑数。为了让拷问更接近真实项目评审我会在提问范围里手动补充一些命中率极高的角度这里分享一组我长期在用的提纲目标问题封闭式这个功能的最终使用者是谁他们现在用的是什么工具和流程数据问题开放式导出/生成的数据来源是哪些表要不要包含关联数据时间范围是全部历史还是时间段筛选交互问题封闭式用户是点击按钮等结果还是要做一个任务中心随时查看进度环境问题封闭式这个功能跑在现有服务上还是需要独立的计算资源有没有部署频率限制失败问题开放式如果失败了用户能看到什么提示重试机制是自动的还是手动的验收问题封闭式你拿什么标准判断这个功能“能用”有没有已有的旧功能可以做行为对拍这个清单看起来废话连篇但很顶用。封闭问题保证你们在关键事实上达成一致开放问题则是给 AI 一条路径去深挖你在边界上的疏漏。你可以把这份提纲直接写进 Grill Me 的提示词里让它照着这个范围提问而不是让模型靠着训练数据里的“大概率”自己发挥。2.3 为什么它能在没写一行代码前就省时间要回答这个“为什么有效”得从 Codex 这类 Agent 型编码模型的运行机制说起。它的工作方式不是一次性吐完整个代码库而是像人类程序员一样边读你项目里的文件、边理解上下文再决定怎么改。这意味着它的每一次决策都建立在上下文窗口里呈现给你的代码结构之上。如果需求描述里少了一个“是否包含附件下载”的细节它大概率不会主动去读文件上传模块的代码更不会去文件存储服务里翻到底存了什么。Grill Me 恰好是在这个机制里打了一个“上移”的补丁它把通常发生在编码中期的“哦原来这里是这个逻辑”提前到了编码开始前。你把拷问阶段挖出来的答案拼成完整需求书后Codex 第一次读项目时就不再是盲人摸象每一步改动都像拿着施工图盖楼。省下来的时间根本不是那几轮问答的时间而是后期发现方向错了、推倒重写的整个周期。再往深了说Grill Me 也顺便解决了一个 bug模型在写代码时如果需求书里同时存在相互矛盾的条件比如“要实时导出”和“数据量可能上百万”明显冲突它会默认选一个它认为更合理的执行而不是报告冲突。但如果你把这两个条件在需求阶段就让业务方自己发现并拍板Codex 手里拿到的就是一个自洽的规格那种“自作主张”的行为会大幅减少。3. 完整实战从一句废话需求到一个能落地的开发任务3.1 准备阶段环境和材料建议准备两样东西一个装了 Codex 命令行工具或者 ChatGPT 的 Codex 模式的开发环境另一个是任意一个支持长上下文对话的入口——其实 Gril Me 这一步不一定挂在 Codex 里跑在普通的大模型对话里也完全够用。我在实际项目里经常把拷问阶段放在一个独立的对话框里进行原因前面说了主要是为了省实现阶段的上下文空间。如果需要写代码的仓库比较大建议先把仓库的目录结构和关键配置文件比如数据库 schema、接口文档、路由定义单独导出来让 Codex 在开始前能快速建立一个“地图”。这一步很多人会忽略但它能极大降低 Codex 第一次读项目的成本。然后是安装 Codex。官方给的安装方式大致是拉取对应平台的安装包或者通过包管理器安装装好后用账号登录获取 token。如果登录时提示 token unavailable我遇到的原因多半是本地缓存了旧的认证信息清掉配置目录重来一遍就能解决。如果你是那种给 Codex 配了自建 API 转发网关的用法出现 cc switch local proxy failed while handling codex endpoint /responses 这种报错基本都是本地网关服务没起来或者端口被占用检查一下相关服务进程和端口监听状态再看看转发配置里的 endpoint 地址是不是写成了旧的 /v1/responses基本都能找回正常状态。这些环境层面的小事能提前处理就提前处理别等需求拷问到一半才发现 Codex 根本启动不了。3.2 跑一次完整的 Grill Me 拷问带示范下面用一个真实场景走一遍全流程。假设输入需求是开头那句“帮我在后台加个导出 Excel 的功能。”把 Grill Me 提示词和这句需求一起丢进对话第一轮 AI 大概率会问“导出的数据是来自全部用户列表还是只来自按当前筛选条件过滤后的结果”你可能会想这有什么关系当然有关系——如果导出的是筛选结果Excel 的列就必须和筛选条件的显示字段完全对应否则用户拿到表格里根本找不到他在页面上看到的筛选条件。我那次实际跑出来的问答记录大概有十五六轮这里挑几个较容易踩坑的问题列出来“导出格式上xlsx 还是 CSV如果用户电脑上是老版本 Officexlsx 打不开怎么办”——这个问题就非常典型直接逼你决定要不要做 CSV 兜底方案。“导出操作是同步返回文件还是先生成任务、完成后通过通知告知用户”——数据量一大同步导出会造成请求超时这几乎是必答题。“表头用中文还是英文字段取值是用数据库原始值还是跟着后台页面的格式化规则比如时间转成 YYYY-MM-DD”——页面显示规则和原始值不一致时你如果不提前定写出来就是二义性代码。“权限上有哪些角色能导出导出的数据量有没有上限超过上限是分批导出还是提示用户缩减条件”——这题看着是在问权限实际是在帮你想清楚要不要做后端限流。“导出失败时用户看到的错误提示文案是什么要不要把失败任务存表给后端留一个手动重试入口”——这题问完你基本就把“可靠性和运维可观测性”的需求也补齐了。整个拷问结束后AI 会按你给它的出口条件汇总一份需求确认书。我习惯在确认书后面再手写补上一段“约束告知”明确告诉 Codex 这个项目不能动数据库 schema、不能引入新的第三方依赖、不能改动公共函数签名。因为如果你不说Codex 很可能为了“流程更优雅”而擅自重构掉你现有的接口逻辑经历过一次的人都懂这是什么滋味。3.3 把拷问产物变成 Codex 的开工指令怎么写主提示词拿到需求确认书后不要直接原封不动地塞给 Codex它还需要一层“工程化翻译”。比如确认书里写着“导出功能要支持按时间范围筛选”到了给 Codex 的指令里我会把它扩展成更明确的实现要求“在现有后台管理系统的 /export 路由下新增导出接口。支持 date_range 参数时间范围导出内容为筛查后的用户列表。列表查询逻辑复用现有 /users 接口同款过滤条件字段映射按页面表格的列配置。导出格式为 xlsx超过 10 万行改为异步任务写入任务表任务完成后回写下载链接。所有导出的文件命名规则为 users_YYYYMMDD_HHmmss.xlsx。不动数据库表结构不新增依赖。”这已经是“接近伪代码的自然语言”了Codex 的每一步都能在项目里找到对应关系。然后再加上一句总要求“实现过程中分三次提交阶段性代码每次提交前先自查接口文档是否需要同步更新。”这句话能让 Agent 型的工具进入更稳定的工作节奏不会被一个超大需求吓得一路推到底最后给你堆出一个找不着北的大 diff。4. 踩坑实录Codex 和 Grill Me 配合时的常见问题与排查技巧4.1 常见问题速查表这一节我把真实使用过程中碰到的高频问题整理成一个速查表按现象、原因、处理方式的格式写方便你以后直接对号入座。现象常见原因处理方式拷问阶段 AI 问着问着开始给方案Grill Me 提示词里缺少“禁止提方案”约束在提问规则里明确写“当前阶段只提问不给出任何实现建议或技术选型”实现阶段 Codex 忽略需求书里的权限要求需求书里没有把权限体系和具体角色名绑定在给 Codex 的提示词里明确写“参考现有项目里 admin 角色的鉴权代码新增接口必须同步加权限校验”拷问结果太长把实现窗口塞满需求确认书没有做摘要提炼成一页以内的开发任务简报把细节留在独立文档里作为参考附件Codex 反复给出互相矛盾的实现方案需求书内部存在冲突条件回到 Grill Me 阶段把冲突条件呈现给业务方拍板在需求书中声明最终决策cc switch local proxy failed while handling codex endpoint /responses本地 API 转发网关服务未启动、端口被占用或 endpoint 路径错误检查网关进程状态、释放占用端口确认转发地址指向 /responses 端点auth token is unavailable本地缓存的认证信息失效清理 Codex 的本地配置目录和缓存重新执行登录流程获取新 token4.2 几个能直接抄的小技巧很多人用 Grill Me 的时候有一个通病拿到需求书就急着开做结果实现阶段发现业务方还有一个“历史原因”没讲。比如我上次做导出功能业务方在最后才提到“导出内容要用月初的汇总数据而不是实时数据”这个信息在初始拷问阶段极难被主动问出来因为提问角度没覆盖到“数据快照时点”。所以我现在会在 Grill Me 的提问范围里强制加一条“请追问该功能要使用的数据是否是实时数据如果不是明确数据快照生成的时间点和策略。”这句话多出来之后帮我避免了好几次返工。另一个小技巧是把拷问阶段的完整问答记录保存下来不要只存需求确认书。原因是实现阶段 Codex 如果对某个细节的理解和你打架你可以直接把对应的那一条 QA 记录发过去它立刻就能纠正。这比再开一轮新的对话、重新描述上下文高效得多。还有一点是关于 Codex 实现过程的分段验收。我会在提示词里要求 Codex 每次只完成一个模块然后停下来等我检查。默认情况下它倾向于一口气把所有东西写完但一次性 diff 太大时人眼很难发现问题。分两次或三次提交每一段的回归成本都很低这个习惯一旦养成就回不去了。5. 把 Grill Me 固化进日常开发流的一点个人体会这套流程我前前后后用了快两个月最大的感受是它没有让写代码这一步变快但它让“改代码”这一步消失了大半。过去我可能花十分钟写提示词然后花两小时在 Codex 的多次迭代里跟它确认“不是这个意思”现在我把同样的十分钟花在了被拷问上之后的实现阶段反倒像在看一个懂行的同事按计划施工。效率的真正抓手从来不是让 AI 一次生成得更多而是让它在动工之前就拿到一个所有变量都被钉死的世界。如果你也想把这套思路落进自己的项目里我的建议是别一上来就追求百分之百完整度。第一次只加三条 Grill Me 的必问领域业务目标、数据来源、验收标准跑两个小需求找找感觉再逐步把性能约束、权限体系、失败反馈这些维度加进去。等你习惯了这种“被人追问到无话可说”的流程你再回头看那些直接扔给 Codex 的提示词就会觉得自己以前像闭着眼睛在跟一个执行能力超强但不读空气的队友合作。最后再分享一个小技巧拷问阶段尽量用独立的对话框别和实现阶段共用会话。这不只是省上下文窗口更关键的是让模型在“审问模式”和“施工模式”之间的切换成本降到最低。两个模式需要的思维风格完全不同混在一起只会让它在写代码时还带着那股“不断确认需求”的谨慎劲效率反而慢。这套 Codex × Grill Me 的组合就是靠这一前一后的两道工序把一个模糊念头变成了一次真正能交付的工程。