---
name: purpose-means-analysis
description: >-
  当用户希望实现一项尚未实现的正向功能或构造新系统，
  并想从该根本目的出发逐层分析可用手段时使用。
  也用于为替换已有系统而重新分析其原本功能，
  还原论文、算法和已有方案如何逐层实现预期功能；
  分析结果也可作为功能测试、设计评审或领域知识组织的基础。
  不用于追溯已有缺点的产生机制，或在原系统内降低延迟、
  减少损耗等局部改进任务。
  本 Skill 通过逐节点展开目的手段链，生成树形 Markdown 分析报告。
  用户只说“这个方法的各部分如何服务整体功能”
  “有哪些可行方案”“从头设计”“换一种系统实现这个功能”也可以考虑使用。
author: functoreality
version: 261105
---

# 目的手段链分析 Skill

## 概述

目的手段链分析从一个尚待实现的根本目的出发，逐层回答：

> 为实现这一目的，可以通过完成什么来直接达到？

右侧具体手段实现左侧目的；抽象方案大类则逐层限定
“可以用哪类方式实现”的搜索空间，直到得到更具体的手段。
分析结果通常写成一棵以根本目的为起点、向下展开手段的树形 Markdown 大纲。

它适合生成或理解系统设计方案，而不是追溯已发生缺点的客观原因。
若已有系统存在缺点，但用户希望用新系统替代它，
应把原系统本来要实现的目的作为本 Skill 的根，探索替换性方案。

根本目的应表达从设计视角待实现的正向功能、输出或对象。
还原已有方案时，该功能在现实中可能已经实现，
但仍应把它写成该方案原本要实现的正向功能。
“将设备 A 上的信息传输至 B”适合作为根；
“现有系统延迟过高”或“降低现有系统延迟”不适合。
局部子目的仍可表达为降低误差、提高稳定性等必要性质，
但不应因此把改进已有缺点误当成根本目的。

本 Skill 采用逐节点展开、优先队列、即时检查、独立子树和收尾复盘。
手段空间通常开放，
不要求穷尽所有可能手段，只在当前抽象层级尽力列出有价值的方案大类。

## 何时使用

典型用途包括：

- 从根本目的出发，设计全新系统或生成候选方案
- 为规避已有系统的缺点，重新分析该系统本来应实现的目的，以寻找可替代的系统
- 拆解论文、算法或已有方案，看清每一层手段如何服务预期功能
- 为后续功能测试或设计评审，先拆出系统预期功能所依赖的关键手段
- 为领域知识组织提供目的与手段的结构骨架

功能测试、设计评审和知识组织是分析结果的后续用途，
不改变主树中的实现关系或方案空间限定关系。
若用户还要求生成测试计划或整理知识框架，先完成目的手段链，
再把结果转换为相应产物，不把测试动作或笔记操作混入主树。

开始分析前阅读 `references/scenarios.md`，先确定本次是开放方案探索、
替换设计还是已知方案还原。该选择决定是否生成未采用的替代方案，
以及材料的使用边界；功能测试、设计评审和知识组织只属于分析完成后的转换。

## 核心输出

创建一个 Markdown 文件，以 Tab 缩进表示层级。
缩进下一层的节点是上一层节点的直接手段、直接子目的，
或对实现方式的直接限定。

```markdown
# 目的手段链分析：[根本目的概括]

* 获得可用于预报的准确模型
	* 构造能表示目标规律的映射
		* 采用神经网络表示映射：or
			* 采用卷积网络表示映射：方案大类
			* 采用注意力网络表示映射：方案大类
	* 使模型参数反映目标规律
		* 定义能评判模型输出的损失函数
		* 使用优化算法更新参数
```

当分析模式、展开边界、已知方案或材料范围会影响读者对树的理解时，
可在标题下补一段简短的“分析约定”，例如本次是开放探索还是既有方案还原、
准备交付方案地图还是完整候选链。不适用时无需添加。

