想做个 AI 工具?先让这个 Skill 把问题问清楚

“做一个 AI 工具，把材料整理成简报。”

把这句话交给 AI，可以继续让它写功能、选技术、排开发步骤。但我会先停在需求这一步。谁拿材料来，简报给谁看，第一版到底交出什么？这些选择没有定下来，后面的方案很容易替我做决定。

一份叫 grill-me 的 Skill，给了我一个值得借用的方法：把方案拆成有依赖关系的问题，分轮追问，再依据使用者的回答继续。本文写的是方法教程和原创简化提示词，没有我的项目实测，也不承诺能验证市场需求。

我关注的这份仓库里，grill-me 的入口很短，正文只要求调用另一个名为 grilling 的 Skill。真正的访谈规则在后者里面。复制入口文件之前，需要看清这个依赖。

grilling 会把方案展开成一棵“决策树”。它先找出当前能回答的问题，每题附推荐答案；收到使用者的回答后，再重新判断下一轮该问什么。依赖上一轮答案的问题，要留到后面。

默认是分轮提问，一轮可以有多个问题。它没有规定每次只能问一个，也没有要求一定问满多少题。材料中出现的访谈题数只是示例。

它还区分了两种工作。能够从现有文件或环境查到的事实，交给助手调查；方案中的取舍，仍由使用者决定。原规则要求完成访谈后先确认共同理解，再行动。

这份 Skill 的说明也写明，访谈本身不落地文件。如果你需要需求文档，还要另做整理。它不会因为聊完，就自动把一个产品做出来。

我会先检查自己的助手能否调用被引用的技能。有用户在仓库讨论中报告，某些助手没有这个调用工具，需要改为读取被引用的文件。我没有复现这个兼容性问题；至少可以确认，入口引用另一个 Skill，不能假定单独复制它就能通用。

仍用“把材料整理成简报的小工具”作教学示意。这里没有真实客户，也没有预设用户已经选好了方向。

第一轮可以先问：这份简报给谁使用？对方拿到后要完成什么？这两个问题能帮助判断第一版的范围。

至于要不要做多人协作，可能取决于使用者是谁；要不要支持批量导入，也可能取决于材料从哪里来。前面的选择没定，就把这些问题暂存，避免一口气讨论所有功能。

能查资料的部分则先查。例如你已经有一份项目说明，助手可以读取其中的输入格式和当前功能。读不到就写清未知及原因，不能为了让访谈继续而猜一个答案。只有你知道的业务情况，仍需要向你询问。

问题可以带建议，但建议要交代理由。比如“如果第一版只服务一个固定角色，建议先围绕一项任务设计”，这是一项取舍建议，需要你接受或调整。助手写下的推荐，不等于你已经选定。

我会把这一轮的输出控制在当前版本要解决的事上。以后可能增加的功能先放在暂缓清单，不让追问不断扩大项目。

你可以回答“还不知道”。例如，目标用户到底需不需要这份简报，不能靠助手再追问十次就得到证据。可能要先看一份手工样稿，或做一个小原型，再找合适的人确认。

这也是原说明中的一个边界：有些问题需要实际做点东西才能回答，访谈无法替代那一步。先记下待验证项，以及准备怎样验证；拿到结果，再继续受它影响的问题。

“第一版输出多长”可能是你可以当场选的设计条件。“用户愿不愿付费”则需要后续证据。两者都能写进方案，但后者不能被助手填成已经验证的事实。

问完后，我还会看一遍已确认与未确认的事项。有人接受了建议，也可能只是暂时选择。这个状态要留下，免得下一次聊天把暂定方案当成承诺。

下面是我整理的原创简化指令，借用了分轮追问的思路，并增加会话内的决定记录。它不是原 Skill 的完整实现，也没有做等效性测试；可以先在普通对话里使用，不必先安装仓库中的入口。

使用时先给一个小范围的想法，例如只讨论“收到一份文字材料后，怎样整理成一页简报”。这仍是教学示意，不要求你接受这个产品方向。面对助手列出的一轮问题，可以逐题答，也可以反问它为什么推荐这样选。

这套方法产出的，是一组更清楚的决定和待验证项。它还不能证明有人需要这个工具，也不能证明第一版做出来就能赚钱。

我会把产品方案往后放一步，先确认哪些决定真的是自己做的。你准备做的那个 AI 工具，现在最不确定的是服务谁，还是第一版该交出什么？

评论区/后台私信发送关键词：方案追问

即可领取《方案追问》工具包及Skill