从AI Scribe到多Agent平台，HiPaw的产品范围在四年间不断膨胀，却让MVP边界越来越模糊。作者复盘发现，Vibe Coding降低了开发门槛，却放大了“完整产品幻觉”。当技术实现越来越快，产品取舍反而成为更核心的挑战。本文深入拆解功能膨胀的路径与MVP的本质。

2023 年，我开始关注动物医疗 AI。那时还没有一个成形的产品，我更关心的是：AI 能不能进入动物医院的真实工作流，而不只是做一个脱离诊疗现场的问答工具？

2024 年，我把这份关注第一次收敛成 HiPaw 的产品设想。最初的问题很具体：兽医在接诊时要同时和宠主沟通、观察或检查动物，还要记录病历。现场录入可能打断诊疗节奏，诊后补写又增加整理负担，并可能遗漏信息。最早的方案，是让 AI 把诊疗内容整理成一份 SOAP 病历草稿，再由兽医审核和修改。

当时，我已经开始借助生成式 AI 做原型。后来，这种开发方式有了一个更流行的名字——Vibe Coding。到了 2025—2026 年，随着我继续补 PRD、研究竞品和技术方案，HiPaw 也在一轮轮修改中不断长大：既然已经理解了诊疗内容，是不是可以顺便生成宠主能看懂的护理说明？既然已经读取了病例，是不是可以再查指南和药典？既然能查资料，是不是还可以做禁忌提醒、鉴别诊断和用药审核？任务越来越多，是不是还需要 Router、RAG、Reranking、Function Calling 和多个 Agent 协作？

2026 年，我重新打开最新一版飞书文档，发现自己在“MVP 版明确目标”下面写了一句话：

以 AI Scribe 作为 MVP，把诊疗对话转化为可审核、可编辑的结构化病历。

看起来，范围已经很清楚了。但在同一份文档的后面，我又列出了两条“HiPaw MVP 核心流程”：一条是录音、转写、生成病历、医生审核；另一条是 Ask HiPaw——医生提出问题，系统读取患宠上下文，检索知识库，按需调用工具，再生成回答。

换句话说，我一边告诉自己“首版只做 Scribe”，一边又把 Clinical Advisor 的雏形留在了 MVP 里。

这些年份记录的是一个产品设想如何变化，不代表 HiPaw 已经在相应年份上线或完成验证。现有材料能够证明的是方案和目标不断变得完整，却还不能证明这些功能已经产生真实效果。

这些功能单独拿出来看，几乎每一个都有理由。也正因为没有哪个想法明显荒唐，我很难主动删掉它们。文档越来越完整，系统架构越来越像一个平台，但“MVP 到底要验证什么”反而越来越模糊。

我一度把这种卡顿理解为技术鸿沟：是不是因为我还不够懂 Agent、RAG 和 Reranking，所以做不好版本规划？重新回看从 2024 年到现在的方案后，我发现技术名词只是表层。更大的问题是，我把长期愿景、完整产品和当前实验放进了同一个版本。

2026 年的这次复盘，让我形成了一个还在继续验证的判断：Vibe Coding 降低了功能实现的门槛，却没有降低产品取舍、AI 评测和风险控制的难度。MVP 不是功能最少，而是一次只承担最少的不确定性。

一、从 Scribe 到多 Agent 平台，范围是怎样一步步长大的？

回看 2025—2026 年的几轮方案，HiPaw 的范围不是突然膨胀的，而是沿着用户旅程一步步扩大的。

第一步是 Scribe：录音或口述进入系统，经过转写和信息整理，生成固定模板的 SOAP 病历，医生审核后复制到原来的医院系统。这条链路对应一个相对清楚的任务——减少兽医整理病历的负担。

第二步是 Client Guide：既然病历已经生成，为什么不再把专业表达改写成宠主看得懂的居家护理说明？它似乎只是同一份内容换一种语言，但用户已经从兽医变成了宠主，成功标准也从“记录是否准确”变成了“沟通是否清楚、是否减少重复解释”。

第三步是 Medical Auditor：如果系统已经知道动物的物种、体重和用药信息，是不是可以再核验剂量和禁忌？从界面上看，它可能只是多一张提醒卡片；从产品责任看，它已经开始影响医疗行为。

第四步是 Clinical Advisor：读取当前病例、历史病历和外部知识，为医生提供资料、鉴别方向或下一步检查建议。为了让回答有依据，方案自然又引出了知识库、RAG、证据引用、知识更新、Reranking、工具调用和拒答机制。

