重新丈量目标
我已经有了 Codex 和 Claude Code 的订阅，也有不少 coding plan。可回头看，我交给 AI 的，仍主要是个人的小爱好和工作中的一些事务。工具的能力在变，我给自己设定的目标，却好像没有跟着变。
最近读到 Felix Rieseberg 的一篇文章：《How to be more ambitious: A tutorial for humans with models》。它让我停下来想了想：在 AI 的帮助下，我是不是应该更有雄心一点？
以前，有些想法会因为实现起来太难，被我直接放下。现在，动手的条件已经好了很多，那些被搁置的目标，也值得重新拿出来看看。
👉四个维度
🧭 雄心不只有“做得更快”
四个维度可以同时用来审视一件事：时间、结果、方法与视野各有要问的问题。
Rieseberg 把使用 AI 的雄心拆成四个维度：速度（Speed）、高度（Altitude）、深度（Depth）和广度（Range）。速度最容易理解：同样的工作，用更少的时间完成。后三个维度，给了我重新审视目标的几个入口。
高度，是从眼前的任务往上看，找到真正想实现的结果；深度，是学习领域内优秀专业人士的做事方法，接触他们使用的工具和原始材料；广度，是把其他学科的知识与技术带进来，看看能否找到不同的解法。我觉得这套框架有用，因为它让我看见：即使手头的事都做快了，目标、方法和视野仍有很大的调整空间。
我想把四个问题一起问：能做多快，想走多高，能钻多深，还能往哪里看？
⚡ 速度：我不能只给旧清单加速
加快已有任务之外，也给那些过去没写进清单的目标留一个位置。
对我来说，个人可用的计算资源已经相当充沛。Codex、Claude Code 和手上的 coding plan，让不少想法有了更容易动手的条件。但我的使用范围，仍主要落在一些小爱好和工作事务上。
这些事有实际帮助，也有乐趣。我在意的是，如果始终只从已有的待办清单里挑任务，AI 再能干，也主要是在帮我把旧清单做快一点。省下来的时间，很容易又被相似的任务填满。订阅额度用得更多，也不能直接说明我做的事更值得。
我需要重新看一遍那张清单：哪些目标，过去因为觉得做不了，连写下来的机会都没有？
🏔️ 高度：从修一个 bug，到追问系统怎样更可靠
长期可靠性需要报告、复现与验证持续衔接，目标和工作条件要一起调整。
原文里有个很直观的例子：Rieseberg 起初让 Claude 修复单次崩溃，后来希望它持续帮助应用保持稳定。我把这个变化理解为，从“修好这个 bug”往上问一步：“怎样才能让软件更少出问题？”任务还在，但它开始围绕一个更长远的结果组织起来。
这个例子让我注意到，更高的目标需要工作条件跟着变。作者先让模型能获取崩溃报告，知道应用版本对应哪个代码提交，还能在不同系统上复现问题、验证修复。“没有 bug”可以指引方向，实际工作仍要靠报告、测试和持续反馈来推进。在我看来，值得借鉴的是这种把目标与工作流一起调整的做法。
下次交给 AI 一个动作之前，我想先问：这个动作服务的结果是什么，还有没有更直接的做法？
🔬 深度：沿着专家的工作方法往下走
如果以后尝试游戏开发，我想沿着材料、方法、工具与反馈学习，再用可玩原型检验想法。
深度最打动我的地方，是可以借助 AI 去学习真正的专家怎样做事：他们从什么材料开始，按什么顺序推进，使用哪些工具，又怎么知道自己做对了。这些东西往往藏在实际工作里，只看交付的报告，很容易漏掉。
Rieseberg 在深度一节用客户流失分析举例：回到原始日志和数据，用数据库与统计模型检验“问题出在 onboarding”这个判断，再拿未见过的数据检查预测。对我来说，这提供了一种具体的学习方式：让 AI 带着我走过专业工作的过程，弄懂每一步为什么需要，以及它能排除什么错误。
如果以后尝试游戏开发，我也想这样入手：先研究开发者怎样用引擎做可玩原型，把核心玩法跑通，再结合试玩观察和性能分析决定下一步。引擎、profiler、playtest 都有各自要回答的问题。和 AI 一起走一遍这样的流程，应该比直接索要“一款完整游戏”更能让我学到东西。
我想借助 AI 进入专家的工作现场：接触材料、使用工具、接受反馈，再回头修正判断。
🌐 广度：把别的领域真正用进来
围绕同一个问题引入不同方法，才有机会发现熟悉路径之外的解法。
原文里还有个我很喜欢的例子：Rieseberg 看到同事 Alex Albert 用 Blender 渲染室内设计，才想到可以借助 Claude 为自己的主页做 3D 场景，尽管他自己以前也做过游戏。熟悉一项技术，和想到把它用在眼前这件事上，中间仍隔着一步。
这让我想到，我可能也在用熟悉的工作方式限制 AI。习惯从写代码的角度看问题，就容易一直让它写代码。但一个 side project 是否有用，可能还取决于交互设计、数据分析和信息表达。我想多问一句：别的领域会怎样理解这个问题？如果引入它的方法，做出的作品会有什么变化？
一个新视角有没有价值，可以看它带来了什么实际变化：多看见了什么，换用了什么工具，检验了什么原本没想到的问题。
🛡️ 实现门槛降低了，判断责任还在
实现加速时，验证、停止条件与撤回空间也需要进入工作流程。
读完文章，我最直接的体会是：以前不少事情，是敢想，但做起来太难。现在，implementation 的门槛显著降低了。至少对我个人而言，认真想清楚“还有什么值得做”，变得更迫切了。
一个合理的反驳是：目标变大，也可能只是制造更多不可靠的代码、分析和维护负担。我认同这个提醒。如果实现加速，验证却跟不上，省下来的时间可能会以返工的形式还回去。所以我希望，目标扩大时，测试、反馈和停止条件也一起想清楚。涉及真实使用者或重要决策时，还需要保留人工检查和可撤回的空间。
AI 可以帮我承担更多实现工作。目标是否值得、结果是否可信、出了问题怎样收拾，仍需要我认真判断。
🌱 把这四个问题带回 ASF 和我的 side projects
把四个问题带回 ASF 和个人项目，具体方向仍需在项目里继续寻找。
接下来，我希望在 ASF 的项目运作和个人 side projects 上，重新看一遍自己的目标。速度上，哪些事务可以更高效；高度上，单个任务服务的结果是什么，能否围绕那个结果重新组织工作。
深度上，我想多学习业内专家的真实工作流，弄清楚他们依赖的材料、工具和检验方法；广度上，我希望留意熟悉领域之外的解法。同时，也要看自己能否负担更大目标随之而来的验证和维护。四个维度给了我一个重新开始想的入口，具体往哪走，还需要回到项目里慢慢找。
我手上已经有了不少工具。我觉得，接下来更值得花时间想的是：自己究竟想用它们完成什么。
来源：Felix Rieseberg，How to be more ambitious: A tutorial for humans with models。四维框架、崩溃修复、客户流失分析与 Blender 跨域案例来自该文。