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 轮结构化探索、每轮从不同透镜切入、逐轮累积并提炼 ISC（Ideal 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 工作流的三个入口：

1. 用户直接调用：例如说"use iterative depth on this problem"（对这个问题进行迭代深度分析）；
2. 算法在 OBSERVE 阶段调用：当能力审计（Capability Audit）判定该问题需要 IterativeDepth 时自动触发；
3. 其他技能调用：需要增强需求提取能力时，由其他技能代为发起。

从 v8.20.2.md 的算法文档可以看出，OBSERVE 阶段是 LifeOS 算法循环（current state → ideal state 的爬坡）中负责理解问题、撰写 ISA（Ideal State Artifact，理想状态工件）的阶段，IterativeDepth 作为能力菜单上的一员，正是在这一阶段被选入。

三、工作流输入（Inputs）

Explore 工作流接收三类输入：

第三项是关键：透镜不是随机挑选，而是由问题特征决定——安全类问题侧重失败与对手透镜，UX 类问题侧重体验透镜。文档明确强调："让问题来选择透镜"（Let the problem select the lenses）。

四、执行阶段：透镜目录与选用策略

执行的第一步是阅读 TheLenses.md 并选出契合问题的透镜，然后逐透镜探索，把先前透镜发现的准则带入下一轮，使后续轮次建立在前序成果之上。每一轮都必须浮现真正的新准则；一旦某轮只是复述了此前轮次已经发现的内容，就应停止增加透镜。透镜可以内联运行，也可以作为并行后台 Agent 运行。

8 个透镜全解析

TheLenses.md 按"从最具体到最抽象、从最常用到最专门"的顺序编排了 8 个透镜：

Lens 1：LITERAL（表层需求）

• 提问："他们明确说了什么？具体、成文的需求是什么？"
• 理论基础：需求获取基础（Requirements elicitation fundamentals）
• 聚焦：解析原话，识别每一条明示的需求、约束、偏好，不做任何解释——只提取说过的话。
• ISC 输出：为每一条明示需求生成标准。
• 提示词变体："列出这个请求中明确陈述的每一条具体、可测试的需求。不要推断——只提取。"

Lens 2：STAKEHOLDER（还有谁关心？）

• 提问："谁受到这个影响？所有人、系统与实体。每个都需要什么？"
• 理论基础：面向观点的需求工程（Finkelstein & Nuseibeh）、三角验证（Denzin）
• 聚焦：识别请求者之外的每一个干系人——最终用户、维护者、管理员、下游系统、未来的开发者。每个人有哪些未被说出的需求？
• ISC 输出：为原请求中不存在的干系人需求生成标准。
• 提示词变体："识别受此工作影响的每一个干系人。对每个干系人，他们会补充哪些请求者没有提到的需求？"

Lens 3：FAILURE（哪里会出错？）

• 提问："什么会失败？对手会利用什么？边界情况是什么？"
• 理论基础：滥用用例（Sindre & Opdahl）、事前验尸（Klein）、STRIDE 威胁建模
• 聚焦：假设解决方案已存在，然后打碎它。错误状态、竞态条件、安全漏洞、数据损坏、用户困惑、负载下的性能——每一种可能出错的方式。
• ISC 输出：反标准（Anti-criteria）——"绝不能发生"的失败模式，以及防御性标准。
• 提示词变体："这个解决方案明天上线。列出它第一周内所有可能的失败方式。要有对抗性。"

Lens 4：TEMPORAL（过去、现在、未来）

• 提问："这会如何随时间变化？历史是什么？6 个月后会发生什么？"
• 理论基础：因果分层分析（Inayatullah）、渐进细化（PMBOK）
• 聚焦：这个问题为什么现在存在？以前尝试过什么？未来什么变化会破坏当前方案？迁移路径、向后兼容、规模变化。
• ISC 输出：持久性、迁移与面向未来的标准。
• 提示词变体："什么背景催生了这个请求？未来 3-12 个月会发生什么变化，使这个方案失效？"

Lens 5：EXPERIENTIAL（应该是什么感受？）

• 提问："当它完美运行时，用户会有什么感受？体验是什么？"
• 理论基础：欣赏式探询（Cooperrider）、de Bono 红帽思维（情绪）
• 聚焦：功能正确性之外的主观体验——速度、优雅、惊喜、愉悦、信心、信任。"能用"与"好用得惊艳"的差别在哪里？
• ISC 输出：把体验从"可用"提升到"愉悦"的体验质量标准。
• 提示词变体："描述这个方案的完美用户体验。什么让人说'这正是我想要的'，而不是'这在技术上能用'？"

Lens 6：CONSTRAINT INVERSION（假如呢？）

• 提问："如果我们移除所有约束会怎样？如果我们加上极端约束呢？"
• 理论基础：TRIZ（Altshuller）、水平思考（de Bono）、重构（Dorst）
• 聚焦：移除假定的约束——拥有无限时间/资源时我们会构建什么？然后加上极端约束——如果它必须离线工作、必须在 100ms 内完成、必须零依赖？两个方向都会暴露隐藏假设。
• ISC 输出：挑战假设、揭示真正本质的标准。
• 提示词变体："我们假设了哪些没被说出的约束？移除它们——什么变了？现在加上极端约束——什么才是真正本质的？"

Lens 7：ANALOGICAL（什么模式适用？）