到了这里，HiPaw 已经不再是一款病历生成工具，而是同时想解决病历记录、宠主沟通、资料查询和临床判断四类问题。它们发生在同一场诊疗中，也可能共享相同的病例上下文，但“相关”不等于“应该在同一版本里解决”。

我过去容易把这种连续性误认为完整性：用户完成病历以后还要给宠主解释，所以 Client Guide 似乎必不可少；医生看到复杂病例还要查资料，所以 Clinical Advisor 也像是闭环的一部分。可如果按照这个逻辑继续追下去，支付、随访、复诊提醒、库存、保险和医院管理也都能进入同一张产品蓝图。

产品愿景当然可以完整。问题在于，我没有把愿景和版本分开。

长期愿景回答的是：HiPaw 最终希望成为什么？

可用产品回答的是：它能否稳定地解决某一类用户任务？

MVP 回答的则应该是：目前最关键、最不确定的假设是什么，我怎样以尽可能小的成本获得足以做下一步决策的证据？

当这三个问题被写在同一层级，路线图就很容易退化成功能清单。功能清单越完整，MVP 越难开始。

图 1：每一项新增能力单独看都有理由，组合起来却让 MVP 失去清晰边界。

二、Vibe Coding 降低了开发成本，却放大了“完整产品幻觉”

在过去，开发资源本身会强迫团队取舍。一个功能需要排期、设计、前后端协作和测试，提出新需求的人必须说明它为什么值得做。现在，Vibe Coding 能让我很快做出页面、串起模型调用，甚至搭出一个看上去相当完整的 Demo。新增功能的心理成本明显降低了。

对我来说，这带来了三个很容易混淆的判断。

第一，“模型能生成”被误认为“产品能交付”。

大模型可以在几秒内生成一段临床建议，这说明文字能够被生成，却不能证明它引用了正确资料、适用于当前物种和病例，也不能证明它没有遗漏禁忌。一个 Demo 只需要成功一次；一个进入工作流的产品，需要知道它会以哪些方式失败，以及失败后谁能发现、谁来纠正。

第二，“多一个入口”被误认为“只多一个功能”。

在界面上，Clinical Advisor 可能只是病历右侧的一块问答区域。但它背后新增的不是一个输入框，而是病例上下文权限、医学知识来源、检索和排序、引用绑定、知识版本、专家评测、无答案处理、日志审计以及责任边界。开发出来的按钮只是水面上的部分。

第三，“技术上相关”被误认为“产品上同版”。

Scribe 和 Clinical Advisor 都要读取诊疗信息，所以把它们放进同一个架构很自然。但共享输入不代表共享价值假设。就像导航和自动驾驶都要使用地图，它们仍然不是同一个风险等级的功能。

医疗场景又进一步放大了这种完整产品幻觉。诊疗记录、资料查询、用药提醒和宠主沟通本来就彼此相连，每个环节都可能发现值得解决的问题。如果我只按“是否有用”来判断，每项功能都可能得到肯定答案；只有改成“它是否是验证本轮核心假设不可缺少的部分”，范围才有机会收住。

因此，MVP 之所以需要小，不只是因为开发资源有限，也因为一个团队在同一阶段能够建立和解释的证据有限。如果把语音采集、病历生成、知识检索和临床建议一起测试，即使结果不好，也很难判断是输入质量、生成质量、检索效果出了问题，还是用户根本不需要其中某项能力。功能越多，得到的未必是更多信息，也可能只是更难解释的结果。

所以，Vibe Coding 并没有让产品经理的工作变少。它只是把难度从“如何把功能做出来”，转移到了“为什么现在要做、做到什么程度、怎样证明有效、什么情况下必须停止”。当实现速度越来越快，取舍速度反而需要更快。

三、Scribe 和 Clinical Advisor 之间，不是一个功能的距离

在产品结构图里，Scribe Agent 和 Clinical Advisor Agent 可以被画成两个并列方框。但从信息来源、失败后果和评测方式看，它们更像两类产品。

Scribe 的主要任务，是把诊疗过程中已经出现的信息提取出来，整理成结构化病历草稿。它并不等于低风险：宠物名称或说话人归属写错，关键症状被遗漏，“没有呕吐”被写成“有呕吐”，或者 0.5 ml 被写成 5 ml，都可能造成严重后果。但它的主要依据仍然是原始录音、转写内容和病历模板，医生也可以把草稿与刚刚发生的诊疗过程进行对照。

