从一个模糊的想法出发：grill-me 拷问HERMES & AGENT ENGINEERING · 课时 03

3.1 从模糊想法到清晰需求

你最开始的想法，大概率是这种感觉：

"我想做一个知识管理系统。" "我想写一个帮我整理读书笔记的 Agent。" "我想做一个自动跟进技术方案的 Bot。"

这几句话里有多少信息量？几乎为零。"知识管理系统"这个词可以指一个简单的本地文件夹，也可以指一个带全文搜索、标签分类、AI 摘要、多人协作的大型平台。"整理读书笔记"可以是一个 Markdown 文件，也可以是一个带数据库的 Web 应用。

这就是起点：一个模糊的、不完整的、充满歧义的想法。这个阶段的任务，就是把它变成一份清晰的需求描述——让任何读到它的人（包括 AI）都知道你要做什么。

和传统软件工程里的需求文档不同，不需要几十页的文档，能回答清楚这几个问题：

• 谁用？ 你自己，还是团队，还是公开给所有人？
• 做什么？ 核心功能是什么，哪些是次要的，哪些是边界？
• 数据规模？ 几十条，几千条，还是几十万条？
• 平台、部署和成本边界？ 必须跑在某个平台上，不能依赖云服务，或者必须控制预算？

看起来简单，但大多数人一开始是答不上来的。所以我们需要用某种方式来整理清楚思路，形成一个初步的需求描述。

3.2 这个阶段有哪些工具

这个阶段，理论上可以不借助任何工具，直接写一份需求简报。但如果想法还比较模糊，更适合先用问答把它展开，再整理成文档。

目前比较成熟的工具有这几个：

• grill-me：Matt Pocock 写的一个开源 Skill，核心是三句话规则，让 AI 沿着决策树一层层追问你，直到需求有了清楚的轮廓。
• 自己写 prompt：如果你不想依赖外部工具，也可以自己写一个 prompt 让 AI 按同样的逻辑追问你，效果差不多。

这些方法的作用都是帮助你完成需求发现，而不是替你生成技术方案。下面以 grill-me 为例，看看这个追问过程到底怎么走。

3.3 以 grill-me 为例

grill-me 的核心是三句话：

1. Work your way down the decision tree. Ask about the leaves.
2. Ask one question at a time.
3. If you can just look it up, do that instead.

翻译过来：

1. 沿决策树逐层往下走，问到叶子节点。
2. 一次只问一个问题。
3. 能自己查到的，就别问。

就这三句。没有复杂流程图，没有模板，没有十几个步骤。Matt 写它的初衷很简单：他发现很多项目做不下去，不是因为技术难，而是因为一开始就没想清楚。所以他写了三句话，让 AI 按这个规则来拷问你。

三句话分别说了三件事儿：

第一条，"沿决策树逐层往下走"——你说要做知识管理系统，AI 先问"给谁用"，你回答了，它再问"存什么类型的内容"，你回答了，它再问"怎么组织这些内容"。一个问题引出下一个问题，像剥洋葱，一层层剥到最具体的细节。

第二条，"一次只问一个问题"——很多 AI 工具喜欢一次性抛五六个问题，你看到就头疼，随便回几个，剩下的默认了。一次只问一个，你只需要回答当前这一个，答完再进入下一个。

第三条，"能自己查到的就不问"——你不需要告诉 AI 飞书文档的 API 叫什么，它自己会去查。grill-me 问的都是只有你才知道的事情：你的使用场景、你的偏好、你的边界条件。

拿"知识管理系统"这个例子走一遍，大概是这样：

AI：你打算给谁用？ 你：我自己。 AI：主要存什么类型的内容？ 你：技术文章、读书笔记、PDF 文档。 AI：你怎么组织这些内容？比如按文件夹、按标签、还是按别的？ 你：分层标签，比如"AI/大模型""AI/工具""写作/书评"这种。 AI：内容怎么进来？手动粘贴、浏览器插件、还是自动抓取？ 你：手动粘贴为主，浏览器插件辅助。 AI：数据规模大概多大？ 你：几千到上万条吧。 AI：优先在什么平台上用？ 你：Web 端，移动端以后再说。

