LifeOS BASICINFO 身份配置文件解析:从 Bootstrap 占位到个性化身份层 LifeOS BASICINFO 身份配置文件解析从 Bootstrap 占位到个性化身份层【免费下载链接】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导读BASICINFO.md是 LifeOS 安装后在LIFEOS/USER/身份层中落地的第一份会话引导配置文件它以 Bootstrap 模板形式预置姓名、时区、单位制与沟通偏好等最小上下文保证系统在用户尚未深度定制时即可正常运转。本文以该文件为骨架结合 ScaffoldUser.ts、PRINCIPAL_IDENTITY.md 与 LIFEOS_CONFIG.toml 等仓库源码完整讲解 BASICINFO 的字段含义、加载时机、/interview个性化流程及背后的 Freshness 标记机制帮助你理解并正确维护这套身份层。一、文件定位BASICINFO 在 LifeOS 身份层中的角色LifeOS 是一个意图工程平台其核心思想是把用户的当前状态与理想状态之间的鸿沟作为系统运转的输入。要实现这一点系统首先必须了解用户是谁。BASICINFO.md正是这一身份认知的最小载体其文件头注释直接说明了它的设计意图Bootstrap default — functional before interview. Run/interviewto personalize.The DA references this file at session start for framing — name, timezone, unit conventions, and communication style all live here.也就是说这份文件承担三重职责Bootstrapping开箱即用安装完成后无需任何配置即可运行DADigital Assistant数字助理能凭默认值完成一次完整会话Session framing会话框定每次会话启动时DA 读取该文件来确立以谁的身份、在什么时区、用什么单位制和沟通风格来工作个性化入口所有占位字段都标记为(interview)等待/interview流程填充真实数据。从目录结构看它位于 LIFEOS/install/USER/ 下的身份层。同层目录中还有一份信息量更大的 PRINCIPAL_IDENTITY.md在PRINCIPAL/子目录下两者构成精简引导 完整身份的双层结构BASICINFO 管会话开场的最少上下文PRINCIPAL_IDENTITY 管每会话启动时通过CLAUDE.md的导入加载的完整身份引用。二、字段逐项解析BASICINFO 的完整配置骨架BASICINFO.md 的正文结构非常清晰共分三组基本信息Basic Info、联系方式Contact、工作方式Workstyle。下面逐字段给出含义、当前默认值与个性化后的取值建议。2.1 基本信息Basic Info字段默认值含义与说明NameUser用户显示名称。占位值User表明系统尚未个性化PronunciationUser音标/读音标注注释明确指出used by voice system——语音系统依赖此字段正确发音Pronouns(interview)人称代词等待访谈填充Location(interview)地理位置用于本地化语境TimezoneAmerica/Los_AngelesIANA 时区标识。这是系统时间框架的权威来源DA 以此对齐今天现在等时间概念Primary LanguageEnglish主要语言决定 DA 的默认输出语言Preferred UnitsMetric (Celsius, meters, kilograms)偏好单位制。注释给出的默认是公制摄氏度、米、千克2.2 联系方式Contact字段默认值含义与说明Primary Email(interview)主邮箱Public Profile(s)(interview)公开主页注释明确列出候选GitHub、LinkedIn、X、个人网站2.3 工作方式Workstyle字段默认值含义与说明Hours(interview)典型工作时间段Deep Focus Windows(interview)高效专注窗口即用户状态最好的时段Communication Preference(interview)沟通风格偏好注释给出三档terse简洁/detailed详尽/ 两者之间关键结论以上字段中(interview)占位符出现的频率决定了该文件当前是否就绪。文件末尾的注脚强调The DA references this file at session start for framing — name, timezone, unit conventions, and communication style all live here.——姓名、时区、单位约定、沟通风格这四类信息是本文件的核心载荷任何缺失都会导致 DA 在这些维度上退回到占位假设。三、生命周期从模板落盘到个性化改写3.1 模板从哪来ScaffoldUser.ts 的 existsSync 守护复制仓库中负责把install/USER模板树拷贝到用户数据目录的工具是 ScaffoldUser.ts。其文件头注释写明了它的行为契约Setup step 5. existsSync-GUARDED copy of the shippedinstall/USERtemplate tree into the users data home (configDir/USER, default ~/.config/LIFEOS/USER). Never overwrites a populated file — existing user content always wins.关键点有三路径落点模板从install/USER复制到configDir/USER默认~/.config/LIFEOS/USER永不覆盖用户内容复制使用copyMissing来源于 InstallEngine.ts只补缺、不改写已存在的用户文件永远优先开发树保护如果目标目录被检测为开发源码树detectDevTree工具会拒绝执行除非显式传入--allow-dev。其 CLI 用法--apply为实际写入否则为 dry-run 预览# 预览将复制哪些缺失文件不写入 bun ScaffoldUser.ts # 实际将 install/USER 模板树复制到用户数据目录 bun ScaffoldUser.ts --apply # 指定配置根目录/配置目录/技能根目录并允许在开发树场景执行 bun ScaffoldUser.ts --config-root dir --config-dir dir --skill-root dir --apply --allow-devBASICINFO.md 就是经由这条流水线进入用户USER/目录的众多模板文件之一。同时USER/README.md 明确指出隐私边界整个USER/目录是私有的永远不会随 LifeOS 发布包分发——发布构建器会从暂存区删除整个USER/树并用通用脚手架取而代之。因此 BASICINFO 中的默认值只存在于本地不会泄露到公共仓库。3.2 什么时候被加载会话开场的 framing 机制BASICINFO 的加载时点由文件末尾注脚直接声明session start每次会话开始。这与同层身份文件保持一致——USER/README.md 说明整个 USER 目录由CLAUDE.md的导入在每次会话启动时加载使 DA 启动时就知道你是谁、在做什么。而 FreshnessSystem.md 则给出了更精确的运行时细节LIFEOS/PULSE/lib/lifeos-context.ts的buildLifeosContextBlock()会以60 秒 mtime 缓存机制读取四份宪法级文件DA_IDENTITY、PRINCIPAL_IDENTITY、PRINCIPAL_TELOS、PROJECTS及两份热层记忆文件。这意味着身份文件的任何改动最多在一分钟内即被系统感知并反映到会话上下文中。3.3 如何个性化/interview流程与占位符的终结BASICINFO 中所有(interview)占位符的归宿都由同一条命令决定/interview。这也是 LifeOS 个性化体系的总入口可以从三份文档交叉印证其行为在 BASICINFO 中注释给出最简指引Run/interviewto personalize在 PRINCIPAL_IDENTITY.md 中重复出现的⚠ INTERVIEW REQUIRED警告强调run/interviewto populate this file with your real identity content. The DA loads it at every session start; without your content, the model operates on placeholders.不运行访谈模型将一直基于占位符工作在 FreshnessSystem.md 中/interview被明确为ContextCheckin 工作流的入口它运行在~/.claude/skills/Interview/Workflows/ContextCheckin.md自 2026-08-11 起采用证据驱动模式——StateEvidence.ts按域缓存观测数据、InterviewDue.ts计算确定性到期裁决由 launchd 任务com.lifeos.interviewdue每日刷新渲染为状态栏的 徽标对话以声明 vs 证据的矛盾开场而不是空泛地问你的使命是什么。从源码结构看/interview的产物远不止 BASICINFO它会重写身份PRINCIPAL_IDENTITY、填充 LIFEOS_CONFIG.toml 中的 principal/da/voice 区块、录入 PRONUNCIATIONS.json 发音表等。而 BASICINFO 作为会话开场的最小框定文件在访谈完成后的典型形态是Name变为真实姓名、Timezone保持或修正为实际 IANA 时区、Communication Preference落定为terse/detailed之一。四、与相邻配置文件的协同BASICINFO 的上游与旁支要正确维护 BASICINFO必须理解它在身份配置生态中的位置。以下三份文件与它关系最密切4.1 上游权威LIFEOS_CONFIG.tomlLIFEOS_CONFIG.toml 被 HookSystem.md 明确为规范身份源The canonical identity source isLIFEOS/USER/CONFIG/LIFEOS_CONFIG.toml, read viaLIFEOS/TOOLS/LifeosConfig.ts。它的[principal]区块与 BASICINFO 高度重叠但承载的信息更机器化[principal] name Your Name # required — your display name pronunciation # optional — phonetic spelling if needed timezone America/Los_Angeles # required — IANA timezone hometown # optional currency USD # optional — ISO 4217, drives Pulse Finances tab formatting对照可见name、pronunciation、timezone三个字段在 BASICINFO 与 TOML 中一一对应而 TOML 额外引入了currencyISO 4217驱动 Pulse 财务页格式化。两条链路的关系是TOML 是系统代码读取的规范源BASICINFO 是 DA 会话开场时的人类可读框定参考——它们由同一个/interview流程协同填充维护时应注意保持两者一致。4.2 完整身份旁支PRINCIPAL_IDENTITY.mdPRINCIPAL_IDENTITY.md 是 BASICINFO 的完整版除姓名/发音/位置/时区外还包含 Career Essence职业脉络、Worldview世界观、Key Positions关键立场、Personal Interests个人兴趣、Preferences工具与决策偏好等长文段落。BASICINFO 可以看作它的Quick Reference 摘要。/interview完成时会同时重写这两份文件。4.3 语音旁支PRONUNCIATIONS.md / PRONUNCIATIONS.jsonBASICINFO 中的Pronunciation字段服务于语音系统而真正的发音覆盖表在 PRONUNCIATIONS.md 及其同目录 JSON 中。该文档特别强调一个易错点语音层不读取 md 文件只读取扁平的text: spoken form映射 JSON——md 只是给人看的注释且匹配是字面匹配需要逐条添加你真实会说的变形如is live、went live而非只有词根。五、Freshness 标记BASICINFO 的保鲜机制BASICINFO.md 文件头带有一个简单的 frontmatterprovenance: template用于标记其模板出身。在整个 LifeOS 身份层中frontmatter 是文件与所有消费方Pulse、Daemon、Interview、技能之间的 API见 LifeOsSchema.md而 FreshnessSystem.md 定义了完整的保鲜约定。对于身份类文件保鲜的关键字段是last_reviewed:评审标记区别于last_updated:写入标记。ContextCheckin 工作流对身份文件的审查遵循明确规则PRINCIPAL_IDENTITY.md身份文件的代表审查话术示例Identity hasnt been touched in {N}d. Quick Reference says youre at {role}. Still right?每次经批准的内容编辑后必须调用bumpReviewedTimestamp推进last_reviewed:否则文件会永远停留在 F 级新鲜度状态栏的 FRESH 行和/api/freshness/summary中的 A–F 等级均由此字段计算。因此BASICINFO 中姓名、时区、单位制、沟通风格的变更不仅是内容编辑更是一次应被记录的新鲜度评审——这正是 LifeOS文件即状态哲学的体现。六、维护清单与最佳实践综合以上分析可以整理出针对 BASICINFO及其所属身份层的维护要点安装后立即运行/interview模板状态下 DA 基于占位符工作访谈是终结所有(interview)占位符的唯一正规路径保持 BASICINFO 与 LIFEOS_CONFIG.toml 一致name/pronunciation/timezone双处出现改一处不忘另一处TOML 是系统读取的规范源语音相关变更要双写BASICINFO 的Pronunciation是会话框定参考真正的发音覆盖必须进入PRONUNCIATIONS.jsonmd 仅为注释身份文件改动后更新新鲜度标记用bumpReviewedTimestamp推进last_reviewed:否则新鲜度等级不会恢复勿在发布目录中留下真实身份install/USER/下的模板是脚手架真实数据只存在于本地configDir/USER发布构建会自动剔除善用 ScaffoldUser 的守护语义--apply之前先用 dry-run 查看copyMissing保证你的既有编辑永不被模板覆盖。七、小结BASICINFO.md虽是一份只有 30 行的模板文件却是 LifeOS 身份层中最先被 DA 消费的会话框定契约它以 Bootstrap 默认值保证开箱可用以(interview)占位符指明个性化路径以provenance: template标记其模板出身。理解它的字段语义、加载时机、上游权威LIFEOS_CONFIG.toml与保鲜机制是正确使用整个 LifeOS 身份层的第一步。当你在自己的USER/目录中看到这份文件时请记住文件末尾那句话——名字、时区、单位约定与沟通风格都住在这里它们共同决定了你的 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考