企业官网建设流程全解析

LifeOS Identity 身份页模板深度解读：用一份 Markdown 文件承载"我是谁"，驱动意图工程系统

【免费下载链接】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 开源仓库中的身份页模板 Identity.md 为骨架，完整解析其 frontmatter 契约（category/kind/publish/review_cadence/provenance）与四段式正文结构，并结合仓库内 Pulse 渲染管线、DA 会话加载机制与发布生命周期，说明一份模板文件如何在 LifeOS 的意图工程体系中落地为"每轮对话都被 DA 读取的身份参考"。读完本文，你将掌握该模板的用法、底层源码依据，以及把它定制成个人身份文件PRINCIPAL_IDENTITY.md的完整实操路径。

一、模板定位：USER_TEMPLATES 是 Pulse 页面的出厂脚手架

Identity.md位于 USER_TEMPLATES 目录下，该目录随每个 LifeOS 版本发布，与 README.md 中声明的约定一致：目录内每个*.md文件都是一个 Pulse v2 页面的起步脚手架（starter scaffold）。

与Identity.md同级的模板共有五个，分别对应不同 Pulse 页面：

README 给出了模板的标准使用流程：

1. 复制到 USER 目录（不带_TEMPLATES后缀）：

   cp LIFEOS/USER_TEMPLATES/Books.md LIFEOS/USER/Books.md

2. 编辑文件，填入自己的内容。Pulse 会检测到变更，并自动把 frontmatter 中的provenance: template翻转为provenance: customized。
3. 或者直接删除模板、从零编写——Pulse 只要求文件存在于 manifest 指向的路径即可。

值得注意的是：provenance是模板体系的核心开关。provenance: template表示该文件会被公共发布管线包含进下一个版本；provenance: customized则会被发布管线排除，你的编辑保持私有。这一机制保证"出厂内容人人一致、个人改动永不泄漏"。

二、Identity.md 逐段解析：frontmatter 契约与四段正文骨架

模板正文虽短，但它是"身份这个概念在 LifeOS 中的最小可渲染形态"。完整内容由 YAML frontmatter 与四个二级标题段落组成：

--- category: identity kind: narrative publish: false review_cadence: 180d provenance: template last_updated: 2026-05-03 --- # Identity Who you are, in one short reference. Replace with your own framing. ## Quick facts # 快速事实：Location / Time zone / Pronouns ## Worldview # 世界观：你对宇宙、道德与自身角色的信念 ## Direction # 方向：当下在做的事，以及未来一年的去向 ## Stance # 立场：Builder vs. theorizer 等二选一词汇

2.1 frontmatter 各字段的技术含义

结合 LifeOsSchema.md 对 frontmatter 契约的说明，可对每个字段给出精确解释：

对身份页而言，category: identity的定位在 LifeOsSchema 中描述得非常清楚——identity 是"不可再分的'这就是我'"，与OurStory.md、Opinions.md、Resume.md、Contacts.md同属一个分区。

2.2 四段正文的写作意图

模板用一句话点明主旨："Who you are, in one short reference. Replace with your own framing."（你是谁——用一份简短的参考承载，替换成你自己的框架）。四个小节各司其职：

• Quick facts：位置、时区、人称代词等可被快速扫描的事实项。这是 DA 在会话中做时间、地点、语言假设时的第一手依据。
• Worldview：关于宇宙、道德与自身角色的信念。这决定了 DA 给你提建议时的价值框架——LifeOsThesis 把"你是谁"归入情境意图（situational intent），与 TELOS 的持久意图、ISA 的任务意图并列。
• Direction：当下正在做的事 + 未来一年的去向。这是"当前状态 → 理想状态"迁移路径的即时快照。
• Stance：用二选一词汇锁定沟通风格（Builder vs. theorizer、Operator vs. analyst、Optimist vs. pessimist），让 DA 的协作姿态与你的工作方式对齐。

三、kind: narrative渲染契约：身份页在 Pulse 中如何呈现

