企业官网建设流程全解析

LifeOS Mission 层实战指南：用 MISSION.md 定义你的持久北极星，让 DA 在每次会话中为你校准方向

【免费下载链接】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 的 TELOS（个人操作系统中的"为什么"层）中，Mission（使命）是比 Goals 更持久、更上层的存在——它是你做事的根本原因，是 DA（数字助理）在每次会话开始时读取、并在做任何权衡取舍时优先引用的"北极星"。本文以仓库中随安装器分发的 MISSION.md 模板为骨架，结合GenerateTelosSummary.ts、TelosFreshness.ts等源码实现，讲清楚三个问题：Mission 在 LifeOS 数据层中的位置、模板的正确写法与填充方式，以及系统是如何解析、保鲜并把它注入每一次会话上下文的。读完你可以直接在自己的 LifeOS 安装中把占位符换成真实使命，并理解背后每一行配置和命令的作用。

一、Mission 在 LifeOS 中的位置：TELOS 是"为什么"层

LifeOS 把个人数据按层次组织，其中TELOS承载的是你人生层面的"为什么"——你试图用一生做成什么、什么在阻碍你、你打算怎么处理。仓库中的 TELOS/README.md 明确说明：

TELOS is your personal "why." It describes what you're trying to do with your life, what's getting in the way, and how you plan to handle it. LifeOS reads it at every session start so the DA understands the context behind any work you ask for.

也就是说，TELOS 不是一个被动存档，而是每次会话启动时都会被 DA 读取的上下文。整个TELOS目录包含多个主题文件：

从源码结构看，Mission 是被显式建模为"基础且慢变"的数据：TelosFreshness.ts中的新鲜度配置把mission设为90 天，与beliefs、models、frames并列，注释写明这是 "Slow-moving foundational — quarterly review cadence"。换句话说，系统假设使命是季度级审查的稳定层，而不是周更的动态目标。

二、MISSION.md 模板逐段拆解：三句话定义你的使命

随安装器分发的 MISSION.md 是一个provenance: template的样本文件，它的作用是展示 Mission 数据的形状（SHAPE），文件头部的提示写得非常直白：

This file shows the SHAPE of your TELOS data. Every entry below is a placeholder. Run/interview(or talk to your DA) to replace these samples with your actual mission, goals, beliefs, etc.

模板的核心是三个编号条目，采用- **Mn:** (sample) 一句话描述的列表格式：

• M0— 最核心的使命："Help the people I care about live better — clearer thinking, more agency, fewer needless obstacles."（帮助我在乎的人活得更好——更清晰的思考、更多的自主权、更少的无谓障碍。）
• M1— 对领域/社区的增益："Leave my field, my community, or my craft a little better than I found it."（让我的领域、社区或手艺比我发现它时更好一点。）
• M2— 可选的超越性愿景（标注为 aspirational, optional）："Make something that's still useful long after I'm gone."（做出在我离开很久之后仍有用的东西。）

注意 M2 的标注——它明确写了aspirational, optional，说明模板在设计上区分了"必须回答"与"可以有野心"两层。写真实使命时，M0 是必填的根基，M1 是对外的增量承诺，M2 是留给长期主义的弹性空间。

Mission 与 Goals 的本质区别

模板的## Notes段落给出了 LifeOS 判定使命的核心判据，这是整份文档最有分量的方法论：

Missions are more stable than goals. A goal is done when its ISCs pass; a mission keeps going. If your mission list shifts every few months, you're describing goals.

判定标准：目标是可完成的——当它的 ISC（可度量成功标准）通过时目标就"结束"；而使命是持续进行的，永不"达成"。一个实用的自检：如果你的使命列表每隔几个月就变动，你写的其实是目标。

模板还提供了一个写作引导问题："if the world had more of X because of you, what would X be?"（如果世界因你而更多地拥有了 X，那个 X 是什么？）——用这个句式逼出使命而非目标。对照 GOALS.md 的样本可以看出差异：目标长这样——"Ship MVP of Project X by 2026-Q2 — measurable: 100 daily active users"，带明确日期与度量；而使命没有任何截止日期。

三、填充 Mission 的三种方式

TELOS/README.md 给出了三条填充路径，按推荐程度排序：

1. 最省事：运行/interview。安装完成后运行该命令，它会按顺序走完 TELOS 的各个 phase，提出正确的问题，并把你的回答写入TELOS.md——把每个(sample)占位符替换成真正属于你的内容。每个 phase 结束时它会自动调用摘要生成器。
2. 手动编辑：直接打开TELOS.md，在对应## Mission的 H2 小节下删掉占位符、写入真实内容。README 强调"Keep entries short and high-signal; the DA reads this at session start"——DA 在会话启动时读取它，所以要短而高信号，不要长篇大论。
3. 从已有数据迁移：如果你在 Obsidian、Notion、日记或旧的 Telos 仓库里已有使命/目标，先运行Migrateskill 再跑/interview，让访谈只补缺口、而不是让你重打一遍。

