企业官网建设流程全解析

LifeOS 7.x 升级后旧 pai 启动别名失效怎么迁移

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS

把 7.x 之前的 LifeOS 安装升级到 7.x 之后，很多人发现终端里的pai启动别名出了问题：有的直接报文件不存在，有的还能启动 Claude 但 LifeOS 的宪法层（LIFEOS_SYSTEM_PROMPT.md）没有被加载。原因是 7.x 把PAI/目录树整体改名成了LIFEOS/，并把启动方式改成了"宪法化"的lifeos.ts -s LIFEOS_SYSTEM_PROMPT.md。这篇文章的迁移目标是：保持pai这个别名名不变（肌肉记忆继续可用），把它重新指向 7.x 启动器。适用环境是 Claude Code 配合 zsh/bash rc 文件；fish 用户需要按文档手动处理，后文单独说明。

两种旧别名为什么失效

pre-7.x 安装写入的pai别名只有两种历史形态（见 install.sh 的迁移注释）：

# 形态 1：裸 claude 启动 alias pai='cd ~/.claude && claude' # 形态 2：指向旧 PAI 目录树 alias pai='bun ~/.claude/PAI/ACTIONS/pai.ts'

升级到 7.x 后，这两条的失效方式不同：

• 形态 2 会死掉：PAI/目录树在 7.x 已不存在，bun找不到文件，启动失败；
• 形态 1 会静默降级：claude本身还能起，但没有通过启动器附加LIFEOS_SYSTEM_PROMPT.md，也就是 INSTALL.md 说的"bare-claudeform launches without the constitution"——会话里只有 CLAUDE.md，没有整套 operating contract。

7.x 的正确启动方式是由 启动器 携带宪法文件拉起 Claude：

bun <configRoot>/LIFEOS/TOOLS/lifeos.ts -s <configRoot>/LIFEOS/LIFEOS_SYSTEM_PROMPT.md

其中<configRoot>是bun Tools/DetectEnv.ts报告的配置根目录（Claude Code 下通常是~/.claude）。INSTALL.md 明确警告：不要用 DetectEnv 的实际结果，不要硬编码任何 home 路径。

哪些别名会被迁移、哪些绝不碰

install.sh 的检测是刻意收紧的，只有同时满足以下条件才算"旧别名"：

• 别名名是pai、kai或旧的lifeos（grep 模式alias[[:space:]]+(pai|kai|lifeos)=）；
• 且别名体包含/PAI/路径，或为裸&& claude启动形式；
• 且不包含LIFEOS_SYSTEM_PROMPT。

两条绝不触碰的规则：

1. 已包含LIFEOS_SYSTEM_PROMPT的当前 7.x 别名永远不会被改写；
2. 包含ARBOL/Actions/lifeos.ts的别名是维护者侧的 Arbol CLI（该目录树不在公开 payload 中），即使它出现在 rc 文件里也要原样保留。

所以如果你的 rc 里还有其他自定义别名，这次迁移不会波及它们。

路径一：让 7.x 引导脚本自动迁移（默认路径）

如果你是通过升级流程来到 7.x 的，别名迁移本来就在流程里：Update 工作流 检测到版本落后时会先运行随附的 bootstrap（bash <skillRoot>/install/install.sh），而 install.sh 的 Step 5/6 就是别名迁移本身。对 rc 文件它做的事：

1. 依次扫描~/.zshrc、~/.bashrc、~/.bash_profile、~/.profile；
2. 先把整个 rc 备份为<rc>.lifeos-backup-<时间戳>；
3. 命中的旧别名行被注释掉，并打上标记# [migrated to LifeOS <tag> — see .lifeos-backup]；
4. 在文件末尾为相同的别名名追加指向 7.x 启动器的新别名，并补一个规范的lifeos别名（如果 rc 里还没有）。

改写是幂等的——被注释掉的行不再匹配检测模式，重复运行脚本不会二次处理。

运行 bootstrap 前先说清它的副作用，因为它不止改别名：脚本会检查并自动安装 bun（≥ 1.2）、联网抓取最新 LifeOS release、把 LifeOS skill 增量写入 skills 目录、向配置根的.gitignore追加 3 条 Interceptor 截图捕获规则，最后自动进入/LifeOS setup（本机装有claude且不在 Claude Code 会话内时会直接exec claude "/LifeOS setup"）。也就是说，如果 7.x 文件已经在磁盘上、你只想要别名迁移，优先走下面的路径二，避免再跑一次完整 bootstrap。

bootstrap 入口（来自 INSTALL.md）：

curl -fsSL https://ourlifeos.ai/install.sh | bash

如果想在它动手前先预览别名迁移会改哪些文件，可以用 DRY-RUN 模式，此时不写任何文件：

DRY_RUN=1 bash -c 'curl -fsSL https://ourlifeos.ai/install.sh | bash'

命中旧别名时会看到类似输出（脚本实际字符串）：

[DRY-RUN] Would back up ~/.zshrc, comment the line(s) out, and repoint to the 7.x launcher.

