进行过内容审计的人都深有体会：当你问AI“我这份资料还有哪些不足”，它常常只会给出一些无关痛痒的建议，比如“建议补充更多细节”。那些真正的业务缺口——比如用户反复投诉却从未在文档中体现的交互流程、竞品早已上线而自身方案仍然空白的核心功能、每次合规审查都被标注为“缺乏依据”的流程环节——这些靠笼统的提问方式根本挖掘不出来。你需要把真实的应用场景像钉子一样牢牢嵌入提示词中，迫使模型无法回避。

将业务场景嵌入提示词开篇

第一步：用“作为【特定角色】正在执行【具体任务】”来锁定上下文。举个例子：“作为SaaS产品运营负责人，正在为Q3客户成功手册补充服务触点检查清单”。但仅靠这一句还不够。

第二步：紧接着明确动作发生的物理或系统环境。例如：“该手册将嵌入客户登录后的Help Center弹窗页面，用户平均停留时间仅为47秒”。这样一来，模型就清楚它生成的内容必须适配如此短暂的使用窗口。

第三步：添加一条不可逾越的硬性约束。例如：“所有识别出的缺口必须符合以下条件：能够在5秒内被一线客服利用现有CRM字段调取对应的解决方案”。请注意，如果不加上这一句，Perplexity可能会列出需要新建数据库才能支撑的“理想化”缺口——这类方案看上去很完美，但永远无法落地执行。

用真实失败案例替代空泛的问题描述

空泛的问题描述很容易被AI“美化”成理论层面的不足，只有提供真实案例才能促使其直面现实。以下是三种可操作的方法：

方法一：直接复制一段真实的用户反馈原文（不超过三行），并加上引导语：“基于以下真实工单记录识别内容缺口：……”然后附上工单内容。不要自行总结，原始文本最具说服力。

方法二：复述一次内部会议中的矛盾点。例如：“在昨天的跨部门对齐会上，实施团队指出‘无法向客户演示API错误码映射逻辑’，而技术文档中仅说明‘支持标准HTTP状态码’”。这种会议中暴露的矛盾本身就是缺口的位置标识。

方法三：引用已有材料中的实际缺陷。例如：“对照《2024年GDPR数据删除SOP》第3.2条要求，检查当前客户自助删除页面中缺少‘删除影响范围可视化提示’这一环节”。用现成的标准去对照现有内容，缺口自然显现。

强制输出带有验证路径的结果

仅仅识别缺口还不够，必须确保每个缺口都可追溯、可验证、可执行。

第一步：明确要求Perplexity返回的每个缺口都必须附带验证方法。例如：“每条缺口后标注：①验证来源（如某次用户访谈录音时间戳/某份审计报告条款号）；②当前缺失位置（如帮助中心URL路径/内部Wiki页标题）”。

第二步：限定验证操作必须具体可行。验证方式不能是“查阅更多资料”这类笼统表述，而必须是“打开Chrome访问XX链接→点击右上角‘反馈’按钮→查看弹窗中是否出现‘导出日志’选项”这样精确的操作指令。

第三步：杜绝模糊表述。禁止使用“部分用户”“某些场景”这类来源不明的词语。如果涉及用户群体，必须写明“使用iOS 17+设备且开启屏幕朗读功能的视障用户”这类可查证的条件。只有严格到这一步，AI生成的缺口才具备真正的业务价值。