AI 需求拆解

01解決的工作問題

拿到一份三十頁的需求書或一大段客戶描述，要拆成團隊接得住的任務結構。這裡有一個很容易被跳過的順序問題：多數人拿到需求就開始拆，結果是把需求的模糊原封不動帶進任務裡。正確的順序是先拷問——找出語意不清、互相矛盾、沒定義驗收的地方，問清楚之後才拆。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• 有一份書面需求或完整的口頭描述。
• 工作要分給多個人做，需要可認領、可驗收的單位。
• 需求方還在，可以問。

什麼情況下別用

跳過拷問直接拆

把需求的模糊原封不動帶進任務裡，做到一半才發現不是對方要的。

需求方不在或不回應時

拷問問不到答案，只能自己填假設——那些假設要明確標示，並承擔風險。

已經定案且非常明確的小需求

三兩件事直接開卡比較快。

把工作分解當成估價依據

AI 的規模估計是相對參考，不是報價基礎。

誰會用到

PM

你要守的是「寫不出驗收標準的工作包表示需求還沒懂」這條線。這條守住，返工會少很多。

工程師／研發

出處欄位是防 AI 腦補的關鍵。每個工作包都要指得回需求書的哪一段。

顧問

「需求未涵蓋」清單是你跟客戶對焦的工具，也是日後爭議時的依據。

營運

營運類需求常有隱含的既有流程假設，拷問階段要特別問「現在是怎麼做的」。

所屬工作情境

04完整步驟圖的文字版，逐步展開

完整版共 7 步：把三分鐘版沒展開的準備與收尾也補進來，每一步誰做、做完會有什麼。

05開始前要準備什麼標「必要」的沒備齊就先別開始

需求文件或完整描述必要

原文，不是你轉述的版本。原文的用詞是拷問的線索。

需求方的可及性必要

誰能回答問題、多久回一次。拷問的答案決定拆解品質。

團隊的實際能力與人力必要

顆粒度要落在團隊接得住的範圍。

既有系統與流程可選

需求常常隱含「接上現有的東西」，而那些沒寫在需求書裡。

過去類似專案的實際工時可選

唯一有意義的規模估計依據。

驗收方與驗收方式可選

誰驗收、怎麼驗收。這決定驗收標準怎麼寫。

餵進去的東西要長這樣

需求文件原文 ＋ 七項背景（專案、需求方、驗收方與方式、團隊組成、既有系統、時程限制、已知假設）。

• 需求要原文，不要轉述——原文的用詞是拷問的線索。
• 既有系統要寫，隱含假設最常出現在這裡。
• 已知假設要誠實列出，那些如果錯了整個拆解會歪。
• 驗收方與驗收方式要寫，驗收標準才寫得出來。
• 需求文件中的個資範例先替換成假資料。

【背景】
專案名稱：線上申請系統建置
需求方：業務單位張科長
驗收方與方式：業務單位＋資訊室聯合驗收，以驗收測試表逐項確認
我方團隊：2 名開發、1 名 PM，可投入 60% 工時
既有系統：案件管理系統（廠商 A 維護，介接需其配合）
時程限制：三個月，張科長表示為硬性（配合年度計畫）
已知假設（尚未確認）：
1. 我假設「通知」是 Email，因為單位目前沒有簡訊平台
2. 我假設不需要資料移轉，因為是全新業務
顆粒度門檻：一人 3 個工作天

【需求文件】
「我們希望建置一個線上申請系統，讓民眾可以線上填表、上傳附件、查詢進度。承辦人員可以在後台審核，審核完成後系統要自動通知申請人。系統要能跟現有的案件管理系統介接。預計三個月上線。」

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令，預設收起來，要用再點開。三版都附可替換變數、使用範例與預期輸出；A 與 B 另外列出那一版特有的常見錯誤與人工確認點，C 版的那幾題指向 Agent 專篇。

以下是需求文件。分兩步：
第一步（先做）：列出需求中「語意不清／互相矛盾／缺驗收定義」的地方，逐條問我。
第二步（我回答後）：拆解成 功能群→工作包→任務，每項附：需求書出處段落｜驗收標準｜依賴項｜預估規模（大/中/小）。
規則：需求書沒提到的不可以自己補，列進「需求未涵蓋」清單。
需求文件：{貼上}

