Caira 可以在 3 次點擊內審閱你的合約：

• 直接將建議修改和註解加到你的檔案中

• 生成電郵摘要，傳送給對方

註冊免費試用少於 30 秒。無需信用卡：開始免費試用

「在我電腦上運作正常」：為何網頁開發者需要更好的合約

網頁開發界一直被「期望落差」困擾。

你交付符合規格的程式碼。客戶用一部 2014 年的 iPhone 6 打開，然後大叫 「壞咗！」

你建好他們要求的 CMS。六個月後，他們又打電話來，要求你修復一個由 他們 安裝的外掛所造成的 bug。

開發是理性的。客戶是情緒化的。你的合約就是兩者之間唯一的橋樑。沒有它，你就等於接受一輩子的無償技術支援。

以下是你需要在《業務條款》中修補的法律漏洞。

1. 「瀏覽器相容性」的黑洞

情景： 你做了一個俐落的 React 網站。它在 Chrome 和 Safari 上都運作順暢。客戶的 CEO 卻在辦公室用 Internet Explorer 11 打開。網格版面崩壞。對方扣住款項，直到「所有裝置都能用」為止。

法律現實：

「所有裝置都能用」在技術上根本不可能。若沒有明確列明，法庭可能會把「功能正常的網站」解讀為「在標準商業工具上可運作」，而這甚至可能包括較舊的瀏覽器。

解決方法：

加上一條支援瀏覽器條款。

要具體。「本網站設計為可於 Chrome、Safari、Firefox 及 Edge 的最新兩個版本上運作。除非在規格中明確同意，否則不包括對舊版瀏覽器（例如 IE11）的相容性。」

2. 驗收測試（「上線」觸發條款）

情景： 你完成網站。你把連結發出去。「有什麼想法記得告訴我。」

3 個星期都沒有回音。

然後：「可以改一下字體嗎？」

再過 2 個星期又沒聲音。

然後：「其實，可以把 logo 移一移嗎？」

你已經過了截止日期 3 個月，最後 50% 的款項還沒收到。

法律現實：

如果沒有明確定義「驗收期」，項目就會進入殭屍狀態。它既不是完成，也不是未完成。

解決方法：

加上一條「視作接納」條款。

「客戶自交付日起有 7 天時間測試軟件。若在 7 天內未有以書面形式報告任何具體『錯誤』（定義為當機／嚴重故障），則軟件將被視作已接納，而尾款即告到期。」

這樣就會逼他們檢查，否則就要付款。

3. 範圍蔓延（「只係一個小改動」）

情景： 你報價做 5 個頁面。做到一半，客戶把文案傳來。結果有 12 個頁面。「我只是把 About 頁拆開了而已，沒什麼大不了吧？」

這當然是大問題。這牽涉到導覽邏輯、流動選單影響，以及內容輸入時間。

解決方法：

不要再以「一個網站」報價。要以「一項工作範圍」報價。

• 嚴格交付項目：「5 個靜態頁面。1 個聯絡表格。」

變更條款： 「任何超出本範圍的具體要求，將按我們的標準每小時 £[X] 收費。開發將暫停，直到 Vairation 獲批准為止。」*

4. 程式碼歸誰？（IP 權利）

情景： 你使用你慣常的「Starter Theme」，或者是你多年前寫下的一套 helper functions。客戶之後和你鬧翻，並要求取得所有程式碼的「完整版權轉讓」。

如果你把所有東西都轉讓出去，法律上你之後就不能再把自己的 starter theme 用到下一個客戶身上。你賣掉的是「工具」，不只是「屋子」。

解決方法：

要分清「客製程式碼」和「背景 IP」。

「開發者於全數付款後，將客製設計及文字排版的版權轉讓予客戶。」*

「開發者保留所有『背景 IP』（可重用的函式庫／框架）的擁有權，並授予客戶一項永久、非獨家的授權，僅供本網站使用。」*

5. 「終身」修正漏洞

情景： 網站上線了。兩年後，WordPress 更新，網站壞了。客戶打來：「係你做的，你就修好。」

解決方法：

加上一個保固期。

「我們在上線後提供 30 天保固期，以修復上線時已存在的 bug。任何在 30 天後才出現，或由第三方更新（外掛／瀏覽器變更）所造成的問題，均屬需收費的維護工作。」

點解合約審閱就係你嘅文件說明

你會為程式碼加註解。你亦應該為你的商業關係加註解。

AI 合約審閱會解析你的開發協議。它會檢查你有沒有不小心承諾了「適用於特定用途」（一個很高的法律門檻），而不是「合理技能與謹慎」。它確保你的「驗收」流程滴水不漏。它幫你交付項目並收到款項，而不留下遺留債務。

免責聲明：本文資訊僅供一般參考，不擬作為專業法律、財務、稅務或醫療建議。