反思一下为什么我的开源项目没有做好

（重新编辑）

感谢楼上的反馈。原文是我直接写的，但表达确实比较仓促，很多中英文术语混在一起，读起来不够顺畅。下面重新整理一次，核心问题不变：如何在坚持评测严谨性的同时，更有效地传播一个开源项目。

利益披露：我是 Tura 的维护者。这篇帖子不是以第三方身份评价自己的项目，而是希望就开源项目的传播方式和评测方法获得坦率的建议。

从 2026 年初开始，RTK 、Caveman 和 Ponytail 等项目声称可以减少 80%～ 90% 的 Token 使用量。其中一些项目在很短的时间内获得了数万 GitHub Star 。

我之前的创业项目在做电商聊天机器人。事实上，它和后来发布的 Universal Commerce Protocol （ UCP ）几乎相同。UCP 发布后，我决定不再继续这个方向。

今年年初，我开始把我们为电商聊天机器人 Agent 构建的架构改造成 SDK 。简单来说，它的核心思路是使用状态机和确定性的执行序列，在完成同一任务时，将与 LLM 服务商之间的往返次数减少约 80%，从而显著降低 Token 消耗。

我非常清楚 RTK 之类的工具为什么在真正的长时间任务中不起作用。我在 7 月 18 日发布了一份报告，JetBrains 在 7 月 20 日发布的报告得出了基本相同的结论：RTK 和 Caveman 这类 Token 节省插件，在真实的长时间任务中几乎没有效果。

- JetBrains 报告： https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/
- 我的报告及可复现方法： https://github.com/Tura-AI/tura/blob/main/docs/blog/token-saving-plugins-are-mostly-stupid-idea.md

我也认为自己知道如何在长时间任务中真正实现超过 80% 的 Token 降低。然而，我发现宣传这个开源项目比构建它困难得多。

## 我认为问题出在哪里

### 大多数编程 Agent 用户并不关心是什么真正导致了 Token 消耗

无论是接受过正式软件工程训练的开发者，还是自学的“氛围编程者”，编程 Agent 用户之间都存在巨大的认知差距。

一篇系统解释运行机制、并挑战既有假设的长文章，在已经充斥着 AI 生成文章和“节省 95% Token”插件的论坛里，很难得到传播。

简单的观点更容易传播。人并非完全理性，通常更愿意相信容易理解的解释。这或许也是为什么建立在错误因果关系上的伪科学内容，往往比认真解释数学原理的内容获得更多关注。

### 作者本人的傲慢

这可能是两个问题的结合。

对于一个非常相信科学测试、评测和基准测试的人来说，没有评测支持的软件工程主张可能毫无意义。

但也许正是我自己的傲慢，以及我对 RTK 等工具的轻视，甚至嫉妒，让我不愿意用真正有效的方式介绍和推广自己的工作。

如果你读到了这里，我真诚地希望得到你的建议：

- 如何在不牺牲严格评测和基准测试的前提下，更有效地介绍这个项目？
- 什么样的证据会让你愿意尝试一个不知名的编程 Agent SDK ？
- 目前的表达是否过于技术化、过于攻击性，或者选错了目标受众？
- 我应该如何修改仓库首页或基准测试的展示方式？

我知道，使用 Codex 或 Claude 构建一个编程 Agent 并不算特别困难。但我也相信，总会有人理解基准测试和评测框架的价值。

项目于 7 月 16 日发布，目前有 400 多个 GitHub Star：

https://github.com/Tura-AI/tura

欢迎批评，包括你不会使用它的原因。