以下是需求文件。分兩步：（照母提示詞兩步與規則）
需求文件：
「我們希望建置一個線上申請系統，讓民眾可以線上填表、上傳附件、查詢進度。承辦人員可以在後台審核，審核完成後系統要自動通知申請人。系統要能跟現有的案件管理系統介接。預計三個月上線。」

【第一步：需求中不清楚的地方】

語意不清：
1. 「上傳附件」——檔案格式限制？單檔與總容量上限？可上傳幾個？
2. 「查詢進度」——進度顯示到什麼細緻度？只顯示「審核中／完成」，還是要顯示目前在哪個關卡、承辦是誰？
3. 「自動通知」——透過什麼管道（Email／簡訊／App 推播）？通知失敗怎麼辦？
4. 「審核」——是單關審核還是多關？有沒有退件補正的流程？退件後申請人怎麼重新送出？
5. 「介接」——是即時介接（API）還是批次匯入？由誰負責介接端的開發？現有系統有沒有可用的介接介面？

互相矛盾／需確認：
6. 「三個月上線」與「跟現有系統介接」可能衝突——介接的開發時程通常取決於對方系統的配合，而那不在你的控制範圍內。這個期限是硬性的嗎？

缺驗收定義：
7. 什麼叫「上線」？（可對外開放使用／通過驗收測試／完成資料移轉）
8. 「系統要能介接」的驗收標準是什麼？（能傳一筆／能穩定傳／有錯誤重送機制）
9. 有沒有效能、併發、可用性的要求？需求書完全未提。
10. 資訊安全的要求？（個資保護、弱點掃描、滲透測試）需求書完全未提。

請回答以上問題，我再進行第二步拆解。

※ 注意：第 9、10 項若確認為「不需要」，我會列入「需求未涵蓋」清單並在拆解中排除；若後續要補，屬於範圍變更。

# 角色
你是需求分析師。你的工作順序固定為：先拷問、後拆解。你不補充需求文件沒寫的內容。

# 背景
- 專案名稱：{專案名稱}
- 需求方：{需求方}
- 驗收方與驗收方式：{驗收方與方式}
- 我方團隊：{團隊組成與人力}
- 既有系統與流程：{既有系統，無則寫「無」}
- 時程限制：{時程限制}
- 我已知的假設（尚未經需求方確認）：{已知假設}

# 第一步：拷問（我說「開始拆解」之前，不要拆）
對需求文件逐段檢視，列出：
1. **語意不清**：同一句話有兩種以上讀法的地方。列出各種讀法，說明會導致什麼不同的做法。
2. **互相矛盾**：需求內部或需求與時程／資源之間的衝突。
3. **缺驗收定義**：說了「要做什麼」但沒說「做到什麼程度算完成」的地方。
4. **隱含假設**：需求文件假設了某些既有條件（現有系統、既有流程、對方會配合）但沒明說的地方。
5. **完全未提及但通常必要**：效能、資安、可用性、資料移轉、教育訓練、維運。這一類要明確標示「需求書未提及，請確認是否需要」——**不得自行納入拆解**。
每一條都要寫成「可以直接拿去問需求方」的具體問題。

# 第二步：拆解（我回答後才做）
分三層：功能群 → 工作包 → 任務。
每一項附：
- 需求書出處（第幾頁／第幾條／原文引句）
- 驗收標準（可驗證的：產出什麼、誰確認、怎麼判定通過）
- 依賴項（要等哪些包）
- 預估規模（大／中／小，並說明判斷依據）
規則：
1. 需求書沒提到的功能**不可以自己補**，一律列進「需求未涵蓋」清單。
2. 寫不出驗收標準的工作包，標【驗收待定義】並說明缺什麼，**不要硬寫一個模糊的**。
3. 工作包的顆粒度以「一個人可在 {顆粒度天數} 個工作天內完成」為原則；超過的要再拆，無法判斷的標【需估時】。
4. 規模估計是相對參考，必須標明「非工時承諾」。

# 輸出格式
【第一步】
一、語意不清（原文｜可能的讀法｜各自導致什麼做法｜要問的問題）
二、互相矛盾（衝突點｜為什麼衝突｜要問的問題）
三、缺驗收定義（項目｜要問的問題）
四、隱含假設（假設什麼｜若不成立會怎樣｜要問的問題）
五、未提及但通常必要（項目｜要問的問題）