若有多个彼此独立的根本目的，结果是由多棵树构成的森林。
每个根本目的另起一个二级标题，分别展开；只有多个要求共同构成不可分割的
单一功能时，才合并为一个根。

书写约定：

- 节点优先写成清晰的动宾短语，或“使对象达到某性质”的短语
- 同级节点默认是 And，表示这些要素需共同完成
- 多种可相互替代的方案在父节点后标记 `：or`
- 可表达为求和、乘积、并集、最大值或最小值等明确关系时，
  可标记 `：+`、`：×`、`：∪`、`：max`、`：min`；更多关系亦可自行补充
- 已达到本次目标粒度的节点标记 `：末端（理由）`
- 仍可展开但本次暂不继续的节点标记 `：暂缓（理由）`
- 只表示逐步限定方案空间、尚不是可执行方案的节点标记 `：方案大类`。
  若它作为叶节点交付，还应同时标明暂缓理由
- 当一组子节点是要素拆解、方案空间、已选方案细化或测量判别，
  而树的文字和关系标记不足以看出这一点时，可在父节点后简短标注展开轴，
  如 `：要素拆解`、`：方案空间，or`。能清楚读出的情形无需机械标注
- 共享手段和回路均用纯文字引用，见“重复、共享与环路”

若分析后期发现结果文档缩进层级过深，不便直接阅读，
且环境提供了 `outline-read` skill，可考虑启用。

## 分析流程

开始前，先阅读 `references/node-definition.md`。
其中规定目的手段节点的表述、原子化和术语区分要求。
后续“符合节点规范”均指满足该文件。

### 步骤 1：理解任务，确定分析范围与根本目的

1. 识别本次是开放方案探索、替换性设计，还是还原已知方案。
   按 `references/scenarios.md` 确定是否生成未采用的替代方案
2. 识别用户真正希望实现的正向功能、输出或对象，
   区分它与用户先提出的表层功能、具体方法或局部操作
3. 若表层需求可能只是候选手段或中间目的，按下方“推导根本目的”处理
4. 将根本目的改写为符合节点规范、清晰、具体、可继续展开的表述
5. 若用户给出的是已有系统或缺点，区分两种任务：
   - 若要解释或修补原系统内的缺点，本 Skill 不适用
   - 若要用新系统实现原本应有的功能，将该功能作为根本目的
6. 根本目的不必预先附带资源、成本或可行性限制。
   这些信息通常属于具体手段的实施条件，或用于调整展开优先级
7. 根据用户请求和上下文，暂定本次希望得到的宽度和深度。
   不必强求用户预先给出精确层数，分析中可随信息增多而调整
8. 若最终用途是测试、评审或知识组织，
   只用于决定交付后是否另行转换结果，不改变主树的目的手段关系
9. 若识别出多个彼此独立的根本目的，判断它们应构成多棵树，
   还是共同构成一个不可分割的功能；
   存在重大歧义，或有三个及以上目的时，先向用户确认
10. 后续若认为根本目的需要改写，先向用户说明并取得同意

#### 推导根本目的

用户最先提出的需求未必是本次分析的根。按以下过程逐层上溯：

1. 问“实现这个需求，直接服务什么正向功能、输出或目标状态？”
2. 将答案视为上一层目的，继续追问
3. 直到再上溯只能得到脱离当前项目的空泛价值判断，或不再改变方案空间时停止。
   不把“让用户更方便”“改善生活”这类抽象价值判断写成根本目的
4. 不确定当前层是否已足以作为根本目的时，先向用户确认

例如，外卖平台用户提出“按距离排序”时，可推得它服务于“使用户能预期或缩短送达时间”。
这有助于发现“设置 15 分钟配送专区”是“排序”之外的可行解决手段。
若再上溯到“满足日常饮食需要”已脱离当前外卖平台设计项目的方案空间，即可停止。

### 步骤 2：初始化分析文件与待展开队列

