Class 03 學員提問與技術解答

有資源的最佳解（參考用）：大型團隊處理 API 效能時，第一步通常不是直接改程式，而是先量測、再定位、再最佳化。完整做法會包含監控、壓測、log tracing、profiling、CI/CD 效能回歸測試，系統性找出瓶頸到底在前端、API、資料庫、網路、外部服務，還是使用者流程。

• 觀測與量測（先知道慢在哪裡）：
  • 監控指標：追蹤 response time、error rate、request count、database query time、CPU / memory / network。
  • 壓力測試：使用 k6、JMeter、autocannon 或雲端壓測工具，模擬不同人數、不同資料量、不同查詢情境。
  • 追蹤與 log：讓每個 request 都能追蹤從前端、API、資料庫到外部服務的耗時。
• 資料庫層級優化：
  • 建立合理索引（Index）：確保常用的 WHERE、JOIN 和 ORDER BY 欄位都有索引，避免全表掃描。
  • 解決 N+1 查詢問題：在多表關聯查詢時，使用 JOIN 語法或預先載入（Eager Loading），千萬不要在迴圈中重複向資料庫下查詢指令。
  • 資料庫連線池（Connection Pool）：重複使用連線，省去每次 API 請求都要重新與資料庫 Handshake 的時間成本。
• 引進快取層（Caching）：使用 Redis 快取讀取極度頻繁但鮮少變動的資料（如：系統設定、基礎字典、用戶基本權限等）。
• 非同步處理（Asynchronous Workers）：針對發送驗證信、生成報表等耗時工作，API 不應阻塞等待，應直接丟入訊息佇列（如 BullMQ / RabbitMQ），並立刻回傳 202 Accepted。
• 容量與架構調整：當單機或單一 API server 已無法承受負載，才進一步評估水平擴充、Load Balancer、讀寫分離、資料分區、API Gateway 與完整監控告警。

有資源的最佳解（參考用）：如果是大型 ERP / SaaS 公司，面對 AI 協助建表與外掛擴充，最佳解不是只寫一份命名規則，而是建立完整的 ERP Data & Extension Governance Platform。它把資料表、欄位、API payload、workflow table、migration、客戶版本、外掛依賴與 AI 產生紀錄都納入同一套治理流程。

• Metadata Registry：每一張表、每一個欄位、每一個 payload 都要有 metadata，包含用途、資料來源、負責人、客戶、專案、版本、敏感等級、保留期限與退役條件。
• Extension Catalog：所有外掛、客製功能、AI Runtime、staging table、integration table 都登錄成 catalog item，清楚標示它依賴哪些 ERP core table、API、版本與客戶環境。
• Schema Review Workflow：AI 可以提出 schema draft，但必須經過命名檢查、重複概念檢查、資料型態檢查、權限檢查、升級相容性檢查與人類審批。
• Migration Pipeline：所有 DDL 變更都透過 migration 檔管理，能在 dev / staging / production 逐層驗證，也能回溯誰在什麼版本做了什麼改動。
• Impact Analysis：上線前自動分析哪些客戶、報表、外掛、API、排程、工作流會被影響，避免「改一張表，壞一片功能」。
• Lifecycle Management：資料表不是建立後永遠存在。系統要能追蹤使用率、孤兒表、重複功能、待封存資料、退役流程與 audit trail。
• AI Governance Policy：明確規範 AI 可以做什麼，例如查重、建議命名、產生 migration draft、補文件、分析相依；也明確規範 AI 不可以做什麼，例如未審批自動改 core table、改正式欄位、寫入正式流程。

這種有資源版的核心目標，是讓 AI 加速資料與外掛設計，但所有新增、修改、上線、升級、退役都留在可審查、可追蹤、可治理的軌道上。

有資源的最佳解（參考用）：成熟企業會優先採購企業版 AI 帳號與正式協作平台，而不是讓員工長期使用私人帳號或共用帳密。企業版的價值不只是模型比較強，而是提供管理主控台、權限、資料保護、稽核紀錄、團隊協作、費用管理與供應商合約責任。

