企业官网建设流程全解析

为什么你的提示词对比实验总是"说不清原因"

改一句系统提示词，模型的输出变了——但你无法确定变化来自你自己的指令，还是来自 pi 宿主提示词（harness prompt）的措辞、工具列表、项目上下文。这就是提示词 A/B 测试最大的陷阱：变量没有隔离。

pi-purge正是为解决这个问题而生的 pi 扩展：一条/purge命令，就能让同一个会话在三种系统提示词条件下运行——pi 原版、精简版、或只发你的一份人设提示词。关闭时它不读盘、不改写任何内容，行为与没安装完全一致，天然就是一个干净的对照组开关。

安装 pi-purge：一条命令进入实验环境

在 pi 会话外执行安装命令即可：

pi install npm:pi-purge

包内自带一段简短示例人设，装完就能跑，无需准备任何文件。想用自己的提示词，只需要一个本地 Markdown 文件，例如~/prompts/persona.md。

安装包元数据（名称、版本、依赖约束、关键词）见 package.json，完整中文说明见 README.zh-CN.md。

三种实验条件：append / replace / strict 各扮演什么角色

pi-purge 的核心设计是把"宿主提示词保留多少"做成三档实验条件，对应 A/B/C 三个组：

三种模式的实现逻辑在 extensions/pi-purge.ts 的before_agent_start钩子中；模式对照表可对照 README.zh-CN.md。

两个关键工程细节，直接决定实验可靠性：

• 工具不依赖系统提示词。工具 schema 走 API 的tools参数，所以即使在strict下工具也全部可用——排除"工具丢了导致行为变化"这个干扰项。
• replace依赖固定文案定位切除段落。pi 升级改措辞时它会原样保留提示词（退化成append），而不是切错位置；此时/purge status会显示身份段 未匹配。strict不做任何匹配，跨 pi 版本行为一致，详见 stripHostPersona 实现。

跑通一组 A/B 测试：最小完整步骤 🧪

以"同一句请求在三种条件下各跑一遍"为例：

第 1 步：准备人设文件（或用内置示例快速验证流程）

/purge source C:/prompts/persona.md

切换失败（如文件不存在）会自动回滚并报错，不会静默降级，逻辑见 source 子命令。

第 2 步：设定条件并开启

/purge mode strict /purge on

第 3 步：发送同一请求，观察输出。

第 4 步：换条件。新开会话（new）或退出重启，把模式改成replace、append各跑一遍。这里有个容易忽略的福利：每次session_start（启动 / 新建 / resume / 重载）都强制从关闭状态开始，状态只活在内存里、退出即失、不写任何文件。也就是说 pi-purge 帮你保证了每次实验的起点是干净的，不可能"上一轮忘了关"污染下一组。这条会话级隔离由 session_start 钩子 保证，并有专门的测试断言 test/pi-purge.test.mjs。

第 5 步：记录环境变量。每组实验结束前执行：

/purge status

它会输出当前模式、提示词来源、已加载字符数，以及上一轮实际切除/保留了什么（身份段 已切除 / pi 文档段 已切除）。官方文档也明确建议：留结果时把status输出一起记录（README.zh-CN.md）。这份输出就是你实验记录里的"环境指纹"。

控制变量：五条实操准则让结论站得住

1. 输入完全一致：同一请求文本、同一模型、同一工作目录。注意strict会一并丢弃AGENTS.md/ 项目上下文、skills 列表和其他扩展注入的提示词——这正是它能做单变量隔离的原因，但也意味着strict下的结果不能直接和普通会话对比。
2. 每组独立会话：利用"会话级默认关闭"设计，组间物理隔离，避免状态残留。
3. 每组多采样：LLM 输出本身有随机性，同一条件至少跑 3~5 次，观察的是分布差异而非单次差异。
4. 盯住status的字符数：每轮注入的提示词长度会被记录（如"每轮注入 N 字符"）。若两次对比中你的指令长度差异很大，长度本身就成了未受控变量。
5. 改人设文件后用/purge reload重读，不要指望它自动热更新外部文件。

⚠️ 一个反直觉的提醒：append侵入最小、信号也最弱（宿主提示词后段权重仍然很大），replace仍残留宿主文本且其他扩展可能在之后追加内容——实践中只有strict能让人设不与别的框架措辞竞争。做"人设到底起没起作用"这类归因实验，优先选strict。

进阶：用 PI_PURGE_SOURCE 做批量条件化测试

如果想"每个 pi 进程自动指向指定人设文件"（例如开三个终端分别跑三组条件），可以设置环境变量：

PI_PURGE_SOURCE=/home/me/persona.md pi

它只提供source的初始值：仍然需要手动/purge on，会话内/purge source <路径>优先级更高，文件不存在时开启会直接报错而非静默回退到内置示例——批量脚本里这一点能防止"悄悄用了错误的提示词"。机制见 ENV_SOURCE 定义 与 环境变量测试套件。

实验记录模板：一张表说清整组实验

表中的"注入字符数"与"身份段/文档段切除状态"直接抄自/purge status输出，保证每条记录可追溯。

常见问题 FAQ

关闭 pi-purge 会影响 pi 吗？不会。关闭时不读盘、不改写提示词，pi 行为与未安装该扩展完全一致；退出 pi 一定回到原始提示词。

为什么内置人设这么短？发布到包仓库的内容会被扫描滥用性提示词，完整人设文本过不了扫描。所以内置文本只是占位示例，真正做实验时把自己的提示词放在本地、用/purge source引用。

0.1.x 升级到 0.2 要注意什么？0.2 不再读写pi-purge.json，也不自动探测提示词文件——旧的状态文件可直接删除，它已不被读取。

如何验证扩展行为符合预期？运行测试套件即可（两个套件均跑在临时 agent 目录，并断言全程不写任何文件）：

npm test

小结

pi-purge 把提示词 A/B 测试里最难的"条件切换与变量隔离"收敛成了一条/purge命令：三种模式对应对照、半隔离、单变量三组实验条件，会话级无盘设计保证了组间干净，/purge status提供了可留档的环境指纹。配合本文的五条控制变量准则和记录模板，你不需要任何额外框架，就能在本地 pi 里跑出一套结论可信的系统提示词对比实验。

• 完整命令与模式说明：README.zh-CN.md
• 核心实现（钩子、命令、切除逻辑）：extensions/pi-purge.ts
• 行为测试（含会话归零、回滚、无盘断言）：test/pi-purge.test.mjs