CRM 重建專案 · SA × AI 需求協作實證
機械式作業省下約 50%，換成閱讀、理解與驗證 AI 產出的時間（約 +50~60%）——SA 總工時持平。 真正換到的是：需求落差在開發前被攔截，以及一批傳統做法下根本不會存在的規格資產。
每個數據都點得動——先看它的分母與口徑，再跳到對應的證據。
02 ── 工時到底省在哪、賠在哪？
這三個數字是 SA 本人的體感估算，沒有工時單可以佐證。 把它攤開講，是為了讓後面的資產與案例證據站得住。
工時持平，那到底值在哪？——先看落差是什麼時候被發現的。
03 ── 和原本用信件確認相比，差在哪？
「文字寫清楚了，收件人自己想像畫面。」
關鍵問題：「同一個認知差，要多晚才被發現？」
「先看得見、操作得到，再把需求寫死。」
落差在確認階段就被看見、回修，才進開發。
同一個認知差，傳統流程要等開發完成後才會現形；這套做法讓它在「操作確認」這一站就被看見—— 第 05 章會拿真實需求走一遍。
讓落差提早現形的，是哪一套機制？
04 ── 讓落差提早現形的，是哪一套機制？
核心是「調整 Prototype ⇄ 業務操作確認」的往返：有落差就回修，確認後才定案落檔。 AI 負責查證與整理｜SA 負責分析與判斷｜業務負責拍板｜正式文件負責定案與追溯。 點任一站看它做什麼；點方法看它守在哪一站。
以 Prototype 讓業務提早看見落差，在成本較低的階段修正，而不是等正式系統完成才發現誤解。
AI 協助查證、比對、整理與產生候選答案；SA 負責判斷，業務負責確認真實工作方式並拍板。
決定不留在聊天或信件中，而會形成規則、驗收情境、穩定 ID、議題與變更紀錄。
機制講完了。拿一個真實需求，完整走一遍。
05 ── 拿一個真實需求，完整走一遍
按「▶ 讓真實需求走一遍」，看「客戶名片建檔」怎麼在站 4 被抓到落差、回修、再確認，才寫進規格； 再按「⇄ 換傳統做法再走一次」，看同一個落差晚多久才現形。
PROTOTYPE 確認了什麼
批次操作是否順暢、逐張確認如何接續、取消時保留哪些結果。
業務決定了什麼
真實使用方式、最低建檔條件，以及同一批名片共用的「認識場合」。
文件固定了什麼
批次上限、檔案限制、可編輯欄位、失敗處理、取消行為與驗收環境。
一個案例不夠？看 35 天累積下來的實據。
06 ── 為什麼相信這不是特例？
以下每一項都能在 CRM 專案文件裡直接點出來，統計方式列在下方的明細區。 這些不是「做得比較快」，是傳統做法下不會存在的產物。
60題
已結案需求議題
議題台帳逐列計數。每題含決策者、承辦、結論、日期與複審條件。
164條
GWT 驗收情境
分母＝8 個業務規格模組。正向與負向動線都寫成前提／動作／預期結果。
156個
穩定需求 ID
可反查一項需求影響哪些規格與測試，細拆見明細。
21份
正式規格文件
共 11,897 行。業務規格 8 ＋ 資料規格 8 ＋ 通則 ＋ 參數值域 ＋ 共用 2。
10頁
可操作雛形
涵蓋銷售主線全模組，業務可用真實工作情境直接操作。
5輪
結構化確認單
08-07／08-12／08-20／08-24／09-03，每輪可勾選、可下載回覆檔。
35天
連續變更歷程
首筆變更紀錄（07-31）至統計日（09-03），記錄改了什麼以及為什麼改。
隨時
全局盤點能力
任何時間都能答出未定案題數與卡點歸屬——信件確認的做法，這張圖畫不出來。
業務原話
把「已轉換」加進潛在客戶的狀態選單。
分析發現
狀態代表目前階段、日後可被修改。若把「已轉換」塞進狀態欄，之後任何人改一次狀態， 「曾經轉換過」這個事實就被覆寫消失了。
最後規格
保留獨立且不可逆的 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 專案文件——「確認過」不是一句話，是一條查得到的鏈。
把六個階段拼回一張圖——然後呢？
09 ── 收束
這條路已經走完第一步。缺的量化證據，只有下一個專案能補上—— 試點的代價只有一個：SA 要開始記工時。值不值得推到全公司，到時候讓數據說話。
工時沒有變少——機械作業省下來的，都花在讀懂與檢查 AI 產出上。CASE-02 就是這筆時間換來的：AI 的候選答案完全符合業務原話，是人讀出它會把「曾經轉換過」這個歷史事實覆寫掉。
換到的是確定性：需求落差在開發前被攔截（60 題議題開發前結案），每個決定都查得到來源。
這套心法不綁 CRM：換一個專案，換的是要查證的舊系統與要拍板的使用者，流程本身不動。