市面上关于“产品经理+AI”的讨论，往往集中在竞品调研（写八股文报告）或一键生成高保真UI上，亦或是在营销产品经理如何玩 Vibe Coding，不再需要研发协助之类的。

但对于我们这些偏传统的B端/中后台产品经理而言，我们的核心价值从来不是画出多么精美的界面，更不是代替研发去写代码，而是业务逻辑的闭环、复杂规则的定义以及系统交互的准确性。

“B 端产品的护城河不在于原型画得有多高保真，而在于业务逻辑的闭环与异常流程的防御。Gemini 擅长的正是逻辑，而非审美。”

本文不谈虚的，只分享我如何使用 Google Gemini 全家桶来重构产品经理的日常工作流，利用 AI 提升逻辑产出的效率。

0 为什么选择Gemini？

在尝试了各类 LLM 后，我认为，对于需要处理复杂业务逻辑的中后台 PM 来说，Gemini 有几个无法替代的优势：

• 超长上下文：中后台系统的业务链条极长，Gemini 能在一个对话框内持续消化几万字的上下文而不产生幻觉，这对迭代长文档至关重要。
• 搜索与知识整合：依托 Google 强大的搜索能力，在查询海外 SaaS 解决方案、API 文档或技术标准时，其准确性远超竞品。具体到我个人而言，我过去一年做的都是国外项目，需要围绕Shopify平台以及周边SaaS生态来做各种对接集成，Gemini 帮了我很大的忙。
• Canvas 交互画布：这是本文的重点。我知道 Gemini 在程序员眼里并非最适用于编码的 AI，但 Gemini 的前端代码生成能力确实极强，非常适合直接生成HTML交互原型。中后台系统不需要什么高保真的原型设计，无非就是列表啊，表单之类的，Gemini 完全能够胜任。说实话，我已经有一年时间没有用过传统的原型工具了（如Axure RP）。

1 使用环境优化：固定IP访问Gemini

不管你是白嫖的 Gemini 账号还是正规付费购买的，避不开的一个问题就是网络环境。从风控角度考虑，建议固定 IP（首选美国）来访问 Gemini，避免被封号。

这说起来容易，做起来。。。好吧其实也不难。我相信能访问 Gemini 的人自然知道如何出海冲浪，但大部分人都是使用共享 IP。多人共用的 IP 无法保证稳定性，所以自己买个（美国）VPS 搭建一个出海服务，是必须的。

• 如果你嫌麻烦，可以用“链式代理”方式来解决（Clash 系的客户端基本都支持此方式），随便买个廉价的服务做前置，然后跳转你自己的固定 IP 去访问 Gemini。
• 如果你愿意折腾，有一种更小众的方式，那就是“流量中转/端口转发”方式（可以参考这篇文章）。

我自己的使用方式参考：通过专门的浏览器（如 Firefox）来使用 Gemini，让代理接管此浏览器的全局流量；平时的工作浏览器（如 Chrome）不受干扰。这是因为我习惯用美国 IP 访问 Gemini，但是我日常出海一般用香港 IP（不管是在家里还是在公司网络，默认都可用香港 IP 访问 Google），为了避免干扰，我决定分开两个浏览器的使用场景。

2 必备：打造你的专属AI产品助理 (Gemini Gems)

很多时候我们觉得AI“也就那样吧”，是因为我们把它当成了搜索引擎，而不是“员工”。

“AI 不应该只是一个比以前更聪明的搜索引擎，它应该被定义为你的虚拟员工——需要 onboarding（入职培训），需要 SOP（操作规范），也需要 Review（绩效考核）。”

Gemini 推出的 Gems 功能，允许我们预设一套复杂的 System Instructions（系统指令）。这其实是在用写代码的逻辑来写提示词（Prompt as Code）：我们需要定义变量（角色/背景）、定义函数/Skill（评审/绘图能力）、甚至定义异常处理（如何处理幻觉/如何回滚）。

为了适应中后台复杂的产研流程，我创建了一个名为 "PRD 助手" 的 Gem。在这个 Gem 中，我不只是简单地告诉它“你是一名资深的产品经理”，而是写入了多条严格的执行协议。

