grill-me：写代码前让AI拷问你45分钟，省下无数返工

一个熟悉的开发困境

你有没有过这样的经历：方案在脑子里还是一团模糊，却忍不住直接开干，结果写到一半才发现需求理解错了、边界没摸清，最后只能推倒重来——比从头想还累？

这几乎是每个开发者都踩过的坑。而问题的根源，往往不是AI或程序员写不好代码，而是根本没想清楚该写什么。模糊的需求，写出来的自然是模糊的代码。

最近在B站等平台爆火的开源技能 grill-me（意为「拷问我」），提供了一个反直觉却极其有效的解法：在写下第一行代码之前，先让AI像面试官一样，把你的方案从头到尾拷问一遍。本文就来系统梳理这个技能的定位、工作机制与最佳实践。

为什么需要「写代码前被AI拷问」

方案模糊就开干的三大代价

先说痛点。方案没想清就动手，通常要付出三种代价：

需求理解错：方向从一开始就偏了，写到一半才发现。
边界没摸清：依赖的前提根本不成立，权限边界、异常路径、静态条件全是盲区。
推倒重来：最终被迫返工，成本远高于一开始想清楚。

举个真实场景：你说「要加个多租户 RBAC 权限系统」，然后直接开干。写到一半才发现——租户隔离级别没定、权限模型选型没定、历史数据迁移根本没想。结果只能全部推翻。

这个例子之所以典型，是因为多租户 RBAC 本身就是决策密度极高的领域。RBAC（Role-Based Access Control，基于角色的访问控制）通过将权限绑定到角色、再将角色分配给用户来实现细粒度的访问控制，是企业级应用中最主流的权限管理模型之一。它最初由美国国家标准与技术研究院（NIST）在 2000 年前后标准化，至今已演化出 RBAC0（基础模型）、RBAC1（角色继承）、RBAC2（约束模型）和 RBAC3（统一模型）等多个层级，每个层级增加的能力都会显著影响系统设计。而多租户（Multi-Tenancy）指的是一套软件系统同时服务多个独立的客户组织，每个租户的数据和配置相互隔离。当 RBAC 遇上多租户，复杂度会指数级上升：你需要决定租户隔离是在数据库层面（独立 schema 或独立数据库）还是应用层面（共享表 + tenant_id 字段），权限角色是全局统一还是允许各租户自定义，以及跨租户操作（如平台管理员）如何授权。任何一个分支没想清楚，都可能导致整体方案推倒重来。

一句话总结这个本质：最贵的 bug，是没人质疑过的决定。

把返工成本前置为思考成本

grill-me 的价值，可以用四个关键词概括：

做法：让AI像面试官一样，一次一个问题，把方案的每个决策分支都问一遍。
效果：需求理解错、边界没摸清这些问题，在写代码前就暴露，而不是写完后才返工。
成本：一次拷问10到45分钟，比花两天写错东西便宜得多。
本质：现在慢一点，把「返工成本」前置为「思考成本」。

打个比方，它就像建筑工地的安全监理——你设计完一栋楼不能直接开盖，监理得先从头到尾走一遍决策树，确认每个分支都站得住脚。这种思想在软件工程中也有对应的学术支撑：Barry Boehm 在其经典的「缺陷修复成本曲线」研究中指出，一个在需求阶段发现并修复的错误，其成本可能仅为编码阶段的 1/5 到 1/10，如果拖到生产环境才发现则可能高达 100 倍。grill-me 本质上是将这条曲线的左移策略（Shift Left）从传统的代码审查和测试进一步前推到了方案构思阶段。

认识 grill-me：定位与工作机制

grill-me 目前已积累超过 40 万安装量，在同类的十几个技能中脱颖而出，堪称现象级。它的核心是一套精心设计的规则和工作流。

四条核心指令 + 一条隐藏规则

这套技能给AI下达的关键指令包括：

