LifeOS ApertureOscillation 技能实战三程光圈振荡在组件逻辑与系统一致性之间定位设计张力【免费下载链接】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导读ApertureOscillation 是 LifeOS 内置的一项作用域振荡思考技能把同一个问题固定不变在两个缩放级别上分别作答——先是窄口径组件优先再是宽口径系统优先——然后综合两轮答案输出两者分叉之处。这个分叉本身就是交付物设计张力、作用域建议、以及任何单一缩放级别都无法浮现的一致性裁决。本文以该技能的工作流文档 Oscillate.md 为主体结合 SKILL.md 与 Algorithm v8.20.2 中关于思考技能硬下限与集成点的证据完整讲解它的触发方式、输入定义、三程执行结构、输出模板、Agent 委托协议与最佳实践。读完你将掌握一套可立即投入架构决策、功能设计与系统一致性审查的作用域振荡方法并理解它在 LifeOS 运行循环OBSERVE/THINK 阶段中的精确挂载位置。为什么需要振荡作用域单次缩放必然失明一个组件在孤立环境中设计会得到属于它自己的干净逻辑同一个组件放到一个明确的系统愿景中设计则要继承截然不同的约束。只选一个缩放级别就会错过另一个——要么交付一个自己运行得很好、却和系统打架的组件要么交付一个服务了系统、却无视组件天然形态的组件。最昂贵的返工恰恰来自这种错配而且通常是在构建进行到一半时才被发现。ApertureOscillation 的认知基础是LLM以及人类会根据框架上下文的作用域产出不同的答案。该技能的做法不是旋转分析透镜那是 IterativeDepth 的工作也不是发散生成想法那是 BeCreative 的工作而是把问题保持不变只围绕它移动作用域包络做三次结构化的 pass窄口径战术优先具体事物为主宏观背景为辅捕捉组件天然想成为什么——它自己的内部逻辑与形态宽口径战略优先愿景/系统目标为主具体事物由它推导而来捕捉系统需要组件成为什么——局部思维容易遗漏的一致性、对齐要求与约束振荡综合把两轮输出喂到一起追问战术视图与战略视图在哪里分叉。两轮之间的张力、缺口与意外就是输出本身。何时调用三种触发路径根据工作流文档ApertureOscillation 可以通过三种方式被唤起用户直接调用例如说 use aperture oscillation on this对这件事做光圈振荡、oscillate scope on this对这件事做作用域振荡由 Algorithm 调用在 OBSERVE 或 THINK 阶段当 ApertureOscillation 能力被选中时详见下文与 Algorithm 阶段的集成由其他技能调用任何需要在承诺某个方案之前先做作用域-一致性分析的技能。技能自身的路由表见 SKILL.md进一步说明触发短语包括 aperture oscillation、oscillate scope、zoom in/out放大缩小、tactical vs strategic战术 vs 战略等其描述字段同时声明了NOT FOR lens rotation across angles跨角度旋转透镜请改用 IterativeDepth的反向边界。输入定义两个必须不同的输入调用前需要准备三个输入其中前两个是必需的输入含义说明Tactical Target战术目标正在构建、设计或决策的那个具体事物窄而具体的那个问题Strategic Context战略上下文战术目标所服务的更大图景、系统愿景或目的更宏观的目标Current State当前状态可选已有的 ISC 标准、方案决策或约束可复用既有结论如果没有显式输入则从对话中提取tactical 当前正在处理的那个具体诉求strategic 上下文中的更宏大目标、系统或愿景来自 CLAUDE.md、TELOS、项目上下文。中止条件abort如果战术目标和战略上下文本质上是同一回事不存在有意义的作用域差异则立即中止转而推荐 IterativeDepth。这是该技能的守门逻辑——两个输入必须有真实差异振荡才有价值。SKILL.md 的 Gotchas 部分也强调如果 tactical target 和 strategic context 是同一个东西ApertureOscillation 就没有增量价值——请改用 IterativeDepth。一次完成的振荡长什么样三条验收标准工作流文档明确给出了 done-definition输出必须同时具备三个属性窄口径答案以组件为主、系统为背景来回答同一个问题——捕捉组件天然想成为什么它自己的逻辑、模式、惯例、接口以及孤立来看一个好的实现应该是什么样宽口径答案以系统为主、组件由系统推导而来——捕捉系统需要组件成为什么与相邻部件的连贯性、对齐要求以及更大图景强加的、局部思维看不到的约束综合结论逐一列出两轮答案分叉的每一个点给每个分叉一个解决方案最后以一致性裁决ALIGNED 一致或DIVERGENT 分歧收尾。如果两轮答案一致那么没有分叉本身就是发现——把它说出来这意味着战术与战略层面已经一致。文档特别强调两轮 pass 必须在以谁为主上真正不同——如果宽口径答案只是窄口径答案的复述说明作用域切换没有真正发生。要把每个框架推到另一个框架不会产生这种结论的程度。输出模板完整的报告结构运行结束后先框定两个输入再按以下模板报告结果模板需完整保留是团队协作与结果沉淀的统一格式 APERTURE OSCILLATION Tactical Target: [the specific thing — 1-2 sentences] Strategic Context: [the bigger picture — 1-2 sentences] ── Narrow (component-first) ── [what the component wants to be, on its own logic] ── Wide (system-first) ── [what the system needs the component to be] ── Synthesis ── Divergences: [each point where narrow and wide disagree] ⚡ DESIGN TENSIONS: [each tension resolution recommendation] ISC IMPLICATIONS: [new / refined / anti- criteria surfaced by the oscillation] Coherence: [ALIGNED | DIVERGENT — one-line verdict] Key Insight: [the most important thing single-scope analysis would have missed]其中ISC IMPLICATIONSISC 含义一节把振荡产出的设计张力转化为可写入 ISA 的判据——新增new、精炼refined或反判据anti-标准。这正好呼应了 Algorithm 文档中ISA 的每个 claim 都要命名能证伪它的探针的设计哲学见 v8.20.2.md振荡不只是输出一段分析而是为后续的判据书写提供输入材料。Key Insight一行则强制收敛出单作用域分析一定会漏掉的最重要的一件事。与 Algorithm 阶段的集成OBSERVE 与 THINK 两个挂载点ApertureOscillation 不是孤立的技能它在 LifeOS 运行循环中有两个精确的集成点这是它在 Algorithm 中被能力化调用的正式入口OBSERVE 阶段在写 ISC 判据之前tactical target 用户的请求strategic context 项目 / TELOS / 对话上下文。作用是在 ISC 判据落笔之前就浮现设计张力让判据本身被作用域振荡所滋养THINK 阶段在承诺方案之前tactical target 被提议的方案strategic context 更宏观的系统/项目目标。作用是验证方案在被承诺之前同时服务于局部需求与系统需求。在 changelog.md 中可以找到这套机制为何存在的历史依据v6.3.02026-04-29记录了一次思维能力词汇闭合枚举回归——当 {{PRINCIPAL_NAME}} 要求在 E2 级别强制思考技能数量时系统倾向于编造通用标签decomposition、edge-case enumeration而不是从规范列表中原样选用 FirstPrinciples、IterativeDepth、ApertureOscillation、SystemsThinking、RootCauseAnalysis 等真实能力。v6.1.0 则把思考能力数量定为硬性下限hard floorE2 ≥2、E3 ≥4、E4 ≥6、E5 ≥8取自 capabilities.md 中Thinking Analysis表且不能被 show-your-math 豁免。这意味着在高努力级别Deep E4 / Comprehensive E5运行架构类任务时ApertureOscillation 是被 Algorithm 明确计数和期望调用的思考能力之一而非可选的锦上添花。在 settings.enhancements.json 中ApertureOscillation 同样被收录进思考技能清单描述为 tactical/strategic scope oscillation — surface design tensions invisible at any single zoom level战术/战略作用域振荡——浮现任何单一缩放级别都看不见的设计张力。与 IterativeDepth 的组合使用互补而非竞争ApertureOscillation 与 IterativeDepth 是互补关系不是竞争关系先 IterativeDepth——从多个分析角度理解问题每次 pass 用一个不同科学透镜2-8 轮产出隐藏需求与盲点再 ApertureOscillation——验证被提议的方案是否同时服务于局部与系统需求。在 DeepE4或 ComprehensiveE5努力级别两者按序使用能产出最丰富的要求集IterativeDepth 发现完整的问题空间ApertureOscillation 确保方案契合系统。SKILL.md 中的对比表精确划分了两者的边界维度IterativeDepthApertureOscillation变化的量分析透镜失败、利益相关者、时间…作用域/缩放级别窄、宽、综合pass 数量2-83固定输入单一问题陈述两个输入tactical target strategic context输出多角度获得的更丰富需求局部视图与系统视图之间的设计张力最适合需求发现、盲点消除架构决策、功能设计、系统一致性何时组合先用 IterativeDepth理解问题再用 ApertureOscillation理解方案落在哪里一个易混点3 次 pass 是正确的次数。与 IterativeDepth 的 2-8 轮不同窄/宽/综合的结构在 3 轮时就已完备——再增加 pass 只会变成透镜旋转那是 IterativeDepth 的职责。ApertureOscillation 的 Quick Reference 也强调3 passes — always 3 (narrow, wide, synthesis)。Agent Mode为 Algorithm 委托而生的代理简报模板当需要派生一个 agent 去执行 ApertureOscillation 时用下面这份完整简报模板把两个输入和 done-definition 一并交代清楚该模板同时充当 SLA 约定CONTEXT: Perform Aperture Oscillation — answer one question at two scope levels to surface design tensions between local component logic and system-level coherence. TACTICAL TARGET: {specific thing being built} STRATEGIC CONTEXT: {bigger-picture goal or system vision} DELIVERABLE: a narrow (component-first) answer, a wide (system-first) answer to the same question, and a synthesis naming every divergence with a resolution and a coherence verdict (ALIGNED | DIVERGENT). Report design tensions and ISC implications. SLA: Complete within 45 seconds.这份模板的价值在于它把技能的方法论固化成可复用的委托协议——CONTEXT 说明任务性质TACTICAL/STRATEGIC 两个占位符承载输入DELIVERABLE 明确三程结构与产出形态SLA 规定完成时限。在 LifeOS 的 Algorithm 语境下见 v8.20.2.md 的Delegate liveness工具契约委托必须有明确交付物和时限约束这份模板正好与之对齐。实战示例从缓存层到 Webhook 的两个完整走查SKILL.md 提供了两个端到端示例完整呈现三程振荡的实际产出形态。示例一系统内的功能设计Tactical target: Build a caching layer for session data Strategic context: LifeOS is a Life OS that needs responsive, session-spanning AI assistance Pass 1 (Narrow): Redis with TTL, standard session cache patterns Pass 2 (Wide): Cache must survive session boundaries, integrate with memory system, serve the Life OS vision Pass 3 (Synthesis): Tension — standard session cache expires data that the Life OS needs to persist. Resolution: hybrid cache with session-scoped fast layer memory-backed persistent layer.注意这里的张力结构窄口径给出的是教科书式的Redis TTL 标准会话缓存宽口径则暴露出Life OS 需要跨会话持久这一局部思维看不到的约束两者冲突TTL 会清掉需要持久化的数据最终裁决是混合缓存——会话级快速层 内存回退持久层。示例二架构决策Tactical target: Add webhook support to the Feed system Strategic context: Feed is one pipeline in Arbol, which processes content for Surface Pass 1 (Narrow): Standard webhook receiver, queue, retry logic Pass 2 (Wide): Webhooks must flow through Arbols action/function pattern, integrate with existing queue infrastructure Pass 3 (Synthesis): Tension — standalone webhook service vs. Arbol action. Resolution: implement as Arbol action, not standalone service, because the strategic context demands pipeline coherence over component independence.这个示例点出了振荡最有价值的一类结论该做成服务、库还是内联代码的答案完全取决于你是放大到组件还是缩小到系统SKILL.md 的 Use/Win 部分明确列出这一触发场景。最终裁决是作为 Arbol action 而非独立服务实现因为战略上下文要求管线一致性优先于组件独立性——这是纯组件视角给不出的答案。使用收益与触发场景使用时机任何时候你在一个更大的系统内构建某个具体事物需要确保局部设计服务全局愿景、同时又不丢失组件自身逻辑时。具体触发场景来自 SKILL.md 的 Use/Win架构决策——这应该做成服务、库还是内联代码完全取决于你的缩放级别功能设计——用户要的功能与产品需要的功能往往微妙不同振荡能浮现这个差距系统一致性检查——向现有基础设施新增部件时新部件必须同时服务于自身目的和系统目的单作用域框架会漏掉其中一个设计评审——在承诺方案之前振荡作用域检查战术计划与战略愿景是否一致作用域协商——当用户说构建 X而 X 的复杂度取决于上下文时振荡能揭示哪种作用域是合适的。收益在成为构建中途的意外之前浮现设计张力——最贵的返工来自自己运行得很好、但不服务系统的组件作用域清晰——在窄口径和宽口径下看同一个问题往往发现显而易见的那个作用域其实是错的一致性信心——战术与战略对齐时可以带着确信去构建分歧时你确切知道该在哪里做权衡。Gotchas 与运行记录三个关键注意点SKILL.md 的 Gotchas需要两个不同的输入——tactical 与 strategic 相同时改用 IterativeDepth3 次 pass 是正确的数量——结构在 3 轮时完备加 pass 属于 IterativeDepth 的职责综合 pass 才是价值所在——第 1、2 轮只是铺垫如果综合轮没有发现分叉那也是合法且有价值的发现说明战术与战略视图已经对齐。另外SKILL.md 自注这是一项BPE-fragile对更智能模型脆弱的技能——更聪明的模型可能无需提示就天然会振荡作用域因此建议按季度测试Quarterly test recommended。执行记录每次完成工作流后向执行日志追加一行 JSONL 记录这是技能可观测性的组成部分echo {ts:$(date -u %Y-%m-%dT%H:%M:%SZ),skill:ApertureOscillation,workflow:Oscillate,input:8_WORD_SUMMARY,status:ok|error,duration_s:SECONDS} ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl其中8_WORD_SUMMARY用一句话简述输入内容SECONDS填近似耗时工作流失败时记录status: error。自定义覆盖与仓库导航与 LifeOS 的其他技能一致ApertureOscillation 支持用户级自定义覆盖执行前先检查~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/ApertureOscillation/若该目录存在则加载其中的 PREFERENCES.md、配置或资源覆盖默认行为不存在则按技能默认执行。这是 LifeOS 面向不同用户个性化思考技能的标准机制。进一步阅读本主题在仓库中的完整材料工作流文档Oscillate.md本文主体技能定义与示例SKILL.md互补技能IterativeDepth/SKILL.md集成点与思考能力硬下限LIFEOS/ALGORITHM/v8.20.2.md、LIFEOS/ALGORITHM/changelog.md技能清单中的收录条目settings.enhancements.json【免费下载链接】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 ApertureOscillation 技能实战：三程光圈振荡，在组件逻辑与系统一致性之间定位设计张力
LifeOS ApertureOscillation 技能实战三程光圈振荡在组件逻辑与系统一致性之间定位设计张力【免费下载链接】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导读ApertureOscillation 是 LifeOS 内置的一项作用域振荡思考技能把同一个问题固定不变在两个缩放级别上分别作答——先是窄口径组件优先再是宽口径系统优先——然后综合两轮答案输出两者分叉之处。这个分叉本身就是交付物设计张力、作用域建议、以及任何单一缩放级别都无法浮现的一致性裁决。本文以该技能的工作流文档 Oscillate.md 为主体结合 SKILL.md 与 Algorithm v8.20.2 中关于思考技能硬下限与集成点的证据完整讲解它的触发方式、输入定义、三程执行结构、输出模板、Agent 委托协议与最佳实践。读完你将掌握一套可立即投入架构决策、功能设计与系统一致性审查的作用域振荡方法并理解它在 LifeOS 运行循环OBSERVE/THINK 阶段中的精确挂载位置。为什么需要振荡作用域单次缩放必然失明一个组件在孤立环境中设计会得到属于它自己的干净逻辑同一个组件放到一个明确的系统愿景中设计则要继承截然不同的约束。只选一个缩放级别就会错过另一个——要么交付一个自己运行得很好、却和系统打架的组件要么交付一个服务了系统、却无视组件天然形态的组件。最昂贵的返工恰恰来自这种错配而且通常是在构建进行到一半时才被发现。ApertureOscillation 的认知基础是LLM以及人类会根据框架上下文的作用域产出不同的答案。该技能的做法不是旋转分析透镜那是 IterativeDepth 的工作也不是发散生成想法那是 BeCreative 的工作而是把问题保持不变只围绕它移动作用域包络做三次结构化的 pass窄口径战术优先具体事物为主宏观背景为辅捕捉组件天然想成为什么——它自己的内部逻辑与形态宽口径战略优先愿景/系统目标为主具体事物由它推导而来捕捉系统需要组件成为什么——局部思维容易遗漏的一致性、对齐要求与约束振荡综合把两轮输出喂到一起追问战术视图与战略视图在哪里分叉。两轮之间的张力、缺口与意外就是输出本身。何时调用三种触发路径根据工作流文档ApertureOscillation 可以通过三种方式被唤起用户直接调用例如说 use aperture oscillation on this对这件事做光圈振荡、oscillate scope on this对这件事做作用域振荡由 Algorithm 调用在 OBSERVE 或 THINK 阶段当 ApertureOscillation 能力被选中时详见下文与 Algorithm 阶段的集成由其他技能调用任何需要在承诺某个方案之前先做作用域-一致性分析的技能。技能自身的路由表见 SKILL.md进一步说明触发短语包括 aperture oscillation、oscillate scope、zoom in/out放大缩小、tactical vs strategic战术 vs 战略等其描述字段同时声明了NOT FOR lens rotation across angles跨角度旋转透镜请改用 IterativeDepth的反向边界。输入定义两个必须不同的输入调用前需要准备三个输入其中前两个是必需的输入含义说明Tactical Target战术目标正在构建、设计或决策的那个具体事物窄而具体的那个问题Strategic Context战略上下文战术目标所服务的更大图景、系统愿景或目的更宏观的目标Current State当前状态可选已有的 ISC 标准、方案决策或约束可复用既有结论如果没有显式输入则从对话中提取tactical 当前正在处理的那个具体诉求strategic 上下文中的更宏大目标、系统或愿景来自 CLAUDE.md、TELOS、项目上下文。中止条件abort如果战术目标和战略上下文本质上是同一回事不存在有意义的作用域差异则立即中止转而推荐 IterativeDepth。这是该技能的守门逻辑——两个输入必须有真实差异振荡才有价值。SKILL.md 的 Gotchas 部分也强调如果 tactical target 和 strategic context 是同一个东西ApertureOscillation 就没有增量价值——请改用 IterativeDepth。一次完成的振荡长什么样三条验收标准工作流文档明确给出了 done-definition输出必须同时具备三个属性窄口径答案以组件为主、系统为背景来回答同一个问题——捕捉组件天然想成为什么它自己的逻辑、模式、惯例、接口以及孤立来看一个好的实现应该是什么样宽口径答案以系统为主、组件由系统推导而来——捕捉系统需要组件成为什么与相邻部件的连贯性、对齐要求以及更大图景强加的、局部思维看不到的约束综合结论逐一列出两轮答案分叉的每一个点给每个分叉一个解决方案最后以一致性裁决ALIGNED 一致或DIVERGENT 分歧收尾。如果两轮答案一致那么没有分叉本身就是发现——把它说出来这意味着战术与战略层面已经一致。文档特别强调两轮 pass 必须在以谁为主上真正不同——如果宽口径答案只是窄口径答案的复述说明作用域切换没有真正发生。要把每个框架推到另一个框架不会产生这种结论的程度。输出模板完整的报告结构运行结束后先框定两个输入再按以下模板报告结果模板需完整保留是团队协作与结果沉淀的统一格式 APERTURE OSCILLATION Tactical Target: [the specific thing — 1-2 sentences] Strategic Context: [the bigger picture — 1-2 sentences] ── Narrow (component-first) ── [what the component wants to be, on its own logic] ── Wide (system-first) ── [what the system needs the component to be] ── Synthesis ── Divergences: [each point where narrow and wide disagree] ⚡ DESIGN TENSIONS: [each tension resolution recommendation] ISC IMPLICATIONS: [new / refined / anti- criteria surfaced by the oscillation] Coherence: [ALIGNED | DIVERGENT — one-line verdict] Key Insight: [the most important thing single-scope analysis would have missed]其中ISC IMPLICATIONSISC 含义一节把振荡产出的设计张力转化为可写入 ISA 的判据——新增new、精炼refined或反判据anti-标准。这正好呼应了 Algorithm 文档中ISA 的每个 claim 都要命名能证伪它的探针的设计哲学见 v8.20.2.md振荡不只是输出一段分析而是为后续的判据书写提供输入材料。Key Insight一行则强制收敛出单作用域分析一定会漏掉的最重要的一件事。与 Algorithm 阶段的集成OBSERVE 与 THINK 两个挂载点ApertureOscillation 不是孤立的技能它在 LifeOS 运行循环中有两个精确的集成点这是它在 Algorithm 中被能力化调用的正式入口OBSERVE 阶段在写 ISC 判据之前tactical target 用户的请求strategic context 项目 / TELOS / 对话上下文。作用是在 ISC 判据落笔之前就浮现设计张力让判据本身被作用域振荡所滋养THINK 阶段在承诺方案之前tactical target 被提议的方案strategic context 更宏观的系统/项目目标。作用是验证方案在被承诺之前同时服务于局部需求与系统需求。在 changelog.md 中可以找到这套机制为何存在的历史依据v6.3.02026-04-29记录了一次思维能力词汇闭合枚举回归——当 {{PRINCIPAL_NAME}} 要求在 E2 级别强制思考技能数量时系统倾向于编造通用标签decomposition、edge-case enumeration而不是从规范列表中原样选用 FirstPrinciples、IterativeDepth、ApertureOscillation、SystemsThinking、RootCauseAnalysis 等真实能力。v6.1.0 则把思考能力数量定为硬性下限hard floorE2 ≥2、E3 ≥4、E4 ≥6、E5 ≥8取自 capabilities.md 中Thinking Analysis表且不能被 show-your-math 豁免。这意味着在高努力级别Deep E4 / Comprehensive E5运行架构类任务时ApertureOscillation 是被 Algorithm 明确计数和期望调用的思考能力之一而非可选的锦上添花。在 settings.enhancements.json 中ApertureOscillation 同样被收录进思考技能清单描述为 tactical/strategic scope oscillation — surface design tensions invisible at any single zoom level战术/战略作用域振荡——浮现任何单一缩放级别都看不见的设计张力。与 IterativeDepth 的组合使用互补而非竞争ApertureOscillation 与 IterativeDepth 是互补关系不是竞争关系先 IterativeDepth——从多个分析角度理解问题每次 pass 用一个不同科学透镜2-8 轮产出隐藏需求与盲点再 ApertureOscillation——验证被提议的方案是否同时服务于局部与系统需求。在 DeepE4或 ComprehensiveE5努力级别两者按序使用能产出最丰富的要求集IterativeDepth 发现完整的问题空间ApertureOscillation 确保方案契合系统。SKILL.md 中的对比表精确划分了两者的边界维度IterativeDepthApertureOscillation变化的量分析透镜失败、利益相关者、时间…作用域/缩放级别窄、宽、综合pass 数量2-83固定输入单一问题陈述两个输入tactical target strategic context输出多角度获得的更丰富需求局部视图与系统视图之间的设计张力最适合需求发现、盲点消除架构决策、功能设计、系统一致性何时组合先用 IterativeDepth理解问题再用 ApertureOscillation理解方案落在哪里一个易混点3 次 pass 是正确的次数。与 IterativeDepth 的 2-8 轮不同窄/宽/综合的结构在 3 轮时就已完备——再增加 pass 只会变成透镜旋转那是 IterativeDepth 的职责。ApertureOscillation 的 Quick Reference 也强调3 passes — always 3 (narrow, wide, synthesis)。Agent Mode为 Algorithm 委托而生的代理简报模板当需要派生一个 agent 去执行 ApertureOscillation 时用下面这份完整简报模板把两个输入和 done-definition 一并交代清楚该模板同时充当 SLA 约定CONTEXT: Perform Aperture Oscillation — answer one question at two scope levels to surface design tensions between local component logic and system-level coherence. TACTICAL TARGET: {specific thing being built} STRATEGIC CONTEXT: {bigger-picture goal or system vision} DELIVERABLE: a narrow (component-first) answer, a wide (system-first) answer to the same question, and a synthesis naming every divergence with a resolution and a coherence verdict (ALIGNED | DIVERGENT). Report design tensions and ISC implications. SLA: Complete within 45 seconds.这份模板的价值在于它把技能的方法论固化成可复用的委托协议——CONTEXT 说明任务性质TACTICAL/STRATEGIC 两个占位符承载输入DELIVERABLE 明确三程结构与产出形态SLA 规定完成时限。在 LifeOS 的 Algorithm 语境下见 v8.20.2.md 的Delegate liveness工具契约委托必须有明确交付物和时限约束这份模板正好与之对齐。实战示例从缓存层到 Webhook 的两个完整走查SKILL.md 提供了两个端到端示例完整呈现三程振荡的实际产出形态。示例一系统内的功能设计Tactical target: Build a caching layer for session data Strategic context: LifeOS is a Life OS that needs responsive, session-spanning AI assistance Pass 1 (Narrow): Redis with TTL, standard session cache patterns Pass 2 (Wide): Cache must survive session boundaries, integrate with memory system, serve the Life OS vision Pass 3 (Synthesis): Tension — standard session cache expires data that the Life OS needs to persist. Resolution: hybrid cache with session-scoped fast layer memory-backed persistent layer.注意这里的张力结构窄口径给出的是教科书式的Redis TTL 标准会话缓存宽口径则暴露出Life OS 需要跨会话持久这一局部思维看不到的约束两者冲突TTL 会清掉需要持久化的数据最终裁决是混合缓存——会话级快速层 内存回退持久层。示例二架构决策Tactical target: Add webhook support to the Feed system Strategic context: Feed is one pipeline in Arbol, which processes content for Surface Pass 1 (Narrow): Standard webhook receiver, queue, retry logic Pass 2 (Wide): Webhooks must flow through Arbols action/function pattern, integrate with existing queue infrastructure Pass 3 (Synthesis): Tension — standalone webhook service vs. Arbol action. Resolution: implement as Arbol action, not standalone service, because the strategic context demands pipeline coherence over component independence.这个示例点出了振荡最有价值的一类结论该做成服务、库还是内联代码的答案完全取决于你是放大到组件还是缩小到系统SKILL.md 的 Use/Win 部分明确列出这一触发场景。最终裁决是作为 Arbol action 而非独立服务实现因为战略上下文要求管线一致性优先于组件独立性——这是纯组件视角给不出的答案。使用收益与触发场景使用时机任何时候你在一个更大的系统内构建某个具体事物需要确保局部设计服务全局愿景、同时又不丢失组件自身逻辑时。具体触发场景来自 SKILL.md 的 Use/Win架构决策——这应该做成服务、库还是内联代码完全取决于你的缩放级别功能设计——用户要的功能与产品需要的功能往往微妙不同振荡能浮现这个差距系统一致性检查——向现有基础设施新增部件时新部件必须同时服务于自身目的和系统目的单作用域框架会漏掉其中一个设计评审——在承诺方案之前振荡作用域检查战术计划与战略愿景是否一致作用域协商——当用户说构建 X而 X 的复杂度取决于上下文时振荡能揭示哪种作用域是合适的。收益在成为构建中途的意外之前浮现设计张力——最贵的返工来自自己运行得很好、但不服务系统的组件作用域清晰——在窄口径和宽口径下看同一个问题往往发现显而易见的那个作用域其实是错的一致性信心——战术与战略对齐时可以带着确信去构建分歧时你确切知道该在哪里做权衡。Gotchas 与运行记录三个关键注意点SKILL.md 的 Gotchas需要两个不同的输入——tactical 与 strategic 相同时改用 IterativeDepth3 次 pass 是正确的数量——结构在 3 轮时完备加 pass 属于 IterativeDepth 的职责综合 pass 才是价值所在——第 1、2 轮只是铺垫如果综合轮没有发现分叉那也是合法且有价值的发现说明战术与战略视图已经对齐。另外SKILL.md 自注这是一项BPE-fragile对更智能模型脆弱的技能——更聪明的模型可能无需提示就天然会振荡作用域因此建议按季度测试Quarterly test recommended。执行记录每次完成工作流后向执行日志追加一行 JSONL 记录这是技能可观测性的组成部分echo {ts:$(date -u %Y-%m-%dT%H:%M:%SZ),skill:ApertureOscillation,workflow:Oscillate,input:8_WORD_SUMMARY,status:ok|error,duration_s:SECONDS} ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl其中8_WORD_SUMMARY用一句话简述输入内容SECONDS填近似耗时工作流失败时记录status: error。自定义覆盖与仓库导航与 LifeOS 的其他技能一致ApertureOscillation 支持用户级自定义覆盖执行前先检查~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/ApertureOscillation/若该目录存在则加载其中的 PREFERENCES.md、配置或资源覆盖默认行为不存在则按技能默认执行。这是 LifeOS 面向不同用户个性化思考技能的标准机制。进一步阅读本主题在仓库中的完整材料工作流文档Oscillate.md本文主体技能定义与示例SKILL.md互补技能IterativeDepth/SKILL.md集成点与思考能力硬下限LIFEOS/ALGORITHM/v8.20.2.md、LIFEOS/ALGORITHM/changelog.md技能清单中的收录条目settings.enhancements.json【免费下载链接】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），仅供参考