你让AI修改一份方案，它顺手调整了已经确认的内容；你让AI分析数据，它给出了结论，却没有说明统计口径；你让AI加一个功能，它完成了开发，却改变了原有行为。
这些结果往往看起来很完整，真正使用时才暴露问题。
原因之一是：我们把任务交给了AI，却把完成任务所需的信息留在了自己脑子里。
同事知道的业务背景，AI未必知道；团队默认遵守的约定，AI未必见过；你认为不言自明的边界，AI可能当作可以自由发挥的空间。
对于开始把AI加入工作的产品经理，以及任何使用AI完成任务的人，首先要建立一个习惯：
交代任务时，把目标、上下文、范围、边界和验收说清楚。
一、目标：你希望改变什么？
“写一份竞品分析”“优化这个页面”“整理用户反馈”，描述的是要做的事情，却没有说明这件事要帮助你解决什么问题。
目标不清楚，AI容易追求一份看起来像样的产出。内容可能丰富，却无法支持你的下一步行动。
例如，你要求：
分析三个竞品的会员体系。
AI可能给你一张很长的功能对比表。但你真正想知道的是：我们的产品是否应该推出付费会员，以及哪些权益值得优先验证。
更有效的说法是：
分析三个竞品的会员体系，帮助我们判断是否值得试验付费会员。重点关注权益差异、价格门槛和用户付费理由，为下一次产品决策提供依据。
目标越明确，AI越容易判断哪些信息重要，哪些内容可以省略。
交代目标时，回答一句话：这份结果将帮助谁，做出什么决定或完成什么行动？
二、上下文：它需要知道哪些事实？
人类同事会从历史讨论、业务经验和日常协作中理解任务。AI能够使用哪些背景，取决于你提供的材料，以及它实际能访问的信息。
一条简单指令背后，可能藏着大量必要条件：
• 产品面向哪些用户？
• 当前采用什么流程？
• 已经做过哪些尝试？
• 数据采用什么统计口径？
• 哪些结论已经确认，哪些仍是假设？
例如，让AI分析“本月转化率下降”，至少需要说明转化率的定义、对比时间段，以及期间是否发生了渠道、价格或埋点变化。否则，它可能把不可比较的数据放在一起，给出貌似合理的解释。
提供上下文也不等于把所有材料一股脑塞进去。优先提供会影响判断的事实，并标明材料的日期、来源和适用范围。
如果资料不足，可以要求AI先列出缺失信息，暂时不要下结论。
三、范围：这次做到哪里？
目标说明方向，范围决定本次任务的大小。
“完善方案”可以意味着修改表达，也可以意味着重做定位、调整价格、增加渠道规划。如果没有限定，AI可能主动扩展任务，让你得到更多内容，也承担更多审查工作。
可以把范围写成三部分：
本次要做什么、暂时不做什么、最终交付什么。
例如：
本次只分析最近一个月的新用户反馈，找出影响首次使用的三个主要问题。暂不讨论老用户留存。输出一页结论，每个问题附上对应的反馈证据和待验证建议。
这种要求既限制了分析范围，也规定了交付形式。
对于复杂任务，最好拆成几个可以检查的阶段：先确认材料和分析方法，再生成初稿，最后完善结果。每一步发现偏差，都比完整产出后推倒重来更容易。
四、边界：哪些内容不能擅自改变？
范围说明要做什么，边界说明执行时必须遵守什么。
这一步尤其容易被忽略。我们通常会告诉AI“增加什么”，却忘记说明“保留什么”。
例如：
• 修改产品方案时，保留已经确认的价格和发布日期。
• 整理访谈时，不编造用户原话，不把推测写成用户意见。
• 分析数据时，不改变指标定义，不擅自填补缺失值。
• 调整功能时，保留现有权限规则和默认行为。
• 撰写内容时，不把未经核实的数字写成事实。
边界还应该包括遇到不确定情况时的处理方式：
如果发现材料冲突，列出冲突并等待确认。
如果需要修改已确认内容，先说明原因和影响。
如果找不到证据，标记为待核实。
关键不是禁止AI提出建议，而是让建议与已经执行的修改区分清楚。
五、验收：你凭什么认为它做对了？
“专业一点”“完整一点”“效果更好”，都很难作为验收标准。
一份结果是否合格，需要有可以检查的依据。
用户反馈分析
每个主要结论都能追溯到原始反馈；事实与推测分开。
数据分析
说明指标口径、计算方法及缺失数据；关键结果可以复核。
产品方案
覆盖目标用户、核心问题、方案取舍和验证方式。
内容写作
核心事实有来源；符合篇幅要求；没有编造案例或引语。
功能开发
满足业务规则；覆盖异常情况；原有行为经过检查。
对于产品经理，还要区分两个层次：
任务完成了吗？产品问题解决了吗？
AI可以按要求完成方案、文案或代码，但用户是否愿意使用、转化是否改善，仍需要真实反馈和数据来验证。
验收产出，是第一步；验证价值，是下一步。
把一句模糊指令，变成一份可执行任务
以整理用户反馈为例。
原来的指令只有一句：
帮我分析这些用户反馈，给一些优化建议。
可以改成：
目标： 帮助产品团队选择下一轮新用户体验优化的重点。
上下文： 材料来自最近一个月的新用户访谈和客服记录。产品正在调整首次使用流程，部分反馈可能对应旧版本，请注意区分。
范围： 找出三个优先讨论的问题，输出问题描述、反馈证据、影响分析和待验证建议。暂不讨论老用户留存。
边界： 不编造用户原话；不把反馈次数等同于用户占比；无法确认的版本信息标记为待核实。
验收： 每个问题都能追溯到原始材料；事实、推测和建议分别标明；说明哪些信息还不足以支持决策。
这份任务说明没有复杂的提示词技巧，但它显著减少了AI自行猜测的空间，也方便你检查结果。
说清楚以后，仍然需要判断
这五件事不需要每次写成长文。低风险的小任务，几句话就够；涉及重要决策、数据结论或系统修改的任务，则值得交代得更完整。
也不要把所有细节都一次性锁死。探索性工作可以给AI更大的发挥空间，但要说明：哪些属于探索，哪些已经确认，哪些必须经过你的审查。
对于使用Scrum的团队，这也是需求细化的一个实际方向：把影响理解和执行的隐含信息补充出来，再根据反馈持续调整。AI可以帮助发现遗漏、提出问题和生成草稿，团队仍需要对产品价值、技术取舍与质量作出判断。
AI让执行变快了，也让含糊的要求更快变成了具体结果。
下一次给AI派活之前，花一分钟检查：
目标是什么？它知道哪些背景？这次做到哪里？哪些内容不能动？最后怎么验收？
这五个问题，决定了你得到的是一份看似完整的答案，还是一份能够进入实际工作的成果。
