紧人头松 Token 预算

两个方向相反的资源原则：

1. 人手刻意少配（under-fund / under-resource）

• 项目只放一个工程师。人少 + 想快点交付的内在动机，会迫使人们 "Claude-ify"——把大量工作自动化交给 Claude
• 人配多了反而降低 AI 杠杆：没有压力去自动化
• Claude Code 自己就是例证：头几个月只有 Boris 一个人，"唯一的优势就是速度"
• 配套原则："今天能做的事就今天做"——对速度的追求会自然导向让 Claude 做更多

2. Token 刻意多给（不要过早优化成本）

• Boris 给 CTO 们的标准建议：开始时不要优化、不要砍成本，给工程师尽可能多的 token
• 逻辑：宽松的 token 让人敢试"本来觉得太疯狂"的想法 → 某个想法跑通并需要规模化时，才是优化时点（此时再考虑降级到 Haiku/Sonnet 等）
• 成本结构支撑：个人实验期的 token 花费相对业务其他成本很低，真正的大账单只在规模化后出现——而那时你已经验证了价值
• 现状参照：Anthropic 有工程师每月消耗数十万美元 token；"无限 token"开始成为一些公司的招聘福利

效果证据：Anthropic 一年内工程团队约 4 倍扩张的同时，人均 PR 产出提升 200%。对照组：Boris 曾在 Meta 负责全公司代码质量，数百名工程师干一年，效率提升只有几个百分点。