# 廠商交付了原始碼，網站就能接手嗎？先驗收五項可重建能力

- 網址：https://www.edgedeploy.tw/blog/website-source-code-rebuild-handover-checklist
- 分類：系統整合與技術案例
- 發佈日期：2026-09-07
- 更新日期：2026-09-07
- 作者：邊境部署

> 拿到程式碼，不代表新團隊能在乾淨環境完成建置、設定資料庫與重新上線。本文用五項驗收問題，協助企業確認版本、相依套件、環境設定、部署流程與實際演練，避免換廠商後才發現網站只能由原團隊維護。

網站專案結案時，廠商交付一個壓縮檔或程式碼平台連結，企業便以為技術交接完成。幾個月後要更換廠商，新團隊下載程式碼，卻發現套件版本不明、資料庫少了欄位、圖片放在另一個帳號，正式環境需要哪些設定也沒有人說得清楚。

這會直接影響維護與營運持續性。安全修補可能因不敢重新發布而延後，主機故障時只能等待原廠商，換人接手還要付費逆向整理。若新團隊一邊猜設定、一邊操作正式網站，表單、會員、訂單與搜尋入口也可能在交接中中斷。

可以把原始碼想成餐廳留下的食材與廚具。材料都在，不代表另一位廚師能做出正在販售的餐點；還需要正確份量、設備條件、備料順序與出餐檢查。網站的可重建能力，就是讓合格的新團隊依照受控資料，在不依賴原作者記憶的情況下，做出可驗證的版本。

## 原始碼只是材料，正式網站還包含一條製作路徑

原始碼是開發者編寫、可供修改的程式內容。建置是把原始碼、套件與設定轉成可執行網站的過程；部署則是把完成的版本送到主機，讓使用者真正能存取。只交付原始碼，沒有建置與部署條件，就像只交零件而沒有組裝與啟動方式。

網站還可能依賴資料庫結構、上傳檔案、排程、網域、寄信、金流與其他外部服務。環境變數是依不同環境提供的設定值，例如服務網址或秘密憑證。交接文件應列出需要哪些變數、用途與保管人，但不能把密碼或金鑰直接寫進程式碼。

美國國家標準暨技術研究院（NIST）的安全軟體開發框架建議，把原始碼、可執行成果與以程式描述的設定納入受控保存，並為每次發布保留必要檔案與來源資料。小網站不必照搬大型企業流程，但交付物不能只剩一份來源不明的檔案。

## 用五個問題驗收「程式碼都交給你了」

1. **正式網站對應哪一個版本？** 公司能否從版本紀錄指出目前上線的提交、發布時間與核准人，並看出交付後是否還有未同步修改。只拿到最後一包檔案，無法可靠比較差異。
2. **相依套件與建置條件能否重現？** 確認程式語言、執行環境、套件鎖定檔與建置指令。套件鎖定檔是記錄實際使用版本的清單，可減少今天下載與半年後下載得到不同結果，但仍需要安全更新與相容性測試。
3. **設定與秘密值是否分得清楚？** 列出每個環境變數的名稱、用途、取得位置與負責人，不交付真實密碼副本。確認公司能在新環境建立自己的憑證，舊廠商離場後也能撤換。
4. **資料與外部服務的變更是否可接續？** 資料庫遷移是用可追蹤步驟調整資料表結構。要確認遷移紀錄、檔案位置、排程、網域、寄信、金流與通知服務都能對回公司帳號，並說明執行順序與回復條件。
5. **是否在乾淨環境完成一次演練？** 由未參與原開發的人，使用新建的測試環境依文件完成建置、部署與核心流程檢查。驗收證據應包含使用版本、執行步驟、缺少項目、結果與花費時間，不是原廠商在自己的電腦再次展示。

SLSA（軟體供應鏈安全等級框架）把來源證明解釋為可驗證的資訊，用來追查軟體成果在何時、何處、以何種方式產生，並連回所使用的原始碼。中小企業不一定需要導入完整框架，但至少應能把正式版本連回來源與建置紀錄。

## 便宜交付少的，常是整理、演練與接手責任

只交壓縮檔成本最低，對純靜態、少量頁面且不再修改的網站，可能足以保留內容。限制是版本歷史、套件條件與正式設定容易遺失。公司持有程式碼儲存庫、部署平台與設定清單，能降低單一廠商依賴，但仍不代表另一個人已經成功接手。

較完整的方案會加入自動建置、測試環境、版本化的資料庫變更、發布紀錄與交接演練。英國政府的部署指引強調，正式環境應能辨識正在運作的版本，並追溯到來源紀錄。這些能力增加前期建置與持續維護成本，價值在縮短修補、復原與換廠商時的猜測，不是保證永遠不出錯。

## 今天先做一次不碰正式站的重建演練

先選定目前正式版本，請廠商把程式碼入口、建置指令、必要設定名稱、資料庫變更、檔案位置與外部服務整理成一頁清單。接著使用臨時測試環境與假資料，由另一位工程人員照文件操作，驗證首頁、登入、詢價、通知及最重要的交易流程。

若演練卡住，先把問題分成「資料沒交付、文件看不懂、權限不在公司、外部服務無法替代」四類。每一類的處理方式與費用不同。不要為了證明能重建，直接刪除正式資源、複製真實客戶資料，或把秘密值貼進一般文件與通訊群組。

## 自行處理的邊界與接洽準備

企業可以先確認公司是否擁有程式碼平台與部署平台的管理權，找出正式版本，並要求現任廠商展示一次從零開始的測試建置。若網站只有公開內容，也可接受較輕量的交接，但要明確記錄日後修改與復原仍依賴誰。

若網站涉及會員、付款、個資、多套資料庫、排程或多家外部服務，或目前版本與交付程式碼對不起來，就需要開發、主機、資料與營運角色共同盤點。接洽前可準備程式碼與主機入口、最近發布時間、套件清單、環境變數名稱、資料庫變更紀錄、外部服務、核心流程與維護合約。邊境部署可以協助把這些現況整理成可重建範圍、缺口與驗收演練，先證明另一個團隊接得起來，再決定補文件、調整權限或重整發布流程。

## 查證來源

- [NIST：Secure Software Development Framework Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)
- [SLSA：Provenance](https://slsa.dev/spec/v1.2/provenance)
- [GOV.UK Service Manual：Deploying software regularly](https://www.gov.uk/service-manual/technology/deploying-software-regularly)
- [GOV.UK：The Digital, Data and Technology Playbook](https://www.gov.uk/government/publications/the-digital-data-and-technology-playbook/the-digital-data-and-technology-playbook)