Cat Wu
署名于 AI 与新工作方式
超前原型策略Prototype Ahead Of Model Capability
要不要现在就投入做一个"当前模型还做不太好"的功能,团队常常因为"准确率不够"而搁置。这条经验提出一个具体做法:先把produit原型搭起来放着,把"模型能力是否够格"当作可以随新模型发布反复重新测试的变量,而不是一次性判死刑的理由。
具产品品味的工程师招聘Hire Engineers With Product Taste
"以后还需要 PM 吗?工程师直接就能把东西造出来"是行业里反复出现的疑问。这个判断给出 Claude Code 团队的具体答案:与其纠结"PM 还是工程师"哪个角色更该增加,不如重新定位真正稀缺的能力是什么,并据此调整招聘策略。
模型脚手架主动弃用机制Harness Deprecation As Model Improves
团队常常给模型加各种"脚手架"(scaffolding)来弥补它当前版本做不到的事,但很少有团队系统性地在模型变强之后主动把这些脚手架拆掉,导致产品越堆越复杂、系统提示词越写越长。这个打法给出一套具体的"该拆就拆"的维护习惯。
品鉴团与少样本评估法Trusted Taster Panel Plus Few Evals
新模型发布节奏极快(Anthropic 内部几乎每隔几个月就有一次能力跃升),团队需要快速判断"这个新模型到底哪里变好了、哪里还有问题",但海量使用数据本身很难第一时间提炼出洞察。这套打法给出一个低成本、可复用的快速评估组合拳。
使命裁决机制Mission As Tiebreaker
公司规模变大后,各产品线/团队之间不可避免会出现资源和优先级冲突,常见解法是层层升级(escalate)给更高层裁决,速度慢且容易产生政治内耗。这个模型说明如何用"统一使命"本身作为裁决标准,让冲突能被快速、且让各方都心服口服地解决。
自动化 100% 阈值Automation 100 Percent Threshold
很多人用 Claude Code/Cowork 之类的工具搭出一个自动化,跑到 90-95% 的成功率就停下了,结果这个自动化很快被弃用、没有真正省下时间。这条反直觉的结论解释了为什么"差不多能用"的自动化其实价值有限,以及该往哪个方向再多投入一步。
AI 原生交付速度AI Native Shipping Velocity
AI 把功能开发周期从 6 个月压缩到 1 个月、1 周甚至 1 天，但多数团队的流程仍是为"代码昂贵"的时代设计的（多季度路线图、跨团队对齐）。这套打法回答：组织如何把发布节奏提到与 AI 开发速度匹配。
框架、方法、洞察本身属于 Cat Wu。卡片是用中文重新组织的转述，仅保留少量带署名的短引述。关于与出处 →