• Name：PRD助手
• Description：专为跨境电商PM打造的Canvas增强版Copilot。核心能力：1. PRD（Markdown）与交互原型（HTML）双向同步与版本管理；2. 精通Shopify/OMS/ERP集成逻辑与用户故事拆解；3. 内置“虚拟评审团”(/review)与“预案-确认”防重构协议，确保系统设计规范、严谨、可落地。
• Default tool：选Canvas（这样新开的对话会默认激活右侧的画布，方便后续渲染PRD或者原型）
• Instructions：参考如下

你是 **电商PRD/原型专家 (Canvas Pro)**，一位精通 Shopify 前端交互与复杂后端系统（ERP, OMS, WMS, RMA）集成的资深架构师。你的核心职责是利用 Gemini Canvas 的特性，辅助我实现 **“文档+原型”** 的双向设计与全生命周期管理。

请严格遵守以下核心行为准则（System Instructions）：

### 0. 初始化与引导协议 (Initial Protocol) - [HIGHEST PRIORITY]
* **首句拦截机制**：在对话开始后的**第一句交互**（无论我发送的内容是什么，哪怕是具体的业务需求），请**完全忽略**对该内容的业务推理或处理。
* **强制版本检查**：请务必先输出以下提示（Markdown 引用格式），并暂停后续动作：
> **模型效能检查**
>
> 复杂的 PRD 撰写与交互式原型生成需要强大的推理能力。**请确认您当前使用的是 Gemini 3 Pro 或 Thinking 模型，输出效果会更好**。
>
> *请在确认完毕后回复“OK”或者“好的”，我们即可继续对话。*
* **解锁条件**：只有在我回复了确认指令（如“OK”、“好的”）之后，你才解锁后续功能，并引导我重新输入或开始处理真正的业务需求。

### 1. 语言规范
* **全中文写作**：PRD的所有内容（包括标题、正文、备注）必须使用中文。
* **例外情况**：仅允许使用行业通用的专业英文缩写术语（如 SKU, API, ERP, RMA, Shopify, webhook 等）。绝不允许出现中英文混杂的标题（如 "Introduction 介绍"）。

### 2. 文档结构与内容要求
撰写的PRD必须包含以下核心章节：
1. **版本变更记录**：位于文档最顶部（规则见下文）。
2. **项目背景**：清晰描述业务现状及发起该需求的动因。
3. **项目收益**：必须包含定性或定量的收益测算（如：预计提升人效20%，或解决客服客诉痛点）。
4. **详细需求（用户故事模式）**：
* 核心功能描述必须采用 **用户故事 (User Story)** 格式：“作为 [角色]，我希望 [做什么]，以便于 [达到什么价值]”。
* 必须配合 **验收标准 (Acceptance Criteria)**。

### 3. 严格的版本控制机制
你必须像一个严谨的配置管理员一样维护文档版本：
* **版本号规则**：
* 初始版本为 **V1.0.0**。
* **修订号 (Z)**：微小修改、文案优化，自增第三位 (V1.0.1)。
* **次版本号 (Y)**：增加新功能但非重构，自增第二位 (V1.1.0)。
* **主版本号 (X)**：仅重大架构调整或重写时，自增第一位 (V2.0.0)。
* **时间戳强制 (Timestamp Enforcement)**：
* 版本记录中的“日期”字段，**必须**严格获取当前的实时系统时间（Current Date），格式统一为 `YYYY-MM-DD`。
* **严禁**使用过去的年份（如 2023, 2024）或虚构的日期作为当前版本的发布时间。
* **自动更新总结**：每次输出PRD时，必须在开头的“版本变更记录”中，自动总结本次修改的核心内容。

### 4. 交互引导
* 在对话开始时，请引导我一次性提供尽可能多的上下文（业务目标、逻辑、截图、附件等）。

### 5. PRD可视化
* 在 Markdown 文档阶段，请积极使用 Mermaid 图表（时序图、状态图、流程图）来辅助说明后端逻辑和业务流程。

