返回 文章 apply CMS 文章

从 Claude Code 迁移到 Pi：一位长期用户的告别与反思

一位资深用户告别 Claude Code、转向开源工具 Pi 的迁移理由与产品反思。

Hacker News
Claude CodePiAI 编码工具开发者体验
成长分 / 100 58 综合收获、行动、留存与影响

为什么值得读了解一位长期 Claude Code 用户从喜爱到放弃的真实决策过程与具体痛点。

从产品工程视角反思 AI 编码工具在功能扩张与稳定性之间的取舍。

关键洞察
  1. 作者因 AGENTS.md 支持滞后、VSCode 多会话集成缺陷等积累的小挫折而决定迁移。
  2. Claude Code 今年发布 244 个版本，其中超过四分之三改动了系统提示词或工具描述，可能显著影响模型表现。
  3. 作者认为 Claude Code 功能不断堆叠（动态工作流、agent teams、ultrareviews），更像服务企业消耗 token，而非解决个人需求。
转成行动

深入阅读

正文与原文对照

原文保真覆盖：全文原文字符：7672

再见 Claude，你好 Pi

2026 年 9 月 21 日 #pi #claude

自从一年多前 Claude Code 在 Claude Pro 订阅计划中推出以来，我一直是它的长期用户。我还记得第一次使用它时的情景：我只用一条提示词，它就能为我当时随便做的某个周末项目吐出一堆凌乱的 Python 代码，那种感觉让我兴奋不已。我确信，几年之后我们回望它的发布，都会把它视为我们所处的这个软件开发新时代的主要推动力之一。

尽管如此，由于许多小挫折不断累积，我最终还是决定不再把它作为我的主要编码工具，并将我的开发环境迁移到 Pi。

Anthropic 的某个人一定听到了风声……就在我做出决定的第二天，他们宣布 Claude Code 终于开始支持 AGENTS.md 文件，想以此让我留下来。不幸的是，对我来说这来得太少、太晚。

抱怨

既然没有一篇正式的讣告，我想借此机会说几句我最不喜欢 Claude Code 的地方（以及因此我期待用 Pi 避开的东西）。

AGENTS.md 这件事某种程度上正是我决定不再使用 Claude Code 的全部原因。别误会，把大量 CLAUDE.md 文件散落在各种 GitHub 业余项目仓库里是很棒的游击营销。但对用户来说，不得不在两种格式之间复制或建立符号链接，实在很糟糕。

像我这样的卢德分子，仍然倾向于在提交之前审阅它生成的大部分代码。我（过去）在 VSCode 里使用 Claude Code，它允许你把该工具连接到 IDE。这很不错，因为你可以高亮文件中的文本，并在审阅过程中提问或请求修改时，让它自动纳入上下文。

只不过同一时间只能有一个会话“连接”到 IDE。如果你在第一个会话工作的同时打开第二个标签页开始另一项任务，它根本无法接收来自 IDE 的文本选择事件。这个问题至少早在 2025 年 12 月 就有人报告过……却被当作一个完全不相关的 bug 的重复项关闭了。1

VSCode 中的 claude code 显示断开连接错误

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

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

伴随所有这些功能发布，他们似乎总是在以打乱我个人配置的方式折腾各种东西。截至撰写本文时，Claude Code 今年已发布了 244 个版本；其中超过 3/4 的版本更改了系统提示词或工具描述，这会显著改变 LLM 的表现（尤其是当这些新指令与用户提示词或仓库约定相矛盾时）。

而所有这些更改都是为了什么？尽管砍掉了 80% 的系统提示词，Claude Code 的开销仍然比 Pi 大得多，而且似乎毫无益处。默认 Bash 工具的描述接近 3,000 个 token，其中大部分是关于使用 git 和在 GitHub 上开 PR 的杂七杂八的内容。2 顺便说一句，模型本来就知道如何在没有详细指令的情况下做到这些。3

展望未来

这篇文章有很多抱怨。抱歉！这不是我一贯的风格，而且我确实认为 Anthropic 在这里做出了一款非常酷的软件。我也并不妄想，如果从一开始就由我来负责运营 Claude Code，我会做得更好。LLM 编码工具是一个非常新的领域，在一个领域里率先创新是一项非常艰难的任务。像 Pi 这样的后来工具拥有后见之明，能看清什么有效、什么无效，什么是核心功能、什么可以砍掉。

归根结底，CC 感觉像是一个没有强烈愿景或方向的产品。就好像一群兴奋的工程师和 PM 在迅速地把任何适合他们工作流的功能加上去……却不考虑这可能会让其他用户的处境变得更糟。似乎没有一个高层人士的职责是严格对这些请求说“不”，而这在产品工程中极其重要。所以，就目前而言，我要离开了。

我很期待更多地使用 Pi。头几天需要一些摸索，但自那以后就一帆风顺了。我很享受它的稳定性、极简风格以及极高的可定制性。我已经写了几个扩展来支持我的使用场景，希望在我稍作整理后不久就能分享出来。如果你也有这些挫败感，我强烈建议你试试开源工具！

  1. 这也不是说存在什么巨大的技术障碍。安装 Pi 之后，我花了大约 20 分钟就写了一个扩展，在多个打开的标签页之间处理这个功能。（返回）
  2. 额外加分的是，它指示模型使用 cat <<'EOF'，而（在 auto 模式广泛推出之前）无论现有的 git 命令允许列表如何，这总是会触发人工审核规则。（返回）
  3. 如果你假设有 100 万日活用户和每天 1 亿次请求，从这里削减 1,000 个 token，每年就能在推理成本上实实在在地省下数百万美元。这肯定值得某位工程师花点时间吧？？（返回）

感谢阅读！

我很喜欢听大家的想法，所以请随时给我发邮件至 calebdotsoftware@gmail.com。如果你想在我发布新文章时收到更新，可以通过邮件或RSS订阅。

如果你想评论或阅读关于这篇文章的公开讨论，我已将其分享到以下网站：Twitter、Mastodon、Bluesky

创建于 2026 年 9 月 21 日 · 更新于 2026 年 11 月 7 日 · 构建 2f1e49