并行执行优化器 是做什么的？
当速度来自同时进行独立工作时使用此技能： 仓库检查、文件读取、API验证、浏览器检测、构建/测试通道、 部署回读或多工作树实现通道。
核心模式
在行动之前将紧急情况转化为依赖关系图。
- 定义目标和完成信号。
- 将工作分解为通道。
- 将每个通道标记为并行、串行或门控。
- 同时运行独立的读取/检查操作。
- 保持写入操作按文件、工作树、分支、服务或数据集隔离。
- 仅在证据显示通道兼容后才进行合并。
- 以验证表结尾，而不是模糊的速度声明。
通道矩阵
在重大推进之前，编写一个简洁的矩阵：
通道 | 可否并行执行？ | 写入范围 | 风险 | 验证
仓库扫描 | 是 | 无 | 低 | rg/git status 输出
后端补丁 | 可能 | src/api | 中 | 单元测试
前端补丁 | 可能 | app/components | 中 | 浏览器截图
部署回读 | 构建之后 | 远程服务 | 高 | 实时URL + 日志
仅当通道的写入范围不冲突时才并行运行它们。
执行规则
- 批量处理文件读取、搜索、状态检查和元数据查询。
- 对于大型不相关的实现通道，使用隔离的工作树。
- 在单独的会话中启动长周期测试、构建、数据回填和部署， 然后有目的地轮询它们。
- 如果一个通道发现了会改变计划的阻塞点，则暂停依赖它的通道 并更新矩阵。
- 除非用户明确要求一个持续运行的服务，否则永远不要让后台进程 超出当前轮次的存活时间。
- 在没有明确门控的情况下，不要并行执行破坏性命令、迁移、对同一张表的写入， 或影响线上客户的部署。
输出格式
报告时使用以下格式：
并行执行结果：
- 运行通道数：5
- 完成通道数：4
- 阻塞通道：部署回读，等待DNS传播
- 发现的快速路径：批量仓库扫描 + 聚焦测试
- 验证：lint通过、单元测试通过、线上冒烟测试通过
失败模式
- 过多并发导致冲突的编辑。
- 对工具本身进行基准测试而非任务本身。
- 在正确性得到证明之前将“快”视为完成。
- 忘记轮询正在运行的会话。
- 在成功摘要后隐藏跳过检查的项目。