夜雨聆风最近我一直在折腾 Pi 的插件生态。
一开始的感觉是： 看起来每个插件都很有用。
有的能联网查文档，有的能做代码图谱，有的能子代理并行，有的能浏览器自动化，还有的能帮你省 token、做状态栏、管理会话、防止系统休眠……
但真装多了以后，我很快发现另一个问题：
Pi 插件不是越多越好。 真正有价值的，是那些能进入你日常开发闭环的插件。
有些插件演示看起来很炫，但实际用两次就忘了； 有些插件名字很普通，却一旦装上就不想关掉； 还有一些插件，功能确实强，但在 Windows 原生环境里安装体验并不友好，最后只能成为"推荐给别人"的遗憾项。
所以我做了一件比较折腾的事：
我把一批 Pi 插件分别交给 Google Gemini 和 Qwen 做交叉评估，再结合我自己的 Windows 环境实际使用情况，最后整理出这篇文章。
这篇文章会分三部分：
Gemini 和 Qwen 交叉筛选后，我认为值得推荐的 15 个 Pi 插件 我个人正在使用，并且愿意继续保留的 5 个插件 一个我特别想装、但最后在 Windows 上留下遗憾的插件
先说明一下： 这里的"联合推荐"不是 Google 或 Qwen 官方合作背书，而是我用两个模型对同一批插件做交叉评估后，整理出来的结果。
>_ 为什么我想写这篇？
Pi 的插件生态有一个很明显的特点：
它不是单纯的功能扩展，而是在改变 Agent 的工作方式。
一个好的插件，不只是让 Pi 多一个按钮，而是会让它：
更懂你的代码库 更少产生幻觉 更能并行处理任务 更不容易改坏代码 更接近真实工程流程
但与此同时，插件也带来了新的问题：
权限越来越大 功能越来越重叠 安装门槛越来越高 Windows 兼容性参差不齐 很多插件看起来强，实际上并不适合长期常驻
所以我不想写一篇简单的"插件大全"。
我更想写的是一份筛选结果：
哪些插件真的值得装？ 哪些插件只是看起来不错？ 哪些插件适合 Linux/macOS，但在 Windows 上要谨慎？ 哪些是我自己真的在用？ 哪些是我喜欢但没能顺利用上的？
这就是这篇文章的由来。
>_ 我的筛选标准
在让 Gemini 和 Qwen 参与评估时，我主要看这几个维度：
1. 日常使用频率
不是"演示时很惊艳"，而是"平时真的会用到"。
2. 痛点强度
它解决的问题是不是高频、真实、明显。
3. 工程价值
它是否能让 Pi 更接近真实开发流程，而不是只停留在聊天层面。
4. 平台兼容性
尤其是我自己在 Windows 上使用，所以会特别关注：
Windows 原生环境是否稳定 是否依赖 native module 是否更适合 Linux/macOS/WSL2
5. 权限与风险
越底层的插件，越要谨慎。 尤其是涉及：
Shell 执行 浏览器控制 网络抓取 文件修改 安全拦截
6. 是否单功能清晰
我更偏好"解决一个明确问题"的插件，而不是大而杂的合集包。
一、Gemini 和 Qwen 交叉推荐：15 个值得关注的 Pi 插件
下面这 15 个，是我认为综合价值比较高的一批。
为了避免写成"每个都强烈推荐"的流水账，我把它们分成了三档：
优先安装档 强烈推荐档 场景型推荐档
>_ 第一档：优先安装档
这一档的特点是： 它们更像基础设施，而不是小玩具。
如果你只想装少数几个，先看这些。
备注：我把以下两个放在"优先档"是建议新用户优先装，但目前我的项目类型里没那么多需要它们的场景，所以暂未启用 —— 这跟"我自用 5 个"是两个维度，推荐优先级 vs 个人实测。
1. context-mode
安装命令：
pi install npm:context-mode一句话定位： 大仓库上下文优化与本地检索。
它解决什么问题？ 当项目变大以后，最麻烦的事情不是"Pi 不会写代码"，而是：
上下文越来越长 token 消耗越来越高 响应越来越慢 模型越来越容易被无关代码干扰
context-mode 的价值就在于： 它不是把整个项目一股脑塞给模型，而是尽量按需检索相关上下文。
适合谁？
大型项目 monorepo 老代码库 对 token 成本敏感的人
我的评价： 这是我认为非常接近"核心基础设施"的一类插件。 尤其当你的项目超过一定规模后，它的价值会非常明显。
2. pi-web-access
安装命令：
pi install npm:pi-web-access一句话定位： 通用联网、查文档、抓网页、减少过期知识幻觉。
它解决什么问题？ 模型最大的问题之一，不是不会写，而是：
它可能用旧 API 很自信地教你写代码。
pi-web-access 的价值在于让 Pi 能更直接地接触外部世界：
搜索技术文档 抓取网页内容 读取 PDF 克隆 GitHub 仓库分析 查看更新日志
适合谁？
经常使用新库的人 做框架升级的人 需要频繁查官方文档的人
我的评价： 这是一个通用性很强的插件。 它不一定每天都惊艳，但确实能显著降低"模型一本正经胡说八道"的概率。
3. pi-subagents
安装命令：
pi install npm:pi-subagents一句话定位： 子代理协作与并行任务分发。
它解决什么问题？ 有些任务天然适合拆分：
主代理写核心逻辑 子代理补测试 子代理整理文档 子代理做调研
pi-subagents 的价值就在于让 Pi 不只是单线程对话，而是能形成更复杂的工作流。
适合谁？
大型重构 多任务并行 需要调研 + 实现同时推进的场景
我的评价： 它不是每个小任务都需要，但一旦遇到复杂项目，价值会突然放大。 属于"平时不显山露水，关键时候很有用"的类型。
4. pi-hashline-edit
安装命令：
pi install npm:pi-hashline-edit一句话定位： 用锚点提升代码编辑的精确度。
它解决什么问题？ Agent 改代码时，一个很常见但很烦人的问题是：
改错行 插错位置 替换错片段
pi-hashline-edit 的思路是通过更精确的锚点机制来提升编辑稳定性。
适合谁？
经常让 Pi 做精确修改的人 对"改错位置"很敏感的人 真实工程代码维护者
我的评价： 这个插件听起来不性感，但它解决的是很实际的问题。 对真实项目来说，稳定比炫技重要得多。
5. pi-lens
安装命令：
pi install npm:pi-lens一句话定位： 把 LSP 报错和类型检查反馈回灌给 Pi。
它解决什么问题？ Agent 写代码最怕什么？
不是写慢，而是：
写错了还不知道。
如果 Pi 能在修改代码后自动感知 TypeScript、Python、Rust 等 LSP 报错，它就能从"猜着写"变成"看着反馈写"。
适合谁？
TypeScript 用户 Python 用户 Rust 用户 希望 Agent 自动修复低级错误的人
我的评价： 这是我认为非常值得推荐的一类方向。 它不是简单增强，而是在补 Agent 的工程感知能力。
6. pi-git-checkpoint
安装命令：
pi install npm:pi-git-checkpoint一句话定位： 每轮修改前做快照，让 Agent 改代码有后悔药。
它解决什么问题？ 当你让 Pi 连续修改多个文件时，最大的心理负担是：
万一改坏了怎么办？
pi-git-checkpoint 的价值就是降低这种心理负担。 它让 Pi 的修改不再是"一次性冒险"，而是可以回退的过程。
适合谁？
重构场景 多文件修改 不完全信任 Agent 一次性改完的人
我的评价： 这类插件的意义不是让 Pi 更聪明，而是让你更敢用它。 这其实非常重要。
>_ 第二档：强烈推荐档
这一档不是绝对刚需，但装上以后，体验会明显变好。
7. @gotgenes/pi-permission-system
安装命令：
pi install npm:@gotgenes/pi-permission-system一句话定位： 权限边界、路径沙盒和命令控制。
它解决什么问题？ Agent 能力越强，权限问题越重要。 你不一定希望它可以：
随便改任何目录 随便执行任何命令 随便碰敏感文件
这个插件的价值在于给 Pi 加上更明确的边界。
适合谁？
让 Agent 执行 Shell 的人 项目中有敏感配置的人 团队使用 Agent 的人
我的评价： 这类插件非常值得重视。 Agent 越自动化，越需要边界。
8. hypa
安装命令：
pi install npm:hypa一句话定位： 压缩冗长日志，拯救上下文窗口。
它解决什么问题？ 测试输出、构建日志、依赖安装日志，经常一刷就是几千行。 这些内容如果全部进入上下文，既贵又吵。
hypa 的价值就是把这些长日志压缩成更关键的信息。
适合谁？
经常跑测试的人 经常构建的人 日志很长的人 想省 token 的人
我的评价： 这是那种看起来不起眼，但真能救命的插件。
9. @plannotator/pi-extension
安装命令：
pi install npm:@plannotator/pi-extension一句话定位： Plan Mode，先出方案，再动代码。
它解决什么问题？ 复杂任务最怕 Agent 上来就改。 一旦方向错了，改得越多，错得越多。
这个插件的价值是让 Pi 先给出方案，等人确认后再执行。
适合谁？
架构改动 模块重构 多步骤任务 需要人工审批方案的人
我的评价： 它不是增强智能，而是增强可控性。 这类能力在真实工程里非常重要。
10. pi-interview
安装命令：
pi install npm:pi-interview一句话定位： 用交互式表单收集结构化输入。
它解决什么问题？ 当需求不明确时，Pi 经常会在终端里反复问你：
你要方案 A 还是 B？ 是否保留这个文件？ 使用哪种实现方式？
pi-interview 把这些提问变成更结构化的表单交互。
适合谁？
需求模糊的任务 多方案选择 不想在终端里打很多字的人
我的评价： 它不是每次都用，但在关键节点上很省时间。
11. @narumitw/pi-chrome-devtools
安装命令：
pi install npm:@narumitw/pi-chrome-devtools一句话定位： 通过 Chrome DevTools Protocol 做浏览器自动化。
它解决什么问题？ 前端问题很多时候不是"代码看起来对不对"，而是：
页面有没有渲染出来 控制台有没有报错 样式有没有炸 交互能不能点
这个插件让 Pi 有机会直接验证浏览器里的结果。
适合谁？
前端开发 全栈开发 需要 UI 验证的人
我的评价： 如果你是前端，它的价值会很高。 如果你不是前端，它就更偏场景型。
12. pi-tscg
安装命令：
pi install npm:pi-tscg一句话定位： 工具 schema 与结果压缩，偏底层优化。
它解决什么问题？ 这个插件不是那种一眼就能看懂价值的类型。 它更偏底层：
工具 schema 压缩 结果压缩 provider 感知缓存
目标还是为了降低开销、提升效率。
适合谁？
对 token 成本敏感的人 工具调用频繁的人 喜欢做底层优化的人
我的评价： 它属于"值得观察和保留"的一类。 不是最显眼，但方向很对。
>_ 第三档：场景型推荐档
这一档不是所有人都需要，但对口的人会很喜欢。
13. @narumitw/pi-firecrawl
安装命令：
pi install npm:@narumitw/pi-firecrawl一句话定位： 深度网页爬取与文档抓取。
它解决什么问题？ 有些文档网站结构复杂，普通抓取不够用。 如果你需要：
爬整站文档 建本地知识库 做框架文档聚合
这类插件会很有价值。
适合谁？
文档库建设 知识库整理 深度技术资料收集
我的评价： 它和 pi-web-access 有一定重叠。 如果你只是普通查网页，未必需要同时保留两个。
14. @capyup/pi-goal
安装命令：
pi install npm:@capyup/pi-goal一句话定位： 长任务目标锁定。
它解决什么问题？ 长任务最大的问题之一是：
聊着聊着，Agent 忘了最初要干什么。
pi-goal 的价值就是把目标固定住，让 Pi 在长流程里不容易跑偏。
适合谁？
多阶段任务 长时间重构 迁移型工作
我的评价： 短任务不太需要它。 但如果你经常做长任务，它会很有帮助。
15. @narumitw/pi-caffeinate
安装命令：
pi install npm:@narumitw/pi-caffeinate一句话定位： Agent 运行期间防止系统休眠。
它解决什么问题？ 有些任务很长：
跑测试 构建镜像 自动化流程 大规模重构
如果系统中途休眠，任务就可能中断。
适合谁？
笔记本用户 长任务用户 自动化流程用户
我的评价： 功能不复杂，但确实解决了一个真实痛点。 只是它更偏场景型，不适合所有人长期常驻。
二、我个人正在使用，并且愿意继续推荐的 5 个插件
前面那 15 个，是"筛选结果"。
下面这 5 个，是我自己真的在用，并且目前愿意继续保留的。
这部分我会写得更主观一点。
一个重要提醒：第一档里
pi-lens和pi-git-checkpoint我没列入自用，不是因为不好，而是我当前项目类型还没遇到那么强的需求。我把它们放在第一档是给"新用户入门优先级"建议，跟"我自己长期保留"是两个不同的判断维度。
>_ 1. context-mode
如果只能留一个，我大概率会留 context-mode。
原因很简单：
只要项目稍微大一点，上下文质量就会直接影响 Pi 的表现。
它不是那种第一次用就让人惊呼的插件，但属于用了以后会慢慢发现离不开的类型。
它最大的价值不是"看起来更智能"，而是：
上下文更干净 无关内容更少 token 消耗更可控 大项目更可用
对我个人来说，这是目前最不想关掉的一类扩展。
>_ 2. pi-web-access
我很怕模型拿旧 API 教我写代码。
尤其是前端生态，很多东西变化太快。 一个库半年前和现在的用法可能完全不一样。
pi-web-access 对我来说最大的价值不是"能搜索"，而是：
让 Pi 有机会接触更新的文档和真实网页内容。
这会明显减少一些过期知识带来的幻觉。
它不一定每次都完美，但确实是我愿意保留的通用能力。
>_ 3. pi-subagents
pi-subagents 不是每天都会用到。
但一旦遇到复杂任务，它的价值就很明显。
比如：
一边改主逻辑 一边补测试 一边整理变更说明 一边做旁路调研
这种"主线继续推进，支线并行处理"的感觉，确实很像真实团队协作。
它让我觉得 Pi 不只是一个对话框，而更像一个可以拆分任务的工作系统。
>_ 4. pi-hashline-edit
这个插件是我觉得"名字很工程，价值也很工程"的代表。
它不炫。
但它解决的是一个很实际的问题：
改代码时，尽量别改错地方。
对真实项目来说，这比很多花哨功能重要得多。
我越来越觉得，Agent 开发真正值钱的不是"能不能写一大段"，而是：
能不能精确改 能不能少改坏 能不能稳定插入 能不能可靠替换
pi-hashline-edit 就是朝这个方向走的插件。
>_ 5. pi-interview
pi-interview 对我来说是一个"关键节点很舒服"的插件。
当 Pi 需要我做选择时，比起在终端里来回打字，我更愿意通过结构化表单完成：
单选 多选 文本输入 确认选项
这会减少很多歧义，也少打很多字。
它不是每次都用，但在需求不明确、方案有分支的时候，体验确实更好。
三、我最遗憾的 1 个插件：pi-code-graph
如果这篇文章只让我推荐"最强插件"，我可能会犹豫。 但如果让我选一个"最遗憾"的插件，我会选：
pi install npm:pi-code-graph>_ 为什么是它？
因为 pi-code-graph 做的事情确实很吸引人。
它试图解决的是大型项目里一个非常关键的问题：
如果我改了这里，到底会影响哪里？
这类能力对真实工程非常重要。 尤其是当你面对：
老项目 大仓库 复杂调用链 跨模块依赖
如果能通过代码依赖图谱看清函数调用关系和影响范围，价值非常大。
所以从功能方向上看，我是真的很喜欢它。
>_ 但遗憾在哪里？
遗憾的是，它在 Windows 原生环境下的安装体验并不友好。
我尝试安装时，一直没能顺利成功。 这类插件通常会涉及：
AST 分析 本地图谱构建 原生模块依赖 编译工具链
这些在 Linux 或 macOS 上往往更顺，但在 Windows 原生环境里就容易翻车。
所以最后我对它的态度变成了：
我很想推荐它，但我没法在 Windows 原生环境里顺畅地推荐它。
>_ 我会怎么建议别人？
如果你用的是：
Linux macOS Windows 下的 WSL2
那我会很建议你尝试一下 pi-code-graph。
但如果你和我一样，主要在 Windows 原生环境里折腾，那可能要做好安装失败的心理准备。
它不是不好。 它只是环境门槛更高。
最后说几句：Pi 插件真正值钱的地方，不是"多"
写完这轮筛选，我最大的感受是：
Pi 插件真正值钱的地方，不是让 Agent 看起来更炫，而是让它更接近真实工程流程。
什么叫真实工程流程？
就是：
能感知代码错误 能控制修改边界 能回滚 能压缩日志 能查新文档 能并行处理任务 能在长任务里不跑偏 能在复杂需求前先确认方案
这些听起来都不够"炸裂"。
但它们才是决定你会不会长期用下去的关键。
所以如果让我给一句最简单的建议，那就是：
先装核心基础设施，再按场景补扩展，最后再考虑那些高级玩具。
不要一上来就装满。 插件装多了，不只是变慢，还会增加权限风险和维护成本。
真正好的配置，不是"看起来全家桶"，而是：
少而精，并且能进入你的日常工作流。
>_ 附：如果让我给一份最短推荐清单
如果你只想看最精简版本，我会这样推荐：
最值得优先看的
我个人目前在用的
最遗憾但想推荐给别人试的
>_ 写在最后
这篇文章不是想说"这 15 个都必须装"。
恰恰相反。
我更想表达的是：
在 Pi 插件生态里，真正值得长期保留的并不多。 你要做的不是装满，而是装对。
如果你也在用 Pi，建议你从自己的真实工作流出发：
你写前端多，就优先看浏览器自动化 你项目很大，就优先看上下文优化和代码图谱 你很在意安全，就优先看权限和回滚 你经常跑长任务，就优先看目标锁定和防休眠
插件从来不是目的。 让 Pi 真正帮你干活，才是目的。
免责声明
本文中的"Gemini 和 Qwen 联合推荐"指作者分别使用 Google Gemini 与 Qwen 对候选插件进行交叉评估，并非 Google 或 Qwen 官方合作背书。 Pi 插件生态更新较快，包名、版本、安装命令和兼容性都可能变化，安装前建议自行核对源码、权限和平台支持情况。