1.4 最小可用目标：MVP 流程图

选型定了，录音规范也立了，接下来是最容易激情犯错的一步：画功能清单。老板拿着白板笔准备大干一场，开口就是要有声纹识别区分谁在说话、要支持中英日多语言、要能实时投影字幕到会议室屏幕上、最好顺便把纪要翻译成英文发给海外同事。我赶紧拦住他：先跑通再迭代，MVP 的第一条纪律就是砍功能。 内部工具最怕的就是版本膨胀。功能堆得越多，每个都做得半吊子，最后同事们嫌难用，统统退回手写纪要。我们的策略是先把主干打通：从录音上传到纪要发到同事手机上，一条链路完整走通，哪怕每个环节都很粗糙。主干通了，后面添枝加叶才有意义。

砍功能的底气来自一个清醒的认知：同事们不会因为功能多而爱用一个工具，只会因为某个功能真好用而离不开它。每个半成品功能都在透支整个工具的信誉度，主干的打磨却需要集中的精力。与其每样都沾一点，不如把最痛的那一环做到极致，再回头谈扩展。这个认知后来被我应用到了之后所有内部项目上。

MVP 流程图：一条链路没有支线

砍完功能之后，MVP 的流程简单到可以在一张餐巾纸上画完。整个系统就是一条单链路，没有任何支线：

会议录音 → 上传存储 → ASR 转写 → 文本清理 → 信息提取 → 纪要页面 → 短信通知参会人

这条链路里每个环节只做一件事，环节与环节之间用存储和回调松耦合地连接：录音落到存储桶里，上传事件触发转写，转写结果再依次进入清理和提取，最后生成纪要并发出短信。任何一环失败都可以重跑，不会影响其他环节。这个设计后来被证明是整个项目最正确的架构决策——在单链路上排查问题，比在一张蜘蛛网里排查容易十倍。

画 MVP 流程图有个诀窍：每画一个节点就问自己一句，这事能不能不做。如果链路断了还能把纪要手动发出去，那这个节点就是支线，砍掉。最后留下的六个环节，每一个都是“不做就走不下去”的必经之路。

MVP 功能表：只留主干

我们把所有想要的功能摊在桌上，按“是否影响主流程”分成两类，最后 MVP 只保留了下面这张表里的六个功能：

验收标准里最关键的一条是“每条待办有责任人与截止日”——这不是技术指标，而是业务底线：如果提取出来的待办没有责任人，同事们两分钟内就会退回人工纪要。MVP 的验收标准必须从用户视角写，而不是从技术视角写，这是做内部工具最容易跑偏的地方。

还有一条经验：功能表里的优先级一栏，我当初只允许填“必须”两个字，没有“高、中、低”这种暧昧选项。一旦出现中间档位，必然有一堆功能被标成中优先级，然后顺理成章地挤进 MVP。用二元的“必须 / 暂缓”逼自己表态，是控制范围最有效的手段。

不做清单：这些功能统统暂缓

砍掉的功能比留下的多得多。我把它们也列成一张表，附上暂缓理由——后来每次有人想加功能，我就把这张表翻出来：

其中说话人分离最可惜。它技术上确实诱人，能自动标注每句话是谁说的，把纪要的可用性再推进一步。但实测下来准确率不够稳定，尤其多人抢话的场景。与其给出一份充满错误的发言人标注，不如先在纪要里留下时间戳和段落结构，让提取环节结合语境做粗粒度归集。先把体验做稳，再谈把体验做炫。

不做清单的维护方式也有讲究：每砍掉一个功能，都在理由栏写清楚什么条件可以重新启用。比如说话人分离的条件是准确率达到可用水平，多语言的条件是有真实的跨国会议需求。这样一来暂缓不等于否定，提出需求的同事也容易接受——他的想法被记住了，只是时机未到。

风险清单：先把可能翻车的地方圈出来

排期之外我还列了一张风险清单。做兼职推进的内部项目，最大的敌人不是技术难点，而是那些“没想到”：

其中第三条最值得多说一句：即便自动化做得再好，AI 打草稿、人来定稿这条原则我们一直坚持到项目最后。自动化的目标是把人的时间从两小时压到五分钟，而不是压到零——剩下那五分钟的判断，恰恰是人类不可替代的部分。这个定位决定了我们的纪要工具始终有一个简单的人工校对页面，同事愿意用，很大程度是因为他们知道最终拍板的还是人。

四周时间线：小步快跑

作为一个人兼职推进的项目，我把 MVP 排了四周的工期，每周一个可演示的里程碑：

排期的核心思想是每周交付的东西都能被同事摸到。第一周末我就拉着产品经理传了一份真实录音，虽然那时候还没有转写，但“录音能传上来且保住了”这件事本身已经建立了信任。内部项目最怕的是闭门造车三个月拿出来的完美 Demo——那时候需求早就变了。这套内部小工具的部署方式，可以参考我的轻量建站实战，用的就是同一套思路；涉及到底层云资源的规划，腾讯云五件套实战里有更系统的说明。

排期里还藏着一个小技巧：把最难的一周放在第二周而不是第四周。转写接入是整个链路不确定性最高的一环，早做早暴露问题；如果把它压到最后，前面三周看似顺利，最后一周翻车连缓冲的时间都没有。做工程方案永远要把风险最高的部分往前赶，把可预期的部分留在后面。

另一点是把验收方式写得能用一句话执行。每周验收时我就照着表格最后那一列问一个问题，答案只有通过或者不通过两种。这种二元验收让每周的演示特别高效，也避免了对不合格交付物的含糊容忍。第一个月每个周五下班前，我都会当着老板的面跑一遍这张验收单，从上传到短信，全程不碰开发机，只用平时同事用的入口。这个仪式感的小动作让老板成了我们最忠实的内测用户。

先跑通再迭代

MVP 不是低配版的偷懒，而是一种心理保护机制。四周后我们拿着这套粗糙的工具跑完了第一次真实例会，纪要确实自动发到了每个人手机上——虽然格式还丑，虽然有一两条待办没提取干净，但当短信到达的那一刻，群里炸出的那一排大拇指，让这个项目从此有了自己奔跑的动力。

从那以后，迭代变成了一件自觉的事：每周同事会用，会把不顺手的地方告诉我，我按优先级改。说话人分离后来在第三个月通过提取环节的优化部分解决了，实时字幕也在半年后加进了规划。回顾起来，如果一开始就奔着全功能去，这个项目大概率会死在第二个月的某个深夜——那时候主流程还没通，新功能在堆积，而同事们的耐心已经耗尽。先把主干走通，让工具在真实使用中长大，这是我做这个项目学到的最重要的一课。

后来我们复盘整个 MVP 阶段，发现一个反直觉的规律：同事容忍粗糙，但不能容忍不可靠。一个偶尔少条待办但稳定运行的系统，远比一个功能齐全却隔三差五罢工的系统受欢迎。MVP 想要守住口碑，优先保障的应该是稳定性和速度，而不是功能完备度。这个认知贯穿了后面所有迭代，我们宁愿某个版本砍掉一个功能，也不允许它在同事最需要的时候掉链子。

关于后续一步步的实现细节，比如分片上传怎么处理、转写结果怎么解读，我会在后面的章节里逐个展开。等工具跑稳之后，如果你想给它加上更智能的提取与交互能力，可以参考AI 智能体开发；纪要的长期归档与检索设计，推荐先读笔记知识库实战。

延伸阅读

• 轻量建站实战：内部小工具的部署与访问
• 腾讯云五件套实战：项目用到的云服务整体规划
• AI 智能体开发：纪要工具未来的智能化扩展