开发者因Claude Code问题频发转向Pi

当然，你也可以直接使用官方的 Claude Code VSCode GUI 扩展，它确实支持打开多个标签页，并把选中的文本加载到每个标签页的上下文中。但这个扩展本身也有不少问题。内置的斜杠命令有一半在 GUI 里根本用不了。它完全不支持自定义状态栏。子代理的输出消息只是按时间顺序堆叠进主聊天线程，同时运行多个子代理时读起来一团糟。我还能继续列下去。

尽管已经存在这么多问题，Anthropic 似乎仍在以狂热的速度往 Claude Code 里塞功能，而不太在意质量和稳定性。动态工作流、代理团队、ultrareviews——这些对企业客户来说都是每天烧掉更多 token 的好办法，但并不是我真正想要或需要的东西。

伴随着这些功能发布，他们似乎总是在调整一些东西，把我的个人配置搞乱。截至本文写作时，Claude Code 今年已经发布了 244 个版本；其中超过四分之三的版本改动了系统提示或工具描述，这会显著改变 LLM 的表现（尤其是当这些新指令与用户提示或仓库约定相冲突时）。

而所有这些改动是为了什么？尽管砍掉了 80% 的系统提示，Claude Code 的开销仍然远高于 Pi，而且似乎没有任何好处。默认 Bash 工具的描述接近 3,000 个 token，其中大部分是关于使用 git 和在 GitHub 上开 PR 的杂七杂八内容。2 顺便说一句，模型本来就知道怎么做这些事，不需要详细指令。3

这篇文章充满了抱怨。抱歉！这不是我一贯的风格，我确实认为 Anthropic 在这里做出了一款很酷的软件。我也并不妄想，如果我一开始就负责 Claude Code，我能做得更好。LLM 编码工具链是一个非常新的领域，成为某个领域的第一批创新者是一件非常困难的事。像 Pi 这样的后来者拥有后见之明，能看清什么行得通、什么行不通，什么是核心功能、什么可以砍掉。

归根结底，CC 感觉像是一款没有强烈愿景或方向的产品。就好像一群兴奋的工程师和 PM 在快速堆上适合他们自己工作流的功能……却不考虑这可能会让其他用户的情况变得更糟。似乎没有一个高层的人专门负责对这些请求说“不”，而这在产品工程中极其重要。所以，暂时来说，我走了。

我很期待更多地投入 Pi。头几天需要一些摸索，但之后就一直很顺利。我喜欢它的稳定性、极简风格以及极高的可定制性。我已经写了几个扩展来支持我的使用场景，希望整理一下之后尽快分享出来。如果你也有这些困扰，我强烈建议试试开源工具链！

这也不是说有什么巨大的技术障碍。安装 Pi 之后，我写了一个扩展来处理多个打开标签页中的这个功能，大概只用了 20 分钟。（返回）

额外加分的是，它指示模型使用 cat <<'EOF'，这（在自动模式广泛推出之前）总是会触发人工审查规则，不管已有的 git 命令允许列表如何。（返回）

如果你假设有 100 万 DAU 和每天 1 亿次请求，从这里削减 1,000 个 token，每年光推理成本就能省下数百万美元。这总该值得某个工程师花点时间吧？？（返回）