用文档拷问与地图化拆解复杂问题

是什么 这是一条关于 Agent 辅助研发流程的纯观点推文。作者分享了一条短而实用的工作流：先把 Issue 描述交给 /grill-with-docs，通过文档与追问检验问题边界；当发现任务远比预期庞大时，再使用 /wayfinder 生成地图，帮助理解结构、依赖与推进路径，最后回到执行阶段。

核心设计 从命令名称和上下文看，这套流程把“实现”前移为“理解”。第一步承担质询和范围暴露，第二步承担空间化建模，形成“发现复杂度—建立全局认知—继续实施”的阶段转换。它的价值不在某个命令本身，而在于把意外发现显式转化为下一步行动，避免工程师在错误假设上持续编码。

关键洞察 对 Agent 工程尤其重要的是，复杂任务不应只依赖一次提示直接产出代码。先让 Agent 挑战需求，再要求它整理地图，相当于为上下文构建增加检查点，也能降低遗漏依赖和返工概率。这是一种可复用的研发前置套路。

边界与风险 推文没有说明两个命令的具体实现、输入格式或地图准确性。文档质量不足时，质询可能放大误判；地图也可能制造虚假的确定感，并增加时间和 token 成本。实际使用仍需用源码、验收标准和真实依赖复核结果。