EXECUTIVE SUMMARY ｜ SA × AI 需求協作方法論 · CRM 重建專案
這次在 CRM 專案中，將 AI 用於資料盤點、需求分析、雛形製作與規格整理，完成八個模組的需求確認，並留下可供開發與交接使用的正式規格。這些協作方式，也能供其他專案採用。
點任一組數字，看它的分母和出處。
02 ── 這些產出，對公司有什麼用？
這批成果分別支援需求確認、正式開發與後續交接。以下按用途整理，每項數字的計算範圍與來源都列在第 06 章。
用途 01 ── 開發有依據
開發同仁拿到確認過的規則，也查得到議題由誰決定、目前卡在哪裡。
60題
已結案需求議題
議題台帳逐列計數。每題含決策者、承辦、結論、日期與複審條件。
已確認的議題有結論，開發前能查閱決策依據
20份
規格與導讀文件
共 11,739 行。業務規格 8 ＋ 模組資料規格 7 ＋ 通則 1 ＋ 參數值域 1 ＋ 共用 2 ＋ 導讀 1。
規格寫得越完整，AI 產出來的程式越穩
隨時
全局盤點能力
任何時間都能答出未定案題數與卡點歸屬。
隨時答得出專案卡在誰身上
用途 02 ── 確認與驗收
業務先操作雛形、回答確認單；確認後的正向與反向流程，再寫成可驗收的條件。
10頁
可操作雛形
涵蓋銷售主線全模組，業務可用真實工作情境直接操作。
使用者看得到、摸得到，才給得出真意見
5輪
結構化確認單
08-07／08-12／08-20／08-24／09-03，每輪可勾選、可下載回覆檔。
背景與選項一起提供，讓使用者更容易回覆
164條
GWT 驗收情境
分母＝8 個業務規格模組。正向與反向動線都寫成前提／動作／預期結果。
測試可以直接照規格驗，不用再翻譯一次需求
用途 03 ── 修改與交接
透過需求 ID 與變更紀錄，接手的人能查詢相關規則與修改理由，再評估影響範圍。
156個
穩定需求 ID
可反查一項需求影響哪些規格與測試，細拆見明細。
改一條規則前，先估得出影響範圍
35天
連續變更歷程
首筆變更紀錄（07-31）至統計日（09-03），記錄改了什麼以及為什麼改。
接手的人查得到改動內容與原因
信件確認同樣可以留下規格。這次把議題結論、驗收情境、變更理由與需求 ID 一起整理進文件，讓開發與接手的人能沿用。查看數字的統計方式與出處 →
這批產出是怎麼來的？先看六個階段怎麼與 AI 配合。
03 ── 每個階段，怎麼與 AI 配合？
從盤點到交付，每一站都有 AI 可以協助的工作：擴大查找範圍、比較方案、快速製作雛形，再把回覆整理成完整且一致的規格。 虛線框內的「雛形 ⇄ 確認 → 定案」把討論收斂成開發依據。點任一站，查看協作做法、人的責任與這一步的優點。
核心價值 × 3
AI 協助擴大盤點與分析範圍，雛形讓業務能具體確認，回覆再整理成前後一致的規格。每一階段都由人確認與判斷，讓 AI 的產出成為下一步可用的依據。
AI 協助交叉查看程式、資料、文件與訪談，整理疑點及不同方案；SA 依來源查證，補足分析時需要的資訊。
用可操作雛形與結構化確認單，讓業務依真實情境體驗、回答與拍板；有落差就回修，再次確認後才定案。
比對新舊回覆與跨模組規則，把確認結果寫成規格、驗收情境與變更紀錄，讓開發和接手的人查得到依據。
流程走完六站。和原本用信件確認相比，差在哪？
04 ── 和原本用信件確認相比，差在哪？
「文字寫清楚了，收件人自己想像畫面。」
關鍵問題：「同一個認知差，要多晚才被發現？」
「先看得見、操作得到，再把需求寫死。」
落差在確認階段就被看見、回修，才進開發。
同一個認知差，傳統流程要等開發完成後才會現形；這套做法讓它在「操作確認」這一站就被看見—— 第 05 章會拿真實需求走一遍。
差別講完了。拿一個真實需求，完整走一遍。
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 系列採不同編碼格式，未計入此數。 | 規格／ |
| 20 份／11,739 行 | ✓ 文件計數 | 2026-09-05 複核：業務規格 8 ＋ 模組資料規格 7 ＋ 通則 1 ＋ 參數值域 1 ＋ 共用 2 ＋ 導讀 1，共 20 份，不含模組範本。11,739 行僅計業務與資料規格內文（不含範本、共用及導讀），以換行字元計數。參數管理的資料表定義於通則，沒有獨立的第 8 份模組資料規格。 | 規格／ |
| 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：換一個專案，換的是要查證的舊系統與要拍板的使用者，流程本身不動。