在有資源的情況下，AI 使用會從「個人工具」提升成 Enterprise AI Operating Model。它不是只管 token，而是同時管理 AI portfolio、帳號權限、資料分類、使用紀錄、成本、稽核與知識交接。

• AI Portfolio Management：定義不同 AI 的角色分工，例如文件型、工程型、研究型、審查型、會議型、客服型。重點不是哪個 AI 最強，而是哪個 AI 適合哪類任務。
• Enterprise Account & Access Governance：以企業版帳號集中管理使用者、群組、角色、權限、客戶資料隔離、離職停權、專案交接與費用歸屬，避免不受控多人共用帳號。
• Collaboration Platform：優先使用能支援共享空間、團隊知識庫、專案權限、文件協作、審批流程與管理者可視性的企業平台。
• Data Classification：依資料敏感度決定能否給 AI 使用，例如公開資料、內部資料、客戶資料、個資、財務資料、原始程式、密鑰與正式營運資料，應有不同使用規則。
• Usage Log & Audit Trail：重要 AI 使用應留下紀錄：誰使用、用在哪個專案、輸入哪些資料類型、產出什麼文件、是否經過人類審查、是否進入正式交付。
• Cost / Token Governance：token 管理只是其中一環。企業應追蹤模型費用、專案費用、團隊額度、使用價值與浪費來源，把昂貴模型用在高價值判斷。
• ISO / Audit 對齊：
  • ISO 27001：關注資訊安全、存取控制、資料分類、供應商風險與稽核紀錄。
  • ISO 42001：關注 AI 管理系統、風險、責任、治理流程與持續改善。
  • Computer Audit：關注操作紀錄、權限、變更管理、交接與可追溯性。

這種有資源版的核心目標，是把 AI 從「每個人各自使用的工具」變成企業可管理的 AI 團隊。未來企業競爭力不只來自模型能力，而來自人與 AI、AI 與 AI 能否在同一套 context、規則與治理框架下協作。

核心答覆：Antigravity 這類高階 AI coding agent，中文互動通常沒有問題；真正限制不在於「它聽不聽得懂中文」，而在於開發工具、程式碼、套件、生態文件、錯誤訊息、模型推理語料與底層工具鏈，大量仍以英文為主。

痛點與物理限制：介面中文化只是 UX 層問題，技術上相對容易；但思考過程、工具輸出、程式碼語境與錯誤訊息英文化，是更深層的生態限制。從 tokenizer 與模型訓練角度看，英文在 token 使用效率、程式語料密度、API 文件、開源討論與程式碼網絡中通常更有優勢。簡單說：AI 可以用中文跟你溝通，但很多底層技術路徑仍然是英文高速公路。

推薦替代路徑：不要把目標設定成「所有介面都變中文」，而是建立中文決策層與英文技術層的橋接方式。

• 人類決策層中文化：需求、計畫、風險、驗收、會議紀錄與交接文件，用繁體中文保存。
• 技術執行層保留英文：程式碼、log、API、錯誤訊息、套件文件與 Git 紀錄，逐步習慣英文原生環境。
• 翻譯與摘要工具輔助：遇到英文輸出時，請 AI 幫忙翻譯、摘要、分類與標註風險，而不是要求所有工具都改成中文。
• 工具分工：前期用中文親和的工具做思考整理，後期用高階 coding agent 做本地執行、專案操作與工程落地。

有資源的最佳解（參考用）：大型企業與 AI 公司通常不會只問「哪個 IDE 最好用」，而會把工具分成兩層：AI Agent Tool 與 AI IDE。

• AI Agent Tool（主角）：
  • 代表：Antigravity、Codex、Claude Code、Gemini Agent、OpenAI Agent 等。
  • 定位：數位員工，能協助撰寫程式、文件、review、debug、研究、規劃與測試。
  • 評估重點：能否讀取 context、操作工具、處理多檔案任務、產生可審查紀錄、支援權限與企業治理。