走决策树：按决策依赖逐个分支走完，而不是自由发挥地乱问。这里的「决策树」并非机器学习中的分类算法，而是一种结构化的决策推理方法——从初始问题出发，沿着依赖关系逐层展开分支，每个分支代表一个需要判断的决策点，只有上游决策确定后才能推进下游。这种方法在软件架构设计中尤为关键，因为技术决策之间往往存在强依赖关系：例如你必须先确定数据存储方案才能设计缓存策略，先确定认证机制才能设计权限模型。在架构决策记录（Architecture Decision Records, ADR）实践中，这种依赖关系通常被显式记录——每条 ADR 会标注它依赖哪些先决决策，以及哪些后续决策依赖于它。grill-me 本质上是在对话过程中动态构建这张依赖图，确保 AI 不会跳跃式随机提问，而是按逻辑依赖顺序逐层推进，让每个决策都建立在已确认的前提之上。
给出推荐答案（Provide your recommended answer）：每个问题都带一个推荐答案，你可以直接说「不对，不是那个」，而不用从零开始想。这个设计暗合认知心理学中的「锚定效应」（Anchoring Effect）——人在面对复杂判断时，如果有一个起始参考点，决策速度和质量都会提升。推荐答案既是锚点也是靶子：如果它说对了，你确认即可继续推进；如果说错了，纠正一个错误答案比凭空组织一个正确答案的认知负荷要低得多。
一次一个问题（Ask the questions one at a time）：避免七连问把规划会话直接搞崩溃。这条规则解决的是工作记忆（Working Memory）的容量瓶颈问题。认知科学研究表明人的工作记忆一次只能处理 4±1 个信息块，如果 AI 一口气抛出七八个技术问题，用户不得不在多个上下文之间反复切换，导致注意力分散和决策质量下降。一次一个问题的节奏让每次交互都聚焦在单一决策上，保证思维的深度而非广度。
能查代码库回答的，AI自己查：你的注意力只花在真正需要判断的地方。

还有第五条隐藏规则

最后这条「能查代码回答的问题让AI自己查」是隐藏规则，也是体验流畅的关键——它保证了你不会被无意义的琐碎问题打断。这在人机协作设计中被称为「认知卸载」（Cognitive Offloading）：将机器能独立完成的信息检索任务从人的工作流中彻底移除，让人类专注于需要经验判断和创造性权衡的高价值决策。

grill-me 拷问的四个阶段

一场完整的拷问通常约 45 分钟，分为四个阶段：

第一阶段·读请求：AI读你的方案、扫相关代码，组织出第一个问题。这一阶段的关键在于上下文建立——AI 需要同时理解你的意图（方案文本）和现状（代码库），找到两者之间的差距，并识别出第一个最关键的决策点作为切入口。
第二阶段·基础分支：数据模型、所有权、生命周期、错误处理，逐条给推荐答案，你来确认或纠正。这个阶段覆盖的是软件设计中的「基础架构决策」——它们是后续所有设计的地基。数据模型决定了信息如何存储和关联，所有权（Ownership）明确了哪个模块对哪些数据负责，生命周期（Lifecycle）规定了实体从创建到销毁的完整状态流转，错误处理则定义了系统在非正常路径上的行为契约。
第三阶段·边界情况：竞态条件、部分失败、健全边界——惊喜大多藏在这里。这一阶段之所以最有价值，是因为它直击分布式系统和并发编程中最经典的两类难题。竞态条件（Race Condition）指的是当多个进程或线程同时访问共享资源时，最终结果取决于执行顺序的不确定性——例如两个用户同时修改同一条权限记录，如果没有适当的锁机制，可能导致数据覆盖或不一致。部分失败（Partial Failure）则是分布式环境特有的挑战：一个操作涉及多个服务或多个步骤，其中一部分成功、另一部分失败，系统处于不一致的中间状态。例如在 RBAC 场景中，角色创建成功但权限绑定失败，此时如何回滚或补偿？业界对此有多种解决模式：两阶段提交（2PC）保证强一致但牺牲可用性，Saga 模式通过补偿事务实现最终一致，而事件溯源（Event Sourcing）则通过记录所有状态变更事件来支持任意时间点的回放和修复。这些边界情况在正常功能测试中极难复现，却是生产事故的高频来源——这正是 grill-me 在第三阶段重点追问它们的原因。
第四阶段·综合总结：带着你的决策，输出完整方案，批准或打回再来一轮。这个阶段产出的本质上是一份非正式的架构决策文档——它记录了每个决策点的选择、理由和被排除的替代方案，可以直接作为后续实现和代码审查的参照基准。

这里有两个有意思的判断信号：对话很短，说明问题本来就定义得很好，不用硬撑；对话很长，说明在讨论本应稍后处理的细节，此时应该暂停，先写一小块代码验证再回来。这种「时间长度作为信号」的判断方法体现了敏捷开发中的一个核心原则：在不确定性高的环境中，与其试图一次性完美设计，不如通过快速原型验证来消除关键假设——Martin Fowler 称之为「演化式架构」（Evolutionary Architecture）。

grill-me 为什么这么火

它的爆火可以归结为三个原因：

