夜雨聆风前几天和一位自然资源行业领导聊天，他提到一个真实问题：需求调研最难的地方，是需求的模糊性——需求往往以一些模糊的业务感受的形式存在业务处室和它下面二级机构的相关部门人员的脑子里。比如“最好能智能分析一下”“希望有一个全省一张图”“合规审查最好能自动化”。这些想法都很好，但都不能直接变成系统需求。
我们平时用的传统调研方式，比如发问卷、收表格、开现场会、访谈业务人员、整理政策文件，最后非常考验项目经理的个人经验。能力强，就能挖到关键点；能力差，就只能得到一堆材料和几句“希望系统智能一点”。
不是业务部门不配合，也不是项目经理不努力。
问题在于：如果没有专业的提问能力，我们很难清晰地把业务人员脑子里的真实需求提取出来。如果没有专业的需求整理能力，我们很难准确的把需求整理成有效的PRD文档。
今天想聊的，就是怎么用 AI 工具辅助这件事。我以前写过一篇文章《Claude Code 进阶：记忆与编排的完整方案》里面提到过OMC和OpenSpec。现在我越发觉得OMC 和 OpenSpec 的不只是给程序员做 vibe coding 用的，对不写代码的项目经理更有价值。前者帮我们把原始材料变成专业调研问题，后者帮我们把原始需求整理成PRD文档。
真实项目里，需求不是从空白开始的
我还是以“自然资源资产智慧组合供应系统”为例。
这个项目一开始收集到的材料很典型：政策文件、业务指南、具体案例，以及“合规分析、项目推荐、AI 组合生成、资源总览”等初步业务目标。
如果项目经理只是把材料读一遍，然后直接写项目 PRD，很容易写成一份“看起来很完整、其实很空”的文档。
比如：
系统建设智能组合、智能推荐、合规审查、资源总览四大模块，实现自然资源资产组合供应高效化、精准化、合规化。
这句话没有错，但它还不能支撑系统开发。
因为它背后至少还藏着几个必须确认的问题：
“智能组合”到底从哪里开始？是先有产业需求，再反向匹配资源，还是先选定资源，再生成组合方案？ “合规审查”到底审什么？产权、空间规划、用途管制、交易程序、定价机制，哪些是一期必须覆盖的？ 这些判断现在由谁做？依据什么材料？有没有固定表格、台账、审批单或历史案例？ 数据从哪里来？哪些已经有，哪些只存在于线下 Excel、报表或业务人员经验里？
更合理的方式是：项目经理先把原始需求和原始材料交给 AI，让 AI 梳理出问题地图；再带着问题地图去业务处室、二级机构、市县单位做针对性访谈。这样拿回来的材料，才有机会形成适合 vibe coding 的 PRD。
Deep Interview：用苏格拉底式提问准备问题
OMC 的 Deep Interview 最有价值的地方，不是让 AI 替项目经理决定需求，而是让它像一个资深业务分析师一样，帮我们把“该问什么、问谁、为什么问”先梳理清楚。
它背后的方法，更接近苏格拉底式提问。
苏格拉底式提问的核心，不是直接给结论，而是通过连续追问，把对方脑子里那些默认成立、但从来没有说清楚的东西挖出来。放到需求调研里，就是问：
你说的“智能”，具体指自动判断、辅助推荐，还是生成材料？ 你说的“效率低”，低在哪个环节？是材料收集、规则判断、跨部门流转，还是领导审批？ “合规审查”的依据是什么？有没有明确规则、历史案例或红线条件？
这些问题看起来普通，但它们会逼近需求的真实形态：定义是什么，证据在哪里，边界在哪里，什么情况算通过。所以 Deep Interview 的价值，不是生成漂亮问题清单，而是把粗需求拆成可以现场追问的专业问题。
我们可以把政策文件、业务指南、项目案例和建设方案交给它，要求它：
请基于这些材料，为业务处室和市县业务部门设计需求访谈问题。先输出问题地图，再按不同访谈对象拆成问题清单。问题要能挖出业务目标、现状痛点、流程细节、数据来源、审批规则、系统边界和验收标准。不要替业务部门编答案。
比如针对“智能组合”，它可能会问：当前业务部门形成组合供应项目时，是先有产业需求再反向匹配资源，还是先选定资源再生成组合方案？两种路径对应的是完全不同的产品流程。
传统调研经常问：“你们希望系统实现哪些功能？”这个问题看似合理，其实很难得到好答案。更好的问法是：“你们现在做一个组合供应项目，从发现资源到形成方案，通常经过哪些环节？哪个环节最耗时间？哪些判断必须人工拍板？”这类问题才有机会把隐性知识提取出来。
Deep Interview 不是替代访谈，是让访谈更专业。
OpenSpec Explore：把原始需求整理成设计
调研之后，项目经理通常会得到一堆原始材料：访谈记录、会议纪要、政策依据、业务流程、各方诉求，以及大量待确认问题。这时候可以进入 OpenSpec 的/opsx:explore。
它适合做正式输出前的“探索式整理”：先把问题空间摊开，确认哪些需求还不清楚，哪些模块边界需要确认，哪些能力依赖数据，哪些适合一期做，哪些应该延后。
更重要的是，OpenSpec 可以把探索结果沉淀成一个个真实的change。
比如这个项目里有一个真实 change 叫空间智绘推荐。它不是一句“推荐要更智能”，而是被整理成：
新增“地图绘制范围 -> AI 空间分析 -> 智能推荐”能力。用户绘制多边形范围后，系统分析空间特征，由 AI 生成带空间上下文的推荐理由。
这就把“推荐能不能更精准一点”，翻译成了可以讨论、可以设计、可以开发的系统变化。
另一个 change 叫ranked-combo-batches，处理的是“AI 生成组合方案时，到底怎么推荐、怎么换一批、怎么解释推荐理由”。
原始需求可能只是：“AI 推荐的方案要合理一点。如果不满意，能不能换一批？推荐理由要说得清楚一点。”进入 OpenSpec 后，它会被拆成可验证规则：模式 A 内部排序，用户不满意时返回下一批；模式 B 不再硬凑方案，而是返回失败诊断和调整建议；推荐原因必须基于面积、金额、类型、距离、风险等可追溯事实。
这才是系统设计真正需要的东西。
OpenSpec 的价值不是把调研材料简单改写成 PRD，而是把原始需求整理成：为什么要改，改什么、不改什么，用户怎么操作，系统怎么响应，什么情况算成功，哪些规则可以被验证。
AI 辅助需求调研法
这两个工具串起来，就是一套 AI 辅助需求调研方法。
第一步，收集材料。政策文件、业务报表、历史案例、会议纪要、手工台账都有价值。
第二步，用 Deep Interview 生成访谈问题，并带着问题去访谈。重点不是问“你要什么功能”，而是问清楚目标、流程、痛点、规则、数据来源和成功标准。
第三步，用 OpenSpec Explore 整理成系统设计。基于proposal.md 和客户确认需求，基于design.md 和研发确认方案。
结语
政务信息化项目经理长期处在一个尴尬位置：不能替业务部门决定需求，但如果只是原样转述，研发又没法落地。真正的价值在中间：把业务部门脑子里的模糊经验，通过专业提问提取出来，再整理成研发能理解、业务能确认、项目能推进的系统设计。
过去这件事非常依赖个人经验。AI 工具改变的正是这里：Deep Interview 帮我们提升提问质量，OpenSpec Explore 帮我们提升整理质量。一个负责“问得专业”，一个负责“理得清楚”。
这才是 AI 对项目经理最有价值的地方。