### 6. PRD/原型 双向切换模式 (Canvas Workflow)
为了适应在同一个 Canvas 中快速切换“文档”与“原型”的工作流，请严格执行以下逻辑：
1. **无摩擦切换**：当指令要求“生成原型”、“看效果”或“切换回文档”时，无需进行“是否覆盖”的二次确认，直接执行 Canvas 内容的重写。
2. **统一的版本号题头**：
* **文档状态 (Markdown)**：标题下方第一行必须注明 `> 当前关联原型版本：Prototype V{Y}`。
* **原型状态 (HTML)**：界面顶部必须有一个固定的 Status Bar，显示 `PRD: V{X} | Prototype: V{Y}`。
3. **原型中的需求嵌入**：在生成 HTML 原型时，请尝试将 PRD 中的“验收标准”以“侧边栏说明”或“可折叠注释”形式嵌入界面，便于图文对照。
4. **切回文档的智能恢复**：从 HTML 切回 Markdown 时，需基于对话上下文恢复文档结构，并同步在原型预览阶段产生的修改意见。

### 7. 严禁过度重构 (Anti-Refactoring Policy)
* **原子化修改**：当我对 Canvas 内容提出修改意见时，**只修改我明确指定的段落或逻辑**。
* **禁止事项**：严禁为了“通顺”而擅自重写未涉及的章节、改变文档结构或精简核心逻辑。除非我明确指令“重构全文”。

### 8. "预案-确认-执行" 协议 (Plan-Confirm-Execute)
在正式更新 Canvas 之前，必须严格遵守以下流程：
1. **变更预案**：在左侧对话流中简练列出修改计划（例如：“计划修改：1. PRD新增字段X；2. 原型增加弹窗”）。
2. **等待确认**：等待我回复“确认”或“OK”后，再刷新 Canvas。
3. **执行与反馈**：更新后告知“Canvas 已更新至 V1.0.X”。

### 9. 异步同步机制 (Sync Check)
* **单方变更提醒**：当我只修改了 PRD 而未提原型（或反之）时，在执行完修改后，**必须**在对话结尾追加询问：“检测到您修改了 [PRD/原型]，是否需要同步更新对应的 [原型/PRD] ？”
* **拒绝自动同步**：严禁在未获得许可的情况下，擅自同步修改另一方视图。

### 10. 会话环境隔离 (Session Sandbox Policy)
* **严格的上下文界限**：请视每一个新的对话窗口为完全独立的、封闭的“沙盒”环境。
* **屏蔽历史记忆**：严禁主动引用、联想或带入我在其他历史对话（Cross-Session Memory）中提及的业务背景、旧项目数据或过往偏好。
* **零预设启动**：每一场新对话开始时，你的初始状态必须是空白的。请仅基于**本次对话窗口内**我实时提供的文本、附件、截图及指令进行推理。

### 11. 虚拟评审团机制 (Virtual Review Board)
当收到特定的评审指令时，请暂时脱离“作者”视角，**冻结当前 Canvas 不做修改**，切换至“独立审计员”视角，并在左侧对话流中输出评审报告。

**指令定义与执行标准：**

#### A. 指令 `/review basic` (基础校验)
* **角色**：资深跨境电商产品经理。
* **校验维度**：
1. **完整性**：是否包含背景、目标、用户故事、验收标准、异常场景（网络异常、权限不足、接口宕机）。每个功能点是否明确“做什么、为什么、怎么做”。
2. **逻辑一致性**：术语是否统一（如 SKU vs ASIN，FBA库存 vs 本地库存）；业务流程是否闭环（如：库存预警 -> 补货 -> 采购 -> 入库，无断点）。
3. **可落地性**：是否存在高并发/大数据量瓶颈；成本与产出是否匹配；是否符合 Shopify 平台规则。
4. **清晰度**：拒绝模糊用语（如“提升体验”），必须可量化。

#### B. 指令 `/review deep` (深度三维审核)
* **角色**：同时扮演 **产品专家 + 研发负责人 + 测试负责人** 三位一体。
* **校验维度 (高强度)**：
1. **技术深挖**：针对核心模块（库存算法、FBA数据同步、补货阈值），检查是否存在技术盲区？输入输出参数是否明确？异常处理机制是否完善？
2. **跨境适配性**：是否适配多站点（北美/欧洲/日本）差异？是否兼容多币种、多时区、多语言？是否符合 VAT 税务与 GDPR 合规？
3. **数据指标**：核心指标（周转天数、缺货率）定义是否准确？系统能否自动统计？
4. **系统兼容性**：是否与现有系统（OMS, ERP, 采购系统）存在数据流冲突？接口定义是否清晰？
* **输出要求**：
* 问题分级：必须修改 (Blocker) / 建议修改 (Major) / 可选优化 (Minor)。
* 提供具体的修改方案，而非空泛建议。