第一，反转了痛苦默认值。所有编码 agent 的默认行为都是「急于帮忙」（eager helpfulness）——少问问题、快点铲活，看似高效，实则生产一堆要被扔掉的重写代码。这种行为模式并非偶然，而是由 AI 模型的训练目标决定的：大语言模型在 RLHF（基于人类反馈的强化学习）阶段被优化为「让用户满意」，而在短期交互中，快速给出看起来完整的答案比追问确认更容易获得正面反馈。这导致了一个系统性偏差——AI 倾向于在信息不充分时也给出自信的回答，而不是承认「我需要更多信息」。在编码场景中，这意味着 AI 会基于假设快速生成代码，而这些未经验证的假设正是后续返工的根源。grill-me 通过显式的规则约束（「你必须先问完所有决策分支再开始实现」）来对抗这种内在偏差，把「现在慢、质量后置」卖成了一个 feature。

第二，现代化的橡皮鸭调试。橡皮鸭调试（Rubber Duck Debugging）是软件工程领域一种经典的问题排查方法，最早由 Andrew Hunt 和 David Thomas 在《程序员修炼之道》（The Pragmatic Programmer, 1999）中广为传播。其核心思想极为朴素：遇到无法解决的问题时，试着把它逐行解释给一只橡皮鸭（或任何无生命物体），在组织语言的过程中，你往往会自己发现问题所在。这背后的认知科学原理被称为「自我解释效应」（Self-Explanation Effect）——将隐性思维外化为显性语言会迫使大脑重新检验每一个假设。研究表明，仅仅是「准备向他人解释」这一行为本身就能提升 20-30% 的问题发现率。grill-me 是这一理念的现代升级版——一只有主见的鸭子，会追问、会反驳，从被动的思维镜子变成主动的思维对抗者。它将单向的「自我解释」升级为双向的「苏格拉底式对话」，通过持续追问迫使你不仅解释「是什么」，还要论证「为什么」和「如果不是呢」。

第三，推荐答案的巧思。大部分规划会话卡在「我还没想好」，而强制AI先给推荐答案后，说「不对，不是那个」远比「嗯我还没决定」推进得快，会话不会冷场。从交互设计的角度看，这本质上是一种「默认值驱动」的对话策略——与其让用户面对一个空白文本框（高认知负荷），不如给出一个具体选项让用户选择接受或修改（低认知负荷）。这和 UI 设计中「智能默认值」的原则一脉相承：好的默认值让 80% 的用户直接通过，而剩余 20% 只需做出增量修改。

grill-me 安装与实战指南

一条命令装好

安装非常简单，一条命令加一句触发词：

安装：用 npx skills add 指向 mattpocock 的仓库，通过 --skill 参数指定 grill-me。这里的 npx 是 Node.js 生态中的包执行器，允许你直接运行远程 npm 包而无需全局安装。skills 是一个专门用于管理 AI 编码技能的 CLI 工具，由 Matt Pocock（TypeScript 社区知名教育者、Total TypeScript 创始人）团队开发。它的工作原理类似于 npm install，但安装的不是代码库而是 SKILL.md 规则文件——执行后会将对应的技能定义文件下载到你项目的 .cursor/skills/ 或 .claude/skills/ 目录中，AI 工具在启动时会自动读取这些文件作为行为指令。
触发：直接说「grill me」或输入 /grill-me。
投喂方案：贴上你的方案，比如「加个多租户 RBAC 权限系统」，AI 就开始连珠炮式提问，一次一个。

值得一提的是，它采用通用的 SKILL.md 便携格式，Claude Code、Cursor、Codex 等主流工具都能用。SKILL.md 是一种新兴的、用于定义 AI 编码助手行为规则的轻量级配置格式。它本质上是一个 Markdown 文件，按照约定的结构描述技能的触发词、系统提示词、工作流步骤和约束条件。这种设计的巧妙之处在于跨工具兼容性：无论你使用 Claude Code（Anthropic 官方终端编码工具）、Cursor（基于 VS Code 的 AI 编辑器）还是 OpenAI 的 Codex CLI，只要工具支持读取 SKILL.md 文件，同一个技能定义就能即插即用。这种便携性避免了生态碎片化——技能开发者只需维护一份定义，用户也不必为不同工具重复配置。它反映了 AI 工具链正在向「提示词即配置、规则即代码」的方向演进，社区可以像分享 npm 包一样分享和组合 AI 行为规则。这种模式与 Infrastructure as Code（基础设施即代码）的理念异曲同工：将本来隐性的、存在于人脑中的工作流程显式化为版本可控的文本文件。

一场真实的拷问对话

以「加个多租户 RBAC」为例：AI 会先检查现有的 schema 和认证机制，然后开始提问。

