EXECUTIVE SUMMARY ｜ SA × AI 需求協作方法論 · CRM 重建專案
AI 把寫程式的成本壓下來之後，瓶頸就換到規格上了。這套做法在 CRM 走完第一輪：全面盤點、多方案比較、決策留檔、需求可追溯。 CRM 是第一個驗證場，流程本身不綁專案。
點任一組數字，看它的分母和出處。
02 ── 這套做法會產生什麼？
以下每一項都能在 CRM 專案文件裡直接點出來，分母與統計方式列在 06 的明細區。 重點不在數量，在性質：每一項都標明了決策者、分母與出處，所以換人接手也接得下去。
60題
已結案需求議題
議題台帳逐列計數。每題含決策者、承辦、結論、日期與複審條件。
需求爭議不會拖到開發後才吵
164條
GWT 驗收情境
分母＝8 個業務規格模組。正向與反向動線都寫成前提／動作／預期結果。
測試可以直接照規格驗，不用再翻譯一次需求
156個
穩定需求 ID
可反查一項需求影響哪些規格與測試，細拆見明細。
改一條規則前，先估得出影響範圍
21份
正式規格文件
共 11,897 行。業務規格 8 ＋ 資料規格 8 ＋ 通則 ＋ 參數值域 ＋ 共用 2。
規格寫得越完整，AI 產出來的程式越穩
10頁
可操作雛形
涵蓋銷售主線全模組，業務可用真實工作情境直接操作。
使用者看得到、摸得到，才給得出真意見
5輪
結構化確認單
08-07／08-12／08-20／08-24／09-03，每輪可勾選、可下載回覆檔。
使用者答得出來，不用一直開會
35天
連續變更歷程
首筆變更紀錄（07-31）至統計日（09-03），記錄改了什麼以及為什麼改。
人員異動時，交接不會斷
隨時
全局盤點能力
任何時間都能答出未定案題數與卡點歸屬。
隨時答得出專案卡在誰身上
這批產出是怎麼來的？先看它跟原本的做法差在哪。
03 ── 和原本用信件確認相比，差在哪？
「文字寫清楚了，收件人自己想像畫面。」
關鍵問題：「同一個認知差，要多晚才被發現？」
「先看得見、操作得到，再把需求寫死。」
落差在確認階段就被看見、回修，才進開發。
同一個認知差，傳統流程要等開發完成後才會現形；這套做法讓它在「操作確認」這一站就被看見—— 第 05 章會拿真實需求走一遍。
讓落差提早現形的，是哪一套機制？
04 ── 讓落差提早現形的，是哪一套機制？
核心是「調整 Prototype ⇄ 業務操作確認」的往返：有落差就回修，確認後才定案落檔。 AI 負責查證與整理｜SA 負責分析與判斷｜業務負責拍板｜正式文件負責定案與追溯。 點任一站看它做什麼；點方法看它守在哪一站。
VALUES × 3
前面講的是怎麼做，這一段是做完之後真正拿到什麼。這三件事互相撐著：落差提早看見，修正才便宜；人保留決策權，AI 才不會把錯的答案做得又快又整齊；決定變成文件，這批東西才帶得走。
以 Prototype 讓業務提早看見落差，在成本較低的階段修正，而不是等正式系統完成才發現誤解。
AI 協助查證、比對、整理與產生候選答案；SA 負責判斷，業務負責確認真實工作方式並拍板。
決定不留在聊天或信件中，而會形成規則、驗收情境、穩定 ID、議題與變更紀錄。
機制講完了。拿一個真實需求，完整走一遍。
05 ── 拿一個真實需求，完整走一遍
按「▶ 讓真實需求走一遍」，看「客戶名片建檔」怎麼在站 4 被抓到落差、回修、再確認，才寫進規格； 再按「⇄ 換傳統做法再走一次」，看同一個落差晚多久才現形。
PROTOTYPE 確認了什麼
批次操作是否順暢、逐張確認如何接續、取消時保留哪些結果。
業務決定了什麼
真實使用方式、最低建檔條件，以及同一批名片共用的「認識場合」。
文件固定了什麼
批次上限、檔案限制、可編輯欄位、失敗處理、取消行為與驗收環境。
一個案例不夠？看 35 天累積下來的實據。
06 ── 為什麼相信這不是特例？
02 那批產出不是一次性的成果，是這套流程每一輪都會生出來的東西。 下面三個案例是實際發生的紀錄：需求原話、分析過程與最後定案都查得到，每個數字的分母列在明細區。
業務原話
把「已轉換」加進潛在客戶的狀態選單。
分析發現
狀態代表目前階段、日後可被修改。若把「已轉換」塞進狀態欄，之後任何人改一次狀態， 「曾經轉換過」這個事實就被覆寫消失了。
最後規格
保留獨立且不可逆的 converted 旗標，與生命週期 status 正交分離； 並補上驗收情境擋掉重複轉換與已轉換編輯。（出處：規格／業務規格／01-潛在客戶.md）
潛在客戶、商機、公司與聯絡人各自存在不同來源欄位與清單。
潛在客戶轉換後，來源可能對不上或遺失，報表也無法可靠比較。
來源收斂為共用值域；不需要保存來源的模組直接移除欄位。
查證讓散落的清單被看見，業務拍板讓收斂有依據——報表從此可以可靠比較。
案例均為 CRM 重建專案實際發生的紀錄：需求原話、分析過程與最後定案都可回查，非示意情境。
| 數字 | 怎麼來的 | 分母與統計方式 | 出處 |
|---|---|---|---|
| 60 題 | ✓ 文件計數 | 議題總覽的已結案表逐列計數：60 列。 | 待確認事項.md 議題總覽 |
| 164 條 GWT | ✓ 文件計數 | 8 個業務規格模組中 Given 出現次數加總（公司 19、聯絡人 21、潛在客戶 28、商機 21、銷售項目 14、合約比對 14、報價單 22、參數管理 25）。不含模組範本檔的 2 條。 | 規格／業務規格／*.md |
| 156 個穩定 ID | ✓ 文件計數 | 規格目錄全文抓取 ID 後去重：RULE 80、CALC 30、FLOW 46。MSG／PERM／BTN 系列採不同編碼格式，未計入此數。 | 規格／ |
| 21 份／11,897 行 | ✓ 文件計數 | 業務規格 8 ＋ 資料規格 8 ＋ 資料規格通則 ＋ 參數值域 ＋ 共用 2 ＋ README。行數為業務規格與資料規格 wc -l 加總。 | 規格／ |
| 10 頁雛形 | ✓ 文件計數 | 工作版目錄下的頁面 HTML 檔數：潛在客戶、公司、聯絡人、商機、報價單、銷售項目、合約比對、參數管理、首頁、錯誤頁。 | 雛形頁面／*.html |
| 5 輪確認單 | ✓ 文件計數 | 業務交付目錄的日期資料夾數：20260807／20260812／20260820／20260824／20260903。 | 業務交付／ |
| 35 天變更歷程 | ✓ 文件計數 | 首筆變更紀錄（2026-07-31）至統計日（2026-09-03），含首尾共 35 天；歷程檔按月切檔（2026-07、08、09），首筆日期以檔內紀錄為準。 | 變更歷程／2026-07.md |
| −50% 機械作業 | ● 實作經驗 | 涵蓋盤點整理資料、整理問題、記錄問題、撰寫 Prototype 四類作業，以做過同類工作的前後對照估計，未逐項計時。 | 實際執行者的工作經驗 |
| +50~60% 審閱檢查 | ● 實作經驗 | 涵蓋人工閱讀與理解 AI 產出，以及檢查輸出正確性，同上估計方式。 | 實際執行者的工作經驗 |
| 3 個案例 | ✓ 文件計數 | 客戶名片（議題 37）、已轉換旗標（規格 01-潛在客戶）、來源清單收斂（跨模組治理）。 | 議題台帳與業務規格 |
數字都可回查。那 AI 的角色邊界畫在哪裡？
07 ── AI 做這麼多，界線畫在哪？
AI 加快查證與整理，但每一個決定都有人負責；尚未確認的問題被階段閘門擋下，不會流入下一階段。
那「確認過」三個字，怎麼證明不是口說無憑？
08 ── 說「確認過」就算數嗎？
從需求原話到 UAT 驗收是一條可追溯的鏈：往前查得到誰拍板、為什麼；往後查得到影響哪些規格與測試。 點鏈上任何一站，看它往兩端連到哪裡；再點同一站回到全景。
實例出處：客戶名片＝議題 37；「已轉換」＝規格／業務規格／01-潛在客戶.md。 報告內容均回查 CRM 專案文件——「確認過」不是一句話，是一條查得到的鏈。
這套做法在 CRM 走完一輪了。換到別的部門、別的專案，誰用得上？
09 ── 推廣的話，誰用得上？
這套流程不是只有資深 SA 用得動，受益的也不只有 SA。 不同程度、不同角色拿到的東西不一樣，這是它能在不同部門落地的原因。
新手 SA ── 補的是能力
站 1、站 2 把「該查什麼、什麼算問題」外部化，讓他問得出資深才問得出的問題。這條用法多一道覆核。
資深 SA ── 補的是產能
站 3、站 4、站 5 他本來就會，卡的是做不完、留不住。AI 在這裡是放大器，現在就能直接用。
開發與接手的人 ── 拿到的是資產
站 6 的規格、決策紀錄與穩定 ID 是給下游用的。他們不在現場，需要有人替他們爭取。
把六個階段拼回一張圖，然後呢？
10 ── 收束
這條路已經走完第一步。要證明它不是特例，只有下一個專案能補上： 指定一個專案沿用同樣的六個階段，量出同樣的產出。值不值得推到全公司，到時候讓數據說話。
換到的是可以交接的確定性：60 題需求議題結案、164 條驗收情境、35 天連續變更歷程，每個決定都查得到是誰拍的板、為什麼這樣決定。
人的判斷仍然是關鍵：CASE-02 就是證據。AI 的候選答案完全符合業務原話，是人讀出它會把「曾經轉換過」這個歷史事實覆寫掉。這套流程把 AI 的產能放在查證與整理，把拍板留給人。
這套心法不綁 CRM：換一個專案，換的是要查證的舊系統與要拍板的使用者，流程本身不動。