1. 立即创建分析 Markdown 文件，写入根本目的；若有多个根，按森林结构分别写入
2. 在记忆中维护待展开节点队列，初始包含每棵树的根节点
3. 若模式、展开边界或材料范围对读者理解有重要影响，可在标题后写入简短分析约定
4. 对开放的 Or 方案空间，先在当前抽象层级做一轮横向探索，
   列出有区分度的工作原理或方案大类
5. 形成这一层骨架后，再对节点给出相对优先级，
   优先深入最可能产生有价值方案的分支

优先级可参考：该节点离根本目的的关键程度、产出高价值方案的机会、
现有知识或资源是否支持进一步细化、该分支是否尚未充分理解、用户是否特别关注。
资源和约束只影响投入多少分析精力；现有条件不支持的手段分支仍保留，
仅需适时标记“暂缓”、不做深入展开，用户使用最终分析报告时会自行忽略。
“先横向、后深入”不要求穷尽所有可能方案，
只为避免最先想到的方案过早占据全部分析精力。

### 步骤 3：逐节点展开

队列非空时，取出优先级最高的节点。每次只展开当前节点的一层直接子节点，
再将新节点放回队列。发现上层表述或拆分有问题时，允许回退修改。
若当前节点要生成开放的 Or 方案，先完成本层必要的横向探索，
再把各方案按优先级放回队列。

#### 3.1 确认节点表述与角色

检查当前节点是否符合节点规范，并确认它：

- 清晰、具体、原子化，不把多层目的手段关系塞进同一节点
- 在当前上下文中表述“要实现什么”或“以什么实现”，而非只是分类标签
- 没有把时间顺序、纯因果关系或主观理由误写成目的手段关系

对每一条边都可问：

> 若右侧是具体手段，完成它是否直接为实现左侧节点提供手段？
> 若右侧是方案大类，它是否直接限定了用哪类方式实现左侧节点？

若中间仍有更贴近左侧目的的子目的，应补上该层，不直接跳到具体方案。

#### 3.2 检查重复、共享与环路

先搜索文字相同或高度相似的已有节点。
对象、条件、阶段不同的相似表述未必等价，应补充限定语后继续展开。

只有节点实际指向同一目的或同一手段，且预期下层展开也一致时，
才可停止重复展开。无法判断时，先继续展开，让后续节点自行暴露差异。

- 同一子问题在不同位置重复出现时，标注 `：上方已分析` 或 `：下方已分析`
- 同一手段服务多个目的，或其子树对多个位置都有价值时，建立独立子树
- 当前节点与祖先节点等价时，标注 `：祖先节点已分析`
  并简要说明反馈或抑制关系，不再递归展开

祖先回指只用于表达关系并阻止无限递归，
不表示本 Skill 已判断该反馈环路能否启动或实际实施。
这类判断留待使用分析结果选择和落实方案时进行。

共享手段的写法如下：

```markdown
* 实现目的 A
	* 手段 S：单独深入分析

* 实现目的 B
	* 手段 S：见“单独分析：手段 S”

# 单独分析：手段 S
* 手段 S
	* 子手段 1
	* 子手段 2
```

独立子树是原树的阅读重构，不表示手段只服务于标题上方的一个目的。

#### 3.3 选择展开模式并寻找直接手段

先找当前目的最直接的手段或子目的，而不是一步跳到过细的实现细节。
生成子节点前，先判断本轮要回答哪一种问题（仅列出常见形态，不是完备清单）：

1. **条件或要素拆解**：哪些条件、性质或组成部分需共同成立
2. **方案空间展开**：可以沿哪些相互有区分度的原理或方案方向实现
3. **已选方案细化**：这一方案还需什么结构、参数、资源或实施步骤
4. **测量或判别实现**：怎样获得某性质是否成立的判断或具体取值

