2004年四月二十七號。周二。
早上八點。工作室。
蘇明遠把列印好的白皮書裝進文件袋——兩百九十五頁，三百份精裝裝訂。旁邊還有一張光碟，存著電子版。
」韓委員那邊怎麼送？」
」兩份。」林遠說，」一份快遞到德勤北京代表處，韓委員親收。一份電子版郵件發過去，附英文摘要。Morrison和Hayes看英文版，韓委員看中文版。」
」快遞今天能到？」
」同城快遞，明天上午之前肯定到。但韓委員如果急著看，會先看電子版。」
蘇明遠把文件袋封好。」那我們等反饋？」
」等。但別乾等。」林遠走到白板前，」今天開始做演示方案的第一版——八個小時的演示，每一分鐘都要設計。」
上午十點。
團隊圍坐在會議區。白板上畫著演示的時間軸。
」八個小時，分四個板塊。」林遠說，」上午兩個半小時：引擎架構講解加四標準並行運行的實時演示。午餐一小時——非正式交流，不談技術，建立關係。下午三個小時：衝突消解引擎、行業聚類發現、多方衝突處理。最後一個半小時：白皮書核心回顧加合作展望。」
」上午的實時演示用什麼數據？」趙強問。
」還是那兩千零三萬條測試數據。」林遠說，」架構講解部分需要穩定的、可重複的演示環境。測試數據我們已經跑了十幾輪，結果完全可控。」
」下午呢？」
」下午是重點。」林遠說，」衝突消解引擎的演示——我要用行業聚類後的矩陣視圖。先展示製造業的衝突模式，再展示服務業，最後展示那個四方衝突的案例。層層遞進。」
」演示順序有講究？」王晨問。
」有。」林遠說，」Morrison是項目合伙人，他關心'這東西能不能用'。所以先給他看最直觀的——矩陣視圖，顏色標記，一點就出詳情。讓他覺得'哇，這個好懂'。」
」Hayes呢？」
」Hayes是技術把關人。他不看界面——他看架構。所以架構講解那部分，我要花二十分鐘講衝突消解引擎的分層設計。兩方衝突怎麼比對，三方衝突怎麼分層，多方衝突怎麼處理。」
趙強說：」他會追問技術細節。」
」當然。所以我需要準備三套回答——表層回答給Morrison聽，技術回答給Hayes聽，兜底回答給最壞的情況。」
」兜底回答？」
」如果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格式的欄位結構。」
他在筆記本上寫下四個字：數據預處理。
然後翻回課本，繼續看進程調度。
考試要過。盲測要贏。兩件事都不能丟。