Claude Code使用指南：Anthropic工程师日常技巧
"模型能力越强，约束条件就越应当精简。"
"Agent 运行时间越长，偏离预期时消耗的 token 就越多。"
"核心思路是把验证机制嵌入到产物本身。"
本期分享者 Arno 是 Anthropic Applied AI 团队的架构师。这场分享并非抽象的理念阐述，而是一场可实操的动手工作坊：他使用一个真实仓库，演示 Anthropic 工程师如何配置 Claude Code，如何让模型主动提问、生成 HTML 规格草案，再将验证流程嵌入 React 组件和浏览器环境。官方文档中提到的项目上下文文件、自定义命令、钩子机制和子代理（subagents），在实际演示中都指向同一个目标——让 Claude Code 成为工程系统的一个有机组成部分。这不是一篇“Claude Code 技巧汇总”，而更像一份内部工作习惯的公开复盘。
配套仓库分为三个阶段。第一阶段让 Claude 扮演需求访谈者，避免初期遗漏关键信息；第二阶段将需求转化为多个 HTML 设计方向，便于人类快速比对；第三阶段将验证框架嵌入一个迷你待办应用。三个阶段串联起来，完整覆盖了一次 Agent 开发从构思、规格、落地到验收的全流程。
模型能力越强，工作习惯越需迭代
Arno 开场首先解释了为何需要重新设计工作流程：模型能力不断增强，Agent 的运行时长和任务复杂度也随之提升。但代价同样上升。一个短任务偏离方向，最多浪费几分钟；一个长任务出错，可能消耗大量 token，并产生一堆难以追溯的中间产物。Claude Code 的高级用法，不在于记住更多命令，而在于任务启动前就规划好方向、验证回路和反馈通道。
"如果你让 Agent 运行更长时间，它在出错时会消耗大量 token。"
这也是他反复强调“改变习惯”的根本原因。过去编程时，人可以边思考边修改；在 Agent 参与后，前置规格、交互式追问和可验证产物的优先级大幅提升。团队将 Claude Code 融入实际工程，不仅是让模型修改文件，更是让它在更少人工干预的情况下，始终知道自己是否偏离了既定轨道。
这场工作坊建立在 Tarik 一周半前在旧金山的分享基础上，核心材料源自那篇名为《The Unreasonable Effectiveness of HTML files》的文章。Arno 并没有将 HTML 视为单纯的网页文件，而是将其定位为一种能让人类和 Agent 同步理解任务的中间产物。Agent 的运行周期越长，越需要在启动阶段就把“如何被检验”的规则写入材料。
不要急于撰写需求，先让 Claude 向你提问
第一层工作流聚焦于需求提取。Arno 引用了 Richard Sutton 的“苦涩教训”来阐述一个判断：模型能力越强，人类越应当克制“提前硬编码一切”的冲动。他认为，Claude 很可能比你自己更擅长从对话中提炼出真实需求。就像用户常说“看到才知道自己想要什么”，产品经理和工程师也常常无法一次性讲清楚他们想要的系统全貌。
"Claude 可能比你更擅长提取你真正想要和需要的内容。"
他现场以一个账单分摊应用（bill splitting app）为例。一个糟糕的 Prompt 是“make it better”；而一个优秀的 Prompt 会明确指定领域、目标受众和开放式问题，并授权 Claude 使用“ask user question”工具来进行需求访谈。Claude 随后会追问：这是给朋友用的，还是包含另一类用户？需求不再是一次性陈述，而变成一轮轮接近真实用户访谈的信息收集过程。
Arno 还顺手展示了几个日常设置：快速模式、自动模式和 effort 参数。他对自动模式的评价非常直接：如果你还没用，现在就该开始用。在 effort 方面，他推荐使用 X 高，也可以将 effort 拉到最大值。背后的逻辑很清晰：需求访谈和规格探索需要快速的来回交互，权限弹窗和低推理强度都会打断节奏。
这种基于提问的 Prompt 模式对产品经理和工程师都非常实用。人类无需一次性将所有边界条件说清楚，只需要告诉 Claude 领域、受众和想要探索的问题，再让它逐轮追问。在 Arno 的案例中，分摊应用从“给谁用”开始逐步收敛，然后再进入规格稿阶段。在长任务启动前，多花几轮问答，通常比事后返工更划算。
Markdown 过长时，HTML 规格稿更具产品感
第二层工作流探讨规格稿的形态。Arno 引用了同事的话：Markdown 文件是 AI 原生软件开发周期的通用语言。但他同时指出，Markdown 一旦变长就会失效。超过两百行后，人类很难认真读完，同事也难以基于它提出具体的反馈。HTML 在此处承担了新的角色：它能将更多信息压缩进一个可查看、可点击、可截屏的产物中。
"Markdown 文件是 AI 原生软件开发周期的通用语言。"
在演示中，他让 Claude 为分摊应用生成了四个 HTML 设计方向，包括粗野主义（brutalist）和东京金融科技（Tokyo fintech）等不同视觉风格。人类不再需要靠想象来理解需求文档，而是可以直接点击、比较、截屏，再将视觉反馈交回给 Claude。对于前端、产品和设计协作而言，这种规格稿比一长串文字更容易达成共识。
他还现场询问有多少人会使用截屏向 Claude 反馈，接着明确建议大家这样做。前端中常见的“有点歪”、“层级不对”、“这里太挤”等问题，很难仅靠文字描述清楚。Opus 4.7 的视觉能力比以往更强，将截屏与 HTML 规格稿一起交给 Claude，能让反馈从抽象的意见转变为可定位的修改点。
Arno 对 HTML 的定位非常清晰：将人类在规格阶段通常会做的验证工作前置到产物中。它既能被人类阅读，也能被 Agent 使用；既能表达布局和状态，也能承载后续的验证入口。Markdown 仍然有价值，但当任务涉及界面、状态和视觉反馈时，HTML 能大幅减少 Claude 的猜测成本。
验证需要从事后检查，前移到产物内部
视频中最具价值的部分是第三阶段的验证框架（Verification Framework）。Arno 特意区分了测试（test）和验证（verify）：普通测试关注代码能否通过，而验证关注产物是否能够被人类和 Agent 原生地检查。演示项目切换为一个 React 待办应用，其中包含了组件、测试夹具（fixtures）、测试库、数据发布（data emissions）、属性（attributes）和 Playwright MCP。
"让验证机制原生地存在于产物本身，这样 Agent 和人类可以共同驱动它。"
Arno 的目标非常明确：未来 Agent 将越来越多地自行运行、自行检查、自行提供证据。团队需要做的，是将产物设计为能够被 Agent 原生验证。当验证成为产物（artifact）的一部分时，Claude Code 才能从“会改代码”进化到“能证明改动有效”。
这一步的工程味非常浓。它不满足于“跑一遍测试”。Arno 要求的是在组件旁边写清楚已知状态、数据合同（data contracts）、必须保持的不变性（invariants），以及能够推动边界条件的探测脚本（probes）。当 Claude Code 接手任务时，它看到的不仅仅是源代码，还有一套能告诉它“哪里算对、哪里算错”的验证地图。
DOM 也可以成为 Agent 的数据合同
在待办应用中，组件会将 total、done、active 等状态发布到 DOM 中。Arno 现场进行添加、勾选、删除任务的操作，浏览器中的 data-verify 单元也随之变化。这样一来，Agent 无需艰难地抓取页面，也无需猜测 React 内部状态；它可以直接读取公开的 DOM 合同来执行验证。
"如果将状态发布到 DOM，就能独立于应用状态来运行验证。"
每个组件都包含模式（schemas）、测试夹具（fixtures）、已知状态（known states）和不变量（invariants）。Arno 还故意插入一个会失败的验证：3 + 4 被硬编码为不等于 10。普通的测试矩阵可能仍然通过，但验证仪表盘（Verification Dashboard）会暴露这个错误。随后，Agent 可以使用浏览器和 Playwright MCP 来查明是哪条合同出了错。
他还现场做了一个更极端的动作：删除了待办应用中的 total stats 合同。应用本身还能正常运行，但一批验证立即失败。这个场景非常典型：用户界面看起来一切正常，但 Agent 所依赖的数据合同却断裂了。将合同显式写出来，才能让 Claude Code 发现“看不见的断裂”。
更巧妙的是，Arno 演示了“测试通过但验证失败”的情形。运行 bun verify 时，测试矩阵可以通过，因为普通测试没有覆盖那条故意写错的业务逻辑；但浏览器中的验证仪表盘仍然能捕获 4 + 3 不等于 10 的错误。测试负责代码层的安全网，而验证负责产物层的可信度。
同一套验证，需要面向人类、Agent 和 CI
Arno 将验证分为三种呈现方式：人类可读的仪表盘、Agent 通过浏览器驱动的方式，以及 CI 中无头模式运行的命令行。三者围绕同一份清单（manifest）、同一批探测脚本（probes）和同一组不变量（invariants）工作。人类在页面上看到失败，Agent 也能读到；CI 可以通过 run bun verify 运行完整的验证矩阵。
"可以用人类可读的方式验证，也可以用 Agent 优先的方式验证，还可以无头模式运行。"
他强调探测脚本必须能够偏离 happy path。只验证顺利路径，Agent 很容易给出看似漂亮、实际脆弱的结果。将边界状态、错误状态、状态不一致都做成可运行的验证，Claude Code 才能在修改后自行发现问题，而不是等人肉 QA 来兜底。
这套设计也解释了为什么 Playwright MCP 在演示中如此重要。Claude 可以直接从浏览器运行验证、读取 DOM 合同、查看失败详情，再回到代码中诊断原因。人类的仪表盘和 Agent 优先的浏览器共享同一种观察方式，减少了“人类看到一套、机器看到另一套”的错位。
这也是“Agent Native”的实际含义：把清单、状态、模式和回放能力交给 Agent，而不是只让它模仿人眼到处点击。人类可以在仪表盘上点击“Run all”；Agent 可以从浏览器拿到同样的验证清单；CI 可以在命令行中运行同样的矩阵。三条路径互相对齐，排查问题时才不会分裂。团队越依赖并行的 Agent，就越需要这种统一的观察面，否则每个任务都会留下不同格式的“口头解释”。
证据也需要自动留存
验证如果只告诉你 pass 或 fail，还不够。Arno 现场演示了记录（recording）功能：验证步骤可以被录制成剪辑（clips），打包下载，上传到 S3，或者分享给同事。Claude Code 团队现在会记录大量的代码变更，尤其是前端变更，用以证明验证确实执行过。这一点很像把“我检查过了”变成机器可复现的证据包。
"你可以下载所有剪辑，或者单独下载，它们就是证明验证已运行的打包文件。"
对团队协作来说，证据包会改变代码评审的颗粒度。评审者不再需要只看差异对比和口头说明，而是可以看到 Agent 如何运行、在哪里失败、如何修复。当 Agent 开始提交越来越多的代码时，验证记录会成为团队信任它的基础设施。
Arno 说得很具体：Claude Code 团队会记录大量的代码变更，至少前端改动会纳入这样的流程。视频中可以看到每段剪辑可以单独下载，也可以打包下载。它就像一份可交付的验收材料，帮助团队在高速交付时保留可追溯性。
多投入一点规格 token，就能少返工很多轮
最后 Arno 回到一个实际问题：HTML 规格是否会消耗更多 token？他的回答偏向否定。单次生成 HTML 可能更贵，但如果规格更丰富、更易读、更容易通过截图反馈，长期来看会减少迭代轮次。他也建议使用 Opus 4.7 来承担这类视觉和规格工作，快速模式用于快速迭代规格，自动模式用于减少中途的权限打断。
"从长期来看，如果 HTML 规格足够好、足够丰富，你会减少迭代次数。"
这场工作坊的核心，其实是把 Claude Code 当作团队的工程系统来对待：先让它问清楚，再让它生成可查看的规格稿，最后让产物本身携带可验证的合同和证据。会用 Claude Code 的团队，差距会逐渐从“谁更会写 Prompt”转向“谁更会设计 Agent 可以工作的环境”。
这对产品、设计和工程共同协作的团队尤其重要。产品经理需要把模糊需求交给 Claude 追问，设计师需要把视觉方向变成可反馈的 HTML，工程师需要把可验证状态暴露给浏览器和 CI。Claude Code 介入得越深，协作的对象就不仅仅是代码文件，还包括规格、状态、证据和工作节奏。
官方文档中提到的上下文文件、命令、钩子、子代理，在这条主线中也能找到位置。上下文文件帮助 Agent 理解项目背景；命令让常见操作可复用；钩子将检查和上下文的插入时机自动化；子代理可以承担更专门的诊断和验证任务。这些能力共同构成一套工程环境，让 Claude Code 有信息可读、有入口可入、有检查可做，也有留下证据的方式。
核心总结
“How we Claude Code”的价值，在于展示 Anthropic 如何将 Claude Code 纳入工程闭环。下次让 Agent 执行长任务之前，可以先问三件事：需求是否已经被采访清楚，规格能否被人快速看懂，结果能否被 Agent 自己验证。先把这三件事补齐，再考虑规模化，别让 Agent 在黑箱中奔跑、独自猜答案。