这些不是节点的永久类型，而是当前这一次父子展开所采用的关系轴。
同一组兄弟节点只回答一种问题。若几个视角都重要，
用中间节点分层表达，或把次要视角放入独立子树。
若树的文字、And/Or 标记和 `：方案大类` 标记仍不足以表明本轮关系轴，
可在父节点后补 `：条件拆解`、`：方案空间`、`：已选方案细化` 或 `：测量判别` 等。
这是帮助读者理解的可选标记，不要求每次展开都写。

第一次遇到不熟悉的节点形态、需要展开方案大类，
或无法判断应选哪种关系轴时，阅读 `references/expansion-patterns.md`
中对应章节。然后优先使用下列思路：

1. 若目的可由定义、公式、必要条件或明确的组成关系刻画，先用它拆出条件
2. 若要改变属性状态，可列举能产生该状态的工作原理或方案大类
3. 若手段是构造某个对象、映射或系统，可拆其必要的结构、性质、
   参数选择或实现过程
4. 若手段是输入输出变换、测量或评判，可拆输入、输出、所用原理、
   评判准则或实现机制
5. 若以上均不合适，再按问题的逻辑构成直接拆分

对可量化目的或手段，优先尝试用严格定义、直接公式或可操作判据拆分；
若它们无助于当前拆分，再考虑直观关系或自由拆分。
检查公式中的每个量是否承担不同角色，
是否依赖未显式写出的条件、筛选规则或变换步骤。
这些隐藏条件若能被设计或改变，应写成相应的子目的或子手段。
公式仅是发现目标结构和必要条件的依据，
公式中的量不会自动变成可实施的手段。
写入前仍需解释该项如何直接服务父节点，
并根据实际目的手段关系重新判断组合关系类型。

这里的直接公式是最贴近当前父节点的定义或关系式，
不是消去中间量、合并多个阶段后得到的整合公式。
若公式中的量需要经过中间变换才能服务父节点，先补出该变换或中间子目的。
数学上等价不代表实施过程可以压平；可设计、可选择或需要实际执行的变换，
仍应按直接目的手段关系保留为独立层级。

不必把“所有手段都必须列全”当作硬性要求。
对开放方案空间，应先列出有区分度的方案大类，再在高价值分支继续细化。
“无法穷尽开放方案”不等于“不检查封闭拆分的局部完备性”。

#### 3.4 确定组合关系、验证拆分并检查跳步

在写入前判断同层手段的关系：

- And：各项共同构成当前目的的实现条件
- Or：同层分支表示互相替代的实现路径，或处于同一抽象层级的方案大类
- +、×：父节点本身确实由子节点的量直接求和或相乘时才使用
- ∪、max、min 等：父节点与子节点确实具有相应的直接关系时才使用，
  并在含义可能不清楚时简要注明关系式或拆分依据

若一个复杂结构同时包含 And 和 Or，不要把不同逻辑混写在同一组兄弟节点。
补出一个中间子目的或方案节点，使每个父节点的同级关系清楚。

然后做三项验证：

1. **直接性**：每个子节点都应直接服务父节点。
   And 子节点不必单独保证父目的实现，但应承担可解释的、非跳步的必要作用。
   具体 Or 方案应描述一条结构上独立的实现路径，
   而不是其中一个仍需与兄弟节点共同成立的组件。
   除非任务要求评估，不必在生成阶段证明该方案实际可行或有效。
   抽象方案大类可以尚未给出可执行方案，
   但必须直接限定“用哪类方式实现父目的”，并标记 `：方案大类`。
   若某节点只是在远处可能有帮助，先补出它直接服务的中间子目的。
2. **And 局部完备性**：在当前声明的范围和假设中，
   假设已列子节点全部完成，问父目的是否仍可能无法实现。
   如果可能，补出遗漏的必要条件或桥接子目的后重新验证。
