Claude Code 团队的人自己怎么用 Claude Code？第一条建议就把我钉住了

今天刷到 Rohan Paul 转的一条推，内容是 Claude Code 团队的 Thariq 在一个视频里分享的十条建议，讲怎么把 Claude Code 的潜力榨干。

这种「N 条最佳实践」的帖子我平时是直接划走的，AI 圈每天能产出八百条使用技巧，大部分是车轱辘话来回倒。但这条我从头看到了尾，因为第一条就把我钉住了。

他说，别再盯着 Claude 有没有把活干对，去盯它是不是在干对的活。

原话是 shift from verifying whether Claude did the work right to verifying whether Claude is doing the right work。这两句英文长得像双胞胎，中间差的却不是一个介词，是整个工作方式。

我自己的日常工作就是给大模型搭脚手架，就是让 agent 真正能干活的那层工程，工具怎么接、上下文怎么喂、跑挂了怎么重试。天天看模型在生产环境里跑，我对一件事有很深的体感，模型把代码写错，这种失败是便宜的，测试会红，类型检查会骂，你总能抓到它。真正贵的失败是它花四十分钟优雅地实现了一个你根本不想要的东西。代码本身挑不出毛病，每个函数都干净，注释都齐，但方向从第一分钟就歪了。

测试全绿，方向全错。这种活你 review 的时候最难受，因为你挑不出错，只能整个推翻。

所以 Thariq 这十条建议，我越看越觉得它们其实不是十条，是一条。剩下九条全是在回答同一个问题，怎么保证 Claude 在干对的活。

先看前面几条，它们全都发生在写代码之前。

第二条，把 Claude 当思考伙伴，一开始就给它完整的上下文，别上来就让它写实现。这条听着像废话，但你回想一下自己上一次开 Claude Code 是怎么开的。大概率是丢一句「帮我把这个功能加上」，然后就开始等结果了。我们对 AI 的默认姿势还是当外包，需求一甩，验收时再说。Thariq 的意思是，你得把它当成那个坐你旁边、可以一起对着白板比划的同事。

第三条更有意思，先写一个很小的 spec，就是一份粗糙的规格文档，几行就够，然后让 Claude 反过来采访你。让它问你实现细节，你答，答完再定稿。

这个反转有点子牛逼。我们的惯性是人提问 AI 回答，他直接倒过来，让 AI 当记者你当受访者。你脑子里那些「我以为很明显所以没说」的隐含假设，恰恰是被提问揪出来的。人类结对编程里最值钱的环节从来不是一起敲代码，是那句「等等，你这里为什么这么设计」。现在这个环节可以跟模型做了。

第四条，让 Claude 对一个想法探索多个方向，直接生成几版 HTML 原型给你挑，在写任何正式代码之前先把方向偏差暴露出来。Claude Code 团队自己内部就特别爱用 HTML 当沟通媒介，他们博客里专门写过这事，与其用文字描述「大概是这种感觉的界面」，不如三分钟出三版能点的页面，你指着其中一版说就要这个。文字会骗人，原型不会。

到这里你应该看出味道了，前四条全是在花「写代码之前」的时间。这跟我们的直觉拧着来。用 AI 不就是图快吗，怎么越用越像在开需求评审会。

但你再想一层就通了。模型生成代码的速度已经快到近乎免费，瓶颈早就不在「写」了，在「写对方向」。方向对了，几小时的活模型自己能跑完。方向错了，它跑得越快，你删得越多。

第五条是我最喜欢的一条，给丰富的上下文，而不是死板的约束。Thariq 举的例子特别妙，告诉 Claude 这个功能是个实验，大概率一个月后就删。

就这么一句话，模型的整个实现策略都会变。它不会去精心设计抽象层，不会把配置抽成单独模块，不会写那种「为未来扩展性着想」的代码，因为它知道这玩意活不过一个月，怎么删着方便怎么来。

你品一下这和「不要过度设计」这条指令的区别。后者是个禁令，模型只知道不能做什么。前者是个事实，模型自己能推出该做什么。把 why 给够，how 让它自己想，这比把 how 写成军规有效得多。坦率讲，这条对带人也成立，只是我们对人都经常做不到，张口就是规矩，懒得解释背景。

