← 返回全部项目持续维护
开源工具 / From daily friction to public tools
Pi 开源扩展
从每天和 AI 协作时遇到的摩擦里找机会，再把值得长期解决的问题做成开源工具。
01 / 为什么做
先找到真正的问题，再决定产品应该长成什么。
长任务会中断，多个 AI 分工后容易混乱，用户取消了但主代理不知道，中文界面只翻译了一部分。这些问题反复出现以后，就不能再靠一句“请继续”或更长的提示词解决。
这 17 个扩展不是先列好功能清单，再去寻找用途。我会先判断问题是偶发失误，还是别人也会遇到的结构性缺口；再区分应该改提示词、工作流、上游宿主，还是做成一个长期维护的扩展。
02 / 从问题到改动
每次真正的改动，都从一个已经看见的问题开始。
01
dteam 已经做出来了，我却发现自己不敢把它放进真实开发流程。
- 我的判断
- 问题不是功能不够，而是五种角色、对抗式合议、积分制和 batch 把工具做得太重，使用场景也没有说清。
- 具体改动
- 推翻旧定位，改成 T1/T2/T3 模型分级执行层；任务与 worker 分开，依赖、工具选择和最终收口仍由主代理判断。
02
模型连续报错后，正在进行的 Task Plan 会暂停，甚至在后续回合被清掉。
- 我的判断
- 这不是提醒模型“继续”就能解决的问题，而是任务状态、完成合同和恢复时机需要成为产品能力。
- 具体改动
- 让计划保留目标、阶段、证据和恢复状态；模型错误后暂停原计划，只由下一条真实用户输入恢复。
03
复杂对齐时，AI 常把多个问题塞进一段文字，或者只给一个推荐答案。
- 我的判断
- 这里缺的是可以同时承载单选、多选和多个并列问题的交互，不应该继续依赖自由文本。
- 具体改动
- 做出 dask：一轮平铺多个问题，每题可以单选或多选；单题最多 12 项，更多就要求拆解，并与 grill 保持松耦合。
04
中文界面改了一部分，命令说明、会话摘要和模型看到的工具描述仍然是英文。
- 我的判断
- 本地化不只是翻译按钮，而是要同时照顾人看到的界面、模型读到的工具说明和压缩后的会话记忆。
- 具体改动
- pi-di18n 分成界面、模型工具描述和摘要三条链路，覆盖 12 种语言，并为运行时翻译保留缓存和回退。
03 / 我负责什么
项目有什么，和我在其中做了什么，是两件事。
- 从自己的真实使用中记录反复摩擦，判断问题应该由提示词、工作流、上游宿主还是独立扩展解决。
- 在动手前检查上游实现和已有扩展，明确产品边界、非目标和可以被验证的使用结果。
- 设计任务状态、权限门禁、用户取消、失败恢复和体面退出等产品规则。
- 组织 AI Agent 完成实现、测试、文档与发布，并逐项验收。
- 把扩展放回真实工作中持续使用，遇到下一次失效时继续调整或推翻。
04 / 关键取舍
我更愿意展示取舍，而不是给自己贴能力标签。
- 一个问题反复出现、不能靠一次提示解决，并且具有共用价值时，才值得被做成扩展。
- 任务不等于执行者；一个 task 可以由多个 worker 协助，dgoal 与 dteam 可以组合但彼此独立。
- 主代理负责理解依赖、选择工具和最终判断，worker 只在明确授权的范围内执行。
- 用户取消、模型报错、超时和恢复必须成为系统状态，不能靠模型临场猜测。
05 / AI 怎么参与
AI 是协作者，不是成果归属的替身。
代码主要通过 AI 协作完成，但需求边界、异常行为、测试方法和是否发布由我负责。我的工作重点不是“让 AI 多写代码”，而是让它在可检查的边界里工作。
06 / 怎么检查
写完不是完成，能被检查才接近完成。
- 扩展已经公开发布并在日常工作中持续使用。
- 发布前分别检查本地行为、自动化测试、包内容和版本状态。
- 公开下载数据按 npm 官方统计口径记录。
07 / 现在做到哪里
截至 2026 年 7 月，npm 账号下有 22 个公开包，累计 26,081 次下载；其中 17 个是围绕 Pi 工作流制作的扩展。
17个 Pi 扩展
26,081次 npm 下载截至 2026-07-30