别只让 AI 更快：用速度、升维、深度和范围扩大问题边界
本文整理自 Felix Rieseberg（@felixrieseberg）的 X 帖子及其长文教程《How to be more ambitious: A tutorial for humans with models》。原文作者在 Claude 团队工作，文章中的案例和方法来自个人工作经验。本文保留原文的框架与示例，同时补充了适合 GPT88 工作流的验收和权限说明；不把个人体验写成所有模型都能达到的承诺。
“更有野心”不是把提示词写得更长
“使用 AI 时要更有野心”很容易变成一句口号：看到一个惊人的案例，转发并说“我们还不够大胆”。但对正在处理具体工作的普通人来说，真正的问题是：下一步应该怎么改变任务？
Felix 将这种野心拆成四个方向：
| 方向 | 要问的问题 | 典型变化 |
|---|---|---|
| 速度 Speed | 同样的工作能否更快完成？ | 用 AI 加速代码、写作或整理 |
| 升维 Altitude | 这个任务真正要改变的结果是什么？ | 从做一份报告，升级为帮助团队更早发现问题 |
| 深度 Depth | 领域顶尖实践者会怎样完成它？ | 使用原始数据、专业工具和可复现方法 |
| 范围 Range | 哪些其他领域能带来新的方法？ | 让分析师、记者、设计师或审查者共同参与 |
速度是最容易理解的收益，但文章真正强调的是后面三项：不要只让模型把当前任务做得更快，也要重新审视任务的目标、方法和参与者。
一、速度：最成熟，但不要停在这里
让同一项工作在更短时间完成，是 AI 最直接的经济价值：写一段代码、整理一份资料、生成一个初稿，模型通常可以明显缩短等待时间。
原文没有展开速度，因为它已经是最常见的使用方式。对实际项目来说，速度仍然需要验收：
- 统计从开始到可交付结果的总时间，而不是只看首个回复；
- 记录返工、人工核验和失败重试；
- 确认加速没有把错误、隐性维护和风险转移到后面。
如果只是把“请完成这项工作”改成“请快一点”，通常不会得到数量级提升。更大的变化来自重新定义任务。
二、升维：从完成任务到改变结果
1. 问“目标之后还要发生什么”
当你让 AI 修复一个崩溃时，任务层级是“修这个问题”。升维后的问题是：“怎样让我们的应用持续保持无崩溃？”
后一个问题会迫使模型继续追问：崩溃数据从哪里来？应用版本如何对应 Git commit？不同操作系统能否复现？修复后谁来验证？这已经从一次性补丁变成了可持续的质量工作流。
2. 从季度汇报到持续决策系统
原文用虚构的 Acme 公司季度业务回顾（QBR）举例。可以把一份“填数据的演示文稿”逐级升级为：
- 给模型尽可能完整的业务数据，让它说明本季度发生了什么、为什么发生，以及应该采取什么行动；
- 让它从全部信息中找出最紧急的三个决策，并列出不同方向的支持与反对理由；
- 追问季度汇报的真正目的：帮助管理层尽早发现问题、重新分配资金和人员；
- 设计一种比季度演示更早发现问题的机制，并用历史数据回放，验证它是否真的能更早发出信号；
- 先与原有流程并行运行一段时间，再决定是否替换。
这里的关键不是让 AI 代替管理层做决定，而是让它参与发现信号、生成选项和验证流程。最终决策仍需要业务负责人承担。
3. 升维什么时候有效
升维特别适合有明确终极结果、需要多人开会或持续跟踪的工作，例如质量监控、客户流失分析、运营预警和研发稳定性。对纯创意任务，升维不一定带来更好结果，仍要保留创作者的判断和审美。
三、深度：要更深入，而不是只做更大的版本
有些任务的目标不是改变流程，而是把当前问题做得足够好。深度意味着让模型使用这个领域中真正有效的原始资料、工具和方法，而不是只换一套专业术语。
1. 要求专业方法，不要只要求专业口吻
当你说“请像数据科学家一样分析”，模型可能只改变措辞，却仍然用 Markdown 表格做表面总结。更深的要求应该是：
- 从原始数据库或事件日志开始，而不是只读已经整理过的结论；
- 使用统计模型、实验设计或其他领域常用工具；
- 展示假设、数据质量、误差和适用范围；
- 产出能够复现的中间结果和检查方法。
2. 设置高但可验证的目标
原文建议把目标设得“不合理”一些，例如把网页从 10 秒优化到 200 毫秒，然后让模型继续寻找瓶颈和可行路径。这里需要保留一个边界：高目标用于扩大探索空间，不等于可以跳过成本、资源和安全评估。
更稳妥的写法是要求模型先列出：
- 当前基线和测量方式；
- 达到目标需要改变的环节；
- 可能的技术与资源约束；
- 一个低风险验证实验；
- 如果目标不可达，最接近的可交付结果是什么。
3. 让模型挑战已知假设
业务团队常常把“客户流失是 onboarding 问题”当作结论。更深入的任务是把原始数据交给模型，并要求它反向验证：“请尝试从原始数据复现这个判断；如果不能，请指出替代解释。”
当模型已经深入数据，还可以继续追问：是否存在团队尚未意识到的早期信号？能否建立一个回放过去一年日志的模拟，并在未见数据上验证信号？这类工作必须带有数据时间范围、训练/验证切分和人工复核，不能把模型生成的相关性直接当成因果关系。
4. 不要让模型自己当唯一裁判
原文特别强调外部评判：不要让模型只凭自己的文字宣布“做对了”。外部评判可以是测试、数据库约束、浏览器检查、真实用户反馈、独立评审模型或领域专家。
一个适合复用的提示词是：
我想要这个任务的更深入版本，而不是更大的版本。
在重写任务之前，请先回答：
1. 这个领域的顶尖实践者会做什么，而我的要求没有覆盖什么？
2. 他们会从哪些最原始的资料开始，而不是从哪些已经加工过的摘要开始？
3. 他们会使用哪些具体方法和工具？
4. 除了你和我之外，什么东西可以证明结果是正确的？
然后把我的任务重写成一个包含这些要求、并且可以验收的版本。
四、范围：把其他领域带进来
范围不是让模型扮演更多角色，而是让任务真正借用其他领域的方法。一个季度汇报并不只是“一份 deck”，它也可以被描述成：让忙碌的人在三十分钟内相信一套因果解释，并在不确定性下做出决定。
把名词改成动词，往往更容易发现可借用的能力：
- “做一份报告”可以变成“解释变化、建立因果、帮助决策”；
- “设计一张页面”可以变成“引导注意力、降低理解成本、促成下一步”；
- “分析流失”可以变成“发现早期信号、验证假设、选择干预动作”。
接着组建合适的“队伍”：
- 分析师负责数据和统计；
- 记者负责追问事实、证据和反例；
- 编辑负责结构、清晰度和读者理解；
- 动效与音频设计师负责展示和呈现；
- 红队、做空研究员或法务审查者负责寻找漏洞。
这里应要求模型执行这些领域的方法，而不是只用某个职业的口吻写作。角色扮演如果没有工具、资料和明确产物，容易变成更长的对话，却不一定改善结果。
范围也可以体现在工具上：原文提到用 Blender 做三维环境、把设计工作与网页开发结合。适合的工具应由任务需要决定，不要为了“多 Agent”而强行增加复杂度。
五、这四种野心需要怎样的环境
升维、深度和范围都可能要求模型使用电脑、安装软件、访问数据、运行测试或调用 MCP 连接器。环境能力越强，权限风险也越高。
开始前至少要明确：
- 模型可以读取哪些目录和数据；
- 哪些 API、账号、密钥和生产资源禁止访问；
- 软件安装和网络连接是否需要人工确认；
- 哪些动作只能在沙箱或临时分支执行；
- 完成标准是什么，外部验收器在哪里；
- 失败、超时或模型判断不确定时如何停止。
“让模型自己做完”不等于把所有权限都打开。真正可复用的工作流，应该让目标更大胆，同时让执行边界更明确。
六、人类为什么需要“被允许”做更大的事
文章最后把问题带回人的自我效能感：人们常常被自己认为“不可能”或“不属于自己专业”的事情限制。看到别人完成一个以前没想过的任务，会降低尝试门槛；明确、困难但可验证的目标，也比“尽力而为”更容易产生行动。
这不意味着盲目相信所有目标都能实现。更可靠的方式是：
- 把大胆目标写出来；
- 找到一个低成本、可撤销的验证实验；
- 为失败保留预算和停止条件；
- 记录真正有效的工具、资料和方法；
- 把成功流程固化成下一次可复用的工作单元。
一张可直接使用的任务升级表
当你下一次准备把任务交给 AI，可以按顺序问：
- 速度：能否减少机械劳动和等待？
- 升维：这个任务真正要改变的结果是什么？有没有比当前交付物更好的机制？
- 深度：顶尖实践者会使用哪些原始资料、方法、工具和外部检查？
- 范围：哪些其他学科能提供独特视角？它们要执行什么方法？
- 验证：什么独立信号能证明结果正确？
- 边界：模型需要哪些权限，哪些动作必须由人确认？
这套顺序的重点是扩大问题定义，再缩小到一个可执行、可验收的实验。没有数据、工具和验证条件时，增加野心只会增加幻觉和返工。
来源与说明
- Felix Rieseberg 的 X 帖子，发布于 2026-10-13。
- How to be more ambitious: A tutorial for humans with models。
- 原文提到的 Claude、工具调用、多 Agent、MCP 和软件环境属于作者文章中的工作背景；本文没有据此推断当前产品能力、价格或服务可用性。
本文是对公开教程的结构化整理。四类野心、示例任务和验收清单保留了原文思想并做了中文编辑；关于权限、外部验证和高风险任务的说明属于编辑补充。