如果你最近几个月一直泡在开发者社区，多半听过同一种体感：工具还是那些工具，但从大约 2024 年 11 月底起，许多人说「不对劲了」——像给日常工作加了助推器，又像被新节奏拽着走。对 Claude Code 的创造者 Boris Cherny 来说，这种「不对劲」更早：2024 年 9 月前后，他曾连续高强度投入，甚至用他自己的话说，隐约觉得「可能成了」，兴奋与不确定叠在一起。
我好奇的是：为什么最后站住脚的形态，竟然是终端（CLI）？ 它本该是成本最低的临时壳，却在内部与外部都长成了长期主战场之一。下面正文会逐一把这次对谈里反复出现的四条主线先铺开——产品开发哲学、技术演进、对人的建议、未来展望。
读前三个锚点
- 为「六个月后的模型」下注：不为当下模型的短板打补丁打到死，而是盯 frontier——今天勉强、明天会强的能力带。
- latent demand（隐性需求）：产品功能尽量从用户已经在做的行为里长出来，而不是硬发明新仪式。
- 脚手架（scaffolding）与苦涩的教训（The Bitter Lesson）：围绕模型堆工程，短期可能换来 10%～20% 的增益；模型一换代，这些胶水代码往往变成技术债。墙上裱文章不是玄学，是提醒：别和模型对赌。
一、产品开发哲学：超前构建、隐性需求、少即是多
1.1 「不要为今天的模型构建」到底在说什么？
Boris 反复提到 Anthropic 内部的一种产品直觉：别只给「今天的模型」做完美适配，要想「六个月后的模型」会在哪里变强。原因很简单：能力曲线不是线性微调，而是阶段性跃迁；你今天为笨点打的补丁，可能在下一版模型里被「原生能力」直接覆盖。
笔者理解，这句话不是让团队放弃当下可用性，而是提醒优先级：别把产品命运绑死在临时补偿逻辑上。他也提到与 The Bitter Lesson（Rich Sutton）同方向的判断——更通用的方法往往赢过堆特例；工程上的 scaffolding 要假设会过期。
1.2 终端为什么「反常识」地赢了？
对谈里一个很抓人的矛盾是：终端本来像起点（先跑起来再说），最后却像终点（很多人就停在这里）。起步时只有一个人、要最快验证 API 与 tool use，CLI 是最低成本路径；内部 dogfooding 两天后，对面同事已经在用它写代码——「原型还没准备好」与「已经好用」同时成立。
这类路径，和 Boris 说的 latent demand 合拍：人们不会突然换一套完全不同的工作流；你若把增强叠在他们本来就在做的事上，更容易起势。另一个类比是对 TypeScript 的回顾：不是把 JavaScript 程序员改成另一套「正确写法」，而是在现实写法旁边补类型系统；Claude Code 也在谈「像 Unix 工具一样可 pipe、可组合」，但不为炫技而增加门槛。
1.3 CLAUDE.md：从自发行为到产品机制
团队观察到：工程师开始写 Markdown 给模型做「项目说明」——这就是 CLAUDE.md 的来源。Boris 自己的 CLAUDE.md 极简到只有两行（与 PR 合并、内部协作节奏相关），更多共识放在仓库共享的 CLAUDE.md 里，靠持续 PR 维护。
当文件膨胀到几千 token，他的建议很「反直觉」：删掉重来。与其堆满防御性指令，不如用最少指令把模型拉回正轨；模型变强后，你反而可能写得更少。
二、技术演进：从 hack 到工具、从啰嗦到可配置
2.1 起源：不是「被指派做 CLI」，而是把能力吃满
叙事里有一条很清晰的线：Anthropic 早押 编程作为关键能力路径之一；Labs 时期 Claude Code、MCP、桌面端 在 Boris 看来是串起来的。没人命令他「做 CLI」，而是出现 product overhang 感：模型能力可能已经够格，但产品形态还没把它「吃干榨净」。
于是路径是：最小终端聊天 → 调用 API → 把文档里的 tool-use 示例搬到 TypeScript → 试 bash、读文件、再试更野的脚本——直到出现那种「模型就是想用工具」的冲击。
2.2 Tool use、sub-agents、plan mode：把「先想清楚」写进默认
- Tool use：对谈强调模型「想用工具」的倾向；工程上则是把工具当严肃接口，观察模型真实调用路径，而不是把它关进「只许走固定 API」的盒子里。
- Sub-agents / 递归：口述里用「mama Claude / 子代理」这类比喻描述并行与分工；更偏架构想象，不是让读者当规格书背。
- Plan mode：来自用户反复说「先规划、先别写代码」。Boris 也提到实现可以很朴素——本质是把『先别写代码』写进约束；同时他又认为 plan mode 的生命周期可能有限（模型会更稳、更自动）。
- 重要澄清：对话里有一句「也许一个月后 plan mode 都不需要」更接近现场推演/玩笑，不是产品路线图承诺；读者别把它当成截止日期。
2.3 输出要详细还是摘要？——从内部「起义」到 verbose mode
团队曾尝试隐藏 bash 输出只给总结，结果内部强烈反对：要看 bash——因为场景差异很大（git 输出 vs. Kubernetes 细节）。后来对 file read/search 做摘要式展示；社区又有声音要细节，于是加 verbose mode（/config）。这条线很「产品」：默认随模型能力变，用户选择权要保留。
2.4 重写与迭代：代码像快消品
Boris 提到 Claude Code 自身频繁 unship 工具、持续重写；口述里甚至有「六个月前代码几乎不剩」「很大比例是最近几个月写的」这类判断——这是内部工程文化的主观描述，不是可审计的财务指标。对读者而言，更有用的 takeaway 是：假设脚手架会过期，而不是把任何一版辅助层当成终局架构。
三、对工程师与创始人：心态、招聘、协作方式
3.1 beginner mindset + 第一性原理
模型变强时，「经验」会快速贬值：资深工程师被奖励的强观点，可能变成阻力。Boris 更强调：能承认自己错过、能改模型——面试里会问「你什么时候错了」。
3.2 招聘：transcript 作为材料
对谈里提到：可以用与 Claude Code / Codex 协作的 transcript 观察——是否看日志、能否在跑偏时拉回、是否补测试、是否具备系统性。它不是替代传统面试，而是多一个可观测维度。
3.3 「双峰」人才与通才
他观察团队里高效工程师的分布：一极是工具链/运行时极深的专家；另一极是跨产品、基建、设计、用研、业务的通才。例子包括：先给工具链补「可测试工具」的能力，再让模型去写工具本身——跳出盒子比堆代码行数更关键。
3.4 生产力叙事：听个响，别当审计数字
对谈里出现 Steve Yegge 的「1000x」、以及内部 PR / commits 等粗颗粒统计——人均产出大幅上涨这类说法。笔者建议：把它当情绪与方向的旁证，而不是可横向对比的绝对指标；不同公司、不同代码库，PR 含义差很大。
四、未来展望：形态扩散、协作拓扑、安全与边界
4.1 从 CLI 到多 form factor
Boris 也承认：团队一直在试 web、桌面 app、移动端 code tab、Slack、GitHub、IDE 扩展——想找到「下一个形态」。他对 CLI 寿命的预测多次错，所以更谨慎：CLI 是主线叙事之一条，不是排他答案。
4.2 Co-work：非技术用户的 GUI 外壳
对谈描述 co-work 更像 Claude Code 的 GUI wrapper（同一 agent 内核），为非技术用户补 VM、权限、删除保护 等。这里同样要强调：产品叙述来自访谈，具体能力以官方文档为准。
4.3 Agent topologies（智能体拓扑）与 Teams
关键词包括 uncorrelated context windows（多路上下文互不污染）、test-time compute（堆上下文与算力换能力）、以及 Claude Teams 作为协作承载。对 DevTool 创始人，他的建议句式是：先想模型想做什么动作，再让它更容易做到——同时满足人类用户与模型。
4.4 更激进的预测：把「上限」当思想实验
对谈里还有 编程被「解决」、软件工程师头衔淡化、PM/设计/finance 也写代码 等长期判断，以及 ASL4 / 滥用风险 等安全框架下的提醒。笔者态度是：这是沿趋势外推，不是既定事实；涉及安全与滥用的段落，本文只保留理念级概括，不做任何可执行细节展开。
五、批判性留白（笔者必读）
- 单方信源：优势是第一手产品史；劣势是成功叙事会天然更亮。
- 数字：内部 PR 涨幅、第三方占比、外部引用（如 Mercury/SemiAnalysis）——请回原文与出处。
- 时间线：口述里的月份、版本（如 Opus 4.5 等）以当时对谈为准；产品迭代快，读者以官方文档为准。
参考文献与延伸阅读
- 对谈视频：www.youtube.com/watch?v=PQU…
- Claude Code（产品页）：www.anthropic.com/claude-code
- Claude Code Docs（概览）：docs.anthropic.com/en/docs/cla…
- Rich Sutton，The Bitter Lesson：www.incompleteideas.net/IncIdeas/Bi…
