企业官网建设流程全解析

Brainstorming - 框架建立机制分析

核心问题：为什么一段话能"建立框架"？

这是关于大语言模型如何处理指令的根本问题。

问题1：加载skill后，这段话怎么就建立起框架了？

需要理解的底层机制

1. 大语言模型的指令遵循（Instruction Following）机制

基本原理：
当你向模型发送"使用brainstorming技能"这个指令时，模型内部发生了什么？

[输入到模型] 使用superpowers:brainstorming技能 ↓ [模型的指令处理系统] 识别：这是一个技能调用指令 ↓ [模型内部操作] 加载指定的技能文件（SKILL.md） ↓ [模型理解过程] 将技能内容纳入当前的"上下文窗口" ↓ [模型行为调整] 基于技能内容，调整后续输出的行为模式

关键概念：上下文窗口（Context Window）

大语言模型不是"记住"了技能，而是：

1. 将技能内容放入当前上下文窗口
2. 在生成回答时，考虑上下文窗口中的所有内容
3. 技能内容成为生成回答时的"约束"和"指南"

2. 技能内容在上下文中的作用

当SKILL.md的内容被加载到上下文窗口后：

# 模型的内部表示（简化）context={"user_input":"我需要一个待办应用","skill_content":""" # Brainstorming Ideas Into Designs Help turn ideas into fully formed designs and specs... Start by understanding the current project context... ""","previous_conversation":[...]}# 模型生成回答时response=model.generate(context)

模型生成回答时：

• 考虑user_input
• 遵循skill_content中的指导
• 一致于previous_conversation
• 输出符合所有约束的回答

关键是：模型不是"决定"遵循技能，而是通过训练学会的：

• 模型的训练数据包含大量"遵循指令"的例子
• 模型学会：当有指令时，要调整输出行为
• 模型学会：指令的内容决定了如何调整

3. 为什么"概述部分"特别重要？

这涉及到模型的"注意力机制"（Attention Mechanism）

当模型生成回答时：

# 模型内部的注意力权重（简化）attention_weights={"user_input":0.3,# 用户意图很重要"skill_header":0.15,# 技能标题"skill_overview":0.25,# 技能概述 ← 重点"skill_details":0.2,# 详细指令"conversation_history":0.1# 对话历史}

"概述部分"的特殊作用：

1. 位置权重：概述通常在技能的较早部分

   • 模型给予较早内容更高的权重
   • 概述成为"首要考虑"的约束

2. 概括性：概述是高层次的、概括性的内容

   • 模型学会：概括性内容 = 高级指导原则
   • 详细内容 = 具体实现细节
   • 概述优先于细节

3. 建立基线：概述建立了行为的基线模式

   • 后续详细内容都是这个基线的具体化
   • 如果详细内容与概述矛盾，模型倾向于遵循概述

4. 具体例子：框架建立的过程

场景：你说"我需要一个待办应用"

没有brainstorming技能时：

# 模型的上下文context={"user_input":"我需要一个待办应用","system_prompt":"你是一个有用的AI助手"}# 模型生成（基于训练数据中的"常见模式"）response=""" 好的，我帮你构建一个待办应用。 我将使用： - 前端：React（现代化、生态成熟） - 后端：Node.js + Express（轻量级） - 数据库：MongoDB（灵活、适合待办数据） - 状态管理：Redux（复杂应用的标准选择） 架构设计： - MVC模式 - RESTful API - 响应式设计 让我开始编写代码... """

模型为什么这样输出？

• 基于训练数据中"待办应用"的"标准答案"
• 没有明确约束，所以使用"最佳实践"假设
• 倾向于直接提供解决方案

有brainstorming技能时：

# 模型的上下文context={"user_input":"我需要一个待办应用","system_prompt":"你是一个有用的AI助手","skill_content":""" # Brainstorming Ideas Into Designs Help turn ideas into fully formed designs and specs through natural collaborative dialogue. Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval. """}# 模型生成（受技能内容约束）response=""" 让我先理解一下项目的当前情况。 请告诉我： 1. 你希望用这个应用做什么？ - 日常任务管理？ - 工作项目跟踪？ - 学习计划？ - 其他用途？ 2. 你计划在哪里使用这个应用？ - 主要是手机上？ - 电脑上？ - 两者都要支持？ """

