模型脚手架主动弃用机制
解决什么问题
团队常常给模型加各种"脚手架"(scaffolding)来弥补它当前版本做不到的事,但很少有团队系统性地在模型变强之后主动把这些脚手架拆掉,导致产品越堆越复杂、系统提示词越写越长。这个打法给出一套具体的"该拆就拆"的维护习惯。
核心内容
- 识别:很多产品功能的本质是"给弱模型的拐杖"。经典例子是 Claude Code 的待办列表(to-do list)功能:早期模型被要求"改 20 处调用点"时,常常改了 5 处就停手。团队成员 Sid 的解法是模拟人类做法——像 VS Code 里列出所有调用点、逐一替换那样,给 Claude 一个待办列表工具,并反复提醒它"没做完列表上所有项就不能算完成"。这个功能上线后确实解决了当时的问题。
- 验证:每次新模型发布,重新审视每一条脚手架是否还需要。到了 Opus 4 及之后的模型,团队发现模型已经能在不被提醒的情况下自然地使用、完成待办列表,不再需要"你完成列表了吗"这种反复敲打式的提示。做法是每次发布新模型,通读一遍整个系统提示词,逐段自问"模型现在还需要这条提醒吗",不需要就删掉。
- 结果:待办列表这个功能本身被大幅"去重要化"——现在模型用不用它都无所谓,已经不是必要功能,只是作为用户"能看到 Claude 在做什么"的辅助展示保留下来。
- 配套心法:新模型解锁的不只是"删减",还有"全新功能"。团队多次尝试构建 Claude Code 的代码评审(code review)功能,早期模型的准确率不够,直到 Opus 4.5/4.6、Sonnet 4.6 这一代,代码评审质量才好到工程团队愿意把它作为合并 PR 前的强制关卡——这是模型跨过某个能力门槛后才被"解锁"的全新产品,而不是靠脚手架堆出来的。
适用边界
- 这套习惯要求团队愿意在每次模型发布时投入时间做"系统提示词/脚手架审计",而不是只顾着测试新功能——这本身是一项持续的维护成本。
- 判断"这条脚手架还需不需要"依赖对模型行为的敏锐观察(参见配套的
trusted-taster-panel-plus-few-evals--cat-wu),不是一个自动化流程。
关键引述 · 原话
Cat Wu: "We can remove a lot of prompting interventions every time the model gets smarter. And we actually do this every time we launch a model, we read through the entire system prompt and we reflect on, okay, for each of these sections, does the model really need this reminder anymore."
Lenny Rachitsky（对 Cat Wu 观点的总结，非 Cat Wu 本人所说）: "I forget who said this on the podcast, that the model will eat your harness for breakfast... as the models get smarter, it becomes simpler and simpler for it just to do the thing you want it to do."
关联卡片
- 与 `ai-coding-new-bottlenecks--mike-krieger`(同语料库,Anthropic CPO 视角)呼应:两者都指出"模型变强后,原有流程/脚手架需要持续主动瘦身",分别来自产品一线执行者和公司层面战略视角。
被这些卡引用
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2+fixed