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 自己就能知道有没有走偏 工程师向
让 Claude 先采访需求、生成 HTML 规格稿、通过 DOM 合同自我验证并留下证据的工作流 工作流分五步：让 Claude 用提问工具反过来采访你确认需求；生成可点击的 HTML 规格稿代替长文档；组件把关键状态发布到 DOM 形成公开合同；Agent 直接读 DOM 运行验证而不必抓取页面或猜内部状态；验证过程被录成证据留档。测试关注代码能否通过，验证关注产物能否被人和 Agent 直接检查。 ① 需求 先让它采访你 ask user question ② 规格 HTML 规格稿 可点，不是长文档 ③ 产物 DOM 合同 状态公开可读 ④ 验证 Agent 自己跑 不用猜内部状态 ⑤ 证据 录下来 可复盘 test：代码能不能过？ 单测、lint 通过，但产物可能根本不对 verify：产物能不能被检查？ 人和 Agent 都能原生看到真实结果 验证探针要能推离顺利路径 —— 只测 happy path，会得到看起来漂亮、实际脆弱的结果。
长任务跑偏的代价很大，所以要在任务开始前就把方向、验证和反馈通道布好。这条链的关键是第三步：让组件把关键状态发布到 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 这条分清楚，再谈环境设计。