別再問 AI「能不能做」：提示詞全文＋規格書範本＋SOP 範本＋資安稽核清單

直播《別再問 AI「能不能做」——讓 AI 交出可審查產物的四個提問轉換》學員資料包。 這四招與模型無關，改的是提問結構，不是模型能力。任何主流模型都適用。 【　】內是你要自行替換的內容。

這份資料包怎麼用

每一站都是「一段提示詞 ＋ 一份空白範本」的組合：提示詞負責讓 AI 交出東西，範本負責讓你檢查它交得對不對。

建議用法：把範本貼給 AI，要求它照格式填，空著的欄位不准跳過，要寫「不適用」並說明理由。欄位填不滿的地方，就是你這個專案還沒想清楚的地方。

0. 四句型總表

共通點只有一個：你要求了一份別人可以審查的東西。可行性報告可以被打槍、開發計畫可以被改、測試會紅、稽核表有覆蓋率。「可以做」不行。

站 1｜想法期：可行性評估報告

用在：你有一個想法、還沒動手。

1-1 可行性評估提示詞

關鍵句：最後一句是整段最值錢的地方，它逼 AI 承認自己的極限。它承認的那三件事，通常就是你該優先驗證的。

針對以下需求，幫我做一份可行性評估報告：
【貼上需求描述】

報告需包含：
1. 技術可行性：現有技術能否達成，需要哪些關鍵元件
2. 難易度分級：把需求拆成子項目，每項標 S / M / L 並說明理由
3. 風險與未知數：哪些地方我現在無法確定，可能會爆的點在哪
4. 前置資源：需要的環境、帳號、授權、資料、外部服務
5. 建議驗證順序：哪一塊最不確定，該先用半天做個丟棄式小原型（spike）證明走得通，為什麼是它

最後請標出：你對這份評估最沒把握的三件事。

為什麼有效：「能不能做」是 yes/no 題，模型有討好傾向（Sycophancy），幾乎永遠答「可以」。指定產出格式，它才非攤開不可。

1-2 可行性評估報告範本

把這份範本連同需求描述一起丟給 AI，要求它照格式填；填完你自己再看一次「第 7 節」，那三件事就是你這週該優先驗證的東西。

# 【功能名稱】可行性評估報告

## 1. 需求摘要

- 功能名稱：
- 目標使用者：
- 要解決的問題：
- 明確不包含（本次不做）：

## 2. 技術可行性

| 子項目 | 需要的資料／介面 | 可行性 | 判斷依據 |
|---|---|---|---|
|  |  |  |  |

## 3. 難易度分級

| 子項目 | S／M／L | 分級理由 | 需要先驗證嗎？ |
|---|---|---|---|
|  |  |  |  |

## 4. 風險與未知數

| 未知數 | 若判斷錯誤的影響 | 目前假設 | 驗證方式 |
|---|---|---|---|
|  |  |  |  |

## 5. 前置資源

- 執行環境：
- 權限／帳號：
- 測試資料：
- 外部服務：
- 需要閱讀的規格或來源：

## 6. 建議驗證順序

| 順序 | Spike（丟棄式小原型） | 輸入 | 預期結果 | 失敗後的決策 |
|---:|---|---|---|---|
| 1 |  |  |  |  |
| 2 |  |  |  |  |

## 7. 我最沒把握的三件事

1.
2.
3.

難易度分級的判準：S＝照現有做法就能完成；M＝要查資料或整合，但走得通；L＝有沒解過的未知數，必須先做 spike。分不出來就標 L，不要樂觀。

站 2｜設計期：選型分析 → 開發計畫

用在：確定要做了，但還沒開始寫。 順序：① 選型分析 → ② 開發計畫 → ③ 才實作。不要一開口就指定技術棧。

2-1 選型分析

關鍵句：「我的限制是」四個欄位。沒有限制的選型建議等於沒建議。最後一句要它交出推薦的有效邊界。

我要做【需求】。我的限制是：
- 開發環境：【例：Windows + PowerShell】
- 團隊技能：【例：熟 Java，前端只有一人】
- 部署環境：【例：公司內網，不能連外】
- 時程與人力：【…】

請列出 2-4 個可行的技術選型方案，每個方案說明：
優點、缺點、適用情境、在我上述限制下的契合度。
最後給出你的推薦與理由，並說明什麼情況下你會改推薦別的方案。

2-2 技術選型比較表範本

要求 AI 把選型結果填進這張表。重點在最後一段「有效邊界」：一個沒有邊界的推薦，等於它只是挑了個最常見的答案給你。

# 【需求名稱】技術選型比較表

## 我的限制

