用Pi构建Pi

# 用 Pi 构建 Pi 来源：https://lucumr.pocoo.org/2026/5/24/pi-oss/ 写于 2026 年 5 月 24 日 Pi (https://pi.dev/) 现在是 Earendil 的一部分，但从重要意义上说，它仍然是 Mario (https://mariozechner.at/) 的项目。他与它的议题跟踪器相处的时间比我还长，接触开源项目中新形态代理（agent）流量的怪异之处也更久。这篇文章主要反映了我自己在跟踪器中花更多时间、使用 Pi 来开发 Pi、以及观察至今所学到的东西后的个人体验。 ## 垃圾议题（Slop Issues） 不出所料，我们正在使用 Pi 来构建 Pi。这听起来像是一个可爱的吃自家粮（dogfooding）的做法，但它确实帮助我们理解我们所做的事情。使用代理进行构建的一个有趣效果是，它稍微改变了议题跟踪器的角色。议题描述不仅仅是用户发给维护者的消息，因为我们也把它们用作 Pi 会话中提示（prompt）的输入。这可能是我交给我那个 clanker1 (https://lucumr.pocoo.org/2026/5/24/pi-oss/#fn-1) 的东西，然后说：“理解这个，复现它，检查代码，并提出修复方案。” 这意味着议题的形态以一种新的方式变得重要。一个糟糕的议题过去总是令人烦恼，但至少很多议题是模糊的。现在我们还要面对一类议题，它们 5% 是人类写的，95% 是 clanker 生成的，而且很大程度上是不准确的垃圾。一个包含看似合理但错误诊断的糟糕议题会额外增加工作量。 目前最令人沮丧的失败模式是，人们提交的议题不是用自己的话描述的。它们包含某个地方观察到的问题，但被扔进一个 clanker，然后 clanker 改写了它，搞得一团糟。通常，提示写得太差，以至于得出的结论往往不准确，但总是充满自信。结果就是对根本原因的完全猜测、虚假的最小复现、建议的实现策略、与相邻但经常是错误的代码的类比，以及一长串可能相关也可能不相关的错误类别。 这比没有诊断更糟糕。 我不想指出具体的议题，因为我真的不想说任何人的坏话，但这很令人沮丧。另一个令人沮丧的原因是，当我把那个议题交给 Pi 时，Pi 也会看到错误的诊断。它不会将议题正文视为谣言。它将其视为证据。它会愉快地沿着议题已经为它准备好的路径走下去，因为行文很自信，代码引用看起来也合理。我们使用一个自定义的斜杠命令叫做 `/is`，其中专门包含以下指令： > 不要相信议题中的分析。独立验证行为，并从代码和执行路径中得出自己的分析。 不幸的是，这并不能完全奏效，因为当人类首先把他们的议题扔进 clanker 的绞肉机时，他们的 clanker 几乎立即扩大了范围。原本非常狭窄、基于事实的 bug 观察，变成了一个充满假说的、范围大得多的东西。所以至少我个人越来越希望议题报告被浓缩为人类实际观察到的事实： 1. 我运行了这个命令。 2. 我期望发生这个。 3. 实际上发生了这个。 4. 这是确切的错误或日志。 这就够了。如果你用 LLM 来理解问题，那很好，也许把它作为后续评论留下。但议题和议题文本应该是你拥有的东西。如果你不知道根本原因，就直说。我也会操作 clanker，我宁愿自己做，也不愿用你的垃圾。如果你的复现是猜测，就说出来。如果唯一的硬事实是一个堆栈跟踪，给我堆栈跟踪，然后到此为止。 ## 垃圾产生垃圾 我们看到充满垃圾的议题，只是这些机器当前质量的结果。遗憾的是，它们在创建好的议题方面的失败，也延伸到了生成的很多代码。不是全部，但是很多代码。我一次又一次地发现它们把议题和实现过度工程化了。 如果你告诉它们“这个格式错误的会话日志导致读取器崩溃”，clanker 通常会增加一个宽容的读取器。然后它会添加一个回退，也许再添加一个迁移，然后是更多调试输出，然后是为所有这些添加测试。这些单独来看不一定都是错的，但对系统来说可能是错误的一步。 Pi 核心是一个设计相当良好的会话日志，具有必须得到维护的不变量。clanker 当前的行为就是假设不存在这样的不变量，而是让系统能够处理各种格式错误，在这个过程中把复杂性搞得一团糟。 几乎总是，正确的修复不是处理坏状态，而是让坏状态不可能出现。这对于持久化数据（如 Pi 会话日志）非常重要。它们会被打开、分支、压缩、导出、共享和分析。目标是永远不要写入坏的会话数据。然而，如果你只是让 clanker 自由发挥，它会试图用更宽松的读取器来处理会话日志中每一个坏数据的情况。 我已经对此抱怨了很多，但在 Pi 代码库上的工作不断强化这个观点。这是 LLM 编写的代码增长出那么多不必要的复杂性的方式之一。所有这些模型看到局部失败，就试图在局部进行防御。作为维护者，我们必须不断把对话拉回到全局不变量上，这比应该的更难，而且很费劲。 ## 数量才是问题 然后还有数量的问题。跟踪器收到了大量的议题和 PR，其中很大一部分明显是 LLM 辅助的。有些是好的，没有一个是优秀的，大多数只是糟糕的。总吞吐量本身就是一个维护问题。 你可能知道，Pi 的议题跟踪器是自动关闭所有新贡献者的议题和拉取请求的，我们会通过手动流程重新打开其中一些或批准个人。所以自动关闭 -> 重新打开 -> 再次关闭，对我们来说是一个值得观察的有趣统计。 我在写这篇文章时提取了过去 90 天公开的 GitHub 跟踪器数据。排除 Earendil 成员，剩下 3,145 个外部议题和拉取请求。其中 2,504 个被自动关闭，因为它们来自未经批准的个人。17% 被重新打开。对于拉取请求，数字更糟：不到 10% 被合并。 2026 年 2 月 24 日至 5 月 24 日期间，Pi 议题和拉取请求的每周外部数量和接受率（排除 Earendil 成员），重新打开的拉取请求在其后被合并时显示。 许多议题和 PR 完全是垃圾，在某些情况下，人类甚至没有意识到他们创建了这些。低质量垃圾的来源包括 OpenClaw 实例，以及人们放到上下文中某些似乎鼓励创建议题的技能。 GitHub 显然没有准备好应对这种新形态的开源，但我越来越觉得，与其责备 GitHub，不如责备所有那些让这种体验变得痛苦的参与者。如果你的 clanker 在别人的议题跟踪器上拉了一堆屎，那并不是 GitHub 的错，只是你一个人的错。 ## 谨慎的并行处理 Pi 可能是用 Pi 构建的，但我们现在距离 Bun 和 OpenClaw 已经达到的水平还很远：完全分离、自动化的软件工程。也许我们会达到那个点，我不知道。今天看来，我们似乎还不知道如何实现一个暗工厂（dark factory），我们也没有这个愿望。话虽如此，还是有相当多的并行处理在使用，主要是用来复现问题。 我们为此使用的小配置是三个小片段，放在 Pi 自己提交的 `.pi` (https://github.com/earendil-works/pi/tree/main/.pi) 文件夹中。`/is`（用于分析**is**sue）是一个分析 GitHub 议题的提示：它标记并分配议题，读取整个线程和链接，然后明确告诉代理不要相信议题中的分析，要从代码中得出自己的诊断。然后一个扩展添加了一个 `prompt-url-widget`，它在代理开始之前监视提示，识别出 `/is`（或 PR 的等价物）放入提示中的 GitHub 议题或 PR URL，用 `gh` 获取标题和作者，在一个小 UI 小部件中渲染，并重命名会话。它还会在会话开始或切换时重建该状态，所以如果我们重新打开一个较旧的调查，窗口仍然会告诉开发者它属于哪个议题。 在实践中，这意味着可以打开多个 Pi 窗口，每个窗口针对不同的议题运行 `/is`，UI 保持调查在视觉上可区分，同时代理独立进行复现和代码阅读。调查完成后，可以依次处理它们。为了完成所有工作，`/wr`（**wr**ap it up）是匹配的总结提示：它会从会话中推断出 GitHub 上下文，更新变更日志，起草或发布带有免责声明的最终议题评论，仅提交在该会话中更改的文件，当只有一个议题时添加适当的 `closes #...`，并从 `main` 推送。 Pi 终端会话显示一个代理分析，带有一个 GitHub 议题小部件显示议题标题、作者和 URL。 ## 开源是关于值得修复的难题 你可能已经注意到了，但在后 AI 世界中的开源正面临一种奇怪的新压力。我们得到了更多的代码、更多的项目和更多的议题。项目没有真正的用户，或者只有一时的受众，即使拥有数千颗星的项目也可能只有短短几周的寿命。 对我们来说，Pi 的套接层值得仔细维护，因为它解决了困难的协调问题，并创建了一个我们可以和他人共同构建的平台。我们也知道协调与合作让我们所有人都得到提升。很多时候，正确的答案不是在局部解决一个问题，而是让上游行为正确。Mario 非常擅长拒绝让 Pi 掩盖每个配置错误的网关，我们正试图保持这种纪律。当网关行为正确时，每个人都受益。 可悲的是，这种思维方式正在迅速消失，因为这些机器使得局部变通变得廉价，所以代码积累了对每一种错误行为的局部防御。不再是人与人交谈确定修复属于哪里，而是一个人和一台机器孤立地绕过问题。 请记住，AI 并没有增加需要软件的人数，也没有增加可以审查软件的维护者数量。它主要增加了代码量和争夺注意力的项目数量。其中一些是健康的，但很多则分散了本应共享的努力。 我们需要更强的基础，而不是更弱的基础。开源需要更多的协作，而不是更多的与机器孤立的工作。人类交流很困难，当你可以独自与你的 clanker 坐在一起时，很容易避免交流。但孤立并不是开源价值的来源。价值在于社区和结构，让项目能够比其原始创作者活得更久。 本文被标记为 ai (https://lucumr.pocoo.org/tags/ai/)、open-source (https://lucumr.pocoo.org/tags/open-source/) 和 pi (https://lucumr.pocoo.org/tags/pi/) 复制为 (https://lucumr.pocoo.org/2026/5/24/pi-oss.md) / 查看 (https://lucumr.pocoo.org/2026/5/24/pi-oss.md) markdown