王天娇
AI产品经理
📧 Wangtj0212@outlook.com
📞 18992042758
📍 深圳 · 可即刻到岗
香港理工大学 · 语言学硕士（QS全球前50）
语用学×产品洞察 Agent 编排与评测
Prompt 工程 用户研究
数据分析 竞品分析
MCP v2.0 协议 Multi-Agent 编排 Agent 评测集 DeepSeek Harness 端侧 AI 推理
RAG Dify PWA 离线 Cursor Python
13 个可交互产品原型
3 个个人核心案例
5万 字PRD
20+ 用户深访
⚡ 精简速览
🎬 关闭动效
🎯 3 分钟了解我，从这三张卡片进入：
📖 关于这个作品集
王天娇，香港理工大学语言学硕士，求职 AI 产品经理。本作品集记录产品判断与落地过程，每个决策都标注当时的约束（预算、技术边界、用户隐私、时间窗口）与取舍。13 个项目中，核心案例经过用户测试与多轮迭代，其余项目基于竞品走查与需求调研完成初版。
🤖 这个作品集本身是一次 AI Native 实践：需求与判断由我完成，编码执行交给 AI；13 个 demo 按场景验证端侧识别、多 Agent 编排、MCP 协议与本地推理的适用边界。AI 用在哪、不用在哪，本身就是产品决策。
📌 3 分钟路径：能力总览 → 核心案例（宠伴）→ 技术决策（PRD Quality Gate）。时间有限时，先看这三块。
▶
展开 · 我判断一件事的方法
先证需求真伪： 语用学拆言外之意（"还行吧"可能是礼貌性不满）＋ 行为数据 / 差评交叉验证，过滤伪需求再谈功能。
再定 AI 边界： 确定性规则直写、开放检索才用 RAG、隐私场景走端侧、跨系统才上 Agent / MCP：先答"AI 该不该介入、介入在哪一层"。
最后用评测闭环兜底： 同一评测集跑分 → 归因到链路节点 → 改 → 复测；对外只写有来源的实测数据。
🧠
AI 产品思维
Harness五步法（驾驭AI能力的五步产品方法论） · AI能力边界判断 · 人机协作模式设计 · 13 个AI产品
📊
数据驱动决策
NPS +12→+38 · 留存44% [内部测试] · A/B测试 · 评测集+MECE（相互独立、完全穷尽） 闭环
⚙️
技术理解力
Prompt/RAG/Agent · MCP协议 · 端侧AI · 传感器选型与IoT通信（ESP32/MQTT/HX711） · Tesseract.js 本地OCR
🎯
用户体验设计
语言学驱动 的用户洞察 · 20+ 深访覆盖4类人群 · 隐私优先架构 · 本地OCR方案
🚀
项目落地
100% P0交付率（实习期2条产品线） · App Store上架 · 5万 字PRD（累计）
用户访谈 + 行为数据 + 差评挖掘三管齐下，从"用户说的"和"用户做的"两个维度交叉验证需求真伪
🔍
需求发现方法论
从用户行为数据和真实反馈中定义需求，而非从技术能力出发找场景
1
方法论框架
① 用户深度访谈 ：挖掘隐性需求（含语用学追问"没直说"的部分）。
② SQL 行为数据 ：验证"用户实际怎么做"。
③ 应用商店差评分析 ：发现竞品未满足的需求。
三管齐下： 交叉验证"用户说的"与"用户做的"，过滤伪需求。
2
案例：AI健身教练产品线 · 行为数据驱动
发现①（反馈时机）： 「查看报告→分享」跳出率 60%：用户练完才看到纠错报告，错误动作模式已形成。
发现②（激活瓶颈）： 注册→首次 AI 激活仅 50%（最大转化瓶颈），41% 失败源于视频质量问题。
由此定义两项需求： ① 实时纠错（反馈从训练后前置到训练中）；② 上传前预检 + 新手引导 3 步化（激活优化 → D1 留存 +9.3pp）。
3
案例：宠伴 · 访谈+差评挖掘
约20位 宠物主访谈+应用商店差评分析，量化定义核心问题：70% 用户每月遗忘疫苗接种，83% 将隐私顾虑置于成本之上。主动砍掉社区/商城模块，聚焦轻量健康记录，确定"隐私优先+零成本"的产品定位。
4
案例：会议·反刍舱 · 场景观察
访谈PM/项目协作人群，发现会后整理纪要平均耗时15-20分钟，漏项率约30% 。核心矛盾不是"没有工具"，而是"工具太重"：用户需要的是"这一场会议的产出可被追踪"。明确不做大而全的协作套件，聚焦最小闭环。
🔬
语用学在深访中的实际应用（点击展开）
语用学解决的是"用户没说出口的需求"。 以下三个来自实际深访的片段，展示如何从用户原话拆出可执行的需求：
用户原话 语用学分析 挖掘出的真实需求 宠伴用户："还行吧，能用" 模糊限定词"还行吧"+会话终止信号"能用"：Grice合作原则的"量准则"被刻意违反（故意少给信息），用户在用礼貌策略掩饰不满 追问"哪个操作让你觉得卡？"→ 定位到疫苗记录路径需要5步才能完成一条录入，记录耗时缩短约60%后该用户从被动使用转为主动推荐 会议舱用户："会上说过、会后没落地" 被动语态"没落地"回避责任归属：用户不是在抱怨某个工具，是在描述一个"没有谁负责"的系统性失败 拆解出"没落地"的三个子环节：没记录→没分配→没追踪。由此设计结构化待办+状态流转+漏项抽检闭环，而非又一个"协作平台" 健身产品用户："这个功能能不能也加一下？" 表面是功能请求，深层是替代行为 ：用户加功能是在回避"现有功能不好用"这个更难开口的真问题。话语分析中这叫"话题替换" 后退一步问"你现在用哪个功能实现这个需求？"→ 暴露了当前操作流程的断裂点，修复后在P0需求评审中被确认优先级最高
这套方法在深访、需求评审、评论分析三个环节复用：语用学在对话中找信息缺口 （用户少说了什么），话语分析识别会议里的回避信号 （谁在绕开什么话题），语料库方法把200+条评论转化为可量化决策 。
多维度结构化对比 + LLM辅助批量分析竞品更新日志，提炼可落地的产品决策
⚔️
竞品分析方法论
按迭代趋势/共性方向/差异化方向/用户痛点四维度输出结构化报告
1
方法论框架
四维度对比，输出结构化报告：
方法：用 LLM 批量分析竞品更新日志与用户评论，把发现转成可落地的产品决策。
2
案例：AI高尔夫产品线 · 4款竞品深度分析
方法： 用 DeepSeek/ChatGPT 批量分析 4 款头部高尔夫记录类 App 近 12 个月的更新日志与用户评论。
关键发现： 行业趋势从"记录工具"转向"社交分享"，核心需求从"看数据"升级为"晒成绩"。
推动的决策：
3
案例：宠伴 · 竞品功能对比
对比4款宠物管理类App的疫苗提醒功能、隐私策略、付费模式，发现现有工具重社交商城、轻健康记录 ，隐私保护均弱于用户预期。由此确定"本地存储+零服务器"的技术差异化路线，把差异化写进PRD。
4
案例：跨境电商 · 市场格局分析
调研范围： 全链路痛点（需求模糊/信息碎片化/选品靠经验/多语言文案/合规风险/运营缺失）+ 传统 Chatbot vs Multi-Agent 效率对比。
核心发现： 用户"不知道该问什么"比"找不到答案"更致命。
范式设计： "6-Agent 全链路协作"：需求解析→市场调研→选品→文案→合规→运营策略，Orchestrator 路由调度，系统主动推送结构化信息卡片。
SQL埋点分析 + 漏斗转化 + 数据验证闭环，用数据驱动需求优先级决策和效果验证
📊
数据分析方法论
定义指标→埋点设计→数据采集→漏斗分析→验证闭环
1
方法论框架：数据分析闭环五步
① 定义核心指标 ：转化率/NPS/留存/FAQ 等，按产品阶段选北极星。
② 埋点事件设计 ：事件名/触发时机/关键参数，与 PRD 同步交付。
③ SQL 数据采集与漏斗拆解 ：建表 → 写查询 → 定位流失点。
④ 归因分析 ：分群交叉/渠道对比/失败拆解，找"为什么"而非只看"是什么"。
⑤ 决策 → 验证 → 闭环 ：数据驱动的优先级排序与效果追踪。
实战案例：AI健身教练核心功能交叉分析 · 全链路留存归因
用户组合 人数 占比 D7留存 仅AI分析 182 29.4% 32% AI + 体态评估 87 14.0% 45% AI + 体态 + 松解（全链路） 41 6.6% 58%
归因： 全链路用户D7留存58%，是仅AI用户(32%)的1.8倍 。"评估→纠错→恢复"闭环创造最强粘性：产品价值不是AI分析单点功能，是"一站式健康管理"的链路完整性。决策： 体态评估页增加"去训练"入口→驱动功能间联动，将单功能用户推向全链路。验证： 做过体态评估的用户后续AI分析使用率62.6%，比未评估用户(46.6%)高+16pp 。PM价值： 交叉分析不是"看哪个功能用的人多"，是用SQL把用户行为组合起来，发现"功能A×功能B"的协同效应远大于单独使用。这个洞察单看功能FAQ看不出来。
2
案例：高尔夫产品 · 全模块埋点体系
交付物： 全模块埋点事件体系（26 个事件覆盖 11 个页面），核心为单杆轨迹模块 8 个事件（首页点击→导入视频→相册/相机选择→轨迹颜色→重播/导出）。
规范： 定义事件名/触发时机/关键参数（如 trace_color），并输出埋点验收标准。
验证： 用 SQL 校验单杆轨迹核心漏斗（导入→导出）的事件触发率与参数完整性。
3
案例：宠伴 · A/B验证体系
建立"假设→实验→指标"验证体系：提醒配置意愿指数（任务完成率0.35+配置意愿量表0.35+主观耗时0.30）+13% ，记录耗时缩短约60% ，种子用户NPS +12→+38 ，转化率42% ，7日留存44% 。[内部测试·种子用户轮次验证]
关于数据边界的说明： 以上量化指标（NPS/留存/转化率）均来自种子用户轮次验证，样本量有限。这些数据用于方向判断 ：产品有没有在变好、每次迭代有没有改善趋势：而非统计推断（NPS值不能直接代表市场规模）。下一阶段目标：在真实商业产品环境中积累自然流量下的转化和留存数据，验证同样方法论在大样本下的有效性。这不是"数据不够好"：这是对数据来源的诚实交代，也是对下一步的明确规划。
4
案例：PRD Quality Gate · 效果测评
~5000字PRD实测850ms 响应，检出6/19 项合规项定位13处 遗漏，验证System Prompt直写规则优于RAG检索的适用边界。用数据证明"确定性审核场景用Prompt直写、开放性场景用RAG"的技术选型结论。[内部实测·单次PRD样本]
🏋️
Insta360影石 · 软件产品经理（运动相机） · 2026.07-至今
运动相机软件产品 · 负责软件产品需求分析与功能迭代
上海析微智能科技 · AI产品经理 · 2026.04-06
AI健身教练 / AI高尔夫两条产品线 · 负责产品方案与数据驱动迭代
🔍
PRD Quality Gate · AI自动化审核 已上线
独立产品 · 2025.12-至今
1
背景
团队PRD评审依赖人工逐条检查，经常遗漏模糊点和歧义描述，导致开发阶段反复返工。
2
问题定义 · 核心判断
基于个人积累的19项PRD质量检查清单 ，识别到这部分工作可通过AI自动化：规则确定性强，适合System Prompt直写，无需RAG知识库。核心判断： PRD检查是确定性规则检查→System Prompt比RAG更稳定可控。
技术选型决策链：System Prompt直写 vs RAG检索
问题： PRD检查是确定性规则审核：输入是PRD全文，输出是逐项0/1判定，规则固定不变。场景属性决定了技术方案：不需要检索外部知识，不需要动态上下文。
方案 遗漏检出 Token消耗 一致性 适用场景 System Prompt直写（选用） 13处/5000字 基准(100%) >95% 确定性规则检查 RAG检索 8处/5000字 +60% ~85% 开放性知识检索
PM 判断（实测同一份 5000 字 PRD）： System Prompt 检出 13 处遗漏、RAG 仅 8 处：RAG 的检索噪声干扰了规则匹配。
选型结论： 确定性审核用 Prompt 直写、开放性场景用 RAG：不是哪个更好，是用对场景。选 System Prompt 不是因为"更简单"，而是数据证明它在此场景更有效。
🔬
Temperature 参数调优：四组实测数据（点击展开）
Temperature 一致性 遗漏检出 幻觉率 结论 0.0 100% 8处 0% 过于保守 0.2（选用） >95% 13处 <5% 最佳平衡 0.5 82% 15处 18% 幻觉不可控 0.8 65% 16处 35% 不可用
PM判断： 这不是"温度越低越好"的简单结论。Temp 0.0一致性100%但只检出8处（过于保守），Temp 0.5检出15处但18%幻觉率不可接受。Temp 0.2是最佳平衡点：>95%一致性+13处检出+<5%幻觉。这就是数据驱动的技术决策：不是选最好看的参数，是用对比测试找到适配场景的最优解。
为什么用四维拆解（输入/逻辑/异常/评估）： 基于MECE原则将19项规则结构化到四个维度。实测13处遗漏 分布如下：
维度 规则数 检出项 遗漏项 说明 输入侧 5 2 2 用户故事格式、验收标准定义 异常侧 5 1 7 54%遗漏集中在此 逻辑侧 5 3 4 功能逻辑完整性、边界条件 评估侧 5 0 0 评估标准全部通过
归因： 13 处遗漏中异常侧占 7 处（54%），验证"PRD 最常遗漏异常流程"的行业共识。
决策： 针对异常侧，补第 20 项规则（异常流程完整性检查），用同一份 PRD 复测。
闭环： 复测确认新增规则有效堵住遗漏：不是"加更多规则"，而是"数据告诉哪里漏最多 → 针对性补强 → 复测验证"。
3
产品架构
平台： Dify Chatflow · 模型： mimo-v2-flash · Temperature 0.2（控制幻觉）· 审核四维： 输入侧/逻辑侧/异常侧/评估侧 · 三重护栏： 操作确认→过程可解释→结果可修正
4
功能 + Harness底层逻辑
用户提交PRD→AI逐项检查19项规则→生成结构化审核报告
每项"未通过"附带具体引用和判断依据（过程可解释）
用户可手动修改AI判断（结果可修正）
方案权衡采用"效果/成本/周期矩阵"进行选型决策
Harness 五步链路（本项目）
1 功能点： PRD评审中人工逐条检查遗漏模糊点和歧义描述
2 AI方案： System Prompt直写19项规则 + Dify Fixed Workflow + Temp 0.2
3 评测+MECE： 高尔夫产品线V5.0 PRD(~5000字)→四维拆解（输入/逻辑/异常/评估）→每项0/1判定
4 跑评测： 检出6/19合规+13处遗漏→人工对照验证AI判断准确性
5 改链路： 针对漏判维度优化System Prompt描述→补第20项规则→同PRD复测验证改善
5
用户流程
提交PRD → 确认输入(护栏①) → AI逐项检查19条 → 输出报告+依据(护栏②) → 确认/修改(护栏③)
从0到1完成的软硬件协同产品，展示AI产品经理从软件到IoT硬件的完整能力闭环
🐾
宠伴·健康台账 核心案例
产品负责人 · 2025.09-至今
1
背景
多宠家庭疫苗、驱虫、体检提醒分散在相册与群聊，易遗漏；记录路径长，持续使用意愿弱。
2
问题定义 · 用户需求调研
调研方法： 约20位 宠物主访谈（约12位完成40-60分钟深度访谈，覆盖新手/多宠/流失/行业专家4类人群）+ 86份 问卷（有效72份 ）+ 4款头部App近6个月200+ 条评论LLM情感分析，交叉验证"用户说的"和"用户做的"。KANO分层：基础型（疫苗提醒+多宠档案）、期望型（本地OCR+花费视图）、兴奋型（AI周报+PWA离线），基础型优先交付。
核心发现： 约70% 用户每月至少遗忘一次接种节点；约83% 不愿上传接种凭证到云端。由此确立"轻量健康记录册·隐私优先·零服务器依赖"的产品定位。
「我不想为了记这个再下一个特别重的App，最好打开就能补一条。」——用户原话（已脱敏）
「家里俩狗之前老搞混谁该驱虫了，现在分开看一目了然，总算不用拿本子记了。」——种子用户反馈
3
产品架构与决策
定位： 轻量健康记录册·隐私优先·零服务器依赖 · 主动砍掉： 社区、商城（访谈中仅2人提到）· MVP闭环： 自动提醒+疫苗记录→反馈驱动加OCR→再加数据看板 · 迭代规则： 需求被超过50%用户提及才下一个做
约束类型 约束条件 我的取舍 成本 零服务器预算（个人项目） 砍社区/商城 → PWA + localStorage，开发成本降低约60% 隐私 83% 用户拒绝云上传 Tesseract.js 本地 OCR（牺牲识别精度换数据主权） 用户注意力 "不想下一个新 App"（用户原话） PWA 免安装（牺牲原生体验换零门槛） 时间 1 人开发，业余时间 推迟花费看板/AI 周报到 V2，MVP 先验证核心提醒闭环 硬件BOM ¥74 单设备预算（ESP32+HX711+DHT22） 称重优先于摄像头（进食量是就医第一信号，无隐私争议）
为什么砍掉社区和商城： 20人深访中仅2人提到社区需求，而社区/商城会引入内容审核、服务器成本、广告变现压力，与"轻量+隐私"定位直接矛盾。砍掉后产品架构从"App"简化为"PWA"，开发成本降低约60%[估算·App→PWA架构简化] ，且无需应用商店审核。
为什么选 PWA 而非原生 App： 免安装、打开即用 ：目标用户"不想下一个新 App"（用户原话），先降门槛再谈留存。离线可用 ：满足"地铁上记一笔"的低网络场景。迭代更快 ：无需应用商店审核。
取舍： 牺牲原生App的推送与动效 ，换取零门槛：用户的第一诉求是"不想下一个新App"。
+
更多决策分析（点击展开）
为什么这样定位： 调研发现83%用户拒绝云上传，而竞品（宠物家、小爪在家）全部走云端路线。这意味着存在一个被忽略的细分市场："只想要提醒功能、不想注册、不想上传数据"的轻量用户。与其和竞品在功能丰富度上竞争，不如在"零门槛+零隐私风险"上建立差异化。
为什么用KANO模型： 用户需求多样（提醒、OCR、花费、周报、导出），但MVP资源有限。KANO模型能区分"不做就流失"（基础型）和"做了有惊喜"（兴奋型），避免把资源浪费在"做了用户也无感"的功能上。实测验证：优先交付基础型需求后，NPS从+12提升到+38。
为什么从软件扩展到硬件： 纯软件形态下，建档→首条记录转化率42%，7日留存44%触达天花板：用户"平时想不起来打开"。智能食盆（ESP32+HX711称重传感器，BOM ¥74）自动上报进食数据，从"记录工具"升级为"监测系统"。选ESP32而非树莓派（成本¥18 vs ¥200+，深睡续航30天 vs 仅数小时）；选称重传感器而非摄像头（克级数据无隐私争议，不触发83%用户云端顾虑）。通信走MQTT局域网闭环，零云端流量，延续隐私优先定位。
🗺️
场景映射（点击展开）
为什么做场景映射： 用户的真实使用场景决定产品形态：不在"真空"里设计功能，而在单手、分心、无网的具体约束中做产品决策。
维度 场景分析 物理环境 家中沙发 / 宠物医院候诊 / 通勤地铁上，需要单手操作，光线条件多变 行为状态 单手操作为主（另一只手牵狗/抱猫/拿接种本），不能长时间盯着屏幕 注意力状态 高度分心，需要 3 秒内完成一次疫苗记录，否则用户会放弃 时间约束 "地铁上记一笔"场景：从打开到完成全程不超过 30 秒 网络条件 宠物医院信号差、地铁隧道无网 → PWA 离线可用是刚需，不是加分项
4
功能点
多宠独立档案+疫苗日历+花费看板+智能提醒（按宠隔离）
本地OCR识别接种凭证（Tesseract.js，83%用户拒绝云上传）
自动算有效期+按月聚合花费视图（用户反馈驱动）
AI健康周报（基于疫苗/驱虫/花费数据生成智能报告）
PWA可安装+离线可用+JSON导出备份
智能食盆：ESP32称重传感器自动上报进食克数，MQTT局域网传输
实时健康看板：进食量/饮水/温度趋势图（Chart.js），异常预警推送
5
用户流程
打开即建档 → 设疫苗提醒(按宠隔离) → 拍照→本地OCR→确认入账 → 看板查看健康+花费 → 食盆自动上报进食数据+预警
6
效果
+13% 提醒配置意愿 +8% 回访意愿 ~60%↓ 记录耗时 50条 需求池工单 +12→+38 NPS
核心成果
种子用户NPS从+12提升至+38，转化率42%，7日留存44%。
[内部测试·种子用户轮次验证] PWA零服务器成本完成idea→验证→迭代闭环。需求池50条工单（40已闭环+7进行中+3待评审）。智能食盆硬件方案BOM ¥74，ESP32深睡模式续航30天，MQTT局域网传输零云端流量。
AI 决策总结： 本地 OCR 选 Tesseract.js（83% 用户拒云上传）→ 隐私优先的端侧 AI；AI 周报基于疫苗/驱虫/花费三类结构化数据生成 → 确定性数据场景用规则+模板而非大模型自由生成；PWA 离线可用 → AI 功能不依赖服务端，低网络环境可用；IoT层：ESP32称重传感器选型 → 进食克数硬数据优于摄像头行为识别（无隐私争议，准确率更高）；MQTT→WebSocket局域网通道 → 传感器数据不出用户家，延续隐私优先架构。四个AI/硬件决策均以用户隐私为第一优先级，数据可解释。
📊
数据分析体系（点击展开）
全链路数据源清单： ①用户行为埋点：PWA页面停留时长、功能点击频次（提醒设置/OCR录入/看板查看）、任务完成率漏斗；②业务数据：疫苗记录条数、驱虫提醒配置率、花费录入频次、AI周报生成量；③用户反馈数据：种子用户访谈录音+文本（约12位）、应用商店评论情感分析（200+条）；④问卷数据：86份结构化问卷（有效72份），含SUS可用性量表、NPS净推荐值、功能优先级排序。
核心分析指标体系：
指标类型 指标名称 定义与计算规则 当前数值 用户增长 新增建档数 首次创建宠物档案的独立用户数/周 持续增长中 活跃留存 7日留存率 首次使用后第7天仍有操作的用户占比 44% 转化变现 建档→配置提醒转化率 完成建档后24h内设置≥1条提醒的用户占比 42% 体验反馈 NPS净推荐值 （推荐者%-贬损者%）×100 +12→+38 体验反馈 提醒配置意愿指数 任务完成率×0.35+配置意愿量表×0.35+主观耗时×0.30 +13%
数据可视化方案： ①面向产研：Chart.js实时看板（疫苗录入趋势、功能使用热力图、OCR识别准确率监控）；②面向用户：AI健康周报（基于疫苗/驱虫/花费数据自动生成图表报告）；③面向迭代决策：需求池工单状态看板（50条：40已闭环+7进行中+3待评审），每周同步优先级变化。
体验完整 Demo →
🔎
竞品分析摘要（点击展开）
竞品选取标准： ①直接竞品：小爪在家（宠物疫苗驱虫提醒，注册制云同步）、宠物家（宠物健康管理+商城，功能重叠度>60%）；②间接竞品：有宠（宠物社区+电商，含轻量健康记录但非核心）、波奇宠物（宠物电商为主，健康记录为辅）；③替代竞品：iOS日历提醒+备忘录、微信文件传输助手：用户当前实际使用的"土办法"，零成本但体验碎片化。[竞品数据来源：2025-2026年应用商店公开信息及行业报告]
核心维度对比：
对比维度 宠伴 多数云端宠物App 用户体验（上手成本） 打开即建档，0注册 ，PWA安装 需手机号注册+完善资料，上手门槛高 功能完整性（提醒+记录） 按宠物独立 提醒策略；稍后/忽略粒度到单次事项 多为账号级推送，模板固定，较少支持单宠单策略 技术能力（隐私/OCR） 默认本地存储 +可选自建备份；OCR离线（Tesseract.js） 多为云账号体系，隐私路径单一；OCR非主线能力 商业化表现（盈利模式） PWA零服务器成本，无广告无内购 广告+会员订阅+商城导流，用户感知"重"
差异化优势→迭代方向： ①隐私差异化：83%用户将隐私置于成本之上，"本地优先"是产品卖点→持续强化离线能力；②体验差异化：0注册+PWA即装即用，竞品平均注册流程4步→保持极简路径；③功能差异化：按宠独立提醒+单次粒度安抚，竞品均无此设计→深化多宠场景。
关键发现→设计决策： 多数竞品未很好支持"多宠独立提醒+单次粒度安抚"。优先交付按宠独立提醒与本地OCR，把差异化写进PRD，避免做成又一个通用日历。
🔧
智能硬件接入方案·四版迭代规划（点击展开）
V0 · MVP原型
ESP32 DIY宠物体重秤，¥30-50 BOM ，1周末出原型
V1 · 数据桥接
接入现有智能设备数据，补全活动量+健康指标
V2 · 场景联动
喂食/饮水/如厕数据自动同步，构建宠物全天候健康画像
V3 · AI健康中枢
多设备数据融合+AI异常检测，从记录工具升级为智能健康管家
版本 方案 推荐设备/元件 数据维度 参考成本 V0 DIY体重秤 ESP32 + HX711 + 称重传感器 体重自动同步 ¥30-50 V1 数据桥接 FitBark 2 活动量/睡眠/健康指数 $49.95 · 无订阅 V2 场景联动 小佩生态 （喂食器/饮水机/猫砂盆）进食/饮水/如厕 ￥300-500/件 V3 AI健康中枢 多设备数据融合+AI异常检测 全维度交叉分析+预警 长期愿景
核心逻辑： V0 DIY验证"自动采集→App融合"链路（ESPHome→WiFi/MQTT→REST API，参考
mblk/cat-scale ）；V1 接入FitBark 2（$49.95·零订阅·REST API），与"本地优先+零成本"理念最契合；V2 小佩全屋统一API（pypetkitapi开源库）；V3 多设备数据融合+
宠智灵AI 异常检测，从记录工具升级为健康管家。差异化：市面产品均为"单设备单App"数据孤岛，宠伴做聚合层实现跨设备交叉分析。
扩展规划① · 摄像头AI行为识别（对齐V3 AI健康中枢）： 称重只能回答"吃了多少"，回答不了"状态如何"。接入家庭摄像头后，可自动捕捉活动量、进食行为、异常静止：补全称重之外的动态健康维度。技术选型对比：
技术方案 关键点 运行环境 实时性 适用场景 MediaPipe Pose （推荐）33个（含3D坐标） Android/iOS/Web/桌面 30fps+ 宠物姿态/进食/异常行为识别 MoveNet 17个 边缘设备/Web 30fps+ 轻量实时场景 YOLO11 COCO关键点 GPU/边缘/WebGPU 高帧率 多任务+异常检测
扩展规划② · 多传感器融合设计： 称重（进食量/饮水量·硬数据）+ 温湿度（环境风险）+ 摄像头视觉（行为异常）三通道交叉验证。单一传感器噪声大：宠物踩踏/打翻食盆会产生假称重信号，单纯看一条曲线容易误报。融合后按"信号可信度"加权：当"称重下降"与"视觉确认未进食"同时出现时，告警置信度才达到推送阈值。这套"多通道互为印证"的设计，延续了我在AI运动产品中验证过的"视觉+惯性双通道校验"思路：单一数据源易误判，交叉验证才可靠。
扩展规划③ · 端侧AI可行性： 2026年端侧推理成本降至1/10，TI TinyEngine等MCU级NPU将延迟降90倍、能耗降120倍：ESP32未来可直接在端侧运行轻量异常检测模型，无WiFi也能本地判断"进食是否异常"，隐私与功耗双赢，与宠伴"隐私优先"定位完全一致。
技术参考： pypetkitapi（MIT协议·pip install）· 萤石IoT开放平台 · 宠智灵AI（行为识别>92%准确率）· GitHub PetPulse。 [数据来源：PyPI/pypetkitapi 1.26.0、FitBark官网、PETKIT官网、宠智灵官网]
从0到1完成 · 每个项目都有完整的产品闭环
🚦
PRD Quality Gate
1 提交PRD→ 2 确认输入→ 3 AI逐项检查→ 4 输出报告→ 5 确认修改
痛点：PRD质量检查依赖人工经验，新手容易遗漏关键要素。
核心判断： 确定性规则用System Prompt直写，比RAG更稳定。
19条PRD质量检查规则 · ~850ms响应 · 三重护栏机制
实测检出6/19合规项+13处遗漏，已上线交付团队使用
查看 Dify 工作流 →
🎙️
会议·反刍舱 Whisper本地转写 种子内测
产品负责人 · 2025.11-至今
1
背景与问题
会后纪要复述成本高，待办落在聊天与备忘录里不可追踪，"会上说过、会后没落地"反复出现。
「我最怕的是会开完了群里还在重复问谁做什么。」——用户原话（已脱敏）
2
产品决策
取舍：不做大而全协作套件 。转写 → 结构化待办 → 状态追踪 → 周报复盘 。
3
产品架构
4大核心模块： 语音转写（Whisper本地）→待办台账（结构化字段）→状态流转（待办→进行中→完成→归档状态机）→复盘笔记（短周期回顾）· 可选Node.js+Express+SQLite后端满足团队私有化部署
为什么选Whisper本地转写而非云端： 访谈发现"会议内容涉及商业机密"是用户最大顾虑。飞书妙记/通义听悟都走云端，数据上传后用户无法控制。Whisper本地转写牺牲少量准确率换取数据主权，符合目标用户的隐私需求：这和宠伴"本地优先"的决策逻辑一致。
为什么聚焦最小闭环而非大协作套件： 10人访谈中发现，用户不需要"又一个协作平台"：他们已经有飞书/钉钉/Notion。真正缺的是"会议中说的事有没有落地"。做最小闭环（转写→待办→状态→复盘）可以在不改变用户现有工具链的情况下补上缺失的一环。
+
更多决策分析（点击展开）
为什么做状态流转而非简单待办列表： 用户反馈"待办列了但没人管进度"：问题不是没有待办，而是待办没有生命周期。简单待办列表只有"完成/未完成"两态，但真实场景是"已分配→进行中→遇到阻塞→已完成"。状态流转让每条待办有"进度可查"，也支持漏项抽检：超过3天未流转的待办自动标红提醒。
4
功能
本地Whisper语音转写（隐私优先） 结构化待办+P0/P1/P2优先级+状态流转
漏项抽检+议题-待办关联分组 周报月报+TOP词+健康评分+KPI+趋势图
反刍闭环（标记已解决+结论）+会议知识图谱
5
用户流程
录音 → 本地转写 → AI提取待办 → 确认→分配→追踪 → 周报复盘
6
效果
6-8场 会议演练 4名 协作者跟评 104→118 待办完成指数
核心成果
待办完成趋势每轮迭代持续改善（+4%→+12%→+18%），验证"转写→待办→复盘"闭环有效性
体验完整 Demo →
🗺️
场景映射（点击展开）
为什么做场景映射： 会议场景的物理约束直接决定技术选型：AI 方案不在"真空"里比较，而在隐私、网络、注意力约束中求最优解。
维度 场景分析 物理环境 会议室 / 咖啡厅 / 出差途中：背景噪音不可控，多人发言需区分说话人 行为状态 用户正在开会讨论，双手可能在记笔记/投屏，不能操作复杂界面 注意力状态 会议中高度专注讨论内容：会后回顾"刚才说了什么"而非实时看转写 时间约束 会后 5 分钟内需要看到结构化待办，否则"会后失忆"已经发生 网络条件 客户会议室可能无 Wi-Fi 权限、出差途中移动网络不稳 → 本地转写是刚需 隐私要求 商业机密讨论（定价/合同/人事）→ 数据不能上传云端，客户合规硬约束
📋
需求调研·竞品·数据（点击展开）
用户需求调研： 小范围邀请4名 协作者固定跟评 + 会议场景观察6-8场 + 问卷62份 （有效51份 ）+ 竞品试用对比（飞书妙记/通义听悟/Fireflies.ai）。KANO分层：基础型（语音转写+待办提取）、期望型（状态流转+漏项抽检）、兴奋型（周报复盘+知识图谱）。
竞品分析： •
飞书妙记/通义听悟 ：语音转写+摘要，依赖生态+云端处理，缺少待办状态追踪。
•
Otter.ai ：
$100M ARR·25M+用户（2025.03） ，AI会议转录+搜索。
•
差异化 ：本地Whisper隐私优先（竞品均云端）、状态流转+漏项抽检（竞品无）、周报复盘闭环（竞品需导出）。[数据来源：2025-2026年公开产品信息]
数据分析： 核心指标：待办完成指数（完成率×0.4+及时率×0.3+漏项率×0.3），实测104→118 ；转写准确率>95%。每轮迭代改善+4%→+12%→+18% 。
按行业方向分类 · 每个项目都有完整的产品闭环
✍️
内容创作
AI辅助内容生产，降低创作门槛。从写作到剧本到游戏，贯穿同一条产品理念：AI 降低开始成本，不替代创作。
✍️
星途·创作舱 AI灵感辅助 产品
独立产品 · 2025.09-至今
1 新建主题→ 2 角色设定→ 3 章节写作→ 4 AI灵感辅助→ 5 进度追踪+导出
连载/兼职作者资料分散、断更焦虑。
核心判断： 用户卡在"开始"而非"写不出来"。产品定位： AI 帮作者坐下，不替作者写。
为什么聚焦"降低开始成本"而非提升写作质量： 访谈中兼职/连载作者最常卡住的不是"写不好"，而是坐下后打开文档不知从哪续[访谈定性判断]。AI 生成标题/开头/角色设定，降低的是"开始"的心理门槛；创作质量仍取决于作者。
为什么用健康分+进度追踪： 连载作者的隐性焦虑是"我这个月写了多少"。GitHub风格的贡献热力图把模糊的焦虑量化为可视数据：看到连续创作天数形成正向反馈，中断则触发提醒。这是行为设计中"损失厌恶"的应用：人们更害怕失去已有的连续记录，而非追求未来的写作目标。
多主题+角色设定+章节状态流转 AI灵感生成（标题/开头/角色）
写作目标+进度+时间线+健康分 周月报+快照+PWA
体验 Demo →
📋
需求·竞品·数据
调研： 种子用户3-5名 兼职/连载作者，问卷45份 ，竞品差评分析（汤圆创作/话本小说）；KANO：基础型（章节管理）、期望型（AI灵感辅助）、兴奋型（健康分+进度追踪）。竞品： 直接：汤圆创作（中文网络文学创作平台，支持章节管理+社区互动）、话本小说（互动式小说创作平台，支持分支剧情）；间接：Notion写作模板（通用文档工具，非专项创作工具）、Claude/ChatGPT（通用AI助手，可辅助写作但无创作工作流管理）；替代：Word+网盘（传统方式，无AI辅助无进度追踪）。差异化：AI降低"开始成本"而非替代创作，聚焦创作工作流管理。[竞品数据来源：2025-2026年应用商店公开信息]数据： 写作目标完成率、AI灵感使用率、章节状态流转漏斗、周活跃写作天数。
🎭
剧本·复盘舱 AI剧情生成 产品
独立产品 · 2025.12-至今
1 导入剧本→ 2 场景拆分→ 3 改稿追踪→ 4 AI剧情建议→ 5 热力图复盘
长剧本改稿忘因、进度模糊。产品架构：GitHub风格热力图(26周+连续天数) + Trello场景看板 + AI剧情面板。
为什么用 GitHub 风格热力图： 改稿是"高频低量"（每天改一点），模糊的焦虑需要"可见的节奏"来缓解。
做法：把碎片修改拼成贡献日历（26 周 + 连续天数），让编剧看到自己的节奏；该可视化模式已被 GitHub 在持续习惯追踪上验证有效。
为什么用 Trello 场景看板而非线性文档： 剧本是非线性的：改第 3 场可能影响第 15 场。
做法：每场戏独立成卡片，可拖拽排序、标记状态（草稿/初审/定稿），匹配编剧"跳跃式修改"的工作方式；线性文档（Word）做不到这一点。
热力图+场景看板+分场标签 AI剧情生成（走向/对白/场景）
月度回顾+高频词+多格式导出
体验 Demo →
📋
需求·竞品·数据
调研： 种子用户3-5名 编剧/影视策划，问卷38份 ，竞品差评分析（Celtx/WriterSolo）；KANO：基础型（场景拆分、改稿记录）、期望型（AI剧情建议）、兴奋型（热力图复盘+高频词分析）。竞品： 直接：Celtx、WriterSolo；间接：Notion编剧模板；替代：Excel改稿记录。差异化：GitHub热力图可视化改稿频率。数据： 热力图活跃天数、AI建议采纳率、改稿追踪完整度、月度回顾生成率。
🎮
雾灯残页 · AI辅助文字冒险游戏 AI生成+人工质控 产品
独立产品 · 2025.10-至今
1 用户调研→ 2 信息架构设计→ 3 AI辅助内容生成→ 4 质量控制流程→ 5 数据驱动迭代
独立游戏产品设计项目。核心价值：完整的 AI 辅助内容生产 PM 工作流：用户调研→信息架构→AI 生成→人工质控→数据迭代。
为什么做"AI辅助"而非"AI生成"： 文字冒险的核心体验是"选择感"。若完全 AI 生成，分支会乱、玩家很快发现"选什么都一样"。
解法： 28 条分支 × 6 结局由人工设计，AI 只负责填充文本（对白/描述），结构可控、体验一致。
为什么用暗骰机制： 传统文字冒险的属性检定是透明的（"力量15，检定成功"），暗骰让玩家看不到具体数值：这增加了不确定性带来的紧张感，也防止玩家"save scum"（反复读档刷结果）。5属性暗骰机制让每次选择都有真实后果，提升重玩价值。
用户调研：15款文字冒险游戏体验分析，提取核心玩法要素 信息架构：28条分支路径×6结局×5属性暗骰机制设计
质量控制：建立AI生成→人工筛选精修的标准化流程 数据埋点：结局达成分布、分支路径覆盖率、用户留存追踪
🎮 试玩游戏 Demo →
📖 开发文档 →
📋
需求·竞品·数据
调研： 体验15款 文字冒险游戏（含Darkest Dungeon/Blasphemous/Castlevania），分析核心玩法要素与用户留存机制；KANO：基础型（分支剧情+存档读档）、期望型（属性检定+多结局）、兴奋型（暗骰机制+AI生图立绘）。竞品： 直接：Ren'Py官方模板、TyranoBuilder；间接：AI Dungeon；替代：纯文字MUD。差异化：AI辅助内容生产的PM工作流（用户调研→信息架构→AI生成→人工质控→数据迭代）。数据： 分支路径覆盖率（28条 ）、结局达成分布、AI生成内容质量控制效果（697→17 破折号清洗）、用户留存追踪。
AI辅助提升个人/团队工作效率，解决"知道但做不到"的问题。从拖延诊断到任务执行，验证"规则引擎保底+AI增强"的双轨架构。
🚀
冷启动·行动引擎 规则引擎+AI双轨 产品
产品原型 · 2026.01-05
AI拆解拖延任务为最小可执行行动。双模式设计：规则引擎保底（离线可用）+AI创意增强，AI失败自动降级。
~80% AI诊断满意度 <5% 离线触发率 [内部测试·3-5名拖延症用户]
体验 Demo →
AI辅助生活决策，把复杂计算逻辑产品化。用户不需理解算法，输入参数即可得到可决策的结果。
🏠
住值·租房生命成本计算器 AI顾问+算法 产品
产品原型 · 2026.05
贪心预算分配算法+双层Bmax公式计算个性化房租上限。AI顾问提供决策建议。展示如何把复杂计算逻辑产品化。
关键价值
用户不需理解算法，输入参数即可得到可决策的结果。
体验 Demo →
🖼️
PixelPick · AI 影像精选 AI选片+增强 产品
AI + 影像产品 · 2026.06
1 上传照片→ 2 AI四维评分→ 3 精选最佳→ 4 增强前后对比
展示 AI PM 的影像产品思维："AI 不该在拍照时干扰用户，而应在拍完后帮用户精选"。四维评分（清晰度/亮度/色彩/构图）由 Canvas 本地计算，增强效果可开关可拖拽对比，让用户看见 AI 做了什么而非黑盒"美化"。
为什么做选片+增强而不是单一功能： 竞品调研发现 Remini（5 亿+ 下载量）只做"一键增强"但没有选片能力，Google Photos Best Take 只做表情优选但评分标准是黑盒。用户的真实痛点链条是"拍了太多→不知道留哪张→留了也不满意画质"：选片和增强是一个连续决策，拆成两个独立 App 会增加用户切换成本。
为什么四维评分需要透明化： Google Photos 的 AI 选片只告诉你"这是最佳"，不告诉你"为什么"。用户不信任黑盒：摄影师的判断标准（构图/曝光/情绪）和 AI 的评分逻辑往往不一致。PixelPick 把四个维度的分数和进度条都展示出来，让用户理解 AI 的判断依据，才能信任 AI 的推荐。
为什么不用大模型做评分： 四维评分全部用 Canvas 像素数学实现（标准差=清晰度、均值=亮度、色相多样性=色彩、中心/边缘亮度差=构图），不调用任何 LLM API ：选片是排序，不是理解。
用大模型反而引入三个问题： 延迟 800–2000ms （Canvas 本地 < 50ms）照片需上传第三方服务器 ，与隐私优先策略矛盾输出不确定 ：温度参数使同一张照片两次打分可能不同，破坏用户信任
PM 判断： 把 AI 用在不需要 AI 的地方不是能力展示，是反模式。
探索价值
验证影像工具类产品的核心 PM 命题：硬件决定能捕捉多少原始信息，软件决定能利用多少，AI 决定能从已有信息里重建多少。PixelPick 展示的是"AI 介入影像工作流的哪个节点"以及"如何让 AI 决策透明化"这两个 PM 关键判断。
体验 Demo →
影像产品视角： PixelPick验证的是"AI在影像工作流中的介入节点"这个核心PM命题：不是在拍照时干扰用户，而是在拍完后帮用户做决策（选哪张、怎么修）。这和运动相机"拍完自动出片"的产品逻辑是同一条价值链的不同节点。
📋
需求·竞品·数据
需求发现： 基于竞品走查与手机摄影经验提炼的需求洞察（未做正式用户访谈）。痛点链：一次出行拍大量照片，事后筛选耗时且"选了也不确定是不是最好的那张"：选片环节是比修图更靠前的瓶颈。KANO 需求分层：基础型：清晰度筛选（模糊照片自动排除）；期望型：多维度评分（不仅看清晰度，还看构图和色彩）；兴奋型：增强前后可拖拽对比（不是一键美化黑盒）。产品方向：用户不是"不会修图"，而是"不知道选哪张来修"。
[需求洞察，基于竞品走查+个人体验]
竞品分析：
•
Remini ：
全球5亿+下载 ，AI一键增强+老照片修复。优势：效果惊艳；局限：无选片能力、增强不可控、全部云端处理。
•
Google Photos ：Best Take自动合成最佳表情，端侧AI。优势：深度整合Google生态；局限：限定Pixel生态、评分黑盒、增强不可对比。
•
间接竞品 ：Adobe Lightroom（专业修图无选片）、VSCO（滤镜推荐无评分体系）；替代方案：手动翻相册。
•
差异化 ：①选片+增强连续闭环②四维评分透明化③增强可开关可拖拽对比。
[竞品数据来源：Remini官网、AppBrain 2026年6月、Google Photos Help]
数据闭环： 核心指标：①选片采纳率（用户接受 AI 推荐最佳照片的比例）；②增强满意度（用户使用增强后不撤销的比例）；③拖拽对比交互率（进入对比视图后完成拖拽操作的比例，衡量"用户是否真的在对比"）。过程指标：照片上传完成率、评分查看深度（是否展开查看四维详情）、增强开关独立切换频率（哪个效果被关闭最多，反馈评分维度权重调整）。
⚙️
技术架构与设计决策（点击展开）
(a) 北极星指标与过程指标
北极星指标：选片采纳率 ：用户上传照片后，接受 AI 推荐的最佳照片（不手动更换）的比例。这个指标同时衡量"评分模型是否准确反映了用户审美"和"评分透明度是否建立了信任"。
过程指标（按交互步骤拆解）：
步骤 过程指标 衡量什么 上传 上传完成率 用户选择照片后成功进入分析阶段的比例（文件大小/格式/数量限制是否合理） 评分 四维详情展开率 用户点击查看每张照片四维分数细节的比例（透明度设计是否引起用户兴趣） 选片 选片采纳率（北极星） 用户接受 AI 推荐的 BEST 照片且不手动更换的比例 对比 拖拽完成率 进入对比视图后实际拖拽滑块操作的比例（衡量"用户是否真的在对比"） 增强 增强效果保留率 用户打开增强开关后保持开启的比例（被关闭最多的效果反映用户偏好）
产品视角： 北极星是选片采纳率而非增强使用率，因为选片是比修图更靠前的瓶颈。用户先要知道"选哪张"，然后才决定"要不要修"。如果选片错了，增强做得再好也没用。过程指标按交互漏斗拆解，每一步的流失定位到具体的产品问题。
(b) 技术方案权衡
为什么用 Canvas 本地计算而非服务端 API：
维度 Canvas 本地计算（当前方案） 服务端 API（如 Google Vision API） 延迟 即时 （无网络往返，200px 采样图像 <50ms 分析）200-800ms（取决于网络和图像大小） 隐私 零上传 （照片全程留在设备）需上传原图到第三方服务器 精度 基础（像素统计 + 启发式规则，无深度学习） 高 （CNN/Transformer 模型，可检测语义内容）成本 零 （纯客户端计算）每千张 $1.50 起（以 Google Vision API Label Detection 为例，该 API 不做图像质量评分，仅作价格量级参考） 离线可用 是 否
决策逻辑： 原型阶段优先验证产品逻辑而非模型精度。Canvas 方案可以快速验证"评分透明化"的产品方向：如果连基础像素统计得出的评分用户都愿意信任并采纳，那产品方向就对了，后续升级模型是工程问题。如果用户根本不信任 AI 评分，再好的模型也没用。这一决策逻辑与宠伴选择 Tesseract.js 本地 OCR 一致：PM 不能等到"完美方案"才做用户验证。
(c) 四维评分权重设计的依据
核心原则：权重反映产品预期，原型阶段基于固定权重快速验证方向。
• 清晰度 35%： 最基础的筛选条件：模糊照片在任何场景下都不可用。权重最高，但评分函数设计为"够用即可"（30-95 分区间，普通清晰度即可得 60+），而非追求极致锐度
• 构图 35%： 画面结构的核心判断：三等分法则、中心对称、引导线等。与清晰度并列最高权重，因为构图是"拍得好不好"的核心维度，也是手机摄影用户最常提及的评判标准
• 色彩 20%： 色彩丰富度和和谐度：高饱和≠好照片，但极度单调的灰暗画面通常不受欢迎。中等权重，因为色彩是"锦上添花"而非"雪中送炭"
• 亮度 10%： 曝光是否合理：过曝和欠曝都扣分，但曝光问题可以通过增强功能弥补（而模糊或构图差无法弥补），因此权重最低
产品视角： 权重设计本身就是产品决策：它代表了"你认为什么样的照片是好的"。如果权重设置和用户审美不一致，用户永远不会信任 AI 的推荐。Demo 阶段用固定权重快速验证方向，生产环境中应支持用户自定义权重（"我更在意构图"→ 构图权重上调）。
(d) 增强效果用 CSS Filter 而非真正 AI 增强的设计意图
核心问题：为什么不用 Remini 式的真实 AI 增强？
• 这是 PM Demo，不是产品交付： Demo 的目的是验证"让用户对比原图 vs 增强"这个交互概念是否有价值，以及"增强开关独立可控"是否被用户需要：这两点用 CSS Filter 模拟完全足够
• 真实的 AI 增强（超分辨率/去噪/色彩重建）需要 GPU 推理： Web 端可以用 TensorFlow.js 或 ONNX Runtime Web 跑轻量模型，但会增加 5-15MB 的模型加载时间和 2-5 秒的推理延迟：Demo 阶段的用户体验损害远大于收益
• CSS Filter 本身就是产品洞察： 降噪=对比度微调、锐化=亮度微调、色彩增强=饱和度提升：这些滤镜模拟的不是"AI 做了什么"，而是"用户期望 AI 做到的效果"。Demo 验证的是需求层面而非技术层面
产品视角： 一个好的 Demo 不需要完美的技术实现：它需要让用户"看到"产品概念。如果用户不理解"AI 增强"意味着什么，给他看再精细的超分辨率结果也没用。滑块对比 + 独立开关的设计本身比 AI 模型的精度更重要：它解决了"用户不信任 AI 修图"这个比"AI 修得不够好"更根本的问题。
行业垂直AI Agent应用。v2 升级：LangGraph 真并行 + MCP 服务总线 + 场景化 Demo（3个完整 storyline）+ PM 决策链可视化。
🌐
GlobalFUN · 跨境电商AI拼团 v2 架构升级
行业垂直探索 · 2026.01-05
1 需求输入→ 2 市场调研→ 3 选品推荐→ 4 文案生成→ 5 合规审核→ 6 运营上架
LangGraph + MCP服务总线 + 6-Agent真并行： 需求解析Agent → LangGraph Send() 同时分发至市场调研/选品分析/合规审核（3 Agent 真并行），再汇总至文案生成+运营策略Agent，最终 Compiler 输出结构化卡片 + PM 决策链。覆盖跨境电商全链路闭环，不做传统问答Chatbot。v2 新增场景化 Demo（日本食品/韩国美妆/澳洲保健品），每个场景含完整比价→关税→合规→推荐 storyline。
为什么选 MCP 服务总线而非传统 API 网关： MCP 原生支持"工具描述 + 上下文传递"，Agent 之间可直接传递结构化输出；传统 API 网关是"请求-响应"式，不支持 Agent 间上下文。
v2 落地： 用 LangGraph Send() 实现 3 Agent 真并行（调研/选品/合规同时执行），相比 v1 串行分发延迟降低约 60%。
为什么从 4-Agent 扩到 6-Agent： 初版缺"文案生成"与"合规审核"，用户反馈"选品给了但文案要自己写、合规要自己查"；这两环恰好最耗时、最容易出错。
拆分后的收益： 每个 Agent 的 System Prompt 更聚焦（500–800 tokens），输出质量可控；合成单 Agent 会让 Prompt 超 4000 tokens、注意力分散。
为什么做结构化卡片推送而非传统 Chatbot： 访谈发现用户"不知道该问什么"（该问关税、物流还是合规）。
做法：Agent 主动推送结构化卡片（"这是该选品的关税风险评估""以下是 3 套多语言文案方案"），把"用户搜索"变成"系统推荐"，降低使用门槛。
98.2% 意图识别 180ms MCP延迟 -40% Token消耗 87% 数据源命中 72% 文案采纳率 94% 合规拦截
探索价值
v2 核心升级：LangGraph Send() 实现 3 Agent 真并行（延迟降 60%）+ MCP Router 统一工具调用（6 工具集中管理，Agent 不再直接 new Tool）+ 场景化 Demo（3 个完整 storyline，可复现） + PM 决策链可视化（每场景输出比价→关税→合规→推荐四步决策）+ 部分成功降级（agent_errors 追踪，单个 Agent 失败不阻塞全局）。前端新增 decision_chain 卡片类型 + 并行执行脉冲动画。从"面试稿"到"能打的架构展示"。
📋
需求·竞品·数据
调研： 访谈
8位 跨境电商用户（含代购、海淘新手），问卷
42份 ，行业报告分析（海关总署/艾瑞咨询跨境报告）；KANO：基础型（商品浏览+拼团+多语言切换）、期望型（AI比价+关税计算+结构化信息推送）、兴奋型（6-Agent全链路协作+合规校验+多语言文案生成）。
竞品： 直接：
拼多多全球购（Temu Q1 2026 GMV达280亿美元，全球月活5.3亿） 、天猫国际（AI客服+智能翻译）；间接：亚马逊全球购（全球电商巨头，AI驱动个性化推荐）；替代：代购+转运公司（人工服务，高成本低效率）。差异化：MCP+6-Agent结构化推送，覆盖从需求解析到运营策略的完整闭环，区别于传统电商平台的单一AI推荐功能。[竞品数据来源：雪球PDD 2026Q1财报分析]
数据： Agent卡片点击率、意图识别率（
98.2% [内部测试·100次调用均值] ）、MCP平均延迟（
180ms [内部测试·50次调用均值] ）、比价→下单转化漏斗、6-Agent协作流水线完成率。
⚙️
技术架构与设计决策（点击展开）
(a) 北极星指标与过程指标
北极星指标：6-Agent协作流水线完成率 ：即用户发起需求后，6个Agent全部成功执行并输出最终结果的比率。这个指标直接衡量"端到端价值交付"，因为它要求从需求解析到运营策略的每个环节都不能断裂。
过程指标（按Agent拆解）：
Agent 过程指标 衡量什么 需求解析 意图识别准确率 用户输入→结构化意图的正确率（实测98.2%[内部测试·100次调用均值] ） 市场调研 数据源命中率 返回结果中包含有效市场数据的比率 选品分析 比价→下单转化率 用户查看选品卡片后进入下单流程的比率 文案生成 多语言文案采纳率 用户直接使用AI生成文案（不修改）的比率 合规审核 合规拦截准确率 正确拦截不合规商品的比率（减少误拦/漏拦） 运营策略 策略采纳率 用户采纳AI运营建议的比率
产品视角： 北极星指标衡量"链路是否跑通"，过程指标定位"哪个环节断了"。两者结合形成完整的诊断体系：北极星掉了看过程指标，过程指标掉了定位到具体Agent。
(b) 技术框架
v2 技术栈升级： 从 v1 自研 Node.js Orchestrator 迁移至 LangGraph + Python/FastAPI。技术栈如下：
• 编排层： LangGraph StateGraph + Send() 实现 Agent 真并行 fan-out，替代 v1 的串行 list 分发
• LLM层： OpenAI GPT-4o（主模型）+ GPT-4o-mini（轻量子任务），通过 OpenAI API 直接调用
• 协议层： 自研 MCP 协议实现（MCPRouter + MCPMessage），6 工具集中注册管理，Agent 不再直接 new Tool
• Agent层： 每个 Sub Agent 接受 MCPRouter 注入，通过 router.call() 统一调用工具，附带 scenario-driven 决策链
• 后端： Python FastAPI + WebSocket 流式推送，v2 API Server 使用 AGENT_OUTPUT_KEYS 集中映射 + decision_chain 卡片类型
• 前端： React + TypeScript + Tailwind CSS 单页应用，结构化卡片渲染 + 并行 Agent 可视化
为什么从 Node.js 自研迁移到 LangGraph： v1 自研编排器的 list 分发本质是伪并行（asyncio.gather 但非 LangGraph Send 的 fan-out），且需要手写错误恢复和状态管理。LangGraph 原生支持 StateGraph + Send() 真并行、自动状态合并、节点级错误隔离，减少约 60% 编排代码量。
(c) v2 架构选择：LangGraph 编排 vs v1 自研 Orchestrator
两种方式的对比：
维度 v1 自研编排器 (Node.js) v2 LangGraph (Python) 并行模式 伪并行（list 分发 + asyncio.gather） 真并行 （Send() fan-out，每个 Agent 独立执行）错误处理 手写 try-except + 全局 flag 节点级隔离 （_run_agent_safe + agent_errors 追踪）状态管理 手动 merge dict 自动 （PipelineState TypedDict + add_messages reducer）编排代码量 ~220 行 ~115 行 （减少 ~48%）工具调用 Agent 直接 new Tool() MCPRouter 注入 （router.call() 统一管理）
迁移决策： LangGraph 不是一个"大而全"的框架：它只做状态图编排（StateGraph + Node + Edge），不强制使用 LangChain 生态的其他组件。迁移后编排代码量减少约 48%，同时获得了真并行、自动状态合并和节点级错误隔离三个 v1 缺失的能力。
(d) 为什么Sub Agent模式适合跨境电商场景
核心原因：任务可拆解、领域可隔离、失败可定位。
• 任务可拆解： 跨境电商的业务链路天然分为6个独立阶段（需求→调研→选品→文案→合规→运营），每个阶段有明确的输入/输出，适合拆分为独立Agent
• 领域可隔离： 每个Agent的System Prompt和工具集完全不同（调研Agent需要搜索工具，合规Agent需要法规库，文案Agent需要翻译工具）。如果用单个大Agent，Prompt会变得极其臃肿，上下文窗口会被无关信息占用
• 失败可定位： Sub Agent模式下，如果最终结果有问题，可以通过检查每个Sub Agent的输出精确定位是哪个环节出了问题。单Agent模式下所有逻辑混在一起，难以定位
对比单Agent方案： 如果用单个GPT-4o完成全部6个环节，需要一次性输入所有工具定义和业务规则，Prompt长度会超过4000 tokens，导致注意力分散、输出质量下降。拆分为6个Sub Agent后，每个Agent的Prompt控制在500-800 tokens，专注度更高。
(e) v2 并行执行机制与通讯方式
真并行实现： Intent Parser 解析完成后，route_after_intent 返回 [Send("market_analyst", state), Send("product_scout", state), Send("compliance", state)]：LangGraph 将同一 state 副本 fan-out 至 3 个 Agent 节点，各自独立异步执行，最终在 Compiler 节点自动合并状态。
错误恢复： 每个 Agent 节点由 _run_agent_safe() 包裹，单个 Agent 失败不阻断其他并行 Agent。失败信息写入 agent_errors，Compiler 在结果中展示"部分成功"状态，不丢失已成功的 Agent 结果。
Sub Agent对Main Agent的输出结构： 针对通过筛选和未通过筛选两种情况，定义了不同的输出Schema：
// 通过筛选的输出结构
{
"status": "pass",
"agent": "需求解析Agent",
"intent": { "category": "选品", "keywords": ["蓝牙耳机","TWS"], "confidence": 0.95 },
"structured_data": { "budget": "200-500元", "target_market": "东南亚", "quantity": 100 },
"next_agent": "市场调研Agent",
"latency_ms": 180
}
// 未通过筛选的输出结构
{
"status": "fail",
"agent": "合规审核Agent",
"reason": "商品涉及CE认证缺失",
"severity": "high",
"suggestion": "建议补充CE认证文件或更换供应商",
"blocked": true,
"fallback": "运营策略Agent（生成合规整改建议）"
}
设计决策： 通过/失败两种输出结构的核心差异在于：pass状态携带next_agent字段引导流转，fail状态携带suggestion和fallback字段提供补救路径。v2 中 LangGraph Compiler 统一处理状态汇总：不管 Agent 返回 pass 还是 fail，agent_errors 追踪部分失败，Compiler 输出"部分成功"卡片而非直接终止。
PM工作流标准化工具。把AI使用经验沉淀为可复用的标准化资产。
📚
Prompt Library · AIGC提示词库
开源工具 · 2025.11-至今
按PM工作流分类的标准化Prompt模板库，12个模板覆盖6步工作流。GitHub开源（MIT协议）。
12个标准化Prompt · 8个分类 · 19项PRD检查清单系统化
体验 Demo →
用开源硬件小成本验证软硬协同的产品可行性：目标是与硬件团队高效协作，而非转行做硬件
🔧
硬件动手实践
3个原型实验，验证"软件PM理解硬件边界"的价值
2
小小汪·电子宠物机器狗 ： 拼装 + Vibecoding
买了现成的PCB板和3D打印外壳，自己动手做了组装和固件配置，然后用 Vibe Coding 参考开源代码写了交互逻辑。最大的收获不是硬件本身，而是理解了"为什么加一个看起来很小的功能，硬件工程师说要改BOM"：从此评估需求时对技术方给的工期有了更实际的判断。参考了
立创开源硬件平台 的 smart-puppy 和 GitHub 上
PetoiCamp/OpenCat 。
3
树莓派 + 语音控制 ： 探索"自然语言→硬件执行"
买了树莓派和现成的传感器、舵机模组，按开源教程接线配置，用 Vibe Coding 实现了语音指令控制硬件动作。这是一个轻量的"AI+硬件"交互验证：用户说一句话，机器做出反应。虽然只是跑通了 Demo，但让我对端侧 AI 在 IoT 设备上的可行性有了直观判断。参考了
OpenClaw 和
av4625/robot_dog 的开源方案。
4
为什么PM要碰硬件
不是为了会焊电路板。 是三个实际价值：①快速验证：买现成模组跟着开源教程跑通一个原型，在硬件团队排期前就能拿到初步数据，让需求评审有据可依；②技术判断力：亲手组装过、跑通过、改过代码，和硬件团队沟通时能更准确理解工期和成本背后的技术约束；③沟通效率：需求评审时，评估方案周期和成本的判断更接近实际，减少来回对齐的沟通成本。
🔄
底层逻辑：Harness 五步法
所有 AI 项目遵循同一思维链路：从用户任务出发，经过评测验证，用数据驱动迭代
功能点 → AI技术方案 → 评测集+MECE标准 → 跑评测找链路问题 → 改链路重测 → 展示分数改善
1 从具体用户任务 出发，不是从模型能力出发
2 选择AI技术方案 （Prompt Chain / RAG / Workflow / Agent Team），解释为什么不用更复杂/更简单的
3 设计评测集 + MECE评分标准 ，目的是发现链路问题而非证明"AI很厉害"
4 跑评测集，定位链路节点具体问题 ，归因到 prompt / query rewrite / context / routing / fallback
5 针对低分维度迭代对应节点，用同一评测集复测 ，观察指标改善
🚦
六道关卡（Stage Gate 1-6）
设计任何 AI 功能前，逐一验证这六关：任一关不通过就暂停
G 关卡 检查什么 我的实际应用 1 场景与需求 用户是谁？失败成本？ "练错无人纠正"→训练效果差+受伤风险 2 AI必要性 为什么不用规则/人工？ PRD检查=确定规则→System Prompt比RAG更稳定 3 链路可落地 输入→AI→验证→输出→人确认→反馈 三重护栏：操作确认→过程可解释→结果可修正 4 评测可设计 怎么判断AI好坏？ 四维拆解+人工对照验证 5 Badcase迭代 出错怎么归因改？ 13处遗漏→按维度归类→优化Prompt 6 证据边界 能写/不能写什么？ 实测数据可讲，不编造未上线效果
从"给人用的工具"到"给 AI 用的工具"：PM 的 AI 协作范式转变。不只是设计 AI 产品，更是自己使用 AI 工作。
🤖
AI Native PM 的三层工作流
把 AI 使用经验沉淀为可复用资产：让 AI 成为可管理的协作者，而不只是一次性工具
第一层：我的 AI 协作工具链
🖥️
Cursor
Vibe Coding 原型交付13个 可交互产品
→
⚙️
Dify
Workflow 编排
→
🐙
GitHub
开源 Prompt 资产
→
📋
Obsidian
知识沉淀
第二层：我如何定义 AI 与人的交互节点
核心原则：AI 做执行，人做判断。每个 AI 工作流都必须在关键节点设置人的介入点，否则你不是在管理 AI，你只是在看 AI 表演。
护栏 触发时机 人做什么 AI 做什么 操作确认 提交 PRD 前 确认输入完整、补充上下文 等待，不作判断 过程可解释 AI 审核后 查看每项判据和原文引用 逐项输出 0/1 判定 + 原文依据 结果可修正 输出报告后 手动修改 AI 误判项 记录修正，下次同类场景可参照
第三层：我写给 AI 的 Skill 设计思路
好的 Skill = 好的 PRD：输入明确、输出结构化、可独立测试、可组合复用。以 PRD Quality Gate 的 System Prompt 设计为例：
PRD Quality Gate · Skill 边界定义
1 输入： PRD 全文 + 19 项检查规则（每项含名称/描述/判定标准/示例）
2 处理： 逐项 0/1 判定 + 引用原文定位 + 判断依据（用 Temp 0.2 控制一致性）
3 输出： 结构化 JSON（pass/fail + reason + suggestion），不做自由文本
4 与人交互节点： 提交确认（人→AI）→ 审核报告（AI→人）→ 人工可修改误判（人→系统）
5 AI 不可做的事： 替人做通过/不通过的最终决策：AI 只看规则，不替判断
设计逻辑： 市面上大多数 Prompt 库按"写作/营销/编程"等 AI 能力分类，但 PM 的工作不是"写一篇文章"而是"定义需求→设计功能→写 PRD→评审→验收→复盘"。我的 Skill 设计遵循三个原则：①按 PM 工作流节点分类而非按 AI 能力分类；②输入输出必须结构化（JSON），方便 Agent 间流转；③每个 Skill 都定义"AI 不可做的事"：这是 PM 判断力的体现，不是技术问题。
同样的一件事，开发的逻辑是做一个好用的工具给用户；AI Native 的逻辑是写一套 Skill：既然工作流程是固定的、区别在于设计上，那就直接在 Skill 里定好边界以及和人交互的节点，剩下的交给 AI 完成。
下面不是行业简报，是四个我反复验证过的判断 ：每条关键信号都能溯源到官方原文，并在作品集里有一个产品决策做印证（2026-09 更新）。
⚡
判断一：Agent 的价值单位变了：从"回答质量"变成"任务完成率"
AI 产品不再以"答得好不好"取胜，而以"替你把事做完没有"取胜
判断： 2026 下半年，AI 产品的竞争点从对话质量转移到任务闭环：用户不再满足于"AI 回答了"，而是"AI 把这一件事办成了"。这要求产品设计以执行链路 为单位，而不是以对话轮次为单位。佐证： 海外：Anthropic Cowork 从 2026.01 桌面预览到 02.24 企业 GA、07 移动/网页全端，官方数据显示超 90% 使用与编程无关 （Anthropic，2026.07）；Google 在 I/O 发布 7×24 云端个人 Agent Gemini Spark，并把 Gemini 3.5 官方定位为 "frontier intelligence with action"（Google，2026.05）。国内同步规模化：美团 CatPaw 内部 9 万员工、3 万个 Agent （官方，2026.07）；字节 Seed2.1 官方定位从"一次回答"转向"端到端交付"（官方，2026.06）。在作品集里： 跨境电商 6-Agent 从第一天就让每个 Sub-Agent 直接产出结果（合规报告 / 定价策略 / 产品文案），而不是给用户建议；会议舱把"这一场会议的产出"变成可追踪、有状态流转的待办闭环。我在个人产品里验证的正是"任务闭环优先"。
🔌
判断二：协议标准化是 Agent 产品的终局，不是可选项
产品绑不绑单一模型，取决于你押注协议还是押注 SDK
判断： 多供应商 Agent 协作会成为默认形态，谁能统一工具描述与调用协议，谁就掌握生态入口：所以"用协议组织 Agent"比"绑定某家 SDK"更接近终局。佐证： 8.18 Anthropic 合并 MCP v2.0 草案、OpenAI 工程师任共同 reviewer（统一工具 Schema、异步流式传输、跨 Agent 上下文传播）；Gartner 显示 62% Fortune 500 把"协议不兼容"列为多供应商 Agent 最大障碍；Google 未签名，阵营分叉风险显现。生态外扩实证：字节火山 Mobile Use Agent 原生支持 MCP + Skills 、扣子 2.5 已内置（官方，2026.04）——协议生态正从桌面扩向移动端；Google 官方同步给 MCP 建了可横向评测的行业基准 MCP Atlas （Gemini 3.5，83.6%，2026.05）。在作品集里： GlobalFUN v2 在 v2.0 草案之前就采用 MCPRouter + 原生 MCP 服务总线编排 6 个 Sub-Agent，而非绑定单一厂商 SDK：押注协议标准化的方向被 v2.0 直接验证。
⚙️
判断三：模型层会持续贬值，编排与评测才保值
当开源框架能把 Claude Code / Codex 当子代理编排，模型不再是壁垒
判断： 模型能力会被快速追平，而"怎么编排 Agent、怎么验证它真的有用"成为新的稀缺能力：PM 的价值从选模型转向设计与评测。佐证： 8.13 DeepSeek Harness 开源（MIT，"一切皆插件"的 Agent 运行时，官方插件可把 Claude Code / Codex 当子代理）；Composio 实测 DeepSeek V4-Flash 真实多步任务 240 次仅 129 次通过：基准分高不代表编排可用，评测是硬功夫。头部厂商同步把评测重心迁到真实任务：字节 Seed2.1 用 GDPVal（真实任务经济价值）与 ALE（新任务泛化） 做评估（官方，2026.06）；Google 在 GDPval 上给出 1656 Elo、并上线 MCP Atlas（官方，2026.05）；OpenAI 于 8.06 以 System Card 公开 GPT-5.6 能力与安全评测（官方，2026.08）；美团把 Agent 评测体系用于 31 万行代码 AI 重构 的生产管理（官方，2026.05）。在作品集里： PRD Quality Gate 用评测集驱动迭代：同一份 PRD、19 项规则检出 13 处遗漏后不盲目加规则，而是归因"异常流程占 54%"、补第 20 项规则、再用同一份 PRD 复测验证。跨境电商把 6-Agent 当作可插拔组件而非写死链路。
📱
判断四：端侧 AI 是产品决策，不是技术选型
"什么必须本地、什么可上云、延迟容忍度多少"先于任何模型参数
判断： 端侧 AI 的本质是一组产品约束的取舍：隐私数据不出设备、推理延迟可容忍、离线可用：先回答这三个问题，再谈模型。隐私不是小众偏好，是被监管验证过的行业标准。佐证： 7 月 WAIC 2026，7 款手机端侧 AI 完成国家备案，端侧推理成本降至 1/10，端侧 AI 纳入正式监管框架。分端运行印证：字节用"云手机 + 视觉模型"执行移动端任务（官方，2026.04），美团 CatPaw 移动端发起任务、云端 7×24 长跑（官方，2026.07）——算力放端上还是云端，正成为按场景定夺的产品决策。端侧能力同步升级：Google I/O 展示 Gemini Nano 端侧多模态与 AppFunctions（App 级 MCP 对接，媒体转述待官方原文核实）。在作品集里： 宠伴 83% 用户拒云上传 → 选 Tesseract.js 本地 OCR、Whisper 本地转写（商业机密不上云）；PixelPick 四维评分用 Canvas 本地像素计算而非调用视觉大模型：零上传、零延迟、评分确定性（同一张照片两次结果一致，用户才敢信任 AI 推荐）。
📎
本页核心信号的官方一手来源
9 条官方原文，每条都可点验（美团 · 字节 · Anthropic · Google · OpenAI · DeepSeek · 2026-09）
✨
我能为团队带来什么
🔍 洞察用户没说出口的
语用学深访 × 行为数据/差评交叉验证：宠伴记录耗时 -60%、NPS +12→+38
⚙️ 用对 AI 边界
Prompt / RAG / Agent / 端侧按场景选型：确定性审核直写规则而非 RAG，本地 OCR / Whisper 守住隐私
🧪 Agent 编排与评测
6-Agent 作可插拔组件；用评测集做技术决策：13 处遗漏→归因→补规则→同 PRD 复测
📱 软硬协同 × 影像 AI
Insta360 运动相机软件 PM + 宠伴 ESP32 硬件原型：在硬件约束里设计 AI 软件体验