用了世界前二的大模型Astra，我还是被这个项目搞崩了：真正的瓶颈已经不只是模型

最近在做一个白膜视频同步帧批量转换的项目，真的把我头都搞大了。

本来以为现在 AI 已经这么强了，GPT、Claude，包括各种国产大模型能力都越来越猛，遇到不会的问题直接交给 AI，应该能轻松很多。

真正做进去以后，我才发现完全不是这么回事。

这个项目会涉及视频处理、3D 模型、Blender、脚本自动化、原片识别、数据提取等一整套流程，其中很多东西都是我以前没有系统接触过的。

单独拿出任何一个环节，其实 AI 都能帮上忙。

Blender 不会，可以问 AI；脚本不会写，可以让 AI 写；视频里的数据怎么提取，也可以让模型分析。

真正麻烦的是，这些东西不是互相独立的，而是串在一条完整链路里的。前面某一个环节稍微出现一点偏差，后面就可能被不断放大，最后你看到的只是“成品不对”，但真正的问题可能早在几个步骤之前就已经埋下了。

这几天国庆基本也没怎么休息，一直在折腾这个项目。折腾到后面，我越来越强烈地意识到一件事情：

AI 很强，不代表复杂项目就会自动变简单。

甚至在某些情况下，如果你自己对整个项目没有一个全局认知，模型越强，反而越容易把事情搞得越来越复杂。

1. AI 能补你的知识，但补不了你脑子里的“全局地图”

复杂项目和普通问答最大的区别，是它不是一道题，而是一整个系统。

在这个项目里，原片识别、数据提取、3D 模型、相机、动画、Blender 脚本、渲染输出之间都有依赖关系。任何一个地方出现误差，都有可能继续传递到下一个环节。

所以经常会出现一种情况：AI 给你的每一段代码看起来都没什么问题，每一个单独步骤也似乎能跑，但整个链路串起来就是不对。

这其实是很典型的工程问题。

局部正确，不代表系统正确。

刚开始我还会不停地把问题丢给 AI，让它修这里、改那里。后来发现，如果连我自己都不知道整个系统的数据到底怎么流转、哪些变量互相影响、每一步的输入输出分别是什么，那其实我也没有办法真正判断 AI 到底是在解决问题，还是只是在局部打补丁。

所以现在我越来越觉得，未来人使用 AI 的一个重要能力，不一定是你每个技术细节都比 AI 强，而是你能不能建立一个整体的系统模型。

你至少要知道，这一步输入什么、输出什么，下一步依赖什么，结果应该怎么验证，出问题之后应该往哪里回溯。

人可以不会亲自写每一行代码，但不能完全没有这张“地图”。

这其实已经不是提示词能力了，而更接近架构能力。

2. 不要按上下文长度切会话，要按任务边界切

这次项目里还有一个很大的变化，是我开始重新理解“会话应该怎么用”。

以前我经常会有一个习惯，一个会话聊得比较长了，我就会觉得上下文差不多快满了，赶紧换一个新会话，免得后面上下文压缩之后影响效果。

但这次连续折腾下来，我发现这个思路并不太对。

真正决定要不要切换会话的，不应该只是上下文还剩多少，而应该看任务边界有没有发生变化。

如果当前这个会话一直在解决同一类问题，比如一直在处理 Blender 相机、坐标或者动画相关的问题，那么前面几十轮排查过程其实都是非常有价值的上下文。

AI 已经知道哪些方案试过了、哪些地方出过错、现在有哪些限制条件。如果这时候只是因为“聊天太长”就重新开一个会话，很多信息反而需要重新建立。

但如果 Blender 这一阶段已经结束，下一步准备开始做批处理调度，或者从视频分析切换到另一个完全不同的任务类别，那就应该开新会话。

所以我现在更倾向于一个原则：

看任务边界，而不是看 Token 边界。

当然，这也不是说同一个会话可以无限聊下去。如果上下文已经被大量无关信息污染，或者前期错误假设太多，也需要及时清理。

更准确地说，应该根据任务连续性和上下文质量来决定是否切换，而不是机械地看会话长度。

3. 一个总指挥，不要让一个会话什么都干

后来我又开始尝试另外一种方式：用一个主会话作为总指挥，然后让不同会话分别负责不同类型的任务。

