向 AI 提出需求后，不要急着让它立刻执行。一个简单却常被忽略的技巧是：让 AI 先向你提问，把模糊的需求打磨清晰。需求越明确，AI 的执行效果就越好。这不是理论，而是每天和 AI 协作的工程实践中，投入产出比最高的习惯。
为什么初始需求总是不完整
我们向 AI 提需求时，大脑往往只有"目标轮廓"，缺少实现所需的细节。这不是表达能力的问题，而是人类思维的本质——我们习惯在上下文中省略自认为"显然"的信息。
用户："帮我写一个数据清洗脚本"
AI 的内心独白：
- 什么格式的数据？CSV/JSON/数据库？
- 数据量多大？100行还是100万行？
- 清洗规则是什么？去重？缺失值？异常值？
- 输出格式要求？
- 性能要求？需要并行处理吗？
AI 面对模糊需求时，只能做两件事：
- 猜测——基于概率选一个最常见的路径，但很可能不是你要的
- 泛化——写一个"什么都能做但什么都不精"的通用方案
两种结果都不理想。
让 AI 向你提问：一个简单的 Prompt 模式
解决这个问题的方法极其简单——在需求后面加一句话：
"在开始之前，请先向我提问，确认所有你需要的细节。"
就这么一句。但它会彻底改变 AI 的行为模式。
对比案例
模式 A：直接执行（模糊需求）
用户：帮我写一个定时备份脚本
AI：好的，这是一个使用 cron 和 rsync 的备份脚本...
结果：脚本可能备份了错误的目录、没有考虑增量备份、没有错误通知、没有日志轮转。
模式 B：提问澄清后再执行
用户：帮我写一个定时备份脚本。在开始之前，请先向我提问，确认所有你需要的细节。
AI：好的，在编写脚本之前，我需要了解以下几点：
1. 需要备份哪些目录或文件？
2. 备份目标位置是哪里？（本地磁盘/NAS/云存储）
3. 备份频率？（每小时/每天/每周）
4. 需要增量备份还是全量备份？
5. 备份失败时如何通知你？
6. 需要保留多少历史版本？
7. 对备份速度有要求吗？数据量大概多大？
用户：
1. /home/hugo/Projects 和 /home/hugo/Documents
2. NAS，挂载在 /mnt/nas/backup
3. 每天凌晨2点
4. 增量备份，每周日全量
5. 钉钉机器人通知
6. 保留30天
7. 大约50GB，2小时内完成即可
AI：好的，基于你的需求，以下是完整的备份方案...
结果：脚本精准匹配需求，一次可用，不需要反复修改。
更多实战案例
备份脚本是技术场景。但这个技巧的威力远不止于此。以下是几个不同领域的真实案例，展示"让 AI 先提问"如何显著提升输出质量。
案例一：HR 人才评估报告
模糊需求直接执行：
HR：帮我写一份高级前端工程师的人才评估报告
AI：好的，以下是一份评估报告模板...
结果：AI 生成了一份泛泛的模板——技术能力、沟通能力、团队协作，每条评价都是"该候选人表现良好"。这份报告无法用于实际的晋升决策，因为缺少具体的评估维度、业务场景和量化标准。
提问澄清后执行：
HR：帮我写一份高级前端工程师的人才评估报告。请先向我提问，确认评估的关键维度。
AI：好的，在撰写报告之前，我需要了解：
1. 这位候选人的核心职责是什么？（业务线/技术方向）
2. 评估用于什么场景？（晋升/绩效/招聘录用）
3. 有哪些具体的项目成果可以引用？
4. 技术栈要求是什么？（React/Vue/Node.js/其他）
5. 除了技术能力，还需要评估哪些软技能？
6. 评估报告的读者是谁？（技术主管/HRBP/高管）
7. 需要量化评分吗？评分标准是什么？
HR：
1. 负责钉钉文档前端，主攻协同编辑和性能优化
2. P7 升 P8 晋升评审
3. 主导了文档加载速度优化，首屏从 3s 降到 0.8s
4. React + TypeScript + WebWorker
5. 技术影响力、跨团队协作、mentorship
6. 技术委员会 + HRBP
7. 需要，5 分制，附带具体证据
AI：好的，以下是针对该候选人的晋升评估报告...
结果：报告精准聚焦晋升场景，每个评估维度都有具体项目数据支撑，技术影响力部分引用了真实的性能优化成果。评审委员会可以直接基于这份报告做决策，无需补充材料。
关键差异： 模糊需求下，AI 不知道"高级前端"在你们公司意味着什么，不知道 P7 和 P8 的能力差距在哪里，更不知道钉钉文档这个业务场景的特殊性。提问把这些隐含的组织上下文全部显式化了。
案例二：产品经理写 PRD
模糊需求直接执行：
PM：帮我写一个智能待办功能的产品需求文档
AI：好的，以下是 PRD...
结果：PRD 包含了功能概述、用户故事、界面描述，但全是通用内容。没有考虑你们产品的用户画像、技术约束、数据隐私要求、与现有功能的集成方式。开发团队拿到后问了一堆问题，PRD 被打回重写。
提问澄清后执行：
PM：帮我写一个智能待办功能的产品需求文档。请先向我提问，确认所有关键细节。
AI：好的，在撰写 PRD 之前，我需要了解：
1. 目标用户是谁？（企业用户/个人用户/特定角色）
2. "智能"具体指什么能力？（NLP 解析/优先级排序/自动提醒/其他）
3. 待办数据的来源是什么？（手动创建/邮件解析/会议记录/审批流转）
4. 有哪些技术约束？（端侧模型/云端 API/混合）
5. 数据隐私和合规要求？
6. 需要和哪些现有功能集成？
7. 成功的衡量指标是什么？
8. 优先级：MVP 包含哪些功能？哪些放后续版本？
PM：
1. 钉钉企业用户，主要是管理者和项目成员
2. NLP 解析（自然语言创建）+ 智能优先级排序
3. 手动创建 + 群聊消息转待办 + 审批流转
4. 端侧小模型做 NLP 解析，云端做大模型优先级排序
5. 企业数据不出域，符合 GDPR
6. 集成钉钉日历、项目、审批
7. 待办创建效率提升 50%，完成率提升 30%
8. MVP：NLP 创建 + 优先级排序；V2：群聊转待办 + 审批集成
AI：好的，以下是完整的 PRD...
结果：PRD 直接可用。开发团队拿到后没有返工，因为技术约束、集成方式、MVP 范围都已明确。产品评审一次通过。
案例三：市场营销活动方案
模糊需求直接执行：
市场：帮我写一个 618 大促的活动策划方案
AI：好的，以下是方案...
结果：方案包含活动背景、目标、玩法、预算分配，但全是行业通用模板。没有考虑品牌定位、目标客群、渠道资源、历史数据、竞品动作。方案看起来"什么都有"，但"什么都不能直接用"。
提问澄清后执行：
市场：帮我写一个 618 大促的活动策划方案。请先向我提问，确认关键信息。
AI：好的，在策划之前，我需要了解：
1. 品牌/产品是什么？客单价区间？
2. 目标客群画像？（年龄/地域/消费习惯）
3. 核心目标是什么？（GMV/拉新/清库存/品牌曝光）
4. 可用渠道有哪些？（天猫/抖音/私域/线下）
5. 预算范围？
6. 去年 618 的数据和教训？
7. 主要竞品今年可能做什么？
8. 供应链能否支撑爆发？发货能力？
市场：
1. 智能办公硬件，客单价 200-800 元
2. 25-40 岁职场人，一二线城市，注重效率
3. 核心目标 GMV 500 万，次要目标拉新 2 万
4. 天猫旗舰店 + 抖音直播 + 钉钉私域社群
5. 营销预算 50 万
6. 去年 GMV 300 万，教训：库存预估不足，爆款断货
7. 竞品 A 可能做满减，竞品 B 可能做联名款
8. 供应链 OK，日发货能力 5000 单
AI：好的，以下是针对性的 618 策划方案...
结果：方案直接对齐业务目标，预算分配基于渠道 ROI 历史数据，库存计划参考了去年的教训，竞品应对策略有针对性。方案评审时，老板直接签字通过。
提问澄清的工作流程
┌─────────────┐
│ 用户提需求 │
└──────┬──────┘
│
v
┌─────────────────┐
│ AI 列出待确认问题 │◄─── 关键步骤
└──────┬──────────┘
│
v
┌─────────────┐
│ 用户逐一回答 │
└──────┬──────┘
│
v
┌─────────────────┐
│ AI 确认理解无误 │
└──────┬──────────┘
│
v
┌─────────────┐
│ AI 开始执行 │
└─────────────┘
这个流程的核心在于把"猜测-返工"的循环前置到"提问-确认"阶段。返工的成本远高于多问几个问题。
实战技巧
技巧 1：设定提问的边界
有时候 AI 会问太多问题，陷入过度澄清。你可以设定边界：
"请先列出你最需要确认的 3-5 个关键问题，不要超过 5 个。"
这样既保证了关键信息的收集，又不会让对话变得冗长。
技巧 2：分阶段澄清
对于复杂需求，可以分阶段进行：
"这是一个多阶段项目。请先针对第一阶段（数据接入）向我提问，
确认后再进入下一阶段。"
技巧 3：让 AI 复述需求
在 AI 提问完毕、开始执行之前，让它复述一遍完整需求：
"在开始编码之前，请用你自己的话总结一下我的完整需求，
确保我们理解一致。"
这一步能捕获最后的理解偏差。
技巧 4：提供"不知道"的出口
有些细节你可能还没想好。告诉 AI 哪些是确定的，哪些可以它自己决定：
"1-4 是我的明确要求。5-7 我还没有想法，你可以基于最佳实践给出建议。"
为什么这个技巧如此有效
信息论视角
模糊需求的信息熵很高。AI 的每个问题都在降低熵值，直到信息足够确定一个具体的实现路径。
初始需求："写个备份脚本" → 熵值高，可能方案 >1000 种
澄清后："增量备份50GB到NAS..." → 熵值低，可能方案 <10 种
认知科学视角
人类在描述需求时存在"知识的诅咒"（Curse of Knowledge）——你知道的太多，以至于忘记了别人（或 AI）不知道什么。AI 的提问帮你打破这个诅咒，把隐含的假设显式化。
工程视角
在软件工程中，需求澄清是需求分析阶段的核心工作。跳过这一步，直接进入实现，是项目失败的最常见原因之一。AI 协作也不例外。
常见误区
误区 1：“AI 应该能猜到我的意思”
AI 确实有一定的推理能力，但"猜"意味着概率分布。你的需求落在概率峰值上的可能性，远小于落在长尾区域的可能性。
误区 2：“问太多问题效率低”
提问花 2 分钟，返工花 20 分钟。哪个效率低？
误区 3：“我已经说得很清楚了”
你可能觉得清楚了，但 AI 的"清楚"和人类的"清楚"标准不同。AI 需要的是可执行的明确性，而不是人类语境下的合理理解。
总结
| 维度 | 直接执行 | 提问澄清后执行 |
|---|---|---|
| 首次可用率 | 低（20-40%） | 高（70-90%） |
| 返工次数 | 2-5 次 | 0-1 次 |
| 总耗时 | 长 | 短 |
| 结果质量 | 泛化/猜测 | 精准匹配 |
| 用户满意度 | 低 | 高 |
让 AI 向你提问，不是 AI 能力不足的表现，而是高效人机协作的基本功。下次使用悟空或任何 AI Agent 时，试试在需求末尾加上：
“在开始之前，请先向我提问，确认所有你需要的细节。”
你会发现，AI 突然变"聪明"了。其实它一直都很聪明，只是你终于给了它足够的信息来发挥。
你在和 AI 协作时有什么高效的需求表达方式？欢迎在评论区分享。