削减AI工作流Token成本80%

【这是什么】 这是一套针对 Claude Code 动态工作流的降本方案。原作者发现，每次让 LLM 为工作流动态生成代理提示词并编排执行，会消耗大量 token。他们从 ~/.claude/projects 中积累了数周的执行记录，让 Claude 分析这些日志，结果发现看似复杂的工作流实际只由 3 种步骤反复拼装而成：

• 实现者/worker：从计划中领取任务，在指定文件边界内写代码与测试；
• 检查门控/gate：基于 git 变更判断需要跑哪些测试；
• 最终发布检查：部署到暂存环境并运行完整验证。

作者随后将这些临时拼装方式固化为标准代理 workflow-worker 和 workflow-gate，把“跑什么测试”的决策逻辑搬进 Makefile，再让 Claude 编写一个能读取计划文件并直接生成工作流 JavaScript 的工具。最终 token 成本降为原来的约 20%，工作流运行时间从 5-6 小时缩短到 20-40 分钟。

本质上是把“用 AI 即时编排 AI”改成“先用 AI 沉淀经验，再用代码编排 AI”。所有不再需要 LLM 临时发挥的部分，全部被静态化、脚本化。

【背景 / 谁做的】 原始帖子来自 Hacker News，描述语气为“我们”，说明作者至少是一个小团队或拥有多会话工作流的重度 Claude Code 用户。他们具备 git tree、Makefile、测试套件等成熟的工程基础设施，也熟悉 Claude Code 的磁盘日志目录和 agent 配置格式。

同一时间段，Hacker News 相关帖子中出现了方向相似的项目：

• Agent-compiler：面向重复工作流的脚本化方案，声称可减少 60-80% 工具调用；
• Argus for Claude Code：声称可用 80% 更少 token 运行重复 AI 工作流。

这些独立案例指向同一个结论：大量开发团队正在共同经历 Claude Code 动态工作流的成本失控，而答案不是更好的 prompt，而是把工作流本身编译成确定性代码。

【怎么获客】 这条帖子本身就是一个获客实验。若将它产品化，可复用的获客路径有：

• 在 Hacker News、X、Reddit 的开发者社区发布“削减 80% token”类实测贴，以具体数字建立信任；
• 将标准代理模板和工作流生成器做成开源仓库，让开发者通过 GitHub 发现并试用；
• 与 Claude Code 的 CLI/插件生态绑定，通过 claude/agents 目录直接安装，降低接入摩擦；
• 面向已经为 AI 编程付高额 token 费的团队，提供“工作流优化审计”服务，把本案例作为售前素材；
• 对于一人公司，可将整个方案打包成技术服务，交付“静态代理 + Makefile + 生成器”的定制工作流。

开发者工具的早期用户通常集中在 HN、Discord、GitHub 和 X，这类“省钱 + 加速”的信息传播能力很强，天然适配社区驱动增长。

【验证情况 / MRR】 原帖没有披露 MRR，也未声称是商业产品。它提供的验证数据非常具体：

• token 花销降为原来的约 20%；
• 工作流运行时间从 5-6 小时降至 20-40 分钟；
• 复杂计划的 JavaScript 工作流生成从 10 分钟降为 1 秒；
• 作者让 Claude 分析过去数周日志后，确认所有动态工作流只由少数几种步骤组合而成。

同类项目 Agent-compiler、Argus for Claude Code 也给出了相近的效果区间，比如“60-80% 更少工具调用”和“80% 更少 token”。这构成相互印证。目前这些项目更多处于技术验证和展示阶段，公开可见的收入数据并不存在。这个赛道的“MRR”可能仍为零，但用户痛点已经清晰，且解决方案的门槛正在快速降低。

【对一人公司的可复制性】 对一人公司而言，这套方法最值得复制的不是具体代码，而是“让 AI 自己帮自己省 token”的路径：

1. 收集历史执行日志：Claude Code 会在 ~/.claude/projects 保存每次会话，这是现成的分析语料；
2. 让 Claude 自己总结反复出现的工作流模式，找到可沉淀的公因子；
3. 把公因子写成标准 Markdown 代理，放入 ./claude/agents，避免每次由 LLM 重新写提示词；
4. 将测试编排基于 git 变更移入 Makefile，例如“www 文件变了就跑 Web 测试，后端变了就跑 API 测试”；
5. 写一个计划文件读取器，直接生成工作流 JavaScript，由 Claude 自己完成代码实现；
6. 利用命名代理的权限钩子，限制 worker 不能跑整个测试套件、不能 make、不能碰他人文件。

这种方法不需要大型研发团队。一人公司如果已经在用 Claude Code 做并行开发，采用后可以直接让单次复杂工作流的成本从几十美元降到几美元，运行时间从数小时压缩到半小时内。低成本后，AI 并行 worker 才能真正进入个人预算范围。

更重要的是，生成出的 Makefile 测试门和工作流脚本并不依赖 AI 存在。社区讨论中有人指出，即使 AI 明天全部停用，他们为 SCSS、HTML、Liquid、YAML 构建的自定义 eslint 规则仍然对团队有巨大价值。同理，这套优化沉淀下来的静态验证基础设施，本身就是长期可用的资产。

【风险与机会】 风险：

• 静态代理会减少 LLM 的自由度，如果任务边界本身划分错误，worker 之间仍可能出现文件冲突；
• 过度依赖 Claude Code 内部实现，如 ~/.claude/projects 格式、agent 定义规范和 hook 签名，上游一旦调整就需要重新适配；
• 权限控制是双刃剑，过于严格的 worker 可能频繁卡住并被迫等待 gate 检查，如果 gate 不够高效，整体吞吐仍会下降；
• 作者能成功，是因为业务最终被抽象成“实现 + 门控 + 发布”三种模式；如果你的工作流没有清晰的可复用模式，这种思路需要先做大量流程整理，不能直接套用。

机会：

• 当前就是 Claude Code 工作流编译器的窗口期。可以将“计划文件 → 工作流 JS → Makefile 门控 → 标准代理”打包成一套通用工具，做成类似 Agent-compiler 的开源产品，再通过企业级部署和私有化支持收费；
• 可以做成“token 成本优化器”，自动扫描用户本地历史日志，生成静态工作流模板，让用户直观看到省下的费用；
• 可以让这套方法论进入“AI 工程咨询”领域，帮助中型团队削减 AI agent 使用成本，以这次 80% 的量化结果作为主打案例；
• 长期看，Claude Code 只是第一个宿主。未来大量 agent 平台都需要把重复动态编排沉淀为静态资产，掌握这套工作流抽象能力的人，可以把同一方法论复制到更多 AI coding agent 上。

这个帖子最有价值的信号，不是“80%”这个数字，而是它再次证明：AI 工作流一旦开始规模化，最高杠杆不是写更多提示词，而是把已经确定的部分写成代码。

信息来源：Hacker News