| 類別 | 本專案的限制 | 若這條限制改變，會影響什麼？ |
|---|---|---|
| 開發環境 |  |  |
| 團隊技能 |  |  |
| 部署環境 |  |  |
| 時程與人力 |  |  |
| 資料與整合 |  |  |

## 候選方案

| 方案 | 核心作法 | 優點 | 缺點 | 在我限制下的契合度 | 適用情境 |
|---|---|---|---|---|---|
| A |  |  |  |  |  |
| B |  |  |  |  |  |
| C |  |  |  |  |  |

## 推薦與有效邊界

- 推薦方案：
- 推薦理由：
- 什麼情況下我會改推薦別的方案？
  1. 若【條件】成立 → 改推薦【方案】，因為【理由】
  2.
  3.

2-3 開發計畫

關鍵句：「先不要寫程式碼」。計畫是便宜的中間產物，計畫改一行，程式碼改一天。第 4 項讓驗收標準直接變成測試案例清單，站 3 的紅燈就是從這張清單來的。

採用【選定方案】。請寫一份開發計畫：
1. 模組拆解：每個模組的職責與相依關係
2. 里程碑：分幾個階段，每階段的產出是什麼
3. 每階段的驗收標準：怎樣算做完（要可驗證，不要「功能正常」這種寫法）
4. 每階段用 TDD 進行：把該階段的驗收標準直接寫成測試案例清單（測試名稱＝驗收標準），實作順序是先讓測試紅、再做到綠
5. 風險點與對應的先行驗證

先不要寫程式碼。

驗收標準的寫法：每一條都要能打勾。例如「空專案回 0」「三個任務完成一個回 1/3」「A→B→A 的循環相依被拒絕」。不要寫「功能正常」。

2-4 開發計畫書範本

這份填完就是你的規格書。最後一節「明確不做」不要留白——寫不出來，通常代表範圍還沒收斂。

# 【專案名稱】第一階段開發計畫

## 採用方案

- 選定方案：
- 決策依據（連結到選型比較表）：

## 模組拆解

| 模組 | 職責 | 輸入 | 輸出 | 相依模組 |
|---|---|---|---|---|
|  |  |  |  |  |

## 里程碑

| 里程碑 | 工作內容 | 產出 | 驗收方式 | 風險與先行驗證 |
|---|---|---|---|---|
| M1 |  |  |  |  |
| M2 |  |  |  |  |
| M3 |  |  |  |  |

## 驗收標準（＝測試案例清單）

每一條用「當……，執行……，應該……」寫，寫完直接當成測試名稱。

| # | 當（前提） | 執行（動作） | 應該（預期結果） | 證據 | 對應測試名稱 |
|---:|---|---|---|---|---|
| 1 |  |  |  |  |  |
| 2 |  |  |  |  |  |
| 3 |  |  |  |  |  |

## 風險點與先行驗證

| 風險 | 影響 | 先行驗證方式 | 何時做 |
|---|---|---|---|
|  |  |  |  |

## 明確不做

-
-

這張表怎麼接到站 3：「對應測試名稱」那一欄直接複製給 AI，就是站 3-1 的測試清單來源。驗收標準寫得夠具體，紅燈才紅得有意義。

站 3｜開發驗收期：TDD → E2E → SOP

用在：開發中到完工驗收。測試不是事後動作，從第一分鐘就開始，結束時留下三樣東西。

3-1 開發時就 TDD

關鍵句：最後一句約束不能少。沒有它，AI 會一口氣寫完然後告訴你「測試都過了」。 紅燈要確認：失敗原因是「功能未實作」，不是打錯字或環境問題，否則紅得沒有意義。

用 TDD 實作【功能】：
1. 先寫測試，跑一次，讓我看到它是紅的（失敗訊息貼給我）
2. 再寫最小實作讓測試轉綠
3. 最後重構，重構後測試必須維持綠

測試要涵蓋：正常路徑、邊界值、錯誤分支。
在我確認紅燈之前，不要寫實作程式碼。

為什麼要先寫測試：AI 寫完程式再補測試，會寫出「證明自己對」的測試，拿它驗證等於它自己驗證自己。先寫測試，測試就是規格。

3-2 完工後 E2E

關鍵句：「寫成可重跑的腳本檔」「不要用一次性的互動指令」。一次性指令跑完就沒了，腳本是資產。

用 Playwright 幫我寫 e2e 測試腳本，涵蓋這幾條使用者流程：
【流程 1】【流程 2】【流程 3】

要求：
- 寫成可重跑的腳本檔，放在 e2e/ 目錄下，加中文註解說明用途
- 不要用一次性的互動指令
- 每個腳本可獨立執行，失敗時輸出足以定位問題的訊息

3-3 把截圖變成 SOP