一个容易踩的坑是文件职责：虽然MISSION.md等拆分文件仍在目录里，但 README 明确指出它们只是legacy samples，仅供向后兼容展示形状，工具只会在TELOS.md缺少对应##section 时才回退读取它们。正确方向是统一收敛进TELOS.md，不要把一个统一的TELOS.md重新拆回多个主题文件。

四、源码视角：Mission 如何被解析与注入会话

1.GenerateTelosSummary.ts：从 MISSION.md 提取使命

摘要生成器 GenerateTelosSummary.ts 是连接"你的数据"与"每次会话上下文"的桥梁。它的parseMissions()实现如下：

/** * Parse mission items from MISSION.md */ function parseMissions(): string[] { const content = readTelosFile('MISSION.md'); const items = parseItems(content, 'M'); return items.map(i => `- **${i.id}**: ${truncate(i.text, 75)}`); }

关键点：它按M前缀的 ID（M0、M1、M2…）解析条目，并截断到 75 字符——这就是为什么模板要求使命"短而高信号"。生成结果被写入 PRINCIPAL_TELOS.md 的## Missions小节，该文件的 frontmatter 明确标注generator: LIFEOS/TOOLS/GenerateTelosSummary.ts与derived_from: LIFEOS/USER/TELOS/TELOS.md，并且头部警告"Do not edit manually"——它会被加载进每次会话，手动编辑会在下次生成时被覆盖。

源码中还有一层回退逻辑（LEGACY_FILE_TO_SECTION映射）：MISSION.md对应missionsection。只有当TELOS.md中没有## Mission小节时，工具才回退到拆分文件——这与 README 中"legacy 向后兼容"的说明完全吻合。另外值得注意的边界情况：TELOS.md是手写的，历史上曾出现过## MISSIONS（复数）无法命中mission（单数）查找键、导致 section 渲染为空的问题（源码注释引用了公开 issue），所以务必保持标题与模板一致：## Mission。

2.TelosFreshness.ts：使命的新鲜度保鲜

TelosFreshness.ts 用<!-- updated: YYYY-MM-DD by:who -->这类标记追踪每个 section 的最近审查时间，并据此判定"过期"。其中：

// Slow-moving foundational — quarterly review cadence mission: 90, beliefs: 90, models: 90, frames: 90,

mission的新鲜度窗口是90 天。这意味着：系统建议你每季度至少回看一次使命；超过 90 天未更新，新鲜度机制会把它标记为 stale，提示你重新校准。这是对模板中"使命比目标稳定"的方法论在代码层面的制度化——目标类数据的刷新节奏更短，而使命按季度计。

3. 会话注入链路

整条链路可以这样概括：你编辑TELOS.md→ 运行bun ~/.claude/LIFEOS/TOOLS/GenerateTelosSummary.ts重新生成PRINCIPAL_TELOS.md→ 每次会话启动时 DA 通过CLAUDE.md加载摘要 → DA 在权衡任何取舍时优先保护使命。正如PRINCIPAL_TELOS.md尾部所写："This file is the DA's compressed view of who you are and what you're trying to do. The Algorithm uses it to prioritize…"—— 凡是阻碍使命的事，会被系统视为高信号（high-signal）优先处理。

/interview命令在完成每个 phase 后会自动触发摘要再生成，所以日常你并不需要手动跑生成命令；只有当你绕过访谈、直接手改TELOS.md时，才需要手动执行上面的命令保持同步。

五、实战建议：写出一份合格的 Mission

综合模板方法与源码约束，落地时建议遵循以下几点：

1. 三句起步，从 M0 写起：先用模板的引导句式 "if the world had more of X because of you…" 写 M0，再补 M1（对外的增量承诺），M2 可选。
2. 用"能否完成"自检：如果一句话可以用"做到 X 日期前完成某事"来重写，那它是目标不是使命。使命没有终点的判据是：即使所有目标都达成，它依然在。
3. 控制长度：parseMissions()会截断到 75 字符，DA 在会话启动时读取它——写得太长会被截断，写得太散会稀释信号。
4. 保持标题一致：统一写在TELOS.md的## Mission（单数）小节下，避免## MISSIONS这类复数标题导致解析落空。
5. 按季度维护：利用 90 天新鲜度窗口，把使命审查放进季度节奏；改动后通过/interview或手动运行GenerateTelosSummary.ts重新生成摘要。

结语

Mission 是 LifeOS 中最简单也最容易被忽略的数据层：它不过是一份三行的列表，却决定了 DA 在每一次权衡时的优先级。理解 MISSION.md 模板背后的设计——为什么使命要比目标稳定、为什么要短、为什么要写进单一事实来源TELOS.md——你就能让整个系统从"帮你做任务"升级为"帮你过对的一生"。运行/interview，从替换 M0 开始。

【免费下载链接】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