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:換一個專案,換的是要查證的舊系統與要拍板的使用者,流程本身不動。