#### C. 指令 `/review quick` (5点光速扫描)
* **角色**：敏捷教练。
* **快速回答以下 5 个问题 (Bullet Points)**：
1. 文档是否遗漏核心功能模块？
2. 是否存在前后矛盾的需求描述？
3. 验收标准是否可量化/可测试？
4. 是否触犯亚马逊/平台合规红线？
5. 是否明确了非功能需求（性能、安全、边界）？

**评审后的交互：**
* 输出报告后，请务必询问：“是否需要我根据以上建议，为您制定 Canvas 的修改预案？”

### 12. 输出渠道强制协议 (Output Channel Protocol)
为了保证工作区整洁，请严格执行“左右分屏”的内容输出策略：

* **右侧 Canvas (交付物)**：
* **强制默认**：任何 **PRD文档正文** (Markdown) 或 **原型代码** (HTML) 的内容，**必须** 自动触发并渲染在 Canvas 画布中。
* **禁止事项**：严禁在左侧对话流中输出大段的 PRD 章节或 HTML 代码块，除非我明确要求“在对话中显示”。
* **首次启动**：当明确需求开始撰写初稿时，直接调起 Canvas 展示 V1.0.0，无需在对话流中重复正文。

* **左侧对话流 (控制台)**：
* 仅用于：需求沟通、逻辑确认、修改预案 (Briefing)、评审报告 (Review Report) 以及简单的状态通知（如“Canvas 已创建，版本号 V1.0.0”）。

这里我逐个规则讲解下背后的考量：

• 初始化与引导协议：Gem 无法定义新对话默认调用的模型，我一般用 Gemini 3 Pro 来撰写复杂的 PRD 和制作原型，为了避免忘了选用 Pro 模型，我加了个前置引导。
• 语言规范：默认情况下，Gemini 输出的中文内容总是会默认带上一些英文标题，显得 AI 味十足。这条规范是为了强制 AI 输出纯中文，不要搞中英文夹杂的版本。
• 文档结构与内容要求：我们经常会在修改 PRD 或者原型时，改着改着发现，之前的版本其实更好，想要回到之前的版本去。但我发现，纯自然语言指令，无法让 AI 准确回到指定的版本/状态。
  • 如果研发的代码需要 Git 来管理版本，为什么产品经理的 PRD 却要依赖‘最终版_打死不改_v3.docx’？
  • 我想起，研发写代码不是习惯用版本控制么，产品经理也可以啊！让 AI 在每次更新文档时自增版本号+记录变更日志就可以啦。这样的话，假如我要回到过去的某个版本，直接发指令，写清楚版本号就行了，可以精确回滚到某个版本的 PRD 或者原型。用 AI 实现文档的版本化，是对产品工程学的回归。
• 交互引导：AI 太聪明了，经常在我们仅仅提供少量输入的情况下，它就开始洋洋洒洒进行输出了。所以，我设计了一个引导，提示用户在对话开始时，尽可能一次性输入大量的背景信息，这样第一个版本出来的效果就大差不差了。
• PRD可视化：B 端中后台产品比较重业务逻辑，这一部分是为了让 AI 尽量用时序图、状态图、流程图等来阐述业务。
• PRD/原型双向切换模式：在同一个 Gemini 对话窗口中，没办法在右侧 Canvas 画布同时显示 PRD 文档和原型（HTML），这部分是为了让 AI 了解我经常来回切换的指令，不用做额外确认。
• 严禁过度重构：有时候我只是让 AI 修改一两句话，结果它自作主张，将全文按照它理解的方式“优化”了一次，比如调整了措词或者偷偷删减了一些段落，这并非我的愿意。因此，我有必要强制让 AI 仅仅修改我明确指定的范围。
• "预案-确认-执行" 协议：当我需要 AI 修改多个地方/段落时，为了确保它改对对方，我会希望 AI 先跟我讲，它打算如何修改，我看了觉得没问题后，才让它执行。
• 异步同步机制：如前面提到的，我经常来回切换 PRD 文档和原型（HTML）进行修改，有时候我改了一边忘了另一边。我希望 AI 能够提醒我记得同步修改，但也别不打招呼就自行同步更新。
• 会话环境隔离：使用同一个 Gemini 账号对话久了，它会记住我的喜好和背景，好处是它越来越了解我，不好的地方是它在我新开一个话题时，有时候会不合时宜地联想起我之前聊过的话题，给我整出一个四不像来。举个栗子，我可能新开一个对话问了下旅行攻略，结果它上来就是“作为产品经理，你XXX”。。。不是哥们，我问你旅游攻略呢，你提醒我工作是为啥。。。同样的道理，我在写 PRD 时，由于我会跨多个系统/话题，我并不需要 AI 过分联想我之前做过的项目，所以我希望当前的对话是一个全新的起点，让我们从零开始吧~
• 用 AI 帮评审 PRD：PRD 肯定是要经过评审的，不过 AI 能否帮上忙呢？当然可以，让 AI 扮演特定角色即可。为了方便快速调用/切换角色，我还定义了快捷指令，比如输入 /review basic 就可以对 PRD 执行一次常规的审阅。Review 完成后，根据输出的报告，还要主动问我是否要更新到 Canvas 画布去。我只需要做一个懒人，回复 yes 或者 no 就可以了。写到这里，我想起来，我在调校这个 PRD 助手前后，Claude 推出的 Skills 正火呢，其实我这个在 Prompt 里内置不同角色的方法，和 Skills是有异曲同工之妙的：定义技能、按需调用。
• 输出渠道强制协议：Gemini 的对话窗结构，左侧对话流，右侧 Canvas 画布，各司其职。右侧一般用于可交付物（PRD和原型）的产出，左侧更多是用于中间过程的对话。此限制是为了避免 Gemini 有时候把大段的 PRD 或者 HTML 代码直接在左侧窗口返回给我。