Clinical Advisor 则会引入诊疗现场之外的新信息，例如指南、药典、禁忌、鉴别方向和处置建议。它不只是在整理已经发生的事实，而是在参与判断。一个语言流畅、甚至带着引用的错误建议，未必容易被用户立即发现。

两者的差别可以这样看：

图 3：Scribe 和 Clinical Advisor 共享病例上下文，却需要完全不同的评测与风险控制。

1. Scribe 不能只看“写得像不像”

如果把 Scribe 当成普通文本生成，很容易只看转写准确率、文本相似度或病历是否通顺。但对医疗记录来说，字符变化很小，不代表错误很小。“无发热”变成“有发热”，只差一个字，临床含义却完全不同。

因此，我下一步需要为 Scribe 建立的评测至少有三层。

第一层是事实质量：关键症状、检查结果、既往史和医生判断是否被正确提取，有没有加入原始内容中不存在的事实。

第二层是严重错误：数字、单位、剂量、否定关系、物种、对象和说话人归属是否出错。这些错误不能被平均准确率掩盖，也不能和措辞不够自然放在同一个等级里计算。

第三层是工作流价值：医生从诊疗结束到完成病历实际用了多长时间，需要修改多少，是否因为不信任而重新写一遍，下次是否仍愿意主动使用。

文档中曾经出现“病历提效 70%”“术语识别率大于 95%”之类的目标，但这些目前只是目标，不是结果。真正开始验证时，我不能先写一个漂亮的百分比，再去寻找支持它的数据。更合理的顺序是先测量原流程的基线，再冻结评测样本和错误分类，最后判断产品是否真的减少了总工作时间。

2. RAG 能找到资料，却不能自动证明建议安全

Clinical Advisor 的复杂度首先来自知识。模型参数中已有的信息可能过时，也无法保证适用于当前病例，因此，只要产品需要回答外部或持续更新的医学知识，就需要考虑资料准入、检索、排序、版本控制和证据溯源。RAG 可能是其中一种重要方案。

但“检索到了资料”和“给出了可信建议”之间仍然隔着很长一段距离。

系统可能检索到正确主题下却不适用于当前物种的资料；可能引用了可靠文献，却在总结时扩大了原文结论；也可能因为体重、年龄、肝肾状态或当前用药缺失，给出在一般情况下成立、对当前病例却危险的建议。引用存在，不代表引用真的支持结论；召回率高，也不代表最后的回答可用。

Clinical Advisor 因此需要另一套评测：关键证据是否被检索到，资料是否适用且处于正确版本，回答中的重要判断能否被引用内容支持，病例条件是否被正确使用，系统在信息不足时能否追问或拒答，以及兽医专家如何判断危险遗漏和误报。

这里还会出现提醒疲劳。如果系统为了避免漏掉风险而频繁报警，医生可能很快忽略提示；如果为了减少打扰而提高触发门槛，又可能错过真正危险的情况。这已经不是“再接一个知识库”能够解决的问题，而是一套独立的产品、评测和治理工作。

所以，Scribe 和 Clinical Advisor 不能仅仅因为都服务兽医、都读取病例，就被当作同一 MVP 的两个功能。它们验证不同的用户价值，使用不同的数据和评测体系，也跨越了不同的信任与风险等级。共享上下文，不等于应该共享 MVP。

四、重新定义 MVP：不是最少功能，而是最小证据闭环

过去我把 MVP 想成“功能少一点的完整产品”。这种理解很容易把产品愿景压缩后整体搬进首版：完整产品有三个 Agent，MVP 就每个 Agent 先做一个简单版本；完整产品要接医院系统，MVP 就先做一个轻量接口。

但三个不成熟的 Agent 仍然在同时验证三个问题。一套简化的系统集成，也仍然会引入权限、数据格式和协作成本。功能做得简陋，并不代表承担的不确定性更少。

我现在更愿意把 MVP 定义成“最小证据闭环”：用户能在一个明确场景里完成一次任务，模型产生输出，用户可以审核和纠正，产品记录结果，团队据此决定继续、调整还是停止。

这个闭环至少要回答五个问题：

1. 这一版只验证哪个关键假设？
2. 用户完成任务的最短路径是什么？
3. 哪些功能明确不进入本版？
4. 用什么价值指标和严重错误判断结果？
5. 获得什么证据后，才允许增加下一层能力？

按照这个方法，HiPaw 的首版假设可以收敛为：

