第349章 白皮書交付！韓委員的反饋！德勤的盲測挑戰！
2004年四月二十七號。周二。
早上八點。工作室。
蘇明遠把列印好的白皮書裝進文件袋——兩百九十五頁，三百份精裝裝訂。旁邊還有一張光碟，存著電子版。
"韓委員那邊怎麼送？"
"兩份。"林遠說，"一份快遞到德勤北京代表處，韓委員親收。一份電子版郵件發過去，附英文摘要。Morrison和Hayes看英文版，韓委員看中文版。"
"快遞今天能到？"
"同城快遞，明天上午之前肯定到。但韓委員如果急著看，會先看電子版。"
蘇明遠把文件袋封好。"那我們等反饋？"
"等。但別乾等。"林遠走到白板前，"今天開始做演示方案的第一版——八個小時的演示，每一分鐘都要設計。"
上午十點。
團隊圍坐在會議區。白板上畫著演示的時間軸。
"八個小時，分四個板塊。"林遠說，"上午兩個半小時：引擎架構講解加四標準並行運行的實時演示。午餐一小時——非正式交流，不談技術，建立關係。下午三個小時：衝突消解引擎、行業聚類發現、多方衝突處理。最後一個半小時：白皮書核心回顧加合作展望。"
"上午的實時演示用什麼數據？"趙強問。
"還是那兩千零三萬條測試數據。"林遠說，"架構講解部分需要穩定的、可重複的演示環境。測試數據我們已經跑了十幾輪，結果完全可控。"
"下午呢？"
"下午是重點。"林遠說，"衝突消解引擎的演示——我要用行業聚類後的矩陣視圖。先展示製造業的衝突模式，再展示服務業，最後展示那個四方衝突的案例。層層遞進。"
"演示順序有講究？"王晨問。
"有。"林遠說，"Morrison是項目合伙人，他關心'這東西能不能用'。所以先給他看最直觀的——矩陣視圖，顏色標記，一點就出詳情。讓他覺得'哇，這個好懂'。"
"Hayes呢？"
"Hayes是技術把關人。他不看界面——他看架構。所以架構講解那部分，我要花二十分鐘講衝突消解引擎的分層設計。兩方衝突怎麼比對，三方衝突怎麼分層，多方衝突怎麼處理。"
趙強說："他會追問技術細節。"
"當然。所以我需要準備三套回答——表層回答給Morrison聽，技術回答給Hayes聽，兜底回答給最壞的情況。"
全網首發更新 讀小說選 TW 看書網，𝘀𝗵𝘂.𝘁𝘄超流暢
"兜底回答？"
"如果Hayes問到一個我們沒準備過的問題——我不能說'這個我們還沒考慮'。要有一個通用的回答框架：'這個問題的本質是XX，我們的架構設計原則是YY，具體實現是ZZ。'即使沒有現成答案，也要讓對方覺得我們有能力找到答案。"
蘇明遠在旁邊聽著，插了一句："這是商務談判的技巧。"
"這是所有說服術的核心。"林遠說，"不是讓對方覺得你什麼都知道——而是讓對方覺得你什麼都能搞定。"
下午三點。
蘇明遠的電話響了。
他看了一眼來電顯示，表情變了。"韓委員。"
林遠做了個手勢——開免提。
"林遠，白皮書我看了。"韓委員的聲音很平靜，"電子版今天上午收到的，我看了三個小時。"
"您覺得怎麼樣？"
"說實話——超出預期。"韓委員說，"行業聚類那一段寫得非常好。多方衝突的分層處理也很有想法。但我今天打電話不是來誇你的。"
林遠沒說話，等著。
"Morrison和Hayes到北京之後，不只是看你的演示。"韓委員說，"Hayes提了一個要求——他要從德勤自己的項目檔案里抽一份真實的審計數據，用你的引擎跑一遍。"
工作室里安靜了。
"他要盲測。"韓委員說，"不告訴你數據內容，不告訴你預期結果。你的引擎跑完之後，和德勤去年的審計結論做比對。"
蘇明遠看了林遠一眼。
"韓委員，"林遠說，"這份數據什麼時候給？"
"明天。我讓 Morrison 的團隊把數據脫敏後發過來。一家製造業企業，五年的完整審計底稿。去年這個項目有四十七組跨標準衝突——是德勤內部已知的。"
"四十七組。"林遠重複了一遍。
"對。你的引擎如果能找到其中四十組以上——Hayes會認可。找到全部四十七組——他會 impressed。"
"如果找不到呢？"
韓委員沉默了一秒。"找不到，說明你的引擎只是在測試數據上表現好。真實場景和測試數據是兩回事。"
"我明白了。"
"林遠，我不瞞你——Hayes這個人，做事很嚴謹。他不是來走過場的。他是真的在評估這套引擎能不能納入德勤的全球技術框架。"
"謝謝韓委員提醒。"
"還有一件事。"韓委員說，"那份數據量可能比你想像的大。那家製造業企業有海外業務，審計底稿里混了國際財報準則和當地準則的交叉引用。不純粹是美國政府會計和國際財報準則的對比。"
"也就是說——數據里有噪音。"
"對。有噪音，有冗餘，有格式不一致的地方。真實數據都是這樣的。"
林遠想了想。"我們的引擎設計的時候考慮過這種情況嗎？"
"你告訴我。"韓委員說。
"考慮過。"林遠說，"數據預處理層有格式標準化模塊，能處理XBRL、XML、CSV三種格式的混合輸入。噪聲數據——只要不影響審計邏輯的完整性，引擎會標記為'數據質量問題'，和'審計結論衝突'分開處理。"
"好。"韓委員說，"那明天數據到了，你們先做預處理。後天——2004年四月二十九號——跑盲測。我要在2004年五月一號之前看到結果。"
"明白。"
掛了電話，工作室里安靜了十幾秒。
蘇明遠第一個開口。"盲測。四十七組衝突。真實數據。"
"對。"
"這和白皮書不一樣。白皮書是我們自己寫的內容——每一個字都在掌控之中。盲測是別人出的題——我們不知道答案。"
"所以才叫盲測。"林遠說。
趙強一直沉默。這時候他開口了。
"四十七組已知衝突——這是德勤自己的審計師去年手動找到的。數量不一定完整。"
林遠看向他。
"真實數據里的衝突，不一定只有四十七組。"趙強說，"人工審計會遺漏。如果我們的引擎找到了五十組、六十組——多出來的那些，怎麼處理？"
林遠想了幾秒。"多出來的，標註為'人工審計未發現的新衝突'。如果這些衝突經得起驗證——那就不只是'通過盲測'了。"
"那是什麼？"
"那是證明我們的引擎比人工審計更強。"
趙強點頭。"明白了。"
下午四點。
林遠站在白板前，把演示方案擦掉一半，重新寫：
新增任務：德勤盲測
4.28（周三）：接收數據 + 預處理
4.29（周四）：引擎運行 + 結果比對
4.30（周五）：結果報告 → 交付韓委員
盲測目標：
基準線：找到47組已知衝突中的40組（85%）
目標線：找到全部47組（100%）
驚喜線：發現人工審計遺漏的額外衝突
"四天。"蘇明遠說，"白皮書剛交出去，盲測就來了。"
"這不是壞事。"林遠說，"韓委員願意讓我們用真實數據測試——說明他認真對待這件事。如果他只是敷衍，隨便找個測試數據走個過場就行了。"
"你的意思是——盲測本身就是信任的信號？"
"對。但信任不等於通過。"林遠說，"Hayes出這道題，不是為了為難我們。他是想知道：這套引擎在真實世界的泥潭裡，還能不能跑。"
"泥潭？"
"真實數據就是泥潭。格式混亂、欄位缺失、準則交叉引用斷裂——測試數據是 cleaned 過的，真實數據不會。"
趙強說："數據預處理模塊需要加強。現有的格式標準化只處理三種格式——如果德勤的數據里有第四種格式呢？"
"先等數據到了再說。"林遠說，"今晚把數據預處理的代碼重新審一遍，把所有可能的問題列出來。明天數據一到，立刻開始。"
晚上七點。
林遠回到宿舍。
桌上攤著北達的課本——高等數學、作業系統、編譯原理。期中考試在五月中旬，他已經有兩周沒翻課本了。
他翻開作業系統課本，看了二十分鐘。進程調度、內存管理、文件系統。這些知識和引擎開發直接相關——調度器的無鎖設計、上下文切換的開銷優化，底層原理都在這本書里。
但他現在滿腦子都是盲測。
四十七組衝突。真實數據。泥潭。
他合上課本，在腦子裡過了一遍引擎的數據預處理流程。
格式標準化→欄位映射→數據清洗→完整性校驗→送入審計引擎。
每一步都可能出問題。每一步都必須穩健。
"小艾，德勤的審計底稿通常用什麼格式？"
"主流是XBRL。"小艾說，"但二零零四年的XBRL標準還不成熟，很多事務所用的是自定義的XML Schema。德勤自己的格式叫Deloitte Audit Format——DAF，本質上是XBRL的變體，但擴展了大約百分之十五的自定義欄位。"
"自定義欄位——意味著我們的欄位映射表可能缺東西。"
"對。但自定義欄位通常不影響核心審計邏輯。關鍵是把標準欄位正確映射過來。"
"嗯。"林遠說，"明天數據到了，第一件事——分析DAF格式的欄位結構。"
他在筆記本上寫下四個字：數據預處理。
然後翻回課本，繼續看進程調度。
考試要過。盲測要贏。兩件事都不能丟。
早上八點。工作室。
蘇明遠把列印好的白皮書裝進文件袋——兩百九十五頁，三百份精裝裝訂。旁邊還有一張光碟，存著電子版。
"韓委員那邊怎麼送？"
"兩份。"林遠說，"一份快遞到德勤北京代表處，韓委員親收。一份電子版郵件發過去，附英文摘要。Morrison和Hayes看英文版，韓委員看中文版。"
"快遞今天能到？"
"同城快遞，明天上午之前肯定到。但韓委員如果急著看，會先看電子版。"
蘇明遠把文件袋封好。"那我們等反饋？"
"等。但別乾等。"林遠走到白板前，"今天開始做演示方案的第一版——八個小時的演示，每一分鐘都要設計。"
上午十點。
團隊圍坐在會議區。白板上畫著演示的時間軸。
"八個小時，分四個板塊。"林遠說，"上午兩個半小時：引擎架構講解加四標準並行運行的實時演示。午餐一小時——非正式交流，不談技術，建立關係。下午三個小時：衝突消解引擎、行業聚類發現、多方衝突處理。最後一個半小時：白皮書核心回顧加合作展望。"
"上午的實時演示用什麼數據？"趙強問。
"還是那兩千零三萬條測試數據。"林遠說，"架構講解部分需要穩定的、可重複的演示環境。測試數據我們已經跑了十幾輪，結果完全可控。"
"下午呢？"
"下午是重點。"林遠說，"衝突消解引擎的演示——我要用行業聚類後的矩陣視圖。先展示製造業的衝突模式，再展示服務業，最後展示那個四方衝突的案例。層層遞進。"
"演示順序有講究？"王晨問。
"有。"林遠說，"Morrison是項目合伙人，他關心'這東西能不能用'。所以先給他看最直觀的——矩陣視圖，顏色標記，一點就出詳情。讓他覺得'哇，這個好懂'。"
"Hayes呢？"
"Hayes是技術把關人。他不看界面——他看架構。所以架構講解那部分，我要花二十分鐘講衝突消解引擎的分層設計。兩方衝突怎麼比對，三方衝突怎麼分層，多方衝突怎麼處理。"
趙強說："他會追問技術細節。"
"當然。所以我需要準備三套回答——表層回答給Morrison聽，技術回答給Hayes聽，兜底回答給最壞的情況。"
全網首發更新 讀小說選 TW 看書網，𝘀𝗵𝘂.𝘁𝘄超流暢
"兜底回答？"
"如果Hayes問到一個我們沒準備過的問題——我不能說'這個我們還沒考慮'。要有一個通用的回答框架：'這個問題的本質是XX，我們的架構設計原則是YY，具體實現是ZZ。'即使沒有現成答案，也要讓對方覺得我們有能力找到答案。"
蘇明遠在旁邊聽著，插了一句："這是商務談判的技巧。"
"這是所有說服術的核心。"林遠說，"不是讓對方覺得你什麼都知道——而是讓對方覺得你什麼都能搞定。"
下午三點。
蘇明遠的電話響了。
他看了一眼來電顯示，表情變了。"韓委員。"
林遠做了個手勢——開免提。
"林遠，白皮書我看了。"韓委員的聲音很平靜，"電子版今天上午收到的，我看了三個小時。"
"您覺得怎麼樣？"
"說實話——超出預期。"韓委員說，"行業聚類那一段寫得非常好。多方衝突的分層處理也很有想法。但我今天打電話不是來誇你的。"
林遠沒說話，等著。
"Morrison和Hayes到北京之後，不只是看你的演示。"韓委員說，"Hayes提了一個要求——他要從德勤自己的項目檔案里抽一份真實的審計數據，用你的引擎跑一遍。"
工作室里安靜了。
"他要盲測。"韓委員說，"不告訴你數據內容，不告訴你預期結果。你的引擎跑完之後，和德勤去年的審計結論做比對。"
蘇明遠看了林遠一眼。
"韓委員，"林遠說，"這份數據什麼時候給？"
"明天。我讓 Morrison 的團隊把數據脫敏後發過來。一家製造業企業，五年的完整審計底稿。去年這個項目有四十七組跨標準衝突——是德勤內部已知的。"
"四十七組。"林遠重複了一遍。
"對。你的引擎如果能找到其中四十組以上——Hayes會認可。找到全部四十七組——他會 impressed。"
"如果找不到呢？"
韓委員沉默了一秒。"找不到，說明你的引擎只是在測試數據上表現好。真實場景和測試數據是兩回事。"
"我明白了。"
"林遠，我不瞞你——Hayes這個人，做事很嚴謹。他不是來走過場的。他是真的在評估這套引擎能不能納入德勤的全球技術框架。"
"謝謝韓委員提醒。"
"還有一件事。"韓委員說，"那份數據量可能比你想像的大。那家製造業企業有海外業務，審計底稿里混了國際財報準則和當地準則的交叉引用。不純粹是美國政府會計和國際財報準則的對比。"
"也就是說——數據里有噪音。"
"對。有噪音，有冗餘，有格式不一致的地方。真實數據都是這樣的。"
林遠想了想。"我們的引擎設計的時候考慮過這種情況嗎？"
"你告訴我。"韓委員說。
"考慮過。"林遠說，"數據預處理層有格式標準化模塊，能處理XBRL、XML、CSV三種格式的混合輸入。噪聲數據——只要不影響審計邏輯的完整性，引擎會標記為'數據質量問題'，和'審計結論衝突'分開處理。"
"好。"韓委員說，"那明天數據到了，你們先做預處理。後天——2004年四月二十九號——跑盲測。我要在2004年五月一號之前看到結果。"
"明白。"
掛了電話，工作室里安靜了十幾秒。
蘇明遠第一個開口。"盲測。四十七組衝突。真實數據。"
"對。"
"這和白皮書不一樣。白皮書是我們自己寫的內容——每一個字都在掌控之中。盲測是別人出的題——我們不知道答案。"
"所以才叫盲測。"林遠說。
趙強一直沉默。這時候他開口了。
"四十七組已知衝突——這是德勤自己的審計師去年手動找到的。數量不一定完整。"
林遠看向他。
"真實數據里的衝突，不一定只有四十七組。"趙強說，"人工審計會遺漏。如果我們的引擎找到了五十組、六十組——多出來的那些，怎麼處理？"
林遠想了幾秒。"多出來的，標註為'人工審計未發現的新衝突'。如果這些衝突經得起驗證——那就不只是'通過盲測'了。"
"那是什麼？"
"那是證明我們的引擎比人工審計更強。"
趙強點頭。"明白了。"
下午四點。
林遠站在白板前，把演示方案擦掉一半，重新寫：
新增任務：德勤盲測
4.28（周三）：接收數據 + 預處理
4.29（周四）：引擎運行 + 結果比對
4.30（周五）：結果報告 → 交付韓委員
盲測目標：
基準線：找到47組已知衝突中的40組（85%）
目標線：找到全部47組（100%）
驚喜線：發現人工審計遺漏的額外衝突
"四天。"蘇明遠說，"白皮書剛交出去，盲測就來了。"
"這不是壞事。"林遠說，"韓委員願意讓我們用真實數據測試——說明他認真對待這件事。如果他只是敷衍，隨便找個測試數據走個過場就行了。"
"你的意思是——盲測本身就是信任的信號？"
"對。但信任不等於通過。"林遠說，"Hayes出這道題，不是為了為難我們。他是想知道：這套引擎在真實世界的泥潭裡，還能不能跑。"
"泥潭？"
"真實數據就是泥潭。格式混亂、欄位缺失、準則交叉引用斷裂——測試數據是 cleaned 過的，真實數據不會。"
趙強說："數據預處理模塊需要加強。現有的格式標準化只處理三種格式——如果德勤的數據里有第四種格式呢？"
"先等數據到了再說。"林遠說，"今晚把數據預處理的代碼重新審一遍，把所有可能的問題列出來。明天數據一到，立刻開始。"
晚上七點。
林遠回到宿舍。
桌上攤著北達的課本——高等數學、作業系統、編譯原理。期中考試在五月中旬，他已經有兩周沒翻課本了。
他翻開作業系統課本，看了二十分鐘。進程調度、內存管理、文件系統。這些知識和引擎開發直接相關——調度器的無鎖設計、上下文切換的開銷優化，底層原理都在這本書里。
但他現在滿腦子都是盲測。
四十七組衝突。真實數據。泥潭。
他合上課本，在腦子裡過了一遍引擎的數據預處理流程。
格式標準化→欄位映射→數據清洗→完整性校驗→送入審計引擎。
每一步都可能出問題。每一步都必須穩健。
"小艾，德勤的審計底稿通常用什麼格式？"
"主流是XBRL。"小艾說，"但二零零四年的XBRL標準還不成熟，很多事務所用的是自定義的XML Schema。德勤自己的格式叫Deloitte Audit Format——DAF，本質上是XBRL的變體，但擴展了大約百分之十五的自定義欄位。"
"自定義欄位——意味著我們的欄位映射表可能缺東西。"
"對。但自定義欄位通常不影響核心審計邏輯。關鍵是把標準欄位正確映射過來。"
"嗯。"林遠說，"明天數據到了，第一件事——分析DAF格式的欄位結構。"
他在筆記本上寫下四個字：數據預處理。
然後翻回課本，繼續看進程調度。
考試要過。盲測要贏。兩件事都不能丟。