用 Pi 构建 Pi：开源项目面临 AI 带来的混乱与挑战

1. 用 Pi 构建 Pi 的反思

2026 年 5 月 24 日撰写的文章提到，Pi 现在是 Earendil 的一部分，但本质上仍是 Mario 的项目。作者在问题跟踪器投入更多时间，用 Pi 开发 Pi 后进行了反思。

2. 混乱问题

用 Pi 构建 Pi 看似是“吃自己的狗粮”，但有助于理解工作。使用代理开发改变了问题跟踪器角色，问题描述还用作 Pi 会话提示输入。糟糕问题一直烦人且表述模糊，现在还有 5% 人工、95%“clanker”生成且大多不准确的问题。人们提交经“clanker”处理后表述混乱的问题，结论不准确却自信，导致对根本原因猜测、虚假复现步骤等。Pi 会把错误诊断当证据，虽有自定义斜杠命令提醒，但“clanker”会扩大问题范围。作者希望问题报告浓缩为人类实际观察内容，如运行命令、期望情况、实际情况和确切错误信息等。

3. 混乱滋生混乱

充满混乱内容的问题体现了当前工具质量，其在创建优质问题上的失败也延伸到很多生成代码。“clanker”常把问题和实现过度复杂化，如处理格式错误会话日志时添加容错读取器、回退机制等。Pi 核心有必须维护的不变量，“clanker”却假设不存在，增加系统复杂性。正确修复方法应是让不良状态不可能出现，大语言模型生成代码产生大量不必要复杂性，维护者需将讨论拉回全局不变量，难度大且繁琐。

4. 数量是个问题

问题跟踪器收到大量问题和拉取请求，相当一部分由大语言模型辅助生成，多数质量糟糕，处理量成为维护难题。Pi 的问题跟踪器自动关闭新贡献者提交的问题和拉取请求，有手动重新打开或批准个别请求的流程。过去 90 天公共 GitHub 跟踪器数据显示，排除 Earendil 成员后有 3145 个外部问题和拉取请求，2504 个因来自未批准个人被自动关闭，17% 的问题被重新打开，拉取请求合并率不到 10%。低质量垃圾信息来源包括 OpenClaw 实例等，不应过多归咎于 GitHub，而应是制造混乱者的问题。

5. 谨慎并行处理

Pi 用 Pi 构建，但距离 Bun 和 OpenClaw 的完全独立、自动化软件工程状态还很远。目前有相当多并行处理工作，主要用于复现问题。使用 Pi 自己提交的 [`.pi`] 文件夹中的三个小部分，`/is` 用于分析 GitHub 问题，添加标签、分配任务等；扩展添加 `prompt-url-widget` 监视提示，显示问题信息并为会话重命名；`/wr` 是收尾提示，更新变更日志等。可同时打开多个 Pi 窗口处理不同问题，调查完成后按顺序处理。

6. 开源在于值得解决的难题

后 AI 时代开源面临新压力，有更多代码、项目和问题，有些项目无真正用户或寿命短。Pi 的框架层值得维护，解决了棘手协调问题，创建了可构建的平台。但现在工具使局部解决方案廉价，代码积累局部防御措施，人们与机器孤立解决问题。AI 未增加需要软件的人数和审查代码的维护者数量，却增加了代码和项目数量，分散精力。开源需要更强大基础和更多协作，人际沟通虽困难，但孤立不是开源价值来源，开源价值在于社区和能超越项目原始创建者寿命的结构。