给 AI 编程助手设置固定的人格或工作规范并不难，难的是把它做成一套能长期使用的工具：换一台电脑仍然能找到软件，多个目标可以独立选择，更新失败后可以定位原因，最重要的是随时能够恢复原状。

我最近把一个最初只能修改 WorkBuddy、依赖固定路径和固定“人格.txt”的脚本，逐步改造成了一个支持 WorkBuddy 与 Hermes 的 Windows 部署器。它会扫描多个人格文件，让用户分别选择要注入的软件与人格，并为两种软件提供状态检查、备份和恢复能力。

这篇文章记录这套方案的设计思路、关键实现和实际踩坑经验。它不是任何软件厂商提供的官方功能，更适合用于自己的设备、测试环境和可控范围内的个性化配置。

最初的问题：能用，但不够可靠

最早的版本只有一条固定流程：从指定位置读取一个固定名称的人格文件，再修改 WorkBuddy。只要换一台电脑、软件安装路径改变，或者用户想给另一个软件使用不同人格，脚本就会失效。

一套真正可复用的部署器至少应该解决以下问题：

• 自动扫描 人格\*.txt，不再把文件名写死。
• 每个软件单独选择，避免运行一次就同时修改所有软件。
• WorkBuddy 与 Hermes 可以分别使用不同人格。
• 自动识别软件目录，兼容不同电脑和安装方式。
• 修改前创建备份，失败时自动回滚。
• 提供状态检测与恢复入口。
• 软件更新覆盖补丁后，能够快速重新部署。

推荐的目录结构

部署包可以保持得很简单：

<部署目录>\
├─ deploy.ps1
├─ install.bat
├─ status.bat
├─ restore.bat
└─ 人格\
   ├─ 专业开发.txt
   ├─ 中文助手.txt
   └─ 代码审查.txt

人格文件名直接作为菜单中的显示名称。这样添加人格时只需放入新的 .txt 文件，不需要再次修改脚本。

第一步：动态扫描并选择人格

PowerShell 可以直接枚举人格目录：

$personaDir = Join-Path $PSScriptRoot '人格'
$personaFiles = Get-ChildItem -LiteralPath $personaDir -Filter '*.txt' -File |
    Sort-Object Name

if ($personaFiles.Count -eq 0) {
    throw '人格目录中没有找到 .txt 文件'
}

当目录中只有一个文件时，可以自动选中；存在多个文件时，再显示编号菜单。脚本还应只接受扫描结果中的文件名，拒绝 ..\ 等路径跳转，避免用户输入意外访问人格目录之外的文件。

这个改动看似简单，却把“修改代码才能增加人格”变成了“复制一个文本文件即可扩展”。

第二步：软件与人格分开选择

部署器不应该默认同时修改所有目标。更合适的交互方式是先选软件，再选该软件要使用的人格：

请选择目标软件：
[1] WorkBuddy
[2] Hermes
[0] 退出

请选择人格：
[1] 专业开发.txt
[2] 中文助手.txt
[3] 代码审查.txt

完成一次部署后返回主菜单，用户可以继续给另一个软件选择不同人格。这使两个软件彼此独立，也降低了误修改的风险。

命令行模式同样值得保留，方便排错和自动化：

# 查看状态
powershell -ExecutionPolicy Bypass -File .\deploy.ps1 status workbuddy

# 给 Hermes 部署指定人格
powershell -ExecutionPolicy Bypass -File .\deploy.ps1 install hermes "专业开发.txt"

# 恢复 WorkBuddy
powershell -ExecutionPolicy Bypass -File .\deploy.ps1 restore workbuddy

日常使用可以双击批处理菜单；出现问题时，命令行输出通常更利于定位。

第三步：自动识别安装目录

把 C:\Program Files\某软件 写死只能覆盖一种安装方式。更稳妥的做法是按可信度逐层探测：

Hermes 还可以优先读取 HERMES_HOME。如果用户主动设置了环境变量，它应高于自动猜测结果。

检测完成后必须验证关键文件是否存在，而不是只判断目录名称。例如，找到 WorkBuddy 目录后还要确认目标 bundle 确实位于预期的 resources 子目录中。这样换电脑或换盘符时，大部分情况无需改脚本；真正不兼容时也能给出明确错误。

两个软件，两种不同的注入方式

“把人格写进软件”并不存在一个通用位置。两个目标的内部机制不同，部署方式也必须分别设计。

WorkBuddy：在请求发送层注入

WorkBuddy 的实现需要修改负责构建模型请求的 JavaScript bundle。为了兼容不同接口，部署器同时检查 /chat/completions 与 /responses 两类请求，并覆盖普通与 headless 两个 bundle。