模型为什么这样输出？

1. 概述第一句：“Help turn ideas into fully formed designs and specs”

   • 模型理解：这是关于"想法→设计"的转换
   • 模型行为调整：不要直接提供解决方案

2. 概述第二句：“Start by understanding the current project context”

   • 模型理解：第一步是理解上下文
   • 模型行为调整：从询问项目背景开始

3. 概述第三句：“then ask questions one at a time”

   • 模型理解：一次一个问题，不能多个
   • 模型行为调整：只问一个主要问题

4. 概述第四句：“present the design and get user approval”

   • 模型理解：先展示设计，获得批准
   • 模型行为调整：不直接进入实现

5. 这是"编程"吗？

这不是传统的编程，这是提示工程（Prompt Engineering）：

传统编程：

defprocess_request(user_input):if"待办应用"inuser_input:returnbrainstorming_workflow(user_input)

提示工程：

Help turn ideas into fully formed designs and specs Start by understanding the current project context

区别：

• 传统编程：明确的规则和条件
• 提示工程：自然语言的指导和原则
• 传统编程：机器严格执行，无例外
• 提示工程：模型基于训练理解和应用

但为什么提示工程如此有效？

1. 模型的大规模训练：模型见过数十亿"遵循指令"的例子
2. 指令识别能力：模型学会识别"这是指令，不是内容"
3. 行为调整能力：模型学会根据指令调整输出模式
4. 上下文整合能力：模型学会将新指令与现有知识整合

所以概述部分之所以能"建立框架"：

• 它利用了模型的指令遵循能力
• 它设定了高层次的行为指导原则
• 它通过在上下文中的位置和概括性获得高权重
• 它为后续详细内容建立了基线

问题2：HARD-GATE标签是所有模型都有的么？

需要理解的自定义语法机制

1. HARD-GATE不是所有模型的内置功能

HARD-GATE不是模型内置的语法，而是Superpowers团队创造的自定义语法。

<HARD-GATE> Do NOT invoke any implementation skill... </HARD-GATE>

这本质上只是特殊的HTML/XML标签：

• <HARD-GATE>和</HARD-GATE>是一对标签
• 标签之间的内容是约束文本
• 这不是模型理解的特殊语法

2. 模型如何理解这个自定义语法？

关键：模型见过大量HTML/XML标签

模型的训练数据包含：

• HTML文档中的标签：<div>,<h1>,<p>,<script>等
• XML文档中的标签：<config>,<setting>,<value>等
• Markdown文档中的代码块

模型学到的模式：

• 标签内的内容通常是"特殊内容"或"元内容"
• 标签提供了内容的结构化
• 标签有时表示"指令"或"注释"

当模型看到<HARD-GATE>时：

# 模型的理解过程（简化）understanding={"recognized_pattern":"这是HTML/XML标签","similar_to":"<code>","<note>","<warning>","<script>","interpretation":{"tag_name":"HARD-GATE","tag_name_meaning":"HARD"+"GATE"=硬性门控,"tag_content":"约束文本","function":"强调或特殊标记的内容"}}

模型的理解：

1. HARD-GATE看起来像标签名
2. GATE有"门控"的含义
3. HARD-GATE组合意为"硬性门控"
4. 标签内的内容是"硬性门控"的规则

3. 为什么要使用这种自定义语法？

这利用了模型的几个特性：

1. 视觉强调（Visual Emphasis）

在文本中，特殊标签会"跳出"：

普通文本 <HARD-GATE> 特殊强调的文本 </HARD-GATE> 普通文本

模型注意力机制：

• 特殊标记获得更高的注意力权重
• 模型给予标记内内容"特殊关注"
• 模型学过：标记内容 = 重要约束

2. 语义强化（Semantic Reinforcement）

标签名本身传递了语义信息：

• <HARD-GATE>：HARD + GATE = 硬性边界，不可绕过
• 如果只是普通文本：“Do NOT invoke…”（可能被忽略）
• 有标签：HARD-GATE（强调硬性）

3. 结构化信息（Structured Information）

标签提供了内容的结构：

<HARD-GATE> 约束内容 </HARD-GATE> <ANOTHER-TAG> 其他内容 </ANOTHER-TAG>

模型可以：

