我们需要“更有野心”地使用AI
沿着一份季度复盘的变化,看懂如何把任务提升到目标、回到原始材料做研究,再引入其他领域的方法;每一步都要留下可检验的结果。
大部分人用 AI 时都被自己的想象力限制了,只拿它写写水邮件、改改格式;我们真正需要的是“更有野心”地使用AI。
参与 Claude 研发的 Felix Rieseberg 经常看到一些自己没想到的 AI 用法。他平时主要使用 Claude,但这套建议并不局限于特定模型。模型在有些方向上表现惊人,有些地方又明显不足。这些经验让他觉得,我们对 AI 提的要求,还可以更有野心一些。
他把这种野心分成四个维度:速度(Speed)、高度(Altitude)、深度(Depth)与广度(Range)。
同一份工作,可以改变哪几件事?
同样是准备一份季度复盘,可以从四个方向改变对 AI 的要求:
- 速度(Speed):把手头的活干得更快。
整理数据、写代码、做幻灯片,目标和步骤基本照旧,让 AI 帮你更快完成。原来需要手动填进汇报模板的数字,现在交给它整理和填入,你再核对结果。 - 高度(Altitude):抬头看,做这件事到底为了什么。
你让 AI 做季度汇报,是为了看清业务问题、决定下一步怎么做。顺着这个目的,可以让它找出最紧迫的三项决策,再设计一套能更早发现经营问题的预警流程。 - 深度(Depth):像顶尖行业专家一样,往问题深处挖。
分析用户为什么流失,就让它打开原始行为日志,用数据库和统计方法检验“新人引导没做好”这个猜测,再拿没见过的数据验证发现。沿着数据、工具和关键假设往下查,直到结论有依据、经得起检验。 - 广度(Range):把不同领域的拿手方法借过来。
同一份季度汇报,可以用分析师的方法核对数字,用记者的方法追查事实出处,用做空研究的方法寻找反面证据。让这些专业方法分别处理问题,检查单一视角容易漏掉的地方。
这四个方向可以分别用,也可以组合。下面沿着这份季度复盘,看每一种要求该怎么继续往下提。
从“做一份季度复盘”出发
Acme 是原文的虚构公司。以下展示任务怎样变化,不代表这些方案已经取得成效。
交付仍是一份复盘,用更少时间完成。数字与结论照样需要核对。
高度 Altitude
改变要实现的结果
先找最紧迫的决策,再设计持续预警;交付从一份文档扩展到能运行的流程。
用当时可获得的历史数据回放,再与旧流程并行试行。
深度 Depth
改变研究问题的方法
用数据库和适合问题的统计方法,检查“新人引导导致流失”的说法,再寻找预警信号。
让新信号接受未见数据检验;预测有效仍不等于证明原因。
广度 Range
引入其他领域的方法
让分析、新闻核查、编辑与对抗调查的方法分别承担具体工作,一个会话也能执行。
查看原始记录、证据出处与反证回应,不能只看“专家们”是否一致赞同。
三条方向可以单独采用,也可以组合;无须把每个任务都升级成一个大项目。
速度:让 AI 把同样的活干得更快
以前自己写代码、整理报表、做 PPT,现在交给 AI,省下时间。这已经很有价值,也是大多数人最容易上手的一层。
高度:把任务交大一点
老板让你做季度汇报,你就让 AI 做 PPT。但这份汇报最终是为了发现问题、做出决策。
那就继续往上提要求:找出这个季度最值得处理的问题,列出最紧迫的三项决策,给出各个方案的利弊。再进一步,让它设计一套平时就能发现异常的流程,看看能不能少等一次季度复盘。
你原本交给它的,只是实现目标的其中一步。
Felix 自己的做法是,从让 Claude 修一个个崩溃,转向让它持续协助保持应用稳定。为此,他先接通崩溃报告、应用版本与代码提交的对应关系,再提供 Windows、macOS 和 Linux 设备,让模型能实际复现和检验修复。
回到季度复盘,新流程有没有用,也得验。原文建议拿历史记录检验,再与旧流程并行跑一个季度;回看历史时,只能用当时已经拿得到的信息。
这种上提适合目标明确的工作。如果你在意的是亲自创作的过程,也没必要一味把任务往上交。
跟着试:季度复盘的三轮完整请求(中英)
下面是按原文案例整理的提示词。先提供相关经营数据,再根据分析结果逐轮追问;中英任选一种语言。
-
第一轮(初始请求:准备复盘底料时发送)
先把相关经营数据给它,弄清这个季度发生了什么:中文提示词:
“请结合我提供的完整经营数据,告诉我本季度业务发生了哪些核心变化、导致这些变化的原因是什么,以及我们接下来应该采取什么行动。”英文提示词:
"Based on the raw business data provided, tell me what key changes occurred this quarter, what caused them, and what concrete actions we should take next." -
第二轮(下一轮追问:讨论决策方向时发送)
看完变化,接着问哪些事需要尽快拍板:中文提示词:
“根据你从数据中了解到的所有情况,梳理出摆在我们面前最紧迫的三项决策,并针对每项决策梳理出正反两方面的论证方案。”英文提示词:
"Based on everything you have learned from the data, identify the three most urgent decisions facing us, and outline potential directions with arguments for and against each." -
第三轮(机制升级追问:尝试建立持续预警时发送)
以前需要人仔细翻数据、做分析,才能看清问题。现在可以让 AI 想一想,有没有办法更早发现异常,及时调整人力和资金:中文提示词:
“业务复盘的存在,是为了让管理层及早察觉潜在隐患并将资金与人力调配到正确的方向。请基于我们公司的历史经营规律,设计一套比‘每季度做一次幻灯片’更及时有效的机制;请从历史数据中证明这套新机制能够更早拦截问题,并在下个季度与现有复盘流程并行运转验证。”英文提示词:
"Propose a process that helps leadership detect emerging problems and allocate resources sooner. Compare it with our quarterly presentation using historical records available at the time. Explain whether it would have warned us earlier, then plan a quarter-long trial alongside the existing process."
深度:像顶尖行业专家一样,往问题深处挖
如果季度复盘发现用户流失严重,别让分析停在“优化新人引导、加强客户关怀”这种谁都能说的建议上。
让它去查原始日志,看看用户在哪一步离开,离开前做过什么,留下来的人有什么不同。需要查数据库就查,需要做统计分析就做。找到规律后,再拿没见过的数据检验,看看这个发现到底靠不靠谱。
“你是一位资深专家”写进提示词很容易。让它真正按专家的方法干活,才开始有深度。
如果公司一直认为流失是新人引导没做好造成的,也让它从数据里查一遍,别带着这个结论去找证据。查出的信号能预测流失,可以用于预警;要认定它就是流失原因,还需要另外的依据。
顺着数据继续往下挖,还可以让它产生新认知:导入过去一年的完整日志,让模型构建一套客户行为模拟,去寻找团队此前根本没意识到的最早流失预警信号,并在未见数据上验证预测效果。这一步的目标,是找出专业人员也可能没注意到的东西。
换到网页提速这样的任务,也可以用高得看似不合理的目标,推动模型继续深挖。比如网页原本耗时 10 秒,你准备要求降到 5 秒,他建议试着把目标提到 200 毫秒,让模型继续找瓶颈、试新方案。这是探索目标,能不能实现,最终要看实际测量。
Felix 特别强调,要有模型自评之外的独立检验,最好是模型能直接运行工具并立刻获得反馈。写代码就跑测试,做预测就看未见数据上的表现,让结果接受检查。
检查既有判断,再寻找新信号
这两轮请求按原文的流失分析示例整理,先完成第一轮,再做第二轮;中英任选一种语言。
第一轮:检查公司的既有判断。
公司一直认为,用户流失主要是新人引导造成的。
请从原始用户日志检查这个判断,列出支持它和与它冲突的证据。
Our current explanation for churn is poor onboarding.
Check that explanation against the original user logs. Report evidence that supports it and evidence that conflicts with it.
第二轮:寻找此前没注意到的预警信号。
请用过去一年的日志建立客户行为模拟。
先检查它能否复现已有记录中的变化。
再寻找我们此前没注意到、能更早预示流失的信号。
用未参与构建和选择信号的数据,检验预测是否仍然成立。
Build a simulation of customer behavior using the last year of logs.
Check whether it reproduces the recorded patterns.
Look for early churn indicators we have not noticed before.
Evaluate their predictive value on data excluded from building the simulation and selecting the signals.
先用四个问题,重新定义手头的任务
使用方式: 换成你自己的任务,先在对话中附上具体要求与现有材料,再发送以下提示词(选择中文或英文其一即可):
中文改编版:
请帮我提高这项任务的专业深度,先不要扩大工作范围。
先回答以下四个问题:
1. 专业人员还会做哪些我没有提出的关键工作?
2. 他们需要哪些原始记录,而不只看现有摘要?
3. 具体应采用什么方法和工具,为什么适合这个问题?
4. 用什么独立证据或检验,可以判断结果是否可靠?
然后据此改写我的任务要求,写清执行步骤与验收方式。
英文改编版:
Help me improve the professional depth of this task without expanding its scope.
Before doing the work, answer four questions:
1. Which important steps would an experienced practitioner add?
2. What original records would they need beyond the summaries already supplied?
3. Which methods and tools fit this problem, and why?
4. What independent evidence or test would establish whether the result is reliable?
Use those answers to revise my task brief, including the work to perform and how to check it.
广度:把其他行业的本事也借过来
还是那份季度汇报。分析师会核对数字,记者会追查消息来源,编辑会检查论证有没有跳步,做空研究员会专门寻找反面证据。
这些方法都可以用上。让 AI 核一次数字、追一次出处、找一轮反证,比给几个 Agent 安上“专家”的头衔,再看它们互相赞同有用得多。
Felix 的一个办法,是把名词换成动词:把“做一份 PPT”,换成“让忙碌的管理层看懂业务变化,并在半小时里做出决策”。沿着这些动作,就更容易看见还缺哪些专业方法。核查账目,可以借法证会计的方法;需要现场演示,再考虑动效和音频设计。
跨领域有时难在根本没想到去借别的工具。Felix 自述他以前做过游戏,却直到看见同事 Alex Albert 用 Blender 渲染室内设计,才第一次想到让 Claude 协助搭建自己主页的 3D 环境。工具其实在那里,他此前没有想到可以这样用。
为什么我们常常不敢提出高要求?
人在面对新工具时,往往被自己习惯的边界困住。Felix 借用心理学中的“自我效能”解释这种心理障碍:人通常只在自己熟悉的领域相信自身能力,而不敢在陌生方向设定高目标。他给了三条建议:先相信事情有可能做成,看看别人已经怎么做,再允许自己试了也会失败。工具在变,你对“我能做什么”的判断也可以跟着更新。这谈的是人愿不愿意尝试;模型做得对不对,仍然要检验。
要让前面的分析和验证真正做起来,模型得能操作计算机、安装软件,并通过 MCP 等方式接入各类相关数据,做完还得有可运行的工具即时检验。否则,“更有野心”很容易只剩下一段更夸张的提示词。
我们需要“更有野心”地使用AI
参与 Claude 研发的 Felix Rieseberg 提出四个方向:速度、高度、深度与广度。这套建议不局限于 Claude;四个方向可以分别用,也可以组合。
准备季度复盘:看清业务发生了什么,决定接下来怎么做。
速度Speed
把手头的活干得更快
仍交付一份汇报,让 AI 整理数据、填模板、做幻灯片,目标与步骤基本照旧。
怎么验:核对数字与结论,确认节省了时间。
高度Altitude
抬头看:汇报到底为了什么?
从完成 PPT,转向找出三项紧迫决策,再设计能更早发现经营问题的预警流程。
怎么验:用当时可获得的历史信息回放,再与旧流程并行跑一个季度。
深度Depth
像专家一样,往问题深处挖
如果发现用户流失,打开原始日志,用数据库和统计方法检查“新人引导没做好”的猜测,再寻找更早的预警信号。
怎么验:用未参与建模与选信号的数据检验;能预测流失,仍不等于证明流失原因。
广度Range
把其他行业的拿手方法借过来
同一份汇报,用分析师的方法核数字、记者的方法查出处、做空研究的方法找反证。
怎么验:查看实际核查记录与反证回应,不能只看几个“专家”是否一致赞同。
任务提大了,检验也要跟上
“你是一位资深专家”写进提示词很容易。要让它按专家的方法干活,还得把材料、工具和验收方式一起交清楚。
提供日志、经营记录等原始信息,别只给加工后的摘要。
让模型说明要查什么、用什么工具,以及为什么适合这个问题。
写代码就跑测试,做预测就看未见数据,别只让模型评价自己。
让野心有条件落地
先相信有可能做成,看看别人怎么做,也允许自己试了会失败。同时,为模型接通相关数据、计算机操作和可运行的工具,让分析与验证真正发生。
依据 Felix Rieseberg 的文章整理。阅读原文
How to be more ambitious: A tutorial for humans with models