面向一种明确的犬猫门诊场景，兽医在诊疗后完成一段简短的主动口述，系统生成固定格式、可编辑的 SOAP 病历草稿。医生审核后，一键复制到原有系统。首版不诊断、不推荐用药，也不自动提交正式病历。

它只需要验证一件事：在严重错误能够被识别和控制的前提下，结构化病历草稿能否明显减少兽医的病历整理时间，并让其愿意重复使用？

最短闭环也随之变成：

主动口述 → 生成 SOAP 草稿 → 医生编辑确认 → 复制使用 → 记录耗时和修改

图 2：MVP 的最小单位不是一个 Agent，而是一条能够产生决策证据的完整闭环。

为什么先做“诊后主动口述”，而不是一开始就做持续录音、实时转写和多人说话分离？因为首轮要验证的是病历草稿的价值，而不是最理想的采集方式。如果连一段干净的主动口述都不能生成有用的草稿，提前解决诊室噪声、唤醒词、说话人识别和中断续接，并不会让核心假设更成立。

同样，为什么先复制到原有系统，而不是直接打通医院 ERP？因为深度集成会增加权限、接口和部署成本，却不一定帮助我更快知道医生是否真的需要这份草稿。一键复制可能不够优雅，但它更适合隔离“病历价值”和“系统集成”两个问题。

1. 先写“不做清单”

如果 Scribe 是本轮唯一假设，那么首版可以明确不做：

• Clinical Advisor 和患宠个体化诊疗建议；
• Client Guide 和多种宠主交付形式；
• Router 与复杂的多 Agent 协作；
• 持续监听、唤醒词和多人说话人分离；
• 多科室、多物种和大量自定义模板；
• 自动写入或提交正式病历；
• 在需求尚未证明前加入完整 RAG、Reranking 和长期记忆。

“不做”不是永久放弃，而是在保护当前实验的解释力。以后每增加一项，都应该能回答：是哪条用户证据或哪类失败案例，要求我们现在加入它？“未来可能有用”可以进入路线图，但不能自动获得进入 MVP 的资格。

2. 把版本写成证据阶梯，而不是功能阶梯

在现有材料还缺少真实试用数据的前提下，我更倾向于这样安排下一步：

V0：人工辅助验证。在获得授权并完成脱敏的前提下，用少量历史材料或合成病例生成固定 SOAP 草稿，请专业人员标注遗漏、无依据新增、数字单位和否定错误。此时甚至不需要完整前端，目标是确认输出是否值得继续做。

V0.1：单闭环原型。只实现主动口述或输入转写、生成固定 SOAP、编辑和复制，同时记录生成时间、审核时间和修改内容。它验证的不是页面是否漂亮，而是用户是否真的省时并愿意再用。

V0.2：工作流增强。只有当病历草稿的价值已经出现，同时“主动口述”被证明是主要阻碍时，再考虑实时录音、降噪、说话人识别、中断续接和模板适配。

后续独立实验：Evidence Search。如果用户确实有高频资料查询需求，可以先做主动发起、范围很窄的证据检索，只展示来源、版本和关键原文，不急着输出患宠个体化建议。

Clinical Advisor：独立立项。它需要重新定义用户任务、知识范围、专家评测集、安全门槛和拒答条件，不以“Scribe 做完后顺便加上”作为进入版本的理由。

这条路线看起来没有原来的多 Agent 平台“完整”，但它能让每一步的结果更容易解释。留存不好时，我可以判断是病历草稿没有价值、质量不够，还是使用路径太麻烦，而不是面对四个模块猜测到底哪里出了问题。

3. 在开发前写下停止条件

路线图通常只写“达到什么结果继续”，却很少写“什么情况下停止”。但停止条件恰恰能阻止团队用新功能掩盖旧假设没有成立。

例如，医生认可病历记录痛点，却不愿在实际流程中使用生成草稿；生成看上去很快，审核和修改反而花费更多时间；关键遗漏或无依据新增反复出现，医生也难以及时发现；或者只有加上 Clinical Advisor，产品才显得“有价值”。这些结果都不应该自动导向“再加一个功能”，而应该触发调整、缩小场景，甚至暂停当前方向。

停止不等于项目失败。它意味着这轮实验提供了决策信息。一个没有停止条件的 MVP，很容易成为只能向前增加、不能回头验证的微型路线图。

五、AIPM 的技术能力，也包括知道什么时候不用技术

重新收敛 MVP，并不意味着 Agent、RAG、Reranking 和 Function Calling 不重要。我仍然需要理解它们，只是学习和使用的顺序应该从“这个产品能不能用上它”，变成“当前任务为什么需要它”。

