反思一下为什么我的开源项目没有做好，业内人士怎么看？

其实这个事情最开始是 26 年开始有很多号称可以节省 80%-90%token 的项目出来了，比如 RTK, caveman, ponytail.他们都声称可以节约大量的 token ，而且短期获得了几万的 github 收藏。

我之前的创业项目是做面向 e-commerce 的 chatbog ，其实是和 Universal Commerce Protocol (UCP) 一摸一样的一个产品，也是因为 UCP 的发布我没有再继续做这个赛道。

今年早些时候，我就想把我们之前搭建 e-commerce chatbot agent 的架构做成 sdk 。

简单说这个架构的核心是通过状态机和执行序列把同样任务中 llm 的 provider call 的往返次数减少 80%来降低同样规模的 token 消耗。

现在的问题是这样的，我很清楚为什么 RTK 这类工具在真正的长任务中是完全无效的。

我 18 号发布的报告，和 jetbrain 20 号发布的报告基本是同样的观察结果，RTK caveman 这类节省 toekn 的插件在真实长任务中毫无作用： https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/ https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea 我很清楚如何真正做到长任务中 80%+ 的 token 消耗减少。

但问题是我在推广我的开源项目中遇到了非常大的困难。

我把主要问题总结为 3 点： 大多数 coding agent 用户，不论是有系统编程技能培训或是没有的所有 vibe coder 其实对真正的 token 消耗的原理理解差异很大。

一个系统的讲解具体流程，并且挑战认知的长文章会在这个充满 ai 写作和 vibe coding 写出来的无数可以号称减少 95%token 使用的插件的论坛中显得愚蠢和天然没有传播性。

简单的才易传播，人不是理性动物，只会相信自己更容易理解的事务。

这就是为什么所有社交媒体上错误归因的伪科学永远比讲数学原理的频道有更高的关注度。

作者的傲慢。

这其实是两个问题的结合，在一个相信科学测试方法和 eval 科学的作者眼中。

没有 eval 和 benchmark 的软件工程是无意义的。

但事实是可能是作者自己的傲慢和对 rtk 这类工具的鄙视甚至是嫉妒造成了他更不愿意用更有效的方式传播他的作品。

如果大家有时间看到这，可以给我提一些意见，告诉我如何才能在尊重 eval 和 benchmark 严谨性的同时更好的推广我的产品。

我知道用 codex 或者 claude 写一个 coding agent 很简单，但我也相信，总会有人理解 benchmark 和 eval harness 的价值。

🔗 原始来源

如果你要核对细节，可以再看原文： V2EX原文链接