客製化系統「程式碼審計」完整指南：上線前 6 個必查項、5 個 red flag、3 個第三方審計報價區間 — 中小企業老闆驗收外包工程廠商的最後一道保險

上週我們陪一家中部的傳產客戶做軟體外包驗收——250 萬發包的 ERP，承包商說「跑得起來、驗收給過」，老闆問了我們一句：「你們覺得這個我能簽嗎？」我們花了三天把 commit log、Dockerfile、資料庫 schema、單元測試覆蓋率全看過一遍，回他一句話：「不能。這套上線後 6 個月會撞牆。」

這個故事不是要嚇你，是要告訴你一個被嚴重低估的環節：**程式碼審計（Code Audit）**。台灣 90% 中小企業老闆發包軟體案時，驗收只看「畫面有沒有跑出來、功能能不能點」——這跟買房只看「燈會不會亮」一樣天真。這篇要做的事情是把程式碼審計拆給沒有工程背景的老闆看：6 個必查項、5 個 red flag、3 個第三方審計報價區間，讓你在 200 萬合約簽下去之前，知道該逼承包商交出什麼。

程式碼審計到底在審什麼

根據 Gartner 2026 軟體外包風險報告，全球外包軟體專案有 42% 在上線後 12 個月內因「程式碼品質不足」需要重做或大幅重構。台灣本地的數字更慘——經濟部中小企業處 2025 數位轉型調查 顯示 67% 的客製化系統發包案，老闆認為「驗收時看不出問題」是最大採購痛點。

程式碼審計分三層：**功能審計**（functional review，QA 在做的事）、**品質審計**（code quality review，看的是可維護性、安全性、效能）、**架構審計**（architecture review，看的是擴展性、整合性）。中小企業老闆驗收時，承包商交付的多半只是第一層——畫面能跑、功能會動。後兩層如果不主動要求，根本不會做。

為什麼非做不可

一個寫得爛的系統，跑得起來不代表撐得住。常見後果：上線 3 個月後資料量一大就卡爆、改一個小欄位要 3 週、找新工程師接手沒人敢動、原承包商離開後系統等於變成黑盒。這些問題在驗收當下完全看不出來，但 12 個月後爆炸時，重做成本通常是原案的 60-150%。

6 個必查項目（驗收前老闆該逼承包商交出來的東西）

這 6 項是「不需要工程背景也能要求」的硬性交付。每一項都對應一個具體的「拿不出來就有問題」訊號。

必查 1：程式碼版控完整 commit log（Git history）

要承包商把專案的 GitHub / GitLab repo 開出來，看 commit 頻率與訊息。健康的專案：每 2-3 天至少 1 個 commit、訊息有意義（不是 "update" "fix bug" 這種廢話）。Red flag：整個專案只有 5-10 個 commit、或 commit 全部集中在最後一週（代表前面都在自己電腦寫，沒做版控）。源碼託管條款部分可以對應 客製化系統「源碼託管」(Source Code Escrow) 完整指南 處理。

必查 2：單元測試覆蓋率（Test Coverage）

中小企業客製化系統，**業務邏輯部分**（計價、訂單流程、報表計算）的 unit test 覆蓋率至少要 60%。承包商通常會說「我們有測啊，QA 都過了」——但 QA 是手動測試，不可重複。要看的是自動化測試，每次 deploy 都會跑。要求承包商交付 `coverage report` HTML 檔。沒有任何自動化測試的專案，一律當作 red flag。

必查 3：依賴套件清單與 CVE 掃描

專案用了哪些第三方套件、有沒有已知漏洞。前端跑 `npm audit`、後端跑 `pip-audit` 或 `bundle audit` 都會出報表。High / Critical 等級的 CVE 一個都不能有（必須升級或替換）。最常出事的是用了 3 年前的 jQuery、過時的 image processing library、或被棄用的 ORM。承包商如果交不出這份報表，可能是因為他們自己沒看過。

必查 4：資料庫 schema 文件與遷移腳本（Migration Scripts）

要看每一張資料表的欄位、索引、外鍵、約束條件，並且要有「從零建立」的 migration scripts。Red flag：資料表是手動在 phpMyAdmin / pgAdmin 點出來的，沒有任何 migration 紀錄——這代表未來搬到新環境（DR、雲端切換）等於重建。資料遷移完整流程可以對應 中小企業客製化系統資料遷移完整指南。