模板声明kind: narrative，其渲染行为由 PulseSchema.md 定义——每个 adapter 输出在进入 Data Plane 前，都要用 Zod 校验的PageDataSchema判别联合体解析。narrative 契约的 TypeScript 形状如下：

{ kind: "narrative", title: "Beliefs", category: "mind", lede?: string, sections: NarrativeSection[], // { heading, body (markdown), level: 1–6 } pullQuotes: string[], meta: PageMeta }

对应关系非常直接：Identity.md的四个##小节（Quick facts / Worldview / Direction / Stance）会被解析为sections[]中的四个NarrativeSection，由<NarrativeView>组件以"散文卡片 + 分区导航 + 可选引用句"的形式渲染。模板中每个##标题自然对应level: 2的 section。

每个页面还携带由AdapterRunner写入的共享PageMeta块，记录provenance、model、costUSD、latencyMs等遥测信息，保证数据平面的每个单元格可审计。校验命令为：

bun LIFEOS/PULSE/Tools/ValidateSchema.ts <path-to-json>

合法输出返回 exit 0，非法输出返回 exit 1 并逐行打印(字段路径) → 错误信息。

四、从模板到生产级身份文件：PRINCIPAL_IDENTITY.md 的完整展开

USER_TEMPLATES/Identity.md是出厂骨架，而真正被系统加载的是安装后落在 PRINCIPAL_IDENTITY.md 的生产级展开版本。这个文件保留了模板的"骨架 DNA"，但做了显著扩展，构成 DA 身份参考的最终形态：

文件头部明确标注了它的运行约束：

INTERVIEW REQUIRED—— 运行/interview用真实身份内容填充该文件。DA 在每次会话启动时加载它；没有你的内容，模型只能在占位符上运行。

从源码结构看，last_updated: 1970-01-01T00:00:00Z、last_updated_by: bootstrap-template是脚手架引导程序留下的"尚未个性化"标记，用于驱动 Interview 技能把该文件纳入待访谈队列。文件末尾的注释同样强调了维护义务："DA 在每个会话开始时读取它——保持其新鲜度，是 DA 保持对齐的方式。"

五、身份如何进入 DA 上下文：会话启动的 @-import 加载链

身份文件不是被动躺着的 Markdown，而是每个会话启动时被强制加载的宪法级文件。加载链在 CLAUDE.template.md 中定义：

• 五个身份文件（PRINCIPAL_TELOS、PRINCIPAL_IDENTITY、DA_IDENTITY、PROJECTS、OPERATIONAL_RULES）默认以注释形式列出，由/LifeOS setup流程（通过 ActivateImports.ts）在 principal 的 USER 脚手架填充完毕后取消注释。
• 文件头注释明确指出：Claude Code 不会跟随被导入文件内部的传递性@-import，因此每个身份文件必须作为顶层@-import 显式列出。

ConfigSystem.md 对启动顺序的描述印证了这一点：会话开始时，CC 加载CLAUDE.md顶层@-import 引用的文件（ARCHITECTURE_SUMMARY、PRINCIPAL_TELOS、PRINCIPAL_IDENTITY、DA_IDENTITY、PROJECTS、OPERATIONAL_RULES），身份文件因此天然处于每一轮对话的上下文起点。

在热层记忆层面，FreshnessSystem.md 记录了buildLifeosContextBlock()的 60 秒 mtime 缓存机制：四个宪法文件（DA_IDENTITY、PRINCIPAL_IDENTITY、PRINCIPAL_TELOS、PROJECTS）加两个热层记忆文件，任一文件的 mtime 变化都会触发重新读取——窗口短到能捕捉同一对话突发内的记忆写入，长到避免每轮提示都重读文件。这正是"身份文件保持常青"的工程保障。

六、provenance 与发布生命周期：模板内容如何与私人内容隔离

Identity.md的provenance: template不是装饰字段，而是发布管线的硬性契约。仓库提供了三个配套 CLI 管理 provenance：

• MarkCustomized.ts：把文件 frontmatter 置为provenance: customized并刷新last_updated。这是你编辑模板后的常态。
• MarkTemplate.ts：反向置为template，其 CLI 帮助文本明确警告"use sparingly——通常用于清空个人数据、重测脚手架"。
• AuditProvenance.ts：遍历 manifest 审计所有源文件，发现缺少provenance:frontmatter 的文件会提示"按 customized 处理"，并输出"✓ all sources have explicit provenance"之类的审计结论。

在正常使用中，你永远不需要手动翻转 provenance——系统通过 Pulse 内联编辑器或直接 mtime 变更检测到编辑后自动处理。

publish: false则从广播侧保证了隐私底线。结合 LifeOsSchema.md 的发布模型说明：DaemonAggregator.ts扫描 USER/ 后只发布publish非false的内容，且身份、健康、财务等领域文件默认全部私有。也就是说，身份页默认只服务你的 DA，绝不外泄。

七、review_cadence: 180d —— 身份保鲜机制

review_cadence: 180d让身份文件进入 LifeOS 的保鲜体系。LifeOsSchema 描述 Pulse 索引器为每个文件计算派生字段：completeness、staleness_days、overdue_review、item_count、preview。当距last_updated超过 180 天时，staleness_days > review_cadence触发overdue_review，Pulse 与 Interview 技能便会把该文件重新推入审查队列——身份不是一次性写就的静态档案，而是按节奏迭代的活文档。

这与整体设计哲学一脉相承：LifeOS 的意图工程要求"你是谁"的意图持续保鲜，否则 DA 的建议会基于过期的身份假设生成。

八、把 Identity 模板落地为你的身份文件：实战清单

综合模板用法、源码契约与生产级展开，一份完整的落地路径如下：

1. 复制模板（或用/LifeOS setup引导安装）：

   cp LIFEOS/USER_TEMPLATES/Identity.md LIFEOS/USER/Identity.md

   若遵循安装后的规范布局，则应落位到USER/PRINCIPAL/PRINCIPAL_IDENTITY.md。

2. 运行/interview完成身份访谈：Interview 技能按interview_phase（身份文件通常落在 P4——identity/voice/mind 阶段）引导你逐段填充，把(interview)占位符替换为真实内容。
3. 逐段填写：Quick facts 填实（时区务必准确，影响所有时间语义）；Worldview 写清楚价值框架；Direction 写当下焦点与一年目标；Stance 用立场词汇锁定协作风格。
4. 确认 frontmatter：category: identity、kind: narrative、publish: false（默认私有）、review_cadence: 180d；编辑后 provenance 会被自动翻转为customized，从此你的身份内容不再进入公共发布。
5. 验证接入：确认CLAUDE.md顶层@-import 包含该文件（由 ActivateImports 在 setup 时完成），并在 Pulse 中确认身份页以<NarrativeView>渲染、派生字段正常。
6. 按节奏维护：在overdue_review提示出现前主动重审，保持last_updated新鲜，让 DA 始终基于当前版本的身份意图工作。

如果将来需要新增身份类概念，遵循扩展契约即可：在 USER/ 根目录放下一个带合法 frontmatter 的.md文件——Pulse 的fs.watch检测到新文件后自动索引、渲染新卡片；Interview 在下次运行时纳入访谈；Daemon 依据publish决定是否广播。Pulse、Daemon、Interview 三处均无需任何代码改动，frontmatter 本身就是 API。

结语

Identity.md看似只有十几行，实则是 LifeOS 意图工程链路的起点：frontmatter 决定了它在 Pulse 中的分区与渲染方式、在发布管线中的可见性、在保鲜体系中的审查节奏；四段正文则定义了 DA 理解"你是谁"的最小信息集。从这份模板到生产级的PRINCIPAL_IDENTITY.md，再到每轮会话开头的@-import 与 60 秒记忆缓存，身份意图在 LifeOS 中完成了从"静态文件"到"每轮对话都生效的运行参数"的转变——这正是意图工程"让每个 prompt 都携带你真正想要的东西"的具象化实现。

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