# Claude Code 上线一周年：演进与方法论回顾

- 来源：meng shao (@shao__meng)
- 发布时间：2026-06-09 08:50
- AIHOT 分数：68
- AIHOT 链接：https://aihot.virxact.com/items/cmq5y4g3h03exsl5itr5ivn4z
- 原文链接：https://x.com/shao__meng/status/2064148065771229198

## AI 摘要

Claude Code 负责人Boris Cherny与Cat Wu回顾一周年核心方法论：每次Claude犯错写入CLAUDE.md或Skill持久化规则而非口头纠正；Verification指agent亲自跑起来验证（如启动模拟器、computer use测试）。Auto Mode取代Plan Mode，用独立分类模型筛权限风险而非人工审批。Routines实现自动化运维（如监听GitHub bug自动提PR）。Context Minimalism主张最小system prompt和工具集。团队预判未来agent运行更久、成百上千并行，产品形态将巨变。

## 正文

Claude Code 上线一周年：演进与方法论回顾

来自 Claude Code 负责人 Boris Cherny 与产品负责人 Cat Wu，从一年前首次内部 demo 只有两个 Slack 点赞，到现在绝对主流 Coding Agent，这一年 Claude Code 到底做对了什么？
https://www.youtube.com/watch?v=Hth_tLaC2j8

# 两条底层方法论

1. 错误即资产：写入规则，而非口头纠正
Boris 的核心习惯：每次 Claude 犯错，不直接说「下次别这样」，而是写入 CLAUDE.md、Skill 或类似持久化机制。

逻辑是：口头纠正只影响当前会话；规则沉淀后，agent 可长期、反复、自主执行。这是「让 agent 几乎无限运行」的前提。

2. Verification（验证）≠ 单元测试
多数人把 verification 理解成 lint、类型检查、单元测试--这些早已自动化，不是 agent 时代的重点。

真正的 verification 是：agent 能否亲自「跑起来」验证结果。
· 早期案例：让 Opus 4 写完功能后，在 bash 里启动另一个 Claude CLI 自测。
· 现在：iOS/Android 模拟器、桌面应用的 computer use 点击测试已成常态。
· Cat 的实践：桌面开发 Skill 教 Claude 启动本地 app、点 UI、测边界；若 staging 异常，先读 Slack 判断是否环境问题；修完后更新 Skill，形成闭环。

要点：验证能力往往需要针对具体产品定制，无法一键通用。

# Loops/Routines：从「人用工具」到「系统替人值守」

Routines 被定位为 Agent SDK 之后第一个「显而易见」的规模化应用。

典型案例：
· 某工程师为 Voice Mode 设 routine：监听所有相关 GitHub issue/bug → 自动提 PR → 通知本人。
· 另一 routine：5 小时未响应的 bug 自动修复，易验证的直接 merge。
· Cat 遇到自己功能的 edge case bug，还没动手，Claude 提示「另一个 Claude 已修好」。

组织影响：
· 代码评审、CI 修复、rebase 等琐事，团队成员已很久没亲手做。
· 多个人的 Claude 并行工作，形成「隐形协作网」。

重点：把工程运维流程产品化、自动化。

# Auto Mode：取代 Plan Mode 的默认选择

Boris 明确表示：Plan Mode 已基本不用，全面切到 Auto Mode。

原因：
· Opus 4 ~ 4.5 仍需显式规划；从 4.6、尤其 4.7 起，模型已能自主规划。
· Auto Mode 的价值是：启动 agent 后即可转向下一个任务，无需盯屏点确认。

安全设计的反直觉结论：
人工逐条审批 99% 都会点「是」的权限提示，反而更危险；Auto Mode 用独立分类模型筛风险，人只关注被拦截的少数异常，整体更安全。

上线前流程：
· 收集数千条 agent 轨迹 + 权限请求，训练分类器；
· 红队 prompt injection、渗透测试；
· 建 eval，确保已知攻击全部被拒；
· 内部团队继续攻击、迭代。

Boris 认为：「把 prompt 路由给另一个模型做安全检查」--他最初认为行不通，实测却效果很好。这反映基于大模型构建产品时，许多旧工程直觉需要重写。

# 组织变革：AI 必须成为流程中心

Boris 引用 90 年代 HBR 案例：PC 普及初期生产力未显现，因为企业只是把电脑「放在旁边」，流程仍是纸笔+文件柜。

真正释放价值，需要把电脑置于业务流程中心，淘汰旧媒介。

类比到 AI：
· Anthropic onboarding 不问人，问 Claude；
· 提问、写代码、CR、安全审查、填表，均经 Claude/Co-Work；
· 领先企业正在把 AI 放到同样位置。

与 PC 转型需 10-15 年不同，AI 转型更快，因为：
· 工作已高度数字化；
· Claude 能操作电脑、写代码、跑代码。

角色融合：
· 产品、设计、DevRel 都在写代码、提 PR；
· 工程师端到端负责：构思 → 实现 → 对接法务/市场/安全 → 发布；
· 设计、PM、财务、数据科学等「邻接角色」广泛采用 Claude Code。
· 未来不是「人人 PM」或「人人工程师」，而是两者合一--好奇心、产品品味、端到端 ownership 成为关键能力。

# 多 Agent 时代的工具形态

从「6 个终端 tab + 6 份 git checkout」→ 单 tab + Agent View + Desktop App（自动 worktree）。

意外变化：Boris 约一半工程工作已在手机上完成--Remote Control、Voice Mode，边走边看 agent，现场聊出新想法即开 agent 实现，无需回电脑。

这说明：工程师的主战场正从 IDE 转向 agent 编排界面。

# Context Minimalism（上下文极简主义）

技术话语的演进轨迹：
· Sonnet 3.5 时代 → Prompt Engineering
· Opus 4 时代 → Context Engineering
· 当前模型 → Context Minimalism

原则：
· 最小 system prompt、最少工具集；
· 只给模型「拉取上下文的能力」，不塞满上下文；
· 过多上下文 ≈ 微观管理，限制模型找更优路径；
· Harness 本身也在变瘦，把 token 空间留给用户意图。

这与一年前「精心构造 mega prompt」的做法形成鲜明对比。

# 对未来的判断

团队预判：
· Agent 运行更久、更自主；
· 很少只跑 1 个 agent，常见是数十、数百、数千；
· 一年后的产品形态很可能与今天完全不同；
· 创新将更多来自用户社区，而非官方闭门设计。

值得肯定的洞见：
· Verification 定义准确，切中 agent 工程要害；
· 「错误写入规则」是可复制的工程纪律；
· Auto Mode 安全思路有实证支撑，不是空喊；
· 组织变革类比有历史参照，不过于浪漫化。

需保持审慎之处：
· 发言者身处 Anthropic 内部，描述的是理想态实践，外部企业落地节奏未必相同；
· 「财务用 Claude Code 做预测」等案例缺少可验证细节；
· Routines 全自动 merge 依赖「易验证」边界，复杂系统风险需自行评估；
· 「角色融合」「手机写代码」更像前沿团队样本，非行业普遍现状。

### 引用推文

> ClaudeDevs：Claude Code's first demo got two Slack reactions. One year after GA, @bcherny and @_catwu look back: verification best practices, why we built auto mode, routin...