# Purpose Means Analysis

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

- Skill: `functoreality/purpose-means-analysis` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add functoreality/purpose-means-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/functoreality/purpose-means-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: functoreality (https://skillmd.com/u/functoreality)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/functoreality/purpose-means-analysis

---


# 目的手段链分析 Skill

## 概述

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

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

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

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

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

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

## 何时使用

典型用途包括：

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

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

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

## 核心输出

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

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

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

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

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

书写约定：

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

## 分析流程

开始前，先阅读 `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 是否有遗漏
4. 开放 Or 是否先建立了有区分度的方案大类，
   而不是被最先想到的单一方案锁定
5. And、Or 与其他组合关系是否准确、没有混写
6. 是否有值得继续展开的高价值节点，末端、暂缓与方案大类标记是否符合其实际状态
7. 已知的重要方案、论文方法或用户提出的候选方案，
   能否通过有效的直接关系进入链中，而不是只在形式上找到安放位置
8. 若存在已知可行方案或材料实际采用的方法，选取一到两个做反向回放：
   从末端手段向上检查其关键操作、条件和中间变换能否逐层实现根本目的。
   若只能安放方案名称，却无法还原完整实现路径，说明仍有跳步或遗漏
9. 共享手段、独立子树、祖先回指和反馈标注是否前后一致
10. 是否有其他不合理、前后矛盾或不利于理解目的手段结构的地方

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

### 步骤 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. 完成两轮收尾复盘，环境允许时进行独立审查，再交付分析结果