• AI IDE（配角）：
  • 代表：Cursor、Windsurf、VS Code、JetBrains 等。
  • 定位：AI 工作的辦公桌，提供編輯器、檔案、終端機、插件、diff、測試與專案操作環境。
  • 評估重點：是否符合企業資安、工程師習慣、既有 repo 流程、插件生態、review 與維護方式。
• 大型企業 / AI 公司適合方向：
  • 情境：大量工程師、大量專案、大量程式碼、大量預算。
  • 做法：導入高階 Agent、企業版 coding agent、內部 agent team、權限治理、CI/CD、測試平台與 code review 流程。
  • 目標：讓 Agent 進入正式工程流程，但所有變更仍需測試、審查、權限與稽核。
• SME / ERP 顧問公司適合方向：
  • 情境：工程資源有限，真正痛點常常是文件分散、流程不清、經驗沒有沉澱。
  • 做法：優先建立 KM、NotebookLM、Google Workspace / Gemini、ChatGPT、Antigravity、GAS、n8n 與共用專案資料夾。
  • 目標：先讓人與 AI 能協作，再逐步導入 Agent；不要在基礎 KM 與 Workflow 尚未建立時，就追求複雜的 Multi-Agent。

結論不是「哪個工具最強」，而是「哪個工具最適合目前階段」。對大部分 ERP 顧問與 SME 而言，先建立 KM、Workflow 與 AI 協作，通常比直接追逐最強 Agent 更有價值。

有資源的最佳解（參考用）：全球 AI 導入正在出現兩極化。第一極是超大型企業，例如 NVIDIA、Google、Microsoft、Apple 這類公司，會發展 Agent Team、Digital Twin、AI Factory、Enterprise Agent，讓 AI 進入研發、供應鏈、產品、資料中心與內部營運。

第二極是超小型團隊，例如 OPC（One Person Company）、顧問與自由工作者。這類團隊可能是一個人加多個 AI Agent，形成小型團隊產能：一個 AI 寫內容、一個 AI review、一個 AI 測試、一個 AI 做研究，最後由人類決策與交付。

真正資深的工程師或顧問，通常不會只是排斥 AI。相反地，他們會更願意相信好模型的能力，也更敢在關鍵問題上使用高階模型、投入較多 token，因為他們知道複雜問題的判斷成本本來就高。差別在於：他們不會把 AI 當神諭，而是會用更深入的領域知識、批判能力與思考能力，提出更尖銳的問題，要求 AI 說明假設、列出風險、提供反例、補上測試，最後自己扮演守護者，守住架構、資料、權限、客戶承諾與正式交付邊界。

在 ERP 顧問場景裡，這種領域知識尤其重要。AI 可能會寫出看似合理的流程或程式，但它不一定懂客戶現場的權限習慣、帳務邏輯、部門責任、導入限制、歷史客製與老闆真正想解決的問題。資深者的價值，是能看出 AI 答案哪裡漂亮但不落地、哪裡有效但有風險、哪裡需要再問一次。

資深能力的定義正在改變：

• 過去的資深工程師：重點常被放在寫程式能力、熟悉框架、解 bug、處理系統細節。
• 未來的資深人才：更重視架構能力、需求拆解、驗收能力、治理能力、風險判斷、AI 管理能力，以及足以判斷 AI 答案品質的領域知識。
• 真正資深的 AI 用法：更相信高模型在複雜問題上的價值，願意把 token 花在架構、風險、review、debug、測試與反例推演上；同時提出更尖銳的問題，要求 AI 自我檢查，而不是只接受第一版答案。
• 批判與思考能力：資深者不只是問 AI「怎麼做」，還會追問「為什麼這樣做」「有沒有反例」「哪裡可能失敗」「是否符合客戶流程」「是否會影響維護與治理」。
• 守護者角色：資深者最後要守住系統邊界，包括資料、權限、正式流程、客戶承諾、維護責任與交付品質。AI 可以加速，但人類仍要負責批准與治理。
• Cross-AI Validation：用不同 AI 互相產生、審查、測試與補充觀點，避免單一 AI 的盲點。
• HITL（Human-in-the-Loop）：AI 可以產出、分析與建議，但正式決策、客戶承諾、資料寫回與風險承擔仍需要人類批准。

