非技术用户提的需求，怎么知道离能开发还差多远

一句话

提需求的人最缺的不是文档模板，是知道自己离「能开发」还差多远。把差距量化出来，需求才谈得下去。

场景

一个不懂技术的人，想让人做一个东西。他能说出来的通常只有一句话：「我想要个能管客户的小工具」。

这句话离「能开发」差着十万八千里，但他自己不知道差在哪——不知道还要交代什么、哪些决定必须他来做、做到什么程度算完。于是常见的结局是：开发的人凭猜做了一版，做出来不是他要的，两边都耗。

这类场景在你接活的时候天天出现：甲方不是不配合，是不知道该配合什么。

原来怎么做

要么靠开发方一遍遍追问（人肉澄清，慢且看运气），要么直接用 AI 写一份需求文档。

后者的坑在于：AI 写出来的需求书看起来很像样，但你无法判断它靠不靠谱——它不会告诉你哪里是猜的、哪里还缺决定。一份看着完整、实际有洞的需求书，比没有更危险——它会让人以为已经想清楚了。

真正的难在哪

以为难点是「让 AI 会写需求文档」，做起来才发现真正的难点有三条：

一、AI 一开口就问技术选型，非技术用户当场就废了。 这是最关键的一条。用户说不清「用 React 还是 Vue」，但一定能说清「用户是在手机上用还是电脑上用」。所以定了条硬规矩：提问只允许用业务语言，禁止直接问技术选型，并且配了对照表——❌「你想用 React 还是 Vue？」→ ✅「用户主要通过什么方式使用？网页 / 手机 / 桌面？」

二、打分最容易变成空话。 给需求书打分这件事，一不小心就成了一句「完整性不足」。所以评估报告必须引用原文 + 给具体建议：指出哪一句不完整、缺什么、建议补成什么样。不能引用的评分，就是耍流氓。

三、追问会无限循环。 用户答不完，AI 就一直问。必须有退出机制：最大轮次 + 用户可以强制通过——允许"先带着已知的风险往下走"，因为这个决定权本来就在用户手里。

我的做法

• 七到十个问题分层澄清，必答与选答分开，问题按项目内容现生成、不做死模板。
• 生成需求书 → 拆成工单 → 五维打分（完整性 / 一致性 / 可衡量性 / 可行性 / 工程化准备），再逐条改进：每条改进用户都可以选「接受建议 / 手动改 / 跳过 / 不同意」——改不改由用户定。
• 改完之后重新评估，分数要能看到变化。工单跟着需求书联动更新，并保留版本历史与回退。
• 输出中立文件（Markdown / JSON），不绑定任何一个工具链、不直接改本地项目文件。 它只负责「梳理」，不负责「代做」——这个克制是它能被信任的原因。
• 同一套方法论做两种载体：有界面的 Web 版用来给人用；无界面的流程版（14 个可复用 Skill 包 + 模板）用来交给 AI 按步骤执行。说明"流程"和"界面"本来就是两件事。

结果与验收标准

• 63 个代码文件、5,420 行；19 个测试文件、1,581 行；交付说明记录 67 项测试通过、0 失败。
• 文档 54 份、约 14.2 万字——含一份 1000 多行的产品设计讨论记录，覆盖澄清 → 技术面分析 → 工程化拆解三个阶段。文档与代码之比是这批项目里最高的，因为这个项目的产出主要就是"把话说清楚"。
• 有三份现成的报告样例：评估报告、评审报告、技术面评审。
• 待填：一次完整梳理实际需要多少分钟
• 待填：实际有多少人用过、反馈如何

验收标准我定的是三条：提问里不许出现技术选型词；每条评估意见必须引用原文并给出具体改法；任何一轮都必须允许用户强制通过。

可复用的方法论

1. 把"差距"变成看得见的分数。 人不会因为被告知"你还需要想清楚"而改进，但会因为看到"这条 2 分、那条 4 分"而动手。
2. 提问的语言决定对方能不能参与。 用对方的语言问，他答得上来；用你的语言问，他只会沉默。
3. 给用户留"带着风险往下走"的出口。 工具不该替人做最终决定，尤其是"够不够了"这种判断。

能力标签

需求澄清 ｜ 五维评估 ｜ 工单拆分 ｜ React ｜ Node.js ｜ 中立文件输出 ｜ 流程包

依据

• 三阶段方法论、提问语言原则、澄清流程设计：../14 Xiangmu Zhushou/需求梳理助手-设计讨论记录.md
• 澄清规则与提问设计：../14 Xiangmu Zhushou/web-version/docs/requirement-clarification.md
• 评估报告的形态与五维口径：../14 Xiangmu Zhushou/web-version/reports/evaluation-report.md
• 双版本形态与测试结论：../14 Xiangmu Zhushou/web-version/README.md
• 仓库规模、文档份数与 Skill 包：../14 Xiangmu Zhushou