2026 年，客戶與接案工作室之間的多數糾紛不是品質問題。是擁有權問題。Codebase 出貨、系統運作、發票收完——18 個月後，客戶想換廠商、想自己改一個模組、想賣公司，才發現合約並沒有真正轉移他們以為已經轉移的東西。本文走過我們寫進每一份合約的三條文字，每條究竟說什麼，以及這些條文是為了避免哪些失敗模式。
這不是法律意見。這是一份「我們使用的合約形狀」的書面說明，讓潛在客戶知道自己在簽的合約裡該看什麼——不論他們最後簽的是我們、還是別人。
一、為什麼傳統「Work for Hire」條款已經不夠
從 2000 年代初開始，標準接案合約模板都靠單一一條「Work for Hire」條款：「本案下產出的所有交付物，為客戶之獨家財產。」當「交付物」意指「一張 CD 裡的 PHP 檔案夾」時，這條已經足夠。2026 年不夠。現代建置包含：AI 生成的程式碼、AI 生成的測試、各種不同授權的第三方相依、接案商內部函式庫、跑在接案商雲端帳號的 infrastructure-as-code、用來營運系統的模型權重與 prompts、註冊到外部平台的內容 schema。一條只說「交付物是你的」的文字，對上面每一項都沉默——沉默之處就是糾紛之處。
二、合約文字一：原始碼與衍生作品擁有權
第一條文字在三個子點上明確表述。
原始碼本身。 提交到專案 repository 的每一行原始碼——包含經工程師審查並接受的 AI 生成程式碼——在每階成果付款時轉移給客戶。不是在專案結束時——是在分階付款時。這件事很重要，因為它封頂了客戶的曝險：合作如果在第三階之後破局，客戶擁有的是「截至第三階為止的工作」，不是零。
衍生作品。 接案商在交付後對 codebase 所做的任何修改、分支、延伸——例如，接案商把類似模式用在未來的合作上——不會回溯主張擁有權。接案商保留在另一條「可重用技術」例外下重用通用模式（Laravel scaffolding 形狀、常見 Vue 元件）的權利，但專案專屬的業務邏輯、schema、code path 無條件歸客戶。
第三方相依。 合約列出專案依賴的每一個 Composer、npm、pub 等套件，含每一個的授權。客戶收到的不是只有 lockfile，是一份書面化的 bill-of-materials。如果某個相依在交付後改變授權條款（會發生），客戶知道自己該稽核什麼。
三、合約文字二：倉庫保管與存取
擁有但不掌管是空話。第二條文字處理「程式碼實體放在哪、誰控制存取」。
Repository 從第一天起就放在客戶帳號下。 不是接案商的。客戶開設 GitHub、GitLab 或 Bitbucket 組織，授予接案商 push 權限。合作結束時，接案商把自己移出；客戶不需要「轉移」任何東西——因為沒有東西要轉。Repo 從未離開他們的帳號。
憑證放在客戶的 secret manager。 AWS Secrets Manager、HashiCorp Vault、1Password Teams——客戶本來放秘密的地方都行。接案商在合作期間持有工作用副本，合作結束時 rotate 掉。接案商在合作結束後，絕不保留對客戶憑證的存取——即使是為了「支援」。
Build artifacts 與 container registry 也在客戶帳號下。 Docker Hub、GitHub Container Registry、AWS ECR——接案商把 image 推到客戶的 registry，不是自己的。同一個邏輯：合作結束時，客戶的部署管線繼續運作，因為什麼東西都不需要搬。
接案商不保留任何「稽核副本」。 聽起來多餘，但必須明白寫清楚：接案商在交付後不在自己伺服器上保留生產 codebase 的副本。存在的唯一副本都在客戶帳號內。合約明訂這件事，接案商書面遵守。
四、合約文字三：AI、模型與 prompts 的 IP 條款
這是 2023 年合約沒有、2026 年合約必須有的條款。
AI 生成的程式碼，視同人類撰寫的程式碼處理。 合作期間由 Claude Code、Cursor、GPT 或任何助手生成的每一行，都經資深工程師審查與簽核，然後在分階付款時和人類撰寫的程式碼一樣移轉給客戶。接案商不會以「AI 寫的」為由保留任何殘留權利。
用來建構代理式功能的 prompts 與系統指令。 如果專案包含 AI 代理人——聊天機器人、副駕駛、自動化工作流——驅動這些代理人的 prompts 屬於交付物的一部分。合約將它們命名為「可保護的智慧財產，移轉給客戶」。這件事重要的原因是：2026 年很多專案裡，prompts 就是產品。
模型權重與微調資料。 如果專案用客戶資料訓練或微調過模型，產出的權重屬於客戶、訓練資料仍歸客戶、接案商不保留兩者的副本。如果接案商用的是託管模型（Claude、GPT、Gemini），合約明訂這些供應商的資料處理條款，並確認客戶資料不被保留用於訓練。這條對雙向都明確：客戶不擁有底層 foundation model，但用他們資料訓練出來的一切都是他們的。
可重用技術例外。 接案商保留將合作期間學到的「通用 AI 開發技術」——prompting 模式、agent 編排形狀、評估框架——應用在未來合作的權利。這個例外是「窄」且「具名」的。它不涵蓋客戶專屬 prompts、業務邏輯或資料。
五、這三條文字防止的三個失敗模式
每一條的存在，都是因為我們親眼看過某個真實失敗模式。
失敗模式一： 交付後 18 個月，客戶想換廠商。新廠商拿不到 repo——repo 放在原接案商的 GitHub 帳號下，而原接案商開始反應變慢。倉庫保管那條防止這個；客戶從來不需要「遷移 repo」，因為 repo 一直就是他們的。
失敗模式二： 客戶想賣公司，買方盡職調查標記「原始碼 IP 轉移不明」。併購卡住。逐階分明的擁有權條款讓這件事瞬間清楚：客戶指向每一階的付款紀錄、買方律師簽字。
失敗模式三： 客戶想從一家 AI 廠商換到另一家，發現 prompts 與編排邏輯從未明確被移轉。他們要嘛重建、要嘛付錢給原接案商把 prompts 抽出來。AI 條款那條防止這個；prompts 從一開始就是客戶 IP。
六、每位新客戶都會走過的入場對話
開始寫任何程式碼之前，我們會帶每位新客戶走過一個小時的對話，用大白話確認上面三條合約文字。問題很簡單：
- Repo 要放在哪一個 GitHub 或 GitLab 組織下？（如果他們還沒有，我們等他們建好。）
- 秘密放在哪？（如果還沒有 secret manager，我們建議一個並等他們設定好。）
- 接受分階付款的法律簽字人是誰？（這決定誰在法律上接手每一階的所有權。）
- 範圍內是否有任何第三方 AI 服務含資料保留或訓練權條款，我們需要點名？（幾乎一定，至少一項服務有。）
- 客戶是否希望合約裡有「繼任廠商」條款，未來若需遷移可自動化交接？（我們建議有。）
這段對話通常讓 kickoff 多花一小時，但能省掉之後幾個月的糾紛風險。它對接案商這邊也是一個有用的過濾：拒絕走這段對話的客戶，傾向於後來會主張合約寫了它沒寫的事。
七、附在每份工作說明書（SOW）後面的兩頁合約附錄
上面三條文字放在一份兩頁的附錄裡，附在我們簽的每一份 SOW 後面。附錄逐案相同；SOW 逐案不同。附錄包含擁有權條款、倉庫保管條款、AI IP 條款、bill-of-materials 模板、以及一條「繼任廠商協助」條款——要求我們在客戶未來移轉時以標準時薪提供合理交接協助。Bill-of-materials 在專案進行中填寫、在最末階交付時完稿。
把附錄標準化的理由是：它把「合約談判」從每次合作中拿掉，把對話拉回它該停留的地方——範圍與價格。客戶在比較我們和其他接案商時，可以向每一家索取等價附錄；做不出來、或交不出快的那幾家，正在透露他們處理這些問題的方式。
如果你這一季正在評估和任何接案夥伴的合作——我們或其他人——「請拿你們的合約附錄」是最有用的單一篩選問題。五分鐘內，答案會告訴你：你正要簽的合約，在第 731 天還能不能服務你。