给Claude Code交代目标而非任务：高度、深度、广度三个维度

用同样的前沿AI模型和同样的工具，不同的人可能得到截然不同的结果。顶尖工程师从相同工具中获得的价值可能是普通用户的10到100倍，而差距似乎来自雄心，也就是你愿意把多大的工作交给模型。Anthropic一位负责Claude的工程主管在10月13日发表的一篇文章中，把这种雄心分为四个维度：速度、高度、深度和广度。本文介绍后三个维度，以及如何把它们用在Claude Code和其他AI智能体上。所谓AI智能体，是指能使用工具、自主完成多步骤工作的AI系统。

单纯的代码生成已拉不开差距

Anthropic自己的招聘记录显示了期望变化之快。2024年，Anthropic技术岗位招聘经理的评估记录中，约5%提到了候选人使用AI工具的经历，非技术岗位约为7%。到2026年，这两个比例分别增长到大约3倍和4倍。让Claude写一个独立功能如今只是基本要求，随着基础代码生产越来越便宜，止步于此的工程师可能会落后。

四个维度如下：

速度只是入门，因此本文只讨论另外三个维度。

高度：交出结果，而不是步骤

提高高度，就是让指令沿着阶梯向上移动：从按部就班的任务，到你想要的结果，再到结果背后的目标。逐步列出操作的提示词，也就是你给模型的指令，会把结果限制在你自己的技术知识范围内。给出目标，模型才有余地自行推理出更好的架构和方案。

以数据库性能问题为例，三个层次如下：

有了结果层次的提示词，Claude可以先判断索引（一种加快数据库读取的查找结构）是否真的是正确的解法。前面提到的Anthropic工程主管也走过同样的路。大约20个月前，这位主管会让Claude修复个别崩溃，之后逐级提升，直到指令简化为一句话：让应用保持零崩溃。要在这个高度上工作，需要崩溃日志记录，以及能在Windows、macOS和Linux上复现缺陷的环境。

先把工具交给智能体

在设定零崩溃这样的目标之前，先直接问智能体：要取得成功，需要哪些工具、凭据和环境访问权限。一种实用的做法是为零崩溃目标建立一个专用的Slack频道：智能体在这里接收目标，被问到需要哪些设置和权限，并每12小时自主运行一次。它会检查代码仓库和依赖项，还可能申请资源，例如一个专供沙箱实验、设有支出上限的独立AWS账号。这个频道应当双向可用，这样智能体在需要新权限时可以提醒相关人员。

智能体很少会主动索要缺少的工具，所以准备工作必须事先做好。工具优先的环境包括：

• 错误日志和分析事件的访问权限
• Stripe等业务系统的只读权限
• 测试设备和有效的用户登录账号
• 创建沙箱测试账号的能力

在授予智能体创建基础设施的广泛权限之前，请先为沙箱设定明确的成本上限和安全边界。

不再充当中间人

在人工流程中，一个人要逐条阅读客服工单，把它改写成给Claude Code的提示词，测试结果，再来回沟通好几轮。这个人只是在传话，而传话本身就成了瓶颈。

替代方案是一个自主的分诊循环。通过MCP服务器把客服收件箱接入智能体（MCP即模型上下文协议，用于把AI模型连接到外部工具和数据），再接入Sentry的实时错误日志。智能体会把每份新报告与对应的崩溃记录相匹配，并尝试在虚拟环境中复现缺陷。如果无法复现，它会直接询问用户，例如用的是哪款浏览器、快捷键是怎么设置的。在一个案例中，某款应用的一位客户用日语反映了快捷键问题。智能体租用了一台macOS机器尝试复现，并起草了一条追问，确认用户说的“key”是指键盘快捷键还是API密钥。

▲ 复现客户所报缺陷的智能体

用会提问的智能体取代仪表板

把分析服务通过MCP服务器接入智能体后，就能随时轻松生成整合多项数据的仪表板。但仪表板的意义在于回答业务问题，所以不如直接把目标交给智能体：

我希望客户更满意、收入更多。每周想出对实现这一点最重要的10个问题，给出答案，并把结果整理成带图表的报告。

接到这项任务的智能体发现，从首次访问到购买的时间中位数约为4分钟，这是冲动消费的迹象。它还发现，把宣传视频完整看完的人反而更不容易购买：视频留存率越高，收入越低。

把指标交给智能体，再瞄准系统

下一步是不再每次出问题时手动启动智能体，而是让智能体负责一组业务指标，例如收入、注册量、退款、流失和应用错误。它每天或每隔几天检查一次，只在发现异常时通知相关人员。

最高的高度是软件工厂，也就是产出软件的系统本身，而不是某个单独的功能。瞄准系统的智能体无需持续监督，就能在多个应用中开发功能、修复缺陷、运行工程工作流；修正一个底层模式，修复就会扩散到所有依赖它的应用和界面。在一个GitHub代码仓库中，机器人智能体全天候地发现问题、提交拉取请求（即代码变更提案）、运行验证并合并修复。日常任务和缺陷可以交给智能体，但规模很大、至关重要的功能似乎仍需要人亲自把关。