• 区分不同类型的约束
• 为不同标签应用不同的处理方式
• 理解内容的层次关系

4. 这是通用的"提示工程"技巧

不是Superpowers独有的，这种技巧在提示工程中很常见：

示例1：特殊的注释标记

<!-- CRITICAL --> 重要内容 <!-- END CRITICAL -->

示例2：代码块中的强调

# !!! IMPORTANT !!!重要代码

示例3：自定义XML标签

<instruction>这里是指令</instruction><output>这里是期望输出</output>

这些技巧都利用相同的原理：

• 特殊标记吸引模型注意力
• 标记名称传递语义信息
• 标记提供结构化信息

5. 模型真的"理解"这个标签吗？

这里的"理解"不是人类意义的理解：

模型的"理解"是：

1. 模式识别：识别出这是一个标签结构
2. 语义推断：从标签名推断出可能的含义
3. 权重调整：给标记内内容更高的权重
4. 行为调整：根据权重和含义调整输出

不是人类的"理解"：

• 模型不知道"HARD-GATE"是Superpowers的定义
• 模型不知道这个标签的"官方"含义
• 模型只是根据训练数据中类似模式的用法来推断

6. 为什么这种自定义语法有效？

根本原因：模型的训练数据包含大量类似模式

模型见过的模式：

1. HTML文档中的特殊标签

   • <noscript>：不执行脚本
   • <code>：代码内容
   • <samp>：示例输出
   • 这些标签标记了"特殊处理"的内容

2. Markdown中的代码块

   • ```python：Python代码
   • ```javascript：JavaScript代码
   • 这些标记告诉模型"如何处理"内容

3. 技术文档中的警告

   • WARNING:、CRITICAL:、IMPORTANT:
   • 这些标记强调了重要内容

当模型看到<HARD-GATE>时：

模型从训练中泛化：

1. “这是一个特殊标记，像<code>或<warning>”
2. “标记名是HARD-GATE，可能意味着硬性约束”
3. “标记内内容应该被特别重视”
4. “行为应该被调整以符合这个约束”

这是泛化，不是明确理解：

• 模型没有HARD-GATE的"定义"
• 模型从大量类似模式中推断出如何处理
• 模型学过：“特殊标记 = 重视这个内容”

7. 具体例子：HARD-GATE如何影响模型行为

场景：智能体正在思考是否跳过brainstorming

没有HARD-GATE标记：

# 上下文context={"skill_content":""" Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. ""","user_input":"我需要一个简单的待办列表","internal_reasoning":"这个看起来很简单，也许不需要完整的设计..."}# 模型的决策过程（简化）decision_weights={"skill_constraint":0.4,# 技能约束"simplicity_assumption":0.6# "简单性"假设}# 决策：跳过设计，直接开始（因为"看起来简单"）

有HARD-GATE标记：

# 上下文context={"skill_content":""" <HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE> ""","user_input":"我需要一个简单的待办列表","internal_reasoning":"这个看起来很简单，但..."}# 模型的决策过程（简化）decision_weights={"hard_gate_constraint":0.8,# 硬性门控（被强调）"simplicity_assumption":0.2# "简单性"假设}# 决策：遵循HARD-GATE约束，不跳过设计

HARD-GATE的强调效果：

1. 注意力提升：标记内内容获得更高权重
2. 语义强化："HARD"传达硬性、不可协商
3. 视觉突出：在文本中显眼，不会被忽略
4. 心理影响：影响模型的"内部推理"权重

两个问题的综合理解

系统观：这是"提示工程黑客"（Prompt Engineering Hacking）

Superpowers做的事情：

1. 利用模型的指令遵循能力

   • 模型被训练为遵循指令
   • 概述部分是高层指令
   • 模型学会根据这些指令调整行为

2. 利用模型的注意力机制

   • 模型给予某些内容更高权重
   • 概述部分（早期、概括性）获得高权重
   • 特殊标记（HARD-GATE）获得高权重

3. 利用模型的模式识别

   • 模型见过大量HTML/XML标签
   • 自定义标签被识别为"特殊标记"
   • 模型学会"特殊标记 = 重视内容"

4. 利用模型的语义推断

   • 模型从"HARD-GATE"推断出"硬性门控"
   • 模型从"Start by understanding"推断出"从理解开始"
   • 模型学会从文本中推断出行为指导

