本文介绍一种面向大模型应用开发者的实战技巧：如何只用一套系统提示词，让 AI 在多轮对话中自动根据项目复杂度，逐步挖掘你的真实需求，并最终输出结构化需求文档。所有代码和示例都基于 DeepSeek / GPT 等主流 LLM 可直接运行的纯文本提示词。
1. 背景：AI 辅助开发的痛点
我用 AI 写代码时，经常遇到一个尴尬：第一次提的需求很模糊，AI 快速生成了代码，但往往不符合我脑子里真正想要的东西------要么缺少关键功能，要么异常处理没考虑，要么数据结构不合适。反复修改很浪费 token，而且容易把对话上下文拉得过长。
如果 AI 能在动手写代码前，先像一个有经验的工程师那样，通过多轮对话把我的需求挖清楚，该有多好？
这就是我要分享的东西：一套自适应需求挖掘的提示词系统。它的特点是：
- 多轮对话，层层递进：每次只问 1-2 个最关键的问题，不一次性轰炸用户。
- 动态调整深度：简单项目问得少（3 轮结束），复杂项目自动深入（性能、安全、部署等）。
- 最终输出结构化文档：可直接交给下一阶段的开发型 AI 使用。
整个系统完全基于纯提示词实现，不需要额外代码，你马上就能复制到 ChatGPT 或 DeepSeek Chat 里试试。
2. 核心设计思路
2.1 把 AI 当成一个"引导式需求分析师"
传统需求分析是人工写一份很长的问题清单，让用户填。但用户（尤其是个人开发者）很少能耐着性子写完。多轮对话的优势是：自然、有针对性、不浪费精力。
我给 AI 定的工作模式：
- 用户只说一句模糊的想法。
- AI 每次只问 1-2 个具体的、能大幅减少不确定性的问题。
- 根据用户的回答，在脑海中（内部状态）维护一个"需求维度检查表"，勾掉已覆盖的维度。
- 所有关键维度都覆盖后，立刻停止提问，输出一份标准化的最终需求文档。
2.2 维度检查表与复杂度感知
为了让 AI 知道"什么时候该继续问，什么时候该停"，我设计了一个维度池和复杂度分级：
- 简单项目（单文件脚本、纯本地工具）：只覆盖功能、交互、存储，2~3 轮结束。
- 中等项目（带数据库、网络请求、多模块）：增加性能、异常处理、安全，约 4~5 轮。
- 复杂项目（分布式、多用户、支付/合规）：再增加部署、可测试性、审计等，6 轮以上。
同时，如果用户回答中明显透露出"这个项目很简单"，AI 要自动降级，避免过度设计。
2.3 防止死循环和重复提问
不加约束的 AI 可能会反复问同一个点，或者陷入无意义追问。我在提示词里明确了两条规则：
- 提问前必须回顾已有信息，禁止重复问已明确的事情。
- 连续两轮没有新增有效信息时，直接结束并输出文档。
这样用户体验非常顺滑，不会觉得被冒犯。
3. 开箱即用的系统提示词（System Prompt）
以下就是这套系统的核心。直接复制到你的 LLM 对话系统提示（System Prompt）里，然后开始第一轮对话即可。
text
你是一个资深嵌入式系统需求分析师，擅长用多轮对话逐步挖掘用户的真实需求。
你的工作方式：用户提出一个模糊的项目想法后，你每次只问1~2个最关键的、能大幅缩小不确定性的问题。
你会根据用户的回答，逐步构建对项目的完整理解。
当所有必要维度的信息都充分收集后（或用户主动说"可以了"），你会输出一份结构化的最终需求文档。
行为准则：
1. 每次只问少量问题，且问题必须具体、可回答，避免让用户写大段描述。
2. 问题顺序从核心到外围：先理清"要做什么""谁用""怎么用"，再深入数据、性能、安全等。
3. 动态调整追问深度：如果项目明显简单（如单文件脚本），就少问；如果复杂（如带网络功能的多模块系统），就多问几轮。
4. 你必须维护一个内部的"需求维度检查表"，包含：功能、用户交互、数据存储、性能、异常处理、安全、部署等。每得到一部分答案，就在心中勾掉对应的维度。
5. 提问前回顾已收集的信息，禁止重复问已明确的事情。如果连续两轮用户回答没有新增有效信息，直接进入最终输出。
6. 当所有必要维度都已覆盖，或者用户回复"没了""可以了"，立即停止追问，直接输出以下格式的最终需求文档：
## 项目名称
## 需求背景
## 详细需求（按维度分点，具体、无歧义）
## 验收标准（3~5条可量化条件）
## 技术约束
现在，请用一句简短的话向用户打招呼，然后开始第一轮提问。3.1 针对特定领域的微调
如果你不是做嵌入式，可以把第一行的"嵌入式系统"改成你的领域，比如"Web 全栈开发"、"移动应用"等。甚至可以去掉领域限制，让 AI 通用。
3.2 加入 Few-shot 示例（可选高级优化）
如果发现 AI 在某些场景下追问不够精准，可以在系统提示词中追加一个完整的"输入→理想对话→输出"的示例。这相当于用数据"驯化" AI 的行为边界。示例越具体，生成效果越稳定。
4. 实战演示：一个命令行工具的需求挖掘
假设用户输入：
我想做一个管理嵌入式代码片段的命令行工具。
AI 的追问过程大致如下：
第一轮 （聚焦核心功能）
AI：你希望这个工具支持哪些操作？比如添加、搜索、编辑、删除？还有什么特别想实现的功能吗？
用户：至少添加和搜索，最好能一键复制到剪贴板。
第二轮 （交互和数据）
AI：搜索时按标题还是全文搜索？是否需要给片段打标签分类？
用户：全文搜索，标签肯定要，还想能按芯片型号筛选。
第三轮 （存储和性能）
AI：本地存储还是需要同步？本地你倾向文件还是小型数据库？
用户：本地 SQLite，代码量几百条，性能不用太操心。
第四轮 （异常处理）
AI：存储文件损坏或误删怎么办？需要备份吗？
用户：自动备份到同目录下的 .backup 文件就行。
此时 AI 判断所有必要维度已覆盖，停止追问并输出最终文档：
markdown
## 项目名称
嵌入式代码片段管理器 (Snippet CLI)
## 需求背景
用户需要一个命令行工具来管理常用的嵌入式代码片段，支持快速搜索、标签分类和按芯片型号筛选，可一键复制。
## 详细需求
- 功能：提供 add, search, list, edit, delete, copy 命令；search 支持全文搜索、标签过滤和芯片型号过滤；copy 将结果复制到系统剪贴板。
- 数据存储：本地 SQLite 数据库，自动在同目录生成 .backup 备份文件。
- 交互：CLI 界面，搜索结果列表带序号，用户输入序号即可复制。
- 异常处理：数据库损坏时自动从备份恢复；命令错误时给出友好提示。
- 性能：支持至少 1000 条片段，搜索响应 <200ms。
## 验收标准
1. 执行 add 可交互式添加片段，含标题、代码、标签和芯片型号。
2. 执行 search spi --chip STM32F4 返回匹配片段。
3. 执行 copy 2 将搜索结果第二条复制到剪贴板。
4. 删除数据库文件后重启工具，自动从 .backup 恢复。
5. 所有命令提供 --help 帮助信息。
## 技术约束
无特别约束。这份文档可以直接作为下一个开发型 AI（或人工）的详细需求规格，逻辑清晰、无歧义。
5. 提示词的进一步优化方向
5.1 状态可见化：让 AI 输出中间分析
有时 AI 追问的维度会遗漏。可以在系统提示词中要求，在每轮提问前先输出一个 <thinking> 块，展示当前已收集的维度和下一步计划。这既能帮助 debug，也能稳定生成质量。
5.2 集成复杂度判断的 Few-shot 示例
如果用户只说了一句"做个计算器"，AI 却去问分布式部署，就太蠢了。增加几个不同复杂度项目的完整示例，可以让 AI 更好地把握追问的度。
5.3 将系统改造成可工程化的 Agent
这套系统提示词本质上是一个单 Agent 的状态机。未来如果你用 FastAPI 搭建后端，可以：
- 把会话状态存到 Redis。
- 前端通过 WebSocket 或 HTTP 轮询，一题一答。
- 最终需求文档生成后，自动触发代码生成 Agent。
到那时，你就从"提示词使用者"进化为"Agent 系统开发者"了。
6. 总结
这篇文章展示了一个完整、可落地的自适应挖需提示词系统。核心价值在于：
- 节省 token：不一次性输出冗长问卷，每次只问最必要的问题。
- 提升体验：像和资深工程师聊天一样，思路被引导着走。
- 输出可直接用：最终需求文档结构化，可直接喂给开发型 AI。
- 跨领域复用：改一下领域描述，就能用在 Web、移动端、数据平台等各种项目中。
如果你每天都在和 AI 结对编程，这套提示词或许能成为你工具箱里的"需求澄清标配"。动手试试，也欢迎把你试用后的效果反馈给我。
首发于 掘金 / CSDN，禁止未经许可的转载