結論是：AI 並不是讓所有人都變成工程師，而是讓更多人有能力完成過去需要工程師才能完成的工作。對台灣企業而言，真正重要的不一定是成為最強工程師，而是成為能與 AI 協作、管理 AI、驗收 AI、整合資源、創造商業價值的人。

有資源的最佳解（參考用）：如果企業資源較完整，可以把這件事升級成正式的「Design to Engineering Workflow」，讓設計、POC、工程、測試與文件都有清楚責任分工。

• 樣板庫與設計系統：先建立企業常用版型、配色、元件、報表樣式、Dashboard 風格與提案頁模板，讓 AI 不必每次從零開始。
• POC 工作區：允許顧問用 Gemini Canvas 或類似工具快速產生展示頁，但明確標示為 demo，不直接連正式資料。
• 工程審查清單：正式化前必須檢查 API、資料流、權限、稽核紀錄、錯誤處理、效能、測試與部署方式。
• UX / QA 驗收：上線前由使用者、顧問、工程師共同驗收，確認畫面好看之外，也真的符合流程、權限與操作習慣。
• 文件與交接：將最終決策、樣板來源、AI 生成內容、人工調整與交付版本留下紀錄，方便後續維護。

成熟企業不會只比較工具名稱，而會建立一條穩定流程：視覺 AI 負責讓想法被看見，工程 AI 負責讓系統可運作，文件 AI 負責讓知識可交接，最後由人類負責商業判斷與正式批准。

有資源的最佳解（參考用）：有資源的企業不會只套一個固定答案，而是根據客戶現場狀態做最佳化配置。先盤點客戶的主機、作業系統、資料庫版本、網路權限、資安要求、備份能力、內部 IT 能力與維護預算，再決定使用 Web / Cloud / Local Runtime / Docker / API Gateway / GAS 等組合。

成熟服務商的價值，是提供完整的環境建議細節，而不是只交付程式。例如：建議硬體規格、OS 版本、DB 版本、Python / Node 標準、部署架構、權限模型、log 保存、備份策略、監控方式、更新週期、回復方案與移轉流程。客戶可以再透過 AI 與專家一起檢查這份建議，逐步最佳化自家環境。

• 環境標準定義：
  • 明確記錄 Python / Node / DB / API / 套件版本，以及安裝方式與升級週期。
  • 避免使用「我這台電腦剛好可以」當成專案交付標準。
• Docker / Container：
  • 適合多人協作、正式維運、伺服器部署、多服務組合與 CI/CD。
  • Docker 的價值是讓環境一致，而不是取代架構設計、權限治理或人類驗收。
• AI Agent 輔助建置：
  • 讓 AI Agent 協助產生 Dockerfile、docker-compose、安裝腳本、環境檢查清單與除錯建議。
  • 但 AI 只能協助建立環境，不能替企業決定誰負責維護、哪些版本標準、哪些資料可以連接、哪些流程可以上線。
• 服務商建議書與最佳化配置：
  • 依客戶規模、資料敏感度、內網限制、IT 人力、維護能力與預算，提供不同等級的部署建議。
  • 讓客戶不是被迫自己摸索環境，而是拿到可被 AI、專家與內部 IT 共同檢查的治理底稿。

所以這題不是 Docker 教學，而是 AI 時代的環境治理思維。工具可以越來越自動化，但標準、責任、風險與交付邊界，仍然要由人類治理。

有資源的最佳解（企業版參考）：成熟企業仍然會搭配 SonarQube、Snyk、GitHub CodeQL、SAST、DAST、依賴套件掃描與 CI/CD 安全檢查。AI Review 與專業工具並非互斥，而是互補：工具負責穩定掃描，AI 負責解讀、分類、補測試、產生修補建議與整理治理報告，人類與專家負責批准與治理。