深度：要专家的方法，不要专家的腔调

深度是指以该领域最优秀专业人士的标准完成一项任务。让模型“像专家一样做”，大多只会改变它的说话方式：它开始提到p值或同期群留存率，方法却一成不变。真正的深度来自让它使用真实的数据库、统计建模和回归分析工具，而不是随手做的Markdown表格和猜测。

以一个加载需要10秒的应用为例。只是要求让它更快，往往得到泛泛的建议，比如把加载推迟到需要时再进行的懒加载，或者React的useMemo。更好的做法是让Claude像性能工程师那样，从性能剖析追踪入手，也就是显示程序各部分把时间花在哪里的计时记录。随后它会逐一检查路由、身份验证、渲染和数据库查询，找出真正的瓶颈，比如耗时很长的数据库查询。

目标同样重要。设定看似不合理的目标，比如在5秒就可以接受的情况下要求200毫秒；当智能体起初说目标不可能实现时，继续施压。这种压力可能促使模型越过表面修补，进入结构性的优化。

文章还提供了一个四步元提示词，即把普通提示词改写成严谨规格说明的提示词。它要求模型：

1. 指出顶尖专家会依靠、而你的提示词遗漏了的东西
2. 确定作为工作依据的原始资料
3. 明确专家会使用的工具
4. 定义能检验结果的客观验证方式

广度：把名词改写成动词

广度是指能察觉到一个完全不同的职业已经解决了你眼前的问题。专业人士往往看不到这种关联，因此建议把任务的核心名词改写成动词短语，说明人们需要做什么以及为什么。“一份演示文稿”就变成了“让忙碌的人相信一个因果故事，从而在不确定的情况下于30分钟内作出决定”。这样一转换，记者、编辑和分析师的方法就都可以借用了。如果不确定哪些领域适用，可以让Claude就这个问题采访你，并找出面临相同结构问题的职业。

把错误提示当作客服工作

应用到HTTP 500（内部服务器错误）页面上，“错误信息”这个名词就变成了“帮助一位困惑的人不必联系任何人，自己解决问题”。这正是客服人员的工作。Claude分析了六个月的客服工单，并按出现频率对错误进行分组。登录、上传、支付和导出这四类错误约占全部工单的61%。对于因文件大小而上传失败的情况，不再显示“请稍后重试”这样的笼统提示，而是清楚告知这个6GB的文件超出了套餐5GB的上限，并在页面内提供压缩文件或升级套餐的选项。

把功能需求当作症状来读

当用户反复要求加一个CSV导出按钮时，通常的做法是做出按钮、关闭工单。好医生面对要求开抗生素的病人时则会换一种做法，先检查症状再开处方。被要求扮演诊断医生的Claude审阅了43条CSV导出需求：

这一诊断指向了更有价值的功能，比如自动同步Google Sheets、按计划发送月度对账单，同时保留一个基本的导出按钮。如今的前沿模型默认不会主动进行这种跨领域思考，用户仍需在提示词中明确引导。未来的模型也许能自然做到这一点。

▲ 把功能需求当作症状来诊断

期望正在落后于模型

文章最后谈到自我效能感，也就是相信自己能取得重大成果的信念。模型能力似乎每两周就上一个台阶，人的期望却停在原地，这道差距成了人为的天花板。看到别人做成难事，天花板就会被重新设定。1954年5月罗杰·班尼斯特突破1英里4分钟大关后，仅仅46天就有另一名跑者做到了同样的事。萨巴斯蒂安·萨维在伦敦打破了马拉松2小时大关。数学家乔治·丹齐格在加州大学伯克利分校上课迟到，把黑板上两道著名的统计学未解难题当成了作业，结果把两道题都解了出来。留意别人用智能体做成了什么，也许是提高自身期望最简单的方法。

下一条提示词该怎么改

想从同一个模型中获得更多，就要瞄得更高、挖得更深、看得更广。可以这样实践：

1. 把下一条给Claude Code的指令，按任务、结果和目标背后的目标三个层次重写。
2. 交付大目标之前，先问智能体需要哪些工具、权限和设置，并为它的沙箱设定成本上限和安全边界。
3. 通过MCP把客服工单和错误日志接入智能体，无法复现缺陷时让它直接询问用户。
4. 不再定期查看仪表板，改为每周提出10个问题，并生成回答这些问题的报告。
5. 做性能优化时，要求提供性能剖析追踪并设定激进的目标。遇到瓶颈时，把问题中的名词改写成动词，寻找已经解决过这个问题的职业。

对最庞大、最关键的功能仍要亲自把关，同时开始把日常工作改为目标层次的指令，看看同一个模型还能多做多少事。