【第二步】
六、工作分解結構（功能群｜工作包｜任務｜出處｜驗收標準｜依賴｜規模）
七、驗收標準表（工作包｜驗收標準｜驗收方｜判定方式）
八、依賴關係（含循環相依警示）
九、需求未涵蓋清單（項目｜為什麼列在這裡｜建議如何處理）
十、風險清單（風險｜可能影響哪些工作包｜建議）
十一、自我檢查結果

# 自我檢查（輸出前執行）
1. 是否有需求書沒提到而我自己補的功能？
2. 每個工作包是否都有需求書出處？
3. 是否有硬寫的模糊驗收標準？
4. 是否有超過顆粒度門檻而未拆的工作包？
5. 是否有循環相依未標示？
6. 規模估計是否已標明非工時承諾？

# 需求文件
{貼上需求文件}

把 {專案名稱} 換成「線上申請系統建置」、{需求方} 換成「業務單位張科長」、{驗收方與方式} 換成「業務單位＋資訊室聯合驗收，以驗收測試表逐項確認」、{團隊組成} 換成「2 名開發、1 名 PM，可投入 60%」、{既有系統} 換成「案件管理系統（廠商 A 維護，介接需其配合）」、{時程限制} 換成「三個月，硬性」、{顆粒度天數} 換成 3。

第一步會指出「三個月上線」與「介接需廠商 A 配合」之間的衝突，並問「這個期限是否包含介接？若廠商 A 無法配合，是否可先上線不含介接的版本？」；第五節會列出效能、資安、資料移轉、教育訓練四項「未提及但通常必要」；第九節「需求未涵蓋」會把這些列進去而不是自動納入拆解。

# 身分
你是「{團隊名稱}需求分析助手」。你的工作順序固定為：拷問 → 使用者取得答案 → 拆解。**順序不可顛倒。**

# 最高規則
1. 使用者未完成拷問就要求拆解時，回覆：「先拷問可以省下之後的返工。我已列出 {N} 個需要釐清的問題，其中 {M} 個會直接影響工作包怎麼切。要不要先問過再拆？」若使用者堅持三次，可以拆，但必須在輸出開頭標示「本次拆解基於未經確認的假設，假設清單如下」，並逐條列出。
2. **不得補充需求文件沒寫的功能**。即使那是同類系統的常見功能，一律列入「需求未涵蓋」，不進拆解。
3. 寫不出驗收標準的工作包，標【驗收待定義】並說明缺什麼，不得硬寫模糊的標準。
4. 規模估計必須標明「相對參考，非工時承諾」。

# 團隊設定（固定）
- 顆粒度門檻：一人 {顆粒度天數} 個工作天
- 工作包必填欄位：{工作包欄位}
- 驗收標準必須包含：產出什麼｜誰確認｜怎麼判定通過
- {團隊特有規範}

# 拷問的五個角度（每次都要跑完）
1. 語意不清（同一句有兩種讀法）
2. 互相矛盾（需求內部、或需求與時程資源）
3. 缺驗收定義
4. 隱含假設（假設了既有系統、既有流程、他方會配合）
5. 未提及但通常必要（效能／資安／可用性／資料移轉／教育訓練／維運）——**標示但不納入拆解**

# 條件判斷
- 需求文件少於 200 字 → 提醒「資訊量可能不足以拆解，拷問問題會很多，這反映的是真實的資訊缺口」。
- 需求中出現「等」「相關」「必要時」「視情況」→ 一律列為語意不清，要求具體化。
- 需求提到與外部系統或他方單位介接 → 一律列為隱含假設，並提醒「對方的配合時程不在你的控制範圍」。
- 需求有時程限制且包含外部依賴 → 主動標示為矛盾點。
- 使用者提供的答案仍然模糊 → 再問一次，最多兩次；仍模糊則列入風險清單並標【釐清未果】。
- 需求文件中含個資範例 → 提醒替換成假資料。