I work on Claude. It's an interesting experience: Every day I learn about yet another feat accomplished with or by Claude that I hadn't considered, didn't think possible, or simply lacked the curiosity and time to try. This month, it may have helped discover a new planet, I've seen the first AI music video that I really like, and we are discussing a new era of math.
Model capabilities don't grow uniformly. Models are, as Terence Tao puts it, "astounding in some directions, while inadequate in others". Some people manage to pilot the astounding capabilities and seem to be flying - it's addicting to watch people reach incredible heights with the products I've built. Many others are still struggling to get their new wings to work, wondering what they're good for beyond asking "What is the capital of France" or "Can you make this email sound less angry".
I frequently proclaim (together with other people working on AI) that we ought to be more ambitious when using it. It's become a rallying cry. Whenever we see something impressive, we repost and write "we're not ambitious enough". I understand how tricky it is to follow that advice, so here's a tutorial on being more ambitious.
I think of ambition in four types: Speed, Altitude, Depth, and Range.
- Speed: The same work in less time, the bread and butter for AI's economic value: If you need some code written, I'll do it faster with Claude. Well established and requires little creativity in how you approach AI, so I'll skip this one.
- Altitude: Going up in abstraction and considering the outcome rather than the individual task.
- Depth: Considering a task the way a field-leading expert would. Rather than operating at the task's layer, we go one level deeper and touch the underlying data, tools, and problems.
- Range: Drawing on multiple fields rather than just the one the task might need at the surface, using knowledge, tools, and techniques you normally wouldn't.
I primarily use Claude (duh) but my advice is not model-specific.
Altitude
We often flippantly call this "letting the model operate at a higher abstraction". When you give the model a task, it's executing your best guess at how to get the outcome you want. To be more ambitious in altitude, ask yourself - what do you want to happen next? What's the goal beyond the goal? At the beginning of last year, I still asked Claude to fix individual crashes for me. Eventually I asked Claude to simply keep our apps crash-free.
Let's consider an everyday (dare I say mundane?) office task. You're at Acme Inc, an imagined company, where you need to put together a deck for the quarterly business review (QBR). Given a bunch of data, Claude will happily make you some slides. Maybe you even have a template and it just needs to fill it in. That's hardly comparable to finding a new planet, so let's look at some concrete steps to make our approach more ambitious. We'll start basic and get a little bit more ambitious with each step:
- As input, most reviews want to know what changed this quarter, why, and what should be done about it. Resist the urge to just update whatever numbers are in the template - give the model too as much data as you can get your hands on so it can understand your business: "Tell me what changed this quarter, why, and what we should do about it."
- Meetings (the good kind, anyway) ideally end with some decisions. Ask Claude: "Work out which three decisions are most urgent in the face of everything you've learned, and start working on potential directions with for/against arguments."
- QBRs are from a time when good reviews required humans to carefully sift through data, figure out what the data means, and if the business should adjust. Ask Claude: "The review exists so leadership catches problems early and moves money and people to the right places. Design a better way to do that than a quarterly deck, show from our own history that it would have caught things sooner, and run it beside the current one for a quarter."
The altitude approach works best if you really are after some ultimate outcome; it works less well for creative endeavors. A good tell-tale sign that ambition in altitude is a good idea is if you're going to have meetings to discuss whatever you're working on. There are currently limits ("Claude, go make money" doesn't seem to work for most businesses by itself in 2026), but I generally see that models seem to be able to operate at higher levels of abstraction the more capable they become.
Altitude is also where people find durable workflows that take the human out of the loop, making it less necessary for you to constantly update the model with task after task. Doing this well often involves changing your workflow - in order to let Claude make sure our app is crash-free, I first had to make sure it can easily fetch crash reports, understand which app version maps to what git commit, and give it access to Windows, macOS, and Linux computers so it can actually independently reproduce and verify fixes.
Depth
Sometimes, you just want a task executed really well. Being ambitious in depth means pushing the model to use the tools, techniques, media, and knowledge employed by the best professionals in the field - and to keep pushing until even those people might learn something new from your work.
Let's continue with our Acme Inc example of a quarterly business review deck. Assume for a second that Acme Inc struggles with some user churn (customer loss over time). I've found a mix of the following techniques useful:
- Insist on the same instruments used by the best in the industry: When prompted to act like a professional, models often switch vocabulary without actually switching methods. To work on our problem with depth, we need to use the same tools as the best data scientists and statisticians. When Claude reaches for markdown tables, insist on the use of databases and statistical models. You don't necessarily have to know what the experts use, Claude usually does.
- Pick unreasonable goals and tell the model that they're very reasonable: You need your website to load in 5s instead of 10s? Ask for 200ms. Does something seem impossible to the model? Reiterate that it's very much solvable, it just needs to keep going.
- Challenge what you know: Especially in business, a lot of things we believe to be true are rough approximations of reality. Give the model access to the raw information and data and ask it to adversarially check assumptions. "We believe churn is an onboarding problem. Try to reproduce that from the raw data."
- Produce new knowledge: Easily tacked onto challenging what you know - once Claude is already deep inside the data, ask it to find blind spots. "Build a simulation of our customers that reproduces the last year from our logs. Then find the earliest signal of churn we don't know about yet, and show it predicts on data it has not seen."
- Use an outside judge: Do not ask the model to judge itself. I assume that this will eventually be solved with increasing model intelligence, but in October 2026, I implore you to insist on outside validation. Ideally that's a tool the model can run to get feedback immediately.
A simple prompt that often helps me:
I want a deeper version of this task, not a bigger one. Before rewriting it: (1) say what a top professional in this field would do here that I'm not asking for; (2) name the rawest material they would start from instead of what has already been digested for me; (3) name the specific methods and tools they would use; (4) say what, other than you or me, would show the result is right. Then rewrite my prompt to ask for exactly that.
Range
In short, being ambitious in range means that we consider our work from the perspective of different fields - more fields than would have been economical in the past. This isn't a particularly unique insight, every single heist movie spends the first 30 minutes assembling a diverse cast of characters and talents. As AI products make it easier and easier to run multi-agent systems (with multiple threads, orchestrators, or simply subagents), I've seen really interesting results by imploring Claude to bring in additional fields.
Putting this into practice isn't easy; it requires you to be creative. Until I saw my colleague Alex Albert use Blender to render interior designs, I never considered using Claude for 3D environments for my homepage - even though I've previously made video games! However, this is easily where I see the most magic happen.
So, how do we do this? I use the following techniques:
- Try to replace the nouns with verbs: An old trick from The Art of Innovation by Tom Kelley and Jonathan Littman. A quarterly review isn't "a deck". It's "getting busy people to believe a story about cause and effect, and to decide under uncertainty, in 30 minutes". Having the verbs makes it easier for both me and Claude to understand which fields might bring in a unique and useful perspective.
- Assemble the crew: The deck needs to be amazing, otherwise aliens will blow up Earth. What kind of team will humanity get together? For production quality, I'd bring in an analyst, a journalist, and an editor. If it has to be presented, probably a motion and audio designer, too. It might be useful to employ an adversarial "red team", too, so let's bring in a short seller and a forensic accountant. It is easy to accidentally engage in role play, which will make your transcript weirder without improving the actual outcome. Use this method to find fields and techniques. Don't ask the model to write a short seller, ask it to do what a short seller does to research their position.
All the ways in which I describe ambition require the model to have a computer with the ability to install software and access to all kinds of relevant data (either using MCP connectors or other means). Plenty of tools make this possible and I recommend that you use one.
We have been here before
That's my concrete advice for how to be more ambitious. If you're willing to stick around for a minute, I'd like to tell you why I think this is even necessary in the first place.
We humans have always been held back by what we believe possible - and what's worse, we usually trust ourselves only in very narrow disciplines. Michelangelo famously didn't want to paint the Sistine Chapel - you see, he was a sculptor, not a painter.
While researching the problem of ambition, I learned that psychology has a name for this: self-efficacy. In short, people with high self-efficacy believe in their own abilities more, and in turn actually accomplish more. There's evidence that self-efficacy can be hacked: Locke and Latham pored over 35 years of goal-setting research to confidently proclaim that humans who are given specific hard goals perform better than those who are simply told to try their best. Stripe founder Patrick Collison maintains a "Fast" list, chronicling the many things humans have accomplished when given both audacious goals and tight deadlines. Some hacks that are well documented:
- Accomplish hard things by believing them to be possible: In 1939, George Dantzig showed up late to a statistics class at Berkeley, copied two problems off the blackboard, and handed in his solutions thinking they were homework. They were two unsolved problems in statistics.
- Accomplish hard things after watching somebody else do them: For decades, humans chased the four-minute mile. Roger Bannister broke it in May 1954 but remained the only human to do so for a mere 46 days. If you're into running, we're watching something similar happen to the two-hour marathon: Sabastian Sawe ran the first official sub-two-hour marathon in London this April. In the same race, the runner-up also broke the two-hour mark.
- Accomplish hard things by giving yourself permission to fail: Apparently everyone's favorite business book is The Inner Game of Tennis, which I discovered just last week. The book's core thesis is that you're not playing your best game of tennis if you're trying really, really hard. We engineers might remember Linux, announced as "just a hobby, won't be big and professional like gnu".
Self-efficacy isn't a new problem, but it is a more powerful one now. In a world where our abilities make leaps every couple of weeks, we need techniques that allow us to do things we didn't really consider or believe possible. If you find more techniques that allow you to be more ambitious, please let me know!
The image for this post is by Francisco Goya, “Modo de volar” (A Way of Flying)