这种方式的优势是注入位置明确；缺点是与具体软件版本绑定。部署后不能只看脚本是否运行成功，还应该统计每个 bundle 找到并修改了多少个目标点。预期数量不符时应立即报错，而不是留下一个表面成功、实际无效的版本。

Hermes：使用原生 SOUL.md

Hermes 提供了更自然的人格入口。部署器找到所有 profile 后，将选定人格写入各 profile 的 SOUL.md，同时保留原文件备份。

相比修改程序文件，原生配置最稳定，也最容易理解和恢复。只要软件本身支持正式的系统提示词或人格文件，应优先使用这种集成方式。

备份、验证与恢复是核心功能

直接修改已安装软件的内部文件有风险，因此部署过程应当像一个小型事务：

1. 确认目标软件和关键文件。
2. 关闭可能占用文件的相关进程。
3. 首次修改前保存原始 .bak。
4. 写入补丁或配置。
5. 执行语法及注入点检查。
6. 失败时自动恢复备份。
7. 输出最终状态和下一步操作。

恢复功能也必须区分不同目标：WorkBuddy 恢复 bundle 与相关模板，Hermes 恢复各 profile 的 SOUL.md。

备份应保存“第一次修改前的原始版本”，而不是每次部署都覆盖。否则第二次部署时，备份里可能已经是修改后的文件，恢复也就失去了意义。

软件更新后为什么又失效了

在实际检查中出现过一种很典型的状态：Hermes 的人格仍然有效，但 WorkBuddy 的注入点变为零。

原因并不神秘：WorkBuddy 的方案修改了安装目录中的程序文件，软件更新会用新版文件覆盖这些补丁；Hermes 使用的是用户配置目录下的原生 SOUL.md，升级通常不会替换它。

因此，部署器应把“状态检查”放在明显位置，并把以下流程视为日常维护的一部分：

软件更新 → 运行状态检查 → 补丁被覆盖 → 重新部署 → 再次验证

更进一步，可以记录已部署人格、目标文件哈希和软件版本。当文件版本变化时主动提示重新部署，但不要在后台静默改写软件。

脚本下载地址：

提取文件 · 爱搜云盘

输入 5 位取件码即可提取爱搜云盘中的文件，支持有效期校验与过期提示。

▤

常见故障排查

WorkBuddy 显示成功，但人格没有变化

先运行 status workbuddy，检查两个 bundle 的注入点数量。如果为零或少于预期，通常是软件升级后代码结构变化，旧的匹配规则已经找不到目标。此时需要针对新版 bundle 重新定位请求构建逻辑，不能简单重复覆盖。

换电脑后找不到软件

先启动目标软件，再运行部署器，让脚本优先从进程路径识别。仍然失败时，检查软件是否为便携版或商店版，并将该安装方式加入探测规则，而不是重新写死另一条个人路径。

隐私与安全边界

人格部署脚本本身可以做到完全本地运行、不上传文件，但这不代表人格内容永远不会离开电脑。人格一旦被加入模型请求，就会随正常对话一起发送给所配置的模型服务商。

使用前建议遵守几条底线：

• 不要在人格文件里保存密码、令牌、客户数据或个人隐私。
• 阅读人格文本，确认它没有诱导泄露文件、上传数据或执行危险命令。
• 阅读部署脚本，确认它没有网络上传、远程下载或隐藏持久化行为。
• 只在自己有权管理的电脑和软件上使用。
• 修改安装目录通常需要管理员权限，也可能影响软件完整性校验和官方支持。
• 不要使用要求绕过安全限制、破坏系统或隐瞒行为的人格提示词。
• 保留原始备份，并确保恢复命令在部署前就能工作。

ExecutionPolicy Bypass 只是允许本地 PowerShell 脚本运行，并不等于脚本可信。真正的信任来自源码审查、明确的修改范围和可验证的恢复机制。

最终得到的不是“注入脚本”，而是一套部署流程

当工具从单一固定路径扩展到多软件、多个人格后，最有价值的部分已经不只是写入提示词，而是围绕变更建立了一套完整流程：自动发现、明确选择、精准修改、结果验证、状态检查和一键恢复。

如果以后再接入新的 AI 软件，可以先问三个问题：

1. 它是否提供官方的系统提示词或人格配置入口？
2. 人格内容最终在请求链路的哪一层生效？
3. 软件升级后，怎样检测变更并安全恢复？

优先使用官方配置；没有官方入口时，才考虑对程序文件做可恢复的本地补丁。这样得到的工具可能没有“一次修改永久有效”那么理想，却更诚实、更容易维护，也更适合长期使用。

提示：本文讨论的是本地个性化和部署工程实践。不同版本的软件内部结构可能随时变化，请在操作前备份数据，并遵守相应软件的使用条款。