基建优先于功能致胜法
解决什么问题
团队做平台型/规模化产品时，容易把资源押在肉眼可见的功能（UI、亮点特性）上，而低估"看不见的地基"（可靠性、隐私、数据质量管线）才是真正决定输赢的变量。这是作者跨三家公司（Porch、WhatsApp/Messenger、Instacart）的复盘结论，外加她在微软亲历的一个具体量化案例。
核心内容
作者反思自己入职微软 AI 平台之前"没想清楚"的一件事：决定平台/产品生死的往往是看不见的基础设施，而不是外表的功能。三个具体反例：
- WhatsApp：赢下市场靠的不是贴纸、状态更新或深色模式（拿下市场时甚至还没有这些功能），而是三件基建级的事——(1) 通讯录直连，能触达你手机里每一个认识的人；(2) 可靠性和速度（"我给印度的奶奶发消息，我知道她一定能收到"）；(3) 端到端加密带来的隐私感（"你每天给最在意的 4 个人发 200 条消息，你需要确定没人能偷看"）。
- Instacart：赢的不是某个具体功能，而是一套每分钟更新 3000 次、覆盖 10 亿件商品的库存匹配引擎，能把消费者要的东西和门店实时对上。
- Porch（作者早期任职公司）：真正撑起公司第一次 5 亿美元估值的，不是"家庭报告"或"房屋风格灵感"这些用户可见功能，而是一套匹配引擎——600 万专业服务人员 × 1300 种服务类型 × 3.7 万个邮编区域，靠"一寸一寸"优化匹配质量做出来的。
量化案例（Dragon，面向医生的 AI 产品）：用合成数据微调时，代码/建议采纳率在 30%-60% 之间浮动；改为用领域专家标注的 60 万条真实医患交互数据持续微调后，采纳率提升到 83%。作者强调这只需要一个小团队跨职能持续跑这个闭环，而不需要一个大型组织。
适用边界
- 这些例子都来自"规模化平台型产品"（消息、生鲜配送、家庭服务撮合、医疗记录），对早期、体验驱动型产品未必是同一优先级——早期产品可能确实需要先靠功能/体验找到 PMF。
- 83% 这个数字是特定产品（Dragon）、特定基线（专家标注 60 万条 vs 合成数据）下的结果，不能直接套用为"专家标注一定带来 X% 提升"的通用基准，但可作为"高质量标注 vs 合成数据"量级差异的参考点。
关键引述 · 原话
"It wasn't the hundreds of features, it was all in the infrastructure and the platform." — Asha Sharma
"We saw a massive difference from when we used synthetic fine-tuning to when we annotated 600,000 patient-physician interactions by experts... something like 30 and 60 character acceptance rate depending on the run to something like 83%." — Asha Sharma
关联卡片
- 与 `three-stage-ai-adoption-pattern--asha-sharma.md` 的第二阶段（把 AI 套进已有流程并衡量真实业务影响）是同一逻辑在企业客户身上的复现
被这些卡引用
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2