AI 编程前，先让 Agent 把你问明白

封面：AI 编程前先让 Agent 把需求问明白

很多人用 AI 编程，一上来就让它写代码。

这很自然。毕竟我们打开 Codex、Claude Code 或 Cursor，就是希望它帮我们干活。能少写一点是一点，能快一点是一点。

但越是复杂任务，越不能急。

真正拖慢项目的，往往不是 AI 写不出代码，而是它一开始就没搞懂你要什么。它不知道哪些文件不能动，不知道哪些边界不能越，不知道测试怎么跑，也不知道做到什么程度才算完成。

这时候，继续催它“直接实现”，就是把返工往后推。

更稳的做法是：先让 Agent 把你问明白。

这里的 Agent，就是能读代码、改文件、跑命令、分步骤完成任务的 AI 助手。Skill，就是给 Agent 用的一组固定工作规则。

最近社区里讨论很热的 grill-me 和 grill-with-docs，核心就做这一件事：在动手前持续追问，直到人和 AI 对计划有共同理解。

先别写代码，先把问题问透

grill-me 的提示词很短。

它要求 AI 围绕你的计划或设计持续追问，一次只问一个问题。每个问题后面，AI 还要给出自己的推荐答案。

这点很关键。

不是让 AI 问一堆开放题，把压力丢回给你。而是让它像一个认真负责的同事一样，一边问，一边给判断。

比如你说：

我想重构这个模块。

普通 AI 很容易直接开始列重构步骤。

grill-me 更适合追问：

这次重构的主要目标是什么？
我的建议是先只选一个主目标：降低测试难度、减少重复代码、拆分循环依赖，或者改善目录边界。否则后面每一步都无法判断优先级。

这个问题看似慢，其实是在省时间。

因为如果目标没选清楚，后面的每一次文件移动、函数合并、测试调整，都会变成争论。

提问不是闲聊，而是走完决策树

好的追问不是“你想要什么风格”“你还有什么要求”。

那种问题太虚，回答完也很难执行。

真正有用的问题，要沿着决策树往下走。决策树，就是一个决定会影响下一个决定的结构。

比如项目级重构，至少会牵出这些问题：

• • 哪些模块必须保留当前对外接口？
• • 哪些文件只是换位置，哪些文件要改职责？
• • 跨模块依赖是先拆，还是先包一层适配？
• • 测试跟着移动，还是先补一层回归测试？
• • 循环依赖要立即切断，还是先标出下一步？
• • 这次改动失败后，回滚边界在哪里？

这些问题不问，计划就会变成漂亮但不可执行的段落。

它表面上有步骤，实际没有约束。

配图：需求追问决策树

grill-with-docs 解决的是上下文丢失

grill-me 很轻，适合快速追问。

但它有一个明显问题：问完以后，如果没有把结论写下来，下一轮对话很容易丢。

grill-with-docs 就是为这个问题出现的。

它保留了 grill-me 的追问方式，又加了一件事：把确定下来的术语和硬决策写进文档。

这里有两个词需要解释。

CONTEXT.md，可以理解为项目共享语言表。它记录项目里一些核心词到底是什么意思，避免大家用同一个词表达不同东西。

ADR，也就是架构决策记录。它记录那些不容易反悔、没有背景会让人疑惑、并且当时确实有取舍的决策。

举个简单例子。

如果你们项目里有一个词叫“任务”，它有时指用户看到的待办，有时指后台调度任务，有时又指 Agent 分配的小工作，那 AI 很容易混。

grill-with-docs 不只是继续问“你说的是哪种任务”。它还会推动你把三个词分清楚，并写进共享语言里。

这样下次再聊，AI 不用重新猜。

配图：追问结果写回共享语言和决策记录

什么时候用 grill-me

没有代码库，或者只是想把一个想法问清楚时，用 grill-me 更合适。

比如：

• • 你要写一篇文章，但选题还没定。
• • 你要做一个活动，但目标人群和流程没想透。
• • 你要设计一个小功能，但还没有进入代码阶段。
• • 你要做一个商业模式推演，重点是把假设问出来。

这种场景不需要沉重的项目文档。

你只需要一个不断追问的 AI，逼你把目标、对象、边界、成本和成功标准说清楚。

什么时候用 grill-with-docs

有代码库、模块、长期维护成本时，用 grill-with-docs 更合适。

比如：