3. **Or 层级一致性与封闭完备性**：不要把抽象方案大类、
   具体候选方案和可执行步骤混在同一组兄弟节点中。
   对具体方案，检查它是否表示结构上独立的实现方向，
   不把可行性与效果评估混入这一关系检查。
   对方案大类，检查各分支是否相关、有区分度，
   并能把后续搜索划分为更易继续展开的区域。
   按某种属性划分前，明确该属性约束的对象和环节，
   并在后续展开中保持含义一致。
   若不同环节可采用不同机制，应分别展开其实现手段，
   避免将局部机制的分类作为整个方案的排他限制。
   例如，液体接触工件以显现截面边界，相机以非接触方式读取边界，
   两者属于不同环节，可在同一方案中共同使用。
   若这是定义、有限分类或材料明确限定的封闭集合，检查是否有遗漏。
   若是开放方案空间，不声称已穷尽所有方案，
   只检查当前层是否已有有区分度的主要方向。
4. **其他关系的语义验证**：按关系自身的严格含义，
   检查各子节点的作用和局部完备性。若无法说清验证方式，
   不要用自定义关系掩盖不清楚的 And、Or 或中间层结构。

若一次拆分无法通过上述检查，先修正表述、补中间层或换一种拆分视角。
只有当前拆分通过验证、节点合理到达末端，或节点被明确暂缓时，才停止尝试。

#### 3.5 判断末端与暂缓节点

不再展开的叶节点分为两类，不要用同一标记混淆：

**末端节点**：当前分析已达到所需粒度，继续展开只会进入无关实现细节，
或已达到本次不再分解的自然原理、外部标准或边界。标记 `：末端（理由）`。
末端只表示本次分析在此完成，不表示已做实际可行性选择。
方案大类只是搜索方向，不能仅因本层足够抽象而标记为末端。
方案大类若本次不再展开，写成 `：方案大类，暂缓（理由）`，明确它仍是待探索前沿。

**暂缓节点**：该节点仍可继续展开，但因优先级低、缺少必要信息、需要用户决策，
或需转入另一项独立分析，本次暂不继续。标记 `：暂缓（理由）`。
暂缓节点是明示的未完成分支，不得当作已完成的末端。
已知当前不具备可行性的对应手段也不删除，可标为 `：暂缓（X 资源当前不可得）`，
不继续展开；是否采用留给分析结果的后续使用决定。

#### 3.6 写入子节点并更新队列

拆分清楚后：

新增节点必须能从当前父节点的直接分解中自然得到。
用户提供的候选方案、论文内容和外部资料可以提醒分析者检查遗漏，
但不能仅因材料提到它就强行挂到某个不相关的父节点下。
若一个重要候选无法自然安放，先检查根本目的、上层拆分或中间桥接层；
仍无法建立直接关系时，将它留作单独候选并说明原因。

1. 在父节点后写入组合关系标记
2. 写入一层直接子节点，不得顺手写更深层（子节点的展开必须等入队后专门取出）
3. 为每个子节点评估优先级，加入待展开队列
4. 及时落盘。通常每完成约 3 到 5 次展开；若在多个分支间交替推进，
   则在形成可恢复的局部骨架或切换重点前写入文件

### 步骤 4：中期结构扫描

通常在新增约 20 到 30 个节点或完成一个主要分支后，检查：

展开依据：
- 是否有优先级低但被过度细化，或优先级高却尚未展开的分支
- 是否缺少连接两层的公式、定义或中间子目的
- 是否存在跳步、角色混淆或不清楚的 And/Or
- 开放 Or 节点是否在一条方案过度深入前，已列出有区分度的本层方案大类
- 同一组 Or 兄弟节点是否处于接近的抽象层级，
  未展开且不在队列中的方案大类是否同时标明暂缓理由

文档结构：
- 同一手段是否被重复展开，是否应改为独立子树
- 是否有过深或过于复杂的子树，应单独分析，以提高结果文档可读性
- 独立子树的文字回指是否准确，是否遗漏它服务的其他目的
- 每个队列外叶节点是否已正确标记为末端、暂缓或已分析回指
- 缩进是否每层严格增加一个 Tab，是否存在孤儿节点

