本文是我在 2026 年 2 月 7 日对自己使用 AI Coding 的阶段性总结。

在这三个月内，我高强度使用 AI Coding，目前已经花费了 3000 余元。当然，在各位大手子的眼里，这点钱可能不算什么，但我更想说的是，我的工作没那么忙，本不该花这么多钱。

而且我的技能水平也不允许我进行纯粹的 Vibe Coding，因此 Token 的消耗量总是 effective 的。我也不会刻意为了烧完 Token 而去过度消耗。

接下来，请大家欣赏我烧了大约 200 亿 Token 总结出来的经验。

前提条件

先说一下写在本文发生之前，我所拥有的前提条件。

硬件环境：首先，我是 Mac 用户。如果你用 Windows 的话，Powershell 对 AI 来说就是一次劫难了，更别说各种权限问题、环境问题，对 AI 来说噪音是非常巨大的。

订阅套餐情况：

• Claude Code：目前是 Max 用户，订购了 100 刀的 Max 套餐。
• 智谱清言（GLM）：购买过他们家 400 块的套餐，不过现在没续费了。
• Kimi：购买了 Lite plan。
• 火山引擎：最近购买了他家 200 块的套餐，用着还不错。

说到这儿，我得提一下火山的 CodingPlan，其实挺值的。你可以考虑走我的邀请链接，现在买可以打 9 折。它的好处是同时支持 Kimi、GLM 和豆包。当然，豆包的模型太垃圾了，没人会用的；还有 DeepSeek，不过我觉得 DeepSeek 在代码场景其实也没什么人用。

目前来说，我觉得各家模型算是百花齐放了，选择很多，甚至很多简单场景下，各个价位段之间也没什么大区别。我个人体验来说，Claude 4.6 Opus > Claude 4.5 Sonnet >= Kimi K2.5 > GPT 5.2 Codex >= GLM 4.7 > 其他模型。

核心目标：让 Agent 长时间运行

好的，正题开始。

你可能好奇，为什么我对让 Agent 长时间运行这件事这么执着。就如 Anthropic 所说，让 Agent 长时间运行是模型性能的核心指标。大部分的模型从一开始只能完成一次对话，到现在的可以利用 Agent 进行长时间的重构而无需人类干预，这才是模型可以拿来衡量的进步。

而非很抽象的”之前他写不出来什么，现在他能写出来”，这东西就没多大参考价值。因为大家都知道那些模型跑 RL 训练场景、刷跑分、刷 benchmark，大伙都清楚。

围绕这个目标，我的实践经历了四个阶段的迭代，每一步都在解决”Agent 为什么跑不长”的一个具体瓶颈：Plan Mode 解决方向问题，Spec Driven 解决记忆问题，反馈循环解决纠偏问题，Ralph Loop 解决续航问题。下面依次展开。

Plan Mode

给可能没开过 Plan Mode 的人讲一下，Plan Mode 是什么。

Plan Mode 是 Claude Code 以及大部分 Code Agent 都支持的一种对话模式。顺便提一下，Claude Code 是首发这一功能的。通过按两次快捷键就可以启用。

总的来说，其流程如下：

1. 用户提出要求。
2. Code Agent 自动 Explore 代码库。
3. 根据 Explore 代码库得到的各种文件上下文信息，理解你所说的计划。
4. 最终生成一份详细的计划书供人类审阅。
5. 审阅通过后，它才去执行。

换句话说，就是让 AI 自己根据你的模糊需求写 PRD，然后执行。

听起来好像没什么，大部分人用 AI 之前其实都会进行这些流程。但我想说的是，把这个流程标准化并内置在 CLI 中，通过按两次快捷键就可以启用，这件事本身是极其方便、极其人体工程学的。

它是一切的起点——没有 Plan，Agent 就是在盲跑，跑得越久错得越远。

Spec Driven Development

Plan Mode 会产出 Plan。而这些 Plan 是非常宝贵的资产——它代表了模型决策的过程，以及模型与人类决策之间的磋商过程，更遑论它本身就是一个 PRD。

因此，将这些资源妥善保管并加以利用，甚至采用更结构化的利用方式，这就是 Spec Driven Development。

在这条路上，演进最快、效果最好的方案，私以为是 OpenSpec，最差的是 Github SpecKit。

我尝试将 Spec Driven 分成三个角度来理解：

1. 结构化

你的 Spec 最好是灵活的，但灵活带来的结果是 Agent 需要浪费宝贵的上下文去检阅各种 Markdown。因此，如果你能写出遵守规范的 Markdown，同时 AI 擅长阅读，你就可以利用外部工具去 parse Markdown。

最终，它既能作为 Markdown 被 LLM 读取，又能作为 Data Source 被工具读取，这是一件很重要的事。我称其为”结构化”。

2. 层叠与依赖

为什么结构化很重要？这涉及到另一个概念。大部分 Spec 和 PRD 在结构上都不可能是扁平的。

在实际开发中，需求往往来自多方，或者同一方会在一个需求上叠加另一个需求。因此，Spec 之间一定存在依赖关系，甚至是层叠、嵌套多层的。

如何支撑 Spec 的层级和依赖关系？换句话说，把它真正作为一个项目管理或任务管理问题去理解是非常重要的。在现代任务管理中，这种”有向无环图”（DAG）是常见的成熟抽象。

3. Spec 设计

