2004年四月二十六號。周一。
早上八點。工作室。
GOOGLE搜索TWKAN
趙強比所有人都早。
林遠到的時候，他已經盯著屏幕兩個小時了。三十條規則的文件打開著，旁邊攤著四本列印出來的準則原文——美國政府會計、國際財報準則、國際審計準則、安全標準體系，每一本都貼滿了便籤條。
」最後九條搞完了？」
趙強點頭。」搞完了。但有個問題。」
他切到一個新的表格文件。
」前二十一條規則處理的都是兩兩衝突——美國政府會計對國際財報準則、國際審計準則對安全標準體系，一對一的比較。但最後九條里，有三對是三個標準同時衝突。」
林遠拉了把椅子坐下。」具體說。」
趙強調出一條記錄。
」審計對象AO-1247，一家政府控股的金融服務企業。固定資產處置收益的確認。」
他指著屏幕上的三列數據。
」美國政府會計認為處置收益應在交易完成日一次性確認。國際財報準則要求按公允價值減去處置費用後分期確認。安全標準體系不直接規範會計處理，但要求對資產處置的授權流程做完整性校驗。國際審計準則又要求審計師對處置交易的商業合理性發表意見。」
」四個標準，四種完全不同的視角。」林遠說。
」對。兩兩衝突好處理——A說這樣，B說那樣，差異來源寫清楚就行。但三方衝突不一樣。」趙強調出另一條記錄，」比如這條——國際審計準則的審計底稿要求引用國際財報準則的公允價值數據，美國政府會計又要求在同一份報告裡用歷史成本法列示。國際審計準則和美國政府會計之間沒有直接的引用關係，但它們都指向了同一個審計對象，結論卻完全不同。」
」也就是說——不是A和B打架，是A、B、C三個各說各話，沒人把它們串起來。」
」對。現有的規則庫結構是'差異類型+衝突來源+準則條文'——三元組。但三方衝突需要四元組：差異類型、衝突來源、準則條文、關聯維度。」
林遠盯著屏幕看了兩分鐘。
」現有的規則庫結構不夠用。但也不需要推翻重來。」
他走到白板前，畫了一個圖。
兩方衝突（21條）：A vs B → 直接比對
三方衝突（新增）：A vs B vs C → 分層比對
第一層：A vs B
第二層：(A vs B) 的結論 vs C
第三層：綜合三方結論，標註分歧根源
」分層處理。」林遠說，」先把多方衝突拆成兩兩比較，然後把兩兩比較的結論再做一個綜合層。綜合層不判斷誰對誰錯——只告訴審計師：美國政府會計從這個角度看是這樣的，國際財報準則從那個角度看是那樣的，國際審計準則又加了另一個維度。」
趙強想了一會兒。」規則庫的數據結構需要加一個欄位——'衝突維度數'。兩方衝突是2，三方是3。前端展示的時候，三方衝突的詳情面板就不只是四欄並排，而是分層展開。」
」對。王晨那邊也需要改——衝突矩陣的單元格顏色要支持第三種狀態。」
」什麼顏色？」
」紫色。綠色無衝突，黃色兩方準則性差異，紅色邏輯性衝突，紫色——多方衝突。需要審計師自己綜合判斷。」
九點半。王晨到了。
林遠把需求跟他說了。王晨沒有立刻動手，而是先畫了一張草圖。
」多層級聯面板。」他把草圖遞給林遠，」點擊紫色單元格，先彈出第一層——兩方比較。底部有一個展開按鈕：'查看第三方標準的關聯影響'。點擊後，面板擴展，顯示第三個標準的視角和它與其他兩個標準的交叉關係。」
」交互層級清晰嗎？」
」清晰。第一層解決百分之八十的情況。第三方的關聯是補充信息，不強制展開。」
林遠點頭。」就這麼做。」
十一點。
趙強完成了規則庫的數據結構升級。三十條規則里，二十一條是兩方衝突，六條升級為三方衝突，剩餘三條需要新增第四條標準的關聯分析。
」實際上四方同時衝突的情況很少。」趙強說，」三千個審計對象里，我只找到了兩例。」
」兩例夠了。」林遠說，」演示的時候，這兩例就是最好的素材。Morrison和Hayes看到兩方衝突，會覺得'這個工具能做基礎比對'。但看到四方衝突的分層推理鏈——他們會意識到這個引擎能處理真實世界的複雜性。」
趙強點頭。」規則庫全部完成。三十條規則，覆蓋467對衝突中的462對——覆蓋率百分之九十八點九。剩下五對涉及準則過渡期條款，標註了'待準則更新後補充'，不影響演示。」
下午。
林遠開始白皮書最終統稿。他把過去三天的進展全部整合：衝突消解引擎的三層架構、行業聚類發現、多方衝突的分層處理機制。
小艾在腦海里幫他做最後的文字打磨。
」第七部分的標題要不要改？」
」原來叫什麼？」
」'總結與展望'。太普通了。」
」'從檢測到認知——四標準並行審計引擎的價值躍遷'。」小艾在腦海里說，」Hayes是方法論專家，他會被'價值躍遷'吸引——從工具層面的檢測，升級到認知層面的行業風險洞察。」
」用。」
下午五點。兩萬九千五百字。定稿。
晚上六點半。
林遠在白板上寫下演示框架：
Morrison演示（2004年5月12日，8小時）：
上午：引擎架構 + 四標準並行運行
午間：工作午餐，非正式交流
下午：衝突消解引擎 + 行業聚類 + 多方衝突
收尾：白皮書核心回顧 + 合作展望
」八個小時，不能全是技術。」他自言自語，」Hayes是技術出身，但他是高級合伙人——最終關心的是商業價值。」
他在框架旁邊加了一行：
Hayes可能會問的關鍵問題：
1. 衝突檢測準確率是多少？
2. 規則庫維護成本——每更新一次準則就要重寫規則？
3. 審計對象從三千擴展到三十萬，性能怎麼保證？
4. 和德勤現有的AuditView框架是什麼關係？
第四個問題最棘手。
」小艾，AuditView的具體技術架構？」
」公開信息有限。」小艾在腦海里說，」核心是風險評估矩陣——按行業、企業規模、審計類型預定義風險等級。本質上是經驗庫的數位化。」
」也就是說，AuditView是'事前'的——審計開始前告訴你風險在哪。我們的引擎是'事後'的——審計跑完之後告訴你結果之間有沒有矛盾。」
」兩者互補。」
」對。Hayes問第四個問題的時候，我就這麼回答——不是替代AuditView，是在AuditView之後再加一層驗證。事前評估風險，事後驗證結果。閉環。」
他在白板上的第四個問題旁邊寫了兩個字：閉環。
晚上八點。
蘇明遠走進來，手裡拿著手機。」陳偉東的電話。」
林遠接過來。」陳老師。」
」林遠，告訴你一個消息。」陳偉東的聲音聽起來很興奮，」863課題的初步方案討論，提前到2004年五月二十號了。」
」2004年五月二十號？」林遠算了一下——不到一個月。
」上面有人在推動，對信息安全方向的課題很著急。」陳偉東說，」我報了你的四標準並行審計引擎作為候選方向之一。」
」我的引擎是審計領域的——和信息安全有關係嗎？」
」關係大了。四個審計標準同時運行，數據在不同標準之間流轉、校驗、衝突消解。這套架構的核心是什麼？是安全的數據流轉和可信的計算驗證。項目方關心的不是審計本身——是這套架構能不能遷移到高安全等級領域的數據安全審計上。」
林遠沉默了幾秒。
」如果演示成功，項目方可能想看的不只是審計引擎，而是底層的架構能力。」
」對。我會在2004年五月二十號的方案討論上引用你的演示結果。」
」明白了。」
」壓力大了吧？」陳偉東笑了笑。
」還好。多一個觀眾，標準更高而已。」
掛了電話，林遠站在窗前。
窗外是北京四月的夜景。深夜的海淀區燈火稀疏，大學城的夜晚總是安靜得比城區更早。
十六天後，兩個完全不同的舞台。
一個是德勤的Morrison和Hayes——商業世界的審判。
一個是863課題的方案討論——國家級的考核。
兩場演示，一套引擎。
他回到白板前，在演示框架的最下面加了一行：
5.20 863課題初步方案討論（陳偉東引用演示結果）
→ 5.12的演示不只是給德勤看——也是給重點項目看底層架構能力
然後在」關鍵問題」列表里加了第五條：
5. 這套架構能不能遷移到非審計領域的數據安全驗證？
這個問題的答案，他已經在腦子裡了。
能。