LifeOS IterativeDepth 技能 Explore 工作流实战指南：多透镜迭代探索与 ISC 标准提取

LifeOS IterativeDepth 技能 Explore 工作流实战指南多透镜迭代探索与 ISC 标准提取【免费下载链接】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 仓库中 IterativeDepth 技能的 Explore 工作流 为骨架完整讲解这套对同一问题进行 N 轮结构化探索、每轮从不同透镜切入、逐轮累积并提炼 ISCIdeal State Criterion理想状态标准的方法论。读完本文你将掌握 Explore 工作流的完整执行流程、8 个科学透镜的选用策略、ISC 标准的格式化规范以及它与 LifeOS 算法 OBSERVE 阶段的集成方式并能在自己的需求分析、需求工程与 AI 提示工程实践中直接复用它。一、IterativeDepth 技能在 LifeOS 中的定位LifeOS 的核心主张是把从当前状态移动到理想状态这件事工程化把完成的样子写成可测试的声明claim再通过证据逐步逼近。而 IterativeDepth迭代深度正是支撑这一主张的多角度需求挖掘能力。根据 SKILL.md 中的技能元数据该技能的定义是Structured multi-angle exploration running 2-8 sequential passes over the same problem, each through a different scientific lens, to surface hidden requirements and edge cases invisible from one angle; each pass yields new ISC criteria.即对同一个问题执行 2~8 轮顺序探索每轮通过一个不同的科学透镜切入挖掘单角度无法发现的隐藏需求与边界情况每一轮都会产出新的 ISC 标准。它的 USE WHEN 触发语包括 iterative depth迭代深度、explore deeper深入探索、multi-angle analysis多角度分析、surface hidden requirements挖掘隐藏需求、blind spot check盲点检查、what am I missing我还遗漏了什么同时明确限定不做scope/zoom 类分析那是 ApertureOscillation 技能的职责。二、Explore 工作流的目的与调用时机Explore 工作流 是 IterativeDepth 技能唯一注册的工作流其**目的Purpose**一句话概括对同一问题运行 N 轮结构化探索每轮从不同透镜出发提取比单次分析更丰富的 ISC 标准。它之所以存在是因为任何单一视角都有盲区——需求方明确说出的话、被忽略的其他干系人、未来会发生的故障、时间推移带来的失效……只有让不同透镜的发现互相碰撞才能逼近完整。三种调用方式Invocation原文档明确了 Explore 工作流的三个入口用户直接调用例如说use iterative depth on this problem对这个问题进行迭代深度分析算法在 OBSERVE 阶段调用当能力审计Capability Audit判定该问题需要 IterativeDepth 时自动触发其他技能调用需要增强需求提取能力时由其他技能代为发起。从 v8.20.2.md 的算法文档可以看出OBSERVE 阶段是 LifeOS 算法循环current state → ideal state 的爬坡中负责理解问题、撰写 ISAIdeal State Artifact理想状态工件的阶段IterativeDepth 作为能力菜单上的一员正是在这一阶段被选入。三、工作流输入InputsExplore 工作流接收三类输入输入说明Problem/Request原始的用户请求或问题陈述Context任何可用的上下文对话历史、代码库状态、先前工作Lenses从 TheLenses.md 中选取问题所需的透镜第三项是关键透镜不是随机挑选而是由问题特征决定——安全类问题侧重失败与对手透镜UX 类问题侧重体验透镜。文档明确强调让问题来选择透镜Let the problem select the lenses。四、执行阶段透镜目录与选用策略执行的第一步是阅读 TheLenses.md 并选出契合问题的透镜然后逐透镜探索把先前透镜发现的准则带入下一轮使后续轮次建立在前序成果之上。每一轮都必须浮现真正的新准则一旦某轮只是复述了此前轮次已经发现的内容就应停止增加透镜。透镜可以内联运行也可以作为并行后台 Agent 运行。8 个透镜全解析TheLenses.md 按从最具体到最抽象、从最常用到最专门的顺序编排了 8 个透镜Lens 1LITERAL表层需求提问他们明确说了什么具体、成文的需求是什么理论基础需求获取基础Requirements elicitation fundamentals聚焦解析原话识别每一条明示的需求、约束、偏好不做任何解释——只提取说过的话。ISC 输出为每一条明示需求生成标准。提示词变体列出这个请求中明确陈述的每一条具体、可测试的需求。不要推断——只提取。Lens 2STAKEHOLDER还有谁关心提问谁受到这个影响所有人、系统与实体。每个都需要什么理论基础面向观点的需求工程Finkelstein Nuseibeh、三角验证Denzin聚焦识别请求者之外的每一个干系人——最终用户、维护者、管理员、下游系统、未来的开发者。每个人有哪些未被说出的需求ISC 输出为原请求中不存在的干系人需求生成标准。提示词变体识别受此工作影响的每一个干系人。对每个干系人他们会补充哪些请求者没有提到的需求Lens 3FAILURE哪里会出错提问什么会失败对手会利用什么边界情况是什么理论基础滥用用例Sindre Opdahl、事前验尸Klein、STRIDE 威胁建模聚焦假设解决方案已存在然后打碎它。错误状态、竞态条件、安全漏洞、数据损坏、用户困惑、负载下的性能——每一种可能出错的方式。ISC 输出反标准Anti-criteria——绝不能发生的失败模式以及防御性标准。提示词变体这个解决方案明天上线。列出它第一周内所有可能的失败方式。要有对抗性。Lens 4TEMPORAL过去、现在、未来提问这会如何随时间变化历史是什么6 个月后会发生什么理论基础因果分层分析Inayatullah、渐进细化PMBOK聚焦这个问题为什么现在存在以前尝试过什么未来什么变化会破坏当前方案迁移路径、向后兼容、规模变化。ISC 输出持久性、迁移与面向未来的标准。提示词变体什么背景催生了这个请求未来 3-12 个月会发生什么变化使这个方案失效Lens 5EXPERIENTIAL应该是什么感受提问当它完美运行时用户会有什么感受体验是什么理论基础欣赏式探询Cooperrider、de Bono 红帽思维情绪聚焦功能正确性之外的主观体验——速度、优雅、惊喜、愉悦、信心、信任。能用与好用得惊艳的差别在哪里ISC 输出把体验从可用提升到愉悦的体验质量标准。提示词变体描述这个方案的完美用户体验。什么让人说这正是我想要的而不是这在技术上能用Lens 6CONSTRAINT INVERSION假如呢提问如果我们移除所有约束会怎样如果我们加上极端约束呢理论基础TRIZAltshuller、水平思考de Bono、重构Dorst聚焦移除假定的约束——拥有无限时间/资源时我们会构建什么然后加上极端约束——如果它必须离线工作、必须在 100ms 内完成、必须零依赖两个方向都会暴露隐藏假设。ISC 输出挑战假设、揭示真正本质的标准。提示词变体我们假设了哪些没被说出的约束移除它们——什么变了现在加上极端约束——什么才是真正本质的Lens 7ANALOGICAL什么模式适用提问以前解决过什么类似的问题其他领域的哪些模式适用理论基础认知灵活性理论Spiro、跨领域迁移聚焦这个问题并不独特。其他代码库、其他行业、其他领域存在哪些类似问题那里涌现了什么模式犯了什么错ISC 输出源自经过验证的模式与类似方案教训的标准。提示词变体其他领域有哪 3-5 个类似问题那里什么方案有效那些方案会在这里暗示什么标准Lens 8META这是正确的问题吗提问我们在解决正确的问题吗框架本身正确吗理论基础诠释学循环Gadamer、双环学习Argyris、软系统方法论Checkland聚焦完全跳出问题。这个请求是不是更深层问题的症状是否存在能消解问题而非解决问题的重构换个问题是否会带来更好的结果ISC 输出重构或扩展问题定义本身的标准。提示词变体忘掉这个具体请求。底层的需要是什么是否存在比所请求的更好的重构选用纪律TheLenses.md 在结尾给出了清晰的选用纪律透镜按具体→抽象、常用→专门排序因此较短的一次运行只需触及靠前的透镜就能覆盖最普遍有用的地面——但具体选哪些、什么顺序完全由问题决定。SKILL.md 进一步强调2~8 轮透镜探索不是无限轮——大多数主题在第 5 轮左右开始收益递减每一轮都应产出真正的新需求而不是复述之前的发现——一旦轮次开始重复提前停止更多轮次本身不是目的非冗余的角度才重要。五、综合阶段Synthesize所有透镜轮次完成后进入综合阶段共四步去重Deduplicate移除各透镜间语义相同的标准合并细化Merge refinements当多个透镜细化了同一标准时保留最具体的版本排序Prioritize被多个透镜共同浮现的标准排名更高格式化Format每一条标准都写成 ISC 形式——8~12 个词、状态而非动作、可二元测试。综合完成后将增强后的标准返回给调用上下文当由算法 OBSERVE 调用时直接喂入 TaskCreate 调用当独立调用时将集合呈现给用户。ISC 标准在仓库中的权威定义ISC 即Ideal State Criterion理想状态标准。ISAFormat.md 将其定义为 ISA 中可测试的声明——理想状态工件ISA以 ISC 为可测试声明进行分解每条 ISC 都是可以对照现实尝试、要么通过要么失败的声明。该文档给出了硬到难以变化hard-to-vary与可测试性的等价判据一条 ISC 是 hard-to-vary当且仅当你能说出一个能证伪它的测试。如果你说不出失败长什么样这条 ISC 就不是 hard-to-vary——它可以用任何东西来满足。它还给出了一组经典示例对比Fluff空泛: - [ ] ISC-N: Email is delivered to the user. Load-bearing承重: - [ ] ISC-N: Email arrives in primary inbox (not Promotions/Spam) within 60s.空泛版本可以用任何东西满足因为没有测试能抓住它的变化承重版本命名了一个可证伪的声明。这与 Explore 工作流要求的二元可测试binary testable标准完全一致——Explore 产出的每一条 ISC 都应当能落到这样一条可证伪的声明上。Explore.md 中8-12 词、状态而非动作、二元可测试的格式化规则正是从这条权威定义派生的操作性表述。六、输出格式Output FormatExplore 工作流定义了标准化的输出模板一次完整运行结束后应输出如下结构 ITERATIVE DEPTH COMPLETE ({N} lenses applied) Coverage: - Lenses used: {list of lens names} - New criteria discovered: {count} - Existing criteria refined: {count} - Anti-criteria discovered: {count} NEW ISC CRITERIA: [Use TaskCreate for each, prefixed ISC-] REFINED ISC CRITERIA: [Use TaskUpdate for each, with evidence of what changed] NEW ANTI-CRITERIA: [Use TaskCreate for each, prefixed ISC-A] Key Insight: [The most surprising finding across all lenses — the thing single-pass analysis would have missed]这个模板的要点值得逐一拆解Coverage 区块量化本次运行的覆盖面——用了几个透镜、发现多少新标准、细化多少既有标准、发现多少反标准三类产出分区新 ISC 标准ISC-前缀、细化的既有标准ISC-前缀 变更证据、新反标准ISC-A前缀即绝不能发生的失败模式Key Insight全透镜中最令人意外的发现——单次分析会错过的东西。SKILL.md 对此有一条硬性要求一次没有浮现任何单次分析会发现不了的跨角度发现的运行是没有价值的A run that surfaces nothing a single pass would have missed added no value。从 SKILL.md 的交付物定义看一次成功的运行必须交付四样东西一套去重后的 ISC 集合——每条都可二元测试、8-12 词、以状态而非动作表述且任意两条不互相复述对既有标准的细化——每条注明改了什么、为什么改反标准——绝不能发生的失败模式至少一个令人惊讶的跨角度发现——只因为两个透镜碰撞才浮现的需求。七、与算法 OBSERVE 阶段的集成原文档明确给出了 Explore 工作流在 LifeOS 算法中的时序位置当能力审计Capability Audit选择 IterativeDepth 时它运行在Reverse Engineering逆向工程之后、ISC CREATIONISC 创建之前从而使 ISC 标准在落笔前就经过多角度探索的充分滋养而不是事后修正。这个排序是经过设计的先在多角度探索中充分理解问题再写入 ISC 标准——先探索后写作优于先写作后修补。在 v8.20.2.md 的算法框架中这对应 OBSERVE 阶段把用户意图转化为 ISA理想状态工件的过程——ISA 是山丘也是测量仪器其声明claims各自命名了能证伪它的探测probe而 IterativeDepth 的价值正是让这些声明在诞生之前就足够丰满、足够多维。从仓库的 ISAFormat.md 可见现代的 ISA 把 ISC 组织在## Claims或## Features区块中每条 ISC 对应## Test Strategy中一行带探测列isc | type | check | threshold | tool | anchors_to | severity的记录。Explore 工作流产出的新标准、细化标准与反标准正是通过 TaskCreate / TaskUpdate 落入这些区块进而被 CheckpointPerISC、ISASync 等钩子与 Bunker 测试执行器消费——这就是把增强后的标准返回给调用上下文的具体落点。八、科学基础为什么多透镜探索有效ScientificFoundation.md 用 20 种经独立验证的技术论证了这套方法的正当性——IterativeDepth 不是某一个人的发明而是一个跨学科反复独立涌现的元模式meta-pattern认知科学家、AI 研究者、需求工程师、设计师、哲学家分别独立收敛到同一模式这一事实本身就是其有效性的强证据。该模式可概括为对同一现象从系统化不同的角度检查 N 次能得到任何单次检查都无法获得的认知。各领域代表技术包括领域代表技术与本技能的映射认知科学与认识论诠释学循环Gadamer、三角验证Denzin、认知灵活性理论Spiro、反思平衡Rawls、同化顺应Piaget、溯因推理Peirce、视角主义Nietzsche每轮迭代都在修正对用户需求的前理解每个透镜都是对同一问题的一次不同方法AI/ML 与提示工程Self-ConsistencyWang et al., 2022、多智能体辩论Du et al., 2023、集成方法Breiman 等、DiVeRSeLi et al., 2023多条推理路径 对同一次 ISC 提取的多个透镜需求工程面向观点的需求工程Finkelstein Nuseibeh、滥用用例Sindre Opdahl、渐进细化PMBOK每轮迭代采用一个不同的干系人视角设计思维与问题解决六顶思考帽de Bono、因果分层分析Inayatullah、软系统方法论Checkland本技能 8 个透镜的直接灵感来源该文档还特别澄清了与计算机科学中迭代深化搜索CS Iterative Deepening / IDDFS的本质区别CS 方法每轮沿同一棵树搜索得更深Korf, 1985而本技能每轮从不同角度搜索同一个问题——精神上相关都受益于重新检查机制上根本不同。三种生效机制为什么这套方法有效ScientificFoundation.md 给出三个机制视角盲区补偿Perspective Blindness Compensation——任何单一视角都有盲点通过视点结构化的轮换覆盖单个轮次永远抓不到的空隙建设性非确定性Productive Non-Determinism——即使在相同透镜下AI 的非确定性也使每轮浮现略微不同的侧面与结构化差异结合后这从缺陷变成特性渐进式前理解Progressive Pre-Understanding——每轮迭代更新分析者的前理解Gadamer 术语使后续轮次更具洞察力第 5 轮能看到第 1 轮看不到的东西因为第 2-4 轮改变了分析者知道该去找什么。值得注意的细节是ScientificFoundation.md 指出 DeFT 框架Ainsworth, 2006直接验证了 2-8 轮范围校准得当也验证了透镜必须结构上互不相同而非简单重跑——这解释了为什么 SKILL.md 反复强调非冗余角度。九、运行纪律与 GotchasSKILL.md 对运行过程有明确的纪律要求2~8 轮不是无限轮大多数主题 5 轮左右收益递减每轮必须有新产出轮次开始重复就提前停止这是一个 BPEBitter Pill Engineering苦药工程敏感的技能需要监控更强的模型是否会让它变得多余建议每季度测试一次。此外SKILL.md 要求每次运行后追加一条 JSONL 执行日志到~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl命令模板为echo {ts:$(date -u %Y-%m-%dT%H:%M:%SZ),skill:IterativeDepth,workflow:WORKFLOW_USED,input:8_WORD_SUMMARY,status:ok|error,duration_s:SECONDS} ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl其中WORKFLOW_USED替换为实际执行的工作流、8_WORD_SUMMARY替换为简短的输入描述、SECONDS替换为大致耗时工作流失败时记录status: error。同时SKILL.md 规定执行前应检查用户自定义目录~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/IterativeDepth/对应仓库中的 CUSTOMIZATIONS 模板 结构若存在PREFERENCES.md等配置则加载覆盖默认行为否则按技能默认执行。十、实战速查一次完整的 Explore 运行综合全部文档一次完整的 Explore 运行可以浓缩为以下检查单触发用户直接要求、算法 OBSERVE 的能力审计选中、或其他技能委托输入明确问题陈述、收集上下文、初步判断需要哪些透镜选透镜阅读 TheLenses.md按问题特征挑选安全→失败/对手透镜UX→体验透镜无需固定数量与顺序逐轮执行每轮从一个透镜出发携带前轮发现进入下一轮每轮必须浮现新准则出现复述即停止透镜可内联或作为并行后台 Agent综合去重 → 合并细化保留最具体版本→ 多透镜共识者优先 → 全部格式化为 8-12 词、状态式、可二元测试的 ISC输出按标准模板输出 Coverage 统计、三类产出新 ISC / 细化 ISC / 反标准 ISC-A与 Key Insight回写算法上下文下喂入 TaskCreate/TaskUpdate落入 ISA 的## Claims/## Features区块独立调用下呈现给用户记录追加 JSONL 执行日志。这套流程把凭感觉想需求替换为结构化、可审计、可复现的多视角挖掘——这正是 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），仅供参考