我订阅 GPT Plus 后，不到三天就把主要额度用完了，后面额外的重置次数也耗尽了。
当时我并没有让它开发一个大型项目，只是用 Work和 Codex 做了几个小任务，比如整理资料、修改代码、分析项目。每个任务看起来都不复杂，但额度下降得非常快。
这让我意识到，订阅 AI 之后，真正需要学习的不只是怎么写 Prompt，还包括怎么选工具、选模式、控制 Token，以及管理长对话。
我从以下四个方面，分析了如何提升 AI 使用效率。

一、AI 选型

现在的 AI 工具很多，可以将它们分成几种不同角色。
  • ChatGPT、Claude、Gemini、DeepSeek 这类通用 AI 助手，主要负责聊天、分析、写作、规划和推理。它们适合帮助人理解问题、整理需求、比较方案，但不会帮你修改项目。
  • Codex、Claude Code 这类 Coding Agent，可以读取代码、修改文件、执行命令、查看报错和运行测试。它们是能够直接动手的开发助手，所以消耗也通常高于普通聊天。
  • Hermes这类 Agent 框架，主要作用是连接模型、工具、记忆和自动化任务。接入 DeepSeek，它主要体现 DeepSeek 的能力；接入其他模型，它的能力上限和调用成本也会随对应模型变化。
  • 图片、视频、配音、剪辑工具属于垂直工具。做 AI 漫剧时，需要剧本模型、图片生成、配音和视频生成等多模型协同完成全部流程。
因此，选择 AI 模型时应该先清楚自己需要完成的是什么类型的任务。比如 App 开发，可以先用一个通用模型负责规划方案，再配一个能够修改代码的 Coding Agent。
对个人用户来说，长期同时订阅多个顶级模型通常不划算。更稳妥的方式是保留一个主力订阅，再用低成本模型承担简单任务，专业工具只在项目制作阶段才启用。
我的组合思路是：ChatGPT 负责日常讨论、规划和综合任务；Codex 只处理确实需要读取和修改项目的工作；DeepSeek 负责批量草稿、简单改写和低风险任务；Claude 在复杂写作、代码审查时使用。

二、模式选择

很多人订阅 AI 后，会下意识选择最强模型、深度思考或 Agent 模式，因为感觉这样回答会更可靠。但不同模式在后台做的事情完全不同。
普通聊天通常只需要读取当前对话，然后生成回答。它适合解释概念、整理思路、修改短文本、制定简单计划。
深度推理模式会花更多计算分析问题。它适合复杂架构设计、难以定位的 Bug、多方案决策和需要严密推导的问题。
联网研究模式还需要搜索、打开网页、筛选来源和整理资料，适合研究最新政策、产品变化、论文和行业信息。
Codex、Claude Code、Work 或其他 Agent 模式则会继续执行操作。它可能先扫描目录，再读取文件，随后修改代码、运行命令、分析错误、继续修改，最后生成总结。用户看到的是一次任务，后台实际可能已经完成了多轮模型调用和工具调用。
更高效的流程是先讨论，再执行。
例如要开发一个背包系统，可以先在普通 Chat 中确认背包包含哪些功能，物品如何分类，数据如何保存，UI 如何刷新，任务完成后怎样验收。这些内容确定后，再交给 Coding Agent，让它根据已经确认的设计实现背包系统。这种方式能够明显减少 Agent 猜需求和返工的次数。
先用便宜的模式把任务整理清楚，再用昂贵的模式完成关键步骤，通常比全程开启最高模式更稳定。

三、Token 管理

很多人理解的 Token 消耗，只包括自己输入的文字和 AI 输出的回答。
实际上在一次对话中，模型可能需要处理系统规则、项目说明、历史消息、上传文件、代码内容、搜索结果和工具执行日志。
例如你输入了一句:"帮我检查一下这个项目的问题"。Agent 为了回答，可能会读取整个目录结构、多个配置文件、大量代码、编译日志和测试结果。项目越大，读取范围越宽，消耗越明显。
上传文件也会占用处理空间。几十页 PDF、长日志、完整聊天记录和大量代码，会先被解析，再进入模型上下文。文件中真正有用的内容可能只有几页，但模型仍需要先找到它们。
输出同样会增加消耗。让 AI 提供完整代码、逐步解释、多个方案、详细理由、总结和自检，看起来很完整，但其中一部分信息可能根本不会被使用。
因此，节省 Token 的关键是减少无效处理。
向 AI 提问时，最好提供四类信息：当前目标、必要背景、允许修改的范围，以及完成标准。
每增加一个要求，模型都需要生成相应内容。一个简单问题同时要求案例、数据、反方观点、专家视角、替代方案和完整自检，回答自然会变长，消耗也会上升。
更合理的方法是按任务选择一两条真正需要的指令。做事实分析时，加入"区分事实、推测和不确定信息"。做方案选择时，加入"按收益、成本和风险排序"。做教程时，加入"细化到新手可以直接执行"。做最终交付时，加入"检查关键遗漏，只报告会影响结果的问题"。
Prompt 的价值来自精确控制任务，而不是不断叠加听起来专业的句子。

四、上下文管理

我以前习惯在一个对话里持续讨论同一个项目，因为前面已经提供过大量背景，感觉继续聊最方便。但随着对话变长，前面加入的旧方案、错误信息和临时想法都会留在上下文中，AI 需要从大量内容里判断哪些仍然有效。
当对话接近上下文上限时，系统还可能压缩早期内容。压缩通常会保留大意，但具体约束、修改原因和细节可能丢失。之后就容易出现几个问题：
  • AI 重复提出已经否决的方案；
  • 忘记之前确认的约束，越改越乱；
  • 反复询问已经确认过的信息。
解决方式是把长期项目从"一条无限延长的对话"，改成"项目资料加阶段对话"。
开发项目可以维护几份简单文档：
  • PROJECT.md 保存项目目标和技术栈。
  • DECISIONS.md 保存已经确认的重要决定。
  • CURRENT_TASK.md 保存当前任务、范围和验收标准。
  • HANDOFF.md 保存本阶段完成情况和下一步。
每次任务结束后，让 AI 生成一份简短交接：当前目标是什么、已经完成什么、修改了哪些内容、哪些决定已经确认、还有什么问题、下一步应该做什么、哪些限制必须保留。
随后开启新对话，只提供最新交接和当前需要的文件。这样做的好处是，每次对话只携带当前任务真正需要的信息。模型更容易抓住重点，旧内容也不会持续干扰新任务。

形成自己的 AI Workflow

可以把 AI 工作拆成四步。
第一步，先用普通聊天理清需求，再把任务范围写清楚。
第二步，根据复杂度选择推理、研究或 Agent。
第三步，执行时限制文件和输出范围。
第四步，阶段结束后生成交接摘要并开启新对话。
这套方法能够减少重复读取、无关扫描、反复试错和过长输出。
当工具分工、模式选择、Token 范围和上下文交接都明确之后，同样的订阅额度，能够完成的有效工作会多很多。