• 工具層：企業常見安全與品質工具：
  • SonarQube / SonarCloud：用於程式品質、Code Smell、維護風險、常見安全問題與技術債檢查。
  • Snyk / Dependabot：用於第三方套件漏洞管理、開源元件風險管理與相依套件升級提醒。
  • GitHub CodeQL：用於 Pull Request 安全分析、自動化程式碼檢查與潛在漏洞查詢。
  • SAST（Static Application Security Testing）：對原始碼做靜態分析，在系統尚未執行前找出可能的安全問題。
  • DAST（Dynamic Application Security Testing）：對執行中的系統做安全測試，觀察實際請求、回應、登入、權限與弱點暴露情況。
• 流程層：工具不能取代治理：
  • 建議流程：AI 產生 → 第二 AI Review → Checklist → 測試環境驗證 → 人類批准（HITL）→ 正式發布。
  • 工具可以協助找問題，但不能替企業決定風險是否可接受、資料是否可寫回、權限是否合理、客戶承諾是否成立。
  • 重要變更必須留下 log、測試資料、回復方式、審查紀錄與批准者。
• ERP 特別注意：高風險通常在資料與權限：
  • 銀河軟體 ERP 情境下，真正高風險的通常是 SQL Server、ERP 權限、Excel 批次更新、API 寫回與客戶資料。
  • 涉及正式資料時，建議使用測試環境、脫敏資料、回復機制與審查紀錄，避免把測試動作變成正式事故。
  • 對 ERP 顧問而言，安全不只是漏洞掃描，也包含流程權限、資料責任、操作紀錄與能否復原。
• SQL Injection 結構性防禦：寫得簡單，但要做得嚴格：
  • 不要將使用者輸入直接拼接進 SQL。
  • 優先使用參數化查詢、Stored Procedure、受控 View、API Gateway 與權限控管。
  • HTML 前端不應直接碰資料庫，帳號、密碼、API Key 與 Token 不應放在前端。

AI 時代最大的改變，不是工具變強而已，而是 Code Review、安全檢查、流程驗證與邏輯驗證的成本大幅下降。對銀河軟體 ERP 顧問而言，最重要的能力是善用第二個 AI 做 review，建立必查清單與禁止清單，建立 HITL 驗收流程，並知道哪些地方一定要驗證；成熟企業則應同時搭配 SonarQube、Snyk、CodeQL、SAST、DAST 等專業工具，形成 AI Review + 工具掃描 + 人類治理的完整安全流程。

有資源的最佳解（企業版參考）：正式團隊會把「AI 技術越權」當成架構治理問題，而不只是 prompt 問題。AI 可以很會寫，但它必須在明確的 architecture boundary 裡寫。

• 技術必用清單 / 禁止清單：
  • 明定可用技術，例如 HTML、RWD、GAS、API Gateway、SQL View、Python Runtime、指定套件版本。
  • 明定禁止技術，例如未批准框架、未批准資料庫、未批准後端服務、未批准雲端儲存、直接寫回正式 ERP。
• 開發規範與 AI 規則檔：
  • 在 README、PROJECT.md、AI_RULES.md 或 coding agent 規則中寫清楚專案 Tier、允許技術、資料邊界與驗收條件。
  • AI 每次改動後，要檢查是否新增未批准的框架、套件、後端、DB、權限或寫回能力。
• 模組化與 HITL：
  • 正式案要把 UI、API、資料存取、權限、log、錯誤處理分開，避免 AI 把所有邏輯塞在一起。
  • 涉及 Tier 3 / Tier 4 的變更，必須由人類或專業顧問 review，不能只靠 AI 自評。

結論：Q10 不是在問要不要用 React 或 Docker，而是在問 AI 開發如何不失控。PoC 可以快，正式案要有規範；AI 可以寫，技術邊界要由人類治理。

有資源的最佳解（企業版參考）：成熟企業會把維護問題做成產品治理，不只是程式碼管理。Q8 是環境基礎，Q10 是技術治理，Q11 則是版本治理、客製治理與長期維運治理。

