開發用 AI：幫團隊把 APP 做出來
- 需求訪談、Vibe Spec 與 Master SPEC
- 流程圖、介面、Mock Data 與 Mock POC
- AI Coding、除錯、文件與功能測試
- 重點：產出速度、工具能力、上下文與協作
TOPIC 01 · APP + AI
一個 APP 專案，AI 可以參與多少？
以 ERP／SaaS 團隊熟悉的資料流程為底，從名片上傳、OCR、人物 KM、CRM 到 BI，逐段辨認哪些工作應由傳統程式處理、哪些適合加入 AI，以及開發用 AI 與正式運作用 AI 有何不同。
從名片到 AI 應用全貌
一般人先看懂資料怎麼走；接著再拆解每一站的 APP、AI 與人工分工。
這堂課不是只教 AI Coding
同一個 AI 名稱可能出現在開發與運作兩邊，但目的、風險與評估標準不同。
運作用 AI：成為 APP 的正式能力
- OCR、多模態理解、資料清理與人物匹配
- KM 摘要、CRM 建議、BI 洞察與 Agent
- 會持續產生成本、延遲、個資與品質責任
- 重點：準確、穩定、成本、隱私與可控性
APP + AI 的核心：APP 提供資料、流程、權限與可持續運作的產品環境；AI 提供理解、判斷、生成與新型互動能力。
逐站拆解 APP + AI
點選專案環節，查看 APP 基本功能、開發用 AI、正式運作用 AI，以及必須保留的人工確認。
APP開發 AI運作 AI人工
閱讀方式：先問「不用 AI 能不能穩定完成？」再問「加入 AI 是否真的提高辨識、決策或使用體驗？」最後確認失敗時能否被發現與修正。
AI 不只增加功能，也改變 APP 的輸入方式
表單仍適合精確資料；自然語言與多模態則讓使用者用更接近真實工作的方式提供資訊。
傳統 APP：使用者配合系統
- 先理解選單、欄位與操作順序
- 自行拆分姓名、公司、需求及備註
- 圖片、文件、語音與文字分開處理
- 查詢前要先知道報表、欄位或功能在哪裡
AI APP：系統先理解使用者意圖
- 用白話說「我要找誰、想知道什麼、下一步做什麼」
- 同時提供圖片、語音、文字、文件與既有資料
- AI 先理解、抽取並提出候選結果
- APP 再以欄位、權限、流程與人工確認完成動作
四種更有效益的 APP 運用
自然語言與多模態不是取代表單，而是降低輸入成本並補足模糊情境。
自然語言查詢
「找出半年沒聯絡、曾對 AI ERP 有興趣的台南客戶。」AI 理解意圖，APP 將條件轉成受控查詢並顯示資料來源。
自然語言操作
「幫我整理明天拜訪名單並產生會前摘要。」AI 規劃步驟，APP 控制可用工具、權限與確認點。
多模態資料輸入
同時輸入名片照片、人物照片、會議錄音、對話截圖及文件，AI 協助理解與歸納成同一人物 Context。
自然語言 × 多模態融合
使用者指著圖片或文件補一句「這張名片是上次會議那位採購主管」，AI 結合語句、影像與既有 KM，提出人物匹配與更新建議。
承接與保存
管理檔案、欄位、人物 ID、權限、版本、流程狀態及可回復紀錄。
理解與轉換
辨識不同媒介、理解自然語言意圖、抽取資料並提出摘要、候選與建議。
確認與決策
校正身分與關鍵欄位，確認對外行動、敏感推測及重大決策。
少切換、少重打
減少操作學習、資料重複輸入與跨系統搬運，讓非技術人員也能直接表達需求。
範例：一場客戶拜訪可以同時輸入什麼？
使用者上傳名片與合照、加入現場錄音或會議摘要，再補一句「這位客戶對庫存預測有興趣，下週提醒我提供案例」。AI 可抽取人物、公司、需求、時間及待辦候選；APP 則把結果分別寫入人物 KM、CRM 互動、商機標籤與排程，送出前由使用者確認。
為什麼不能只做一個聊天框？
聊天框適合表達意圖，但正式 APP 還需要結構化資料、權限、歷史版本、錯誤修正、可追溯來源及穩定流程。好的 AI APP 應同時保留自然語言入口與可檢查的結構化結果。
新型 APP 的價值：讓使用者用自然語言與多模態提供真實情境，讓 AI 負責理解，讓 APP 把理解轉成可保存、可查詢、可執行、可治理的工作成果。
開發用 AI：從想法走到可測試版本
AI 是專案團隊的協作者，不一定會進入正式產品。
概念發想
比較情境、使用者、價值與限制。
Vibe Spec
用白話討論，讓 AI 重述並修正理解。
Master SPEC
整理模組、資料、規則、例外及驗收。
Mock Data
生成足以涵蓋正常與例外的測試資料。
Mock POC
快速做出可操作畫面，確認概念與價值。
MVP
AI Coding 協助建立可供早期使用的版本。
AI Testing
生成案例並透過程式或 Computer Use 驗證。
適合大量使用 AI 的地方
- 發散構想、整理大量資料與比較方案
- 產生初稿、Mock Data、畫面及測試案例
- 讀取完整 SPEC 後進行程式開發與除錯
- 重複性文件、說明與版本差異整理
必須設人工確認點
- 需求與商業目的是否理解正確
- 資料規則、權限、個資與例外是否完整
- POC 是否真的證明使用價值
- MVP 是否符合驗收條件並可安全回復
Chat、Work、Code 如何分工？
Chat 適合把模糊想法談清楚；Work／Cowork 適合依共識進行研究、整理與多工具 POC；Code／Codex 適合在專案資料夾中建立、修正、測試及維護程式。能力會重疊，應依主要交付成果選擇，而不是把產品名稱當成固定流程。
為什麼先做 Mock POC？
POC（Proof of Concept，概念驗證）先確認「做得到而且有價值」；Mock 版本可先避開金鑰、權限、部署與正式資料風險。確認後再進入 MVP（Minimum Viable Product，最小可行產品），建立可供早期使用者實際操作的第一版。
運作用 AI：正式 APP 該選哪條路？
先按用途篩選，再比較成本、速度、隱私、穩定性與維護難度。
快速比較
分數只是教學上的相對概念，正式選型仍要以真實資料做 POC。
| 技術路線 | 理解能力 | 速度 | 成本可控 | 隱私 | 維護簡易 | 適合本案 |
|---|
不要先選模型，先選情境
同一個名片專案可能同時使用傳統程式、小模型、大模型與人工確認。
推薦架構一定只能選一種 AI 嗎？
不需要。常見做法是先用傳統程式做格式檢查，以 OCR 或小模型處理大量低風險任務，只把模糊、複雜或低信心資料交給大型模型，最後由人工確認關鍵結果。這是成本、品質與風險較平衡的混合架構。
什麼時候需要向量資料庫？
姓名、電話、公司與卡片 ID 等精確條件應先使用一般資料庫查詢。只有當需求是「找語意相近的互動、背景或需求」時，才考慮 Embedding 與向量搜尋。向量不是 KM 的必要條件，也不能取代關聯資料的正確性。
有 Token 與無 Token 模式如何取捨？
傳統規則、資料庫查詢與地端固定模型可以降低每次呼叫 Token 的依賴；雲端 LLM 則以 Token 換取較強的理解與生成能力。正式 APP 應分流：能以規則可靠完成的工作不呼叫 LLM，需要語意理解時才使用模型。
AI 能協助治理，但不能替人負責
名片、照片、對話與客戶資料可能涉及個人資料與商業敏感資訊。
資料與權限
確認蒐集目的、告知與合法基礎；限制可讀取的 Drive、CRM 及客戶資料，並保留存取紀錄。
模型與輸出
標示資料來源、模型版本、信心與生成時間；低信心匹配、人物推測及重要建議必須人工確認。
流程與責任
付款、寄信、寫回 CRM、合併人物及刪除資料等不可逆操作，應設明確核准與回復機制。
適合 AI 自動完成
- 摘要、草稿、標籤建議與候選比對
- 異常提醒、重複資料提示與待辦建議
- 測試資料、測試案例與文件初稿
不應讓 AI 單獨決定
- 人物身分最終認定與敏感屬性推測
- 客戶信用、聘僱或重大商業決策
- 對外聯絡、權限調整與不可逆操作
最終原則：讓 AI 提供候選、摘要與建議；讓 APP 保存證據、權限與流程；讓人對重要決定負責。