批量敏捷需求执行

批量解析问题需求文档，协调 fixer 子智能体逐条修复，并输出汇总报告。问题范围不限于样式，也包括 Renderer 交互 / 页面逻辑、协议联调、Main IPC、Core 写入、Agent 流式事件、工具调用、本地存储和配置问题。

输入

用户会提供一个 Markdown 需求文档的路径，文档格式如下：

# 标题

> 解析时间：...
> 来源文件：...
> 记录数：N 条

---

## #编号 — 标题

| 字段 | 内容 |
| --- | --- |
| **编号** | X |
| **时间** | ... |
| **发起人** | ... |
| **定位** | 左侧资源树 / 中间对话 / Core Catalog / Agent 流式 |
| **问题类型** | 样式问题 / 前端逻辑 / 后端逻辑 / 接口问题 / bug |
| **完成状态** | — |
| **验证状态** | — |
| **备注** | — |

### 问题描述

...

### 问题截图

![截图](data/xxx/row_X_img_1.jpeg)

---

工作流程

1. 读取并解析需求文档

读取用户提供的 Markdown 文件，将其按 --- 分隔符拆分为独立的条目。每个条目提取以下字段：

• 编号：条目编号，如 #17。
• 标题：条目标题，如存在则保留。
• 定位：所属页面、模块、协议、Utility 或工具。
• 问题描述：问题描述正文。
• 问题截图路径：截图的相对路径，如有。
• 问题类型：样式问题 / 前端逻辑 / 后端逻辑 / 协议问题 / 流式会话 / 智能体 / bug / 其他。

如果截图路径是相对路径，尝试基于需求文档所在目录解析为绝对路径，以便后续传给 fixer 查看。

2. 加载 fixer 角色定义

读取 .codex/agents/fixer.md，将其内容作为 fixer 子智能体的角色定义和执行边界。不得加载仅限 UI 的 agent 作为全栈替代。

3. 逐条串行调用 fixer

对每个条目，按编号顺序串行执行：必须等上一个 fixer 返回后再启动下一个，避免并发修改同一文件导致冲突。

构造任务描述：

请严格遵守以下 Codex 子智能体使用说明：

1. 你是通过 Codex 子智能体工具调用的修复子智能体。
2. 角色定义使用仓库内 `.codex/agents/fixer.md` 的完整内容。
3. 调用参数建议：
   - agent_type: worker
   - reasoning_effort: high
   - fork_context: true
4. 你不独占代码库，可能存在用户或其他智能体的改动；不要回滚无关修改。
5. 你需要直接在自己的工作区修改代码，并在最终回复中列出修改文件、修复摘要和验证结果。
6. 如果确认必须修改真实用户数据目录、生产密钥或外部系统配置才能解决，停止直接执行外部变更，按 `.codex/agents/fixer.md` 的边界说明原因和建议方案。

{.codex/agents/fixer.md 的完整内容作为角色定义}

当前任务：
- 编号：#{编号}
- 标题：{标题}
- 定位：{定位}
- 问题类型：{问题类型}
- 问题描述：{问题描述}

{如果有截图且文件存在，补充：相关截图：{绝对路径}}
{如果截图不存在，补充：截图路径不可读：{原始路径}}

请定位相关 Renderer 组件/composable、Preload、Main IPC、Core/Agent/Tool Utility、packages/contracts 或配置等上下游代码，直接修改代码解决问题。不要只处理样式；如果问题根因在前端逻辑、协议字段、Core 写入、Agent 事件或业务逻辑，也必须一并修复。保持回复精简。

每次只启动一个 fixer。等待当前 fixer 完成、记录结果后，再启动下一个。

4. 捕获并记录返回值

对每次 fixer 调用，记录：

• 修复状态：根据返回内容判断为 已修复 / 部分修复 / 未修复 / 需要外部变更 / 跳过。
• 修改的文件列表：提取返回中提到的已修改文件路径。
• 修复摘要：fixer 返回的核心内容摘要，1-3 句话。
• 验证结果：fixer 是否进行了验证及验证结果。
• 未修复原因：如果未修复、跳过或需要外部变更，记录原因。

5. 生成解决结果文档

所有条目处理完毕后，创建目录 docs/bug解决需求文档/需求文档/敏捷需求与bug/（如果不存在），并在该目录下生成 docs/bug解决需求文档/需求文档/敏捷需求与bug/{原始文件名（不含扩展名）}-解决结果.md。

文档模板：

# {原始文件名} — 解决结果

> 生成时间：YYYY-MM-DD HH:mm:ss
> 总条目数：N
> 已修复：X
> 部分修复：Y
> 需要外部变更：Z
> 未修复/跳过：W

---

## #{编号} — {标题}

**定位**：{定位}

**问题类型**：{问题类型}

**修复状态**：{已修复/部分修复/未修复/需要外部变更/跳过}

**修改文件**：
{如果有修改文件，列出；如果没有则写“无”}

**修复摘要**：
{fixer 返回的修复内容摘要}

**验证结果**：
{验证结果或说明}

**未修复原因**：
{如未修复、跳过或需要外部变更，说明原因；否则写“—”}

---

注意事项

• 必须串行调用：每个 fixer 任务必须等上一个完成后再启动，避免并发修改同一文件。
• 固定修复 agent：解决问题必须调用 .codex/agents/fixer.md。
• 全栈修复范围：不要把该技能限制为样式修复。样式、前端逻辑、协议联调、Main IPC、Core 写入、Agent 流式、工具调用、配置、参数、返回值等问题都应由 fixer 处理。
• 保留原始文件：不要修改原始需求文档。
• 截图传递：如果截图文件真实存在，在传给 fixer 的任务中提供绝对路径，帮助其定位问题。
• 失败处理：如果某个 fixer 调用失败，记录失败原因后继续处理下一条目，不要中断整个流程。
• 结果文档位置：必须放在 docs/bug解决需求文档/需求文档/敏捷需求与bug/，文件名格式为 {原始文件名}-解决结果.md。