多檔安全重構指令：先盤影響範圍，再分批改，每批可獨立驗證
給 agent 的大型重構作戰手冊：先唯讀盤點『影響範圍 / blast radius』（哪些檔案、呼叫點、測試會受影響），再把改動切成多個小批次，每批保持行為不變、各自跑測試、各自一個原子 commit。拒絕「一次改 40 個檔案然後 build 紅了不知從何救起」。
大型重構最怕 agent 一口氣改幾十個檔案、最後 build 全紅、根本不知道哪一步壞的。
這支指令逼它：① 先唯讀盤出完整影響範圍 ② 切成小批、每批行為不變 ③ 每批各自跑測試 + 各自一個原子 commit，壞了能精準回退。
[ Log in to see the full prompt ]Sign up free to see the full prompt, copy it, save it, and join the discussion. Free content unlocks on login; Pro content is a separate subscription.
適用情境：跨多檔的結構性重構（搬移模組、改命名慣例、抽共用邏輯、換掉某個 API 的所有呼叫點）。為什麼有效：① 強制『先唯讀盤 blast radius 再動手』，這是專業重構的核心紀律，避免 agent 漏掉呼叫點導致 build 紅；② 分批 + 每批保持『可編譯、測試綠、可單獨 commit』，壞掉時能精準二分定位，而不是面對一坨改動束手無策；③ 原子 commit、不混 refactor 與行為變更，讓 PR review 變快、出事好回退；④ 明確禁止『順手改不相干程式碼 / 改不該動的格式』，把 diff 控制在最小可審範圍。技巧：搭配 Claude Code 的 plan mode（Shift+Tab 兩下）或 Codex 的 read-only sandbox 跑 Phase 1，效果最好；VERIFY_COMMAND 填你能一鍵驗證的指令。所有提到的能力（read-only 探索 / plan mode / 分批 commit）都是真實工作流。
## Phase 1 — Blast radius Direct targets: src/api/*.ts 裡 11 處裸 fetch() Call sites & ripple: 23 個元件/hook import 這些函式（清單附檔名） Tests covering: api.test.ts（8 例）＋ 4 個元件測試 = 安全網；profile 流程無測試 → 已標記 Risk hotspots: auth header 注入、401 重導邏輯（行為必須完全保留） Batch plan: - Batch 1/4：新增 apiClient（不改任何呼叫點）— 加法、零風險 - Batch 2/4：搬 read-only GET 端點 → apiClient - Batch 3/4：搬含 auth 的 POST/PUT（高風險批，逐一比對 header） - Batch 4/4：刪除舊裸 fetch + 死碼 每批結束：編譯通過、測試綠、單一 commit。 → 等你核准計畫，我再開始 Phase 2。
Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.