第六条顺着来，方向确定之后，给明确的目标和验证方法。注意顺序，先有前面那些对齐，再谈目标。目标本身还要带着「怎么算完成」一起给，光说做完，不说怎么验证做完，模型和人都会在百分之八十的地方停下来宣布胜利。

然后是工具层的三条。

第七条，用 Claude Code 新出的 /goal 命令。这个命令我之前写文章聊过，它给会话立一个显式的目标，模型会持续工作直到目标真正达成，而不是干到一半礼貌性地停下来问你「还需要我继续吗」。

第八条，用 Workflows 让模型并行处理任务、自己验证自己的输出，最后交一份报告，说清楚实现了什么、哪里跟原计划有出入。

第九条是把七和八拼起来的一句组合指令，大意是，设一个目标完整实现这份 spec，然后用一个 workflow 验证计划的每一部分，最后报告实现了什么、有没有偏差。

这三条放在一起看，其实是把「检查它是不是在干对的活」做成了流程。目标是锚，workflow 是自检，报告是对账。你的角色从盯着屏幕看它敲代码，变成看一份「计划 vs 实际」的 diff。哪里偏了，一眼就能看见。

我是真的觉得这个「报告偏差」的设计被低估了。模型自己说「这里我没按计划来，因为 X」，比你事后从两千行 diff 里考古出它没按计划来，成本差了两个数量级。

最后一条，第十条，对 Claude Fable 5 要更有野心，把那些以前默认 LLM 干不了的任务直接丢给它。

Fable 5 是昨天刚发的，能连续跑好几个小时，自己测试自己，产出质量经常比手搓还高。Thariq 在视频里顺手扔了个炸弹，说这整条视频就是他用 Fable 5 剪的。

好家伙。Claude Code 团队的人，分享 Claude Code 使用技巧的视频，是用 Claude 剪的。这个套娃行为本身比十条建议加起来还有说服力。

剪视频这个活，时间轴、素材、节奏、转场，跟写代码八竿子打不着，以前你跟我说让一个编码 agent 干这个，我只会觉得是营销话术。但「以前默认干不了」这个清单，最近更新得越来越快了，快到我都不太敢用三个月前的经验下判断。

十条过完了。我说说自己的感受。

这十条没有一条在教你写 prompt。没有什么魔法咒语，没有「加上这句话效果提升 300%」的玄学。它们全在讲同一件事，把你和模型之间的信息差填平，然后把验证方式定义清楚，剩下的交给它跑。

这其实跟 Anthropic 自己更早那篇 Claude Code 最佳实践一脉相承，工程师们摸索出来的方向出奇一致，少琢磨怎么指挥，多琢磨怎么对齐。

说真的，我们这行用了几十年的协作结构正在被换掉。以前是人定方向、人写代码、人验收。后来变成人定方向、AI 写代码、人验收，大家觉得这就是终态了。现在看，验收的一大半也可以交出去，模型自己测、自己对账，人只看偏差报告。剩给人的那部分越来越纯粹，就是定方向，以及为方向负责。

写公众号的人最怕这种时刻，聊着聊着把自己聊到风口浪尖上。但我还是得诚实说，定方向这个活，比写代码难，难得多。它要求你真的想清楚自己要什么，而我们很多时候是靠「先写写看」来逃避想清楚这件事的。以后这个逃生通道，可能要收费了。

号子叫小岛，那就用个航海的比方收尾。以前我们的精力都花在划桨上，谁划得快谁厉害。现在桨是电动的了，马力大得吓人，于是真正的问题浮出来了，罗盘在谁手里，针摆没摆正。

桨越快，罗盘越贵。

Thariq 那条视频的原帖在这里，十条建议的完整英文版都在，建议收藏慢慢看。「让 Claude 先采访我」这条我还没试过，但想想就觉得会很好玩，打算今天下午就拿手头的需求试一把，效果如何，过几天写出来跟你汇报。