若分支交替推进已使关系难以追踪、刚建立独立子树，或准备收尾，
即使未达到上述规模也应提前扫描。

结构扫描后，重读本文件以及当前节点用到的本地参考文件，将其载入最新上下文。
分析历史变长后，早期规则容易被忽略。重读后若发现问题，立即返工修正。

### 步骤 5：收尾复盘

不要求在开始时锁定统一层数，也不要求穷尽开放方案空间。
当以下最低条件均满足，且继续展开的预期新增价值已明显低于
增加的篇幅与分析成本时，可以主动进入收尾：

- 根本目的和本次分析模式已经明确
- 每一层兄弟节点采用清楚且一致的展开关系轴
- 关键 And 拆分通过局部完备性检查
- 开放 Or 已形成有区分度的方案大类，高价值方向已深入到足以理解其实现思路的层级
- 所有叶节点均已标为末端、暂缓或已有分析回指
- 已知方案还原任务中，实际采用的主要路径已经闭合

“基本满意”只能作为经过这些条件后的边际收益判断，
不能替代直接性、局部完备性和叶节点状态检查。
边际收益指对当前问题可能新增的结构性认识，
不能仅以节省 token 或缩短篇幅为由提前停止。
满足条件后至少做两轮复盘。每轮逐项检查：

1. 节点表述是否符合规范，包括是否清晰、原子化，并在上下文中保持目的或手段角色
2. 每条边是否为直接目的手段关系，是否存在跳步
3. 节点展开是否完善
   - And 子节点是否局部完备
   - 具体 Or 分支是否为独立实现方向
   - 方案大类是否层级一致
   - 封闭 Or 是否有遗漏
   - 开放 Or 是否先建立了有区分度的方案大类，而不是被最先想到的单一方案锁定
   - And、Or 与其他组合关系是否准确、没有混写
4. 是否有值得继续展开的高价值节点，末端、暂缓与方案大类标记是否符合其实际状态
5. 通过已知方案验证检查分解完善度
   - 已知的重要方案、论文方法或用户提出的候选方案，
     能否通过有效的直接关系进入链中，而不是只在形式上找到安放位置
   - 若存在已知可行方案或材料实际采用的方法，选取一到两个做反向回放：
     从末端手段向上检查其关键操作、条件和中间变换能否逐层实现根本目的。
     若只能安放方案名称，却无法还原完整实现路径，说明仍有跳步或遗漏
6. 共享手段、独立子树、祖先回指和反馈标注是否前后一致
7. 是否有其他不合理、前后矛盾、或不利于理解目的手段结构的地方

某项发现问题后立即修正。一轮修正完成后，下一轮重新从检查 1 开始。
若某轮无修改，改变视角再做下一轮，
例如从末端向根反向检查、从已知方案回放实现路径，或交叉比较不同子树。
只有连续两轮均无修改，且其余未完成分支都已标记为理由充分的暂缓，
才确认收尾复盘通过。暂缓分支不能替代这两轮检查。

### 步骤 6：独立审查

若环境支持创建子 agent，且用户没有要求不要使用，应在步骤 5 通过后，
让一个未参与当前分析的审查者阅读本 Skill、全部本地参考文件和分析结果
（提供文件完整路径）。审查者应先执行步骤 5 的检查，再额外检查缩进、
孤儿节点、未标注叶节点、过早标记末端、未说明的暂缓、语义重复、
共享手段回指，以及缺失的桥接公式或子目的。

审查者不得直接修改结果文件，应列出问题、依据和建议的修正方向，
由主分析者判断并修正。审查者不得创建新的审查者。
若某轮报告指出超过 5 处实质问题，主分析者修正后继续进行下一轮独立审查，
直到某轮报告不超过 5 处实质问题，或独立审查累计达到 3 次。
该阈值只决定是否应在修正后重新审查，不表示不超过 5 处的问题可不修复。
最后由主分析者重新执行一轮步骤 5，直到收尾复盘再次通过。

