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 未增加需要软件的人数和审查代码的维护者数量却增加了代码和项目数量分散精力。开源需要更强大基础和更多协作人际沟通虽困难但孤立不是开源价值来源开源价值在于社区和能超越项目原始创建者寿命的结构。