grill-* 是我在 AI 辅助开发里用得最多、也被误解得最多的一组技能。它名字里带着 grill很多人第一反应是“要开始烤了”“要开怼了”实际上在斜杠命令这个体系里grill 代表的是交叉拷问把代码、需求、设计稿放到一个严格的提问框架下面反复验证它是不是经得起推敲。这篇文章就围绕这组技能最常见的 9 个误解来说清楚适合已经在用 AI 辅助写代码、做评审但是每次用完都觉得“差点意思”的人。我先说结论grill-* 最有价值的不是把东西说得很难听而是让提问变得有结构、有方向、可验证。很多人用歪不是因为工具不行而是他们把它当成了情绪出口或者当成了一个不用动脑的懒人按钮。下面按我实际踩过的顺序一个一个拆。1. 先把 grill-* 的定位说清楚它不是怼人工具是压力测试框架1.1 “grill”在 AI 技能里不是烧烤是交叉拷问grill 这个词在英文里除了烧烤还有另一个意思反复盘问、追问到底。美剧里警察审嫌疑人会叫 grill面试官做压力面也会叫 grill。到了 AI 辅助开发里/grill-* 这组技能借的就是这个语义对一个目标做高强度、结构化的提问逼着它把假设、边界、失败方式都交代出来。所以 grill-* 通常不是一个单独命令而是一族。常见的形态有 /grill-code、/grill-design、/grill-plan、/grill-requirement也有按领域拆的版本。无论名字怎么换底层逻辑是一样的输入一个“对象”技能会从多个角度产生追问最后返回一份带问题清单、风险点、建议修改项的结论。这点必须放在最前面是因为后面 9 个误解里至少一半都源于“以为它是用来骂人的”。1.2 它和普通提问、普通 code review 的根本差别普通提问是“我有问题给我答案”。比如问“这段代码怎么优化”AI 会直接给你一个建议很少反过来问你“你的性能目标是什么”“这个函数被谁调用”“失败时允许什么程度的风险”。grill 反过来。它默认“你给的东西一定有漏洞”然后通过一轮一轮追问把漏洞找出来。这个过程更像压力测试而不是老师讲解。我用一个简单对比来说明维度普通提问grill-*目标拿到答案找到问题默认立场相信输入怀疑输入输出形式一段建议问题清单、边界、风险、修改方案适合阶段学习、快速实现评审、上线前检查、方案选型很多人觉得 grill 输出“太啰嗦”是因为他们只想要一个答案。真想用好它得先接受它的工作方式先问清楚再给结论。我自己第一次用的时候也嫌它烦后来才发现那些“烦人的追问”才是它真正值钱的部分。2. 误解一和误解二把 grill 当喷子把挑错当全部2.1 误解一以为 grill 是“不服就怼”的情绪输出这是所有误解里最常见的。看到名字带 grill就以为它是用来把 AI 或同事“烤”一顿的。于是有人直接把一段代码丢进去什么上下文都不说只打两个字“开烤”。结果返回一堆泛泛的批评比如“这段代码可读性差”“这里需要优化”但没有任何一条能落到具体修改上。这不能怪技能只能怪用法。grill 需要明确目标你要拷问的是性能、安全、可维护性还是需求一致性设定好对象它才会沿着正确的方向追问。什么都不给它就只能在通用层面打转。我一般会在用之前先写一句话比如“这段代码要上线请从并发和异常处理两个角度压力测试。” 这比打十个感叹号有用得多。你给了方向它才知道该往哪里深挖你不给方向它就只能把每个角落都轻轻碰一下结果自然显得很水。2.2 误解二以为 grill 只会挑错不会给出建设性产出第二常见的就是把 grill 理解成“纯挑毛病”。其实一次合格的 grill 输出里最重要的往往不是“哪里错了”而是“怎么证明它对了”。我在实际使用中grill 经常给我补出这些东西边界测试用例空值、超长输入、重复提交、并发冲突失败恢复建议重试策略、回滚方式、日志输出点假设澄清比如“这个函数假定调用方一定传了 id”而这条假设其实没有保证更简单的替代方案有些时候它甚至会说“这个需求根本不需要这段代码”所以我现在的理解是grill 是检查员不是喷子。它给的不是骂名是验收清单。你把它当喷子它就只能给你情绪你把它当检查员它就能给你一份能直接拿去改代码的清单。真实工作里检查员比喷子有用得多。3. 误解三到误解五上下文、范围、输出格式三个老问题3.1 误解三不给上下文就开 grill等于没带病历就去看医生这三个误解本质上是同一个毛病没有把输入条件准备好。grill 再强也是基于上下文推理的。你只给一个函数名不给调用关系、数据来源、运行环境那它只能问出最表层的“有没有空指针”“有没有资源泄漏”。真正的风险比如某个字段从上游接口过来时可能为 null直接断掉了整条主流程这种问题藏在上下文里不藏在函数里。给上下文我一般按这个顺序先贴最小复现片段不要贴整个文件再说明这段代码的输入来源和预期输出然后说清楚你要重点检查的方向最后补上运行环境和已知限制这样一轮 grill 的效果通常比什么都不给、连续 grill 三轮还强。很多人觉得 AI 检查不出来其实是它根本不知道你具体在什么条件下运行这段代码。你补的每一行上下文都是在缩小它的猜测范围。3.2 误解四一次 grill 整个项目结果一个点都没打透很多人会把整个仓库丢进去然后说“帮我全面检查”。听着很合理实际上是最低效的用法。原因很简单grill 的强度是有限的范围越大每个点分配到的追问轮数就越少。检查整个项目最后拿到的就是一长串浅层建议比如“配置文件里有个魔法数”“某处缺少注释”。这些建议没错但没有一条是能直接解决你真正担心的那个问题的。我现在都按“单点切入”来用 grill想检查接口性能就只 grill 那个接口的完整链路想检查并发安全就只 grill 共享变量相关的几个函数想检查需求漏项就只 grill 那张需求清单不要连原型图一起拖进去范围缩小之后输出的深度立刻不一样。这就像医生问诊你一次性把全身症状都说完医生只能给你开一堆常规检查你只针对一个部位他才会给你做深入排查。3.3 误解五不指定输出格式拿到一堆散装结论这是最容易被忽略、也是最影响落地的。grill 默认的输出形式是对话式的它会先追问几句再给结论中间还可能夹杂一些解释。如果你只是想“看看有没有问题”那没问题但如果你要拿着结果去写整改计划就会很痛苦因为你要从一大段话里自己提炼问题。所以我一般会在输入里直接指定输出格式。例如请按以下结构输出 1. 问题清单按严重程度排序 2. 每个问题的复现路径或触发条件 3. 建议修改方式给出具体代码或配置 4. 你认为需要我补充确认的前置条件加上这段格式约束之后grill 的输出从“能看懂”变成“能直接派活”。这条经验对任何斜杠技能都适用不限于 grill。输出格式不是形式主义它决定了你拿到的是“可执行文档”还是“聊天记录”。4. 误解六和误解七把结论当真理把复盘当批斗4.1 误解六grill 输出没有消化验证就直接改代码比不会用更危险的是太相信。有人拿到 grill 的结论也不看它依据的前提是什么直接复制粘贴改代码改完发现新问题更多。grill 本质上是基于推理的分析不是静态分析器。它会给出看起来很笃定的结论比如“这里存在并发写入风险”但这个结论的前提可能是它假设了某个框架版本、某个调用顺序而这些假设不一定和你的环境一致。正确做法是把它当“嫌疑名单”而不是“判决书”。拿到建议之后至少做三件事确认建议里提到的前提是否成立用最小样例复现它说的风险确认真的存在修改后重新 grill 一次看问题清单是不是真的变短了我见过太多人把 AI 的质疑直接当成 bug 清单去提给团队结果因为前提不成立白忙一场。grill 给你的是线索不是罪证。它怀疑哪里你就去验证哪里验证完再动手才是正常顺序。4.2 误解七只在出事之后才想起 grill却不在事前用它grill 最被低估的使用时机是“事前”。很多团队的习惯是代码写完了线上出问题了才拉一个 grill 来复盘“哪里没考虑到”。但这样已经晚了而且复盘时大家情绪都不好。我更推荐把 grill 放在几个固定节点需求评审前先 grill 需求把漏掉的分支和异常情况找出来方案选型时同时 grill 两个方案让它在同样的角度下对比代码提测前先 grill 自己的代码把明显问题修掉再交给测试上线前检查把发布步骤和回滚方案丢进去让它模拟失败场景这样做的好处是问题还在成本最低的阶段就被发现。grill 不是为了“证明谁错了”而是为了在错误造成损失之前把它拦住。早点用它它就不是批斗会而是安全检查。5. 误解八和误解九参数拉满场景用错5.1 误解八深度、轮数、并发全部拉满先炸的是自己grill 这类技能通常会有几个可调参数比如追问深度、最大轮数、并行分析的文件数、输出长度。新手最容易犯的毛病是既然要“拷问”就把所有参数拉到最大。结果往往是这样一次任务跑了很久资源占用飙升最后输出的内容量巨大反而没人看得完。而且参数开满不等于效果最好它只是让 AI 在每个方向上多走几步而很多步是重复的。这里就涉及真实工程里的资源判断。如果你的机器配置一般先把并行数降下来如果任务本身只是检查一个函数完全不需要开深度探索。判断标准很简单单条任务跑完输出里如果出现大量重复信息说明深度过大了如果输出明显太浅再往上加。我的建议是从默认参数开始先跑一次单条任务看输出质量再逐步加。真正需要调参的信号有三种输出太泛可能要把追问深度调高让它在单个问题上深入输出太长可能要把输出格式约束得更紧或者缩小输入范围反复出现相同问题可能是上下文重复导致不是参数问题参数不是越大越好而是刚好够用最好。你一次只 grill 一个文件时根本不需要把并行数开到 20。5.2 误解九在主观审美类问题上硬套 grill结果两边都痛苦grill 的强项是逻辑验证、边界补充、风险暴露。但它不是万能的至少有一类场景非常不适合主观审美和品味判断。比如“帮我 grill 一下这个页面好不好看”“帮我 grill 一下这篇文章的语气舒不舒服”。这种问题不是不能问而是 grill 的结构化追问套上去之后输出往往特别拧巴它会强行给审美找理由最后给出一堆“颜色对比度够不够”“标题长度适中”这种八股式建议对真正想解决的问题没什么帮助。不是所有问题都需要压力测试。需要验证逻辑的用 grill需要体验判断的直接问“这里有什么改进可能”或者多找几个人看更有效。工具选对场景比工具本身强不强更重要。6. 我现在的 grill-* 打开方式6.1 推荐流程单点、小范围、带格式踩完上面这些坑之后我现在的标准流程已经固定下来每次都是四步第一步明确对象。只选一个函数、一个接口、一份需求或一个方案。 第二步补上下文。输入来源、调用方、运行环境、已知限制一次说清。 第三步定义重点。告诉它从性能、安全、可维护性、需求一致性里选 1 到 2 个方向。 第四步指定输出。给出上面说的四段式结构要求按严重程度排序。这套流程跑完之后我再把输出里“需要我确认的前提”单独拎出来逐条验证。验证完再改代码改完再跑第二轮 grill看问题数量有没有下降。整个链条的核心不是“跑没跑 grill”而是“每一轮的输出有没有让下一轮更接近可上线状态”。我一般会连续跑两轮第一轮找问题第二轮验证修改结果。两轮之间的间隔里我自己也要看一遍代码不能全交给它。6.2 适合与不适合的场景对照我把实际经验整理成一张对照表方便判断一个任务该不该开 grill场景是否适合 grill建议用法接口并发和异常处理非常适合单接口开一轮指定并发维度需求评审找漏项非常适合只给需求正文让追问分支场景方案 A/B 选型适合同一组问题分别问两个方案再对比答案上线前检查发布步骤适合让它模拟几个失败场景看回滚是否完整代码整体风格统一一般直接用 lint 和格式化工具grill 成本太高页面好不好看不适合直接请教交互反馈别硬套结构化追问新知识学习不适合先用普通提问把概念弄懂再用 grill 检验理解这张表不是标准答案但能帮你少走弯路。核心判断标准就一条你需要的到底是“找漏洞”还是“找感觉”。找漏洞用 grill找感觉用别的方式。如果拿不准就先问自己一句“这个任务的失败成本是什么” 失败成本越高越适合压力测试失败成本只是“不好看”就不值得开 grill。6.3 遇到 grill 结果不对时的排查顺序grill 输出质量差不一定就说明工具不行。我每次都会按下面的顺序排查先看输入范围是不是太大。范围大了深度必然下降优先缩小范围。再看上下文够不够。调用关系、数据来源、环境限制有没有交代清楚。然后看重点定义。是不是没有告诉它检查方向导致它全面铺开。接着看输出格式要求。没有格式约束的时候结果散是正常的。最后看参数是否合适。不要一上来就怀疑工具先把前面四项洗干净。按这个顺序我遇到过的大部分“grill 不给力”其实都是前面四项的问题真正是工具本身出状况的时候很少。还有一点容易被忽略如果输入材料本身有错误比如代码片段缺了行、需求文档前后矛盾grill 会基于错误的输入给出同样错误的结论。所以开工前先把输入材料读一遍比什么参数都重要。最后说一句我自己的体会grill-* 这族技能本质上是在教你把“质疑”变成一种可重复、可验证的工程动作。它不会替你做决定也不会替你把代码写对但它能逼着你在提交代码之前先把最坏的情况想一想。用对它的人等于多了一个专门负责提问的检查员用错它的人只是在给 AI 和自己的情绪添堵。我的建议始终是先用小输入跑通流程再根据输出质量调参数最后把它固定在关键节点上而不是想起来才用一次。