• 提问："以前解决过什么类似的问题？其他领域的哪些模式适用？"
• 理论基础：认知灵活性理论（Spiro）、跨领域迁移
• 聚焦：这个问题并不独特。其他代码库、其他行业、其他领域存在哪些类似问题？那里涌现了什么模式？犯了什么错？
• ISC 输出：源自经过验证的模式与类似方案教训的标准。
• 提示词变体："其他领域有哪 3-5 个类似问题？那里什么方案有效？那些方案会在这里暗示什么标准？"

Lens 8：META（这是正确的问题吗？）

• 提问："我们在解决正确的问题吗？框架本身正确吗？"
• 理论基础：诠释学循环（Gadamer）、双环学习（Argyris）、软系统方法论（Checkland）
• 聚焦：完全跳出问题。这个请求是不是更深层问题的症状？是否存在能"消解"问题而非"解决"问题的重构？换个问题是否会带来更好的结果？
• ISC 输出：重构或扩展问题定义本身的标准。
• 提示词变体："忘掉这个具体请求。底层的需要是什么？是否存在比所请求的更好的重构？"

选用纪律

TheLenses.md 在结尾给出了清晰的选用纪律：透镜按"具体→抽象、常用→专门"排序，因此较短的一次运行只需触及靠前的透镜，就能覆盖最普遍有用的地面——但具体选哪些、什么顺序，完全由问题决定。SKILL.md 进一步强调：

• 2~8 轮透镜探索，不是无限轮——大多数主题在第 5 轮左右开始收益递减；
• 每一轮都应产出真正的新需求，而不是复述之前的发现——一旦轮次开始重复，提前停止；
• 更多轮次本身不是目的，非冗余的角度才重要。

五、综合阶段（Synthesize）

所有透镜轮次完成后，进入综合阶段，共四步：

1. 去重（Deduplicate）：移除各透镜间语义相同的标准；
2. 合并细化（Merge refinements）：当多个透镜细化了同一标准时，保留最具体的版本；
3. 排序（Prioritize）：被多个透镜共同浮现的标准，排名更高；
4. 格式化（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 Format）

Explore 工作流定义了标准化的输出模板，一次完整运行结束后应输出如下结构：

🔍 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 的交付物定义看，一次成功的运行必须交付四样东西：

1. 一套去重后的 ISC 集合——每条都可二元测试、8-12 词、以状态而非动作表述，且任意两条不互相复述；
2. 对既有标准的细化——每条注明改了什么、为什么改；
3. 反标准——绝不能发生的失败模式；
4. 至少一个令人惊讶的跨角度发现——只因为两个透镜碰撞才浮现的需求。

七、与算法 OBSERVE 阶段的集成

原文档明确给出了 Explore 工作流在 LifeOS 算法中的时序位置：

当能力审计（Capability Audit）选择 IterativeDepth 时，它运行在Reverse Engineering（逆向工程）之后、ISC CREATION（ISC 创建）之前，从而使 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 次，能得到任何单次检查都无法获得的认知。

各领域代表技术包括：

该文档还特别澄清了与计算机科学中"迭代深化搜索"（CS Iterative Deepening / IDDFS）的本质区别：CS 方法每轮沿同一棵树搜索得更深（Korf, 1985），而本技能每轮从不同角度搜索同一个问题——精神上相关（都受益于重新检查），机制上根本不同。

三种生效机制

为什么这套方法有效？ScientificFoundation.md 给出三个机制：

1. 视角盲区补偿（Perspective Blindness Compensation）——任何单一视角都有盲点，通过视点结构化的轮换，覆盖单个轮次永远抓不到的空隙；
2. 建设性非确定性（Productive Non-Determinism）——即使在相同透镜下，AI 的非确定性也使每轮浮现略微不同的侧面，与结构化差异结合后，这从"缺陷"变成"特性"；
3. 渐进式前理解（Progressive Pre-Understanding）——每轮迭代更新分析者的"前理解"（Gadamer 术语），使后续轮次更具洞察力：第 5 轮能看到第 1 轮看不到的东西，因为第 2-4 轮改变了分析者"知道该去找什么"。

值得注意的细节是：ScientificFoundation.md 指出 DeFT 框架（Ainsworth, 2006）"直接验证了 2-8 轮范围校准得当，也验证了透镜必须结构上互不相同（而非简单重跑）"——这解释了为什么 SKILL.md 反复强调"非冗余角度"。

九、运行纪律与 Gotchas

SKILL.md 对运行过程有明确的纪律要求：

• 2~8 轮，不是无限轮：大多数主题 5 轮左右收益递减；
• 每轮必须有新产出：轮次开始重复就提前停止；
• 这是一个 BPE（Bitter 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 运行可以浓缩为以下检查单：

1. 触发：用户直接要求、算法 OBSERVE 的能力审计选中、或其他技能委托；
2. 输入：明确问题陈述、收集上下文、初步判断需要哪些透镜；
3. 选透镜：阅读 TheLenses.md，按问题特征挑选（安全→失败/对手透镜，UX→体验透镜），无需固定数量与顺序；
4. 逐轮执行：每轮从一个透镜出发，携带前轮发现进入下一轮；每轮必须浮现新准则，出现复述即停止；透镜可内联或作为并行后台 Agent；
5. 综合：去重 → 合并细化（保留最具体版本）→ 多透镜共识者优先 → 全部格式化为 8-12 词、状态式、可二元测试的 ISC；
6. 输出：按标准模板输出 Coverage 统计、三类产出（新 ISC / 细化 ISC / 反标准 ISC-A）与 Key Insight；
7. 回写：算法上下文下喂入 TaskCreate/TaskUpdate（落入 ISA 的## Claims/## Features区块），独立调用下呈现给用户；
8. 记录：追加 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