协同文件分析工作流Skill analyze-with-file

---

name: analyze-with-file description: 交互式协作分析工作流，带有文档化讨论过程。记录理解演变，促进多轮问答，并使用内联搜索工具进行深度探索。串行执行，无代理委托。 argument-hint: “TOPIC="<问题或主题>" [–depth=quick|standard|deep] [–continue]”

Codex Analyze-With-File 提示

概述

交互式协作分析工作流，具有文档化讨论过程。记录理解演变，促进多轮问答，并使用内联搜索工具进行深度探索。

核心工作流：主题 → 探索 → 讨论 → 文档化 → 精炼 → 结论 →（可选）快速执行

关键特性：

• 文档化讨论时间线：捕获所有阶段的理解演变
• 每个关键点的决策记录：强制记录关键发现、方向更改和权衡
• 多视角分析：支持最多4个分析视角（串行、内联）
• 交互式讨论：多轮问答，带有用户反馈和方向调整
• 快速执行：将结论直接转换为可执行任务

决策记录协议

关键：在分析过程中，以下情况必须立即记录到 discussion.md：

触发条件	记录内容	目标部分
方向选择	选择的内容、原因、丢弃的替代方案	#### 决策日志
关键发现	发现内容、影响范围、置信水平	#### 关键发现
假设更改	旧假设 → 新理解、原因、影响	#### 修正的假设
用户反馈	用户的原始输入、采纳/调整的理由	#### 用户输入
分歧与权衡	冲突观点、权衡基础、最终选择	#### 决策日志
范围调整	调整前后的范围、触发原因	#### 决策日志

决策记录格式：

> **决策**：[决策描述]
> - **上下文**：[触发此决策的原因]
> - **考虑的选项**：[评估的替代方案]
> - **选择**：[选定的方法] — **原因**：[理由]
> - **影响**：[对分析方向/结论的影响]

记录原则：

• 即时性：决策发生时立即记录，而非阶段结束时
• 完整性：捕获上下文、选项、选定方法和原因
• 可追溯性：后续阶段必须能追溯决策原因

自动模式

当 --yes 或 -y：自动确认探索决策，使用推荐的分析角度，跳过交互式范围界定。

快速开始

# 基本用法
/codex:analyze-with-file TOPIC="如何优化此项目的认证架构"

# 带有深度选择
/codex:analyze-with-file TOPIC="性能瓶颈分析" --depth=deep

# 继续现有会话
/codex:analyze-with-file TOPIC="认证架构" --continue

# 自动模式（跳过确认）
/codex:analyze-with-file -y TOPIC="缓存策略分析"

目标主题

$TOPIC

分析流程

步骤0：会话设置
   ├─ 解析主题、标志（--depth、--continue、-y）
   ├─ 生成会话ID：ANL-{slug}-{date}
   └─ 创建会话文件夹（或检测现有 → 继续模式）

步骤1：主题理解
   ├─ 解析主题，识别分析维度
   ├─ 与用户进行初始范围界定（重点领域、视角、深度）
   └─ 初始化 discussion.md

步骤2：探索（内联，无代理）
   ├─ 检测代码库 → 搜索相关模块、模式
   │   ├─ 读取 project-tech.json / project-guidelines.json（如果存在）
   │   └─ 使用 Grep、Glob、Read、mcp__ace-tool__search_context
   ├─ 多视角分析（如果选择，串行）
   │   ├─ 单视角：全面分析
   │   └─ 多视角（≤4）：串行每视角分析并合成
   ├─ 聚合发现 → explorations.json / perspectives.json
   └─ 用第1轮更新 discussion.md

步骤3：交互式讨论（多轮，最多5轮）
   ├─ 呈现探索发现
   ├─ 收集用户反馈
   ├─ 处理响应：
   │   ├─ 深化 → 在当前方向进行更深内联分析
   │   ├─ 调整方向 → 新内联分析，调整重点
   │   ├─ 问题 → 直接回答并附证据
   │   └─ 完成 → 退出循环进行合成
   ├─ 用每轮更新 discussion.md
   └─ 重复直到用户选择完成或达到最大轮次

步骤4：合成与结论
   ├─ 整合所有洞察 → conclusions.json
   ├─ 用最终合成更新 discussion.md
   └─ 提供选项：快速执行 / 创建问题 / 生成任务 / 导出 / 完成