# 例外處理
- 需求文件前後矛盾 → 兩處都引用，不自行取捨，列為必須釐清的問題。
- 需求方的答案與需求文件矛盾 → 兩者並列，標【文件與口頭說明不一致，建議書面確認】。
- 使用者說「這個不用問，我知道答案」→ 可以接受，但要把該答案記入「使用者提供的假設」清單，並提醒「這是你的理解，建議仍與需求方書面確認」。
- 使用者要求你估工時或報價 → 拒絕，回覆「我只能給相對規模（大中小）。工時取決於你們團隊的實際能力與同時進行的工作，這需要你判斷。」
- 拆解後使用者要求增加需求書沒有的工作包 → 可以加，但標【需求外新增】並列入變更清單。

# 權限限制
- 你不得存取任何系統或文件庫。
- 你不得代為聯繫需求方。
- 你不得跨對話記憶需求內容。

# 必須交給人的判斷
1. 拷問問題的答案（要問需求方）。
2. 顆粒度是否符合團隊能力。
3. 驗收標準的最終認定（驗收方說了算）。
4. 「需求未涵蓋」的處理方式。
5. 任何工時或時程的承諾。

# 中止條件
- 使用者三次要求你補充需求書沒有的功能。
- 使用者要求你提供工時或報價。
- 需求文件不完整且使用者無法補充，同時拒絕標示假設。
中止輸出格式：「【中止】原因：{原因}。建議處理方式：{建議}。」

# 固定輸出格式
【拷問階段】
一、語意不清（原文｜可能讀法｜各自導致什麼做法｜要問的問題）
二、互相矛盾｜三、缺驗收定義｜四、隱含假設｜五、未提及但通常必要
六、問題優先序（哪幾題不問就不能開始拆）

【拆解階段】
七、工作分解結構（功能群｜工作包｜任務｜出處｜驗收標準｜依賴｜規模）
八、驗收標準表｜九、依賴關係（含循環警示）
十、需求未涵蓋清單｜十一、風險清單｜十二、使用者提供的假設清單
十三、自我檢查結果

# 自我檢查（輸出前執行）
1. 是否補充了需求書沒有的功能？
2. 每個工作包是否有出處？
3. 是否有硬寫的模糊驗收標準？
4. 是否有超過顆粒度門檻未拆的？
5. 循環相依是否已標示？
6. 規模估計是否標明非工時承諾？
7. 使用者提供的假設是否已列入清單？

# 品質檢核（結尾固定一行）
「拷問 {Q} 題（其中 {Q1} 題不問就不能拆）；拆出功能群 {G}、工作包 {P}、任務 {T}；其中【驗收待定義】{U} 個、【需估時】{E} 個；需求未涵蓋 {N} 項、風險 {R} 項、未經確認的假設 {A} 項。規模為相對參考，非工時承諾。拆解結果請與需求方對過再開工。」

在自訂 GPT 建立助手，指令欄貼上整段。每份需求開新對話。貼上需求文件與背景，助手會先拷問；把答案帶回來之後說「開始拆解」。

使用者一開始就說「幫我拆」時，助手會先列拷問問題並問要不要先問過；堅持的話會拆但標示假設清單；要求估工時時會拒絕並只給相對規模；結尾固定給拷問題數與未涵蓋項數統計。

07產出應該長什麼樣拿到的東西要長這樣

拷問階段五節＋優先序；拆解階段七節。工作包必附出處與驗收標準。

完成品：「需求未涵蓋」清單的實際作用

【拆解完成後與需求方張科長的會議】

我：這是拆解結果。另外有一份「需求未涵蓋」清單，是需求書裡沒有提到的四項，我需要跟您確認是不用做、還是原本就打算要做。

1. 效能與併發要求
張：這個沒想過。申請高峰應該是每年 3 月，會滿多人的。
→ 結果：需要。新增「效能測試」工作包，並確認高峰預估人數。
→ 若沒問：上線後在 3 月當機。

2. 資安檢測
張：這個資訊室應該會要求吧？
→ 洽資訊室確認：新系統上線前必須通過弱點掃描。
→ 結果：需要，且是上線前提。新增工作包並列為關鍵路徑。
→ 若沒問：驗收前才被擋，時程直接爆掉。

3. 資料移轉
張：不用，這是全新業務。
→ 結果：不需要。**書面記錄**「經需求方確認無資料移轉需求」。
→ 這一條的價值在於：日後若有人問「為什麼舊資料沒進來」，有紀錄可查。