• 標準版 / 客製版 / 元件庫：
  • 標準版：銀河軟體維護，納入服務水準與升級策略。
  • 客製版：獨立管理，需明確記錄客戶、版本、差異、責任與支援範圍。
  • 元件庫：OCR、Workflow、Dashboard、查詢模組、通知模組等共通能力，盡量重用而不是重做。
• 定期 HITL Review：
  • 建議每季或半年進行一次，檢查是否仍在使用、是否偏離標準、是否需要重構、是否需要退役。
  • Review 不只是工程檢查，也包含客戶流程、權限、資料責任、SLA 與維護成本。
• SLA 與客戶共同責任：
  • 標準功能可納入維護合約；客製功能需另行約定相容性、測試責任、升級策略與支援範圍。
  • 重要功能應留下測試紀錄、驗收紀錄與回報紀錄。這不只是保護客戶，也是保護銀河軟體。
• 交付與保固模型：
  • 標準版：使用標準元件，納入一般 SLA，價格較可控。
  • 客製版：標準元件 + 客製化條件 + 客戶內部種子訓練 + 有限期保固，例如 30 / 60 / 90 天。
  • 特殊保固合約：高風險、高客製、正式營運功能，需另訂 SLA、相容性、升級責任、支援時間、測試責任與資料風險。
• Git / PR / Branch 是輔助，不是起點：
  • 當專案進入 Tier 3 / Tier 4，才需要把 Git 分支、Pull Request、Code Review、自動化測試與 release note 做完整。
  • 工具是治理的載體；真正重要的是版本責任、差異責任與客戶承諾。
• 保固檢核與異動性檢查：
  • 定期 HITL Review 的目的，不只是確認功能是否仍在使用，也要確認系統狀態是否仍符合保固與維護條約。
  • 最小可行做法包含交付 manifest.json、版本號、檔案 hash（MD5 或 SHA256）、部署紀錄、設定檔差異、deploy.log、maintenance.log 與安裝清單。
  • 若程式碼、設定檔、套件版本、DB View / Stored Procedure 或安裝環境被客戶或第三方修改，應能透過檢核紀錄判斷是否仍屬於保固範圍。

長期來看，能不能維護不是看第一版功能多漂亮，而是看它能不能被重建、被理解、被測試、被移轉、被接手、被退役，並且能不能證明仍符合保固範圍。AI 時代客製速度變快，但維護成本沒有消失，所以客製功能要被管理，而不是被放任生長。

有資源的最佳解（企業版參考）：行動化不是只有 App 一種交付型態。成熟企業會先做 delivery channel matrix，判斷每個功能適合 Web、RWD、PWA、內部入口、客戶入口、原生 App 或跨平台 App。

• HTML / RWD：
  • 最適合報表、查詢、表單、Dashboard、SOP、客戶入口與內部 workflow。
  • 優點是部署快、更新快、維護成本低、客戶不用上架 App。
• PWA：
  • 適合需要類 App 體驗、加入主畫面、部分離線快取、手機友善操作的情境。
  • 仍保有 Web 更新快速、免商店審查的優勢，但權限、離線與推播能力要依平台限制評估。
• 特殊需求才 App：
  • App 適合推播深度整合、離線能力、特殊硬體、相機/定位/藍牙/NFC 等特殊手機能力，或需要企業 MDM / 平台政策整合的案子。
  • 一旦走 App，就要管理平台審查、版本發布、手機規格、OS 相容性、權限、客服、SLA 與資安責任。
• Q10~Q12 共同治理目標：
  • Q10 技術治理：避免 AI 技術失控。
  • Q11 版本治理：避免客製失控與維護失控。
  • Q12 交付治理：避免交付型態過重、SLA 不清、客戶支援成本失控。

AI 時代最大的風險，不是 AI 不夠強，而是專案長太快、客製太快、技術太多、沒有人治理。因此 Q10~Q12 的共同目標，是建立規範、模組化、AI 管理、專案分級、SLA 與 HITL Review，讓系統能持續成長，而不會失控。