第十二章B〈地板下面〉
港版 v1
地點：鏡界・翠鏡島 / 大陸代工廠區 / 書房 時間：1024年（交叉時間線） 視角：阿強 / 林昭明
阿強收到新case嗰日，冇覺得有咩特別。
能芯嘅新模組。第三代。架構同上兩代唔同——以前嘅模組，核心運算同周邊對接係分開嘅，你處理你嘅，我處理我嘅，中間靠標準協議溝通。第三代唔係。佢將運算同周邊整合埋一齊。一粒模組做晒。效率高。但對接嘅方式，同以前完全唔同。
呢個唔係秘密。行內嘅人都知。規格書公開嘅。技術論壇討論咗幾年。
阿強接到case，第一件事係睇靈韻合成嘅firmware。
佢做咗十五年，呢個動作係本能。你要知道自己企喺邊度，先知道問題喺邊度。
佢睇咗兩日。
唔係因為難。係因為佢要確認自己冇睇錯。
成個firmware嘅核心邏輯——唔係某一段，係成個——由boot sequence到power management到peripheral handshake，每一層嘅assumption都係寫死咗傾向舊架構。舊架構嘅意思係：以某間主流晶片商為中心。邊個係primary，邊個係secondary，成個code嘅邏輯係建立喺呢個不平等嘅前提上面。新模組唔行呢套。
阿強企喺廠房嘅走廊，望住窗外嘅天。佢知道正常嚟講應該點做——重構。至少rewrite同新架構對接嗰幾層。唔係推倒重嚟。但核心嗰幾層，你要改。因為前提變咗。你唔改，上面疊幾多嘢——不斷出update去修補——都只係喺一個傾斜嘅地基上面起樓。
佢等住靈韻合成嗰邊嘅方案。
等咗兩個禮拜。
方案嚟咗。
Workaround。
唔係一個。係一串。喺舊architecture上面，加一層translation layer，將新模組嘅protocol轉做舊格式，再餵畀firmware。中間嘅timing mismatch，用delay buffer頂住。Power state嘅差異，用一個lookup table硬map。
阿強坐喺自己嘅位，望住嗰份方案。
佢做咗十五年。佢見過workaround。間間都有。有時候deadline趕，你冇時間做proper fix，workaround係 合理嘅。臨時嘅。過渡嘅。你寫嘅時候心裡面知道——呢個之後要改返。
但佢睇得出。
呢個唔係臨時嘅。
靈韻合成好勤力咁寫workaround，但冇任何計劃去改核心邏輯。冇roadmap。冇timeline。冇人提過。呢個複雜到極點嘅workaround就係「方案」。唔係過渡。係終點。
佢望住嗰份文件嘅最後一頁。「建議方案」四個字。冇附錄。冇「Phase 2：核心邏輯調整」。冇「長期規劃」。
呢個就係全部。
Workaround行唔行？
行。大部分時候行。
但有邊角case。有timing issue。有啲情況下power state會唔同步。唔係成日發生。但會發生。
發生咗點算？
靈韻合成嘅答案：叫供應商查。
阿強查。查完。唔係供應商嘅問題。係translation layer嘅timing mismatch。佢寫喺報告入面。用字好小心。冇直接話「你哋嘅workaround有問題」。佢寫：「經分析，偏差來源與新舊協議轉換過程中的時序差異相關。建議評估base code層面的調整方案。」
回覆：「已收到。請繼續監測。」
佢繼續監測。問題再出現。佢再寫報告。
回覆：「請提供更多數據以供分析。」
佢提供。
然後靜咗。
過幾日。Firmware有一個minor update。Changelog：「穩定性優化。」
問題暫時冇再出現。
阿強知道佢哋做咗咩。佢哋做咗極之複雜嘅補救——調咗delay buffer嘅參數，加多幾條例外處理。好勤力。但治標唔治本。根本嘅核心邏輯偏向仲喺度。下次換一個邊角case，又會出嚟。然後又叫佢查。然後又加補水code。然後又「穩定性優化」。循環。
佢望返自己嗰句「建議評估base code層面的調整方案」。
喺回覆入面，呢句話冇被提及。
好似佢冇寫過。
佢之後再寫報告，冇再寫呢句。
阿強記得第一年問過一個問題。
唔係好正式嘅。係一個會議尾聲，大家收緊嘢，佢順口問咗一句。
「點解firmware只圍繞舊架構設計？新模組嗰邊嘅support⋯⋯」
佢未講完。
唔係有人打斷佢。係氣氛變咗。好微妙。好似有人喺房間入面開咗冷氣，但你搵唔到冷氣喺邊。
靈韻合成嗰邊嘅人，有一個答咗。
「呢個架構喺市場上嘅份額好細。品質仲有好多問題。我哋嘅重點係服務主流用戶。呢啲嘢交畀ODM自己handle就得。」
阿強點頭。合理。
之後另一個人喺email入面提過類似嘅嘢。用字唔同，意思一樣：「呢個架構嘅兼容性問題係已知嘅。品質同穩定性同主流方案有距離。ODM嗰邊有經驗處理。」
再之後，一個私下嘅場合，仲有人同佢講過。語氣唔同。唔係解釋。係一種⋯⋯佢嗰陣搵唔到詞。
後來佢搵到了。
嗰個語氣唔係安撫。係警告。
「呢個唔係你要理嘅嘢。」
冇人用呢句話。但每一個人嘅語氣都係呢句話。
阿強嗰陣以為係公司政策。正常嘅。每間公司都有佢嘅focus。你唔可能support晒所有嘢。呢個佢理解。
佢冇再問。
但後來——好耐之後——佢偶爾會諗返呢件事。
唔同嘅人。唔同嘅場合。一樣嘅答案。一樣嘅措辭。一樣嘅語氣。
正常嘅公司，你問一個技術問題，唔同人會有唔同角度嘅答案。有人從成本講。有人從技術講。有人從schedule講。因為每個人企嘅位唔同，睇到嘅嘢唔同。
但佢問嘅呢個問題——所有人嘅答案一樣。
阿強唔知道呢個代表咩。可能只係公司嘅official position好清晰。可能只係大家都認同呢個判斷。
可能。
阿強有一次同林昭明食飯。出差。晚餐。一間普通嘅餐廳。
公事傾完。飯食到一半 。唔知點解傾到firmware。可能係因為阿強嗰日做嘅case——又係一個兼容性issue，又係workaround，又係「供應商查一查」。佢有啲攰。攰嘅時候人會講多咗。
「林先生，你有冇留意過⋯⋯靈韻合成嘅firmware update，過去兩年，出咗幾多個？」
林昭明搖頭。
「我數過。六十幾個。」阿強飲咗啖嘢。「六十幾個。好勤力。每隔幾個禮拜就有。Feature改咗。Performance tuning做咗。Bug fix做咗。你睇changelog，好長。好詳細。好似好努力咁。」
佢停咗。
「但你知唔知——六十幾個update，改咗咁多嘢——核心嗰套邏輯有冇變過？」
林昭明望住佢。
「冇。」
阿強放低個杯。
「你要喺入面做先知。或者你要識睇數據。公開嘅changelog唔會話你。佢寫住『穩定性優化』『兼容性改善』『效能提升』——你睇完覺得好正常。但你拎住數據去對，你會發現：新架構嘅問題仲喺度。每一次改完，嗰啲邊角case仲係會出現。改咗六十幾次，核心嘅timing mismatch冇變過。因為佢改嘅嘢全部係圍繞住舊嗰套邏輯轉。」
佢望住枱面。
「佢唔係冇做嘢。佢做咗好多嘢。但做嘅所有嘢都係喺同一個框架入面。框架本身——邊個係primary，邊個係secondary——冇人掂過。」
林昭明問：「你覺得係做唔到，定係唔想改？」
阿強望住佢。呢個問題好直接。直接到佢要諗一陣先答。
「⋯⋯做唔到嘅嘢我見過。做唔到係有原因嘅。你睇得出邊度卡住，邊度資源唔夠，邊度技術仲未到。做唔到嘅樣係——有人喺度試，但未得。」
佢停咗。
「呢度唔係嗰個樣。呢度係——好畀心機去避開個核心。佢哋寧願每一次出update都寫幾百行複雜嘅workaround去補救，都唔肯改底層嗰幾行code。好似有一種無形嘅力量，寫死咗嗰個框架唔准掂。」
林昭明聽完好耐冇講嘢。佢飲咗啖水。然後問：
「你有冇諗過——點解唔准掂？」
阿強好耐冇出聲。餐廳嘅聲音喺佢哋之間流過。碗碟聲。其他枱嘅傾偈。冷氣嘅嗡嗡聲。
「我諗過。」
「你嘅答案呢？」
「⋯⋯可能唔係一個我應該知嘅答案。」
林昭明點頭。好慢。
「我明白。」
沉默。
阿強忽然講咗一樣嘢。唔係計劃好嘅。係嗰種攰到一個程度、對住一個你覺得聽得明嘅人，會唔小心講出嚟嘅嘢。
「林先生。呢啲workaround——我哋寫咗幾多、點寫嘅——你知道係唔可以寫喺明面嘅。」
林昭明望住佢。
「我知道。」
「唔係因為workaround本身有問題。Workaround間間廠都有。」
「我知道。」
阿強揸住個杯。啤酒暖咗。
「係因為——如果有人問，『你哋點解要寫咁多workaround』，答案會牽到一個地方。」
佢停咗。
「冇人想去嘅地方。」
林昭明望住佢。好耐。
「你知道嗰個地方係邊。」
阿強冇答。佢飲咗最後一啖。暖嘅。苦嘅。
「我唔知道。我只係知道——唔好問。」
林昭明嗰晚返到屋企，冇即刻開電腦。
佢坐喺書房，望住枱面。阿強嘅話喺佢腦入面轉。
「改咗咁多嘢——核心嗰套邏輯有冇變過？冇。」
「做嘅所有嘢都係喺同一個框架入面。」
「寧願寫百幾行workaround補救，都唔肯改底層嗰幾行code。」
佢想起自己喺靈韻合成入面嘅經歷。有一次，佢喺一個內部會議入面問過類似嘅問題——唔係問firmware，係問一個流程嘅設計。佢問：「點解呢個流程唔改？明明有更有效嘅方法。」
答案係乜？佢記得。唔同嘅人。唔同嘅場合。一樣嘅答案。
「呢個係historically咁做嘅。」
「改嘅風險太大。」
「你冇經驗先會覺得可以改。」
佢嗰陣以為係佢自己唔夠了解。
而家佢唔咁諗。
佢開咗電腦。
林昭明嗰晚搜尋嘅關鍵字同平時唔同。
佢打咗「品牌廠」「晶片商」「回扣」。
頭幾頁冇咩。行業新聞。產品發布。正常嘅嘢。
然後佢搵到一單舊案。
幾年前。一間品牌廠。全球前幾大。被監管機構查出——長期收取某間晶片供應商嘅巨額款項。條件係：唔用競爭對手嘅產品。
林昭明睇到呢度，停咗。
佢繼續睇。
款項嘅規模係天文數字。持續咗幾年。品牌廠嘅高層知情。佢哋將呢啲款項混入正常收入，令財報好睇。當晶片商停止支付，品牌廠嘅利潤即刻萎縮——但佢哋向投資者隱瞞咗真正嘅原因。
監管機構查咗幾年。最後品牌廠賠咗天文數字嘅和解金。高層罰款。件事上咗新聞，又好快沉咗落去。
林昭明記低咗時間線。
開始收取：某年。被查：幾年後。和解：再幾年後。
和解之後呢？
佢搵。
品牌廠嘅公告寫住：「已全面配合監管要求，完善內部合規制度。」晶片商嗰邊都有類似嘅聲明。法律程序完結。罰款交咗。件事過咗。
但佢想睇嘅唔係呢啲。
佢搵技術論壇。帖子唔多。有啲已經刪咗，靠cache先睇到殘留嘅片段。
有一個帖子，寫喺和解之後兩年。標題好平淡：「XX品牌對YY架構嘅支援現況。」
內容唔平淡。
嗰個人用咗好長嘅篇幅，逐層分析firmware嘅boot sequence。結論係：表面上不斷更新，但核心邏輯冇變。和解之前係咁，和解之後仲係咁。成個firmware嘅assumption——邊種晶片係primary，邊種係secondary——寫死喺code入面，之後所有嘅update都 只係圍住呢個assumption去修補。
有人喺下面回覆：「你expect佢哋因為一單官司就rewrite成個firmware？太天真。加workaround最平。」
又有人回：「我唔expect rewrite。我expect嘅係唔好繼續當另一個架構唔存在。但你睇佢哋過去幾十個update，寧願兜大圈加補丁，都唔肯執正個底層——到今日都仲係二等公民。」
帖子好舊。回覆唔多。後來嘅討論被刪咗幾條。
林昭明再搵。搵更近期嘅。
有。零星嘅。散落喺唔同嘅論壇。用字好小心。冇人直接講嗰句話。但有人問過——
「和解之後十幾年，firmware改咗幾百次，但架構偏向仲係一樣。如果真係冇利益關係，純粹係legacy code嘅問題——十幾年出咁多update，次次都精準避開個核心去修補？」
冇人答。
唔係冇人見到呢個問題。係冇人答得到。或者冇人敢答。
林昭明望住個螢幕。
佢喺筆記入面寫：
「開始收取——某年。」 「和解——幾年後。聲明停止。」 「和解之後至今——firmware表面狂改，但核心前提不變。Workaround不斷疊加。新架構仍然係二等公民。ODM仍然執手尾。」
佢停低。
十幾年。
如果真係停咗。十幾年你出幾百個update，寧願將個firmware寫到九曲十三彎，都唔去改底層嗰一個不平等嘅前提？你係全球前幾大嘅品牌廠。你有幾千個工程師。你每年嘅研發預算係天文數字。
十幾年。
如果真係停咗。
林昭明望住自己寫嘅嘢。佢喺最後嗰行底下，冇寫問題。只寫咗一個問號。
一個問號。
因為嗰個問題——如果寫出嚟——佢自己都唔知道意味住咩。
佢冇合埋部電腦。
佢翻返自己之前做嘅嗰張表。第十二章嗰張。左邊「間間都有」，右邊「唔同」。
右邊嗰欄。佢一條一條睇。
「明知冇問題都叫你再測。」 「零點三度叫你重做。」 「良率好返同你嘅測試冇關係。」 「你提出疑問被當冇講過。」 「結論先定好，叫你測試只係填過程。」
佢將呢啲同firmware嘅資料擺埋一齊。
然後佢做咗一件事——佢翻返過去兩年嘅測試紀錄。唔係全部。係佢記得嘅。阿強講過嘅。論壇上面見到嘅。
佢開始留意一個pattern。
被叫做無限測試嘅case——「做完再做、結果一樣、但要你繼續做」——嗰啲case，涉及嘅產品，有一個共同點。
唔係所有產品都被咁對待。有啲產品嘅測試流程正常得多——有問題就查，查到就修，修完繼續。同阿祥講嘅其他品牌廠嘅做法一樣。
但有一類產品——用新架構嘅產品——嘅測試流程唔同。嗰種「做完再做」嘅pattern，集中喺呢類產品上面。
林昭明望住呢個pattern。
佢唔確定。佢手上嘅數據唔夠。佢冇辦法access靈韻合成嘅內部紀錄。佢只有阿強嘅碎片、論壇嘅碎片、自己嘅記憶碎片。
但碎片擺埋一齊，有一個形狀。
如果firmware嘅base code從來唔打算properly support新架構—— 如果呢個decision背後有歷史原因—— 如果呢個歷史原因唔可以被承認——
咁無限測試嘅功能就唔係「搵問題」。
係製造紀錄。供應商嗰邊全部pass。所以問題唔喺供應商嗰邊。所以問題喺邊？冇人知。或者有人知。但紀錄上面寫住：我哋查過。我哋做過。我哋盡責。
係消耗資源。供應商嘅人忙到冇命做測試、寫報告、開會、再測試。冇時間企後一步問：「等等，呢個問題係咪其實喺firmware嗰邊？」因為佢哋忙。因為下一份報告嘅deadline喺度等。
係建立narrative。做得夠多次之後，連供應商自己都開始懷疑——係咪真係我哋嘅問題？阿強做咗十五年都講唔出邊度唔對。因為佢做咗咁多測試，做到佢自己都唔確定。
林昭明望住自己寫嘅嘢。
佢喺最底加咗一行：
「唔係人有問題。係個system由出世嗰日開始就係咁設計嘅。人只係行緊個system叫佢行嘅路。」
佢停咗。
然後加咗兩個字：
「包括我。」
阿強揸住枝筆。
又一份報告。又一頁。結論欄。
「測試結果符合規格要求，未發現異常。建議維持現行方案並持續監測。」
佢嘅筆停咗一秒。
唔係唔簽。唔係猶豫。係一種⋯⋯佢以前冇過嘅感覺。好似佢嘅手記得一啲佢個腦仲未整理好嘅嘢。
嗰封email。「可以用嚟支持我哋嘅結論。」
嗰六十幾個firmware update。好勤力，但核心邏輯從來冇變。
嗰啲唔同嘅人用同一種語氣講嘅同一句話：「呢個唔係你要理嘅嘢。」
佢嘅名字喺幾百份報告上面。每一份都係真實嘅。佢做咗測試。結果係咁。佢冇造假。冇一份係假嘅。
但呢啲報告喺靈韻合成嘅系統入面扮演緊咩角色——呢個佢唔知。佢只知道：佢嘅簽名入咗系統之後，去咗邊、被點用、出現喺咩文件入面、支撐住咩結論——呢啲佢掂唔到。
佢以前覺得呢個正常。品牌廠嘅internal嘢，供應商本來就唔需要知。呢個係行規。
但如果——
如果佢嘅簽名唔止係「我做咗測試」？如果佢嘅簽名係「供應商確認冇問題」？如果「供應商確認冇問題」呢句話喺靈韻合成嘅系統入面，被用嚟支撐另一個結論——「所以問題唔喺firmware」？
如果佢嘅簽名係一份保險單嘅一部分？
阿強望住枝筆。
佢唔知道。佢真係唔知道。可能只係佢諗多咗。可能佢嘅報告就係佢嘅報告，冇人用嚟做其他嘢。可能靈韻合成嘅firmware唔改base code， 真係因為legacy太深，改唔到。可能一切都有合理嘅解釋。
可能。
但佢做咗十五年。六間品牌廠。佢知道——當所有人用同一種語氣警告你「唔好問」嘅時候，通常唔係因為答案唔重要。
係因為答案太重要。
佢簽名。日期。放埋去右手邊嗰疊。
但呢次，佢嘅手記住咗嗰一秒嘅停頓。
林昭明合埋部電腦。
書房好靜。窗外冇風。
佢而家知道嘅嘢比一個月前多好多。但「知道」呢件事本身，佢唔知道有冇用。
佢知道firmware表面狂改但核心不變。佢知道有歷史。佢知道有pattern。佢知道阿強感覺到嘅嘢同佢感覺到嘅嘢係同一件事嘅兩面。
但佢冇proof。
佢冇靈韻合成嘅internal文件。冇firmware嘅source code。冇商業協議嘅紀錄。冇任何人嘅書面確認。佢有嘅只係：碎片。阿強嘅幾句話。論壇上面嘅殘留帖子。一單十幾年前嘅和解案。同一份六十幾個update、但核心邏輯從來冇變嘅changelog。
碎片擺埋一齊，有一個形狀。但形狀唔係proof。
而且——佢想起阿強講嘅——呢啲workaround嘅數量同細節，係唔可以寫喺明面嘅。品牌廠嘅黑盒入面嘅嘢，佢掂唔到。ODM嘅internal紀錄，佢更加掂唔到。
仲有一層。
公司轉過型。系統換過。舊嘅database退役。舊嘅紀錄format唔compatible。你想翻查？查唔到。唔係因為有人擋你。係因為「系統已經升級咗」。
三層封鎖。
第一層：畀你睇嘅嘢，已經過濾過。你以為你掂到核心，其實你掂到嘅係佢哋劃畀你嘅邊界。
第二層：過濾背後仲有嘢。真正嘅decision、真正嘅安排——從來冇出過某幾個人嘅範圍。
第三層：轉型令raw data斷裂。就算你有一日有權限去查，你都查唔到。因為嗰啲data已經唔存在喺任何你可以access嘅地方。唔係被刪。係被「淘汰」。
林昭明望住自己嘅筆記。
佢寫嘅嘢，喺呢個世界上面，證明唔到任何嘢。
佢知道。
但佢仲係寫。
因為阿強嘅手停咗一秒。老周退咗休走咗。嗰個匿名嘅人冇再上線。阿祥仲喺度做、覺得行業就係咁。佢嘅三個朋友入面，頭兩個覺得佢嘅問題好奇怪，第三個知道但唔想講。
呢啲人——每一個——都摸到咗呢隻大象嘅一部分。但冇一個人見到成隻。因為個system嘅設計就係令每個人只睇到自己嗰一塊，然後以為嗰一塊就係全部。
林昭明唔確定自己見唔見到成隻。可能佢見到嘅只係比其他人多一塊。可能佢嘅拼圖仲有好多塊缺咗。可能佢砌錯咗。
但佢知道一件事。
嗰隻大象存在。
唔係佢幻想出嚟嘅。
我坐喺書房。枱面嘅嘢攤開咗好耐。
阿強嘅話。老周嘅比喻。論壇嘅帖子。一單十幾年前嘅和解案。六十幾個firmware update。一個問號。
我以為靈韻合成嘅問題係管理。係文化。係某幾個人嘅做事方式。我以為如果換一批人，件事會唔同。
但如果唔係人嘅問題呢？
如果成個firmware——成個系統——由第一日開始就係為咗某一種特定嘅安排而設計嘅？如果嗰個設計嘅DNA入面，已經寫死咗規則？如果呢個DNA喺code入面，喺流程入面，喺每一個工程師嘅習慣入面，深到你換幾多人都換唔走？
咁阿強嘅測試就唔止係「管理問題」。
佢嘅名字喺幾百份報告上面。佢嘅簽名係真實嘅。每一次佢簽名，佢以為自己喺確認「我做咗測試，結果係咁」。
但喺個system入面，佢嘅簽名嘅意思可能係另一樣嘢。
可能。我唔確定。我冇proof。
但嗰個pattern——無限測試集中喺某一類產品、firmware表面狂改但核心不 變、workaround不斷疊、所有人用同一種語氣警告你唔好問——呢個pattern唔係隨機嘅。
隨機唔會咁整齊。
我唔知道呢幅圖有幾大。我唔知道地板下面仲有幾多層。每次我以為到底，就發現下面仲有。
但有一樣嘢我而家知道：
當所有人都話「呢個唔係你要理嘅嘢」——
嗰個嘢，通常就係最需要理嘅嘢。
精采看點：
「第十二章A建立咗『地獄分層——表面一樣，底層唔同』。第十二章B回答『底層唔同嘅原因』——但唔係畀一個確定嘅答案。係畀一幅林昭明用碎片拼出嚟嘅圖。圖入面有事實（和解案）、有觀察（firmware偏向）、有感覺（統一口徑嘅警告語氣）、有推斷（無限測試嘅功能）。但冇proof。永遠冇proof。因為三層封鎖——過濾、隱藏、淘汰——確保proof永遠唔會存在。呢個唔係故事嘅弱點。呢個係故事嘅核心。」