Planning
Also: 任務規劃 · 計畫與執行 · plan-and-execute · 任務拆解
Before acting, have the model produce a list of steps, then execute them — revising the list as reality reports back.
When you will meet it
You meet it in every multi-step task — research, refactoring, deployment. Without it two things stay puzzling: why the plan an agent lists up front later changes beyond recognition (normal; the world pushes back), and why mature systems invest in re-planning rather than in one perfect initial plan.
An analogy
Like sketching an itinerary before a trip. It helps: rough order, nothing forgotten. But rain, a closed shop, a better find on the way — all force live edits. No travel companion blames the itinerary for not surviving the trip; that is exactly what it is for.
Minimal example
Plan（示意）:
1. 找出所有呼叫舊 API 的檔案
2. 逐個改成新 API
3. 跑測試
4. 寫變更摘要
執行到第 3 步發現：舊 API 有兩種呼叫模式，
第 2 步只改到其中一種
→ 重新規劃：2a. 補改第二種模式 → 3. 重跑測試 → 4.The point is the second half: a plan's value is not predicting correctly but providing a skeleton to compare against and revise. Without a skeleton, re-planning has nothing to bite on.
What people get wrong
- Assuming a detailed plan should simply be followed. Every executed step brings new information; an agent that clings to the original plan walks further down the wrong road, confidently.
- Treating planning as a pure model property. Half of plan quality is whether the harness offers re-planning at all: are results fed back, is the list allowed to change.