不是"魔法"，而是"科学"

这不是神奇的思维控制，而是基于：

1. 大规模训练：模型见过数十亿遵循指令的例子
2. 能力泛化：模型可以将训练中学到的应用到新情况
3. 模式匹配：模型识别出提示中的模式
4. 权重调整：模型根据识别出的模式调整内部权重

这就是"提示工程"的本质

提示工程 = 对模型训练特性的系统性利用

Superpowers不是在"创造新功能"，而是在：

1. 理解模型的训练特性
2. 设计符合这些特性的提示结构
3. 利用模型的注意力机制
4. 利用模型的语义推断能力
5. 系统性地"编程"模型的行为

实用洞察

为什么其他技能开发者不这样做？

大多数提示工程很粗糙：

"帮我设计一个待办应用" "不要直接写代码，先讨论一下" "问问题，不要猜测"

Superpowers的系统化方法：

<概念框架> Help turn ideas into fully formed designs... <硬性约束> <HARD-GATE> Do NOT invoke any implementation skill... <行为算法> Start by understanding... then ask questions... <语言模式> Use descriptive, collaborative language...

这是"高级提示工程"的教科书级示例

技术层面：

1. 多层次约束：概念 + 硬性 + 行为 + 语言
2. 注意力管理：通过位置、概括性、特殊标记
3. 语义工程：每个标签名和短语都有精心设计
4. 系统性整合：所有部分相互强化

效果层面：

1. 一致的行为：模型不会"创造性"地偏离
2. 高可靠度：约束被稳定地遵循
3. 可预测性：智能体的行为是可预测的
4. 可维护性：技能可以持续改进

Anti-Pattern: “This Is Too Simple To Need A Design” 章节分析

章节的核心作用

这个章节看似"奇怪"，但实际上是Superpowers设计哲学的精妙体现，具有以下关键作用：

1.预防性设计保护机制

核心作用：防止"偷懒"行为和认知偏差

当用户说"这太简单了，不需要设计"时，智能体会被这个章节明确提醒：

“每个项目都会经历这个过程。待办列表、单功能工具、配置更改——所有这些。'简单’项目是未经审视的假设导致最多浪费工作的地方。”

2.对抗经典认知偏差

这是一个精心设计的对抗机制：

3.智能行为对比

有该章节时：

用户: "我只需要一个简单的按钮，有什么好设计的？" 智能体: • 匹配到Anti-Pattern • 引用章节内容 • 坚持设计流程 • 提供具体指导

无该章节时：

用户: "我只需要一个简单的按钮，有什么好设计的？" 智能体: • 可能被"简单性"说服 • 直接跳到实现 • 缺乏明确警告机制

如何判断"简单"？Superpowers的智慧

1.判断标准：不是表面复杂度，而是潜在风险

Superpowers使用"未经思考可能造成的损失"作为标准：

# 表面简单 vs 潜在复杂性对比 | 表面简单 | 潜在复杂性 | 风险等级 | |---------|-----------|---------| | "改个按钮颜色" | • 在10个页面使用<br>• 需要符合品牌规范<br>• 考虑可访问性 | 高 | | "加个字段" | • 数据库变更<br>• API更新<br>• 数据迁移 | 高 | | "改个配置" | • 环境变量影响<br>• 向后兼容<br>• 文档更新 | 中 |

2.真正的"简单"标准

根据章节内容定义：

“The design can be short (a few sentences for truly simple projects)”

真正简单项目的特征：

• ✓单一目的：只做一件事
• ✓无副作用：不影响现有功能
• ✓无依赖：不依赖其他组件
• ✓低风险：出错成本低
• ✓无规范约束：不涉及品牌、可访问性等

3.智能判断流程

# 智能体的内部决策is_truly_simple=True# 1. 快速项目上下文检查project_complexity=explore_project_context()ifproject_complexity>basic_project_threshold:is_truly_simple=False# 2. 依赖关系分析dependencies=find_related_components()iflen(dependencies)>3:is_truly_simple=False# 3. 变更影响范围affected_areas=analyze_impact()iflen(affected_areas)>2:is_truly_simple=False

4."简单设计"的实现

对于被判断为真正简单的项目：