结构化解决了”怎么存”，层叠依赖解决了”怎么组织”，最后一个问题是”里面放什么”——即一份完整的 PRD 应该包含哪些部分：

1. Requirements：用户一开始的需求。你需要先细化出来，写到文档里。
2. Design：根据 Requirements 去写 Design。Design 更多像是架构实现。
3. 任务拆分：根据 Design 去拆分出任务。

能够支撑这些结构的 Spec 抽象，在我眼里才是成功的。最终经历了多次探索，OpenSpec 作为 Successor 脱颖而出。

Plan Mode 让 Agent 知道”做什么”，Spec Driven 让这些计划不会随着上下文窗口滑走而丢失。Agent 跑得越久，上下文越长，Spec 的价值就越大。

反馈循环

有了 Plan，有了 Spec，下一个问题：怎么保证执行不翻车？

可以理解为，你让实习生干活，最好是给他一个详细的计划，告诉他：

1. 你要做什么
2. 更改哪些部分
3. 验收的结果是什么

如果你不把这些条件给全的话，那一定会出事的。

Plan Mode 就是这么一个 case，它把”写计划”这件事由人类转向了 Claude Code 本身。Claude Code 会根据你的要求去 explore 代码库，理解你所说的要求，然后自动给你生成一份计划，并且照着这份计划执行。

这听起来很自然，那么它究竟改变了什么呢？我认为它抽象出了一个模型，即 Plan → Build → Verify → Iterate 这个流程。这个流程被我称为反馈循环。

它主要包含两个关键环节：

1. Plan（计划） ：把要做的事情做得非常透明。
2. Verify（校验） ：通过定义校验流程，让 Agent 知道实际情况与预期的差距有多大，以便迭代。

而人类在这件事上需要做的就是，帮助 Agent 减少每一环、每一步中流程的噪音。一旦这个迭代流程能以一种健康的方式飞速运转，那么 Code Agent 能做的事情就非常多。

到这里，Plan 让 Agent 有方向，Spec 让计划不丢失，反馈循环让执行能自我纠偏。三者叠加，Agent 的单次运行时长已经能拉得很长了。但还差最后一步——Agent 停下来之后，谁来让它继续？

Ralph Loop

Ralph Loop 是 Anthropic 最近研究的一个成果，就是来解决这个问题的——让 Agent 不知疲倦地持续运行。说实话，大部分人看了它的 research 报告都会觉得，这一定是个非常复杂的系统，但其实应该把它拆成两部分来看。

Part 1：Task System

Claude Code 最近在新版本中发布了 Task System。原先的 Todo System 结构比较单一，无法支撑多层级的任务，且内容过于细碎。你对于它储存的信息，几乎只能指望它在 Plan 里，如果脱离了 Plan，就很难追踪上下文。

对此，Anthropic 终于意识到原有的功能不够强大。在参考了现实世界的开发流程（换句话说 OpenSpec…）后，他们开发了支持层级结构的 Task System。

Task System 的主要能力包括：

• 任务之间可以重叠
• 支持任务依赖关系
• 根据依赖关系并发地启动 Agent 实现
• 协调各个子 Agent 的执行并解决冲突

宗旨，Claude Code 基于 Task System，实现了一个多层级的 Multi-Agent。当然，重要的不是它的原理，而是你要知道这件事，你知道这件事就足够了。

不过，Task System 并不如 OpenSpec 那样可视、易于观测，因此仍需审慎使用。

Part 2：Ralph Loop 本体

Task System （又一次）解决了任务编排，Ralph Loop 解决的是”别停下来”。

它利用了 Claude Code 的 Hook 机制：每次 Claude Code 停止（Stop）时都会触发 Stop Hook。Ralph Loop 作为一个 Claude Code Plugin，其原理就是监听 Stop 事件，自动发送一条消息让 Agent 继续运行。

这就是它的核心逻辑。拆掉它的 Task System 的话，Anthropic 这个所谓的让 Agent 运行一整天到几个月的，说实话，是没有含金量的。

确定性任务 vs 非确定性任务

当然，Ralph Loop 代表了另一种可能性，这个可能性是脱离 Task System 存在的。

你可以注意到前面提到的这些，包括 Plan Mode、Task System 以及 OpenSpec，都基于一个有时候并不客观可行的现实条件：即任务是可规划、可恢复的。这个”可恢复”指的是：AI 会在上下文完全失控之前解决问题并前进。这类我称之为确定性任务。

而对于非确定性任务——AI 并不能完全理解任务，甚至需要去盲猜、去实验——你暂时就只能考虑多开几个 Agent，让他们往不同的方向尝试，然后去”抽卡”了。

Ralph Loop 对两类场景都有价值：

• 确定性任务：配合 Task System 实现自动持续运行。
• 非确定性任务：多开 Agent 时，至少你不用一遍一遍地在终端输入 continue 了。

这也是 Ralph Loop 脱离 Task System 独立存在的意义。

结尾

你有 114,514 种方式让它长时间运行，那么剩下的就是找到 use case，比如说：

1. 可以在一个大项目里，让它帮忙补测试，把 coverage 补成 100%。然后让它一天连续运行几个小时，甚至运行一晚上，早上起来直接看结果。
2. 你可以分配给它一份一千章小说的大纲，让它自己去扩充完善并进行写作。
3. 给它一个东西，让它自己去迭代，自己想办法看看哪里能完善，再继续完善。

总之，要相信它的可能性，然后 build more great things!