1.6　为复杂工作流设计任务分解策略

这一条考什么

考你面对一个复杂任务时，能否选出合适的分解模式：子任务固定、可预测的多维度工作用提示链（prompt chaining）；方向未知、需要边做边发现的开放式任务用动态自适应分解。典型题目包括：大型代码评审如何拆成"逐文件本地分析 + 跨文件整合"两类 pass，以及"为遗留代码库补全测试"这类开放任务该如何先摸清结构、再按优先级规划并随依赖发现而调整。

核心概念

两类分解模式

固定顺序流水线（提示链）：把任务拆成预先确定的若干步，每一步是一次聚焦的模型调用，上一步的输出作为下一步的输入，必要时在步骤之间加程序化检查（gate）。适用条件：

• 每次都要做同样几件事（例如每个 PR 都要查风格、安全、文档）。
• 子任务之间边界清楚，可以独立评估。
• 你更看重稳定、可重复、易调试。

动态自适应分解：先做少量探索，根据中间发现决定下一批子任务；计划在执行过程中不断修正。适用条件：

• 事先不知道问题在哪里、需要看哪些文件（例如排查某个接口的间歇性 500）。
• 任务范围大且模糊（"让这个模块更健壮""补全测试"）。
• 每一步的发现都会显著改变后续优先级。

判断方法：问自己"能否在开始前写出完整的步骤清单？"能，就用提示链；不能，就用动态分解。

提示链在代码评审中的应用

把一次大评审塞进一个提示会导致注意力分散：文件多、关注点多时，模型在某些维度上表现好，在另一些维度上漏报；给某一维度加 few-shot 示例，另一维度的召回又下降。拆分方式：

1. 逐文件本地分析 pass：每个文件单独一次调用，只关注该文件内部的问题（逻辑错误、边界条件、明显的安全问题），输出结构化的发现列表。
2. 跨文件整合 pass：把各文件的发现摘要（而非全部源码）汇总，再做一次调用，专门检查跨文件问题：接口签名不一致、调用方未适配、重复实现、数据流断裂。
3. 可选：按关注维度再切分（安全 + API 设计一个提示，业务逻辑一个提示，各自配专属示例），最后合并去重后再发布。

这样每次调用的上下文都小而聚焦，每个维度都有独立的评估标准与示例，互不干扰。

动态分解在开放任务中的应用

以"为遗留代码库添加全面测试"为例，正确的分解不是"先通读全部 200 个文件"或"按顶层目录平均分配工作量"，而是：

1. 摸清结构：用 Glob 列出目录与文件，用 Grep 查找入口、现有测试、被大量 import 的模块。
2. 识别高影响区域：被依赖最多的核心模块、承载关键业务的代码（计费、权限）、近期改动频繁或缺陷集中的部分。
3. 制定带优先级的计划：先给高影响、低耦合的部分写测试，建立可运行的测试基础设施。
4. 边做边调整：写测试时发现某模块依赖一个难以 mock 的全局单例，就新增"先抽象该依赖"的子任务，并重新排序后续计划。

排查类任务也一样：从已知证据（路由定义、堆栈、日志）出发，每一步的发现决定下一步查什么，而不是预先写死"先 grep 错误、再看错误处理、再看数据库、再看中间件"的固定序列，也不是先花大量时间画出全部代码路径再动手。

两者可以组合

真实系统里常常是外层动态、内层固定：协调者动态决定要评审哪些模块，对每个被选中的模块走固定的"本地分析 → 整合"提示链。考试时关键是识别题干强调的是"可预测、每次相同"还是"未知、需探索"。

正确做法与反模式

• 正确：对每次都相同的多维度评审使用提示链，每步聚焦一个维度。反模式：一个超长提示同时覆盖所有维度，靠"让模型自己兼顾"。
• 正确：大型评审拆成逐文件本地分析 pass 与独立的跨文件整合 pass。反模式：一次性把所有文件塞进上下文做整体评审。
• 正确：开放式任务先用轻量工具摸清结构、找高影响区域，再按优先级规划并随发现调整。反模式：预先按目录平均分配，或先通读全部文件再开始。
• 正确：排查问题时根据每一步的证据决定下一步。反模式：执行预设的固定排查序列而无视中间发现。
• 正确：对于可预测任务不引入不必要的动态编排。反模式：把简单固定流程也做成 orchestrator-workers，增加成本和不确定性。

常见陷阱

• "用一个综合提示涵盖全部检查，让模型同时处理"——注意力分散、维度互相干扰，题目中出现"某维度召回率低、加示例后另一维度下降"就是在暗示要拆分。
• "提供整个仓库作为上下文以获得更深理解"——上下文更大反而更稀释注意力；缺跨文件证据时应改为可读文件、可搜索的 Agent 式评审，而不是全量塞入。
• "固定的测试计划：按目录平均分配工作量"——忽略复杂度和业务重要性。
• "先系统性读完所有文件建立完整清单"——成本高、不聚焦，也无法根据发现调整。
• 对可预测的固定检查选"orchestrator-workers 动态判断需要哪些检查"——任务本身可预测时，提示链更简单可靠。

实操练习

目标：用 anthropic SDK 实现"逐文件本地分析 + 跨文件整合"两段式提示链。

1. 准备一个包含 3–5 个 Python 文件的小目录 src/（可以故意让 a.py 的函数签名改了而 b.py 的调用没改）。
2. 保存并运行下面的 chain_review.py。
3. 对比逐文件结果与整合结果，确认跨文件问题只在第二段中被发现。

import json, pathlib
import anthropic

client = anthropic.Anthropic()
MODEL = "claude-sonnet-4-5"

def ask(system, user):
    r = client.messages.create(model=MODEL, max_tokens=2000, system=system,
                               messages=[{"role": "user", "content": user}])
    return r.content[0].text

LOCAL_SYS = ("你是代码评审员。只分析给定的单个文件内部的问题。"
             "输出 JSON：{\"file\":..., \"exports\":[公开函数及签名], "
             "\"imports_used\":[调用的外部函数及参数], \"issues\":[{\"line\":..,\"desc\":..}]}")

CROSS_SYS = ("你是跨文件评审员。输入是多个文件的本地分析结果。"
             "只找跨文件问题：签名不一致、调用方未适配、重复实现。输出要点列表并指明涉及文件。")

local_results = []
for path in sorted(pathlib.Path("src").glob("*.py")):
    out = ask(LOCAL_SYS, f"文件 {path.name}:\n```\n{path.read_text()}\n```")
    print(f"== 本地 pass: {path.name}\n{out}\n")
    local_results.append(out)

print("== 跨文件整合 pass")
print(ask(CROSS_SYS, "\n\n".join(local_results)))

检查结果：本地 pass 应能指出各文件内部问题，并在 exports/imports_used 中记录签名；整合 pass 应指出 b.py 调用 a.py 函数时参数不匹配。再尝试把所有文件放进同一个提示评审，比较漏报情况。

自测清单

• 用一句话说明提示链与动态分解各自的适用条件。
• 为什么大型代码评审要拆成本地 pass 与跨文件 pass？跨文件 pass 的输入应该是什么？
• 一个评审维度召回率低、加示例后另一维度下降，说明了什么？该怎么改？
• "为遗留代码库添加全面测试"应如何分解？第一步做什么？
• 排查间歇性故障时，为什么不应预先写死排查序列？