## 设计简述（几句话即可） **变更**：将按钮颜色从蓝色改为绿色 **理由**：符合成功状态的颜色约定 **影响**：仅修改按钮组件的bg-blue-500为bg-green-500 请确认这个设计是否正确？

效果对比

为什么使用"Anti-Pattern"标题？

1. 术语选择：

   • "Anti-Pattern"表示这是正式的不良模式
   • 给予问题明确的命名，便于识别
   • 体现软件工程领域的专业术语

2. 引用用户话语：

   • 直接引用用户的典型借口：“This Is Too Simple To Need A Design”
   • 当用户说类似话时，智能体能立即匹配
   • 增强情境匹配的精确度

3. 哲学坚持：

   • 体现Superpowers的核心原则：所有项目都需要设计
   • 这不是技术限制，而是质量保证
   • 防止因"看起来简单"而牺牲必要思考

总结

"Anti-Pattern"章节是提示工程的精妙设计：

1. 不是限制，而是保护：防止开发者因过度自信而造成返工
2. 一致性强制：无论项目大小，都遵循相同的质量标准
3. 智慧判断：提供清晰标准区分"真正简单"和"看似简单"
4. 价值体现：虽然开始稍慢，但长期来看节省更多时间和精力

这正是Superpowers区别于普通提示工程的关键——不仅关注技术实现，更关注通过结构化思考保证质量的完整流程。

流程控制章节组分析：Checklist、Process Flow与The Process

三章节的内在关联

这三个章节构成了brainstorming技能的核心执行架构：

1. Checklist：提供9个必须完成的步骤清单
2. Process Flow：用流程图可视化步骤间的逻辑关系和分支
3. The Process：详细说明每个步骤的具体执行方法

1. Checklist：强制性的9步流程

核心特点

• “MUST create a task for each”：每个步骤都必须创建任务
• “complete them in order”：必须按顺序完成
• 强制性的质量检查点：9个步骤包含3个关键审查点

9步流程的深度分析

# 流程的演进逻辑 阶段1：探索与理解 (步骤1-3) 1. **Explore project context** - 查看项目现状 2. **Offer visual companion** - 准备视觉工具（可选） 3. **Ask clarifying questions** - 一问一式理解需求 阶段2：设计与验证 (步骤4-5) 4. **Propose 2-3 approaches** - 提出多种方案 5. **Present design** - 分块呈现设计，获得批准 阶段3：文档化与审查 (步骤6-8) 6. **Write design doc** - 写入设计文档并提交 7. **Spec self-review** - 自动自我审查 8. **User reviews written spec** - 用户审查 阶段4：过渡实现 (步骤9) 9. **Transition to implementation** - 调用writing-plans技能

关键设计原则

渐进式细化：

• 从宏观（项目上下文）到微观（具体设计）
• 从发散（多种方案）到收敛（最终设计）
• 从思考到文档化

强制性质量门控：

• 每个主要阶段结束都有审查点
• 3个关键批准点：设计批准、文档完成、用户确认
• 任何一步不通过都可以回到前一阶段

2. Process Flow：可视化的决策逻辑

流程图的精妙设计