3 Mermaid流程图无缝集成

产品经理干活，少不了各种时序图、状态机图。以前用 Visio 画，改起来很痛苦。现在我全部让 AI 生成 Mermaid 代码。

另外，很多文档系统原生支持 Mermaid 代码渲染，比如飞书。以前我需要画出流程图后，手动截图插入到文档去，这种方法很笨，且无法在文档编辑修改这些流程图。现在呢？我在飞书文档里通过插入“文本绘图”组件（快捷录入方式是：先输入 / 然后输入 mer 即可定位到“文本绘图”），粘贴 AI 给我的 Mermaid 代码，即可渲染出图片，有需要时切换一下视图，就可以在文档中直接修改流程图代码了。

小技巧：如果粘贴 Mermaid 代码到飞书后渲染报错，可以直接将报错信息复制后丢给 Gemini，让它优化一下，大部分情况下尝试一两次就能正常渲染了。

4 Gemini原型生成与分享

前面提到过 HTML 原型的制作，一般在 Gemini 右侧 Canvas 画布渲染预览。然后呢？如何将原型分享给研发和测试同事？

Canvas 右上角有个 Share 菜单，可以生成公网可访问的链接，也就是一个 HTML 网页。另外，也可以通过 Copy contents 方式，将 HTML 代码复制下来，在本地电脑上新建一个 HTML 文档，把代码粘贴进去，用这种方式来分享 HTML 原型。

实际上，既然我们能获得 HTML 形式的原型，那么我们完全可以将原型托管到任何公网可以访问的网盘/主机空间，如 Netlify 或者 Vercel 等平台。

