首先，这篇文章是针对使用openclaw进行java项目维护进行的任务拆分总结，例如修改bug、修改之前功能需求，新开发功能不在此范围。

复杂需求任务拆分框架

我发现让openclaw直接分析整个java项目，然后再做修改，效果不是很好，而且一个大而全的任务，修改的内容很多，后期做代码评审的时候无从下手，近期公司对旧系统做需求变更，将之前一个核心表xx_log拆分成xx_log+xx_log_error两张表，分别存储正常和异常数据，新建视图v_log，联合查询xx_log和xx_log_error，现在需要将所有之前使用xx_log进行查询的地方，都修改成查询v_log视图，如上复杂的需求，我该从哪些方面着手，去拆分这个任务，让大模型做得更好，例如横向拆解，先定位到java项目哪些controller受到影响，然后再基于controller去定位哪些service需要调整，最后是mapper哪些需要调整，以此类推。或者纵向拆解，直接定位到controller，然后基于该controller往下找service，再找mapper，将这个controller改完后，再去定位下一个controller。下面对横向和纵向分解做一下分析对比。

横向拆解（分层式）

第一层：所有 Controller → 第二层：所有 Service → 第三层：所有 Mapper

优点 ：

• 同一层修改模式相似，可以批量处理
• 容易发现重复代码，便于提取公共逻辑

缺点 ：

• 修改跨度大，上下文切换频繁
• 难以验证单个功能的完整性
• 容易遗漏层与层之间的依赖

纵向拆解（调用链式）✅ 推荐

链路1: Controller → Service → Mapper → 测试验证
链路2: Controller → Service → Mapper → 测试验证
...

优点 ：

• 每个链路独立完整，修改后可立即验证
• 上下文集中，不容易遗漏依赖
• 出错时影响范围小，便于回滚

缺点 ：

• 可能有重复修改（多个 Controller 调用同一个 Service）

二、我推荐的任务拆分框架（实践验证）

结合你的 Log 日志修改需求，我建议采用 "业务场景 + 调用链" 混合拆分 ：

┌─────────────────────────────────────────────────────────┐
│  第一层：按业务场景拆分（识别影响的功能模块）            │
├─────────────────────────────────────────────────────────┤
│  第二层：每个场景内按调用链拆分（Controller→Service→DAO）│
├─────────────────────────────────────────────────────────┤
│  第三层：每个文件内按方法拆分（定位具体修改点）          │
└─────────────────────────────────────────────────────────┘

三、具体操作步骤（以 Log 日志修改为例）

📌 步骤 1：识别业务场景（5-10 分钟）

先回答这个问题：哪些用户可见的功能会受到影响？

输出物 ：业务场景清单（6 个场景）

📌 步骤 2：每个场景按调用链拆解（10-15 分钟）

以 "Log 数据查询" 场景为例：

【场景 1】Log 数据查询
├─ 入口：LogQueryController.java
│  ├─ GET /api/logQuery/getOdsSourceList
│  ├─ POST /api/logQuery/getHeader
│  ├─ POST /api/logQuery/list  ← 核心查询接口
│  └─ GET /api/logQuery/queryConditionByDomain
│
├─ 服务：LogQueryServiceImpl.java
│  ├─ list()  ← 主查询方法（改表名为视图）
│  ├─ listBySql()  ← SQL 查询（改表名为视图）
│  ├─ buildQuery()  ← 构建查询条件（逻辑不变）
│  └─ buildResult()  ← 结果处理（逻辑不变）
│
└─ 数据层：LogMapper.java
   └─ (本场景不涉及)

输出物 ：调用链树状图

📌 步骤 3：定义修改类型（5 分钟）

对每个方法标注修改类型：

📌 步骤 4：生成任务清单（最终输出）

## 任务清单：Log 日志异常数据逻辑调整

### 【场景 1】Log 数据查询（优先级 P0）
- [ ] 修改 LogQueryServiceImpl.list() - 表名替换
- [ ] 修改 LogQueryServiceImpl.listBySql() - 表名替换
- [ ] 验证查询接口（手动测试）

### 【场景 2】数据质量统计（优先级 P0）
- [ ] 修改 LogExtDao.batchListDataQuality() - 表名替换
- [ ] 修改 LogExtDao.syncDataSource() - 表名替换
- [ ] 修改 WorkBenchServiceImpl.syncDataTrend() - 表名替换
- [ ] 验证统计准确性（对比数据）

### 【场景 3】异常数据查看（优先级 P1）
- [ ] 确认 LogExtServiceImpl.searchList() - 已使用视图
- [ ] 确认 LogMapper.selectListFromVodsLogAll() - 已使用视图
- [ ] 验证异常数据列表（手动测试）

### 【场景 4】异常数据处理（优先级 P1）
- [ ] 修改 OdsLogExtServiceImpl.batchIgnore() - 确认操作表
- [ ] 修改 OdsLogExtServiceImpl.recommit() - 确认表间移动逻辑
- [ ] 验证忽略/重新提交功能（手动测试）

四、任务提交模板（推荐）

提交给openclaw的任务模板如下：

## 任务：ODS 日志异常数据逻辑调整

### 背景
（简短描述变更原因）

### 已拆解的任务清单
（按上述格式列出所有子任务）

### 执行要求
1. 按优先级顺序执行（P0 → P1 → P2 → P3）
2. 每个场景完成后输出验证结果
3. 遇到不确定的修改点先暂停，汇总后统一确认

### 第一个任务
（明确告诉我从哪个任务开始）

五、为什么这样拆分更有效？

六、总结：最佳实践公式

好的任务拆分 = 业务场景识别 + 调用链追踪 + 修改类型标注 + 优先级排序

提交复杂任务前的检查清单 ：

• 识别所有受影响的业务场景
• 每个场景画出调用链（Controller→Service→DAO）
• 每个方法标注修改类型
• 按影响范围排了优先级
• 明确验证方式