步骤5：快速执行（可选 - 用户选择）
   ├─ 转换 conclusions.recommendations → .task/TASK-*.json（带有收敛的独立任务文件）
   ├─ 预执行分析（依赖关系、文件冲突、执行顺序）
   ├─ 用户确认
   ├─ 直接内联执行（Read/Edit/Write/Grep/Glob/Bash）
   ├─ 记录事件 → execution-events.md，更新 execution.md
   └─ 报告完成摘要

配置

标志	默认值	描述
-y, --yes	false	自动确认所有决策
--continue	false	继续现有会话
--depth	standard	分析深度：quick / standard / deep

会话ID格式：ANL-{slug}-{YYYY-MM-DD}

• slug：小写，字母数字 + CJK 字符，最多40个字符
• date：YYYY-MM-DD（UTC+8）
• 自动检测继续：会话文件夹 + discussion.md 存在 → 继续模式

实现细节

会话初始化

步骤0：初始化会话

const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()

// 解析标志
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
const continueMode = $ARGUMENTS.includes('--continue')
const depthMatch = $ARGUMENTS.match(/--depth[=\s](quick|standard|deep)/)
const analysisDepth = depthMatch ? depthMatch[1] : 'standard'

// 提取主题
const topic = $ARGUMENTS.replace(/--yes|-y|--continue|--depth[=\s]\w+|TOPIC=/g, '').replace(/^["']|["']$/g, '').trim()

// 确定项目根目录
const projectRoot = Bash('git rev-parse --show-toplevel 2>/dev/null || pwd').trim()

const slug = topic.toLowerCase().replace(/[^a-z0-9\u4e00-\u9fa5]+/g, '-').substring(0, 40)
const dateStr = getUtc8ISOString().substring(0, 10)
const sessionId = `ANL-${slug}-${dateStr}`
const sessionFolder = `${projectRoot}/.workflow/.analysis/${sessionId}`

// 自动检测继续：会话文件夹 + discussion.md 存在 → 继续模式
// 如果继续 → 加载 discussion.md + explorations，从最后一轮恢复
Bash(`mkdir -p ${sessionFolder}`)

阶段1：主题理解

目标：解析主题，识别相关分析维度，与用户输入界定分析范围，并初始化讨论文档。

步骤1.1：解析主题和识别维度

匹配主题关键词与分析维度：

const ANALYSIS_DIMENSIONS = {
  architecture:    ['架构', 'architecture', 'design', 'structure', '设计', 'pattern'],
  implementation:  ['实现', 'implement', 'code', 'coding', '代码', 'logic'],
  performance:     ['性能', 'performance', 'optimize', 'bottleneck', '优化', 'speed'],
  security:        ['安全', 'security', 'auth', 'permission', '权限', 'vulnerability'],
  concept:         ['概念', 'concept', 'theory', 'principle', '原理', 'understand'],
  comparison:      ['比较', 'compare', 'vs', 'difference', '区别', 'versus'],
  decision:        ['决策', 'decision', 'choice', 'tradeoff', '选择', 'trade-off']
}

// 匹配主题文本与关键词列表
// 如果匹配多个维度，包含所有
// 如果无匹配，默认为 "architecture" 和 "implementation"
const dimensions = identifyDimensions(topic, ANALYSIS_DIMENSIONS)

步骤1.2：初始范围界定（仅新会话）

对于新会话，收集用户偏好（自动模式或继续模式跳过）：

if (!autoYes && !continueMode) {
  // 1. 重点领域（多选）
  // 从检测到的维度动态生成方向（见维度-方向映射）
  const focusAreas = AskUserQuestion({
    questions: [{
      question: "选择分析重点领域：",
      header: "重点",
      multiSelect: true,
      options: generateFocusOptions(dimensions) // 基于维度动态生成
    }]
  })

  // 2. 分析视角（多选，最多4个）
  const perspectives = AskUserQuestion({
    questions: [{
      question: "选择分析视角（单视角=集中，多视角=更广覆盖）：",
      header: "视角",
      multiSelect: true,
      options: [
        { label: "技术", description: "实现模式、代码结构、技术可行性" },
        { label: "架构", description: "系统设计、可扩展性、组件交互" },
        { label: "安全", description: "漏洞、认证、访问控制" },
        { label: "性能", description: "瓶颈、优化、资源利用" }
      ]
    }]
  })

  // 3. 分析深度（单选，除非 --depth 已设置）
  // Quick：表面级别 | Standard：中等深度 | Deep：全面
}

步骤1.3：初始化 discussion.md

const discussionMd = `# 分析讨论

**会话ID**：${sessionId}
**主题**：${topic}
**开始时间**：${getUtc8ISOString()}
**维度**：${dimensions.join(', ')}
**深度**：${analysisDepth}

## 分析上下文
- 重点领域：${focusAreas.join(', ')}
- 视角：${selectedPerspectives.map(p => p.name).join(', ')}
- 深度：${analysisDepth}

## 初始问题
${generateInitialQuestions(topic, dimensions).map(q => `- ${q}`).join('
')}

## 初始决策
> 记录为何选择这些维度和重点领域。

---

## 讨论时间线

> 随着分析进展，将在此下方追加轮次。
> 每轮必须包含一个决策日志部分，用于记录任何决策。

---

## 决策轨迹

> 整合所有轮次的关键决策（在阶段4中填充）。

---

## 当前理解

> 探索后填充。
`
Write(`${sessionFolder}/discussion.md`, discussionMd)

成功标准：

• 创建会话文件夹并初始化 discussion.md
• 识别分析维度
• 捕获用户偏好（重点、视角、深度）
• 记录初始决策：维度选择理由、排除的维度及原因、用户偏好意图

阶段2：探索

目标：收集代码库上下文并执行分析以构建理解。所有探索内联完成 — 无代理委托。

步骤2.1：检测代码库和探索

直接使用可用工具搜索代码库：

const hasCodebase = Bash(`
  test -f package.json && echo "nodejs" ||
  test -f go.mod && echo "golang" ||
  test -f Cargo.toml && echo "rust" ||
  test -f pyproject.toml && echo "python" ||
  test -f pom.xml && echo "java" ||
  test -d src && echo "generic" ||
  echo "none"
`).trim()

if (hasCodebase !== 'none') {
  // 1. 读取项目元数据（如果存在）
  //    - .workflow/project-tech.json（技术栈信息）
  //    - .workflow/project-guidelines.json（项目约定）

  // 2. 搜索代码库中的相关内容
  //    使用：Grep、Glob、Read 或 mcp__ace-tool__search_context
  //    基于主题关键词和识别维度搜索
  //    重点关注：
  //      - 与主题相关的模块/组件
  //      - 现有模式和代码结构
  //      - 集成点和约束
  //      - 相关配置和依赖

  // 3. 写入发现
  Write(`${sessionFolder}/exploration-codebase.json`, JSON.stringify({
    project_type: hasCodebase,
    relevant_files: [...],    // [{path, relevance, summary}]
    patterns: [...],          // [{pattern, files, description}]
    constraints: [...],       // 发现的架构约束
    integration_points: [...], // [{location, description}]
    key_findings: [...],      // 代码搜索的主要洞察
    _metadata: { timestamp: getUtc8ISOString(), exploration_scope: '...' }
  }, null, 2))
}

步骤2.2：多视角分析（如果选择）

从每个选定视角分析主题。所有分析由AI内联完成。

单视角（默认）：

// 全面分析所有识别维度
// 使用 exploration-codebase.json 作为上下文
// 重点关注：模式、反模式、潜在问题、机会

const findings = {
  session_id: sessionId,
  timestamp: getUtc8ISOString(),
  topic: topic,
  dimensions: dimensions,
  sources: [...],            // [{type, file, summary}]
  key_findings: [...],       // 主要洞察
  discussion_points: [...],  // 用于用户参与的问题
  open_questions: [...]      // 未解决的问题
}
Write(`${sessionFolder}/explorations.json`, JSON.stringify(findings, null, 2))

多视角（2-4个视角，串行）：

// 顺序分析每个视角
// 对于每个视角：
//   1. 专注于该视角的关注领域进行搜索/分析
//   2. 生成视角特定洞察
//   3. 写入独立发现

selectedPerspectives.forEach(perspective => {
  // 从该视角的角度分析
  // 使用 exploration-codebase.json + 维度重点
  // 写入到 explorations/{perspective.name}.json
  Write(`${sessionFolder}/explorations/${perspective.name}.json`, JSON.stringify({
    perspective: perspective.name,
    relevant_files: [...],
    patterns: [...],
    key_findings: [...],
    perspective_insights: [...],
    open_questions: [...],
    _metadata: { timestamp: getUtc8ISOString() }
  }, null, 2))
})

步骤2.3：聚合发现

// 单视角 → explorations.json 已写入
// 多视角 → 合成为 perspectives.json

if (selectedPerspectives.length > 1) {
  const synthesis = {
    session_id: sessionId,
    timestamp: getUtc8ISOString(),
    topic: topic,
    dimensions: dimensions,

    // 独立视角发现
    perspectives: selectedPerspectives.map(p => ({
      name: p.name,
      findings: readJson(`${sessionFolder}/explorations/${p.name}.json`).key_findings,
      insights: readJson(`${sessionFolder}/explorations/${p.name}.json`).perspective_insights,
      questions: readJson(`${sessionFolder}/explorations/${p.name}.json`).open_questions
    })),

    // 跨视角合成
    synthesis: {
      convergent_themes: [...],   // 所有视角一致的观点
      conflicting_views: [...],   // 视角不同的地方
      unique_contributions: [...]  // 特定视角的独特洞察
    },

    aggregated_findings: [...],   // 所有视角的主要洞察
    discussion_points: [...],     // 用于用户参与的问题
    open_questions: [...]         // 未解决的问题
  }
  Write(`${sessionFolder}/perspectives.json`, JSON.stringify(synthesis, null, 2))
}

步骤2.4：更新 discussion.md

用探索结果追加第1轮：

单视角第1轮：

• 分析的来源（文件、模式）
• 关键发现并附证据
• 用户讨论点
• 开放问题

多视角第1轮：

• 每视角摘要（简短）
• 合成部分：
  • 收敛主题（所有视角一致的内容）
  • 冲突观点（视角不同的地方）
  • 独特贡献（特定视角的洞察）
• 讨论点
• 开放问题

成功标准：

• 创建 exploration-codebase.json 包含代码库上下文（如果代码库存在）
• 创建 explorations.json（单视角）或 perspectives.json（多视角）包含发现
• 用第1轮结果更新 discussion.md
• 准备交互式讨论
• 记录关键发现并附证据引用和置信水平
• 记录探索决策（为何选择特定视角/搜索策略）

阶段3：交互式讨论

目标：通过多轮用户引导的讨论周期迭代精炼理解。

最大轮次：5轮讨论（如果用户表示分析完成，可以提前退出）

步骤3.1：呈现发现和收集反馈

显示当前理解并收集用户方向：

// 显示来自 explorations.json 或 perspectives.json 的当前发现摘要
// 显示关键点、讨论点、开放问题

if (!autoYes) {
  const feedback = AskUserQuestion({
    questions: [{
      question: `分析第 ${round} 轮：对当前发现的反馈？`,
      header: "方向",
      multiSelect: false,
      options: [
        { label: "深化", description: "分析方向正确，进行更深调查" },
        { label: "调整方向", description: "需要不同理解或重点" },
        { label: "具体问题", description: "有具体问题要问" },
        { label: "分析完成", description: "获得足够信息，进行合成" }
      ]
    }]
  })
}

步骤3.2：处理用户响应

记录检查点：无论用户选择哪个选项，必须记录到 discussion.md：

• 用户的原始选择和表达
• 此选择对分析方向的影响
• 如果方向更改，使用决策记录格式记录完整决策

深化 — 在当前方向继续分析：

// 使用搜索工具进行更深内联分析
// 调查边缘情况、特殊场景
// 识别尚未讨论的模式
// 建议改进方法
// 提供风险/影响评估
// 用深化发现更新 explorations.json
// 记录：确认的假设、更深探索的具体角度

调整方向 — 新重点领域：

// 询问用户调整后的重点
const adjustedFocus = AskUserQuestion({
  questions: [{
    question: "新分析重点应该是什么？",
    header: "新重点",
    multiSelect: false,
    options: [
      { label: "代码细节", description: "更深入实现具体细节" },
      { label: "架构", description: "更广泛的结构分析" },
      { label: "最佳实践", description: "行业标准和推荐" }
    ]
  }]
})

// 从调整视角使用内联搜索分析
// 比较新洞察与先前分析
// 识别遗漏内容及原因
// 用调整发现更新 explorations.json
// 记录决策：方向调整的触发原因、旧vs新方向、预期影响

具体问题 — 直接回答：

// 通过 AskUserQuestion 捕获用户问题（文本输入）
// 基于代码库搜索和分析回答每个问题
// 提供证据和文件引用
// 为每个答案评分置信度（高/中/低）
// 在 discussion.md 中记录问答
// 记录：问题揭示的知识差距、答案带来的新理解

分析完成 — 退出循环，进入阶段4。

// 记录：为何在此轮结束（足够信息 / 范围完全集中 / 用户满意）

步骤3.3：记录每轮

用每轮讨论结果更新 discussion.md：

部分	内容
用户方向	采取的行动（深化/调整/问题）和重点领域
决策日志	使用决策记录格式记录的本轮决策
分析结果	关键发现、洞察、证据并附文件引用
洞察	从本轮获得的新学习或澄清
修正的假设	重要的错误→正确转换并附解释
开放项	剩余问题或未来调查领域

文档标准：

• 每轮清晰时间戳
• 基于证据的发现并附文件引用
• 显式跟踪假设修正
• 按分析维度组织
• 轮次间链接显示理解演变

成功标准：

• 每轮处理用户反馈
• 用所有讨论轮次更新 discussion.md
• 记录和修正假设
• 达到退出条件（用户选择完成或最大轮次）
• 所有决策点记录使用决策记录格式
• 方向更改记录附前后比较和理由

阶段4：合成与结论

目标：整合所有讨论轮次的洞察，生成结论和建议。

步骤4.1：整合洞察

const conclusions = {
  session_id: sessionId,
  topic: topic,
  completed: getUtc8ISOString(),
  total_rounds: roundCount,
  summary: '...',                    // 执行摘要
  key_conclusions: [                 // 主要结论
    { point: '...', evidence: '...', confidence: 'high|medium|low' }
  ],
  recommendations: [                 // 可操作建议
    { action: '...', rationale: '...', priority: 'high|medium|low' }
  ],
  open_questions: [...],             // 未解决的问题
  follow_up_suggestions: [           // 后续步骤
    { type: 'issue|task|research', summary: '...' }
  ],
  decision_trail: [                  // 所有阶段的整合决策
    { round: 1, decision: '...', context: '...', options_considered: [...], chosen: '...', reason: '...', impact: '...' }
  ]
}
Write(`${sessionFolder}/conclusions.json`, JSON.stringify(conclusions, null, 2))

步骤4.2：最终 discussion.md 更新

追加结论部分并最终化：

合成与结论部分：

• 执行摘要：分析发现概述
• 关键结论：按置信水平排序并附支持证据
• 建议：优先行动项并附理由
• 剩余开放问题：未来工作的未解决项

当前理解（最终）部分：

子部分	内容
已确认点	确认的观点和验证发现
已澄清点	重要修正（错误→正确）
关键洞察	对未来参考有价值的学习

决策轨迹部分：

子部分	内容
关键决策	塑造分析结果的关键决策
方向更改	范围/重点调整的时间线并附理由
进行的权衡	关键权衡及为何选择特定路径

会话统计：总讨论轮次、关键发现计数、覆盖维度、生成工件、决策计数。

步骤4.3：完成后选项

if (!autoYes) {
  AskUserQuestion({
    questions: [{
      question: "分析完成。下一步：",
      header: "下一步",
      multiSelect: false,
      options: [
        { label: "快速执行", description: "将建议转换为任务并串行执行" },
        { label: "创建问题", description: "从结论创建GitHub问题" },
        { label: "生成任务", description: "启动 lite-plan 进行实施规划" },
        { label: "导出报告", description: "生成独立分析报告" },
        { label: "完成", description: "仅保存分析，无进一步行动" }
      ]
    }]
  })
}

选择	行动
快速执行	跳转到阶段5
创建问题	Skill(skill="issue:new", args="...")
生成任务	Skill(skill="workflow:lite-plan", args="...")
导出报告	复制 discussion.md + conclusions.json 到用户指定位置
完成	显示工件路径，结束

成功标准：

• 创建 conclusions.json 包含完整合成
• 用结论和决策轨迹最终化 discussion.md
• 向用户提供有意义的下一步选项
• 完整决策轨迹记录并可从初始范围界定追踪到最终结论

阶段5：快速执行（可选）

目标：将分析结论转换为带收敛标准的独立任务JSON文件，然后直接内联执行任务。

触发：用户在阶段4选择“快速执行”。

关键原则：无额外探索 — 分析阶段已收集所有必要上下文。无CLI委托 — 直接使用工具执行。

流程：conclusions.json → .task/*.json → 用户确认 → 直接内联执行 → execution.md + execution-events.md

完整规范：见 EXECUTE.md 获取详细逐步实现。

模式：cat ~/.ccw/workflows/cli-templates/schemas/task-schema.json

步骤5.1：生成 .task/*.json

将 conclusions.recommendations 转换为独立任务JSON文件。每个文件是带收敛标准的自包含任务：

const conclusions = JSON.parse(Read(`${sessionFolder}/conclusions.json`))
const explorations = file_exists(`${sessionFolder}/explorations.json`)
  ? JSON.parse(Read(`${sessionFolder}/explorations.json`))
  : file_exists(`${sessionFolder}/perspectives.json`)
    ? JSON.parse(Read(`${sessionFolder}/perspectives.json`))
    : null

const tasks = conclusions.recommendations.map((rec, index) => ({
  id: `TASK-${String(index + 1).padStart(3, '0')}`,
  title: rec.action,
  description: rec.rationale,
  type: inferTaskType(rec),  // fix | refactor | feature | enhancement | testing
  priority: rec.priority,
  effort: inferEffort(rec),  // small | medium | large
  files: extractFilesFromEvidence(rec, explorations).map(f => ({
    path: f,
    action: 'modify'
  })),
  depends_on: [],
  convergence: {
    criteria: generateCriteria(rec),         // 可测试条件
    verification: generateVerification(rec), // 可执行命令或步骤
    definition_of_done: generateDoD(rec)     // 业务语言
  },
  evidence: rec.evidence || [],
  source: {
    tool: 'analyze-with-file',
    session_id: sessionId,
    original_id: `TASK-${String(index + 1).padStart(3, '0')}`
  }
}))

// 验证收敛质量（同 req-plan-with-file）
// 将每个任务写入独立JSON文件
Bash(`mkdir -p ${sessionFolder}/.task`)
tasks.forEach(task => {
  Write(`${sessionFolder}/.task/${task.id}.json`, JSON.stringify(task, null, 2))
})

步骤5.2：预执行分析

验证可行性：依赖检测、循环依赖检查（DFS）、拓扑排序执行顺序、文件冲突分析。

步骤5.3：初始化执行工件

创建 execution.md（概述含任务表、预执行分析、执行时间线占位符）和 execution-events.md（时序事件日志头部）。

步骤5.4：用户确认

if (!autoYes) {
  AskUserQuestion({
    questions: [{
      question: `直接执行 ${tasks.length} 个任务？

执行：直接内联，串行`,
      header: "确认",
      multiSelect: false,
      options: [
        { label: "开始执行", description: "串行执行所有任务" },
        { label: "调整任务", description: "修改、重新排序或移除任务" },
        { label: "取消", description: "取消执行，保留 .task/" }
      ]
    }]
  })
}

步骤5.5：直接内联执行

直接使用工具（Read、Edit、Write、Grep、Glob、Bash）逐个执行任务。无CLI委托。

对于执行顺序中的每个任务：

1. 检查依赖已满足
2. 记录 START 事件到 execution-events.md
3. 执行：读取文件 → 分析更改 → 应用修改 → 验证收敛
4. 记录 COMPLETE/FAIL 事件附收敛验证检查表
5. 更新 execution.md 任务状态
6. 如果启用，自动提交（常规提交格式）

步骤5.6：最终化和后续

• 用最终摘要更新 execution.md（统计、任务结果表）
• 用会话页脚最终化 execution-events.md
• 更新 .task/*.json 每个任务的 _execution 状态

if (!autoYes) {
  AskUserQuestion({
    questions: [{
      question: `执行完成：${completedTasks.size}/${tasks.length} 成功。
下一步：`,
      header: "后执行",
      multiSelect: false,
      options: [
        { label: "重试失败", description: `重新执行 ${failedTasks.size} 个失败任务` },
        { label: "查看事件", description: "显示 execution-events.md" },
        { label: "创建问题", description: "从失败任务创建问题" },
        { label: "完成", description: "结束工作流" }
      ]
    }]
  })
}

成功标准：

• 生成 .task/*.json 带收敛标准和来源证明
• execution.md 包含计划概述、任务表、预执行分析、最终摘要
• execution-events.md 包含时序事件流附收敛验证
• 所有任务通过直接内联执行执行（或明确跳过）
• 通知用户结果和后续步骤

输出结构

{projectRoot}/.workflow/.analysis/ANL-{slug}-{date}/
├── discussion.md              # 理解演变和讨论
├── exploration-codebase.json  # 阶段2：代码库上下文
├── explorations/              # 阶段2：多视角探索（如果选择）
│   ├── technical.json
│   ├── architectural.json
│   └── ...
├── explorations.json          # 阶段2：单视角聚合发现
├── perspectives.json          # 阶段2：多视角发现附合成
├── conclusions.json           # 阶段4：最终合成附建议
├── .task/                     # 阶段5：独立任务JSON文件（如果快速执行）
│   ├── TASK-001.json          #   每个任务一个文件带收敛和来源
│   ├── TASK-002.json
│   └── ...
├── execution.md               # 阶段5：执行概述 + 任务表 + 摘要（如果快速执行）
└── execution-events.md        # 阶段5：时序事件日志（如果快速执行）

文件	阶段	描述
discussion.md	1	用会话元数据初始化，阶段4最终化
exploration-codebase.json	2	代码库上下文：相关文件、模式、约束
explorations/*.json	2	每视角探索结果（仅多视角）
explorations.json	2	单视角聚合发现
perspectives.json	2	多视角发现附跨视角合成
conclusions.json	4	最终合成：结论、建议、开放问题
.task/*.json	5	从建议生成的独立任务文件，每个带收敛标准和来源证明
execution.md	5	执行概述：计划来源、任务表、预执行分析、最终摘要
execution-events.md	5	时序事件流附任务细节和收敛验证

分析维度参考

维度指导分析范围和重点：

维度	关键词	描述
architecture	架构, architecture, design, structure, 设计, pattern	系统设计、组件交互、设计模式
implementation	实现, implement, code, coding, 代码, logic	代码模式、实现细节、算法
performance	性能, performance, optimize, bottleneck, 优化, speed	瓶颈、优化机会、资源使用
security	安全, security, auth, permission, 权限, vulnerability	漏洞、认证、访问控制
concept	概念, concept, theory, principle, 原理, understand	基础思想、原则、理论
comparison	比较, compare, vs, difference, 区别, versus	比较解决方案、评估替代方案
decision	决策, decision, choice, tradeoff, 选择, trade-off	权衡、影响分析、决策理由

分析视角

可选多视角分析（单视角是默认，最多4个）：

视角	重点	最适合
技术	实现模式、代码结构、技术可行性	理解如何和技术细节
架构	系统设计、可扩展性、组件交互	理解结构和组织
安全	安全模式、漏洞、访问控制	识别安全风险
性能	瓶颈、优化、资源利用	发现性能问题

选择：用户可在阶段1多选最多4个视角，或默认为单视角全面视图。

分析深度级别

深度	范围	描述
Quick	表面级别理解	快速概述，最小探索
Standard	中等深度附良好覆盖	平衡分析（默认）
Deep	全面详细分析	彻底多轮调查

维度-方向映射

当用户选择重点领域时，从检测到的维度动态生成方向：

维度	可能方向
architecture	系统设计、组件交互、技术选择、集成点、设计模式、可扩展性策略
implementation	代码结构、实现细节、代码模式、错误处理、测试方法、算法分析
performance	性能瓶颈、优化机会、资源利用、缓存策略、并发问题
security	安全漏洞、认证/授权、访问控制、数据保护、输入验证
concept	概念基础、核心机制、基本模式、理论和原则、权衡和推理
comparison	解决方案比较、优缺点分析、技术评估、方法差异
decision	决策标准、权衡分析、风险评估、影响分析、实施影响

实现：呈现2-3个顶部维度相关方向，允许用户多选和添加自定义方向。

整合规则

更新 discussion.md 中的“当前理解”时：

规则	描述
提升确认的洞察	将验证发现移动到“已确认点”
跟踪修正	保留重要的错误→正确转换
关注当前状态	我们现在知道什么，而非过程
避免时间线重复	不将讨论细节复制到整合部分
保留关键学习	保留对未来参考有价值的洞察

示例：

不良（杂乱）：

## 当前理解
在第1轮我们讨论了X，然后在第2轮用户说Y...

良好（整合）：

## 当前理解

### 已确认点
- 认证流程使用JWT带刷新令牌
- 速率限制在API网关级别实现

### 已澄清点
- ~~假设Redis用于会话~~ → 实际使用数据库支持会话

### 关键洞察
- 当前架构支持水平扩展

模板

discussion.md 结构

discussion.md 文件通过分析演变：

• 头部：会话ID、主题、开始时间、识别维度
• 分析上下文：重点领域、视角、深度级别
• 初始问题：指导分析的关键问题
• 初始决策：为何选择这些维度和重点领域
• 讨论时间线：轮次逐个发现
  • 第1轮：初始理解 + 探索结果 + 初始决策日志
  • 第2-N轮：用户反馈 + 方向调整 + 新洞察 + 每轮决策日志
• 决策轨迹：整合所有轮次的关键决策
• 合成与结论：摘要、关键结论、建议
• 当前理解（最终）：整合洞察
• 会话统计：完成轮次、发现计数、生成工件、决策计数

轮次文档模式

每个讨论轮次遵循一致结构：

### 第N轮 - [深化|调整|问答] (时间戳)

#### 用户输入
用户指示他们想关注的内容

#### 决策日志
> **决策**：[方向/范围/方法决策描述]
> - **上下文**：[触发此决策的原因]
> - **考虑的选项**：[评估的替代方案]
> - **选择**：[选定的方法] — **原因**：[理由]
> - **影响**：[对分析方向/结论的影响]

#### 分析结果
本轮分析的新发现
- 发现1（证据：文件:行）
- 发现2（证据：文件:行）

#### 洞察
关键学习和澄清

#### 修正的假设
- ~~先前假设~~ → 修正理解
  - 原因：为何假设错误

#### 开放项
剩余问题或调查领域

错误处理

情况	行动	恢复
未检测到代码库	正常流程，纯主题分析	继续无 exploration-codebase.json
代码库搜索失败	继续可用上下文	在 discussion.md 中注明限制
无相关发现	扩大搜索关键词	询问用户澄清
用户讨论超时	保存状态，显示恢复命令	使用 --continue 恢复
达到最大轮次（5）	强制合成阶段	在结论中突出剩余问题
会话文件夹冲突	附加时间戳后缀	创建唯一文件夹并继续
快速执行：任务失败	在 execution-events.md 中记录失败	用户可重试、跳过或中止
快速执行：验证失败	标记标准为未验证，继续	在事件中注明，手动检查
快速执行：无建议	无法生成 .task/*.json	建议使用 lite-plan

最佳实践

核心原则

1. 代码修改前需明确用户确认：分析阶段严格只读。任何代码更改（阶段5快速执行）需要用户批准。

开始分析前

1. 清晰主题定义：详细主题导致更好的维度识别
2. 用户上下文：理解重点偏好有助于界定分析
3. 视角选择：复杂主题选择2-4个视角，聚焦查询选单视角
4. 范围理解：明确深度期望设置正确分析强度

分析期间

1. 审查发现：在进入讨论前检查探索结果
2. 文档假设：跟踪你认为正确的内容以备后期修正
3. 使用继续模式：恢复会话以基于先前发现而非重新开始
4. 拥抱修正：跟踪错误→正确转换作为有价值学习
5. 迭代思考：每轮讨论应有意义地精炼理解
6. 立即记录决策：永不推迟记录 — 使用决策记录格式在发生时捕获决策。未及时记录的决策是丢失的决策

文档实践

1. 基于证据：每个结论应引用特定代码或模式
2. 置信水平：为结论指示置信度（高/中/低）
3. 时间线清晰：使用清晰时间戳用于可追溯性
4. 演变跟踪：记录理解如何跨轮次更改
5. 行动项：生成具体、可操作的建议
6. 多视角合成：使用多视角时，记录收敛/冲突主题
7. 链接决策到结果：撰写结论时，显式引用哪些决策导致哪些结果 — 这创建从初始范围界定到最终建议的可审计轨迹

何时使用

使用 analyze-with-file 当：

• 探索复杂主题并带有文档化轨迹的协作
• 需要多轮迭代精炼理解
• 决策制定需要探索多视角
• 在实施前建立共享理解
• 想记录理解如何演变

使用快速执行（阶段5）当：

• 分析结论包含清晰、可操作建议
• 上下文已足够 — 无需额外探索
• 想要流线化的分析 → .task/*.json 计划 → 直接执行管道
• 任务相对独立并可串行执行

考虑替代方案当：

• 需要特定bug诊断 → 使用 debug-with-file
• 生成新想法/解决方案 → 使用 brainstorm-with-file
• 复杂规划带并行视角 → 使用 collaborative-plan-with-file
• 准备实施 → 使用 lite-plan
• 需求分解需要 → 使用 req-plan-with-file

---

现在为主题执行 analyze-with-file 工作流： $TOPIC