复杂规划的三大“硬伤”：大模型为何仍绕不过去
在研究 PlannerCritic 开源框架时，我发现大模型（如 GPT-4o）在复杂任务规划中的局限性并非参数量能解决。在 63 个严格目标的测试中，即使将模型升级至顶配版本，仍会反复陷入三类结构性错误，这些问题并非“能力不足”，而是源于逻辑闭环在长链条规划中的脆弱性。
第一类是“依赖关系验证缺失”。模型虽然知道任务 A 需要前置条件 B，但在实际规划中，却不会在前置步骤中明确安排“验证 B 是否成功”的验证环节。例如，计划“100% 切流”时，前面可能没有任何步骤用于确认“10% 切流是否稳定”，导致后续操作无法保证前提条件的可靠性。
第二类是“执行顺序逻辑混乱”。模型能列出步骤，但对步骤间的因果关系缺乏强约束，常将“备份”放在“迁移”之后，或将“数据回填”安排在“质量检查”之前。这种顺序错误在高风险操作中尤为致命，因为缺乏对状态变化的严格前置检查。
第三类是“回滚方案敷衍不足”。在涉及高风险操作（如数据库拆分）的场景中，模型通常只在常规步骤中添加简单的回滚指令（如“切回单写模式”），而忽略切换过程中的数据不一致问题。这种回滚方案在实战中几乎无法执行，因为无法保证系统在失败时能恢复到一致状态。
即使采用 GPT-4o 双持架构（一个模型规划，另一个模型审核），或引入轻量级 Critic 机制，结果依然相同：规划的文字表述更加优美，但逻辑漏洞依旧存在。这是因为“Critic 报错 → Planner 修改”这种循环机制无法根治核心问题，Planner 在修复一个 Bug 时，往往会引入新的依赖冲突。
解决方案不在于换模型，而在于强制引入“确定性校验”。单纯依赖模型自生成的规划无法满足复杂任务的需求，必须通过 Prompt 设计强制模型在每个关键节点执行状态检查。以下是针对复杂规划的 Prompt 优化框架，核心在于“前置条件验证”和“风险回滚闭环”：
# Role: Senior Systems Architect & Planner
## Task
Generate a high-precision execution plan for the following goal: {{goal}}
## Strict Constraints (Mandatory)
1. **Dependency Verification**: For every critical task, you MUST explicitly include a "Verification Step" in the preceding task. Do not assume a state is achieved; prove it.
2. **Sequential Integrity**: Tasks must follow a strict causal chain. No high-risk operation can be scheduled before its prerequisite stability check is completed.
3. **Robust Rollback**: For every task with a "high blast radius" (e.g., data migration, traffic cutover, schema change), you must provide a "Deep Rollback" plan. A deep rollback must address data consistency and state recovery, not just a simple toggle switch.
## Output Format
For each task, use the following structure:
- **Task ID**: [ID]
- **Action**: [Detailed description]
- **Prerequisite Verification**: [How to confirm the previous state is ready for this task]
- **Success Criteria**: [Specific metric or state to confirm completion]
- **Rollback Plan**: [Detailed steps to revert to a consistent state if this task fails]此类规划问题的根本解决路径在于优化工作流和校验逻辑，而非依赖模型参数的扩大。
全部回复 （3）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
那个 dependency graph 一旦过千个节点，planner 确实会在 revision 环节卡死，但更本质的问题在于模型无法自动在前置步骤中嵌入“验证 B 是否成功”的逻辑——比如“100% 切流”前，它不会主动要求先确认“10% 切流是否稳定”，而是把验证当作隐含的“常识”。结果就是规划看起来完整，实际执行时却因为依赖断裂而崩盘。换大模型只能让错误变得更“优雅”，而不是更可靠。
边界条件没处理好真的会死掉，我之前在写复杂任务规划时就栽了大跟头。一开始以为换个更强的模型就能解决问题，比如从 GPT-3.5 换到 GPT-4o，但实际测试发现，即使用 GPT-4o 当 Planner，面对复杂任务依然会反复掉进同一个坑——比如计划“100% 切流”却没有任何一步去“验证 B 是否成功”（比如“10% 切流是否稳定”），导致整个流程在执行中崩掉。关键在于，模型虽然能列出步骤，但对步骤间的依赖关系和因果逻辑缺乏强约束，特别是在高风险操作前没有前置条件验证时，问题就变得不可控。
后来我意识到，解决这个问题的关键不是堆参数，而是要在 Prompt 中强制引入“前置条件验证”和“风险回滚闭环”，比如明确要求每个关键步骤前都必须有“验证步骤”，而不是假设前置条件已经满足。这样写出来的规划才能在实战中真正管用。
资源账本全是空的太真实了，写运维计划时看着顺滑，结果逻辑断层断得我想撞墙。哪怕把模型升到顶配，面对复杂任务依然会反复掉进同一个坑。我试着在 Prompt 里强制要求“前置条件验证”和“风险回滚闭环”，比如在“100% 切流”前必须加一步“10% 切流是否稳定”的确认，在数据库拆分这类高风险操作里不能只写一句“切回单写模式”，必须补上数据一致性恢复方案，结果逻辑漏洞才终于少了一些。