Building Pi With Pi, written on May 24, 2026. Pi is now part of Earendil, but in the important sense it is still Mario's project. He has been living with its issue tracker longer than I have, and he has been exposed to the weirdness of the new form of agent traffic in Open Source projects for longer too. This post is mostly a reflection of my own experience after spending more time in the tracker, using Pi to work on Pi, and watching what I have learned about it so far.
《用 Pi 造 Pi》，2026 年 5 月 24 日。Pi 现在归了 Earendil，但从最重要的意义上说，它仍然是 Mario 的项目。他泡在这个项目的 issue tracker 里的时间比我长，接触「agent 流量」这种开源新形态的怪异之处也更久。这篇主要是我自己的一点经验复盘：在 tracker 里泡了更多时间之后、用 Pi 开发 Pi 的过程中，我到目前为止学到的东西。
Slop Issues · Slop Issue
Unsurprisingly, we are using Pi to build Pi. That sounds like a cute dogfooding thing but it really helps understand what we do. An interesting effect of building with agents is that it changes the role of the issue tracker a tiny bit. The issue descriptions are not just messages from a user to a maintainer because we also use them as inputs for prompts in Pi sessions. It is something I might hand to my clanker and say: "understand this, reproduce it, inspect the code, and propose a fix."
毫无悬念，我们在用 Pi 造 Pi。这听着像个可爱的 dogfooding 段子，但它确实帮我们理解自己在做什么。用 agent 开发有个有趣的副作用：它微妙地改变了 issue tracker 的角色。issue 描述不再只是「用户发给维护者的消息」——我们同时把它当作 Pi session 里 prompt 的输入。我会把它丢给我的 clanker，说：「理解这个问题，复现它，读代码，提出修复。」
That means the shape of the issue matters in a new way. A bad issue was always annoying, but at least a lot of issues were vague. Now we are also dealing with a class of issues that are 5% human and 95% clanker-generated and largely inaccurate shit. A bad issue that contains a plausible but wrong diagnosis creates extra work.
这意味着 issue 的「形状」以一种新的方式变得重要。烂 issue 向来烦人，但至少很多 issue 只是含糊。现在我们要面对一类新的 issue：5% 是人写的，95% 是 clanker 生成的，且大半是不准确的垃圾。一个包含「看似合理但错误诊断」的烂 issue，会制造额外的工作量。
The most frustrating failure mode right now is that people submit issues that are not in their own voice. They contain an observed problem somewhere, but it has been thrown into a clanker and the clanker reworded it and made a huge mess of it. Typically, it was prompted so badly that the conclusions produced are more often than not inaccurate but always full of confidence. The result is complete guesswork on root causes, fake-minimal repros, suggested implementation strategies, analogies to adjacent but often the wrong code, and long lists of error classes that might or might not matter.
现在最让人沮丧的失败模式是：人们提交的 issue 根本不是他们自己的声音。里面确实有个观察到的现象，但它被丢进 clanker 过了一遍，clanker 改写了它，搞得一团糟。典型情况是 prompt 写得太烂，产出的结论多半不准确，却永远满怀自信。结果就是：对根因的纯粹瞎猜、装作最小实为猜出来的复现步骤、想当然的实现策略建议、对相邻但往往不对的代码的类比，还有一长串可能有关也可能无关的错误类型清单。
That is worse than no diagnosis.
这比没有诊断更糟。
I don't want to point to specific issues because I really do not want to bad mouth anyone, but it is frustrating. It is also frustrating because when I give that issue to Pi, Pi sees the wrong diagnosis too. It does not treat the issue body as a rumor. It treats it as evidence. It will happily go down the path that the issue already prepared for it, because the prose is confident and the code references look plausible. We use a custom slash command called /is, which specifically has this instruction in it:
我不想点名具体的 issue——我完全不想说任何人坏话——但这确实让人沮丧。更沮丧的是：当我把这个 issue 交给 Pi 时，Pi 看到的也是那个错误诊断。**它不会把 issue 正文当流言，它把它当证据。**它会高高兴兴地沿着 issue 铺好的路走下去，因为那些文字充满自信、代码引用看起来头头是道。我们用一个叫 /is 的自定义斜杠命令，里面专门写了这条指令：
Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path.
不要相信 issue 里写的分析。独立验证行为，从代码和执行路径推导你自己的分析。
Unfortunately, it does not fully work, because when humans first throw their issue through the clanker wringer, their clanker expands scope almost immediately. What was once a very narrow and fact based bug observation, turns into a much expanded surface area full of hypotheses. So at least personally, I increasingly want issue reports to be condensed to what the human actually observed:
遗憾的是它不能完全起效——因为人先把 issue 丢进 clanker 绞一遍时，clanker 几乎立刻就开始扩范围。原本一个很窄的、基于事实的 bug 观察，变成一个铺满假设的大表面。所以至少就我个人而言，我越来越希望 issue 报告压缩成人真正观察到的东西：
I ran this command. I expected this to happen. This happened instead. Here is the exact error or log.
我跑了这条命令。我预期发生这个。实际发生了那个。这是原始报错或日志。
That is enough. If you used an LLM to understand the problem, great, maybe leave it as a follow-up comment. But the issue and the issue text should be something you own. If you do not know the root cause, say that. I too can operate a clanker, and I would rather do this myself than use your slop. If your repro is a guess, say that. If the only hard fact is one stack trace, give me the stack trace and stop there.
这就够了。如果你用 LLM 理解了这个问题，很好，也许可以放在后续评论里。但 issue 和 issue 正文应该是你自己拥有的东西。不知道根因就直说。我也会开 clanker，我宁可自己开也不想用你的 slop。复现步骤是猜的就说是猜的。如果唯一的硬事实是一条堆栈，那就给我堆栈，到此为止。
Slop Begets Slop · Slop 生 Slop
That we're seeing issues full of slop is just a result of the present day quality of these machines. Sadly, their failures in creating good issues extend to a lot of code that is generated. Not all of it, but a lot of code. Over and over I keep running into them over-engineering the hell out of issues and implementations.
issue 里满是 slop，只是这些机器当下质量的一个缩影。遗憾的是，它们在「产出好 issue」上的失败，同样延伸到了大量生成的代码上。不是全部，但很多。我一遍又一遍地撞见它们把 issue 和实现过度工程到天怒人怨。
If you tell them that "this malformed session log crashes the reader," the clanker will often add a tolerant reader. Then it will add a fallback, then maybe a migration, then more debug output, then a test for all of this. None of this is necessarily wrong in isolation, but it can be the wrong move for the system.
如果你告诉它「这段损坏的 session log 会让 reader 崩溃」，clanker 往往会加一个宽容的 reader。然后加一个 fallback，然后也许一个迁移，然后更多调试输出，然后给这一切补上测试。单拎出来每一步都未必错，但对这个系统来说可能是完全错误的一步棋。
At Pi's core is a rather well-designed session log with invariants that must be upheld. The clanker's present-day behavior is to just assume that no such invariants exist, and instead to make the system work with all kinds of malformedness, blowing up the complexity in the process.
Pi 的核心是一个设计得相当讲究的 session log，带有必须维持的不变量。而 clanker 如今的行为就是假定这些不变量根本不存在，转而让系统去兼容各种各样的畸形数据，把复杂度在这个过程中炸上天。
Almost always, the correct fix is not to handle the bad state, but to make the bad state impossible. This matters a lot for persisted data such as Pi session logs. They are opened, branched, compacted, exported, shared, and analyzed. The goal here is to never write bad session data. Yet if you just let the clanker roam freely, it will attempt to handle every case of bad data in the session log with a more permissive reader.
几乎总是如此：正确的修复不是去处理坏状态，而是让坏状态不可能发生。这对 Pi session log 这样的持久化数据至关重要。它们会被打开、分支、压缩、导出、共享、分析。这里的目标是永远不写入坏数据。可你只要放任 clanker 自由发挥，它就会试图用一个更宽容的 reader 去接住 session log 里每一种坏数据。
I have complained about this plenty, but working on Pi's code base continues to reinforce the point. This is one of the ways LLM authored code grows so much needless complexity. All these models see a local failure and try to locally defend against it. As maintainers we have to keep pulling the conversation back to the global invariant, which is harder than it should be, and it's laborious.
这点我抱怨过很多次，但在 Pi 的代码库上干活只会不断强化它。这正是 LLM 写的代码长出那么多无谓复杂度的路径之一：所有这些模型看见一个局部失败，就试图就地防御它。作为维护者，我们得不断把对话拽回全局不变量——这比它本该有的难度要高，而且十分费劲。
Volume Is The Problem · 总量本身就是问题
Then there is the issue of volume. The tracker is receiving a lot of issues and PRs, and a significant fraction of them are clearly LLM-assisted. Some are good, none are excellent, and most are just bad. The total throughput is a maintenance problem by itself.
然后是总量问题。tracker 收到的 issue 和 PR 很多，其中相当大一部分明显是 LLM 辅助的。有些不错，没有出色的，大多数就是烂。**总吞吐量本身就是一个维护问题。**
As you might know, Pi's issue tracker is automated to close all issues and pull requests from new contributors, and there is a manual process by which we might reopen some of them or approve individuals. So auto-close -> reopen -> close again is an interesting statistic for us to look at.
你可能知道，Pi 的 issue tracker 配了自动化：新贡献者的所有 issue 和 PR 一律自动关闭，另有人工流程可以重开其中一些、或把某些人加入白名单。所以「自动关闭→重开→再关闭」这组统计对我们来说很有看头。
I pulled the public GitHub tracker data while writing this over the last 90 days. Excluding Earendil members, that leaves 3,145 external issues and pull requests. Of those, 2,504 were auto-closed because they were from non-approved individuals. 17% were re-opened but that somewhat undercounts issues, because some remain closed while we still fix them. If we also count issues referenced by a main-branch commit or merged pull request that number rises to 26%. For pull requests the number is worse: 60 of 714 auto-closed PRs were ultimately merged, or about 8%.
写这篇时我拉了公开的 GitHub tracker 数据，取最近 90 天。剔除 Earendil 成员后，共 3,145 个外部 issue 和 PR。其中 2,504 个因来自未白名单的个人而被自动关闭。17% 被重新打开——但这个数对 issue 略有低估，因为有些我们仍在修、但还没重开。如果也算上被 main 分支提交或已合并 PR 引用的 issue，比例升到 26%。PR 更惨：714 个被自动关闭的 PR 里，最终合入的只有 60 个，约 8%。
Many of the issues and PRs are complete slop and in some cases the humans did not even realize that they created them. Sources of low-quality spam include OpenClaw instances, as well as some skills that people put into their context that seemingly encourage issue creation.
很多 issue 和 PR 是彻底的 slop，有些情况下人甚至没意识到自己创建过它们。低质垃圾的来源包括 OpenClaw 实例，以及人们塞进上下文的某些 skills——它们看起来在鼓励创建 issue。
GitHub clearly is not built to deal with this new form of Open Source, but I'm increasingly feeling the need to put the blame less on GitHub than on all the people involved who make that experience painful. If your clanker shits on someone else's issue tracker then it's not the fault of GitHub, it's yours alone.
GitHub 显然不是为这种开源新形态设计的，但我越来越觉得，与其怪 GitHub，不如怪那些把这段体验搞得如此痛苦的当事人。**你的 clanker 在别人的 issue tracker 上拉屎，那不是 GitHub 的错，是你一个人的错。**
Careful Parallelism · 小心的并行
Pi might be built with Pi, but we're quite far off today from where Bun and OpenClaw already are: fully detached, automated software engineering. Maybe we will reach that point, I don't know. Today it does not seem like we know how to pull off a dark factory and we also don't yet have the desire. That said, there is quite a bit of parallelism going on, and it is mostly for reproducing issues.
Pi 也许是用 Pi 造的，但我们今天离 Bun 和 OpenClaw 已经到达的地方——完全脱离人的自动化软件工程——还相当远。也许我们会到那一步，我不知道。至少今天，我们似乎还不知道怎么造出黑灯工厂，而且也还没有那个欲望。话虽如此，并行的量并不小——主要用于复现 issue。
The small setup we use for this is three tiny pieces in Pi's own committed .pi folder. /is (for analyze issue) is a prompt for analyzing GitHub issues: it labels and assigns the issue, reads the full thread and links, then explicitly tells the agent not to trust the analysis in the issue and to derive its own diagnosis from the code. Then an extension adds a prompt-url-widget which watches the prompt before the agent starts, recognizes the GitHub issue or PR URL that /is (or the PR equivalent) put into the prompt, fetches the title and author with gh, renders that in a little UI widget, and renames the session. It also rebuilds that state on session start or session switch, so if we reopen an older investigation the window still tells the developer which issue it belongs to.
我们为此搭的小设施，就是 Pi 自己仓库里随版本提交的 .pi 目录中的三个小件。/is（analyze issue）是分析 GitHub issue 的 prompt：给 issue 打标并指派、读完整线程和链接，然后明确告诉 agent 不要相信 issue 里的分析、要从代码推导自己的诊断。然后一个扩展提供 prompt-url-widget：在 agent 启动前监听 prompt，识别 /is（或 PR 等价命令）放进 prompt 的 GitHub issue/PR URL，用 gh 抓标题和作者，渲染成一个小 UI 挂件，并重命名 session。它还会在 session 启动或切换时重建这个状态——所以重新打开一桩旧调查时，窗口仍然会告诉开发者它属于哪个 issue。
In practice this means it's possible to have several Pi windows open, each running /is against a different issue, and the UI keeps the investigations visually distinct while the agents do their independent reproduction and code reading. Once the investigations are done, one can work through them sequentially. To finish off everything, /wr (wrap it up) is the matching wrap-up prompt: it infers the GitHub context from the session, updates the changelog, drafts or posts the final issue comment with a disclaimer, commits only the files changed in that session, adds the appropriate closes #... when there is exactly one issue, and pushes from main.
实践中这意味着可以同时开好几个 Pi 窗口，每个窗口对不同 issue 跑 /is，UI 让各桩调查在视觉上泾渭分明，agent 们各自独立复现、独立读码。调查做完后，再按顺序逐个处理。收尾由 /wr（wrap it up）负责，它是对应的收口 prompt：从 session 推断 GitHub 上下文、更新 changelog、起草或发布带免责声明的最终 issue 评论、只提交该 session 改过的文件、在恰好只有一个 issue 时加上相应的 closes #...、然后从 main 推送。
Open Source Is About Hard Problems Worth Fixing · 开源关乎值得修的难题
You will have noticed this already but Open Source in a post-AI world is under a strange new pressure. We are getting more code, more projects, and more issues. Projects appear with no real users, or a temporary audience of one, and even projects with thousands of stars can have a shelf life of weeks.
你大概已经注意到了：AI 之后的开源，正承受一种奇怪的新压力。代码更多、项目更多、issue 更多。有的项目出现时就没有真实用户，或只有一个临时受众；连几千 star 的项目，保质期也可能只有几周。
For us, Pi's harness layer is worth maintaining carefully because it solves hard coordination problems and creates a platform we and others can build on. We also know that coordination and cooperation lifts us all up. Many times the right answer is not to work around a problem locally, but to make the upstream behavior correct. Mario has been very good at refusing to make Pi paper over every misconfigured gateway, and we're trying to preserve that discipline. When a gateway behaves correctly, everybody benefits.
对我们来说，Pi 的 harness 层值得精心维护，因为它解决的是困难的协调问题，并创造了一个我们和他人都可以往上盖的平台。我们也知道协调与合作会让所有人受益。很多时候，正确答案不是在本地绕过问题，而是让上游的行为变正确。Mario 一直很擅长拒绝让 Pi 去粉饰每一个配置错误的网关，我们也在努力守住这条纪律。网关行为正确时，所有人都是受益者。
Sadly that type of thinking is quickly disappearing because these machines make local workarounds cheap, so code accumulates local defenses against every misbehavior. Instead of humans talking to humans about where a fix belongs, one human and one machine work around the problem in isolation.
可悲的是，这种思维方式正在快速消失——因为这些机器让本地绕过变得廉价，于是代码里积累起针对每一种不当行为的本地防御。不再是人与人对话商量修复该属于谁，而是一个人和一台机器在孤岛上各自绕过问题。
Keep in mind that AI has not increased the number of people who need software, or the number of maintainers who can review it. It has mostly increased the amount of code and the number of projects competing for attention. Some of that is healthy, but a lot of it fragments effort that should be shared.
记住：**AI 并没有增加需要软件的人，也没有增加能审代码的维护者。**它增加的主要是代码量，和争夺注意力的项目数。其中一些是健康的，但很多只是在切碎本该共享的精力。
We need stronger foundations, not weaker ones. Open Source needs more collaboration, not more isolated work with a machine. Human communication is hard, and it is tempting to avoid it when you can sit alone with your clanker. But isolation is not where Open Source derives its value. The value is in the community and the structure that lets projects outlive their original creators.
我们需要更坚固的地基，而不是更松的。开源需要更多协作，而不是更多「一个人和一台机器」的孤岛作业。人际沟通很难——当你可以独自坐着陪你的 clanker 时，逃避沟通太诱人了。但开源的价值从来不在孤岛。价值在社区，在那些让项目活得比原创者更久的结构里。
To me, clanker is a much preferable term for agent. Agency lies with humans, not with machines. Calling these things agents I still believe is a mistake, but alas.
对我来说，用 clanker 指代 agent 比 agent 这个词好得多。**能动性在人，不在机器。**把这些东西叫 agent，我至今认为是个错误——不过算了，随它去。