> 来源：Useful AI Lab（实用 AI / Useful AI）— https://usefulai.cloud/insights/anthropic-how-we-use-claude-code/
> 作者：CarryChang · 最近更新：2026-07-30 · 语言：zh-CN

[实用 AI 指南](https://usefulai.cloud/) › [深度阅读](https://usefulai.cloud/insights/)

Claude
Arno
Anthropic
Verification

# Anthropic 工程师：我们日常如何使用 Claude Code

这期主讲人 Arno 是 Anthropic Applied AI 团队的架构师，他带来一场可跟做的 workshop：用一个真实 repo 演示怎样配置 Claude Code，怎样让它问问题、生成 HTML 规格稿、再把验证流程做进 React 组件和浏览器。这不是一份"小技巧"合集，更像一份内部工作习惯的公开样本。我认为这期最值钱的地方是 verification framework，也是六篇里唯一给出了具体可抄的实现细节的一篇——不是理念，是能直接搬进项目的做法。

### Agent 变强后，工作习惯也要变

Arno 开场直入：模型越来越强，Agent 可以跑更久、接更复杂的任务，代价也随之变大。短任务跑偏浪费几分钟，**长任务跑偏会烧掉大量 token 并生成一堆难以复盘的中间产物**。

> 如果你让 Agent 跑更长时间，它做错事时会烧掉很多 token。 — — Arno, Anthropic

进阶用法不在多记几个命令，而在任务开始前把方向、验证和反馈通道都布好，让 Agent 在**更少人类 touchpoint** 的情况下知道自己有没有走偏。

### 让 Claude 先采访你，再生成 HTML 规格稿

第一层工作流是需求提取。Arno 借 Sutton 的 bitter lesson 给出判断：模型能力越强，人越应抑制"提前硬编码一切"的冲动。**好 prompt 不是把需求一次写完，而是让 Claude 使用 ask user question 工具反过来采访你**。

> Claude 可能比你更擅长提取你想要什么、需要什么。 — — Arno, Anthropic

坏 prompt 是"make it better"；好 prompt 给出领域、受众、开放式问题，并明确让 Claude 提问。设置上 fast/auto mode 开启、effort 推高——权限弹窗和低推理会打断节奏。

需求成型后，Markdown 一长就失效——超过两百行难以认真读、也难以给出具体反馈。demo 里 Arno 让 Claude 为分账应用生成四个 HTML 设计方向，人直接点击、比较、截图反馈。

> Markdown 文件是 AI-native 软件开发生命周期的通用语。 — — Anthropic

前端的"稍微有点歪""层级不对"很难只靠文字表达，把截图与 HTML 规格稿一起交给 Claude，反馈就从抽象意见变成可定位的改动。

**我的看法：**「让 Claude 反过来采访你」这条我完全认同，而且我觉得它比 workshop 里给的理由更重要——不只是「Claude 可能比你更懂你要什么」，更实际的是它把「需求不清楚」这个问题从事后返工提前到了事前拦截，返工的代价永远比多问几句话贵。唯一要注意的是这依赖 Claude 主动提问的意愿，如果 effort 没调高、模式没设对，它大概率会直接开始干活而不是先问——这一点 Arno 后面提到了，但很容易被忽略。

**图解 17**：
把验证前移到产物里：Agent 自己就能知道有没有走偏
（适合：工程师向）

长任务跑偏的代价很大，所以要在**任务开始前就把方向、验证和反馈通道布好**。这条链的关键是第三步：让组件把关键状态发布到 DOM，形成一份**公开的合同**，Agent 于是能直接读取真实结果自己验证，不必抓页面、不必猜内部状态。下半部分是这套做法的核心区分——**test 问的是代码能不能过，verify 问的是产物能不能被检查**。多花的那点 token，换的是少返工。

### 验证前移到产物：DOM 合同 + 三条路径——这是全篇的核心，我完全站在 Arno 这边

视频最有价值的部分是 verification framework。Arno 区分 test 和 verify：**测试关注代码能否通过，验证关注产物能否被人和 Agent 原生检查**。在 React to-do app 里，组件把 total、done、active 发布到 DOM，Agent 直接读公开的 DOM contract 运行验证，不必 scrape 页面、不必猜内部状态。

test 和 verify 这个区分我认为讲透了一个长期被混用的概念：单测通过只证明代码逻辑符合你写的断言，不证明产物本身对不对。这也是为什么很多团队「测试全绿、上线出问题」——他们验证的是代码，没验证产物。Arno 给的解法很朴素，就是让产物自己暴露状态，这一点没有任何理论门槛，任何前端项目现在就能抄。

> 让验证原生存在于事物本身，这样 Agent 可以和人一起驱动它。 — — Arno, Anthropic

每个组件带 schema、fixtures、known states 和 invariants。Arno 故意写一条"3 + 4 不等于 10"的 invariant：普通测试能通过，**但 verification dashboard 会毫不留情把失败暴露出来**。同一套验证给三个表面用：人看的 dashboard、Agent 从浏览器驱动的方式、CI 里 headless 跑的命令，**三者围绕同一份 manifest、同一批 probes、同一组 invariants 工作**。

> 可以用人类可读的方式验证，也可以用 Agent-first 的方式验证，还可以 headless 地跑。 — — Arno, Anthropic

他强调 probes 要能推离 happy path：只验证顺利路径，Agent 很容易给出看似漂亮、实际脆弱的结果。边界、错误、不一致状态都要能运行验证。

### 证据自动留下，让多花 token 换少返工

验证只告诉 pass/fail 还不够。Arno 现场演示 recording：验证步骤可以被录成 clips，打包下载、放 S3、分享。**当 Agent 提交越来越多代码，验证记录会变成团队信任它的基础设施**。

> 你可以下载全部 clips，它们就是证明验证跑过的 bundle。 — — Arno, Anthropic

HTML spec 单次生成可能更贵，**但规格更丰富、更好读、更容易截图反馈，长期会少迭代很多轮**。会用 Claude Code 的团队，差距会从"谁更会写 prompt"转向"谁更会设计 Agent 可以工作的环境"——context files、commands、hooks、subagents 共同组成这套环境。这个判断我认同，但想补一句：这个结论对个人开发者的适用性要打折扣，「设计 Agent 环境」本身需要工程投入，团队规模够大才能把这笔投入摊薄，独立开发者更现实的策略还是先把 test/verify 这条分清楚，再谈环境设计。

#### Arno 演示了什么

- 让 Claude 先采访你，再开始写需求

- HTML 规格稿代替长文档，可看、可点、可截图

- DOM 合同：组件把状态公开，Agent 直接读取验证

- 同一套验证给人、Agent、CI 三条路径用

#### 原视频

观看 Arno 的完整 workshop 演示，了解 Anthropic 工程师如何将 Claude Code 融入工程闭环。

[▶ 观看 Workshop](https://www.youtube.com/watch?v=IlqJqcl8ONE)

#### 我的评论

- 这是六篇里唯一给出具体可抄实现的一篇，含金量最高

- test/verify 的区分讲透了「测试全绿但产物出问题」的根源

- 反过来采访你，本质是把返工成本提前拦截，性价比很高

- 「设计 Agent 环境」的投入门槛偏高，独立开发者优先级应靠后

## 继续阅读

[如何从零构建你自己的大语言模型：GPT 和 Claude 背后的 5 阶段流水线 → 所有前沿模型都由同样的五个阶段构建：数据 → 预训练 → 监督微调 → 奖励建模 → 强化学习。学会这套骨架，你就不会再把模型当作魔法。](https://usefulai.cloud/insights/how-llms-are-built/)
[Skill 不是更长的 Prompt——如何让 AI 按流程稳定完成复杂任务 → 很多人第一次写 Skill 会写成一个更长的 Prompt，看起来完整但并不好用。Skill 真正的价值是让 Agent 自动识别场景、加载流程、稳定完成任务。](https://usefulai.cloud/insights/claude-skill-not-longer-prompt/)
[深度阅读 → 6 篇 AI 长文的完整中文解读：Claude Code、Skill、Agent、大模型原理。](https://usefulai.cloud/insights/)