超前原型策略
解决什么问题
要不要现在就投入做一个"当前模型还做不太好"的功能,团队常常因为"准确率不够"而搁置。这条经验提出一个具体做法:先把produit原型搭起来放着,把"模型能力是否够格"当作可以随新模型发布反复重新测试的变量,而不是一次性判死刑的理由。
核心内容
- 具体案例:Claude Code 的代码评审(code review)功能。团队"试了好几次"构建这个功能,早期版本(即
/codereview命令)相对简单,评审质量始终不够让工程团队真正信赖。直到 Opus 4.5、Opus 4.6、Sonnet 4.6 这一代模型上线后,团队才判断"这次的代码评审质量足够好",于是让 Claude Code 工程团队把它变成合并 PR 前的强制关卡——可以同时跑多个代码评审 agent 遍历整个代码库,并汇总出需要工程师处理的真实问题清单。 - 做法的核心不是"等模型变好了再开始做",而是提前把不完整的原型建好、放在那里,每次新模型发布时直接把新模型换进已有原型测试,看这次是否跨过了可用门槛:"这样你就知道,为了让这个产品真正可用,还缺什么;然后每次新模型出来,你就直接把它换进你已经搭好的原型里,看看这次是否补上了那个缺口。"
- 这与团队"删减脚手架"的习惯(见
harness-deprecation-as-model-improves--cat-wu)是同一套方法论的两个方向:模型变强时,一部分工作是"拆掉不再需要的辅助脚手架",另一部分工作是"把此前因能力不够而搁置的原型重新跑一遍,看是否已经解锁"。
适用边界
- 这个做法要求团队本身能拿到最新模型的内部访问权限(Anthropic 内部团队天然具备这一优势),对没有这种渠道的外部团队,只能等公开发布后才能测试,提前布局的时间窗口会短很多。
- 判断"这次模型是否真的跨过门槛、值得投入正式化"仍然需要人工评估(不只是准确率数字),尤其是对"工程团队是否信任到愿意作为强制关卡"这类高风险决策。
关键引述 · 原话
Cat Wu: "There's a lot of features that we've been testing out with prior models and the accuracy wasn't high enough for us to want to launch them... it was only with the most recent models that we felt like, okay, this code review is so good that our engineering team relies on this code review to pass before we merge PRs."
Cat Wu: "It's pretty important to build products that don't necessarily work yet so that you know, okay, what is missing for this product to work? And then with the newest model, you can just swap it into the prototype you've already made."
关联卡片
- 与 `build-for-future-capability-curve--karina-nguyen`(同语料库,OpenAI/Anthropic 研究员视角)是同一模式在不同公司、不同项目上的独立体现:提前布局产品构想,等模型能力追上后收获成果。 - 与 `harness-deprecation-as-model-improves--cat-wu` 构成"模型变强后该做什么"的一体两面。
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2