同一次執行，一份給機器看，一份給人看。SOP 永遠跟程式同步，因為它是從實際跑過的畫面生出來的。

在 e2e 腳本的每個關鍵步驟後加上截圖，存到 e2e/screenshots/ 並依步驟編號命名。
跑完後，用這批截圖幫我產出一份操作 SOP 文件：
每個步驟一張圖 + 操作說明 + 預期結果 + 常見錯誤。
輸出成 Markdown。

3-4 SOP 範本

把這份範本連同截圖一起丟給 AI，它會照格式填。流程改了就重跑 E2E，再重生一次 SOP。

# 【功能名稱】操作 SOP

## 使用前提

- 環境：
- 版本：
- 測試資料：

## 步驟

### Step 1｜【步驟名稱】

![Step 1](e2e/screenshots/step-01.png)

- 操作：
- 預期結果：
- 常見錯誤：
- 回復方式：

### Step 2｜【步驟名稱】

![Step 2](e2e/screenshots/step-02.png)

- 操作：
- 預期結果：
- 常見錯誤：
- 回復方式：

（依步驟數量重複，每步一張圖）

## 流程變更時

1. 先改測試、重跑 E2E 取得新截圖。
2. 用新截圖重生本文件。
3. 不要手改截圖或文字，避免文件與畫面分叉。

站 4｜上線前：基準式資安稽核

用在：要上線了。 關鍵句：「沒命中的項目也要列出，並說明為什麼不適用」。只列命中項目的報告，你無法判斷它查得仔細還是只挑好講的講。有清單才有覆蓋率，報告才可以被審查。

4-1 第一層：我寫的程式碼

對照 OWASP Top 10:2025 與 CWE Top 25（2025 版）逐項檢查這份程式碼，
輸出表格：分類代號、是否命中、程式位置、風險等級、修補建議。
沒命中的項目也要列出，並說明為什麼不適用。

版本要注意：OWASP Top 10 在 2025 年 11 月發表新版、2026 年 1 月定版。新增 A03 軟體供應鏈失效、A10 例外狀況處理不當，SSRF 併入 A01。拿 2021 年的清單去問，會整整漏掉供應鏈與例外處理兩塊。

4-2 第二層：我用的第三方元件

列出本專案所有相依套件與版本，逐一查有無已知 CVE，
標出 CVSS 分數、影響說明與建議升級版本，依風險排序。

0 漏洞的意思是「今天乾淨」。沒有任何機制會在明天有新漏洞時通知你。把 npm audit 或對應工具排進 CI，不要只跑一次。

4-3 資安稽核清單：OWASP Top 10:2025

來源：OWASP Top 10:2025。稽核時逐項打勾，未命中要寫理由。

4-4 資安稽核清單：CWE Top 25:2025

來源：MITRE CWE 2025 Top 25，官方頁面更新日期 2025-12-15。Rank 與 Score 是基準清單的資料，不是你專案的漏洞判定。

4-5 稽核報告範本

把這份範本連同程式碼一起給 AI，要求它照表填，不准跳過未命中列。

# 基準式安全稽核報告

## 報告資訊

- 專案／版本：
- 執行日期與時區：
- 稽核者：
- 基準清單版本：OWASP Top 10:2025、CWE Top 25:2025
- 執行命令：

## OWASP／CWE 稽核表

| 基準代號 | 是否命中 | 程式位置 | 證據 | 風險／影響 | 修補建議 | 不適用／未命中原因 |
|---|---|---|---|---|---|---|
| A01:2025 |  |  |  |  |  |  |
| …（十類與 CWE 逐列，不可省略未命中列） |  |  |  |  |  |  |

## 相依套件稽核

| 套件 | 版本 | 直接／間接 | CVE | CVSS 分數 | 修補版本 | 判斷 |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

## 重現證據

- 重現命令：
- 修補前結果：
- 修補內容：
- 修補後結果：
- 回歸測試：

## 限制與未完成項目

- 本報告沒有執行：
- 仍需人工或專業團隊確認：
- 下一步：

4-6 誠實界線

AI 稽核取代不了滲透測試。它沒有實際嘗試組合攻擊路徑、沒有測競爭條件、沒有驗證商業邏輯能不能被繞過。它的價值是便宜的第一道網，在你花錢請人測之前先把明顯的東西掃掉。

稽核全綠不等於安全，只等於「清單上的項目都看過了」。全綠的稽核報告通常代表查得不夠仔細。

修補原則：資訊不是消失，是換了去處。錯誤細節從回應裡拿掉，完整訊息（含路徑與 stack）進日誌。先開日誌再改回應，否則等於把問題變成靜默失敗。

附錄｜常見問題

完整課程：AI 賦能全端開發：從零打造企業級智慧應用