LifeOS 技术栈偏好指南用 TECHSTACKPREFERENCES.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 的TECHSTACKPREFERENCES.md身份文件它如何定义 Digital AssistantDA在建议与编写代码时的语言、运行时、CLI 工具与代码约定如何在会话启动时被加载以及如何通过/interview流程把占位符变成你自己的真实偏好。读完你不仅能填好这份文件还能理解它在整个 LifeOS 内核中的调用链与实现细节。这份文件在 LifeOS 中扮演什么角色TECHSTACKPREFERENCES.md位于 LifeOS/install/USER/TECHSTACKPREFERENCES.md属于 LifeOS 的USER/ 身份层Identity Layer。根据 USER/README.md 的说明这个目录存放LifeOS 所知道的关于你的一切——身份、声音、目标、项目、工作上下文并且这些文件在每次会话启动时由CLAUDE.md的-import 加载因此 DA 启动时就清楚你是谁、你在做什么。与同目录下的 ALGOPREFS.md算法行为偏好和 DIGITAL_ASSISTANT/DA_IDENTITY.mdDA 身份一样这是一份偏好契约文件它不直接参与代码执行而是塑造 DA 每次调用代码能力之前的决策。文件末尾的原话点明了它的地位These preferences shape every code suggestion, refactor, and tool selection. The DA consults this file before invoking any code-writing capability.从源码看这一每次会话启动即加载的机制由LoadContext.hook.ts支撑。HookSystem.md 中记录了LoadContext.hook.ts的职责是在会话开始时注入动态上下文并在 Hook 注册表中以{ type: command, command: $HOME/.claude/hooks/LoadContext.hook.ts }的形式挂载见 LifeOS/install/LIFEOS/DOCUMENTATION/LifeosSystemArchitecture.md 中由 LoadContext.hook.ts 注入启动文件的说明。也就是说你填写的技术栈偏好会在每次会话开头进入 DA 的上下文窗口成为它写代码前的默认约束。Languages主语言与运行时是硬约束文件的第一节用三条规则锁定了语言层条目模板默认含义PrimaryTypeScriptDA 建议和编写代码时的首选语言Runtimebunnever npm/npx包管理与脚本执行一律走 bun禁用 npm/npxAllowed(interview — what other languages are welcome)通过/interview填写其他欢迎的语言Avoid(interview — what to steer away from)通过/interview填写要回避的语言Runtime: bunnever npm/npx不是一句空话仓库内大量证据支持这一点LifeOS 的 Pulse 子系统使用 LifeOS/install/LIFEOS/PULSE/bun.lock 锁定依赖package.json与bun.lock并存说明 bun 是实际包管理器Hooks 以裸路径注册不带bun前缀但 HookSystem.md 在故障排查章节给出了bun ~/.claude/hooks/LoadContext.hook.ts这样的手工执行方式证明 hook 运行在 bun 之上技能层同样贯彻这一约定CreateCLI/SKILL.md 在检查清单中明确列出✅ Follows LifeOS tech stack (Bun, TypeScript)也就是说新建 CLI 类技能是否合规就看它是否遵循 Bun TypeScript。所以填写这一节时Runtime行一般保持默认即可——这是 LifeOS 的系统级约束真正属于你的偏好的是Allowed与Avoid两行例如允许 Python 做数据处理、回避 PHP 做新项目。CLI Tools三层工具选择的决策规则这一节是整份文件技术含量最高的部分它把用哪个工具拆成三个上下文层每层有明确的取舍逻辑第一层工具内Claude tool calls内置Grepripgrep 后端、Glob、Read。取舍理由比 shell 外出更快、无子进程开销。这一设计与你正在阅读的检索体系一致——LifeOS 的文档与代码检索大量依赖 ripgrep 语义的正则匹配工具内调用把搜文件内联进模型上下文避免每次搜索都拉起一个 shell 进程。第二层Bash终端 / 一次性管道rg取代grep、fd取代find、bat取代cat、eza取代ls。理由这些现代替代品提供更好的默认体验——rg默认尊重.gitignore、输出带颜色与行号bat带语法高亮eza提供 git 状态列。适合交互式终端里的人工巡检与一次性管道。第三层可移植技能代码要分发给其他用户的技能优先使用语言原生 fs APIBunfs、Nodefs/promises如果必须 shell out优先find——因为fd不能保证安装在所有用户机器上。这是三层中最重要的可移植性约束你写的技能最终会ship to other users不能假设对方环境里有你私人的工具链。从仓库结构看LifeOS 大量技能如 LifeOS/install/skills/ 下数十个技能目录正是这种要跨环境运行的代码因此这一层的保守选择是工程上的必然。待填项Preferred shell(interview — bash / zsh / fish) —— 交由/interview询问你日常使用的 shell。三层规则可以概括为一句话工具内用内置能力自己终端用现代替代品写给别人的代码用最保守的兼容方案。Conventions路径、注释与错误处理的铁律Conventions 一节定义 DA 写代码时的通用规范规范内容Paths使用$HOME、${LIFEOS_DIR}、相对路径——绝不硬编码用户路径Comments最少化——代码应通过命名自我解释Error handling显式——绝不静默吞掉错误Config(interview — env var / config file / CLI flag preference) —— 询问你偏好哪种配置方式Paths 背后的源码支撑LIFEOS_DIR是 LifeOS 路径体系的核心环境变量其解析在工具层有专门处理。InstallEngine.ts 中的路径规范化逻辑会把${LIFEOS_DIR}/x、$LIFEOS_DIR/x、~/.claude/x等不同写法去重为同一个根.replace(/\$\{?LIFEOS_DIR\}?|\$\{?CLAUDE_PROJECT_DIR\}?|\$\{?CLAUDE_PLUGIN_ROOT\}?|~\/\.claude|\$HOME\/\.claude|\$\{HOME\}\/\.claude/g, §ROOT§)而 LinkUser.ts、ScaffoldUser.ts、SeedPulse.ts 三个工具都在处理LIFEOS_DIR/LIFEOS_CONFIG_DIR/PROJECTS_DIR三键解析到真实安装目录的逻辑。这说明路径必须可移植不是口头偏好而是整个 LifeOS 工具链的实际假设——任何硬编码用户路径的代码都会破坏这套解析机制。作为参考HookSystem.md 中记录了LIFEOS_DIR的典型取值$HOME/.claude。Error handling 的呼应显式错误处理、绝不静默吞错与 LifeOS 的验证文化一脉相承算法偏好文件 ALGOPREFS.md 中Live probes required: Yesno should work的默认值与Should work is forbidden见 DA_IDENTITY.md共同构成同一套纪律——不确定的事要么验证、要么显式标注未验证而不是靠吞掉错误蒙混过关。(interview) 占位项偏好如何从模板变成现实文件里反复出现的(interview — ...)标记表明这份文件是引导程序模板真正的偏好值由/interview流程填充。这与 USER/ 目录的整体设计一致USER/README.md 明确写道文件以脚手架形式抵达。运行/interview用你的真实答案填充它们。访谈是增量的——可以随时停下再继续。DA_IDENTITY.md 同样标注⚠ INTERVIEW REQUIRED —— run/interviewto populate this file。从文档看/interview运行的是 LifeOS/install/skills/Interview/ 下的访谈工作流FreshnessSystem.md 提到其基于证据的上下文签入机制生命周期通过InterviewDue.ts判断何时该再访谈。实际使用中/interview会就 Languages 的 Allowed/Avoid、CLI Tools 的 Preferred shell、Conventions 的 Config 偏好逐项询问并把你的回答写回本文件。增量访谈意味着你可以在任意阶段中断下次从上次停下的位置继续。DA 如何消费这些偏好从加载到落地的调用链整条链路可以串联如下会话启动CLAUDE.md通过-import 载入 USER/ 目录文件LoadContext.hook.ts将启动文件与动态上下文注入见 HookSystem.md 的注册表说明身份读取hooks 的 identity.ts 提供getTechStack()从 principal 的 frontmatter 读取tech_stack字段——技术栈信息被显式建模为可读取的运行时数据代码能力触发前DA 在调用任何写代码能力前查阅本文件文件末尾契约原文落地校验生成技能/CLI 时按CreateCLI的清单检查是否遵循 Bun TypeScript 技术栈CreateCLI/SKILL.md。也就是说你的技术栈偏好不是建议而是会被身份读取层、技能生成清单、路径解析工具链共同强化的可执行约束。编辑与维护建议由于 USER/ 目录是私有层USER/README.md 明确 release builder 会删除整个USER/树并覆盖为通用脚手架因此这些文件永不随发行版分发你可以放心填写真实偏好。实践建议优先走/interview占位项全部通过访谈填充避免手改时遗漏字段或破坏 frontmatter 格式主语言与运行时保持默认TypeScript bun 是 LifeOS 系统级约束改动会与工具链冲突在 Allowed/Avoid 里写清楚边界例如允许 Python数据分析、禁止 COBOLDA 会在多语言场景据此做选择Config 偏好尽早确定env var / config file / CLI flag三选一或组合这决定 DA 给你写的工具如何暴露配置——仓库中 LIFEOS_CONFIG.toml 是主配置文件的范例CONFIG/README.md 说明 secrets 不存其中只存路径引用定期复查技术栈会演化利用/interview的增量机制在访谈到期时刷新FreshnessSystem.md 描述了 freshness 评分与到期重访机制。小结TECHSTACKPREFERENCES.md表面是一份简短的偏好清单实际是 LifeOS意图工程链路中把人的技术选择翻译成DA 行为约束的关键一跳语言与运行时由系统锁死CLI 工具按上下文分层路径/注释/错误处理被工具链源码背书剩下的个人偏好通过/interview增量填充。把它填好你在 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），仅供参考