目標分解
描述
將複雜目標分解為可執行檢查點的最佳實踐。
觸發詞
- goal
- plan
- long-term
- multi-step
- project
- achieve
- milestone
指令
分解原則
- 具體勝於抽象 — 每個檢查點應產出有形的產出物或可驗證的成果，而非「思考 X」
- 3-10 個檢查點 — 太少表示檢查點過於複雜；太多則增加負擔
- 研究先行 — 第一個檢查點應始終收集資訊
- 驗證後再繼續 — 將驗證步驟納入 success_criteria，而非獨立成檢查點
- 前端加載未知項 — 將不確定/高風險的檢查點放在前面，以便早期失敗成本較低
成功標準規則
- 必須是客觀可驗證的 —「檔案存在於路徑 X」、「找到 3 個職位」、「測試通過」
- 無主觀標準 — 避免「品質良好」、「文筆流暢」
- 盡可能包含數量 —「至少 3 個」、「少於 500 字」
何時修訂
- 新資訊使假設無效（公司不招聘）
- 某檢查點顯示計劃遺漏步驟
- 使用者回饋改變方向
- 連續 2 個以上檢查點失敗，表示方法有誤
反模式
- 不要為少於 5 次工具調用的任務創建目標
- 不要製作依賴外部時間的檢查點（「等待回覆」）— 應暫停目標並設定定時提醒以恢復
- 不要將所有複雜性集中在一個檢查點 — 若某檢查點需要 50 次以上工具調用，應進行拆分
範例
良好分解：求職
目標：「在 X 公司找到工作」
- 研究 X（文化、技術棧、近期新聞）— 標準：完成摘要撰寫
- 尋找開放職位 — 標準：列出 3 個以上職位與網址
- 客製化履歷 — 標準：履歷檔案已更新，相關技能已標註
- 起草求職信 — 標準：求職信件已創建，少於 400 字
- 提交申請 — 標準：成功提交確認頁面截圖已保存
良好分解：個人作品集網站
目標：「為我建立一個個人作品集網站」
- 研究設計趨勢並收集需求 — 標準：設計簡報已撰寫
- 設定專案（Next.js + 部署目標）— 標準：專案骨架已建立，開發伺服器可執行
- 建立核心頁面（首頁、關於、作品集）— 標準：3 個頁面可渲染，包含佔位內容
- 加入真實內容與樣式 — 標準：所有區塊已填充，行動裝置響應式正常
- 部署到生產環境 — 標準：正式網址可訪問，無控制台錯誤
良好分解：安全審計
目標：「審計此程式碼庫的安全漏洞」
- 掃描依賴項以找出已知 CVE — 標準：依賴項報告已生成
- 審查認證和會話處理 — 標準：認證流程已記錄，問題已列出
- 檢查注入漏洞（SQL、XSS、命令注入）— 標準：每個輸入路徑已測試
- 撰寫審計報告並附上嚴重性評級 — 標準：報告檔案已建立，發現已優先排序
不良分解
目標：「在 X 公司找到工作」
- 進行研究（過於模糊，無標準）
- 申請（過於廣泛，應拆分為多個步驟）
- 等待回覆（依賴外部時間）
驗證
- 此階段的交付物應以具體產出物（文件、任務單、看板、儲存庫）形式存在，且位置已被共享，而非僅以文字描述
- 每個承諾都有負責人名稱、截止日期和完成定義（可由非作者的人檢查）
- 風險已列出可能性/影響，並有命名應對措施，而非通用的「風險：待定」項目
- 對其他團隊/供應商/代理的依賴關係明確；每個依賴關係的確認已記錄，或標記為「待定」
- 下一階段的成功標準是數值化或其他客觀可測試的
- 在開始工作前，已記錄回退/中止開關/「若 X 則停止」的標準
備註
- 在創建目標前，始終檢查 goals/SKILL.md 是否相關
- 目標系統會自動處理持久性、上下文和自動繼續
- 隨時使用 goal_status 檢查進度