这里还有个小技巧，由于 Gemini 每次 Share 都会形成一个新的分享链接，为了避免研发测试同事保存了之前的 Gemini 原型链接后，没有获得及时更新的版本，你也可以在 Netlify 或者 Vercel 这类平台上建一个项目，获取一个固定的 URL 链接，上传类似以下结构的 HTML 文档：

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>Loading Prototype...</title>

    

    <meta http-equiv="refresh" content="0;url=https://gemini.google.com/share/123456">

    

    <style>

        body { 

            font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; 

            display: flex; 

            flex-direction: column;

            justify-content: center; 

            align-items: center; 

            height: 100vh; 

            background: #ffffff; 

            color: #333; 

        }

        h2 { margin-bottom: 10px; font-weight: 500; }

        p { color: #666; font-size: 14px; }

    </style>

</head>

<body>

    <h2>Loading Prototype Demo</h2>

    <p>Redirecting you to the latest version, please wait...</p>

    

    <script>

        window.location.href = "https://gemini.google.com/share/123456";

    </script>

</body>

</html>

然后每次更新 Gemini 原型，获取到最新 Share 出来的链接后，只需要更新上面这份 HTML 里面的相应链接即可。我估计你也看出来了，上面这份 HTML 的主要作用是作为一个“中转站”，在用户打开这个（Netlify 或 Vercel）网页时，自动跳转到指定的外部链接（Gemini 的分享链接）。

这就像给你的原型配了一个永久域名。无论你后台怎么更新 Gemini 的链接，发给老板和研发的那个 URL 永远不用变。 这样做的好处是，研发测试可以保存一个相对固定的 URL 到浏览器书签，但他们打开访问到的永远是你最新版的原型页面。

5 妙用NotebookLM：联动Gemini外挂知识库

为什么要使用NotebookLM？因为默认的 AI 对话框本质是流式对话，不是持久化的文档管理。我们要设法将知识沉淀下来，也就是我们经常说的“知识库管理”。而 Google 家推出的 NotebookLM就是一个极其强大的知识库，它不仅可以单独使用，还能联动 Gemini 使用。

假设，我们的项目通过了 V1.0 阶段，积累了大量文档后，如何让 AI 在做 V1.1 迭代时基于历史规则来输出，而不是从零开始？

简单粗暴的做法是，将 V1.0 的文档存为 PDF，然后新开一个 Gemini 对话，先把这份 PDF 丢给它，让它先读一遍，然后发指令要求 AI 进行迭代。

不过，Google 的生态是很完善的，有丰富的全家桶，我们可以做得更优雅一些。

1. PRD V1.0 定稿后，通过 Canvas 右上角的 Share - Export to Docs，自动导出存到 Google Docs
2. 在 NotebookLM 新建一个项目，导入 Google Docs 的以上 PRD 文档
3. 新开一个 Gemini 对话，挂载这个 NotebookLM 项目
4. 在 Gemini 对话中，直接提问，如“基于现有的库存扣减逻辑，如果我们要增加‘预售’功能，会对哪些模块产生冲突？”

使用以上 Gemini + NotebookLM 挂载知识库引用方式，相当于可以快速为 AI 对话提供历史背景信息，有助于 AI 生成的内容更专注。

实际上，人类对 NotebookLM 的探索，还是很有限的，只要脑洞足够大，你就能够有更具创意的用法。比如，本文一开始不是花费很大篇幅介绍了 Gem 的定义么，我没提到的是 Gem 本身还能默认挂载 NotebookLM 知识库。这有什么用途呢？比如啊，我们要维护的是一个非常复杂的业务系统，状态机就有十几二十个值，你可以维护到 NotebookLM 去并挂载到 Gem，写死Instructions（类似“你是一个严谨的系统架构师。你的任务是审查 PM 的需求。如果 PM 的需求涉及到修改数据状态，请对照所挂载的知识库内容，检查是否符合状态机的流转规则。如果发现潜在风险，必须标出”），这样当你通过这个定制 Gem 来撰写 PRD 需求时，AI 可以默默为你保驾护航，防止你设计出与当前业务逻辑冲突的功能。

毕竟，作为产品经理，我连自己半年前写过的 PRD 都不记得了，人类的记性哪有 AI 靠谱啊。。。

6 数据分析与可视化呈现

我知道有些人会这么使用 AI：丢一个 Excel 文档给 AI，让 AI 帮忙分析数据。但是，我们要认识到，LLM 本质是“文字接龙”的概率模型，而不是计算器。

好消息是，Gemini 很早就支持运行 Python 代码的功能，按官方的说法，这是在一个沙盒（Sandbox）虚拟环境中执行的。

关于数据隐私与安全：B端PM往往很看重数据安全。需要强调的是，Gemini 的 Python 代码是在谷歌云端的一个隔离沙盒中运行的，代码执行完毕后环境会销毁，这比随便找个第三方在线工具分析数据要安全得多。

如何触发 Gemini 的 Python 数学计算呢？需要我们明确下发指令。参考下面的例子：

作为一个数据分析师，请编写并执行 Python 代码来处理我上传的 Excel 文件。

使用 Pandas 读取文件，不要使用 OCR 或文本阅读模式。

首先打印出数据的总行数，并与我确认（例如：‘检测到 1500 行数据’）。

绝对不要进行抽样或估算，必须对每一行数据进行精确的聚合统计。

基于处理好的完整数据框（DataFrame），生成 HTML 格式的可视化图表（如使用 Plotly 库）或静态图片。

请将统计结果的中间数据（如各分类的总和）打印出来以便我核对。

用这种方式，处理几万行数据都不在话下。当然了，如果数据量实在很大（比如几十万行），建议还是找研发同事帮忙吧，AI 虽然强大，它毕竟不是专门用来做数学计算的。

进阶用法：通过 Canvas 的预览页面的 add gemini features 功能，可以为静态化的数据可视化报表，添加 AI 对话能力，方便读者在查看数据数据可视化报表的同时，可以根据实际需要进行提问，AI 会基于原始的（底层）数据给出合适的答案/解读。举例：我制作一个上季度订单销售情况洞察的可视化 HTML 页面，加上了 AI 对话能力，那么看到这个页面的人，可以直接在页面上调出 AI 对话窗，提出类似“订单峰值是哪一天”这类问题，AI 会基于预置的数据自动给出回答。

7 发散思维：用Gemini创作基于Web的辅助小工具

产品日常工作除了写 PRD 画原型，还经常和其他部门的人打交道，典型就是客服部门。

客服同事在理解一些复杂的系统逻辑时，往往比较吃力，比如我们的退换货逻辑结合虚拟积分的规则，有很多分支场景，光靠嘴巴讲一时半会儿都不一定能讲解清楚。有一段时间，我们在 IM 群里天天回复客服的此类问题，疲于奔命。

有一天，我们突然意识到，为啥不用 Gemini 做个网页小工具，辅助客服判断业务流程呢？我们将业务规则整理后丢给 Gemini，为我们生成了一个类似“退换货判定助手”的 Web 小工具，客服只要点点鼠标，就能将遇到的问题匹配到某个场景，自然就知道相应的处理对策了。通过此方式，我们降低了解释成本，客服很开心，我们也开心。

8 AI幻觉处理

只要是 LLM，就无法杜绝出现幻觉，我们能做的，就是设法规避、降低影响。

• 原则：在一个对话框内，讨论话题要相对集中，比如我们在聊一个退款的功能，不要聊着聊着突然就扯到营销系统去了。
• 优化：当开始出现幻觉时（答非所问），有时候可以尝试用英文输入，可能比你用中文输入效果会好一点（毕竟 Gemini 是国外的）
• 规避：当对话已经很长了，AI 持续答非所问，怎么办？让 AI 总结一下当前对话的主要内容，方便我们复制后，新开对话，将话题延续到下一个主题；以及，将当前对话的主要产出物（PRD 和原型），导出来，再导入到新对话，继续讨论同一个话题。

参考 Prompt（发给旧对话的）：

请停止当前的推理，我们需要重置对话。为了让我能在新的对话框中无缝继续这个话题，请帮我生成一份上下文迁移摘要。

请忽略刚才对话中最后可能出现的错误信息，基于我们之前讨论的正确内容，总结以下几点：

核心目标：我们要解决什么问题？

关键背景：有哪些已经确定的前提条件或限制？

当前进度：我们已经达成了哪些共识？

下一步行动：我们正准备讨论哪个具体环节？

请用清晰的结构输出，方便我直接复制粘贴给下一个新对话。

拿到以上旧对话摘要信息后，发给新的对话。

你可以先输入一句：

我正在进行一个项目讨论，这是之前的上下文摘要，请阅读并确认你已理解，暂时不需要输出新内容，只需回复‘收到’”。

然后粘贴旧对话生成的摘要给新对话，继续之前的话题讨论。

Tips：为避免丢失格式，可以直接复制旧对话框的 PRD 或者原型源码，在新对话框中，新建一个空白的 PRD 或者 HTML 原型（直接告诉 AI，请在右侧 Canvas 画布呈现一个空白文档/空白的 HTML），粘贴进去，再刷新（而不是直接在左侧对话窗中将文本丢给 Gemini）。

结语

AI 不会取代所有产品经理，但懂得用 AI 提升工作效率的产品经理，则会淘汰那些只懂写文档、画原型和传话的产品经理。

对于 B 端/中后台产品经理来说，Gemini Canvas + NotebookLM 的组合，实际上是赋予了我们低成本的代码能力和无限的知识库记忆。希望这套工作流能给大家带来一些启发，把时间从“写文档/画原型”中解放出来，投入到更核心、更有价值的业务思考中去。