在竞品分析中，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端隐性痛点

【核心逻辑】：

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更好的赋能我们。