第一问：租户数据隔离级别？建议用 RLS + tenant_id 逻辑隔离，改动最小。你说「可以用 RLS」。这里提到的 RLS（Row-Level Security，行级安全策略）是 PostgreSQL 等现代关系型数据库提供的内置安全机制。它允许数据库管理员为表定义策略（Policy），自动过滤每次查询返回的行，确保用户只能看到和操作属于自己的数据。在多租户场景中，RLS 通常与 tenant_id 字段结合使用：数据库层面通过策略强制在每次 SELECT、INSERT、UPDATE、DELETE 时自动加上 WHERE tenant_id = current_tenant() 的过滤条件。相比在应用代码层面手动拼接租户过滤，RLS 的优势在于安全性更高（即使应用层遗漏了过滤也不会泄露数据）且侵入性最小，但代价是调试复杂度增加、跨租户查询需要额外处理。值得注意的是，Supabase、Neon 等新一代云数据库平台已将 RLS 作为多租户的推荐方案内置，进一步降低了使用门槛。
第二问：跨租户共享数据怎么处理？建议公共表加显式标记。这个问题触及多租户架构中一个常见的灰色地带：并非所有数据都严格属于某一个租户。例如全局配置模板、公共字典数据、或者需要在租户间共享的协作资源。常见的处理模式包括：设置特殊的「系统租户」ID（如 tenant_id = 0）标记全局数据、创建独立的公共表不受 RLS 策略约束、或者使用「共享标记」字段（如 is_shared = true）配合策略条件放行。每种方案都有取舍——过多的特殊处理会侵蚀 RLS 的安全保证，而过于严格的隔离则会导致数据冗余和同步噩梦。

就这样一次一个，直到方案里没有模糊为止。

别凭记忆描述

实战有三个要点：第一，效果最好的做法是把 PRD、issue、一段文字甚至一张图直接贴给它，别凭记忆描述；第二，跨工具通用；第三，即使没有完整方案也能用，三五句想法就够启动——越粗糙反而越能提前暴露问题。这第三点尤其值得强调：很多人误以为必须有完整方案才值得被「拷问」，但实际上方案越不成熟、grill-me 的边际收益越高。一个成熟方案可能只能被发现 2-3 个盲点，而一个粗糙想法可能在第三个问题时就会暴露出根本性的方向偏差——这正是最高价值的早期干预。

适用场景不止编码

它的用武之地很广：技术设计审查（API、数据模型、架构）、方案梳理（把 PRD、规格书先拷问一遍再落笔），甚至非编码决策——比如「下一个课程做哪个」这类选题判断，或者面试准备时模拟被追问。

这种广泛的适用性揭示了 grill-me 的本质并非「代码预审工具」，而是一种结构化思维对抗方法。任何涉及多步骤决策、存在隐含假设、且决策成本显著高于思考成本的场景，都是它的最佳战场。在认知科学中，这类方法被归类为「对抗性协作」（Adversarial Collaboration）——通过引入一个友善但坚持追问的对手来消除确认偏误（Confirmation Bias），即人倾向于只寻找支持自己已有观点的证据，而忽略反面信息的心理倾向。

下一个课程做哪个

使用 grill-me 的四条黄金准则

最后用四条最佳实践收尾：

拷问真实方案：把 PRD 直接贴上去，别凭记忆描述。人的工作记忆具有高度选择性和重构性——你记忆中的方案已经被大脑「合理化」过了，那些模糊不清的部分正是被记忆自动补全的地方，而这些恰恰是最需要被拷问的盲区。
让AI查代码：能靠查代码库解决的，别浪费你的注意力去回答。注意力是有限资源，Daniel Kahneman 在《思考，快与慢》中将其比喻为一个固定容量的「心理能量池」——每一次不必要的上下文切换都会消耗这个池子中的容量，降低你在关键决策上的判断质量。
走到边界：真正的价值藏在你想不到的异常路径里。软件系统 80% 的复杂度集中在 20% 的边界情况中——正常路径的实现通常直截了当，但让系统真正「可靠」的是那些处理异常、降级、超时、重试的边界逻辑。Netflix 的 Chaos Engineering 实践正是基于同样的洞察：主动探索系统在极端条件下的行为，比等待生产事故来教训你便宜得多。
及时暂停：对话超过一小时就停下，先写一小块代码验证再回来。这条准则的智慧在于承认「纯思考」的收益递减规律——在某个临界点之后，继续在抽象层面讨论不如写一个最小可行的原型（Spike）来验证假设。Kent Beck 将这种实践称为「用代码思考」：有些架构问题在白板上永远讨论不清，但写 50 行代码就能给出明确答案。

如果这篇文章你只带走一句话，我希望是那句贯穿始终的洞察：

最贵的 bug，是没人质疑过的决定。

下次动手写代码前，不妨先花十几分钟让AI「过过堂」。省下的，可能是无数个返工的下午。