LifeOS Migrate 技能深度解析外部存量内容智能摄入、分类路由与带溯源入库实战【免费下载链接】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导读LifeOS 的/migrateMigrate 技能解决所有用户在迁移到 LifeOS 时都会遇到的第一个问题多年积累的旧笔记、CLAUDE.md 规则、Cursor 规则、Obsidian/Notion/Apple Notes 导出如何不靠手工逐条整理就能分类归位到 LifeOS 的 TELOS / Knowledge / 身份 / 偏好等结构化体系中。本文以 Migrate 技能文档 为骨架结合其底层两个工具 MigrateScan.ts 与 MigrateApprove.ts 的源码完整讲解分类算法、置信度阈值、六阶段工作流与提交机制读完后你可以独立完成一次旧内容 → LifeOS 结构化归档的批量迁移。为什么需要 Migrate存量内容的分类困境当你采纳 LifeOS 时通常已经积累了数年的笔记资产——一份 CLAUDE.md、一个 markdown 笔记库、日志式日记、来自其他工具的规则文件。这些内容没有任何一种能天然对齐 LifeOS 的目录结构。如果靠手工把数百个片段分别归类到 TELOS 各章节、知识笔记和操作规则中这种枯燥工作几乎永远不会被完成旧材料最终只会闲置在角落里。Migrate 解决的正是这个问题它读取你已有的内容为每个片段chunk给出一个带置信度评分的目标落点允许你批量批准或逐个复核并在每次落库时附加来源溯源provenance确保任何内容进入 TELOS 都有据可查。文档中对应的自述是Migrates content into the LifeOS structure from external sources。与 /interview 的本质区别Migrate 技能文档开篇就划清了边界与/interview通过提问补全空白不同/migrate已经持有内容——它不需要用户提供新信息只需要对已有内容做分类classify和路由route。这是一个摄入intake型操作而非访谈interview型操作。支持的数据源与分类目标体系V1 支持的数据源根据技能文档Migrate V1 覆盖以下来源文件.md、.markdown、.txt支持单个文件或目录递归扫描标准输入管道输入或直接粘贴内容其他 LifeOS 实例直接指向其USER/TELOS/或MEMORY/KNOWLEDGE/目录Agent 框架规则文件CLAUDE.md、.cursorrules、OpenAI Custom Instructions 导出各类导出Obsidian 库markdown、Notion 导出markdown、Apple Notes 导出.txt、原始日志转储源码中 MigrateScan.ts 的 readSource 函数 印证了这些来源单文件直接读取目录则递归遍历只收集/\.(md|txt|markdown)$/i命中的文件--stdin模式从文件描述符 0 读取。若路径不存在会报错退出Source does not exist: path。分类目标五大类别路由表类别落点目标Foundational TELOS基础层MISSION, GOALS, PROBLEMS, STRATEGIES, CHALLENGES, BELIEFS, WISDOM, MODELS, FRAMES, NARRATIVES, SPARKSIDEAL_STATE 维度HEALTH, MONEY, FREEDOM, RELATIONSHIPS, CREATIVE, RHYTHMS偏好文件BOOKS, AUTHORS, MOVIES, BANDS, RESTAURANTS, FOOD_PREFERENCES, LEARNING, MEETUPS, CIVIC身份信息USER/PRINCIPAL/PRINCIPAL_IDENTITY.md知识MEMORY/KNOWLEDGE/{Ideas,People,Companies,Research}AI 协作规则逐个 walk-through 到宪法性表面constitutional surface——CLAUDE.md 操作规则、hook、settings.json、或相关技能skill的 Gotchasalways do X/never Y 这类模式属于系统补丁绝不允许写入 harness 的memory/feedback_*.md备忘不明确内容标记为 UNCLEAR交由用户手动路由这些目标在源码中体现为一个名为Target的联合类型MigrateScan.ts精确列出了全部 32 个目标值与上表一一对应。仓库中实际的 TELOS 文件存在于 LifeOS/install/USER/TELOS/如MISSION.md、GOALS.md、BELIEFS.md、IDEAL_STATE/等身份落点为 LifeOS/install/USER/PRINCIPAL/PRINCIPAL_IDENTITY.md。运行架构扫描器与审批器两段式管线技能文档明确指出Migrate 没有独立的Workflows/目录整个迁移过程以内联的 Phase 1–6 展开由LIFEOS/TOOLS/下的两个工具支撑触发方式工作流支撑文件/migrate、迁移内容、批量导入、从其他 LifeOS 导入、导入 CLAUDE.md / Cursor 规则 / Obsidian / Notion / Apple Notes 导出、带入旧笔记内联 Phase 1–6识别 → 扫描 → 路由 → 审批 → UNCLEAR → 总结MigrateScan.ts MigrateApprove.ts这条管线的数据流是MigrateScan 产出建议队列 → MigrateApprove 按用户选择提交。两个工具通过一个 JSONL 队列文件衔接队列文件LIFEOS_DIR/MEMORY/MIGRATION/migration-proposals.jsonl其中LIFEOS_DIR默认为~/.claude/LIFEOS可通过环境变量LIFEOS_DIR覆盖MigrateScan.ts提交日志LIFEOS_DIR/MEMORY/MIGRATION/committed.jsonl每次成功提交都会追加一条完整记录MigrateApprove.ts每个建议Proposal对象包含idUUID、时间戳、源文件、源章节、内容预览前 160 字符与全文、建议目标、置信度0–1、分类理由、备选目标、状态pending | approved | rejected | modified。分块算法按标题或段落组切分MigrateScan 的chunkContent函数源码 L178-L202采用两套分块策略标题分块若内容存在##/###级标题则按^(#{2,3}\s.)$正则切分正文前的部分标记为文件名:preamble每个标题下的正文作为独立 chunk段落分块无标题的内容按双空行\n\s*\n切分为段落组仅保留长度超过 30 字符的段落标记为文件名:pN。此外主流程还会跳过正文长度不足 40 字符的琐碎片段if (body.length 40) continue;。这一设计决定了代码注释、日志、原始数据这类碎片容易被过滤或归类失败——这也是技能文档 Gotchas 里警告genre-mismatched 来源的原因。分类机制关键词规则加权 置信度公式分类核心在classify函数源码 L206-L244和全局RULES规则表源码 L101-L145。其原理是每条规则 { target, patterns[], weight }用一组正则模式大小写不敏感去匹配 chunk 正文命中一个模式计 1 次乘以该规则的权重后累加为该目标的得分所有目标按得分降序排列取第一名作为建议目标第二至四名作为备选alternatives无任何模式命中时直接判为UNCLEAR置信度为 0。置信度并非简单的命中数而是第一名与第二名之间的分差margin参与计算的相对量confidence min(1, (margin totalScore * 0.3) / 10)其中margin 第一名得分 - 第二名得分。这意味着同类内容越多、类别间区分越明确置信度越高如果多个目标得分接近即使总得分很高置信度也会被压低从而触发人工确认。规则权重也体现了设计意图——例如反馈/协作规则类always/never do X权重为 3是最高档基础 TELOS 大多为 2身份与知识类多为 1。值得注意的细节是memory/feedback规则中的 DA 名称模式是在运行时通过getDAName()解析并正则转义后动态构建的MigrateScan.ts该函数来自 hooks/lib/identity.ts这样无论你的 DA 叫什么名字都能正确识别when should…这类反馈句式。命令行完整参数MigrateScan用法见源码注释 L21-L27bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --source file # 扫描单个文件 bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --source dir # 递归扫描目录内 .md/.txt bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --stdin # 从标准输入读取 bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --source X --json # JSON 输出供审批管线使用 bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --source X --dry-run # 预览不写入队列--source与--stdin必须二选一。默认模式非--json会在终端输出扫描摘要来源数、提取的 chunk 总数、平均置信度、按目标分组的建议路由表//❓图标区分普通目标/反馈/UNCLEAR并提示低置信度40%与 UNCLEAR 的数量--dry-run不会写入队列文件。MigrateApprove用法见源码注释 L21-L30bun MigrateApprove.ts --review # 列出所有待处理建议 bun MigrateApprove.ts --summary # 队列高层汇总按目标统计 bun MigrateApprove.ts --approve id # 提交单个建议 bun MigrateApprove.ts --modify id --target X # 修改目标后提交 bun MigrateApprove.ts --reject id # 丢弃单个建议 bun MigrateApprove.ts --approve-target target # 批量提交某目标的所有建议 bun MigrateApprove.ts --approve-all # 提交所有待处理建议跳过 UNCLEAR bun MigrateApprove.ts --reset # 清空队列慎用六阶段迁移工作流技能文档将完整流程组织为内联的 Phase 1–6以下为完整展开。Phase 1 — 识别来源先向用户确认要迁移什么典型对话选项包括把内容粘贴给我我从 stdin 处理指给我一个文件路径指给我一个目录我扫描里面所有内容我有一个 Cursor 规则文件在~/Projects/X/.cursorrules我的旧 LifeOS 安装的 TELOS 在~/old-claude/TELOS/收集到来源路径后如果内容是直接粘贴的先写入临时文件再进入扫描。Phase 2 — 扫描运行扫描器bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --source path # 或 echo $CONTENT | bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --stdin扫描器输出包含chunk 总数、建议路由表每个目标各多少 chunk、平均分类置信度、UNCLEAR 数量、低置信度40%chunk 数量。生产环境中建议先加--dry-run预览避免误写队列。Phase 3 — 呈现路由摘要以可扫读的格式向用户展示路由建议Found 47 chunks from 3 files. Proposed routing: TELOS/GOALS.md 12 chunks (78% avg confidence) TELOS/WISDOM.md 8 chunks (65% avg confidence) TELOS/BELIEFS.md 6 chunks (71% avg confidence) MEMORY/KNOWLEDGE/Ideas 15 chunks (52% avg confidence) AI collaboration rules 4 chunks (walk-through: CLAUDE.md / hook / skill) ❓ UNCLEAR 2 chunks (needs your call) Options: - Approve everything trusted (confidence ≥60%)? - Walk through the low-confidence and UNCLEAR chunks one by one? - Review specific categories? - Review everything?Phase 4 — 审批循环根据用户偏好进入三种路径之一快速路径用户说批准所有可信内容bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --approve-all提交所有非 UNCLEAR 的建议然后对话式逐个处理 UNCLEAR 片段。分类路径用户说批准 goals 和 wisdom跳过 knowledgebun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --approve-target TELOS/GOALS.md bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --approve-target TELOS/WISDOM.md逐个走查路径用户希望仔细复核bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --review逐个展示待处理 chunk每个都包含预览 建议目标 置信度 备选目标然后请用户在批准 / 修改目标 / 拒绝三选一记录决策并提交。Phase 5 — 处理 UNCLEAR 片段UNCLEAR 是指没有任何分类规则强匹配的片段。对每个 UNCLEAR显示完整内容而非仅预览询问用户这条不明确——它是什么可能是 X、Y、Z或者用 Knowledge/Ideas 作为兜底用户选定后通过--modify id --target chosen提交源码层面UNCLEAR 建议无法被直接提交commitProposal会报错Cannot commit UNCLEAR proposal. Use --modify first.MigrateApprove.ts L94-L98--approve-all也会主动跳过 UNCLEAR 并将它们保留在队列中等待人工路由源码 L264-L277。Phase 6 — 完成总结审批结束后报告已提交的 chunk 总数、各目标提交数量标记仍剩余的 UNCLEAR建议下一步运行/interview围绕迁移后仍显稀疏的部分进行访谈补全提交机制详解三种落库方式与溯源MigrateApprove.ts的commitProposal函数源码 L94-L163根据目标类型走三条不同路径这是理解迁移后文件长什么样的关键1. 常规 TELOS / USER 文件追加模式目标为TELOS/…、USER/…时把 chunk 全文追加到现有文件的末尾并在内容前插入一行 HTML 注释作为溯源!-- migrated ISO时间戳 from 源文件 :: 源章节 --对应技能文档规则每个提交都携带 provenance提交内容包含标注源文件 章节 时间戳的 HTML 注释任何内容都不会在无归因的情况下落入 TELOS。如果目标文件不存在提交会失败并报错Target file does not exist。2. Knowledge 知识目录每个 chunk 一个新文件目标为MEMORY/KNOWLEDGE/*时每个 chunk 生成一个新文件migrated_slug_id前8位.mdslug 由源章节名清洗生成非字母数字替换为连字符、小写、截断 40 字符文件带结构化 frontmatter--- title: 源章节 type: idea|people|company|research tags: [migrated] created: 日期 source: 源文件路径 ---这正是技能文档规则知识也会产生新文件每个MEMORY/KNOWLEDGE/*chunk 都成为一条带来源元数据的新类型化笔记的落地实现。3. feedback 反馈每个 chunk 一个新文件目标为memory/feedback时同样按 chunk 生成新文件feedback_migrated_slug_id前8位.md带name/description/type: feedback/createdfrontmatter。注意源码中该路径映射到~/.claude/projects/${HARNESS_USER_DIR}/memoryL82-L92即 harness 的自动记忆目录——这与技能文档的宪法性表面规则存在张力详见下一节。每次成功提交都会追加一条完整记录到committed.jsonl形成可审计的迁移历史。置信度阈值与审批决策矩阵技能文档给出了明确的阈值约定≥70%可信trusted可自动批准40–70%中等medium需展示确认40%低low必须走查在实际交互中Phase 3 路由摘要给出的是批准全部可信≥60%的快速路径选项--review输出会用✅≥60%与⚠️60%图标区分建议MigrateApprove.ts L177。三者共同构成一套扫描器给分、审批器分级、人工兜底的决策体系。迁移规则与安全边界技能文档列出以下硬性规则均为迁移过程中的不可违背项每个提交携带 provenance——HTML 注释标注源文件 章节 时间戳详见上文提交机制绝不批量批准 UNCLEAR——必须由用户显式路由置信度阈值≥70% 自动批准候选、40–70% 需确认、40% 必须走查触碰身份文件前必须询问——PRINCIPAL_IDENTITY.md的提交总是先弹提示因为该文件是承重墙load-bearing它在每次会话启动时被加载LifeOS/install/USER/PRINCIPAL/PRINCIPAL_IDENTITY.md 中的身份信息直接影响 DA 的对齐度不重复——若目标中已存在相同内容子串匹配标记出来并在追加前询问尊重私有路径——未经用户按维度逐项确认绝不向IDEAL_STATE/迁移内容决策 #3IDEAL_STATE 完全私有且精修规则永不写入 harness memory——AI 协作规则类 chunk 总是逐个走查并路由到宪法性表面CLAUDE.md 中的操作规则、hook、settings.json权限、或相关技能的 Gotchas。写入 harness 的memory/feedback_*.md目录是被禁止的——每个 feedback 备忘都是一次错过的系统补丁参见系统提示中的 Override of harness auto-memory。关于第 7 条需要说明一个从源码中观察到的细节扫描器确实会把 always/never do X、from now on、rule: 这类模式识别为memory/feedback目标权重 3且动态匹配 DA 名称MigrateApprove 也具备写入 harness memory 的代码路径。但技能文档明确规定这类 chunk 必须走 walk-through 并由用户路由到宪法性表面而非 harness memory——因此使用--approve-all前必须确认队列中没有 AI 协作规则类 chunk这正是规则 7 与 Phase 4 走查路径存在的意义。实战示例技能文档给出了四个代表性场景完整继承如下示例 1/migrate ~/old-claude/TELOS/DA 扫描旧 TELOS 目录对每个 chunk 分类呈现路由摘要提供快速路径与逐个走查两种审批方式。示例 2/migrate然后粘贴 CLAUDE.md 内容DA 从 stdin 读取将大部分 chunk 归类为 AI 协作规则逐个走查至 CLAUDE.md / hooks / 技能 Gotchas如果内容中混入了身份陈述行则可能同时产生 PRINCIPAL_IDENTITY 建议随后进入走查审批。示例 3migrate my Cursor rules at ~/.cursor/rulesDA 扫描规则目录列出可能的规则分类对每个规则走查至宪法性目的地并格外小心——Cursor 规则常含工具特定内容无法直接翻译到 LifeOS。示例 4import the stuff I dumped in /tmp/journal.mdDA 扫描日志预期会得到大量 UNCLEAR 与 WISDOM 分类对每个章节逐个走查。常见问题与 Gotchas技能文档在末尾给出了三个高频故障模式及其处置建议平均置信度过低40%来源大概率是类型错配genre-mismatched例如代码注释、日志、原始数据。建议先做预处理过滤掉非散文片段再扫描。一切都被归为 UNCLEAR来源中没有可识别的 LifeOS 分类学模式。此时应通过/Telos手动添加内容或写成通用 Knowledge 笔记。重复内容警告扫描器目前尚不会对照现有文件去重。提交前先运行--dry-run预览再决定是否提交。相关技能与延伸阅读技能文档列出了与 Migrate 相邻的能力便于迁移完成后继续深化/interviewInterview 技能——通过提问补全空白而非摄入已有内容/TelosUpdate 工作流——直接编辑单个 TELOS 文件/Knowledge——管理知识档案身份档案类技能——管理PRINCIPAL_IDENTITY。迁移完成后建议按 Phase 6 的指引运行/interview补全稀疏区域对于 AI 协作规则类内容可结合 LifeOS 技能 与系统提示 LIFEOS_SYSTEM_PROMPT.md 理解宪法性表面的整体设计。理解本文后你可以安全地实践先--dry-run预览、审查路由表、按目标批量批准或逐个走查最终让积累多年的旧笔记真正进入 LifeOS 的结构化体系而不是沉睡在迁移前的角落。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