分析结果最终交付后，可在回复中简要说明：

- 本次分析覆盖到的方案宽度和实现深度
- 为什么在当前位置停止
- 仍值得继续展开的方案大类、暂缓分支或关键未知点

同时明确用户可以指定任一节点继续深入。
用户要求继续时，从对应叶节点恢复队列即可，不必重新开始整棵分析。

## 输出格式规范

### Markdown 文件结构

```markdown
# 目的手段链分析：[目的概括]

* 根本目的
	* 直接子目的或直接手段
		* 下一层手段
	* 可替代方案：or
		* 方案大类 A：方案大类；暂缓（本次未继续细化）
		* 方案 B：暂缓（优先级较低）
	* 可执行的基础手段：末端（已达到本次目标粒度）

# 单独分析：共享手段
* 共享手段
	* 子手段
```

多根目的可改为以下森林结构：

```markdown
# 目的手段链分析：[项目概括]

## 根本目的 A
* 根本目的 A

## 根本目的 B
* 根本目的 B
```

### 缩进表示规则

- 所有节点以 `* ` 或 `- ` 开头
- 每一层增加一个 Tab（除非使用压平 `←` 简写）
- 不使用编号
- 子节点在当前上下文中实现父节点，
  或将父节点的实现方式直接限定到更具体的方案空间
- 连续唯一子手段可以（非必须）使用压平简写 `* ← X`，与上一行 Y 同级缩进。
  若 X 要作为 Y 的压平子节点，必须同时满足：
  X 是 Y 的唯一直接子节点；Y 是根节点，或 Y 也是其父节点的唯一直接子节点。
  若 Y 有兄弟节点，即使 X 是 Y 的唯一子节点，也不得压平。
  简写链可连续延伸，遇到多子节点处恢复正常 Tab 缩进。

## 与用户互动

- 根本目的理解不确定时先确认
- 分析可能分成多个独立根目的时先说明并确认
- 用户提出的是修补已有系统缺点时，不要强行改写成目的手段分析
- 对范围、资源、成本、风险等信息，默认不提前限制手段空间
- 用户要求只分析既有方法时，保持封闭，不擅自扩展成完整方案库
- 用户要求探索替代方案或从头设计时，主动展开有区分度的候选方案大类
- 用户要求继续深入时，从相应暂缓节点恢复分析，不重新起草已有部分

## 外部资料的使用

除非用户明确要求，先基于用户提供的信息完成相当一部分独立分析。
只有需要核实公式、工作原理、标准或具体方案，且无法从现有材料判断时，
才说明缺口并征求用户同意后查阅外部资料。
外部资料用于发现可能遗漏的思路或核对事实，不应替代对当前目的手段关系的判断。

## 写入时机与命名

在步骤 2 开始时立即创建结果文件。
分析过程中定期落盘，发现表述、关系或结构问题时即时修正。

文件名建议：

- `目的手段链分析-问题名称.md`
- `purpose_means_analysis-xxx.md`

## 开始分析

当用户请求目的手段链分析时：

1. 确认任务的出发点是正向功能的实现问题，或已有方案对该问题的实现结构，
   而不是修补已有系统的局部缺点
2. 确定一个或多个根本目的和当前分析模式，阅读场景参考
3. 展开模式不明确或需要生成方案大类时，阅读相应展开范式
4. 创建 Markdown 分析文件与待展开队列；必要时写入分析约定
5. 对开放方案先横向列出大类，再按优先级逐节点深入展开
6. 检查展开关系轴、直接性、局部完备性、抽象层级、重复、共享、末端和暂缓状态
7. 定期做结构扫描，必要时抽出独立子树
8. 完成两轮收尾复盘，环境允许时进行独立审查，再交付分析结果