在竞品分析中，AI的真正价值不在于它能否找到数据，而在于我们如何「喂料」和「定框架」。本文揭秘两个超预期的Prompt模板，专攻B端产品的功能设计与隐性痛点分析，分享如何让AI像资深架构师一样反推底层逻辑，从帮助文档、更新日志中挖掘竞品的设计缺陷与亮点。
单纯扔给 AI 一个竞品名字，让它写竞品分析，得到的结果通常是垃圾，全是官话套话，甚至数据是编的。
但如果你懂「喂料」和「定框架」，AI 能做出让你惊掉下巴的深度分析。
不要让 AI 去找数据，它找不到B端内部逻辑，要让 AI 去处理数据和推演逻辑。
分享两个超预期竞品分析 Prompt 模板（后面有我的实操案例）：
【适用场景】：
你截了几张竞品后台的图，或者体验了它的某个流程（比如合思的单据审批），想分析它背后的深意。
【常规 Prompt】：
分析一下合思产品的单据审批功能。（结果：泛泛而谈）
【超预期 Prompt】：
角色：你是一位拥有 10 年经验的 B 端产品架构师，擅长透过 UI 看本质。
背景：我正在研究 [竞品名称] 的 [具体功能] 功能。
输入数据：我给你发送[n]张该功能的截图（或者我把操作流程描述给你：步骤1…步骤2…）。
任务：请进行深度解构分析：
1.信息架构还原：根据截图，反推它的底层数据库实体关系（ER图猜想），是一对一还是一对多？
2.设计意图推演：它为什么把 [A按钮] 放在这里而不是那里？是为了解决什么具体的业务痛点？或者是为了规避什么风险？
3.异常流程侦探：基于你的经验，预测一下这个设计在 [极端场景，如：并发/权限隔离] 下可能存在什么隐患？
4.抄作业指南：如果我们也要做这个功能，哪一点是绝对值得抄的（亮点），哪一点是必须改进的（槽点）？
【为什么能超预期？】
因为把 AI 强行按在了架构师的位置上，并且逼它反推底层逻辑。这对于 B 端 PM 来说，比看界面更有价值。
【核心逻辑】：
B 端产品哪里最痛？帮助文档写得越长、越绕的地方，通常就是产品设计最失败、用户最痛的地方。 或者是那些更新日志里反复优化却总修不好的模块。
【适用场景】：
你找到了竞品的帮助中心链接或操作手册PDF。
【超预期 Prompt】：
角色：你是一位资深的实施交付专家，专门负责给客户擦屁股，处理难用的系统。
背景：我正在分析竞品 [A产品] 的 [XX模块]。
输入数据：
1.我复制给你的该功能的官方帮助文档/操作手册内容（越长越好）。
2.或者：该模块过去一年的更新日志。
任务：请透过文档看本质，帮我进行“痛点验尸”：
1.认知负荷检测：文档中哪些步骤解释得异常复杂（比如用了大量“注意”、“务必”、“仅支持”等警示词）？这暗示了该功能在交互设计上存在什么反直觉的设计？
2.“伪需求”鉴定：有没有哪些配置项在文档里写得天花乱坠，但在实际业务中几乎无法落地（因为前置条件太苛刻）？
3.技术债反推：(基于更新日志) 有哪个功能点在过去一年里被反复“修复”或“优化”了 3 次以上？请推断该模块底层可能存在什么架构缺陷（如数据一致性问题、性能瓶颈）？
4.销售攻击话术：如果我是你的竞对，基于上述分析，我去打单时，应该如何一针见血地指出这个产品的弱点，让客户觉得“还是你们懂行”？
【为什么能超预期？】
数据源真实可得：B 端竞品的后台进不去，但帮助文档通常是公开的，你懂得（为了SEO）。
逻辑反证：
1.C 端追求“零说明书”上手。
2.B 端如果说明书像天书，说明产品经理把复杂留给了用户。
3.AI 非常擅长分析文本的晦涩程度，从而帮助定位竞品的糟糕设计。
这里我分享一下针对第一个prompt的实操案例，因为篇幅太长，第二个就不放了，感兴趣的可以自行动手测试效果，行动是第一生产力，相信你会发现新大陆。
我截了5张合思单据审批功能的五张截图，配上我的提示词，发给AI：
下面是AI输出的分析内容，大家感受一下：
你好，我是你的 B 端产品架构师搭档。
收到你发来的 5 张合思（原易快报）的“单据审批”功能截图。合思作为国内报销费控领域的头部 SaaS，其审批设计非常具有代表性：它不是为了“走流程”而设计，而是为了“高频作业”而设计。
下面我将透过这些 UI 表象，为你深度解构其背后的逻辑。
1. 信息架构还原：ER 图猜想（底层实体关系）
从截图 4 和 5 的筛选逻辑，以及截图 1 的列表展示，我们可以反推其底层极其灵活的数据模型。
●核心实体猜想：
* 单据 (Bill/Document)：这是主表，包含单号、标题、提交人、日期等基础字段。
* 表单模板 (Form Template)：截图 1 中的“单据模板”列说明系统支持多种业务单据（差旅、采购、借款）。
* 表单字段 (Form Field)：截图 5 中的“费用承担部门”说明字段是动态配置的，不是硬编码在单据主表里的。
* 视图/筛选器 (View/Filter)：截图 4 是一个独立的实体配置，存储了查询条件的 JSON 结构。
●ER 关系推演：
* 单据 <-> 模板：多对一。
* 单据 <-> 字段值：一对多。
（EAV 模型，Entity-Attribute-Value）。这是 B 端复杂系统的典型特征，为了支持自定义字段查询（如图 5），底层索引设计难度很大。
* 用户 <-> 视图配置：一对多。
每个用户可以定义多套“快速筛选”方案，且支持“与/或”的复杂逻辑嵌套。
2. 设计意图推演：为什么这么做？
这里有三个极具深意的交互细节，分别解决了三个不同的痛点：
A. “连续审批”开关（截图 1 & 3 右上角）
●痛点：财务或高管每天要批几十甚至上百个单子。传统的“点击列表 -> 进入详情 -> 点击同意 -> 返回列表 -> 再点下一个”路径，每一次“返回列表”都是一次思路的中断和时间的浪费。
●设计意图：沉浸式作业模式。
打开开关后，系统预加载（Prefetch）逻辑生效。用户点完“同意”，直接滑入下一张单据，不需要回退。这把“审批”变成了像刷抖音一样的“流式操作”，极大提升了高频审批场景的效率。
B. 搜索框里的“扫码枪”图标（截图 2）
●痛点：财务场景特有的“O2O”断层。财务桌子上堆着一叠纸质报销单（贴好发票的），她需要核对纸质单和系统单据。如果一个个输单号，会疯掉。
●设计意图：软硬结合。
支持 USB 扫码枪。财务拿起纸质单据扫一下二维码，系统列表立刻定位到该单据。那个“出错弹窗提示”复选框，是为了在批量扫码时，遇到扫不出来的单子能通过声音或强弹窗打断财务，防止漏单。这是一个非常懂线下财务作业场景的设计。
C. “与/或” 组合筛选器（截图 5）
●痛点：审批列表不仅是待办，更是台账。领导想看“A部门且金额>1万”或者“B部门或C部门的招待费”。
●设计意图：低代码化的查询能力下放。
它把 SQL 的 `WHERE (A AND B) OR C` 逻辑图形化了。虽然对小白用户有门槛，但对于经常查数的财务主管，这是神技，避免了反复找 IT 导出 Excel 做透视表。
3. 异常流程侦探：潜在隐患与极端场景
作为架构师，我看到了这套强大系统背后可能存在的“坑”：
●并发状态一致性（Race Condition）：
在“连续审批”模式下，假设用户 A 打开了单据 X，正在看。此时提交人撤回了单据，或者即时通讯里另一个审批人 B 已经拒掉了。当 A 点击“同意”时，系统是报错提示“单据状态已变”，还是直接静默失败？
隐患*：如果处理不好，用户会觉得“我明明批了，怎么没生效”。
●扫码枪的“幽灵输入”：
扫码枪本质上是一个模拟键盘输入的设备。如果光标焦点不在搜索框里（比如焦点在浏览器的地址栏），财务一扫码，单号就会变成 URL 跳转，或者输入到其他输入框里造成数据污染。
隐患*：需要前端做全局键盘事件监听捕获，或者强制聚焦逻辑。
●复杂筛选导致的慢查询：
截图 5 允许用户自定义“与/或”嵌套。如果用户搞了一个 `(A or B) and (C or D) and …` 的 5 层嵌套，且涉及非索引字段（如备注文本），可能会导致数据库慢查询（Slow SQL），甚至拖垮整个列表页的加载速度。
隐患*：需要后端做查询超时熔断或限制嵌套层级。
4. 抄作业指南：亮点与槽点
如果我们要做审批中心，以下是我的建议：
绝对值得抄的亮点（Must Have）
1. 连续审批（沉浸模式）：
如果你的用户有日均审批 > 20 单的角色，这个功能是Killer Feature。它体现了你对“高频作业”的尊重。
2. 底部固定操作栏（截图 3）：
在批量模式下，底部浮出操作栏（同意、驳回、打印、导出）。这比放在顶部更符合由上至下的阅读顺序，也更容易点击（费茨定律）。
3. 扫码录入适配：
如果你的系统涉及“实物流转”（如合同原件、发票、入库单），请务必加上这个扫码枪图标和逻辑，懂行的客户看到这个细节会感动。
必须改进的槽点（Should Improve）
1. 筛选器交互过于“工程师思维”（截图 5）：
那个“与/或”的模块化设计虽然强大，但对普通行政或销售主管来说，认知负荷太重。
优化建议*：参考飞书多维表格或 Notion 的筛选交互，使用更自然的语言描述，或者提供“常用筛选推荐”。
2. 列表信息密度过高（截图 1）：
纯表格形式虽然紧凑，但在宽屏下阅读体验一般。
优化建议*：可以提供“卡片视图”或“摘要视图”，突出关键信息（如金额、摘要），弱化单号等次要信息。
总结：合思的这套设计，“财务味儿”很浓，效率至上。它牺牲了一部分易用性（复杂的筛选），换取了极致的专业性（扫码、连续批、高级查）。做 B 端产品，场景决定了交互的上限，这套设计在其特定领域是非常优秀的。
用AI 做竞品分析也是有局限性的，它没有账号，进不去竞品的后台，除非你截图给它。对于复杂的 B 端产品，截图喂养是必须的，也不要问 AI 竞品的一些经营数据，除非官网公开，问这些，AI 为了满足你，一定会开始编造数据。还有AI 无法感受交互的流畅度，比如卡顿、等待加载时间久等。所以作为有主观意识判断的人，要和AI分工明确，各司其职，让AI更好的赋能我们。
作者：PM超进化 公众号：PM超进化
本文由 @PM超进化 原创发布于人人都是产品经理，未经授权，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。