对话的机制非常简单，但就是这么简单的多轮问答，已经把"知识管理系统"从一个空壳概念变成了有具体轮廓的东西。

3.4 拷问完之后你得到什么

拷问结束后，你手里有一套问答记录。比如上面这个例子，你拿到了这些信息：

• 目标用户：自己
• 内容类型：文章、笔记、PDF
• 组织方式：分层标签（如"AI/大模型""AI/工具"）
• 录入方式：手动粘贴 + 浏览器插件
• 数据规模：几千到上万条
• 平台：Web 端优先

但问答记录是过程，不是产物。我的建议是：拷问完之后，让 AI 把刚才的对话整理成一份简单的需求简报，再把它作为下一节制作 SPEC 文档的输入。

把刚才的问答整理成一份需求简报，包含目标用户、产品目标、第一版功能范围、数据规模，以及必须遵守的平台、部署和成本边界。不要写具体技术选型。

为什么要多这一步？两个原因。

第一，你需要在文档里做一次全局审视。问答是一问一答逐条过的，你回答每个问题时都觉得自己想清楚了，但把它们放在一起看，可能发现矛盾。

第二，这份文档你可以直接动手修改。grill-me 是一个帮你查漏补缺、整理思路的工具，不是一份严谨的需求生成器。它拷问出来的内容大概率有遗漏，或者某条回答你当时随口说的、后来觉得不对。这些都需要你手动去补、去改。所以别把问答记录当最终产物，把它当草稿，自己需要再审视一遍。

我个人的观点是，现在的 AI 可以很好地执行你的意图，但并不能很好地帮你做决策。我们依然需要在决策上花大量的时间。

3.5 关于"不做什么"

很多规范和 Agent 框架在讲需求文档时会强调：你不仅要写清楚"要做什么"，还要写清楚"不做什么"。

需求简报应该写清楚第一版要做什么；对于容易被误解、而且确实已经做出决定不做的内容，也可以写出来。

但没有必要追求写出所有的"不做清单"。

这不是说"不做什么"这个出发点有问题。它的出发点是对的——防止 Agent 过度发挥，自己脑补一些你根本不需要的功能。但"出发点是对的"不意味着"这个方法就是最好的"。

我自己的经验是，AI 在两种场景下的表现截然不同。第一种是帮你写文档的时候，它确实容易乱写，把你没提的东西加进去。

但第二种，当 AI按照 SPEC 去执行开发的时候，它很少会主动添加你没提到的功能。比如你做了一个开放的知识管理系统，不需要登录，任何人都能用。如果你没写要做”登录“功能，AI 不会主动给你接一个复杂的 OAuth 登录系统。它只会老老实实做你提到的事情。

所以我还是建议多考虑”要做什么“，少考虑”不做什么“。对于不做什么，想到了就写，想不到就不写。

而且，适度给 AI 留一点自主空间，反而是好事。你不可能把所有细节都想到，AI 在开发过程中帮你补全一些你没考虑到的边缘情况，是一种正向的协作。你不需要通过"不做什么"把它捆死，只需要在关键的地方划好线就行。剩下的，交给它去发挥。

当然，如果有些"不做什么"是出于刻意的策略选择，且容易被人误解，那可以写一笔。比如第一阶段不考虑移动端适配，可以明确写出来，这样可以降低第一版的实现难度。

3.6 grill-me 不是必须的

这里我特别强调，grill-me 对于有经验的人来说不是必须的工具。比如我，大部分的时候会采用一种和 Agent 聊天的方式，随便聊，聊着聊着，需求的原型就出来了。grill-me 特别适合缺少项目经验的人来帮助自己整理思路，但是对于有丰富项目经验的人，反而和 Agent 聊天是一种更好的做法。

11.3 到 11.4

需求简报有了，但离真正的开发还差一步。它描述的是"要解决什么问题、第一版做什么"，而 Agent 开发需要的是"怎么做才算对"——数据模型长什么样、业务规则是什么、怎么验收才算通过。

这就是 11.4 的内容：先把需求简报整理成初版 SPEC，再对 SPEC 做一次针对性的二次澄清，把关键歧义补齐。

3.8 ■ 学点英语