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

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

## 這份資料包怎麼用

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

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

| 站 | 提示詞 | 對應範本 | 這份範本在課程裡叫什麼 |
|---|---|---|---|
| 站 1 想法期 | 1-1 | 1-2 可行性評估報告 | 規格書：需求面 |
| 站 2 設計期 | 2-1、2-3 | 2-2 技術選型比較表、2-4 開發計畫書 | 規格書：設計面 |
| 站 3 開發驗收 | 3-1～3-3 | 3-4 操作 SOP | SOP 範本 |
| 站 4 上線前 | 4-1、4-2 | 4-3／4-4 稽核清單、4-5 稽核報告 | 資安稽核清單 |

---

## 0. 四句型總表

| 階段 | ❌ 別這樣問 | ✅ 這樣問 | 你拿到的產物 |
|---|---|---|---|
| 想法期 | 這個能不能做？ | 做一份可行性評估報告，含難易度分級、風險、驗證順序 | 可審查的報告＋它最沒把握的三件事 |
| 設計期 | 幫我寫一個 X | 先選型分析 → 再開發計畫（每階段用 TDD） → 才實作 | 選型比較表＋里程碑與驗收標準（＝測試案例清單） |
| 開發驗收 | 幫我測試有沒有問題 | TDD 紅綠重構 → Playwright 腳本 → 截圖生 SOP | 測試、可重跑腳本、操作手冊 |
| 上線前 | 幫我看有沒有漏洞 | 對照 OWASP／CWE 逐項稽核，含未命中原因 | 有覆蓋率的稽核表 |

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

---

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

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

### 1-1 可行性評估提示詞

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

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

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

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

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

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

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

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

## 1. 需求摘要

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

## 2. 技術可行性

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

## 3. 難易度分級

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

## 4. 風險與未知數

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

## 5. 前置資源

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

## 6. 建議驗證順序

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

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

1.
2.
3.
```

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

---

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

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

### 2-1 選型分析

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

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

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

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

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

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

## 我的限制

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

## 候選方案

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

## 推薦與有效邊界

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

### 2-3 開發計畫

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

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

先不要寫程式碼。
```

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

### 2-4 開發計畫書範本

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

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

## 採用方案

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

## 模組拆解

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

## 里程碑

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

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

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

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

## 風險點與先行驗證

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

## 明確不做

-
-
```

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

---

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

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

### 3-1 開發時就 TDD

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

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

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

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

### 3-2 完工後 E2E

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

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

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

### 3-3 把截圖變成 SOP

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

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

### 3-4 SOP 範本

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

```markdown
# 【功能名稱】操作 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 第一層：我寫的程式碼

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

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

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

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

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

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

來源：[OWASP Top 10:2025](https://owasp.org/Top10/)。稽核時逐項打勾，未命中要寫理由。

| 代號 | 類別 | 中文說明 | 命中 | 未命中原因 |
|---|---|---|:---:|---|
| A01:2025 | Broken Access Control | 存取控制失效（含 SSRF） | ☐ | |
| A02:2025 | Security Misconfiguration | 安全設定錯誤 | ☐ | |
| A03:2025 | Software Supply Chain Failures | 軟體供應鏈失效（2025 新增） | ☐ | |
| A04:2025 | Cryptographic Failures | 加密機制失效 | ☐ | |
| A05:2025 | Injection | 注入攻擊 | ☐ | |
| A06:2025 | Insecure Design | 不安全的設計 | ☐ | |
| A07:2025 | Authentication Failures | 身分驗證失效 | ☐ | |
| A08:2025 | Software or Data Integrity Failures | 軟體或資料完整性失效 | ☐ | |
| A09:2025 | Security Logging and Alerting Failures | 安全日誌與告警失效 | ☐ | |
| A10:2025 | Mishandling of Exceptional Conditions | 例外狀況處理不當（2025 新增） | ☐ | |

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

來源：[MITRE CWE 2025 Top 25](https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html)，官方頁面更新日期 2025-12-15。Rank 與 Score 是基準清單的資料，不是你專案的漏洞判定。

| Rank | CWE | 官方名稱 | 命中 | 未命中原因 |
|---:|---|---|:---:|---|
| 1 | CWE-79 | Cross-site Scripting (XSS) | ☐ | |
| 2 | CWE-89 | SQL Injection | ☐ | |
| 3 | CWE-352 | Cross-Site Request Forgery (CSRF) | ☐ | |
| 4 | CWE-862 | Missing Authorization | ☐ | |
| 5 | CWE-787 | Out-of-bounds Write | ☐ | |
| 6 | CWE-22 | Path Traversal | ☐ | |
| 7 | CWE-416 | Use After Free | ☐ | |
| 8 | CWE-125 | Out-of-bounds Read | ☐ | |
| 9 | CWE-78 | OS Command Injection | ☐ | |
| 10 | CWE-94 | Code Injection | ☐ | |
| 11 | CWE-120 | Classic Buffer Overflow | ☐ | |
| 12 | CWE-434 | Unrestricted Upload of File with Dangerous Type | ☐ | |
| 13 | CWE-476 | NULL Pointer Dereference | ☐ | |
| 14 | CWE-121 | Stack-based Buffer Overflow | ☐ | |
| 15 | CWE-502 | Deserialization of Untrusted Data | ☐ | |
| 16 | CWE-122 | Heap-based Buffer Overflow | ☐ | |
| 17 | CWE-863 | Incorrect Authorization | ☐ | |
| 18 | CWE-20 | Improper Input Validation | ☐ | |
| 19 | CWE-284 | Improper Access Control | ☐ | |
| 20 | CWE-200 | Exposure of Sensitive Information | ☐ | |
| 21 | CWE-306 | Missing Authentication for Critical Function | ☐ | |
| 22 | CWE-918 | Server-Side Request Forgery (SSRF) | ☐ | |
| 23 | CWE-77 | Command Injection | ☐ | |
| 24 | CWE-639 | Authorization Bypass Through User-Controlled Key | ☐ | |
| 25 | CWE-770 | Allocation of Resources Without Limits or Throttling | ☐ | |

### 4-5 稽核報告範本

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

```markdown
# 基準式安全稽核報告

## 報告資訊

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

## OWASP／CWE 稽核表

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

## 相依套件稽核

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

## 重現證據

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

## 限制與未完成項目

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

### 4-6 誠實界線

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

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

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

---

## 附錄｜常見問題

| 問題 | 回答 |
|---|---|
| 用哪個模型？ | 四招與模型無關，改的是提問結構。 |
| 小專案也要這樣做？ | 站 1、站 2 可以壓縮成一句話。站 3 的 TDD 小專案反而更划算，紅綠循環快。 |
| 這樣不是很花時間？ | 站 1、2 加起來約 30 分鐘，換掉的是「做到一半發現方向錯」的那幾天。 |
| AI 產出的計畫不準怎麼辦？ | 那正是它有價值的地方。計畫寫在紙上你才看得出不準；程式寫完才發現，成本差一個數量級。 |
| agentic coding 跟一般用 ChatGPT 差在哪？ | 一問一答是你當代理；agentic coding 是 AI 當代理跑完「規劃 → 生成 → 驗證 → 修正」，你負責審查每站的產物。 |

完整課程：[AI 賦能全端開發：從零打造企業級智慧應用](https://hahow.in/cr/ai-full-stack)