
第一课完成安装和项目初始化后,Agent 已经知道工单放在哪里、标签怎么用、领域文档从哪里读。接下来终于可以谈需求了。但先别急着让它写规格,更别急着生成代码。“给用户加一个取消订阅入口”“后台支持批量导出”“订单失败后自动重试”,这些话听起来都像需求,实际上只说了一个方向。业务术语、状态变化、异常路径和验收边界还没有被讲清楚。此时 Agent 写得越快,通常只是把猜测更快地变成代码。第二课只解决一个问题:怎样用/grill-with-docs让 Agent 一次问清一个关键决定,并把已经达成共识的术语和架构选择立即写进项目文档。/grill-with-docs到底在做什么这个 skill 不是普通的需求问卷,也不是帮你生成 PRD。它把两种能力组合在一起:/grilling 负责沿着决策树追问,一次只问一个问题 /domain-modeling 负责校准术语,并把结论写入 CONTEXT.md 或 ADR前者让需求变清楚,后者让共识不会随着对话窗口一起消失。完整的工程链路是:grill-with-docs - to-spec - to-tickets - implement - code-review/grill-with-docs位于最前面。它负责把模糊需求问清楚;下一课的/to-spec才负责把已经谈清楚的内容整理成规格。两者不能反过来,否则规格只是把模糊表达排版得更正式。哪些需求值得先 grill不是每个改动都要开一场长访谈。下面几类需求最值得使用:产品只给出目标,没有说明状态变化和验收边界;同一个词在产品、运营和代码里含义不一致;会改变多个业务对象、权限规则或上下游系统;团队正在争论方案,但真正的分歧还没有被说出来;需求里出现“自