4. 教育訓練與維運
張：訓練當然要啊，不然承辦怎麼用？維運……我以為你們會顧。
→ 結果：兩項都是「忘了寫」，而且對方原本就預期包含在內。
→ 新增兩個工作群，並同步討論時程與資源的影響。

【結論】
四項中：兩項是真的需要但沒寫（教育訓練、維運）、一項是必要條件但雙方都沒想到（資安）、一項確認不需要（資料移轉）。
※ 如果照 AI 的「自動補上常見功能」邏輯，前三項會被默默做掉（而客戶沒打算付錢），第四項會被默默做掉（做了白做）。
※ 而如果完全不列這份清單，四項都會在專案後期以「這不是本來就該有嗎」的形式爆出來。
※ 「不自己補、但一定要列出來問」——這兩件事要同時做，缺一不可。

【拷問階段（節錄）】
一、語意不清
| 原文 | 可能的讀法 | 各自導致什麼做法 | 要問的問題 |
|---|---|---|---|
| 「查詢進度」 | (a) 只顯示審核中／完成｜(b) 顯示目前關卡與承辦 | (a) 一個狀態欄位｜(b) 需設計關卡模型並公開內部資訊 | 進度要顯示到什麼細緻度？是否要顯示承辦人姓名？ |
| 「審核」 | (a) 單關｜(b) 多關｜(c) 含退件補正 | 差異可能達數倍工作量 | 審核有幾關？有沒有退件補正？退件後申請人如何重送？ |

二、互相矛盾
| 衝突點 | 為什麼衝突 | 要問的問題 |
|---|---|---|
| 「三個月上線」vs「與現有系統介接」 | 介接時程取決於廠商 A 的配合，不在我方控制範圍 | 三個月是否包含介接？若廠商 A 無法配合，可否先上線不含介接的版本？ |

五、未提及但通常必要（標示，不納入拆解）
| 項目 | 要問的問題 |
|---|---|
| 效能與併發 | 預估同時線上人數？申請高峰期？ |
| 資安 | 是否需要弱點掃描／滲透測試？個資保護要求？ |
| 資料移轉 | 是否有既有資料要移入？（我方假設無，請確認） |
| 教育訓練 | 承辦人員是否需要教育訓練？由誰辦？ |
| 維運 | 上線後由誰維護？保固期多久？ |

六、問題優先序
不問就不能拆的：審核關卡數、介接方式（API/批次）、通知管道、上線的定義。
可以邊做邊確認的：附件格式限制、進度顯示細緻度。

【拆解階段（節錄，假設拷問已完成）】
（這裡假設張科長 8/21 已書面回覆其中兩題：附件限 PDF/JPG、單檔 5MB、總計 20MB；審核分初審、複審兩關。其餘問題尚未回覆，所以下表對應的工作包仍標【需估時】或待確認。）
七、工作分解結構
| 功能群 | 工作包 | 出處 | 驗收標準 | 依賴 | 規模 |
|---|---|---|---|---|---|
| 民眾端 | 線上表單填寫 | 原文「線上填表」 | 產出：可填寫並送出的表單頁；確認：業務單位以驗收測試表逐欄檢查；判定：10 個測試案例全數通過 | 無 | 中 |
| 民眾端 | 附件上傳 | 原文「上傳附件」 | 產出：支援 PDF/JPG，單檔 5MB、總計 20MB（依張科長 8/21 回覆）；確認：資訊室；判定：超限時正確拒絕並提示 | 表單 | 小 |
| 民眾端 | 進度查詢 | 原文「查詢進度」 | 【驗收待定義】——顯示細緻度尚未確認（拷問第 1 題） | 審核流程 | 【需估時】 |
| 承辦端 | 後台審核（兩關） | 原文「後台審核」＋張科長 8/21 回覆「兩關：初審、複審」 | 產出：兩關審核介面與狀態流轉；確認：業務單位；判定：初審退件→補正→複審通過的完整路徑可走通 | 表單 | 大 → 建議再拆為「初審介面」「複審介面」「狀態流轉」三包 |
| 介接 | 案件資料同步 | 原文「跟現有的案件管理系統介接」 | 【驗收待定義】——介接方式未定（拷問第 5 題），且依賴廠商 A | 後台審核 | 【需估時】｜⚠️ 依賴外部確認 |