正式运行后，脚本的成功判定输出同样是文档中的固定文案，可作为核对依据：

Repointed pai to the constituted 7.x launcher (backup: .zshrc.lifeos-backup-20260913-040506)

或没有任何旧别名时：

No stale pre-7.x launch aliases found.

如果不想让 bootstrap 碰别名（例如你在多机之间同步 rc，想完全手动控制），用LIFEOS_SKIP_ALIAS=1跳过这一步，脚本会打印Skipping alias migration (LIFEOS_SKIP_ALIAS=1).。

路径二：7.x 已在磁盘，手动改 rc 文件

当人是绕过 bootstrap 脚本完成 Setup 的（INSTALL.md 明确要求此时手动做同一件事），或你不想再触发完整 bootstrap 时，按下面顺序手动迁移。以 zsh 为例，bash 换成对应 rc 文件即可。

第 1 步：确认 7.x 启动器已就位。install.sh 在启动器缺失时只会注释旧别名并告警、不写新别名（"the LIFEOS launcher isn't placed yet"），所以手动迁移前先确认两个文件存在：

ls ~/.claude/LIFEOS/TOOLS/lifeos.ts ls ~/.claude/LIFEOS/LIFEOS_SYSTEM_PROMPT.md

两个文件都在才能继续；缺了就先完成 7.x 安装，别名迁移要等启动器落盘。

第 2 步：找出需要迁移的旧别名。用与 install.sh 相同的检测链，只列出不含LIFEOS_SYSTEM_PROMPT且属于两种历史形态的行：

grep -HE '^[[:space:]]*alias[[:space:]]+(pai|kai|lifeos)=' \ ~/.zshrc ~/.bashrc ~/.bash_profile ~/.profile 2>/dev/null \ | grep -v 'LIFEOS_SYSTEM_PROMPT' \ | grep -E '/PAI/|&&[[:space:]]*claude'

没有输出就说明没有旧别名需要迁移；有输出的每一行就是要处理的对象。

第 3 步：备份 rc 文件。与脚本的备份命名保持一致：

cp ~/.zshrc ~/.zshrc.lifeos-backup-$(date +%Y%m%d-%H%M%S)

第 4 步：注释旧行、追加新别名。把第 2 步命中的行前面加#注释掉，然后在 rc 文件末尾追加：

# LifeOS 7.x launch aliases (repointed from pre-7.x) alias pai='bun <configRoot>/LIFEOS/TOOLS/lifeos.ts -s <configRoot>/LIFEOS/LIFEOS_SYSTEM_PROMPT.md' alias lifeos='bun <configRoot>/LIFEOS/TOOLS/lifeos.ts -s <configRoot>/LIFEOS/LIFEOS_SYSTEM_PROMPT.md'

两处<configRoot>都替换成DetectEnv.ts报告的实际配置根（Claude Code 下为~/.claude）。按 install.sh 生成的风格，引号内保留为绝对路径——它写入 rc 的是单引号包裹的完整路径，而不是依赖~在单引号内展开。

第 5 步：重新加载 shell。开一个新终端，或在当前终端执行source ~/.zshrc，再核对别名已指向启动器：

type pai

输出应指向bun …/LIFEOS/TOOLS/lifeos.ts -s …/LIFEOS_SYSTEM_PROMPT.md这条命令。按 INSTALL.md 的判定标准，别名一旦调用该启动器，"launches Claude WITH the constitution"；而裸claude保持 vanilla，用户是通过显式输入pai（或lifeos）来选择加载宪法层的——这两点同时成立即迁移完成。

fish 用户：只能手动迁移

install.sh 只处理 zsh/bash 系 rc 文件。对 fish 的 funcsaved 别名，脚本注释 明确写着要按 INSTALL.md 第 7 步手动迁移。在 fish 里定义新别名并持久化：

alias lifeos "bun <configRoot>/LIFEOS/TOOLS/lifeos.ts -s <configRoot>/LIFEOS/LIFEOS_SYSTEM_PROMPT.md" funcsave lifeos

<configRoot>同样替换为 DetectEnv 的实际值。旧的 funcsavedpai不在脚本迁移范围内，需要你在 fish 里自行处理后再验证lifeos能正常启动。

限制与边界

• 启动器未落盘时：脚本和手动路径都只会先注释掉旧别名并告警，新别名要等/LifeOS setup把 LIFEOS 树写好后才有意义——所以第 1 步的文件检查不能省。
• Arbol CLI 别名不属于本次迁移：rc 里若出现指向ARBOL/Actions/lifeos.ts的别名，那是维护者侧的 Arbol CLI，公开 payload 不携带该目录树，原样保留。
• pai-freshness-v1之类的pai-前缀是文档 frontmatter 的 freshness 约定标记，与启动别名无关，不要混淆。
• fish 无自动化：fish 用户完全依赖手动，脚本不会代劳。

迁移完成后，pai、kai、lifeos这些旧入口会全部解析到 7.x 的lifeos.ts启动器，宪法层随每次启动加载；备份文件（*.lifeos-backup-*）留在原处，确认一切正常前不要删。

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS