LifeOS ISA 实战解析用 50 条可验证 ISC 定义「家用能源监控桌面应用」的理想态WattWatch 案例全解读【免费下载链接】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 的 ISAIdeal State Artifact理想态工件技能库中的完整示例 e5-desktop-app.md 为对象逐节拆解一个虚构但完全真实规格的「本地优先家用能源监控桌面应用 WattWatch」是如何被写成一份可测试、可执行、可追溯的 ISA 的。读完本文你将掌握 LifeOS 中「用原子化、可证伪的 ISC 定义 done」的完整写作范式——包括十七节固定结构的组织、50 条验收标准的分类写法、Test Strategy 探针契约、Feature 分解、Dead End 记录与 C/R/L 学习轨迹——并可直接套用到自己的桌面应用、CLI 工具或任何软件项目的规格定义中。说明WattWatch 是 ISA 示例库中的教学项目名文档头部已声明为虚构wattwatch.example.org为 RFC 2606 保留域名其价值在于示范 ISA 的形态与写法而非真实产品。本文所有引用均以仓库实际文件为准。一、这份示例在 ISA 体系中的位置在 LifeOS 的 ISA 技能 中Examples/目录保存着跨越规模与领域的参考 ISA。SKILL.md 的示例索引表将 e5-desktop-app.md 归类为Code / E5 档位「WattWatch — open-source desktop app for personal home-energy monitoring. Single-user app pattern, 50 ISCs, populated Changelog」。也就是说这个文件被定位为E5最大规模的「单用户桌面应用」参考模板与同目录下其他示例形成互补示例文件领域/模式规模e1-minimal.md给 CLI 工具加一个--no-color参数Goal 4 ISC最小快速路径e2-backup-verify.md备份 CLI 的 SHA-256 校验单域18 ISCe3-project.mdarxiv 元数据提取器 CLI中型项目12 ISC八节e4-api-migration.mdREST → GraphQL API 迁移6 个月兼容跨切面73 ISCe5-desktop-app.mdWattWatch 桌面应用本文对象50 ISC全节填充 Changeloge5-enterprise.md多区域 HIPAA 患者门户68 ISC企业参考文档顶部注释还提醒读者该示例写于 v6.25.0 之前因此省略了## Dependencies与## Bridge Criteria并保留了已退役的 frontmatter 键effort:、mode:与旧式标题## Criteria、## Changelog——它们是历史形态节序与新版 frontmatter 以 ISAFormat.md格式规范 v2.21.0为准。写作时按 SKILL.md 的建议先读 canonical-isa.mdBeanLine 示范件掌握节头再选最贴近自己领域与规模的示例当模板。二、Frontmatter 解剖一张「可执行的规格卡片」WattWatch 示例的 frontmatter 展示了 ISA 的身份信息--- task: WattWatch — local-first home energy monitoring desktop app slug: 20260115-090000_wattwatch-v1 project: WattWatch effort: comprehensive effort_source: explicit phase: execute progress: 71/104 mode: interactive started: 2026-01-15T17:00:00Z updated: 2026-04-27T22:30:00Z ---对照 ISAFormat.md 的 Field Rules 可知slug遵循YYYYMMDD-HHMMSS_kebab-description格式task用祈使句描述交付物≤60 字符省略时回退到 H1 标题。progress: 71/104是「已关闭 claim / 总 claim」的机械计数格式规范要求关闭 claim 时立即更新、不要攒到末尾。注意示例的 71/104 与正文 50 条 ISC 存在差异是因为这是虚构教学示例的留白不构成规范冲突。phase在 v2.15.0 之后改为最小生命周期值scoping/climbing/learn/complete旧式站点名如observe/execute/verify只保证可解析、不再写入新 ISAeffort:、effort_source:、mode:均属已退役字段仅在旧 ISA 上容忍。三、第一节骨架Problem → Vision → Out of Scope → Principles → Constraints → Goal这六节构成 ISA 的「前奏」其核心是用文字锁住边界。WattWatch 的写法是教科书级的3.1 Problem先写「现在缺什么」文档用一段话精确刻画痛点屋顶光伏、家用电池、智能插座用户拥有实时能源数据但数据分散在 Shelly、Emporia、Sense、Tesla 五家「围墙花园」里互不通信、无法形成整屋图景且即使问「热泵现在开着吗」这种 LAN 内传感器就能回答的问题也要走一遍厂商云。想真正优化家庭用电的用户只能去搭 Home Assistant、手写 YAML得到的是「爱好者工具箱」而非成品。中间地带——一个聚合主流美国住宅能源传感器的本地优先成品级桌面应用——在 2026 年不存在。3.2 Vision把「惊喜时刻」写成具体场景ISA 的元理想态是「使用系统的人获得惊喜」euphoric surprise## Vision就是把这个通用目标落成具体场景。WattWatch 写的是用户在炎热的下午打开应用看到热泵拉取 4.2kW、光伏产出 6.8kW、Powerwall 实时用盈余充电——而没有一个数据包离开家庭网络用户把截图发给朋友朋友当晚就装上。注意 Vision 写的是体验而非功能清单——这是 SKILL.md 与 ISAFormat.md 反复强调的写法「The claims verify the specific summit; the Vision keeps the universal one in view」。3.3 Out of Scope反愿景一次性说清「不做什么」示例声明了七条范围外事项每条都给出理由无强制云账号完全离线运行云同步可选且默认关闭无电费账单集成聚合的是传感器数据而非账单数据无 HVAC/家电控制WattWatch 只读不写v1 无自动化无移动端仅桌面未来最多做桌面应用自带的只读 Web 视图无商业/多租户部署单家庭、单用户、单机不支持无法合法解码的厂商加密协议Shelly 本地 HTTP 可以、Emporia Vue 本地 UDP 可以、Sense 逆向云协议推迟到其发布文档化本地 API无实时电价套利/电池调度优化v1 只做可视化。3.4 Principles约束「思考方式」五条原则都是可泛化的价值观而非技术选型本地优先不是特性而是整体姿态传感器数据属于房主不回家、不上报遥测、读路径不嵌第三方 SDK精致的单用户桌面应用在 2026 年是正当产品品类硬件集成天生脆弱应用对部分覆盖保持诚实历史数据神圣不可侵犯。3.5 Constraints锁定「解空间」约束是不可动摇的架构命令WattWatch 给出七条硬约束TypeScript Bun 工具链桌面壳用Tauri 2.xRust 系统 webview而非 Electron压缩包体 ≤ 25MB所有传感器数据存本地 SQLite${APP_DATA}/wattwatch/db.sqlite无远程主存储平台分级macOS 13一级须达到生产质量、Linux x86_64/aarch64AppImage .deb二级、Windows 10三级已知问题写进 release notes认证全部本地化单密码、Argon2id、存 OS keychain无 SSO/OAuth/账号服务器可选云同步默认关端到端加密、用户派生密钥同步服务器是「读不到内容的薄中继」传感器轮询节奏可配但受限最小 1 秒、最大 5 分钟整屋默认 5 秒、单设备默认 30 秒UI 在 2019 款 8GB MacBook Air、累积 90 天数据下保持 60fps 滚动、交互延迟 p95 ≤ 100ms。3.6 Goal1–3 句「难以随意变动的主干」Goal 把上述一切压缩成可验证的交付声明交付一个代号 WattWatch、经签名安装包分发的 Tauri 桌面应用聚合 Shelly、Emporia Vue、Sense、Tesla Powerwall 数据到统一本地 SQLite 存储提供实时整屋视图 单设备归因 六个月历史归档默认完全离线、可选端到端加密云同步。四、核心50 条 ISC 验收标准按域组织WattWatch 的## Criteria节旧式标题新版为## Claims两者都解析是文章的主体——50 条原子 claim每条都能用单一二进制探针证伪。示例按十个业务域分组覆盖了从构建分发到反指标的完整验收面4.1 Build DistributionISC-1 ~ ISC-5bun run tauri build产出 macOS arm64 签名.dmg、Linux x86_64.AppImage、Windows x64.msimacOS.dmg公证通过spctl --assess --verbose报告accepted (sourceNotarized Developer ID)三平台产物压缩后 ≤ 25MBwattwatch.example.org/download提供最新签名产物并附 SHA-256wattwatch --version打印与package.json一致的 semver。4.2 First-Run OnboardingISC-6 ~ ISC-11首次启动向导 ≤ 10 分钟完成用户持一台 Shelly 一台 PowerwallLAN 扫描经 mDNS_shelly._tcp.local30 秒内自动发现 ShellyEmporia Vue 配置接受本地凭据并验证 UDP 65432 可达Tesla Powerwall 配置接受网关 IP 与客户密码无需特斯拉云账号Sense 集成前置「实验性——仅云端」免责声明**ISC-11未勾选**要求零凭据以明文落盘全部密钥进 OS keychain——这是一个「还没完成」的 claim 的正确示范留在列表里不假装完成。4.3 Sensor DriversISC-12 ~ ISC-17Shelly 驱动经本地 HTTP APIGen1/status、Gen2/rpc/Shelly.GetStatus轮询 Gen1/Gen2Emporia Vue 驱动解码本地 UDP 广播把 16 路电路通道映射为用户命名标签Tesla Powerwall 驱动对/api/login/Basic认证每 5 秒轮询/api/meters/aggregates与/api/system_status/soeSense 驱动实验性经文档化 WebSocket 认证并明确警告该路径需要 Sense 云端往返驱动健康状态机连续 3 次轮询失败标记degraded连续 10 次失败标记offline并暂停轮询 60 秒轮询延迟预算LAN 传感器 p95 ≤ 200ms云传感器Sensep95 ≤ 2000ms。4.4 Data Model StorageISC-18 ~ ISC-22SQLite schema 含 8 张表device、sensor_reading、circuit、aggregate_5min、aggregate_hourly、aggregate_daily、event、user_prefsensor_reading持续汇总到aggregate_5min原始读数 7 天后裁剪aggregate_hourly保留 13 个月aggregate_daily无限期保留启动时执行PRAGMA integrity_check失败走恢复向导、绝不静默忽略用户触发的Export → JSON在 ≤ 30 秒内写出 6 个月全历史带时间戳文件。4.5 UI / Real-Time ViewISC-23 ~ ISC-28实时仪表盘每 5 秒更新整屋功率、光伏产量、电池 SOC、电网进出逐回路面板按当前电流排序并带 60 分钟 sparklineSankey 能量流图实时渲染 solar → home/battery/grid 分流**ISC-26未勾选**要求任意回路的 raw/hourly/daily 三级下钻视图放大/平移ISC-27/ISC-28 把性能预算落成可测指标2019 MacBook Air 90 天数据下 60fps 滚动、点击到首帧 p95 ≤ 100ms。4.6 AlertsISC-29 ~ ISC-32规则形如if metric op threshold for duration规则触发时弹系统通知并写event行告警状态跨重启持久化、应用关闭期间的告警下次启动展示**ISC-32未勾选**要求即使系统拒绝通知告警仍写入应用内日志。4.7 AuthISC-33 ~ ISC-36首次启动设置本地密码Argon2idm64MB, t3, p4本地密码在启动时解锁 SQLCipher 加密密钥连续 5 次解锁失败触发 5 分钟冷却密码重置需用户确认会丢失既有加密数据v1 无恢复密钥。4.8 Cloud SyncISC-37 ~ ISC-41全部未勾选这组 ISC 展示了「把功能推迟到 v1.1」时的处理方式云同步默认 OFF开启前显示单屏「什么数据会离开设备」说明开启时用 HKDF 每安装稳定盐从本地密码派生同步密钥同步载荷客户端 AES-256-GCM 加密、中继只存密文第二台设备凭相同密码邮箱 60 秒内配对关闭同步 24 小时内删除服务器端密文并弹确认。4.9 UpdatesISC-42 ~ ISC-43每 24 小时检查wattwatch.example.org/api/release/latest一次仅在用户点击「Install」后应用更新更新载荷签名未签名或篡改即中止并可见报错。4.10 OperationalISC-44 ~ ISC-45诊断导出把 SQLite schema不含行、驱动日志最近 24h、OS 信息打包成.zip供支持崩溃报告器 opt-in发送前展示将要发送的确切字节。4.11 Anti-criteria反指标ISC-46 ~ ISC-50反指标是把 Out of Scope / Constraints / Principles 变成可探测的关键机制WattWatch 写了五条Anti: privacy—— 首次启动、用户显式开启云同步之前零出站网络请求用抓包验证Anti: out of scope—— UI 中没有任何Control按钮传感器写路径未接线Anti: data loss—— 应用更新从不覆盖或迁移 SQLite 而不先写带时间戳的.bakAnti: dependency creep—— 构建图里没有 Electronbun pm ls | grep electron为空Anti: telemetry——rg google-analytics|sentry|mixpanel|posthog|fullstory src/零匹配。对照 SKILL.md 的三护栏分类Principles 约束思考、Constraints 约束解空间、Out of Scope 约束愿景、Anti-criteria 约束测试面这五条反指标正是前三者的「探针化」产物。五、Test Strategy每条 claim 一条可执行探针WattWatch 的## Test Strategy采用 YAML 列表形态新版规范是六列/七列表格isc | type | check | threshold | tool | anchors_to | severity示例为历史形态两者语义一致为每条关键 ISC 指定验证类型、检查内容、通过阈值与工具命令ISC类型检查阈值工具ISC-2notarizationmacOS Gatekeeper 接受签名 .dmgspctl报告accepted (sourceNotarized Developer ID)spctl --assess --verbose dist/WattWatch.dmgISC-3bundle-size压缩后产物体积≤ 25MBdu -m dist/WattWatch.dmg ...ISC-7lan-discoverymDNS 扫描返回测试台上 Shelly 设备≥ 1 台≤ 30sbun run scripts/mdns-probe.tsISC-14driver-integrationPowerwall 驱动读取/api/meters/aggregates返回 site/load/solar/battery 值bun run scripts/powerwall-probe.ts --gateway 192.168.x.xISC-21db-integrity既有库上执行PRAGMA integrity_check返回oksqlite3 ${APP_DATA}/wattwatch/db.sqlite PRAGMA integrity_checkISC-27performance90 天数据下 60fps 滚动中位帧时间 ≤ 16.6mstauri devtools performance recorderISC-28interaction-latency点击 → 首帧 p95≤ 100msbun run scripts/ui-latency.ts --runs 200ISC-39crypto同步载荷为 AES-256-GCM 密文载荷熵 ≥ 7.9 bits/bytebun run scripts/sync-payload-entropy.tsISC-46anti-probe首次启动未同意前出站包到非 LAN 目的地的包为 0tcpdump -i en0 not net 192.168.0.0/16 ...60sISC-49anti-dep依赖树无 Electron空匹配bun pm ls \| rg -i electronISC-50anti-telemetry源码无第三方遥测 SDK 字符串0 匹配rg google-analytics\|sentry\|... src/从这份清单可以提炼出 ISA 探针设计的两个要点一是探针要落在「事物与消费者的接缝处」ISAFormat.md 的 seam rule——探针挂在最高且最贴近消费者的边界上二是优先用可运行的确定性探针bash/curl/bun-test 类只有无法运行化的场景才退回截图或人工检查。六、Features垂直切片式功能分解## Features用 YAML 块列出 11 个功能每个声明name、description、satisfies满足哪些 ISC、depends_on与parallelizableSensorDriverShelly / Emporia / Powerwall / Sense四个独立传感器驱动全部parallelizable: true——彼此无依赖这正是「垂直切片」的体现每个驱动端到端满足自己的发现/轮询/健康/延迟预算 claimLocalStorageSQLCipher 支撑的 SQLite含 rollup、保留策略、完整性检查satisfies 含 ISC-18/19/20/21/22/34/48parallelizable: false数据层是串行核心AuthLocalArgon2id OS keychain 冷却depends_on: [LocalStorage]解锁加密密钥依赖存储LiveDashboard实时整屋视图 Sankey 逐回路面板依赖三个主要驱动与 LocalStorageAlerts / CloudSyncOptional / Updater / Distribution / Diagnostics其余功能块CloudSyncOptional 依赖 AuthLocal LocalStorage符合「从本地密码派生同步密钥」的调用链。对照 ISAFormat.md 的 Feature blocks 规则v2.16.0新版中 Features 是承载 claim 的块### Fn · name 一行Why: 内嵌 ISC旧式name | satisfies指针表已删除——本示例展示的正是旧指针表形态其「功能 ↔ ISC 映射」的思想在 v2.16.0 后由 feature block 直接内嵌承载。七、Decisions决策日志与 Dead End## Decisions是带时间戳的决策日志包括死路dead end。WattWatch 记录了七条关键决策其中两条是标注 ❌ DEAD END 的失败尝试2026-01-15选 Tauri 2.x 弃 Electron——≤ 25MB 的包体约束在 Electron 的 Chromium 基线~120MB下不可能达成且系统 webview 复用能显著改善 tier-1 macOS 的冷启动延迟2026-01-22选 SQLite SQLCipher 而非自定义加密 KV——数据形态是真正关系型的设备/回路/读数/聚合且「房主导出」用例要求可移植文件格式❌ DEAD END2026-02-04曾尝试让单个 Worker 线程轮询全部四类传感器以简化调度器。结果卡死的 Sense WebSocket 阻塞了 Shelly 轮询仪表盘延迟超出 ISC-28 达 4 倍。回退为「每驱动独立 worker 隔离事件循环」并明确写「Dont retry」2026-02-19refined:精化 ISC-19 保留策略——「原始读数无限期保留」是幼稚的7 天原始 13 个月小时 无限期天级才是能在 256GB Mac 上撑过 6 个月的真实存储形态❌ DEAD END2026-03-02曾尝试 LAN 认证失败时回退厂商云 API。这违反本地优先原则、引入隐藏云依赖回退为诚实的「该传感器离线」UI2026-03-14云同步从 v1 推迟到 v1.1——中继服务器威胁模型不简单先交付本地优先产品更诚实2026-03-29refined:把 ISC-46 从「无遥测」锐化为「首次启动、用户选择加入前对非 LAN 目的地零出站包」——抓包审查发现 Tauri 的自动更新探测在同意前就触发了更新检查改为等用户完成 onboarding 之后2026-04-10Sense 驱动保留为experimental而非砍掉——用户调研显示 Sense 用户是被现有工具服务最不到位的人群2026-04-22refined:ISC-3 包体目标从 35MB 收紧到 25MB。refined:前缀是 ISAFormat.md 对 Goal/ISC 重构的约定标记而❌ DEAD END ... Dont retry则是把「被证伪的路径」永久钉进审计轨迹防止未来重新论证同一错误。八、ChangelogLearningC/R/L 四段式纠错轨迹示例的## Changelog节新版规范更名为## Learning采用conjectured / refuted by / learned / criterion now四段式格式记录「理解发生变化」的时刻每条都必须四段齐全——SKILL.md 的 Gotchas 明确Append 工作流拒绝写不完整的 C/R/L缺任何一段就是 Decision 而非 Learning entry。WattWatch 示范了四条2026-02-04猜想「单一轮询 worker 承载全部驱动可简化架构且无可见代价」→ 被「卡死的 Sense WebSocket 阻塞 Shelly 轮询、交互延迟超 ISC-28 达 4 倍」证伪 → 学到「一个驱动的失败模式是挂起连接而非错误响应时必须做驱动级隔离」→ criterion nowISC-17 拆分为 LAN 预算≤200ms与云预算≤2000ms驱动实现迁到独立 worker2026-02-22猜想「7 天原始读数够高级用户下钻」→ 被 beta 用户「想查 30 天前 5 分钟分辨率的加热泵诊断数据」证伪 → 学到「5 分钟聚合才是正确的下钻分辨率」→ criterion nowISC-19 锐化为原始 7 天 / 5 分钟聚合 13 个月 / 天级无限期2026-03-02猜想「LAN 认证失败时回退厂商云是对用户的善意」→ 被「回退不可见测试者带着云回退跑了 3 周没察觉」证伪 → 学到「跨信任边界的静默回退违反用户心智模型」→ criterion now无 ISC 变更决策入日志、原则进入代码审查清单2026-03-29猜想「Tauri 默认自动更新探测可以在同意前发布」→ 被「抓包发现欢迎屏都没看到就触发了探测」证伪 → 学到「『无遥测』不够审计必须包含框架默认网络行为」→ criterion nowISC-46 锐化、更新检查推迟到 onboarding 之后。这套格式的价值在于它把「我们当时为什么这么想、现实如何反驳、我们现在知道什么、标准因此如何变化」完整保留跨会话、跨 Agent 可审计——这正是 LifeOS 的 Deutsch 纠错轨迹error-correction trail。九、Verification一行式溯源存根## Verification节为每条已通过[x]的 claim 保存一行溯源存根指向证明所在处commit hash、测试名或探针引用而非大段证据ISC-2spctl --assess --verbose dist/WattWatch.dmg→accepted (sourceNotarized Developer ID)ISC-3du -m→ dmg 22M / AppImage 19M / msi 24MISC-7测试 LAN 上 3 台 Shelly Gen2 全部在 4.1s 内被发现ISC-14探针返回{site_now: -1240, load_now: 3120, solar_now: 4360, battery_now: 0, percentage_charged: 87.4}ISC-21PRAGMA integrity_check→okISC-272019 MacBook Air 90 天数据集滚动中位帧时间 14.2msISC-28200 次运行 p95 点击到首帧 78msISC-46首次启动同意前 60 秒 tcpdump → 0 个非 LAN 目的地包ISC-49 / ISC-50依赖树与源码扫描均为空对照 ISAFormat.md 的「证据在关闭时坍缩」约定Algorithm v8.7.1 claim 12claim 勾选的那一刻其 Verification 条目就压缩为一行存根证据留在 git 与 CI 中ISA 只负责「指向」。一个不断堆积证据段落的 Verification 节正是该约定要防止的失败。十、从 WattWatch 提炼的可复用写作模式读完这份 50-ISC 示例可以提炼出六个直接可复用的 ISA 写作手法边界先行Problem → Vision → Out of Scope → Principles → Constraints 五节是「写 claim 之前的清场」——先把解空间划死claim 才有意义原子化 claim 与单一探针每条 ISC 可被一条命令/一次观察证伪模糊表述如「Email is delivered」会被 ISAFormat.md 的硬变体性示例fluff vs load-bearing 对比淘汰性能预算必须数字化60fps≤16.6ms 帧时间、p95 ≤ 100ms、包体 ≤ 25MB、发现 ≤ 30s——凡约束能映射为预算的都需要数字 ISC而不是「要快」这种氛围反指标不可缺至少一条Anti:claim 把隐私/范围/依赖纪律变成可扫描的探针这是 CheckCompleteness 的硬性要求之一未完成与推迟要如实呈现ISC-11、ISC-15、ISC-26、ISC-32、ISC-37~41 保持[ ]或整体未勾选不假装完成——ISA 展示的是诚实状态失败要留痕两条 DEAD END 四条完整 C/R/L让「什么被证伪过、为什么、标准因此变成什么」永久可查。十一、继续深入相关文档与源码想要把这份示例用到自己的项目可以顺着以下仓库路径继续格式规范权威文件形状契约ISAFormat.md——十七节固定顺序、Frontmatter Field Rules、Test Strategy 六/七/八列契约、ID-Stability、Completeness Gate系统架构概念框架ISASystem.md——五重身份、三护栏分类、六工作流、两处存放地技能主文件工作流路由与 GotchasSKILL.md六条工作流Scaffold.md、Interview.md、Grill.md、CheckCompleteness.md、Reconcile.md、Seed.md、Append.md其他示例按领域选模板canonical-isa.mdBeanLine 示范件先读、e5-enterprise.md企业级、e4-api-migration.md跨切面迁移解析与执行侧源码isa-utils.tsISA 解析、IsaFrontier.ts依赖边与前哨计算、ISAGate.ts关闭门禁、ISARender.ts渲染。结语一份好的 ISA 不是需求文档而是「把 done 写成可证伪的 claim再让每条 claim 都被真实世界检验」的活体解释。WattWatch 示例的价值在于它用 50 条 ISC 完整演示了桌面应用从架构选型Tauri vs Electron、数据模型SQLite rollup 三级保留、硬件驱动四类传感器、认证加密Argon2id SQLCipher到反指标零遥测、零出站的全谱系验收怎么写并用 DEAD END 与 C/R/L 轨迹示范了「理解如何随时间被现实修正」。下次面对任何「要做成什么样才算完成」的问题时照这份骨架把边界划清、把 claim 写细、把探针挂到接缝处你就已经在用 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），仅供参考 LifeOS ISA 实战解析：用 50 条可验证 ISC 定义「家用能源监控桌面应用」的理想态（WattWatch 案例全解读）
LifeOS ISA 实战解析用 50 条可验证 ISC 定义「家用能源监控桌面应用」的理想态WattWatch 案例全解读【免费下载链接】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 的 ISAIdeal State Artifact理想态工件技能库中的完整示例 e5-desktop-app.md 为对象逐节拆解一个虚构但完全真实规格的「本地优先家用能源监控桌面应用 WattWatch」是如何被写成一份可测试、可执行、可追溯的 ISA 的。读完本文你将掌握 LifeOS 中「用原子化、可证伪的 ISC 定义 done」的完整写作范式——包括十七节固定结构的组织、50 条验收标准的分类写法、Test Strategy 探针契约、Feature 分解、Dead End 记录与 C/R/L 学习轨迹——并可直接套用到自己的桌面应用、CLI 工具或任何软件项目的规格定义中。说明WattWatch 是 ISA 示例库中的教学项目名文档头部已声明为虚构wattwatch.example.org为 RFC 2606 保留域名其价值在于示范 ISA 的形态与写法而非真实产品。本文所有引用均以仓库实际文件为准。一、这份示例在 ISA 体系中的位置在 LifeOS 的 ISA 技能 中Examples/目录保存着跨越规模与领域的参考 ISA。SKILL.md 的示例索引表将 e5-desktop-app.md 归类为Code / E5 档位「WattWatch — open-source desktop app for personal home-energy monitoring. Single-user app pattern, 50 ISCs, populated Changelog」。也就是说这个文件被定位为E5最大规模的「单用户桌面应用」参考模板与同目录下其他示例形成互补示例文件领域/模式规模e1-minimal.md给 CLI 工具加一个--no-color参数Goal 4 ISC最小快速路径e2-backup-verify.md备份 CLI 的 SHA-256 校验单域18 ISCe3-project.mdarxiv 元数据提取器 CLI中型项目12 ISC八节e4-api-migration.mdREST → GraphQL API 迁移6 个月兼容跨切面73 ISCe5-desktop-app.mdWattWatch 桌面应用本文对象50 ISC全节填充 Changeloge5-enterprise.md多区域 HIPAA 患者门户68 ISC企业参考文档顶部注释还提醒读者该示例写于 v6.25.0 之前因此省略了## Dependencies与## Bridge Criteria并保留了已退役的 frontmatter 键effort:、mode:与旧式标题## Criteria、## Changelog——它们是历史形态节序与新版 frontmatter 以 ISAFormat.md格式规范 v2.21.0为准。写作时按 SKILL.md 的建议先读 canonical-isa.mdBeanLine 示范件掌握节头再选最贴近自己领域与规模的示例当模板。二、Frontmatter 解剖一张「可执行的规格卡片」WattWatch 示例的 frontmatter 展示了 ISA 的身份信息--- task: WattWatch — local-first home energy monitoring desktop app slug: 20260115-090000_wattwatch-v1 project: WattWatch effort: comprehensive effort_source: explicit phase: execute progress: 71/104 mode: interactive started: 2026-01-15T17:00:00Z updated: 2026-04-27T22:30:00Z ---对照 ISAFormat.md 的 Field Rules 可知slug遵循YYYYMMDD-HHMMSS_kebab-description格式task用祈使句描述交付物≤60 字符省略时回退到 H1 标题。progress: 71/104是「已关闭 claim / 总 claim」的机械计数格式规范要求关闭 claim 时立即更新、不要攒到末尾。注意示例的 71/104 与正文 50 条 ISC 存在差异是因为这是虚构教学示例的留白不构成规范冲突。phase在 v2.15.0 之后改为最小生命周期值scoping/climbing/learn/complete旧式站点名如observe/execute/verify只保证可解析、不再写入新 ISAeffort:、effort_source:、mode:均属已退役字段仅在旧 ISA 上容忍。三、第一节骨架Problem → Vision → Out of Scope → Principles → Constraints → Goal这六节构成 ISA 的「前奏」其核心是用文字锁住边界。WattWatch 的写法是教科书级的3.1 Problem先写「现在缺什么」文档用一段话精确刻画痛点屋顶光伏、家用电池、智能插座用户拥有实时能源数据但数据分散在 Shelly、Emporia、Sense、Tesla 五家「围墙花园」里互不通信、无法形成整屋图景且即使问「热泵现在开着吗」这种 LAN 内传感器就能回答的问题也要走一遍厂商云。想真正优化家庭用电的用户只能去搭 Home Assistant、手写 YAML得到的是「爱好者工具箱」而非成品。中间地带——一个聚合主流美国住宅能源传感器的本地优先成品级桌面应用——在 2026 年不存在。3.2 Vision把「惊喜时刻」写成具体场景ISA 的元理想态是「使用系统的人获得惊喜」euphoric surprise## Vision就是把这个通用目标落成具体场景。WattWatch 写的是用户在炎热的下午打开应用看到热泵拉取 4.2kW、光伏产出 6.8kW、Powerwall 实时用盈余充电——而没有一个数据包离开家庭网络用户把截图发给朋友朋友当晚就装上。注意 Vision 写的是体验而非功能清单——这是 SKILL.md 与 ISAFormat.md 反复强调的写法「The claims verify the specific summit; the Vision keeps the universal one in view」。3.3 Out of Scope反愿景一次性说清「不做什么」示例声明了七条范围外事项每条都给出理由无强制云账号完全离线运行云同步可选且默认关闭无电费账单集成聚合的是传感器数据而非账单数据无 HVAC/家电控制WattWatch 只读不写v1 无自动化无移动端仅桌面未来最多做桌面应用自带的只读 Web 视图无商业/多租户部署单家庭、单用户、单机不支持无法合法解码的厂商加密协议Shelly 本地 HTTP 可以、Emporia Vue 本地 UDP 可以、Sense 逆向云协议推迟到其发布文档化本地 API无实时电价套利/电池调度优化v1 只做可视化。3.4 Principles约束「思考方式」五条原则都是可泛化的价值观而非技术选型本地优先不是特性而是整体姿态传感器数据属于房主不回家、不上报遥测、读路径不嵌第三方 SDK精致的单用户桌面应用在 2026 年是正当产品品类硬件集成天生脆弱应用对部分覆盖保持诚实历史数据神圣不可侵犯。3.5 Constraints锁定「解空间」约束是不可动摇的架构命令WattWatch 给出七条硬约束TypeScript Bun 工具链桌面壳用Tauri 2.xRust 系统 webview而非 Electron压缩包体 ≤ 25MB所有传感器数据存本地 SQLite${APP_DATA}/wattwatch/db.sqlite无远程主存储平台分级macOS 13一级须达到生产质量、Linux x86_64/aarch64AppImage .deb二级、Windows 10三级已知问题写进 release notes认证全部本地化单密码、Argon2id、存 OS keychain无 SSO/OAuth/账号服务器可选云同步默认关端到端加密、用户派生密钥同步服务器是「读不到内容的薄中继」传感器轮询节奏可配但受限最小 1 秒、最大 5 分钟整屋默认 5 秒、单设备默认 30 秒UI 在 2019 款 8GB MacBook Air、累积 90 天数据下保持 60fps 滚动、交互延迟 p95 ≤ 100ms。3.6 Goal1–3 句「难以随意变动的主干」Goal 把上述一切压缩成可验证的交付声明交付一个代号 WattWatch、经签名安装包分发的 Tauri 桌面应用聚合 Shelly、Emporia Vue、Sense、Tesla Powerwall 数据到统一本地 SQLite 存储提供实时整屋视图 单设备归因 六个月历史归档默认完全离线、可选端到端加密云同步。四、核心50 条 ISC 验收标准按域组织WattWatch 的## Criteria节旧式标题新版为## Claims两者都解析是文章的主体——50 条原子 claim每条都能用单一二进制探针证伪。示例按十个业务域分组覆盖了从构建分发到反指标的完整验收面4.1 Build DistributionISC-1 ~ ISC-5bun run tauri build产出 macOS arm64 签名.dmg、Linux x86_64.AppImage、Windows x64.msimacOS.dmg公证通过spctl --assess --verbose报告accepted (sourceNotarized Developer ID)三平台产物压缩后 ≤ 25MBwattwatch.example.org/download提供最新签名产物并附 SHA-256wattwatch --version打印与package.json一致的 semver。4.2 First-Run OnboardingISC-6 ~ ISC-11首次启动向导 ≤ 10 分钟完成用户持一台 Shelly 一台 PowerwallLAN 扫描经 mDNS_shelly._tcp.local30 秒内自动发现 ShellyEmporia Vue 配置接受本地凭据并验证 UDP 65432 可达Tesla Powerwall 配置接受网关 IP 与客户密码无需特斯拉云账号Sense 集成前置「实验性——仅云端」免责声明**ISC-11未勾选**要求零凭据以明文落盘全部密钥进 OS keychain——这是一个「还没完成」的 claim 的正确示范留在列表里不假装完成。4.3 Sensor DriversISC-12 ~ ISC-17Shelly 驱动经本地 HTTP APIGen1/status、Gen2/rpc/Shelly.GetStatus轮询 Gen1/Gen2Emporia Vue 驱动解码本地 UDP 广播把 16 路电路通道映射为用户命名标签Tesla Powerwall 驱动对/api/login/Basic认证每 5 秒轮询/api/meters/aggregates与/api/system_status/soeSense 驱动实验性经文档化 WebSocket 认证并明确警告该路径需要 Sense 云端往返驱动健康状态机连续 3 次轮询失败标记degraded连续 10 次失败标记offline并暂停轮询 60 秒轮询延迟预算LAN 传感器 p95 ≤ 200ms云传感器Sensep95 ≤ 2000ms。4.4 Data Model StorageISC-18 ~ ISC-22SQLite schema 含 8 张表device、sensor_reading、circuit、aggregate_5min、aggregate_hourly、aggregate_daily、event、user_prefsensor_reading持续汇总到aggregate_5min原始读数 7 天后裁剪aggregate_hourly保留 13 个月aggregate_daily无限期保留启动时执行PRAGMA integrity_check失败走恢复向导、绝不静默忽略用户触发的Export → JSON在 ≤ 30 秒内写出 6 个月全历史带时间戳文件。4.5 UI / Real-Time ViewISC-23 ~ ISC-28实时仪表盘每 5 秒更新整屋功率、光伏产量、电池 SOC、电网进出逐回路面板按当前电流排序并带 60 分钟 sparklineSankey 能量流图实时渲染 solar → home/battery/grid 分流**ISC-26未勾选**要求任意回路的 raw/hourly/daily 三级下钻视图放大/平移ISC-27/ISC-28 把性能预算落成可测指标2019 MacBook Air 90 天数据下 60fps 滚动、点击到首帧 p95 ≤ 100ms。4.6 AlertsISC-29 ~ ISC-32规则形如if metric op threshold for duration规则触发时弹系统通知并写event行告警状态跨重启持久化、应用关闭期间的告警下次启动展示**ISC-32未勾选**要求即使系统拒绝通知告警仍写入应用内日志。4.7 AuthISC-33 ~ ISC-36首次启动设置本地密码Argon2idm64MB, t3, p4本地密码在启动时解锁 SQLCipher 加密密钥连续 5 次解锁失败触发 5 分钟冷却密码重置需用户确认会丢失既有加密数据v1 无恢复密钥。4.8 Cloud SyncISC-37 ~ ISC-41全部未勾选这组 ISC 展示了「把功能推迟到 v1.1」时的处理方式云同步默认 OFF开启前显示单屏「什么数据会离开设备」说明开启时用 HKDF 每安装稳定盐从本地密码派生同步密钥同步载荷客户端 AES-256-GCM 加密、中继只存密文第二台设备凭相同密码邮箱 60 秒内配对关闭同步 24 小时内删除服务器端密文并弹确认。4.9 UpdatesISC-42 ~ ISC-43每 24 小时检查wattwatch.example.org/api/release/latest一次仅在用户点击「Install」后应用更新更新载荷签名未签名或篡改即中止并可见报错。4.10 OperationalISC-44 ~ ISC-45诊断导出把 SQLite schema不含行、驱动日志最近 24h、OS 信息打包成.zip供支持崩溃报告器 opt-in发送前展示将要发送的确切字节。4.11 Anti-criteria反指标ISC-46 ~ ISC-50反指标是把 Out of Scope / Constraints / Principles 变成可探测的关键机制WattWatch 写了五条Anti: privacy—— 首次启动、用户显式开启云同步之前零出站网络请求用抓包验证Anti: out of scope—— UI 中没有任何Control按钮传感器写路径未接线Anti: data loss—— 应用更新从不覆盖或迁移 SQLite 而不先写带时间戳的.bakAnti: dependency creep—— 构建图里没有 Electronbun pm ls | grep electron为空Anti: telemetry——rg google-analytics|sentry|mixpanel|posthog|fullstory src/零匹配。对照 SKILL.md 的三护栏分类Principles 约束思考、Constraints 约束解空间、Out of Scope 约束愿景、Anti-criteria 约束测试面这五条反指标正是前三者的「探针化」产物。五、Test Strategy每条 claim 一条可执行探针WattWatch 的## Test Strategy采用 YAML 列表形态新版规范是六列/七列表格isc | type | check | threshold | tool | anchors_to | severity示例为历史形态两者语义一致为每条关键 ISC 指定验证类型、检查内容、通过阈值与工具命令ISC类型检查阈值工具ISC-2notarizationmacOS Gatekeeper 接受签名 .dmgspctl报告accepted (sourceNotarized Developer ID)spctl --assess --verbose dist/WattWatch.dmgISC-3bundle-size压缩后产物体积≤ 25MBdu -m dist/WattWatch.dmg ...ISC-7lan-discoverymDNS 扫描返回测试台上 Shelly 设备≥ 1 台≤ 30sbun run scripts/mdns-probe.tsISC-14driver-integrationPowerwall 驱动读取/api/meters/aggregates返回 site/load/solar/battery 值bun run scripts/powerwall-probe.ts --gateway 192.168.x.xISC-21db-integrity既有库上执行PRAGMA integrity_check返回oksqlite3 ${APP_DATA}/wattwatch/db.sqlite PRAGMA integrity_checkISC-27performance90 天数据下 60fps 滚动中位帧时间 ≤ 16.6mstauri devtools performance recorderISC-28interaction-latency点击 → 首帧 p95≤ 100msbun run scripts/ui-latency.ts --runs 200ISC-39crypto同步载荷为 AES-256-GCM 密文载荷熵 ≥ 7.9 bits/bytebun run scripts/sync-payload-entropy.tsISC-46anti-probe首次启动未同意前出站包到非 LAN 目的地的包为 0tcpdump -i en0 not net 192.168.0.0/16 ...60sISC-49anti-dep依赖树无 Electron空匹配bun pm ls \| rg -i electronISC-50anti-telemetry源码无第三方遥测 SDK 字符串0 匹配rg google-analytics\|sentry\|... src/从这份清单可以提炼出 ISA 探针设计的两个要点一是探针要落在「事物与消费者的接缝处」ISAFormat.md 的 seam rule——探针挂在最高且最贴近消费者的边界上二是优先用可运行的确定性探针bash/curl/bun-test 类只有无法运行化的场景才退回截图或人工检查。六、Features垂直切片式功能分解## Features用 YAML 块列出 11 个功能每个声明name、description、satisfies满足哪些 ISC、depends_on与parallelizableSensorDriverShelly / Emporia / Powerwall / Sense四个独立传感器驱动全部parallelizable: true——彼此无依赖这正是「垂直切片」的体现每个驱动端到端满足自己的发现/轮询/健康/延迟预算 claimLocalStorageSQLCipher 支撑的 SQLite含 rollup、保留策略、完整性检查satisfies 含 ISC-18/19/20/21/22/34/48parallelizable: false数据层是串行核心AuthLocalArgon2id OS keychain 冷却depends_on: [LocalStorage]解锁加密密钥依赖存储LiveDashboard实时整屋视图 Sankey 逐回路面板依赖三个主要驱动与 LocalStorageAlerts / CloudSyncOptional / Updater / Distribution / Diagnostics其余功能块CloudSyncOptional 依赖 AuthLocal LocalStorage符合「从本地密码派生同步密钥」的调用链。对照 ISAFormat.md 的 Feature blocks 规则v2.16.0新版中 Features 是承载 claim 的块### Fn · name 一行Why: 内嵌 ISC旧式name | satisfies指针表已删除——本示例展示的正是旧指针表形态其「功能 ↔ ISC 映射」的思想在 v2.16.0 后由 feature block 直接内嵌承载。七、Decisions决策日志与 Dead End## Decisions是带时间戳的决策日志包括死路dead end。WattWatch 记录了七条关键决策其中两条是标注 ❌ DEAD END 的失败尝试2026-01-15选 Tauri 2.x 弃 Electron——≤ 25MB 的包体约束在 Electron 的 Chromium 基线~120MB下不可能达成且系统 webview 复用能显著改善 tier-1 macOS 的冷启动延迟2026-01-22选 SQLite SQLCipher 而非自定义加密 KV——数据形态是真正关系型的设备/回路/读数/聚合且「房主导出」用例要求可移植文件格式❌ DEAD END2026-02-04曾尝试让单个 Worker 线程轮询全部四类传感器以简化调度器。结果卡死的 Sense WebSocket 阻塞了 Shelly 轮询仪表盘延迟超出 ISC-28 达 4 倍。回退为「每驱动独立 worker 隔离事件循环」并明确写「Dont retry」2026-02-19refined:精化 ISC-19 保留策略——「原始读数无限期保留」是幼稚的7 天原始 13 个月小时 无限期天级才是能在 256GB Mac 上撑过 6 个月的真实存储形态❌ DEAD END2026-03-02曾尝试 LAN 认证失败时回退厂商云 API。这违反本地优先原则、引入隐藏云依赖回退为诚实的「该传感器离线」UI2026-03-14云同步从 v1 推迟到 v1.1——中继服务器威胁模型不简单先交付本地优先产品更诚实2026-03-29refined:把 ISC-46 从「无遥测」锐化为「首次启动、用户选择加入前对非 LAN 目的地零出站包」——抓包审查发现 Tauri 的自动更新探测在同意前就触发了更新检查改为等用户完成 onboarding 之后2026-04-10Sense 驱动保留为experimental而非砍掉——用户调研显示 Sense 用户是被现有工具服务最不到位的人群2026-04-22refined:ISC-3 包体目标从 35MB 收紧到 25MB。refined:前缀是 ISAFormat.md 对 Goal/ISC 重构的约定标记而❌ DEAD END ... Dont retry则是把「被证伪的路径」永久钉进审计轨迹防止未来重新论证同一错误。八、ChangelogLearningC/R/L 四段式纠错轨迹示例的## Changelog节新版规范更名为## Learning采用conjectured / refuted by / learned / criterion now四段式格式记录「理解发生变化」的时刻每条都必须四段齐全——SKILL.md 的 Gotchas 明确Append 工作流拒绝写不完整的 C/R/L缺任何一段就是 Decision 而非 Learning entry。WattWatch 示范了四条2026-02-04猜想「单一轮询 worker 承载全部驱动可简化架构且无可见代价」→ 被「卡死的 Sense WebSocket 阻塞 Shelly 轮询、交互延迟超 ISC-28 达 4 倍」证伪 → 学到「一个驱动的失败模式是挂起连接而非错误响应时必须做驱动级隔离」→ criterion nowISC-17 拆分为 LAN 预算≤200ms与云预算≤2000ms驱动实现迁到独立 worker2026-02-22猜想「7 天原始读数够高级用户下钻」→ 被 beta 用户「想查 30 天前 5 分钟分辨率的加热泵诊断数据」证伪 → 学到「5 分钟聚合才是正确的下钻分辨率」→ criterion nowISC-19 锐化为原始 7 天 / 5 分钟聚合 13 个月 / 天级无限期2026-03-02猜想「LAN 认证失败时回退厂商云是对用户的善意」→ 被「回退不可见测试者带着云回退跑了 3 周没察觉」证伪 → 学到「跨信任边界的静默回退违反用户心智模型」→ criterion now无 ISC 变更决策入日志、原则进入代码审查清单2026-03-29猜想「Tauri 默认自动更新探测可以在同意前发布」→ 被「抓包发现欢迎屏都没看到就触发了探测」证伪 → 学到「『无遥测』不够审计必须包含框架默认网络行为」→ criterion nowISC-46 锐化、更新检查推迟到 onboarding 之后。这套格式的价值在于它把「我们当时为什么这么想、现实如何反驳、我们现在知道什么、标准因此如何变化」完整保留跨会话、跨 Agent 可审计——这正是 LifeOS 的 Deutsch 纠错轨迹error-correction trail。九、Verification一行式溯源存根## Verification节为每条已通过[x]的 claim 保存一行溯源存根指向证明所在处commit hash、测试名或探针引用而非大段证据ISC-2spctl --assess --verbose dist/WattWatch.dmg→accepted (sourceNotarized Developer ID)ISC-3du -m→ dmg 22M / AppImage 19M / msi 24MISC-7测试 LAN 上 3 台 Shelly Gen2 全部在 4.1s 内被发现ISC-14探针返回{site_now: -1240, load_now: 3120, solar_now: 4360, battery_now: 0, percentage_charged: 87.4}ISC-21PRAGMA integrity_check→okISC-272019 MacBook Air 90 天数据集滚动中位帧时间 14.2msISC-28200 次运行 p95 点击到首帧 78msISC-46首次启动同意前 60 秒 tcpdump → 0 个非 LAN 目的地包ISC-49 / ISC-50依赖树与源码扫描均为空对照 ISAFormat.md 的「证据在关闭时坍缩」约定Algorithm v8.7.1 claim 12claim 勾选的那一刻其 Verification 条目就压缩为一行存根证据留在 git 与 CI 中ISA 只负责「指向」。一个不断堆积证据段落的 Verification 节正是该约定要防止的失败。十、从 WattWatch 提炼的可复用写作模式读完这份 50-ISC 示例可以提炼出六个直接可复用的 ISA 写作手法边界先行Problem → Vision → Out of Scope → Principles → Constraints 五节是「写 claim 之前的清场」——先把解空间划死claim 才有意义原子化 claim 与单一探针每条 ISC 可被一条命令/一次观察证伪模糊表述如「Email is delivered」会被 ISAFormat.md 的硬变体性示例fluff vs load-bearing 对比淘汰性能预算必须数字化60fps≤16.6ms 帧时间、p95 ≤ 100ms、包体 ≤ 25MB、发现 ≤ 30s——凡约束能映射为预算的都需要数字 ISC而不是「要快」这种氛围反指标不可缺至少一条Anti:claim 把隐私/范围/依赖纪律变成可扫描的探针这是 CheckCompleteness 的硬性要求之一未完成与推迟要如实呈现ISC-11、ISC-15、ISC-26、ISC-32、ISC-37~41 保持[ ]或整体未勾选不假装完成——ISA 展示的是诚实状态失败要留痕两条 DEAD END 四条完整 C/R/L让「什么被证伪过、为什么、标准因此变成什么」永久可查。十一、继续深入相关文档与源码想要把这份示例用到自己的项目可以顺着以下仓库路径继续格式规范权威文件形状契约ISAFormat.md——十七节固定顺序、Frontmatter Field Rules、Test Strategy 六/七/八列契约、ID-Stability、Completeness Gate系统架构概念框架ISASystem.md——五重身份、三护栏分类、六工作流、两处存放地技能主文件工作流路由与 GotchasSKILL.md六条工作流Scaffold.md、Interview.md、Grill.md、CheckCompleteness.md、Reconcile.md、Seed.md、Append.md其他示例按领域选模板canonical-isa.mdBeanLine 示范件先读、e5-enterprise.md企业级、e4-api-migration.md跨切面迁移解析与执行侧源码isa-utils.tsISA 解析、IsaFrontier.ts依赖边与前哨计算、ISAGate.ts关闭门禁、ISARender.ts渲染。结语一份好的 ISA 不是需求文档而是「把 done 写成可证伪的 claim再让每条 claim 都被真实世界检验」的活体解释。WattWatch 示例的价值在于它用 50 条 ISC 完整演示了桌面应用从架构选型Tauri vs Electron、数据模型SQLite rollup 三级保留、硬件驱动四类传感器、认证加密Argon2id SQLCipher到反指标零遥测、零出站的全谱系验收怎么写并用 DEAD END 与 C/R/L 轨迹示范了「理解如何随时间被现实修正」。下次面对任何「要做成什么样才算完成」的问题时照这份骨架把边界划清、把 claim 写细、把探针挂到接缝处你就已经在用 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），仅供参考