比如一个会话专门处理 Blender 脚本，一个负责视频分析，一个负责排查某一类技术问题，总会话负责拆解任务、查看结果、判断下一步该做什么。

这个方式用下来以后，体验明显好了很多。

因为每一个会话里面的上下文会非常干净。

以前最容易犯的一个错误，就是把所有事情全部塞进一个超级会话里。前面还在聊 Blender，后面突然开始分析视频，中间又穿插业务需求和报错信息，最后整个上下文越来越杂。

AI 并不是完全看不懂，但它需要不断在大量不同信息之间切换注意力。

现在我更倾向于让每一个会话尽量只做一类事情。

其实这和软件工程里的模块化非常像：一个模块尽量只负责一件事情。

而总会话更像一个 Orchestrator，负责调度下面不同的 Worker。

我觉得这也是未来使用 Agent 一个非常重要的思路：不是想着找一个“超级 AI”把所有事情全部做完，而是把任务拆开，然后让不同 Agent 在清晰的职责边界里协作。

4. 强模型真正有价值的地方，是开始能够“自主推进”

这次从国产模型，到 Claude，再到 GPT 系列，我基本把自己能用到的前沿模型都试了一圈。

最后真正用到 Astra 的时候，我能明显感觉到，它和以前很多模型给我的体验不太一样。

这个差异并不只是“回答更聪明一点”。

真正让我印象比较深的是，在复杂任务里面，它开始表现出比较明显的规划能力和持续推进能力。

以前很多模型更像一个能力很强的执行者。

你问一句，它答一句；你给一个任务，它完成一个任务。整个过程中，本质上还是人在不断推动。

但当模型的规划能力、工具调用能力和外部调度机制结合起来以后，它就开始越来越像一个真正能够持续工作的 Agent。

我甚至在总指挥里面设置了 Heartbeat，让它隔一段时间检查其他会话的执行情况，看看任务有没有完成，然后根据结果继续分配下一步任务。

这种体验和传统聊天机器人已经完全不是一回事了。

不过这里需要区分一个东西。

真正产生“自主性”的，并不只是模型本身，而是模型能力、工具调用、状态管理、任务调度和循环机制共同组成的系统。

强模型的价值，是它让这套系统跑起来以后更加稳定，也更加像一个真正能够自主工作的 Agent。

5. Agent 不仅需要 Goal，还必须有 Stop

Heartbeat 这个东西用起来很爽，但也有一个非常现实的问题。

它真的很烧 Token。

如果你不主动终止，它可以一直检查任务、分析结果、重新规划，然后继续执行。

从 Agent 的角度来看，它非常勤奋；从账单的角度来看，它也非常勤奋。

所以我后来越来越意识到，一个真正成熟的 Agent 系统，不能只有 Goal。

还必须有 Stop Condition。

也就是说，你不能只告诉 AI“要做到什么”，还需要告诉它“什么时候该停”。

比如什么条件算成功，失败多少次之后停止，多长时间没有明显进展之后暂停，什么时候必须请求人工介入。

否则 Agent 很容易进入一种状态：看起来一直在做事情，实际上可能只是反复尝试价值很低的路径。

所以我现在觉得，设计 Agent 的时候有两个同样重要的问题：

怎么让它开始干活，以及怎么让它知道什么时候不要再干了。

后者以前很容易被忽视。

6. 当你自己都不专业时，不要把 AI 的路径写死

这次项目里还有一个对我影响比较大的变化，就是我开始减少那种特别详细的步骤式指令。

以前我们学习 Prompt，经常会强调把任务拆得非常细。

第一步做什么，第二步做什么，第三步做什么，最后按照什么格式输出。

在确定性比较强的任务里面，这当然没有问题。

但如果面对的是一个我自己都不熟悉的领域，这种方式有时候反而会产生副作用。

因为一个很简单的问题是：

如果我自己都不专业，我凭什么认为我设计出来的步骤就是最优路径？

可能 AI 原本可以从 A、B、C 三种方向探索，结果我这个外行一上来给它规定：“你必须按照 D 方案做。”

这时候，真正限制 AI 的可能反而变成了我的提示词。

所以现在我更喜欢用 Goal 的思路。