digraph brainstorming { # 关键节点分析 "Explore project context" [shape=box]; # 起点：项目探索 "Visual questions ahead?" [shape=diamond]; # 条件判断：是否需要视觉 "Ask clarifying questions" [shape=box]; # 核心：需求澄清 "Propose 2-3 approaches" [shape=box]; # 方案设计 "Present design sections" [shape=box]; # 设计呈现 "User approves design?" [shape=diamond]; # 质量门控1 "Write design doc" [shape=box]; # 文档化 "Spec self-review" [shape=box]; # 自动审查 "User reviews spec?" [shape=diamond]; # 质量门控2 "Invoke writing-plans skill" [shape=doublecircle]; # 终点 # 关键分支逻辑 "User approves design?" -> "Present design sections" [label="no, revise"]; # 迭代循环 "User reviews spec?" -> "Write design doc" [label="changes requested"]; # 文档迭代 # 终点强制 "The terminal state is invoking writing-plans"; # 明确终点 }

流程图的关键特性

1. 条件分支的精确控制：

• “Visual questions ahead?” - 可选的视觉伴侣路径
• 两个关键的质量判断节点

2. 迭代循环的设计：

• 设计阶段可以返回修改（no, revise）
• 文档阶段可以再次修改（changes requested）
• 允许必要的返工，但控制在合理范围内

3. 终点状态的强制：

• 明确说明终点必须是invoking writing-plans
• 禁止调用其他实现技能
• 确保流程的一致性

3. The Process：细节执行的完整指南

四大核心阶段详解

阶段1：Understanding the idea（理解阶段）

# 超越简单的需求收集 - 先检查项目状态（files, docs, recent commits） - 评估scope：识别大型子系统的需求 - 项目分解能力：将大项目分解为独立的子项目 - 一问一式：每次只问一个问题 - 多选题优先：降低用户认知负担

关键洞察：

“Before asking detailed questions, assess scope”
— 这体现了"预防胜于治疗"的设计哲学

阶段2：Exploring approaches（方案探索）

# 结构化的方案对比 - 提出2-3个不同方案 - 明确对比trade-offs（权衡） - 推荐首选方案并解释理由 - 对话式呈现，不生硬

关键设计：

“Lead with your recommended option and explain why”
— 先推荐再解释，提高效率同时保持透明

阶段3：Presenting the design（设计呈现）

# 分块渐进式呈现 - 按复杂性分块：简单几句话，复杂200-300词 - 每块后获得批准：增量式验证 - 覆盖核心要素：架构、组件、数据流、错误处理、测试 - 保持灵活性：可以返回澄清

阶段4：Design for isolation and clarity（设计原则）

# 高内聚低耦合的设计哲学 - 小单元，单一目的 - 明确定义的接口 - 独立可理解 - 独立可测试 - "文件过大=职责过多"的信号

三章节的协同效应

1.Checklist提供骨架

• 9个强制步骤确保不遗漏关键环节
• 任务创建机制确保进度追踪

2.Process Flow提供脉络

• 流程图可视化逻辑关系
• 明确分支和循环条件
• 强制终点状态

3.The Process提供血肉

• 每个步骤的详细执行指南
• 具体的最佳实践和技巧
• 深度的设计原则

三层架构的优势

Superpowers的流程设计智慧

1.渐进式复杂度控制

• 从简单到复杂
• 从发散到收敛
• 从模糊到明确

2.质量内嵌而非事后检查

• 每个主要阶段都有质量检查
• 设计过程中就获得用户反馈
• 文档化前已经过多轮验证

3.强制性与灵活性的平衡

• 步骤顺序是强制的
• 每步的内容是灵活的
• 迭代循环允许必要的修改

4.认知负荷优化

• 一问一式降低认知负担
• 分块呈现避免信息过载
• 多选题优先提高回答效率

实际执行效果对比

无此结构化流程时：

用户：我需要个登录功能 智能体：好的，我马上给你写代码... # 结果：可能遗漏关键需求，设计不完整

有此结构化流程时：

智能体：我需要先了解项目情况... 1. 探索项目上下文 2. 确认是否需要视觉化 3. 逐步澄清需求（你期望用什么认证方式？） 4. 提出2-3种方案对比 5. 分块呈现设计并获批准 6. 写入设计文档 7. 自查和用户审查 8. 调用writing-plans # 结果：完整的设计，明确的需求，经过验证

总结：流程即质量

这三个章节的完美配合体现了Superpowers的核心设计哲学：

“好的流程产生好的结果”：

1. 完整性：9个步骤覆盖了从需求到设计的全过程
2. 质量性：多个检查点确保设计质量
3. 可控性：清晰的流程图让执行路径一目了然
4. 灵活性：允许必要的迭代，不僵化

这不是简单的步骤列表，而是一个经过深思熟虑的质量保证体系。每个设计都经过层层验证，每份文档都确保完整准确，每个项目都遵循相同的高标准。

关联分析文档

流程控制架构分析

brainstorming技能的流程控制机制是其质量保证的核心。详细分析请参考：

• 02-流程控制架构分析.md

该文档深入分析了三个相互关联的核心章节：

• Checklist：9步强制流程的骨架
• Process Flow：可视化决策逻辑的脉络
• The Process：详细执行指南的血肉

文档版本: 1.3
最后更新: 2026-04-14
分析层次: 技术实现原理 + 设计哲学深度分析