ZiChuanLan/pi-purge

如果你想知道编程 agent 的行为有多少来自它内置的系统提示词、多少来自你写的指令，这个扩展提供了一个会话级的开关，把变量换掉，而不是跟内置提示词硬碰硬。

解决什么问题

你有一个自认为能让 pi 表现更好的提示词文件，但 agent 内置的系统提示词还在，于是结果不好时很难判断：是你的指令被忽略了，还是框架提示词压过了它？通常只能去改内置提示词，既脆弱又难以还原。pi-purge 让你用同一个请求，在原始、裁剪、仅提示词三种配置下分别运行，/purge status 会显示上一轮实际改动了什么。得到的是一组可重复的对比，而不是「我的提示词好像有用」的模糊感觉。

有什么不同

这个扩展的思路不是盖过内置提示词，而是减法。replace 模式删掉 pi 内置的助手身份行和打包的文档段落，保留工具列表、准则和项目上下文；strict 模式只发送你的提示词加上当前工作目录。README 对这个代价说得很直接：strict 同时会丢掉 AGENTS.md/项目上下文、skills 列表以及其他扩展注入的提示词段落，因此其结果不能和普通会话相提并论。append 侵入性最小，但 README 也承认它通常信号最弱，因为框架提示词后面的段落仍然很有分量。默认使用 strict，也正是人格提示词与其他框架文字竞争最少的模式。

状态管理刻意做到最小：作用域是会话，每次启动、new、resume 或 reload 都以关闭状态开始，不写任何磁盘文件。好处是退出 pi 后一定回到原样，代价是每次重启或恢复会话后都要重新打开改写。不想每次手输，可以用 PI_PURGE_SOURCE 指向一个绝对路径的提示词文件，从进程环境里传入而不保存状态。

谁值得试

适合：正在对 pi 编程 agent 做提示词工程或回归测试的人，需要在框架提示词存在、被裁剪、被去掉三种情况下跑同一个任务做 A/B 对比。三个明确的模式正好对应这个实验设计，自带的示例提示词也让第一次运行不需要准备额外文件。

不适合：想给日常编程配一个长期人格的人。按设计它不会跨会话保留，而让实验有效的 strict 隔离，恰恰会去掉普通会话依赖的项目上下文。如果你只是想在正常 pi 行为之上叠加指令，可以用 append 模式，但 README 自己提醒差异可能很小。

使用条件与边界

前提是已安装 pi（@earendil-works/pi-coding-agent），这是扩展而非独立 agent。安装方式是用固定 git 版本或 npm，然后在会话里执行 /purge；项目 README描述了单个 hook 和测试套件。自定义提示词需要用 /purge source <path> 指向文件，编辑后用 /purge reload 重新读取。日常维护主要是记住每个会话重新开启，以及改完文件后重新加载。

更大的限制在解读层面：replace 仍会留下框架文字，其他扩展也可能在本扩展之后追加提示词段落，所以只有 strict 能干净地隔离你的人格提示词。README 也明确指出 strict 的结果不能与普通会话相比。把它当作实验仪器，而不是生产配置。README 注明机制和自带提示词移植自 dsh-purge 项目。

HotRepo 点评

项目创建六天后，于 2026-10-24 以 299 个总星数出现在 HotRepo JavaScript 新项目榜第 25 名。这只是一个带日期的快照，不是增长测量，可比的口榜历史也不足以判断热度能否持续。设计很小，对取舍也足够诚实；采用前主要确认你的工作流能否接受每个会话重新开启，以及 strict 模式下的上下文丢失。