我让AI反过来"采访"我，需求文档再也没返工过
写需求文档时，你是作者；被AI采访时，你是专家。这个角色转换，彻底改变了我的开发流程。
一个让我崩溃的循环
“需求不清楚，能再描述一下吗？”
这是我上个月收到最多的反馈。不是来自产品经理，而是来自AI。
当时我想做一个用户反馈收集系统。我写了这样的需求：
做一个反馈表单，用户可以提交bug和建议，后台能看到所有反馈。
Claude Code开始干活了。半小时后，给我生成了一个基础表单。
“等等，我要的是分类功能。”
好，加上分类。
“不对，分类应该是可配置的，不是写死的。”
改。
“还有，紧急的反馈要能置顶。”
再改。
“用户提交后要能看到处理进度…”
又是半小时过去了，代码改了三轮，我的需求还没说完。
问题出在哪？我以为我知道自己要什么，但实际上我只知道20%。剩下80%的细节，藏在我脑子里，我自己都没意识到。
这个循环我太熟悉了：
- 我写一个粗略需求
- AI实现一个基础版本
- 我看到实现后才想起更多细节
- 反复修改，效率极低
需求不是写不清，是"想不全"。
问题的本质：你知道得太多，反而说不清
这是一个认知科学里经典的现象——知识的诅咒（Curse of Knowledge）。
当你对一件事太熟悉时，你会不自觉地假设别人也知道那些"显而易见"的细节。
比如那个反馈系统：
- 我脑子里清楚"反馈要能分类"，但没写出来，因为"这不是显然的吗？"
- 我知道"紧急的要优先处理"，但没提，因为"这不用说吧？"
- 我想到"用户要看到进度"，但忘了写，因为"这是基本功能啊"
你以为的"显然"，对AI来说是"不存在"。
更糟糕的是，你不知道自己漏掉了什么。
这就是为什么传统的"你写需求→AI实现"流程效率低下。不是AI不行，是你给的信息不全。而你自己都不知道信息不全。
怎么破？
角色反转：让AI来问你
后来我发现了Claude Code里一个被严重低估的工具：AskUserQuestion。
大多数人用AI的方式是：我问，AI答。
但AskUserQuestion把这个关系反过来了：AI问，你答。
这个工具允许AI在执行任务过程中向用户提问。听起来很简单，但它打开了一种全新的协作模式——AI采访。
我基于这个工具整理了一个叫/interview的命令，核心逻辑很简单：
给AI一个粗略的计划或想法 让AI持续用AskUserQuestion向你提问 涉及技术实现、UI细节、边界情况、权衡取舍... 直到AI认为信息足够完整 最后AI帮你把完整的规范写回文件你不再是需求的"撰写者"，而是需求的"回答者"。
这个身份转换带来了本质性的变化。
一次真实的AI采访
让我用那个反馈系统举例，看看被AI采访是什么体验。
我启动了/interview feedback-system.md命令，文件里只有一句话：
做一个用户反馈收集系统
然后AI开始问问题了：
Q1: “反馈系统需要支持哪些类型的反馈？只是bug报告，还是也包括功能建议、使用体验等？”
我：“bug、功能建议、使用问题，这三类吧。”
Q2: “这些分类是固定的，还是管理员需要能自定义添加新分类？”
我想了想：“应该可以自定义，后面可能会加新类型。”
Q3: “用户提交反馈时，需要强制登录吗？还是允许匿名反馈？”
这个我之前没想过：“允许匿名吧，降低门槛。但如果登录了，要关联到用户账号。”
Q4: “匿名反馈的话，如果后续需要联系用户，怎么处理？需要用户留联系方式吗？”
好问题：“可选的邮箱字段，不强制。”
Q5: “反馈需要支持附件吗？比如用户上传截图或日志文件？”
“对，截图必须支持，bug报告没截图很难定位问题。”
Q6: “附件大小和数量有限制吗？需要考虑存储成本。”
“单个文件5MB，最多3张图。”
Q7: “管理后台需要哪些人有权限？是所有员工还是特定角色？”
“产品和开发能看，客服只能看自己处理的。”
…
47个问题之后，AI说：
“我认为我已经收集到足够的信息来完善这个规范。让我帮你整理。”
然后它把我的所有回答整理成了一份结构清晰的需求文档，包括：
- 功能需求（分类的、带优先级的）
- 用户角色和权限
- 数据模型设计
- 边界情况处理
- 技术约束和非功能需求
3000字的需求文档，我一个字没"写"，全是被问出来的。
为什么被问比自己写更有效？
这里面有三个心理学原理在起作用。
原理一：回答比撰写的认知负担低
当你面对一张白纸写需求时，你需要：
- 想清楚有哪些方面
- 决定先写什么后写什么
- 组织语言表达清楚
- 检查有没有遗漏
这是一个高认知负担的任务，你的大脑会自动偷懒，跳过"显而易见"的部分。
但当你回答一个具体问题时，你只需要：
- 理解问题
- 从记忆中调取答案
- 说出来
认知负担大幅降低，你更容易给出完整的信息。
原理二：问题触发被动记忆
很多细节你不是不知道，是想不起来。
“反馈需要支持附件吗？”——你立刻想到了用户截图的场景。
如果没人问这个问题，你可能到开发完成后才想起来：“卧槽，忘了截图功能。”
问题是记忆的钩子。好的问题能钩出你脑子里那些"显而易见到忘了说"的知识。
原理三：苏格拉底式对话
两千多年前，苏格拉底就发现了一个真理：人不是被教会的，而是通过回答问题"想起来"自己本来就知道的东西。
AI采访本质上是苏格拉底式对话的现代版本。
AI不是在帮你想需求，而是在帮你发现你已经知道的需求。
需求不是写出来的，是被问出来的。
AskUserQuestion工具的设计哲学
现在让我们深入看看这个工具是怎么工作的。
AskUserQuestion是Claude Code中一个专门用于向用户提问的工具。它的典型使用场景包括：
澄清模糊需求- 用户说"做个好看的页面"，AI问"好看是指什么风格？简约？活泼？专业？"
确认多选项决策- “这里有三种实现方案：A性能最好但复杂，B最简单但有限制，C折中。你倾向哪个？”
获取缺失参数- “表单验证失败时，错误信息显示在字段下方还是统一显示在顶部？”
验证假设- “我理解你需要实时更新数据，是这样吗？还是定时刷新就够了？”
这个工具的关键价值在于：它让AI从被动执行者变成了主动探索者。
传统模式下，AI拿到需求就开始干，遇到模糊的地方就自己猜。猜对了皆大欢喜，猜错了就返工。
有了AskUserQuestion，AI可以在开始实现之前就把不确定的地方问清楚。前置投入5分钟提问，节省后面50分钟返工。
/interview命令：把提问变成系统化流程
单独使用AskUserQuestion是零散的。但如果把它放进一个结构化的流程里，威力就出来了。
/interview命令就是这样一个流程：
--- description: Interview to flesh out a plan/spec argument-hint: [plan-file] allowed-tools: AskUserQuestion, Read, Glob, Grep, Write, Edit --- Here's the current plan: @$ARGUMENTS Interview me in detail using the AskUserQuestion tool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious. Be very in-depth and continue interviewing me continually until it's complete, then write the spec back to `$ARGUMENTS`几个设计要点：
1. 输入是粗略的，输出是精确的
你只需要给一个包含基本想法的文件，AI负责通过采访把它扩展成完整规范。
2. 问题要"不显而易见"
命令里明确要求"make sure the questions are not obvious"。这很重要——显而易见的问题你自己就能想到，真正有价值的是那些你没意识到需要回答的问题。
3. 深度优先，直到完整
“continue interviewing me continually until it’s complete”——不是问几个问题就完事，而是持续深挖，直到AI认为信息足够完整。
4. 自动回写
采访结束后，AI会把整理好的规范写回原文件。你得到的是一个可以直接用于开发的需求文档。
什么样的问题是好问题？
不是所有问题都有价值。好的采访问题有几个特征：
特征一：挖掘隐含假设
“你提到用户可以删除反馈，这个删除是软删除还是硬删除？删除后管理员还能看到吗？”
这类问题挑战你没说出来的假设。
特征二：探索边界情况
“如果用户提交了一个反馈，然后账号被注销了，这条反馈怎么处理？”
边界情况是bug的温床，提前想清楚能避免很多坑。
特征三：暴露权衡取舍
“实时通知会增加服务器压力和开发复杂度，你确定需要实时的，还是每小时汇总通知就够了？”
好的问题不只是收集信息，还帮你做决策。
特征四：连接前后文
“你之前说紧急反馈要优先处理，这个’优先’具体是什么意思？是自动置顶，还是推送通知给管理员，还是两者都要？”
把之前的回答和新问题串联起来，确保信息一致性。
一个好的采访者，问出来的问题你之前压根没想过，但一听就知道很重要。
适用场景：什么时候该用AI采访？
这套方法并不是万能的。以下是它最有效的场景：
场景一：新功能设计
你有一个想法但细节不清楚。与其自己冥思苦想写需求文档，不如让AI来问你。
场景二：复杂需求澄清
用户或产品经理给了一个模糊需求，你需要把它细化成可执行的规范。
场景三：技术方案评审
你有一个初步的技术方案，想检验它有没有漏洞。让AI从各个角度提问，比自己审查更容易发现盲点。
场景四：项目复盘
项目做完了，想总结经验教训。让AI采访你整个过程中的决策，比自己回忆更系统。
不适合的场景
- 需求已经非常明确，不需要进一步澄清
- 紧急任务，没时间做完整采访
- 你对领域完全不熟悉，问什么都答不上来
实践建议：如何做好AI采访
用了两个月，我总结出几条实践建议：
建议一：初始文档越简单越好
不要一开始就试图写完整的需求。写越多，你的思维就越受限。
给AI一个概念层面的描述就够了：“做一个用户反馈系统”、“优化登录流程”、“重构数据层”。
让细节在采访中自然涌现。
建议二：不要急着回答"我不知道"
很多时候你觉得"我不知道"的问题，其实你是有倾向的，只是没仔细想过。
当AI问到一个你没考虑过的问题时，给自己30秒想想。大多数时候你能给出一个合理的答案。
建议三：允许自己说"这个需要再想想"
如果真的遇到需要更多调研或讨论的问题，告诉AI"这个我需要和团队讨论"或"这个我需要查一下数据"。
AI会标记这个问题，继续问其他的。
建议四：采访结束后要审查
AI整理的规范可能会有理解偏差。采访结束后，花10分钟审查一遍，确保它准确反映了你的意图。
建议五：保留采访记录
采访过程本身也是有价值的。它记录了你做每个决策的原因。将来如果要改需求，回看采访记录能帮你理解当初为什么这样设计。
更深层的思考：AI协作的范式转移
AI采访这种模式，反映了AI协作的一个深层趋势：从"AI执行人类指令"到"AI辅助人类思考"。
早期的AI使用方式是命令式的：“帮我写一个函数”、“帮我修复这个bug”。AI是一个更快的打字员。
但AI真正的价值不只是打字快，而是它能够：
- 从不同角度审视问题
- 提出你没想到的问题
- 帮助你系统化碎片化的想法
AskUserQuestion和/interview命令的设计，正是在释放这种价值。
最了解需求的人永远是你自己。AI不是来告诉你要什么的，而是帮你发现你已经知道的东西。
这可能是AI协作的更高境界：不是AI替你干活，而是AI帮你想清楚。想清楚了，干活就是水到渠成的事。
写在最后
回到开头那个反馈系统的例子。
用AI采访的方式重新做了一遍后，我得到了一份完整的需求规范，然后让Claude Code按照规范实现。
整个开发过程没有一次返工。
不是因为AI变强了，是因为我终于说清楚了自己要什么。
下次当你面对一张白纸不知道怎么写需求时，试试换个方式：
不要写，让AI来问。
需求不是写出来的，是被问出来的。
参考与工具说明
本文涉及的工具和命令：
AskUserQuestion- Claude Code内置工具，允许AI在执行任务过程中向用户提问，用于澄清需求、确认决策、获取缺失信息。
/interview命令- 基于AskUserQuestion构建的Slash Command，实现系统化的AI采访流程。命令接受一个计划文件作为参数，AI会持续提问直到收集足够信息，然后将完整规范写回文件。
使用方式：
# 在Claude Code中执行/interview your-plan-file.md这套工作流的核心理念是角色反转：让AI成为提问者，让人成为回答者。这种模式能有效解决"知识的诅咒"问题，帮助用户发现自己已经知道但没意识到需要表达的信息。
如果这篇文章对你有启发，欢迎关注我，后续会分享更多AI协作开发的实战经验。
有问题欢迎评论区交流，我会尽量回复。
