合作站與自有站為什麼要拆成兩條 agent：白標的接縫不是文案問題
一句話講完：程式碼可以共用，工作方式不能。自有站與合作站現在是兩條 agent、兩份部署，同一個視窗不准同時改兩邊，因為白標真正的接縫在程式裡，不在文案裡。
我們有自己的產品，也有掛在合作方品牌底下交付的同一套產品。程式碼是同一份，這是白標的本質，不是偷懶。
程式碼可以共用，工作方式不能。這兩條線現在是兩條 agent、兩份部署，而且同一個視窗不准同時改兩邊。
為什麼不能同一個視窗
同一個視窗能改兩邊，會出兩種事故，而且兩種都很難在當下發現。
第一種是改 A 壞 B。你在自有站改一個共用元件，合作站跟著變，但你沒開合作站，所以你不知道。要等對方回報，那時候已經在他們的客戶面前了。
第二種更難看：把 B 的字串寫進 A。做完合作站的文案，切回自有站繼續做，腦袋裡還留著上一輪的用語。這種錯不會有錯誤訊息，測試也不會紅，它只是靜靜地出現在錯的品牌上。
拆線就是讓每個視窗只看得到自己那一份。不是不信任模型，是讓錯誤停在一邊。
白標的接縫不是文案問題
我原本以為白標守的是文案：不要在對方的頁面提到我方品牌，不要在我方頁面點名對方客戶。這兩件我們一直做得不錯，對外描述合作案例的時候連對方名字都沒寫。
今天查官網，發現真正的接縫在程式裡。
主站的網址帶上一個給預覽環境用的參數，整個首頁會換成合作方的品牌：對方的識別、對方的標題，而且全頁找不到我方的名字。更麻煩的是這個狀態會寫進瀏覽器，之後開乾淨的網址，出來的還是合作方版本，要清掉瀏覽器資料才會回來。
也就是說，任何人只要知道或猜到那個參數，就能在我方的網域上看到合作方的產品。文案寫得再小心都沒有用，一個查詢參數就全部露出來。
修法是把判斷收緊：正式網域只認網域，參數與瀏覽器記憶那兩條路限預覽環境使用，並且主動清掉已經被寫進去的值，之前被切過的人下次開站就會回到正常版本。改完之後我做了兩個驗證，一個是正式站帶參數應該不變，一個是預覽環境帶參數應該還能切。第二個是陽性對照，如果它也不能切，代表我不是修好了，是把功能弄壞了。
兩份部署買到什麼
最直接的是爆炸半徑：自有站出事的時候，合作站不會跟著倒，反過來也一樣。
第二是節奏。自有站可以一天推好幾次，合作交付有自己的驗收節奏，混在一起就變成兩邊互相遷就。
第三是責任邊界。出事的時候先問是哪一條線，答案兩秒鐘就出來；共用一份部署的時候，這個問題要查很久。
誠實講成本
拆線之後跨線的事變慢了。共用元件改一個，兩邊都要各自處理，不能一次改完。以前一個動作能做完的，現在要兩次，中間還要一次溝通。
我認為這個成本值得付，因為它換到的是「錯誤不會自己跨過去」。但我不想把它寫成沒有代價的最佳實踐。如果你只有一條線，不要為了將來可能有第二條而先拆，那是替想像中的問題付現在的錢。
什麼時候才拆
我的判斷是：當第二條線的收件人不是你自己的時候。
自己用的兩個專案共用一個視窗，出事你自己收。一旦另一邊的畫面會出現在別人的客戶面前，收拾的人就不只是你，那時候隔離的價值才會大於它的成本。
這是實驗室週記，不是產品承諾。
常見問題
白標交付要隔離的是什麼？
不是文案，是程式。文案層面很好守：不要在對方頁面提到我方品牌，不要在我方頁面點名對方客戶。但真正的接縫在程式裡，例如一個給預覽環境用的網址參數，就可能讓正式站整頁換成合作方的品牌，而且狀態被記在瀏覽器裡，開乾淨網址還是合作方版本。
為什麼同一個視窗不能同時改兩邊？
會出兩種事故，而且都很難在當下發現。第一種是改 A 壞 B：你在自有站改共用元件，合作站跟著變，但你沒開合作站，要等對方回報。第二種是把 B 的字串寫進 A：這種錯不會有錯誤訊息，測試也不會紅，它只是靜靜出現在錯的品牌上。
拆成兩份部署買到什麼？
三件。爆炸半徑：一邊出事另一邊不會跟著倒。節奏：自有站可以一天推好幾次，合作交付有自己的驗收節奏，不必互相遷就。責任邊界：出事先問是哪一條線，答案兩秒鐘就出來。
什麼時候才值得拆？
當第二條線的收件人不是你自己的時候。自己用的兩個專案共用一個視窗，出事你自己收。一旦另一邊的畫面會出現在別人的客戶面前，隔離的價值才會大於它的成本。只有一條線就不要為了想像中的第二條先拆。