必查 5：Docker / 部署設定檔（Infrastructure as Code）

專案能不能用一個指令在新機器上跑起來。`docker-compose up` 或類似的部署腳本是基本。Red flag：部署設定全寫在工程師的 README.md 裡（「先裝 nginx、再裝 PostgreSQL、設定 .env、跑 npm build...」）——這代表只有那個工程師會部署。一旦他離職，系統等於沒人能搬。

必查 6：API 文件（OpenAPI / Swagger）與資料字典

如果系統有 API（多數現代系統都有），要有自動產生的 OpenAPI / Swagger 文件——不是手寫的 PDF。文件要包含每個 endpoint 的 request / response schema、authentication 方式、error code。資料字典要寫清楚每張表、每個欄位的業務意義。沒有這些，未來要做手機 App、做整合、換廠商接手都會卡住。

5 個 red flag — 看到任何一個都要按暫停鍵

這 5 個 red flag 不需要會看程式碼也能判斷，是「老闆級警示」。看到立刻找第三方獨立審計，不要相信承包商的解釋。

中了任何一個都不要單純跟承包商爭執——他們會告訴你「業界都這樣」「我們十幾年都這樣寫」。事實是：這些 anti-pattern 在 2010 年也許可接受，2026 年是基本配備缺失。找第三方做獨立審計，把這份報告當成議價籌碼。

3 個第三方審計報價區間（中小企業老闆該抓多少預算）

台灣本地的第三方程式碼審計服務分三個層級。不同層級對應不同合約金額與風險容忍度。

L3 的滲透測試本站不提供（在 11 項服務範圍外），需要另找專業資安顧問公司。但 L1 / L2 屬於客製化系統開發諮詢的衍生服務，可以對齊 中小企業 AI / 軟體採購供應商盡職調查 SOP 與 AI 廠商議價談判完整指南 整套來看。

我們自己怎麼跑這套

我們公司客製化系統開發歷年 15+ 件案落地，每個案子在交付前都會跑一輪內部 code audit checklist——其實就是上面 6 個必查項的擴充版。內部 checklist 有 30 多項，每個 senior 工程師交付前都要 self-audit 一輪，再讓另一個 senior peer review。然後才進客戶驗收流程。

這套流程不是天生的。早期我們也吃過虧——一個用 Laravel 寫的訂單系統，上線 4 個月後因為某個 query 沒下 index，資料量到 8 萬筆就慢到 30 秒回應。從那次之後我們開始把 N+1 query、缺 index、缺 cache 列為交付前必檢項。客戶不會看，但客戶不知道的事情才是工程團隊真正的品質責任。

市場上對程式碼審計的兩個常見誤解

我們不認同的第一個說法：「找小工作室、便宜接案，省下來的錢就能 cover 後續維運」。這個算法有個盲點——你假設後續維運只是「修 bug」，但實際上 60-80% 的後續成本是「重構不可維護的舊系統」。便宜的不是省錢，是把錢延後到 12 個月後再付，而且通常付得更多。

第二個我們不認同的：「程式碼審計是大公司才需要的事」。錯。大公司有錢養 in-house team 持續 review，反而不一定需要第三方介入；中小企業沒有 in-house 工程主管能挑剔承包商交付品質，**才是最需要第三方審計的對象**。200 萬的合約做一次 15 萬的 L2 審計，是 7.5% 的保險費——這個價格買到的是「驗收後 12 個月不會撞牆」的確定性。

怎麼把程式碼審計寫進合約

光自己警覺沒用，要把審計條款寫進原始合約，不然驗收時承包商會推說「合約沒寫」。建議條款結構：

• 驗收前 7 個工作天交付完整 source code repo（Git history、test coverage report、依賴套件 CVE 掃描）
• 驗收方有權委託第三方做程式碼審計，承包商必須配合提供文件與訪談（時間上限 8 小時）
• 審計報告若發現 Critical 等級問題（hard-code 密碼、SQL injection、嚴重架構缺陷），承包商需於 14 個工作天內修正
• 尾款 20-30% 在第三方審計通過後才付，不接受「先付款後審計」
• 承包商需提供 90 天 production warranty，期間內若因品質問題導致系統不可用，須無償修復

這套條款的精神是把「驗收」從一次性事件變成有客觀依據的程序。詳細的撤退條款設計可以對應 客製化系統「合約撤退條款」完整指南 與 客製化系統「上線後 90 天驗證」完整指南。