对 HiPaw 来说，可以先建立这样的对应关系：

• 结构化输出解决的是如何把已有诊疗内容稳定放入 SOAP 字段。它直接服务 Scribe 的核心任务。
• RAG解决的是如何从模型上下文之外查找资料。当任务只是整理当前口述时，未必需要完整 RAG；当产品进入外部医学证据查询时，它才成为重点。
• Reranking解决的是初次检索结果中，真正相关的资料排序不够靠前。只有评测表明“资料已经召回，但排序经常错误”时，它才是确定的问题，而不是架构图上的标配。
• Function Calling适合查询数据库、执行确定性计算或把确认后的内容交给其他系统。它让模型决定调用什么，却不应让模型替代确定性规则本身。
• Agent适合需要动态规划、多步选择工具和根据结果继续行动的任务。固定的“输入—生成—审核—复制”流程，可以先用普通工作流完成。

这也改变了我理解技术名词的方式。对 AIPM 来说，只会解释定义还不够，更重要的是能回答四个问题：它解决哪一种失败？什么证据说明现在需要它？加入后会新增什么风险和评测成本？有没有更简单的方案可以先验证？

例如，用药剂量核验听起来很适合交给“Medical Auditor Agent”，但关键计算并不适合只凭模型的语言概率完成。更可能的方案是让结构化药典和确定性规则负责计算与硬性校验，模型负责理解问题、查找资料或解释结果。此时，产品经理需要做的不是决定“用不用 Agent”，而是把生成、检索、计算和执行的边界分清楚。

技术不是越多越先进。一个简单工作流如果能以更低成本、更清楚的失败路径验证用户价值，就比一个暂时无法评测的多 Agent 系统更适合 MVP。

六、从这次复盘里，我真正需要补的三种能力

回看从 2023 年关注动物医疗 AI、2024 年形成 HiPaw 设想，到 2025—2026 年持续改版的过程，我不再认为自己的问题只是“技术懂得不够多”。这也不是一篇“我已经把 HiPaw 做成功了”的项目总结。现有文档能证明的是，我已经完成了较完整的场景、功能和候选技术梳理；它不能证明产品已经上线，也没有真实试用数据证明病历记录就是用户最高优先级的需求，更不能证明 Clinical Advisor 已经具备可靠的医疗价值。

但正因为项目仍处在方案和学习阶段，这次范围膨胀才暴露出我作为 AIPM 更需要训练的三种能力。

第一是问题边界能力。我需要把“用户还有哪些相关问题”与“这一版只解决什么”分开，把长期愿景、产品版本和当前实验放在不同层级。一个问题即使存在，也不代表它现在必须进入产品。

第二是证据设计能力。在做页面和搭流程之前，先写清核心假设、原流程基线、评测样本、严重错误、价值指标和停止条件。如果还不知道怎样判断功能是否成立，继续开发往往只会增加沉没成本。

第三是风险分层能力。我可以把医疗 AI 的能力粗略分成：

信息整理 → 资料检索 → 选项生成 → 个体化建议 → 自动执行

越往后，输出越可能改变真实医疗行为，所需的数据、专家评测、人工审核和治理机制也越重。一个版本最好不要同时跨越多个风险等级。Scribe 和 Clinical Advisor 看似只隔着一次功能扩展，实际已经从信息整理走向资料检索和临床判断。

为了让这些能力不只停留在反思里，我准备给之后的版本规划增加几条硬约束：

1. 一个版本只有一个核心学习目标。
2. 每个 Must-have 都必须说明它帮助验证哪条假设。
3. 同一版本不同时增加新场景、新数据源和新风险等级。
4. “以后可能需要”默认进入路线图，而不是当前开发清单。
5. 开发前先写一页“MVP 合同”：目标用户、核心场景、关键假设、最短闭环、不做清单、成功门槛、停止条件和升级条件。

我最初担心的是，自己和优秀 AIPM 之间隔着 Agent、RAG、Reranking、Function Calling 等技术名词。现在看来，真正需要跨过的鸿沟不只是“能不能理解和使用这些技术”，还有“能不能在它们都变得容易调用时，仍然守住产品边界”。

Vibe Coding 可以帮我更快做出一个功能，却不会替我判断这个功能是否应该进入当前版本。下一版 HiPaw 需要的，也许不是再增加一个 Agent，而是继续删除，直到它只剩下一件真正值得被验证的事。