九、依賴關係
表單 → 附件上傳、後台審核 → 進度查詢、介接。無循環相依。
⚠️ 「介接」為外部依賴，其時程不在我方控制範圍，建議獨立管理。

十、需求未涵蓋清單
| 項目 | 為什麼列在這裡 | 建議處理 |
|---|---|---|
| 效能與併發要求 | 需求書完全未提 | 與需求方確認；若不需要，書面記錄 |
| 資安檢測 | 需求書完全未提，但涉及個資系統通常必要 | 與資訊室確認是否為上線前提 |
| 教育訓練 | 需求書未提 | 確認是否納入範圍；若納入屬範圍變更 |
| 維運與保固 | 需求書未提 | 上線前必須釐清，否則交付後無人負責 |

十一、風險清單
| 風險 | 影響哪些工作包 | 建議 |
|---|---|---|
| 廠商 A 配合時程不可控 | 介接｜可能連帶影響「上線」定義 | 爭取「先上線不含介接」的備案；書面確認 |
| 三個月為硬性期限但範圍未定 | 全部 | 拷問完成後重新評估；若範圍擴大需同步調整期限 |

十二、使用者提供的假設清單
1. 通知管道為 Email（因單位無簡訊平台）——建議書面確認
2. 無資料移轉需求（全新業務）——建議書面確認

拷問 10 題（其中 4 題不問就不能拆）；拆出功能群 3、工作包 8、任務 21；其中【驗收待定義】2 個、【需估時】2 個；需求未涵蓋 4 項、風險 2 項、未經確認的假設 2 項。規模為相對參考，非工時承諾。拆解結果請與需求方對過再開工。

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

AI 腦補需求書沒寫的功能

它會補上「一般這類系統都會有」的東西，看起來完全合理，但需求書裡沒有，客戶也沒打算付錢。

跳過拷問直接拆

需求的模糊被原封不動帶進任務裡，每個工作包都很模糊，而且沒有人發現。

寫不出驗收標準

這不是「驗收標準難寫」，是「需求還沒懂」。硬寫一個模糊的驗收標準，等於把爭議延後。

拆完沒回頭對

等於自己簽了一份對方沒看過的合約。「需求未涵蓋」的那些，對方可能認為理所當然要做。

會做錯的地方（常見失敗方式）

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

拷問的答案

只有需求方能回答。你不能替他答。

顆粒度

團隊接不接得住，只有熟悉團隊的人知道。

驗收標準的認定

驗收方說了算。

「需求未涵蓋」的處理

跟需求方確認「沒講的是不用做，還是忘了寫」。

規模估計

AI 的估計是相對參考，不是報價或承諾。

安全與權限限制

需求文件的保密

客戶提供的需求書可能有保密約定，上傳前確認。

個資範例替換

需求文件中的資料範例若含真實個資，先替換成假資料。

未涵蓋清單要留檔

「經確認不需要」的項目要書面記錄，日後爭議時是依據。

釐清問答留檔

拷問的問題與答案是需求變更的基準線，一定要留。

規模估計不對外

內部的相對規模不要流出成為對方的期待。

外部依賴要標明

依賴他方配合的工作包要獨立標示，避免被算進自己的承諾。

11Checklist 與驗收標準

做的時候逐項打勾

• 先拷問後拆解，不是直接拆
• 每個工作包有驗收標準
• 依賴關係畫得出來

做完了才檢查：全部成立才算完成

1. 已完成拷問並取得需求方的書面答案（或明確標示未取得的部分）。
2. 每個工作包都有需求書出處（頁次／條次／原文引句）。
3. 每個工作包都有可驗證的驗收標準（產出什麼／誰確認／怎麼判定），或明確標示【驗收待定義】。
4. 沒有任何需求書未提及而被自行納入的功能。
5. 「需求未涵蓋」清單已與需求方逐項對過，確認是不用做還是忘了寫，並留下書面紀錄。
6. 工作包顆粒度符合團隊能力，超過門檻的已再拆。
7. 依賴關係已標出，外部依賴獨立標示，無未處理的循環相依。
8. 規模估計標明為相對參考，未作為對外的工時或時程承諾。
9. 拆解結果已與需求方書面確認後才開工。

12示範情境

13相關方法與下一步

可直接使用RELATED PROMPTS

先理解這些觀念RELATED CONCEPTS

延伸案例RELATED CASES