本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 github.com GitHub - Jinghao67/conductor: Context conductor for clean master sessions, dirty... Context conductor for clean master sessions, dirty explainer sidecars, and interactive AI branches 作为一个既需要发论文（科研导向）又需要做项目（工程导向）的学生，我在使用ai的过程中，经常遇到下面几个问题： 1）主session污染问题：在一个session内和ai聊久了，主 session 很快会被需求讨论、实现细节、失败尝试、长篇解释、review 记录全部污染，最后自己也不知道哪个 session 是干什么的。在科研上，有了idea后需要做不同的实验去验证和实现，实验过程中涉及到配环境、调参等很容易让ai陷入局部最优而进行过度尝试污染上下文的问题。在工程上，很多工程也会涉及到这些问题，subagent由于其不可显示导致人为不可控且需要用户自己设计而过于繁琐。 2）无论是工程还是科研都来源于一个并不具体的想法，可以说：在完成整个项目的过程中，没有人对这个项目完全了解，这就需要有一个session能拿到所有session的context，来解答用户所有的问题，无论是什么问题，这个session就是用来污染的，且永远不会并入主session污染其他session。 3）过程文档至关重要，但是一个被污染的session总结出的过程文档往往是带有各种无意义信息，比如偏向用户让他给解释的概念、反复陈述各种试错的失败信息，显然这对于未来需要这份过程文档的人是噪音，所以如何维护一个无污染的过程文档至关重要。 针对上述问题，我写了conductor，它的思路是把当前主对话变成一个永远干净的master session（用于自己需要理清项目逻辑、写过程文档等），只保留全局目标、关键决策、分支地图和批准后的子session的摘要；具体使用而言：使用时会先把当前对话设为干净的master session，如果需求不清楚，可以结合grill-me or grill-me-docs追问，等讨论清楚后，conductor会先做依赖分析，判断哪些任务可以并行，哪些必须串行等待。 接着，它不会乱开session，而是先生成branch card，每张card写清这个分支要做什么，为什么开，允许带入哪些context，预期产物是什么，完成标准和return condition，只有用户确认后，才会开真正的branch session。最开始会有四个session。1）主session。2）专门用于问问题随便污染的session。3）讨论分多少branch，并行or串行的session。4）第一个branch session 进入branch session后，这个session只拿到自己的branch brief和已批准的master session的context，不会继承任何session的杂乱历史，用户可以在branch里继续交互实现任何东西，这解决了subagent不能交互的问题，这下每个子任务用户都可以及时纠偏，这些细节都会留在branch里，主session依然干净。 当branch觉得任务完成后，不会自动合并，它会先建议完成，用户确认完成后，会生成总结，把这个session中过度的污染去掉但是把经验和正确的流程总结压缩，然后master session会询问用户是否合并，因为某些子任务必须合并进入主线，要么主线不完整，比如，在科研中，配环境复现paper的branch可以不合并，但是自己的重要实验必须要合并，不然主session会缺乏细节了解。 如果使用Treills，conductor还会把master、branch、依赖关系、状态和产物路径持久化成parent/child tasks、branchmap和metadata，方便回看、回退和继续推进。 整个流程的目标是：主session保持干净和主导，分支负责探索完成，专门留有一个有所有session context的session来让用户随意问问题讨论、污染。 6 个帖子 - 4 位参与者 阅读完整话题
这段时间用mattpocock/skills搞了几个给自己用的小玩意，分享一点经验。 啥最好用 grill-me/grill-with-docs 王者grill-me/grill-with-docs再次上线。这技能强就强在“达成共识”四个字，如果你的需求太宽泛，是真的会问到你神志不清的。我试过几次前面一些问题都还是会认真看，后面就摆烂直接开启Yes工程师模式了。 但王者也需要注意一些点，grill-with-docs会记录文档，很好的设计，但文档在完成任务之后应该删掉，因为可能会与后续的需求产生冲突。我在WinTProxy（自己搞的一个Win平台透明代理）的重构就遇到了与文档冲突的问题。我想要用ndisapi取代WinDivert做数据包的捕获和改写以支持WSL和HyperV的二层NAT，但原有架构是多个Worker在三层做数据包的处理，当时留了个docs/adr文档，然后切换ndisapi就遭殃了，它工作在二层，然后NAT又会经过几个网卡，然后就重复捕获了好几次。 to-issues 这个技能的其中一个思想是很值得参考的，垂直切片。这要求任务划分是从端到端的划分，而不是层间划分。一个任务需要处理完一个需求从后端到前端的全部实现，有效反馈对于AGENTS来说是提效的一个重点。 diagnose 很好用的debug技能，上面那个问题最后就是用它找的，当然也算是我懒，主要是trace级别日志太多了，也懒得看。不过这个技能本身规范了一整套流程，有点啰嗦的。后来我自己改了一套更个人化的技能库，对这个技能就是砍掉了后面的修改和测试，只报告原因就行了，把修改和测试交给to-issues和tdd。 tdd 另一个王者，AGENTS时代大概tdd是最合适的了，要是再配上rust。什么叫做写完就结项？准确来说不是这个技能是王者，是测试驱动这种思想是王者。 啥我不用 这里列几个我不用的技能，不过mattpocock的技能库里面的engineering基本都很有用就是了。顺带一提，我自己魔改就是engineering剔除了triage，魔改了包括zoom-out在内的其他技能，然后加上了handoff做session交接。 前置配置的Issue tracker 并不是说不好用，只是我认为做本地的文档会方便一点。但Matt pocock原来设计就是维护github上的项目的，所以并没有什么毛病，也就开头配置时候多个选择而已。 triage 这是搭配上面的Issue tracker用的，你如果是本地文档，你大概率不会用这个。因为你不可能先写个文档描述issue，然后再丢目录里面去排序吧！真的有人这样做吗？ zoom-out 这玩意就一句话，直接写提示词都行，没有什么工作流程之类的，所以本质上只是方便一点。魔改的话可以让它做些数据流图啊之类的，更清晰一点。 一般咋用 grill-with-docs → prototype(optional) → to-prd → to-issues → tdd improve-codebase-architecture → prototype(optional) → to-prd → to-issues → tdd diagnose → tdd 这个to-prd → to-issues很多时候是形影不离的，一开始我认为这两个就该合并，但后来实际开发中发现，有时候不会去写prd的，一个明确的需求就直接拆分任务了。这两个技能拆分是有道理的。 为啥用这 superpowers、trellis等这些其实都用过，有个共同的特点就是流程控制比较强，或者说比较重，穷鬼最喜欢省token了。 1 个帖子 - 1 位参与者 阅读完整话题
我在使用opus4.8(因为知识更加新一些)结合 grill-me这个skill帮助我清晰我毕业设计论文答辩的过程中,出现了如下图的问题(反复rewind无法跳过): claude opus 4.8大人,我就不能选你给的选项之外的吗 3 个帖子 - 3 位参与者 阅读完整话题
已经问了两百多个问题了,还在继续 19 个帖子 - 12 位参与者 阅读完整话题
使用上Grill me之后感觉特别享受拷打的过程，通过来回的拷问可以把很多没考虑到的点细化、补充进来，明确自己的方向。但是确实碰到过几次问了50多个问题，甚至同事说拷打了100个问题的场景，中间有很多问题，其实感觉完全回答不了，一般我就说先开始干吧，剩下的问题先落个文档，后面再问。刚看到x上Matt发了新的关于使用grill me的视频，看完觉得其中2个点对自己挺有启发的： 1.关于 [Low vs High Fidelity] 问题的处理：个人理解：低保真=粗颗粒度、方向性的问题 高保真=具象、细节的问题； 这里建议的是，因为高保真类的问题，他不是适合‘拷打’的，要是需要原型、更可视化的表达来决定，所以这里Matt建议是先用/Handoff，然后/Prototype,在/Handiff，然后继续/Grill。 这个模式确实解答了我就是碰到不好回答的问题怎么去想清楚，然后又不打乱节奏，且把已经被拷问出来的结果做好了handoff。 2.关于 [Choosing the Right Scope] 范围的选择，这点也是，感觉某种程度上grill-me强化了我的完美主义，可能拷打百问后，定下的细节、设计看似在做近乎完美的设计，但是真以这个为goal干起来，结果拉了坨大的。再加上一旦问题过多，上下文窗口导致我们最初的问题最有价值的回答，最后也没有产生应有的价值。 这个点也是给我自己提了一个醒，还是该干就干，AI是放大器，放大你的优点的时候，也会放大我的缺点 与诸佬分享～ 以下是原文和有对应的skill地址 Matt 教学视频： 9 Things People Get Wrong With /grill-me and /grill-with-docs 里面提到的几个skill： Handoff Skill Prototype Skill 1 个帖子 - 1 位参与者 阅读完整话题
Grill一个简单的翻译小工具，Grill了我已经四十多个问题了，它还要问。它怎么这么多问题？它怎么还能问我问题？它到底还要问多久？ 5 个帖子 - 4 位参与者 阅读完整话题
最近用了grill-me这个skill，真的解放我很多的脑细胞啊，不用费心费力想那么多边界条件和问题。 大道至简的胜利, 一个神级skill推荐, 忘掉brainstorming吧 开发调优 最近发现一个神奇skill. mattpocock 的 /grill-me 内容非常精简，只有几句话，但效果出奇的好. 它的作用就是在你提出需求的时候，不断的质问你，和你理清需求. AI编程的第一原则就是清晰准确的描述需求. CC自带的plan中的提问功能, Superpowers里面的brainstorming, 其实都是在做这个事情, 和你理清楚需求再做计划. 需求越清晰, 执行效果… https://linux.do/t/topic/2084756 3 个帖子 - 3 位参与者 阅读完整话题
grill-with-docs: skills/skills/engineering/grill-with-docs/SKILL.md at main · mattpocock/skills · GitHub grill-me: skills/skills/productivity/grill-me/SKILL.md at main · mattpocock/skills · GitHub 作者的文章: aihero.dev grill-with-docs: Align Before You Build Learn /grill-with-docs: combine AI interviewing with domain-driven design to build better codebases with shared language and less repetition. grill-me 的作者 Matt Pocock 最近发了个新skill grill-with-docs ，同时发了篇文讲述了一下它们的区别和选择。最大的不同就是grill-with-docs会在你敲定决策后把要点写进文档，解决了grill-me不会同步写文档容易丢上下文的问题。实际用下来个人感觉后者体验确实更好，不光询问当前的决策，还能看到后面的预览 简而言之对于大部分的开发环境，grill-with-docs可以替掉grill-me。不过docs依赖于它生成的 CONTEXT.md 和 ADR 文档，转skill得先对接。可以用这段提示词来转: 我们之前用grill-me这个skill讨论了很多内容，现在准备切换到grill-with-docs这个skill，开始对接任务 1. 查看grill-with-docs SKILL.md中的内容 2. 回顾我们之前的讨论，提炼出最重要的领域概念、术语定义和决策 3. 参考grill-with-docs的工作流，生成 CONTEXT.md 和ADR文档，存储对话中的关键内容，进行切换skill的对接 4. 列出目前还开放的问题或需要进一步澄清的地方 完成后，将用grill-with-docs替代grill-me继续后面的开发任务 完成之后换新的skill，就不用担心grill的内容丢失的问题了 extra: grill-me并不是就没有用了，正如文中所说 没有代码库，也就是非开发环境下grill-me用起来更好，如文章里提到的策划活动，商业模式推演之类，侧重于个人的 brainstorm 以及一些我个人的观点 暴论 grill-with-docs会同步写文档，所以用起来会比较重，仓库结构也会更复杂，对于写新项目，或者是开发新功能时很好用；但对于小一点的模块，如在原有基础上添一个小补丁，或者是修规模小但难缠的bug时，grill-me用起来更快捷 大型项目我是opus 4.7 & grill-with-docs规划，完成后再切gpt 5.5 xhigh写代码；对于第二种情况，可以直接用5.5 xhigh & grill-me解决。顺带一提我装了 trellis ，规范后切模型很丝滑 3 个帖子 - 3 位参与者 阅读完整话题
最近看到了一个skill grill-me ，参考生成了一个成步堂Skill 剧透 SKILL.md （点击了解更多详细信息） 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 项目链接： github.com GitHub - Caph-dev/delegate-grill-with-docs: A skill to delegate grill-with-docs sessions to a... A skill to delegate grill-with-docs sessions to a subagent that answers the grilling questions on the user's behalf. 如果你用过 mattpocock 的 grill-with-me 或者 grill-with-docs 并且总是认同 LLM 基于这两个skills给出的推荐做法，与此同时对于一直回复“认同”“同意”“可以” 感到厌烦的话，这个skill一定适合你！ 这个skill会派生一个subagent，代替你为每个问题给出最佳回答；主agent接受subagent结果后，会继续推进讨论。最后把结论写回文档中。 使用方法（需要显式调用，不会自动触发） 使用 $delegate-grill-with-docs 对 @xxx-doc.md 做一次深入讨论，并把最终结论回写到原文档。 安装方法： 让你的agent帮你安装, 在对话框内输入: 安装这个skill: https://github.com/Caph-dev/delegate-grill-with-docs 6 个帖子 - 5 位参与者 阅读完整话题
先想清楚，再放手让 agent 跑 上一篇文章聊了 Matt Pocock 的 grill-me skill——用三句话让 agent 像一个严格的 reviewer 一样，把你的方案逐个分支追问到底。它解决的是 AI 编码最核心的问题： 对齐 。 但对齐只是第一步。你花了半小时被灵魂拷问、做完了决策、写好了 PRD ，然后呢？还是得一句一句地跟 agent 说"接下来做这个"、"继续"、"跑一下测试"、"再改改"。 这就像你跟一个新同事把需求讲得清清楚楚，然后每十分钟去他工位上说一句"干完了吗"。 最近 Codex 和 Claude Code 填上了这个缺口，请更新到最新版。 它们同时推出了 /goal 命令——你给 agent 一个明确的目标，它自己循环执行，直到完成或碰到需要你决策的阻塞点。 Grill-me 让你想清楚，/goal 让你放手。这两件事串起来，才是 AI 编码的完整工作流。 下面可以看到,我的一个任务跑了 50 多分钟,我的这些 CLI 都是运行在服务器上的,意味着以后我只需要每天设置好任务,就可以让 AI 24 小时帮我去干活了! /goal 到底是什么 一句话：**/goal 是一个持久化的执行目标，agent 会自主循环工作直到目标达成。** 以前的交互模式是： 你：帮我修复搜索功能的 bug agent：找到问题了，是 XX 的原因，我改了 YY 你：跑一下测试 agent：测试通过了 你：再检查一下性能有没有退化 ... 每一步都要你盯着、你推着。agent 做完一件事就停下来等你指示。 /goal 改变了这个模式： /goal 修复搜索功能的 bug ，直到所有测试通过且性能不退化 agent：（自主循环：分析 → 修复 → 测试 → 验证 → 调优 → 再验证...） agent：目标达成。改了 3 个文件，跑了 12 轮测试，最终延迟从 340ms 降到 89ms 它不是"让 agent 在后台跑"那么简单。它有完整的生命周期管理： 状态机 ：pursuing → paused / achieved / unmet / budget-limited 预算控制 ：token 预算耗尽时优雅退出，不会乱花钱 证据审计 ：agent 不能自己说"搞定了"就搞定，必须基于实际的测试结果、代码变更等证据 暂停/恢复 ： /goal pause 暂停， /goal resume 继续，不丢失上下文 两个平台如何开启? Codex 的 /goal Codex CLI 0.128.0 首先推出了 /goal ，背后是一个叫 "Ralph loop" 的模式——agent 在紧密的循环中工作，每次迭代读取当前状态、执行一个有界的动作、写下结果、退出，然后运行时检查是否继续。 启用方式（目前需要手动开启 feature flag ）： # ~/.codex/config.toml [features] goals = true 用法： # 设定目标 /goal 修复 flaky 的 auth 测试，直到连续跑 10 次全部通过 # 管理生命周期 /goal # 查看当前目标状态 /goal pause # 暂停 /goal resume # 恢复 /goal clear # 清除 Codex 的实现有一个关键设计： completion 必须基于证据 。agent 不能因为"我觉得差不多了"就标记完成。它必须对比目标和实际的文件变更、测试输出、benchmark 结果等具体证据，才能宣布达成。 Claude Code 的 /goal Claude Code 2.1.139 紧随其后加入了 /goal ，功能几乎对齐： 交互模式：直接在 CLI 里用 /goal -p 模式：脚本化调用，适合 CI/CD Remote Control：远程会话中使用 Claude Code 的 /goal 还集成了 token 用量的实时显示——你可以看到 agent 跑了多少 token 、花了多长时间、进行了几轮迭代。如果发现 token 在烧但没进展，说明 agent 陷入了循环，该手动介入了。 怎么写一个好的 Goal 不是所有任务都适合 /goal 。OpenAI 的官方指南给了一个清晰的判断标准： 适合 /goal 的 ：下一步取决于当前学到了什么的任务。比如 debug 、性能优化、依赖迁移、flaky test 调查——你不知道具体要跑几步，但你知道什么时候算完成。 不适合 /goal 的 ：一步就能搞定的事。改个变量名、加个注释、读一段代码——直接用普通 prompt 就行。 一个好的 Goal 应该包含六件事： 目标 ：什么状态算完成 验证方式 ：用什么证据来证明完成 约束 ：什么东西不能退化 边界 ：只能动哪些文件/工具 迭代策略 ：下一步怎么选 阻塞处理 ：卡住了怎么办 对比一下： 弱的 Goal： /goal 修复搜索的 bug （ agent 不知道"修复"的定义是什么，不知道怎么验证，可能改了代码但没跑测试就宣布成功） 强的 Goal： /goal 修复搜索功能中中文分词返回空结果的问题，验证标准是所有搜索相关测试通过且 中文搜索"机器学习"返回至少 3 条结果。只改搜索服务相关代码，不动其他模块。 如果改了核心分词逻辑，必须跑完整回归测试。如果卡在第三方库问题上，停止并报告 依赖版本信息。 （ agent 知道什么算成功、怎么验证、不能动什么、卡住了怎么办） 串起来：从对齐到执行的完整流程 这是我觉得最有价值的部分。grill-me 和 /goal 不是两个独立的工具，它们是同一个工作流的两个阶段。 第一步：用 grill-me 想清楚 /grill-me 我想给搜索功能加上模糊匹配能力 agent 会开始追问： 模糊匹配的容错级别是什么？一个字的错别字还是整个词？ 用什么算法？ Levenshtein ？ Jaccard ？还是 Elasticsearch 的 fuzzy query ？ 响应时间要求是多少？ 中文和英文的处理方式一样吗？ 是在现有搜索结果上加一层，还是作为独立的搜索模式？ 需要高亮匹配部分吗？ 每个问题都给出推荐答案，你只需要确认或调整。跑完一遍之后，你对要做的事情有了清晰的、完整的认知。 第二步：用 /goal 自动执行 grill-me 跑完之后，你已经知道所有答案了。直接写 Goal： /goal 给搜索功能加上模糊匹配能力。具体要求： 1. 使用 Levenshtein 距离算法，容错 1 个字符 2. 中英文分别处理，中文按字符匹配，英文按词匹配 3. 响应时间不超过 200ms 4. 在现有搜索结果上叠加模糊匹配结果 5. 高亮匹配部分 6. 验证标准：所有搜索相关测试通过，新增模糊匹配测试覆盖中英文各 5 个 case 7. 只改搜索服务模块，不动其他服务 然后就放手让 agent 跑。它会自己分析代码、设计方案、写代码、跑测试、修复问题、再测试，直到全部通过。 完整流程对比 以前： 想个大概的方案 直接让 agent 写 看到结果不对，告诉 agent 改 来回折腾 10 轮 最后勉强能用，但很多细节是妥协的结果 现在： grill-me 被追问 20 个问题，想清楚每个细节 /goal 设定明确目标和验证标准 agent 自己跑，你去做别的事 回来看结果，跑通了就收货 注意事项 token 消耗会更大。 /goal 的本质是让 agent 多跑很多轮，每轮都有 token 开销。特别是复杂任务，几百 K token 很正常。设好预算，盯着用量。 不是所有 agent 都适合自主循环。 如果你的项目很乱、测试覆盖很差、没有明确的验证手段，/goal 可能会跑偏。先把这些基础设施补上。 grill-me 的价值在于它强迫你精确。 很多人觉得"我大概知道要做什么"就够了，但 agent 需要的是精确的、无歧义的目标。grill-me 帮你把"大概"变成"确定"。 写在最后 2026 年的 AI 编码工具越来越像一个完整的工程系统，而不只是"帮我写代码"的自动化。grill-me 和 /goal 代表了两个方向： 对齐的深度 和 执行的自主性 。 把这两个指令组合起来，你得到的不是"更快的代码生成"，而是一个真正能独立完成工程任务的 agent 。你负责决策，它负责执行。 这可能才是 AI 编码该有的样子。
先想清楚，再放手让 agent 跑 上一篇文章聊了 Matt Pocock 的 grill-me skill——用三句话让 agent 像一个严格的 reviewer 一样，把你的方案逐个分支追问到底。它解决的是 AI 编码最核心的问题： 对齐 。 但对齐只是第一步。你花了半小时被灵魂拷问、做完了决策、写好了 PRD ，然后呢？还是得一句一句地跟 agent 说"接下来做这个"、"继续"、"跑一下测试"、"再改改"。 这就像你跟一个新同事把需求讲得清清楚楚，然后每十分钟去他工位上说一句"干完了吗"。 最近 Codex 和 Claude Code 填上了这个缺口，请更新到最新版。 它们同时推出了 /goal 命令——你给 agent 一个明确的目标，它自己循环执行，直到完成或碰到需要你决策的阻塞点。 Grill-me 让你想清楚，/goal 让你放手。这两件事串起来，才是 AI 编码的完整工作流。 下面可以看到,我的一个任务跑了 50 多分钟,我的这些 CLI 都是运行在服务器上的,意味着以后我只需要每天设置好任务,就可以让 AI 24 小时帮我去干活了! /goal 到底是什么 一句话：**/goal 是一个持久化的执行目标，agent 会自主循环工作直到目标达成。** 以前的交互模式是： 你：帮我修复搜索功能的 bug agent：找到问题了，是 XX 的原因，我改了 YY 你：跑一下测试 agent：测试通过了 你：再检查一下性能有没有退化 ... 每一步都要你盯着、你推着。agent 做完一件事就停下来等你指示。 /goal 改变了这个模式： /goal 修复搜索功能的 bug ，直到所有测试通过且性能不退化 agent：（自主循环：分析 → 修复 → 测试 → 验证 → 调优 → 再验证...） agent：目标达成。改了 3 个文件，跑了 12 轮测试，最终延迟从 340ms 降到 89ms 它不是"让 agent 在后台跑"那么简单。它有完整的生命周期管理： 状态机 ：pursuing → paused / achieved / unmet / budget-limited 预算控制 ：token 预算耗尽时优雅退出，不会乱花钱 证据审计 ：agent 不能自己说"搞定了"就搞定，必须基于实际的测试结果、代码变更等证据 暂停/恢复 ： /goal pause 暂停， /goal resume 继续，不丢失上下文 两个平台如何开启? Codex 的 /goal Codex CLI 0.128.0 首先推出了 /goal ，背后是一个叫 "Ralph loop" 的模式——agent 在紧密的循环中工作，每次迭代读取当前状态、执行一个有界的动作、写下结果、退出，然后运行时检查是否继续。 启用方式（目前需要手动开启 feature flag ）： # ~/.codex/config.toml [features] goals = true 用法： # 设定目标 /goal 修复 flaky 的 auth 测试，直到连续跑 10 次全部通过 # 管理生命周期 /goal # 查看当前目标状态 /goal pause # 暂停 /goal resume # 恢复 /goal clear # 清除 Codex 的实现有一个关键设计： completion 必须基于证据 。agent 不能因为"我觉得差不多了"就标记完成。它必须对比目标和实际的文件变更、测试输出、benchmark 结果等具体证据，才能宣布达成。 Claude Code 的 /goal Claude Code 2.1.139 紧随其后加入了 /goal ，功能几乎对齐： 交互模式：直接在 CLI 里用 /goal -p 模式：脚本化调用，适合 CI/CD Remote Control：远程会话中使用 Claude Code 的 /goal 还集成了 token 用量的实时显示——你可以看到 agent 跑了多少 token 、花了多长时间、进行了几轮迭代。如果发现 token 在烧但没进展，说明 agent 陷入了循环，该手动介入了。 怎么写一个好的 Goal 不是所有任务都适合 /goal 。OpenAI 的官方指南给了一个清晰的判断标准： 适合 /goal 的 ：下一步取决于当前学到了什么的任务。比如 debug 、性能优化、依赖迁移、flaky test 调查——你不知道具体要跑几步，但你知道什么时候算完成。 不适合 /goal 的 ：一步就能搞定的事。改个变量名、加个注释、读一段代码——直接用普通 prompt 就行。 一个好的 Goal 应该包含六件事： 目标 ：什么状态算完成 验证方式 ：用什么证据来证明完成 约束 ：什么东西不能退化 边界 ：只能动哪些文件/工具 迭代策略 ：下一步怎么选 阻塞处理 ：卡住了怎么办 对比一下： 弱的 Goal： /goal 修复搜索的 bug （ agent 不知道"修复"的定义是什么，不知道怎么验证，可能改了代码但没跑测试就宣布成功） 强的 Goal： /goal 修复搜索功能中中文分词返回空结果的问题，验证标准是所有搜索相关测试通过且 中文搜索"机器学习"返回至少 3 条结果。只改搜索服务相关代码，不动其他模块。 如果改了核心分词逻辑，必须跑完整回归测试。如果卡在第三方库问题上，停止并报告 依赖版本信息。 （ agent 知道什么算成功、怎么验证、不能动什么、卡住了怎么办） 串起来：从对齐到执行的完整流程 这是我觉得最有价值的部分。grill-me 和 /goal 不是两个独立的工具，它们是同一个工作流的两个阶段。 第一步：用 grill-me 想清楚 /grill-me 我想给搜索功能加上模糊匹配能力 agent 会开始追问： 模糊匹配的容错级别是什么？一个字的错别字还是整个词？ 用什么算法？ Levenshtein ？ Jaccard ？还是 Elasticsearch 的 fuzzy query ？ 响应时间要求是多少？ 中文和英文的处理方式一样吗？ 是在现有搜索结果上加一层，还是作为独立的搜索模式？ 需要高亮匹配部分吗？ 每个问题都给出推荐答案，你只需要确认或调整。跑完一遍之后，你对要做的事情有了清晰的、完整的认知。 第二步：用 /goal 自动执行 grill-me 跑完之后，你已经知道所有答案了。直接写 Goal： /goal 给搜索功能加上模糊匹配能力。具体要求： 1. 使用 Levenshtein 距离算法，容错 1 个字符 2. 中英文分别处理，中文按字符匹配，英文按词匹配 3. 响应时间不超过 200ms 4. 在现有搜索结果上叠加模糊匹配结果 5. 高亮匹配部分 6. 验证标准：所有搜索相关测试通过，新增模糊匹配测试覆盖中英文各 5 个 case 7. 只改搜索服务模块，不动其他服务 然后就放手让 agent 跑。它会自己分析代码、设计方案、写代码、跑测试、修复问题、再测试，直到全部通过。 完整流程对比 以前： 想个大概的方案 直接让 agent 写 看到结果不对，告诉 agent 改 来回折腾 10 轮 最后勉强能用，但很多细节是妥协的结果 现在： grill-me 被追问 20 个问题，想清楚每个细节 /goal 设定明确目标和验证标准 agent 自己跑，你去做别的事 回来看结果，跑通了就收货 注意事项 token 消耗会更大。 /goal 的本质是让 agent 多跑很多轮，每轮都有 token 开销。特别是复杂任务，几百 K token 很正常。设好预算，盯着用量。 不是所有 agent 都适合自主循环。 如果你的项目很乱、测试覆盖很差、没有明确的验证手段，/goal 可能会跑偏。先把这些基础设施补上。 grill-me 的价值在于它强迫你精确。 很多人觉得"我大概知道要做什么"就够了，但 agent 需要的是精确的、无歧义的目标。grill-me 帮你把"大概"变成"确定"。 写在最后 2026 年的 AI 编码工具越来越像一个完整的工程系统，而不只是"帮我写代码"的自动化。grill-me 和 /goal 代表了两个方向： 对齐的深度 和 执行的自主性 。 把这两个指令组合起来，你得到的不是"更快的代码生成"，而是一个真正能独立完成工程任务的 agent 。你负责决策，它负责执行。 这可能才是 AI 编码该有的样子。
此前一直在 plan 前用 oh-my-claudecode 的 deep-interview skills， 这个看起来流行于韩国人圈子，最开始是 Q00/ouroboros 搞的。 今天用一次 grill-me 感觉比 deep-interview 问的太长， 而且不像 deep-interview 有模糊的数值能大概预测何时能问完。 让 gpt-5.5 去比较下，好像 grill-me 更适合放在 plan 后。 10 个帖子 - 7 位参与者 阅读完整话题
在vscode 中的 claude code中如何使用这个grill me 6 个帖子 - 3 位参与者 阅读完整话题
4 个帖子 - 3 位参与者 阅读完整话题
现在的 workflow 是 grill-me + trellis，cc 来列 task 和 plan，cx 来执行（通过插件）。现在有个问题是 cc 只能用 glm-5，cx可以用gpt-5.5/5.4，是否直接用 cx 来 plan 和 task 会更好，佬们有什么建议吗？ 1 个帖子 - 1 位参与者 阅读完整话题
之前看好多佬在推荐这个skill，于是在codex下安装，并用gpt 5.4xhigh来收集一个智能研发体项目的需求。 其实之前用了好多次，大多数情况下都是二三十个问题。但这次涉及的需求比较发散，但问的这80多个问题确实提出了好多有价值的点，但总体来说问题结构不是很清晰，有时候会突然跳跃。大多数情况下，无脑“好的继续”就够了。 用这个插件确实会上瘾，为了方便使用，只好用我之前 这个方案 在手机上进行远程vibe，吃饭的时候，摸鱼的时候回答几条 6 个帖子 - 6 位参与者 阅读完整话题
我把grillme的机制融入到了我的cs-brainstorm里了，然后我发现了一个很好用的用法。 情景就是：我确实很有想法，想法多到我自己都记不住，这样的话我很难完整地交代给AI。grillme就能让AI一直问，然后我一直输出，太爽了太爽了。 爽到最后AI都说要不要停一停去开干，然后我说我就会讲还没交代完，继续grillme。它就惨兮兮得继续问我哈哈哈！太爽了。 1 个帖子 - 1 位参与者 阅读完整话题
最近发现一个神奇skill. mattpocock 的 /grill-me github.com/mattpocock/skills grill-me/SKILL.md main --- name: grill-me description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me". --- Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead. 内容非常精简，只有几句话，但效果出奇的好. 它的作用就是在你提出需求的时候，不断的质问你，和你理清需求. AI编程的第一原则就是 清晰准确的描述需求 . CC自带的 plan 中的提问功能, Superpowers里面的 brainstorming , 其实都是在做这个事情, 和你理清楚需求再做计划. 需求越清晰, 执行效果才会越好. `griil-me` 也是在做这个事情, 通过对你刨根问底的深入追问来理清需求. 对需求和做计划时慢一点，实现时才能快一点, AI编程时请记住 慢就是快! 实测 /grill-me > /brainstorming > /plan , grill-me的提问是最多的, 远多于另外两个工具. 实测对比 为了对比grill-me和brainstorming, 我对这两个skill问了一个非常复杂的项目级重构, 大概需要处理几十个文件的移动和重构, 非常多需要确认的细节(某个文件要挪到哪里/跨模块如何处理依赖/如何处理循环依赖/测试要不要跟着重构/某些函数要合并/哪些模块要解耦) grill-me问得非常详细, 问了我差不多20个问题, 花了半个小时, 后者只问了七八个问题. 最终用grill-me的计划, 执行起来一遍过, 100+测试全通过 brainstorming跑起来比较唬人，又是调研又是subagent，但最终产出的计划文档并没有grill-me好 具体表现在前者会生成更加详细的操作步骤, 并且看起来就非常的清晰, 而后者生成的计划文档步骤更少, 更糙一点 grill-me 这个skill的prompt非常的精简，所以能把尽可能多上下文空间留给后面的逻辑, 这一点本身就是巨大的优势 当然也有缺点, 逻辑比较简单，只做了提问，甚至问完都不会自己把文档写下来. 所以请大家问完问题之后，务必让他 写入到计划文档md . 然后清空上下文之后再执行这个计划, 这样才能保持最干净的上下文 建议grill-me生成之后再让他review一遍, 或者让brainstorming Review一遍 交叉验证, 我交叉验证的时候发现grill-me的计划中漏处理一个文件, 不过问题不大 关于AI编程框架, 晚点我会再开新贴分享一个最近思考的暴论 5 个帖子 - 4 位参与者 阅读完整话题