• • 要做跨模块重构。
• • 要改数据模型或 API 形态。
• • 要处理很多领域术语。
• • 要让后续 Agent 接着同一个计划继续做。
• • 要把重要决策留给未来维护者看。

它的重点不是多问几个问题，而是让问出来的结果不丢。

问完以后，术语进共享语言，硬决策进决策记录，计划进可执行文档。

下一次再打开项目，不用从聊天记录里考古。

不要为了 Skill 硬造文档

这里有一个边界。

grill-with-docs 默认会用 CONTEXT.md 和 ADR，但不代表每个项目都要照搬这套目录。

如果你的项目已经有 AGENTS.md、项目规范、设计说明、维护手册或知识库入口，就先写回现有位置。

真正重要的是两件事：

1. 1. 术语有没有统一。
2. 2. 决策有没有留下原因。

文件名不是重点。

为了一个 Skill 硬塞一棵 docs/ 文档树，最后反而会让项目更乱。

一个可直接复制的用法

下次遇到复杂任务，可以先这样说：

请先不要实现。

用 grill-with-docs 的方式审问这个方案。
一次只问一个关键问题，每个问题都给出你的推荐答案。
如果答案能从代码库或现有文档里找到，你先自己查，不要让我重复解释。
每当术语、边界或硬决策被确认后，写入现有项目文档或计划，不要新建无关文档树。
直到目标、输入、输出、禁止事项、依赖关系、测试入口和验收标准都清楚，再生成执行计划。

如果没有代码库，可以把第一句改成：

用 grill-me 的方式审问这个想法。

这个指令真正限制的是两件事。

第一，AI 不能急着实现。

第二，AI 不能只问你问题，还要自己查代码、给推荐答案、把确认过的内容写下来。

配图：把追问指令变成计划和验收清单

问完还要验收

追问不是结束。

问完以后，至少要留下 4 个东西：

• • 一页计划：目标、范围、步骤和不做什么。
• • 一张检查表：测试、命令、截图、人工确认项。
• • 一个风险边界：哪些文件不能动，哪些动作必须先确认。
• • 一个回写位置：术语、决策和经验以后在哪里找。

大型任务还要再做一次 review。

原因很简单：追问能减少误解，但不能保证没有漏文件、漏依赖、漏测试。

社区里有人用 grill-me 做复杂重构，体验很好，但也提到后续 review 发现过漏文件。这反而是很健康的流程。

先追问，再计划，再 review，再执行。

这比一上来让 AI 改 50 个文件稳得多。

配图：小任务和复杂任务的处理分岔

小任务别过度流程化

不是所有任务都需要半小时追问。

如果只是改一个明确 bug，输入、输出和验收都清楚，直接做就行。

比如：

这个测试失败，因为空数组时返回了 null。请只修这个函数，并跑对应测试。

这种任务再用 grill-me 问 20 个问题，就是流程反噬。

判断标准很简单：

如果你能清楚写出目标、范围、禁止事项和验收，就不必强行追问。

如果你写不出来，就先别让 AI 动代码。

真正的变化是人和 AI 的分工

AI 编程不是把“写代码”外包出去。

更准确地说，是把低价值、重复、可验证的执行动作交给 Agent，把目标判断、取舍和验收留在人手里。

grill-me 和 grill-with-docs 的价值，就在这里。

它们提醒我们：不要让 Agent 一开始就当施工队。

先让它当面试官、质检员和记录员。

等它把你问明白，把项目语言查清楚，把硬决策写下来，再让它进入实现阶段。

慢一点，不是拖延。

这是把返工提前消掉。

参考资料

• • grill-me Skill 原文：https://github.com/mattpocock/skills/blob/main/skills/productivity/grill-me/SKILL.md
• • grill-with-docs Skill 原文：https://github.com/mattpocock/skills/blob/main/skills/engineering/grill-with-docs/SKILL.md
• • Matt Pocock：grill-with-docs: Align Before You Build：https://www.aihero.dev/grill-with-docs
• • Matt Pocock：grill-me: Stress-Test a Plan Before You Build：https://www.aihero.dev/skills-grill-me
• • Linux.do 社区讨论：https://linux.do/t/topic/2084756

我是一名 数字创作者 · 独立开发者 · 技术博主，专注成长，拓展技术边界，持续突破自我。

如果这篇文章对你有用，欢迎点个 赞 / 在看，也欢迎在评论区聊聊你的实际问题。