告诉它我要实现什么目标，当前背景是什么，有哪些约束，可以使用什么资源，什么结果算成功，然后让它自己探索解决路径。

这里并不是说以后 Prompt 越简单越好，也不是说完全放任 AI 自由发挥。

而是一个很重要的变化：

少规定路径，多规定边界和验收标准。

当模型能力还比较弱的时候，人需要更多地告诉 AI“怎么做”。

但当模型能力越来越强之后，人在很多场景里更应该告诉 AI：“我要什么，什么不能做，最后什么样算完成。”

中间怎么走，可以适当把空间让给模型。

7. Benchmark 可以参考，但最终还是要看真实任务

这段时间我还有一个很明显的感受，就是现在各种模型排行榜越来越多。

有些模型在榜单上和最顶级模型已经非常接近，甚至某些指标差距看起来非常小。

比如：跑分上GPT 6.1 Sol很接近于GPT 6 Astra，但至少在我这次项目里的实际体感中，差距比排行榜呈现出来的明显得多。

尤其是在长链路任务、跨工具协作、持续规划以及复杂项目推进这类场景里，我能够明显感觉到不同模型之间的稳定性差异。

所以我现在不会再完全依赖榜单判断一个模型到底强不强。

Benchmark 当然有价值，它至少提供了一个标准化的比较方式。

但它测的是一组标准化任务，而我们真正关心的其实是：

这个模型在我的真实任务里面到底表现怎么样。

比如真正做项目时，我关心的可能不是一道题答对没有，而是它能不能连续工作很长时间，能不能发现前面的错误，能不能正确调用工具，能不能在失败之后调整方向，以及整个过程中需要我人工介入多少次。

这些东西不是一个简单分数就能完全体现出来的。

所以真正选择模型的时候，最有价值的 Benchmark 其实是自己的真实工作负载。

拿自己的问题去跑一次，比单纯盯排行榜更有意义。

至于 Astra 和其他模型之间的差距，我现在也更愿意限定在自己的场景里去说。

至少在我这次这种长链路、多工具、Agent 化的复杂项目里，我的实际体感是，顶级模型之间的差距比很多榜单看起来要大。

这是一种生产环境里的体感，而不是一个适用于所有任务的绝对结论。

8. 真正稀缺的能力，正在从“写 Prompt”转向“组织 AI”

折腾到这里，我现在越来越觉得，我们可能已经开始进入 AI 使用的下一个阶段。

以前大家讨论 AI，重点往往是怎么写 Prompt，怎么让 AI 帮自己写文章、写代码、总结内容。

这些东西当然依然重要。

但随着模型能力不断提高，真正开始拉开差距的，可能已经变成另外一些能力。

你能不能定义清楚目标，能不能给 AI 足够准确的上下文，能不能把一个复杂问题拆成合理的任务边界，能不能设计多个 Agent 之间的协作方式，能不能判断 AI 给你的结果到底对不对。

还有一个很关键的问题：

你是否知道什么时候应该控制 AI，什么时候应该让 AI 自己发挥。

以前模型能力不够，人必须手把手教。

现在有些场景已经开始反过来了。

模型可能已经有很强的探索和规划能力，但人依然沿用以前的习惯，把步骤写得特别死，恨不得每一步都替 AI 决定。

这时候，人反而有可能变成系统里的瓶颈。

所以我现在更愿意把这件事情说得稍微严谨一点：

在越来越多复杂任务里，模型能力已经不再是唯一瓶颈。人的目标定义、任务拆解、上下文组织、系统设计和结果验收能力，正在成为新的瓶颈。

这可能也是我这个国庆一直折腾这个项目以后，最大的一个认知变化。

以前所谓“会用 AI”，更多是会提问、会写提示词、会让 AI 帮自己完成某件事情。

而现在我越来越觉得，下一阶段真正值得研究的问题已经变成了：

怎么把 AI 组织成一个可以被调度、被协作、能够持续自主推进工作的生产系统。

未来人的核心能力，也可能会慢慢从“亲自解决每一个问题”，迁移到“定义问题、组织 AI、验证结果”。

模型还会继续变强。

真正需要升级的，可能也包括我们使用 AI 的方式。

关注我，了解更多AI干货。