第328章 中文大寫金額！級聯填充！模板適配攻堅！
三月十九號。周五。
早上八點。遠望工作室。
趙強已經在隔離機器前坐了一個小時。
王經理昨天上午送來的那塊加密硬碟，裡面三份審計數據——製造企業的應收帳款明細、銀行對帳單、固定資產台帳——已經被他逐行掃了一遍。
屏幕上是一張數據質量統計表。
"結果出來了。"他看到林遠進來，直接報數。
"三份數據，總行數八千九百多行。涉及IFRS三十九個輸出欄位中的三十二個——剩下七個欄位在這批數據里沒出現，後面如果遇到需要單獨處理。"
"髒度呢？"
"三類問題。"趙強切換到詳細報告。
"第一類，空值。整體空值率百分之十七，其中應收帳款明細表最嚴重——二十二。主要分布在'對手方名稱''交易日期''備註'三個欄位。"
"第二類，格式不統一。金額欄位最典型——同一列里有逗號分隔、純數字、中文大寫、括號負數四種寫法。日期欄位也有四種格式混用。"
"第三類，結構性問題。合併單元格。固定資產台帳里有大量合併——一個'資產類別'欄位合併了五行到八行不等。解析出來就是第一行有值，下面的行是空。"
林遠拉了把椅子坐下來，盯著屏幕看了一會兒。
"比PwC的數據複雜多少？"
"不是一個量級。"趙強說，"PwC的SOC 2日誌是系統自動生成的，格式雖然非標但有規律。德勤這批數據是審計師手工整理的Excel——人的隨意性比機器大得多。"
"適配方案？"
"昨晚想了一版。"趙強打開一個文本文件。"分三塊——第一塊，中文大寫金額轉換器。第二塊，合併單元格的級聯填充算法。第三塊，日期格式自動識別。三塊都做成獨立的預處理模塊，跑在模板引擎之前。"
"思路對。"林遠說，"先做最難的那個——中文大寫金額。"
上午十點。
林遠坐在工位前，開始寫中文大寫金額轉換器的核心邏輯。
代碼不複雜，但邊界條件多。
他在草稿紙上先列了所有需要處理的字符映射——
壹=1，貳=2，叄=3，肆=4，伍=5，陸=6，柒=7，捌=8，玖=9。
拾=10，佰=100，仟=1000，萬=10000，億=100000000。
元=小數點前結束，角=十分位，分=百分位。
全網首發更新 TW 看書網解無聊，🅢🅗🅤.🅣🅦超方便
"難點在哪？"趙強路過時看了一眼。
"進位邏輯。"林遠說，"比如'壹佰貳拾叄萬肆仟伍佰陸拾柒元捌角玖分'——'萬'字是一個大單位，它前面的'壹佰貳拾叄'要先算成123，再乘以10000。然後'肆仟伍佰陸拾柒'是4567。兩部分加起來才是整數部分。"
"如果只有'萬'沒有'仟佰拾'呢？比如'伍萬元整'？"
"那就是50000。'萬'後面直接跟'元'，中間沒有數字——意味著這一級是零。"
"零怎麼處理？"
"連續多個大寫數字之間如果沒有單位字，就是拼接關係——'壹貳'不是12，是不合法的。但如果遇到'零'，比如'壹佰零叄元'——中間的'零'表示十位和個位之間跳了一級，值是103。"
趙強想了一下。"邊界用例至少需要準備多少？"
"兩百個。"林遠說，"整數部分、純小數、零的各種位置、極大值、負數——全覆蓋。寫完轉換器立刻跑回歸測試。"
"多久能寫完？"
"核心邏輯兩個小時。測試用例再加三個小時。下午五點之前能交。"
下午三點。
趙強的級聯填充算法也寫完了。
"思路很簡單。"他演示給林遠看，"遍歷每一行，遇到某個欄位為空，就向上查找最近的非空值繼承過來。直到遇到新的非空值，切換繼承源。"
"性能呢？"
"八千行數據，處理時間不到一毫秒。"
"邊界——如果第一行就是空的呢？"
"那就沒有可繼承的值，標記為'數據缺失'，輸出時走容錯路徑——欄位值寫null，容錯標記寫'原始數據缺失'。"
"好。跟模板引擎的容錯機制能無縫對接。"
趙強點頭。"還有一個細節——合併單元格有時候不是縱向的，是橫向的。比如'A1到D1合併'，解析出來只有A1有值，B1、C1、D1都是空。"
"橫向合併和縱向合併的區別？"
"橫向是同一行不同列之間的合併——一般表示'這幾個欄位共享同一個值'。縱向是同一列不同行之間的合併——表示'這幾行屬於同一個分類'。"
"橫向合併怎麼處理？"
"需要檢測合併區域。Excel的合併單元格在XML層面有標記——mergedCells標籤。解析的時候先讀合併區域信息，再填充。"
"加到算法里。"林遠說，"縱向級聯填充和橫向合併填充是兩個獨立模塊，但共用同一個預處理管線。"
"已經在做了。"
三月二十號。周六。
蘇明遠收到徐經理的郵件——"第一批數據運行良好。審計團隊反饋格式完全符合SOC 2規範。我們準備把第二批數據也接入引擎。大約兩百條記錄，格式和第一批類似。預計下周發送。"
"好消息。"蘇明遠說，"PwC開始信任我們了。"
"第二批是好事，但也意味著引擎要從'能跑一次'升級到'能持續跑'。"林遠說，"讓趙強把部署文檔補完，加上監控和重啟流程。PwC的IT團隊要能獨立維護。"
"已經在補了。"趙強頭都沒抬。
同一天下午。ARM線有新進展。
趙強的交叉編譯工具鏈已經跑通了。不只是Hello World——他把x86上跑通的模運算庫做了第一版ARM移植。
"編譯通過，運行有問題。"他報告。
"什麼問題？"
"大數乘法溢出。x86上用的是64位整數乘法，結果放在128位的寄存器里。ARM上只有32位乘法指令——兩個32位數相乘，結果只保留低32位，高32位丟了。"
"ARM沒有64位乘法？"
"PXA255是ARMv5TE架構。有一條UMULL指令——無符號64位長乘法。輸入兩個32位數，輸出一個64位結果，存在兩個32位寄存器里。"
"能用？"
"能用，但需要改寫整個大數乘法的底層實現。x86上一條指令的事，ARM上要用UMULL加進位傳播——代碼量翻三倍。"
"多久能改完？"
"三天。"趙強說，"改完之後跑一輪單元測試，確認結果跟x86完全一致。"
林遠點頭。"你改大數乘法，我繼續推混合坐標系的理論方案。"
混合坐標系的核心思路已經成型——倍點操作用雅可比坐標，避免每次計算後的模逆運算；點加操作用仿射坐標，減少乘法次數。兩種坐標在關鍵路徑上做切換。
"切換的代價是一次模逆。"他在草稿紙上算，"窗口寬度4，每輪做一次倍點鏈（4次倍點）加一次點加。如果倍點用雅可比坐標，4次倍點省了4次模逆。切換代價只有1次模逆。淨賺3次。"
"3次模逆省下來——"
"標量乘法整體速度再提升約15%。"林遠說，"加上Mersenne素數域優化的3.5倍和窗口法的加速——三個方向疊加，理論上能達到3500到4000次每秒。"
"距離5000還差一步。"
"最後一步靠ARM彙編級優化來補。等移植完成後，做性能基準，看實際數字在哪裡。不夠的話再想辦法。"
晚上九點。
白板上的任務清單——
德勤：適配進行中。中文大寫轉換器 級聯填充 日期識別。明天聯調。3月22日截止。
ARM：工具鏈 第一版移植有溢出問題→修復中。預計下周三完成。
PwC：運行穩定。第二批數據下周接入。
林遠站在白板前看了一會兒。
德勤的適配進度比預想的快——三塊預處理模塊一天之內全部完成。但聯調才是真正的考驗。模塊單獨跑沒問題，拼到一起跑真實數據——一定會出新的問題。
"明天是硬仗。"他對趙強說。
"嗯。"趙強已經在收拾東西了。"聯調環境我晚上搭好。明天早上直接用德勤數據跑。"
"好。"
蘇明遠先走了。林遠關燈之前，看了一眼手機。
陳嘉怡的消息——
"韓委員問進度。我說一切正常。他說'期待月底見'。"
林遠回了一個字："好。"
八天。
早上八點。遠望工作室。
趙強已經在隔離機器前坐了一個小時。
王經理昨天上午送來的那塊加密硬碟，裡面三份審計數據——製造企業的應收帳款明細、銀行對帳單、固定資產台帳——已經被他逐行掃了一遍。
屏幕上是一張數據質量統計表。
"結果出來了。"他看到林遠進來，直接報數。
"三份數據，總行數八千九百多行。涉及IFRS三十九個輸出欄位中的三十二個——剩下七個欄位在這批數據里沒出現，後面如果遇到需要單獨處理。"
"髒度呢？"
"三類問題。"趙強切換到詳細報告。
"第一類，空值。整體空值率百分之十七，其中應收帳款明細表最嚴重——二十二。主要分布在'對手方名稱''交易日期''備註'三個欄位。"
"第二類，格式不統一。金額欄位最典型——同一列里有逗號分隔、純數字、中文大寫、括號負數四種寫法。日期欄位也有四種格式混用。"
"第三類，結構性問題。合併單元格。固定資產台帳里有大量合併——一個'資產類別'欄位合併了五行到八行不等。解析出來就是第一行有值，下面的行是空。"
林遠拉了把椅子坐下來，盯著屏幕看了一會兒。
"比PwC的數據複雜多少？"
"不是一個量級。"趙強說，"PwC的SOC 2日誌是系統自動生成的，格式雖然非標但有規律。德勤這批數據是審計師手工整理的Excel——人的隨意性比機器大得多。"
"適配方案？"
"昨晚想了一版。"趙強打開一個文本文件。"分三塊——第一塊，中文大寫金額轉換器。第二塊，合併單元格的級聯填充算法。第三塊，日期格式自動識別。三塊都做成獨立的預處理模塊，跑在模板引擎之前。"
"思路對。"林遠說，"先做最難的那個——中文大寫金額。"
上午十點。
林遠坐在工位前，開始寫中文大寫金額轉換器的核心邏輯。
代碼不複雜，但邊界條件多。
他在草稿紙上先列了所有需要處理的字符映射——
壹=1，貳=2，叄=3，肆=4，伍=5，陸=6，柒=7，捌=8，玖=9。
拾=10，佰=100，仟=1000，萬=10000，億=100000000。
元=小數點前結束，角=十分位，分=百分位。
全網首發更新 TW 看書網解無聊，🅢🅗🅤.🅣🅦超方便
"難點在哪？"趙強路過時看了一眼。
"進位邏輯。"林遠說，"比如'壹佰貳拾叄萬肆仟伍佰陸拾柒元捌角玖分'——'萬'字是一個大單位，它前面的'壹佰貳拾叄'要先算成123，再乘以10000。然後'肆仟伍佰陸拾柒'是4567。兩部分加起來才是整數部分。"
"如果只有'萬'沒有'仟佰拾'呢？比如'伍萬元整'？"
"那就是50000。'萬'後面直接跟'元'，中間沒有數字——意味著這一級是零。"
"零怎麼處理？"
"連續多個大寫數字之間如果沒有單位字，就是拼接關係——'壹貳'不是12，是不合法的。但如果遇到'零'，比如'壹佰零叄元'——中間的'零'表示十位和個位之間跳了一級，值是103。"
趙強想了一下。"邊界用例至少需要準備多少？"
"兩百個。"林遠說，"整數部分、純小數、零的各種位置、極大值、負數——全覆蓋。寫完轉換器立刻跑回歸測試。"
"多久能寫完？"
"核心邏輯兩個小時。測試用例再加三個小時。下午五點之前能交。"
下午三點。
趙強的級聯填充算法也寫完了。
"思路很簡單。"他演示給林遠看，"遍歷每一行，遇到某個欄位為空，就向上查找最近的非空值繼承過來。直到遇到新的非空值，切換繼承源。"
"性能呢？"
"八千行數據，處理時間不到一毫秒。"
"邊界——如果第一行就是空的呢？"
"那就沒有可繼承的值，標記為'數據缺失'，輸出時走容錯路徑——欄位值寫null，容錯標記寫'原始數據缺失'。"
"好。跟模板引擎的容錯機制能無縫對接。"
趙強點頭。"還有一個細節——合併單元格有時候不是縱向的，是橫向的。比如'A1到D1合併'，解析出來只有A1有值，B1、C1、D1都是空。"
"橫向合併和縱向合併的區別？"
"橫向是同一行不同列之間的合併——一般表示'這幾個欄位共享同一個值'。縱向是同一列不同行之間的合併——表示'這幾行屬於同一個分類'。"
"橫向合併怎麼處理？"
"需要檢測合併區域。Excel的合併單元格在XML層面有標記——mergedCells標籤。解析的時候先讀合併區域信息，再填充。"
"加到算法里。"林遠說，"縱向級聯填充和橫向合併填充是兩個獨立模塊，但共用同一個預處理管線。"
"已經在做了。"
三月二十號。周六。
蘇明遠收到徐經理的郵件——"第一批數據運行良好。審計團隊反饋格式完全符合SOC 2規範。我們準備把第二批數據也接入引擎。大約兩百條記錄，格式和第一批類似。預計下周發送。"
"好消息。"蘇明遠說，"PwC開始信任我們了。"
"第二批是好事，但也意味著引擎要從'能跑一次'升級到'能持續跑'。"林遠說，"讓趙強把部署文檔補完，加上監控和重啟流程。PwC的IT團隊要能獨立維護。"
"已經在補了。"趙強頭都沒抬。
同一天下午。ARM線有新進展。
趙強的交叉編譯工具鏈已經跑通了。不只是Hello World——他把x86上跑通的模運算庫做了第一版ARM移植。
"編譯通過，運行有問題。"他報告。
"什麼問題？"
"大數乘法溢出。x86上用的是64位整數乘法，結果放在128位的寄存器里。ARM上只有32位乘法指令——兩個32位數相乘，結果只保留低32位，高32位丟了。"
"ARM沒有64位乘法？"
"PXA255是ARMv5TE架構。有一條UMULL指令——無符號64位長乘法。輸入兩個32位數，輸出一個64位結果，存在兩個32位寄存器里。"
"能用？"
"能用，但需要改寫整個大數乘法的底層實現。x86上一條指令的事，ARM上要用UMULL加進位傳播——代碼量翻三倍。"
"多久能改完？"
"三天。"趙強說，"改完之後跑一輪單元測試，確認結果跟x86完全一致。"
林遠點頭。"你改大數乘法，我繼續推混合坐標系的理論方案。"
混合坐標系的核心思路已經成型——倍點操作用雅可比坐標，避免每次計算後的模逆運算；點加操作用仿射坐標，減少乘法次數。兩種坐標在關鍵路徑上做切換。
"切換的代價是一次模逆。"他在草稿紙上算，"窗口寬度4，每輪做一次倍點鏈（4次倍點）加一次點加。如果倍點用雅可比坐標，4次倍點省了4次模逆。切換代價只有1次模逆。淨賺3次。"
"3次模逆省下來——"
"標量乘法整體速度再提升約15%。"林遠說，"加上Mersenne素數域優化的3.5倍和窗口法的加速——三個方向疊加，理論上能達到3500到4000次每秒。"
"距離5000還差一步。"
"最後一步靠ARM彙編級優化來補。等移植完成後，做性能基準，看實際數字在哪裡。不夠的話再想辦法。"
晚上九點。
白板上的任務清單——
德勤：適配進行中。中文大寫轉換器 級聯填充 日期識別。明天聯調。3月22日截止。
ARM：工具鏈 第一版移植有溢出問題→修復中。預計下周三完成。
PwC：運行穩定。第二批數據下周接入。
林遠站在白板前看了一會兒。
德勤的適配進度比預想的快——三塊預處理模塊一天之內全部完成。但聯調才是真正的考驗。模塊單獨跑沒問題，拼到一起跑真實數據——一定會出新的問題。
"明天是硬仗。"他對趙強說。
"嗯。"趙強已經在收拾東西了。"聯調環境我晚上搭好。明天早上直接用德勤數據跑。"
"好。"
蘇明遠先走了。林遠關燈之前，看了一眼手機。
陳嘉怡的消息——
"韓委員問進度。我說一切正常。他說'期待月底見'。"
林遠回了一個字："好。"
八天。