第267章 情緒點獎勵：「初級人工智慧（專家系統）與資料庫原理」
金融戰結束後的第三天，深夜。
淺水灣別墅的書房裡，王恪獨自坐在書桌前。桌面上攤著幾份文件：港元匯率反擊戰的總結報告、明遠集團第三季度財務報表、龍芯流片進度更新……但他此刻的目光沒有聚焦在任何一份文件上。
他在看系統界面。
【情緒點餘額：842,567點】
這個數字在三天內暴漲了近三十萬點。來源很雜：香港市民的感激，實業界同行的敬佩，明遠員工的驕傲，甚至還有那些被擊退的炒家們不甘心的怨念——系統很公平，正面負面情緒都收。
但讓王恪關注的不是數字本身，是界面中央閃爍的新提示：
【檢測到宿主在複雜商戰與國際博弈中取得關鍵勝利，觸發成就：「智勝千里」】
【獎勵已發放：「初級人工智慧（專家系統）與資料庫原理」知識包】
【是否立即接收？】
王恪選擇了「是」。
沒有想像中的強光或巨響，就像打開了一扇門——一扇通往未來三十年的技術之門的門縫。信息不是粗暴地灌入，而是像溪流般緩緩流淌，自然而然地成為他記憶的一部分。
他「想起」了專家系統的核心架構：知識庫、推理機、解釋器、人機接口……
他「想起」了關係數據庫的理論基礎：關係代數、SQL語言、事務處理、索引優化……
他「想起」了更遠的東西：模糊邏輯、神經網絡雛形、甚至一點點機器學習的影子——雖然在這個時代，這些概念連學術論文裡都很少見。
信息太多了，王恪閉上眼，靠在椅背上，讓知識慢慢沉澱。書房裡的掛鍾滴答作響，窗外傳來海浪拍岸的聲音。
不知過了多久，他睜開眼，走到白板前，拿起筆。
沒有刻意去畫，手自己動了起來。左邊畫出專家系統的結構圖：知識庫里存儲規則和事實，推理機根據輸入進行推導，解釋器說明推理過程……右邊畫出資料庫的層次結構：物理層、邏輯層、視圖層，以及它們之間的關係。
畫完了，他看著白板上的圖，笑了。
1983年，世界上第一個商用專家系統「DENDRAL」剛剛問世，只能用於化學分析。關係數據庫的概念雖然提出多年，但主流還是層次資料庫和網狀資料庫。而他現在腦子裡這些東西，如果全部實現，足以讓明遠在軟體領域領先世界十年。
但問題也在這裡：太超前了。
硬體跟不上。方舟二代電腦的內存最多擴展到1MB，硬碟最大40MB——這點容量，跑個像樣的資料庫都吃力，更別說專家系統了。
人才跟不上。全世界懂這些概念的人不超過一百個，大多在大學實驗室里寫論文。
生態跟不上。沒有成熟的開發工具，沒有標準的接口協議，甚至沒有足夠的教育材料培養後續人才。
就像給了石器時代的人一張噴氣發動機圖紙，他知道這東西能飛，但造不出來。
王恪放下筆，坐回桌前。他需要制定一個可行的路線圖——不是一步登天，而是搭建一個階梯，一步一步往上爬。
先從資料庫開始。方舟電腦現在用的還是簡單的文件系統，如果能把關係數據庫的概念簡化，做出一個輕量級的版本，就能大幅提升數據處理能力。這對於企業用戶、科研機構來說，會是巨大的吸引力。
然後是專家系統。可以從最垂直的領域入手，比如……電腦故障診斷？把維修經驗寫成規則，讓系統幫助用戶排查問題。這個不需要太複雜的推理，但實用價值高，而且能積累經驗。
他正想著，書房門被輕輕推開。
婁曉娥端著托盤走進來，上面有一碗湯圓。「就知道你還沒睡。」她輕聲說，「吃點東西吧。」
王恪接過碗，湯圓還溫熱。是芝麻餡的，他最喜歡的口味。
「又在想什麼大計劃？」婁曉娥坐在對面，看著他布滿血絲的眼睛。
「在想……怎麼讓電腦更聰明一點。」王恪舀起一個湯圓，「不是計算快，是能像人一樣推理、判斷。」
婁曉娥笑了：「那不成精了？」
「差不多。」王恪也笑了，「不過不是成精，是成為工具——更強大的工具。比如，如果一個醫生用電腦看病歷，電腦能根據症狀提示可能的疾病；如果一個工程師設計電路，電腦能檢查有沒有錯誤……」
「聽起來像科幻小說。」
「現在是科幻，但十年後可能就是現實。」王恪吃完湯圓，把碗放下，「曉娥，你知道嗎，我現在最缺的不是錢，不是技術，是時間。世界變化太快了，我們必須跑得更快。」
婁曉娥握住他的手：「你已經跑得很快了。別太累。」
「嗯。」王恪點點頭，但心裡知道，他不能停。
第二天，明遠研發中心。
王恪召集了軟體部門的骨幹——一共八個人，領頭的是個三十歲的程式設計師，叫吳志強，香港大學計算機系畢業，參與過方舟作業系統的開發。
「今天討論一個新方向。」王恪在白板上寫下兩個詞：「資料庫」和「專家系統」。
會議室里的人都愣住了。這兩個詞他們聽過，但離明遠現在做的個人電腦作業系統，好像有點遠。
「王總，我們……要做資料庫軟體？」吳志強試探著問，「像Oracle那種？但那是給大型機用的，我們的電腦……」
「不是Oracle那種龐然大物。」王恪畫了一個簡化的架構圖，「我們要做的是一個輕量級的關係數據庫，專門為個人電腦和中小型企業設計。內存占用小，安裝簡單，但功能要全——支持SQL查詢、事務處理、數據備份。」
他頓了頓，看大家的表情：「有問題嗎？」
一個年輕程式設計師舉手：「王總，SQL是什麼？」
王恪這才想起來，SQL語言在1983年還沒有成為標準。Oracle公司剛剛發布了第一個商用SQL資料庫，但文檔不公開，知道的人很少。
「一種查詢語言。」王恪在白板上寫下幾個簡單的例子：「SELECT * FROM employees WHERE salary ＞ 1000」「INSERT INTO products VALUES (『電腦』, 2000)……」
他解釋語法，講關係代數的原理，講為什麼要用表而不是樹形結構來組織數據。講得很淺，但足夠讓這些聰明的程式設計師理解核心思想。
吳志強的眼睛越來越亮：「這個思路……比我們現在用的文件系統先進太多了！如果實現，數據處理效率能提升十倍！」
「但實現難度也大十倍。」另一個程式設計師苦笑，「光是那個事務處理——怎麼保證數據一致性？如果中途斷電怎麼辦？」
「有辦法。」王恪開始畫更詳細的圖，「寫前日誌、檢查點、回滾機制……」
他講了一個小時。不是填鴨式灌輸，而是引導大家思考：如果你們來設計，會怎麼做？遇到這個問題，怎麼解決？
這是王恪的風格——他不直接給答案，而是給方向，給工具，然後讓團隊自己探索。探索過程中犯的錯誤、走過的彎路，都是寶貴的經驗。
會議結束時，吳志強已經興奮得坐不住了：「王總，我們馬上成立項目組！就叫……『方舟資料庫』項目！」
「好。」王恪點頭，「但要記住，第一個版本不要追求完美。核心功能實現就行，三個月內出原型。另外，文檔要詳細，API要清晰——這個資料庫不僅要自己用，將來還要開放給第三方開發者。」
「明白！」
資料庫項目啟動了。王恪接著講專家系統。
這次他更謹慎。因為專家系統涉及的知識表示、推理機制，比資料庫更抽象，更難理解。
「想像一下，我們要做一個電腦故障診斷程序。」他從最具體的場景入手，「用戶說：我的電腦開機沒反應。程序會問：電源燈亮嗎？風扇轉嗎？屏幕有顯示嗎？根據答案，一步步縮小範圍，最後給出可能的原因和解決方法。」
這個例子大家都懂。電腦維修是明遠售後服務的重要部分，每個技術支持人員都受過培訓，腦子裡有一堆經驗規則。
「如果我們把這些規則寫成程序呢？」王恪在白板上畫了一個決策樹，「如果電源燈不亮，檢查插座；如果電源燈亮但風扇不轉，檢查電源模塊；如果風扇轉但屏幕不亮，檢查顯卡……」
「這不就是……流程圖嗎？」有人問。
「類似，但更靈活。」王恪解釋，「流程圖是固定的路徑，而專家系統可以根據輸入動態選擇路徑。而且，它可以解釋為什麼給出某個建議——因為規則A和規則B同時滿足，所以可能是問題C。」
他講了一個簡單的專家系統框架：事實庫存儲當前狀態（電源燈亮、風扇轉、屏幕不亮），規則庫存儲知識（如果電源燈亮且風扇轉但屏幕不亮，那麼可能是顯卡故障），推理機根據事實匹配規則，給出結論。
雖然簡化了很多，但核心思想傳達到了。
會議室里安靜了幾分鐘。程式設計師們在消化這些概念。
吳志強先開口：「王總，這個想法……很厲害。但實現起來，規則怎麼寫？誰來確定規則對不對？」
「問得好。」王恪說，「這就是專家系統的難點：知識獲取。我們需要領域專家——比如我們的技術支持主管，把他們的經驗提煉成規則。這個過程很慢，很痛苦，但一旦做成，價值巨大。」
他頓了頓：「所以我建議，專家系統項目先不成立正式團隊，而是作為研究課題。找兩三個有興趣的人，慢慢探索。我們可以先從最簡單的開始：做一個『方舟電腦配置推薦』系統——用戶輸入預算和用途，系統推薦合適的配置。」
這個切入點很巧妙。既實用，又不複雜，還能積累經驗。
會議從上午九點開到下午三點，中午只是匆匆吃了盒飯。結束時，每個人的筆記本上都記滿了東西，腦子裡裝滿了新概念。
王恪走出會議室時，吳志強追上來：「王總，這些想法……您是怎麼想到的？」
王恪停下腳步，想了想：「多看，多想，多做夢。」
「做夢？」
「對。」王恪笑了，「夢想未來的電腦能做什麼，然後想辦法讓夢想成真。」
接下來的幾周，明遠研發中心多了一些奇怪的白板。
資料庫項目組的白板上畫滿了關係代數的公式和SQL語句的語法樹。專家系統課題組的白板上則是決策樹和規則鏈。
程式設計師們開始瘋狂學習。吳志強托人在美國買到了C.J. Date的關係數據庫理論著作，雖然書很厚，讀起來吃力，但大家輪流看，做筆記，討論。
更實際的是，他們開始動手寫代碼。
資料庫項目組決定先用方舟電腦自帶的方舟作業系統做實驗平台。第一個目標：實現一個最簡單的表結構，支持插入、查詢、刪除。
聽起來簡單，做起來難。光是設計文件存儲格式就爭論了三天——如何平衡空間和時間效率？如何支持變長欄位？如何實現索引？
王恪沒有直接給出方案，而是讓團隊自己試。試錯了重來，再試錯再重來。他只在關鍵時刻點撥一下：「想想磁碟的物理結構，連續讀寫和隨機讀寫的速度差多少？」「索引是不是越多越好？」
這種引導式的教學很有效。一個月後，團隊做出了第一個原型——一個只能存儲一萬條記錄、只支持簡單查詢的微型資料庫。性能很差，功能很弱，但它是真正的關係數據庫，支持SQL的一個子集。
測試那天，項目組所有人都很緊張。
吳志強在命令行輸入：「CREATE TABLE students (id INT, name CHAR(20), score FLOAT);」
回車。屏幕顯示「Table created.」
「INSERT INTO students VALUES (1, 『張三』, 85.5);」
「INSERT INTO students VALUES (2, 『李四』, 92.0);」
然後查詢：「SELECT * FROM students WHERE score ＞ 90;」
屏幕緩緩輸出：「2 李四 92.0」
雖然慢了三秒，但結果正確。
實驗室里爆發出歡呼。有人把帽子扔向空中，有人擁抱身邊的同事。吳志強眼睛紅了——這一個月，他瘦了八斤，掉了不少頭髮，但值了。
王恪也在場。他看著屏幕上那行簡單的輸出，心裡湧起一種奇妙的感動。
這不僅僅是一個資料庫原型。這是一顆種子——一顆將在未來長成參天大樹的種子。當其他公司還在用文件系統時，明遠已經有了關係數據庫；當別人開始追趕時，明遠可能已經在研究分布式資料庫、內存資料庫……
一步領先，步步領先。
「很好。」他拍拍吳志強的肩，「接下來優化性能，完善功能。六個月後，我要看到能商用的版本。」
「保證完成任務！」吳志強大聲說。
專家系統課題組進展慢一些，但也出了成果。他們做了一個「電腦配置推薦」的演示程序，只有二十條規則，但已經能根據預算和用途給出合理的建議。
演示時，一個程式設計師假裝用戶：「我想買台電腦，預算五千港幣，主要用來寫文章和看電影。」
程序問：「需要彩色顯示器嗎？」「需要列印功能嗎？」「需要大容量存儲嗎？」
最後給出建議：「方舟二代基本款，加配40MB硬碟，推薦索尼14寸彩色顯示器，總價四千八。」
雖然簡單，但邏輯清晰，解釋清楚：「因為您的用途不需要高性能處理器，所以選擇基本款；寫文章需要存儲空間，所以加硬碟；看電影需要彩色顯示……」
王恪看完演示，點點頭：「可以。繼續完善，增加更多規則。另外，開始準備下一個項目：硬體故障診斷。」
「王總，我們真的要做這個？」課題組成員有點猶豫，「這可是要動硬體的……」
「從軟體診斷開始。」王恪說，「通過系統日誌、錯誤代碼、用戶描述，推斷可能的問題。不需要百分百準確，能覆蓋80%的常見故障就行。」
他頓了頓：「記住，專家系統的核心不是替代人，是輔助人。讓新手也能像專家一樣解決問題，這才是價值。」
課題組成員記下了。
深夜，王恪再次獨自坐在書房裡。
系統界面展開，情緒點的數字在平穩增長——來自研發人員的興奮、成就感、求知慾……
但更讓他在意的是，界面下方出現了新提示：
【檢測到知識傳播與技術創新，觸發隱藏成就：「薪火相傳」】
【獎勵：知識傳授效率提升30%，團隊學習速度提升20%】
這個獎勵很實在。王恪能感覺到，現在他講解技術概念時，聽眾理解得更快，記得更牢。研發團隊的學習曲線明顯變陡了。
他關掉界面，看著窗外的大海。
1983年就要過去了。這一年，明遠經歷了太多：337調查、商業間諜、金融戰、全球擴張、技術突破……
但王恪知道，真正的挑戰還在後面。龍芯即將流片，方舟三代正在設計，家電業務剛剛起步，海外布局剛剛展開。
而他現在手裡，多了兩張王牌：資料庫和人工智慧的種子。
雖然只是種子，雖然還很弱小，但只要精心培育，總有一天會長成森林。
他想起前世，中國在資料庫和人工智慧領域追趕得多麼辛苦。Oracle、IBM、微軟壟斷了市場，制定著標準。中國公司要麼用他們的產品，要麼在低端市場掙扎。
但現在，1983年，一切都還早。
如果明遠能率先建立起自己的資料庫標準，如果能提前布局人工智慧的底層技術，如果能把這兩項核心技術牢牢掌握在中國人手裡……
那麼，三十年後，世界會是什麼樣子？
王恪不知道答案，但他想去看看。
他拿起筆，在筆記本上寫下：
「1984年目標：
方舟資料庫1.0正式發布
專家系統工具包原型完成
龍芯流片成功
家電市場份額突破30%
歐洲研發中心成立」
寫完了，他看著這五條目標，笑了笑。
貪心嗎？有點。
但時間不等人，時代不等人。
他必須貪心一點，跑得快一點，才能在那個未來到來時，讓中國站得高一點。
窗外的海，潮起潮落。
而書房裡的燈，又亮到了很晚。
淺水灣別墅的書房裡，王恪獨自坐在書桌前。桌面上攤著幾份文件：港元匯率反擊戰的總結報告、明遠集團第三季度財務報表、龍芯流片進度更新……但他此刻的目光沒有聚焦在任何一份文件上。
他在看系統界面。
【情緒點餘額：842,567點】
這個數字在三天內暴漲了近三十萬點。來源很雜：香港市民的感激，實業界同行的敬佩，明遠員工的驕傲，甚至還有那些被擊退的炒家們不甘心的怨念——系統很公平，正面負面情緒都收。
但讓王恪關注的不是數字本身，是界面中央閃爍的新提示：
【檢測到宿主在複雜商戰與國際博弈中取得關鍵勝利，觸發成就：「智勝千里」】
【獎勵已發放：「初級人工智慧（專家系統）與資料庫原理」知識包】
【是否立即接收？】
王恪選擇了「是」。
沒有想像中的強光或巨響，就像打開了一扇門——一扇通往未來三十年的技術之門的門縫。信息不是粗暴地灌入，而是像溪流般緩緩流淌，自然而然地成為他記憶的一部分。
他「想起」了專家系統的核心架構：知識庫、推理機、解釋器、人機接口……
他「想起」了關係數據庫的理論基礎：關係代數、SQL語言、事務處理、索引優化……
他「想起」了更遠的東西：模糊邏輯、神經網絡雛形、甚至一點點機器學習的影子——雖然在這個時代，這些概念連學術論文裡都很少見。
信息太多了，王恪閉上眼，靠在椅背上，讓知識慢慢沉澱。書房裡的掛鍾滴答作響，窗外傳來海浪拍岸的聲音。
不知過了多久，他睜開眼，走到白板前，拿起筆。
沒有刻意去畫，手自己動了起來。左邊畫出專家系統的結構圖：知識庫里存儲規則和事實，推理機根據輸入進行推導，解釋器說明推理過程……右邊畫出資料庫的層次結構：物理層、邏輯層、視圖層，以及它們之間的關係。
畫完了，他看著白板上的圖，笑了。
1983年，世界上第一個商用專家系統「DENDRAL」剛剛問世，只能用於化學分析。關係數據庫的概念雖然提出多年，但主流還是層次資料庫和網狀資料庫。而他現在腦子裡這些東西，如果全部實現，足以讓明遠在軟體領域領先世界十年。
但問題也在這裡：太超前了。
硬體跟不上。方舟二代電腦的內存最多擴展到1MB，硬碟最大40MB——這點容量，跑個像樣的資料庫都吃力，更別說專家系統了。
人才跟不上。全世界懂這些概念的人不超過一百個，大多在大學實驗室里寫論文。
生態跟不上。沒有成熟的開發工具，沒有標準的接口協議，甚至沒有足夠的教育材料培養後續人才。
就像給了石器時代的人一張噴氣發動機圖紙，他知道這東西能飛，但造不出來。
王恪放下筆，坐回桌前。他需要制定一個可行的路線圖——不是一步登天，而是搭建一個階梯，一步一步往上爬。
先從資料庫開始。方舟電腦現在用的還是簡單的文件系統，如果能把關係數據庫的概念簡化，做出一個輕量級的版本，就能大幅提升數據處理能力。這對於企業用戶、科研機構來說，會是巨大的吸引力。
然後是專家系統。可以從最垂直的領域入手，比如……電腦故障診斷？把維修經驗寫成規則，讓系統幫助用戶排查問題。這個不需要太複雜的推理，但實用價值高，而且能積累經驗。
他正想著，書房門被輕輕推開。
婁曉娥端著托盤走進來，上面有一碗湯圓。「就知道你還沒睡。」她輕聲說，「吃點東西吧。」
王恪接過碗，湯圓還溫熱。是芝麻餡的，他最喜歡的口味。
「又在想什麼大計劃？」婁曉娥坐在對面，看著他布滿血絲的眼睛。
「在想……怎麼讓電腦更聰明一點。」王恪舀起一個湯圓，「不是計算快，是能像人一樣推理、判斷。」
婁曉娥笑了：「那不成精了？」
「差不多。」王恪也笑了，「不過不是成精，是成為工具——更強大的工具。比如，如果一個醫生用電腦看病歷，電腦能根據症狀提示可能的疾病；如果一個工程師設計電路，電腦能檢查有沒有錯誤……」
「聽起來像科幻小說。」
「現在是科幻，但十年後可能就是現實。」王恪吃完湯圓，把碗放下，「曉娥，你知道嗎，我現在最缺的不是錢，不是技術，是時間。世界變化太快了，我們必須跑得更快。」
婁曉娥握住他的手：「你已經跑得很快了。別太累。」
「嗯。」王恪點點頭，但心裡知道，他不能停。
第二天，明遠研發中心。
王恪召集了軟體部門的骨幹——一共八個人，領頭的是個三十歲的程式設計師，叫吳志強，香港大學計算機系畢業，參與過方舟作業系統的開發。
「今天討論一個新方向。」王恪在白板上寫下兩個詞：「資料庫」和「專家系統」。
會議室里的人都愣住了。這兩個詞他們聽過，但離明遠現在做的個人電腦作業系統，好像有點遠。
「王總，我們……要做資料庫軟體？」吳志強試探著問，「像Oracle那種？但那是給大型機用的，我們的電腦……」
「不是Oracle那種龐然大物。」王恪畫了一個簡化的架構圖，「我們要做的是一個輕量級的關係數據庫，專門為個人電腦和中小型企業設計。內存占用小，安裝簡單，但功能要全——支持SQL查詢、事務處理、數據備份。」
他頓了頓，看大家的表情：「有問題嗎？」
一個年輕程式設計師舉手：「王總，SQL是什麼？」
王恪這才想起來，SQL語言在1983年還沒有成為標準。Oracle公司剛剛發布了第一個商用SQL資料庫，但文檔不公開，知道的人很少。
「一種查詢語言。」王恪在白板上寫下幾個簡單的例子：「SELECT * FROM employees WHERE salary ＞ 1000」「INSERT INTO products VALUES (『電腦』, 2000)……」
他解釋語法，講關係代數的原理，講為什麼要用表而不是樹形結構來組織數據。講得很淺，但足夠讓這些聰明的程式設計師理解核心思想。
吳志強的眼睛越來越亮：「這個思路……比我們現在用的文件系統先進太多了！如果實現，數據處理效率能提升十倍！」
「但實現難度也大十倍。」另一個程式設計師苦笑，「光是那個事務處理——怎麼保證數據一致性？如果中途斷電怎麼辦？」
「有辦法。」王恪開始畫更詳細的圖，「寫前日誌、檢查點、回滾機制……」
他講了一個小時。不是填鴨式灌輸，而是引導大家思考：如果你們來設計，會怎麼做？遇到這個問題，怎麼解決？
這是王恪的風格——他不直接給答案，而是給方向，給工具，然後讓團隊自己探索。探索過程中犯的錯誤、走過的彎路，都是寶貴的經驗。
會議結束時，吳志強已經興奮得坐不住了：「王總，我們馬上成立項目組！就叫……『方舟資料庫』項目！」
「好。」王恪點頭，「但要記住，第一個版本不要追求完美。核心功能實現就行，三個月內出原型。另外，文檔要詳細，API要清晰——這個資料庫不僅要自己用，將來還要開放給第三方開發者。」
「明白！」
資料庫項目啟動了。王恪接著講專家系統。
這次他更謹慎。因為專家系統涉及的知識表示、推理機制，比資料庫更抽象，更難理解。
「想像一下，我們要做一個電腦故障診斷程序。」他從最具體的場景入手，「用戶說：我的電腦開機沒反應。程序會問：電源燈亮嗎？風扇轉嗎？屏幕有顯示嗎？根據答案，一步步縮小範圍，最後給出可能的原因和解決方法。」
這個例子大家都懂。電腦維修是明遠售後服務的重要部分，每個技術支持人員都受過培訓，腦子裡有一堆經驗規則。
「如果我們把這些規則寫成程序呢？」王恪在白板上畫了一個決策樹，「如果電源燈不亮，檢查插座；如果電源燈亮但風扇不轉，檢查電源模塊；如果風扇轉但屏幕不亮，檢查顯卡……」
「這不就是……流程圖嗎？」有人問。
「類似，但更靈活。」王恪解釋，「流程圖是固定的路徑，而專家系統可以根據輸入動態選擇路徑。而且，它可以解釋為什麼給出某個建議——因為規則A和規則B同時滿足，所以可能是問題C。」
他講了一個簡單的專家系統框架：事實庫存儲當前狀態（電源燈亮、風扇轉、屏幕不亮），規則庫存儲知識（如果電源燈亮且風扇轉但屏幕不亮，那麼可能是顯卡故障），推理機根據事實匹配規則，給出結論。
雖然簡化了很多，但核心思想傳達到了。
會議室里安靜了幾分鐘。程式設計師們在消化這些概念。
吳志強先開口：「王總，這個想法……很厲害。但實現起來，規則怎麼寫？誰來確定規則對不對？」
「問得好。」王恪說，「這就是專家系統的難點：知識獲取。我們需要領域專家——比如我們的技術支持主管，把他們的經驗提煉成規則。這個過程很慢，很痛苦，但一旦做成，價值巨大。」
他頓了頓：「所以我建議，專家系統項目先不成立正式團隊，而是作為研究課題。找兩三個有興趣的人，慢慢探索。我們可以先從最簡單的開始：做一個『方舟電腦配置推薦』系統——用戶輸入預算和用途，系統推薦合適的配置。」
這個切入點很巧妙。既實用，又不複雜，還能積累經驗。
會議從上午九點開到下午三點，中午只是匆匆吃了盒飯。結束時，每個人的筆記本上都記滿了東西，腦子裡裝滿了新概念。
王恪走出會議室時，吳志強追上來：「王總，這些想法……您是怎麼想到的？」
王恪停下腳步，想了想：「多看，多想，多做夢。」
「做夢？」
「對。」王恪笑了，「夢想未來的電腦能做什麼，然後想辦法讓夢想成真。」
接下來的幾周，明遠研發中心多了一些奇怪的白板。
資料庫項目組的白板上畫滿了關係代數的公式和SQL語句的語法樹。專家系統課題組的白板上則是決策樹和規則鏈。
程式設計師們開始瘋狂學習。吳志強托人在美國買到了C.J. Date的關係數據庫理論著作，雖然書很厚，讀起來吃力，但大家輪流看，做筆記，討論。
更實際的是，他們開始動手寫代碼。
資料庫項目組決定先用方舟電腦自帶的方舟作業系統做實驗平台。第一個目標：實現一個最簡單的表結構，支持插入、查詢、刪除。
聽起來簡單，做起來難。光是設計文件存儲格式就爭論了三天——如何平衡空間和時間效率？如何支持變長欄位？如何實現索引？
王恪沒有直接給出方案，而是讓團隊自己試。試錯了重來，再試錯再重來。他只在關鍵時刻點撥一下：「想想磁碟的物理結構，連續讀寫和隨機讀寫的速度差多少？」「索引是不是越多越好？」
這種引導式的教學很有效。一個月後，團隊做出了第一個原型——一個只能存儲一萬條記錄、只支持簡單查詢的微型資料庫。性能很差，功能很弱，但它是真正的關係數據庫，支持SQL的一個子集。
測試那天，項目組所有人都很緊張。
吳志強在命令行輸入：「CREATE TABLE students (id INT, name CHAR(20), score FLOAT);」
回車。屏幕顯示「Table created.」
「INSERT INTO students VALUES (1, 『張三』, 85.5);」
「INSERT INTO students VALUES (2, 『李四』, 92.0);」
然後查詢：「SELECT * FROM students WHERE score ＞ 90;」
屏幕緩緩輸出：「2 李四 92.0」
雖然慢了三秒，但結果正確。
實驗室里爆發出歡呼。有人把帽子扔向空中，有人擁抱身邊的同事。吳志強眼睛紅了——這一個月，他瘦了八斤，掉了不少頭髮，但值了。
王恪也在場。他看著屏幕上那行簡單的輸出，心裡湧起一種奇妙的感動。
這不僅僅是一個資料庫原型。這是一顆種子——一顆將在未來長成參天大樹的種子。當其他公司還在用文件系統時，明遠已經有了關係數據庫；當別人開始追趕時，明遠可能已經在研究分布式資料庫、內存資料庫……
一步領先，步步領先。
「很好。」他拍拍吳志強的肩，「接下來優化性能，完善功能。六個月後，我要看到能商用的版本。」
「保證完成任務！」吳志強大聲說。
專家系統課題組進展慢一些，但也出了成果。他們做了一個「電腦配置推薦」的演示程序，只有二十條規則，但已經能根據預算和用途給出合理的建議。
演示時，一個程式設計師假裝用戶：「我想買台電腦，預算五千港幣，主要用來寫文章和看電影。」
程序問：「需要彩色顯示器嗎？」「需要列印功能嗎？」「需要大容量存儲嗎？」
最後給出建議：「方舟二代基本款，加配40MB硬碟，推薦索尼14寸彩色顯示器，總價四千八。」
雖然簡單，但邏輯清晰，解釋清楚：「因為您的用途不需要高性能處理器，所以選擇基本款；寫文章需要存儲空間，所以加硬碟；看電影需要彩色顯示……」
王恪看完演示，點點頭：「可以。繼續完善，增加更多規則。另外，開始準備下一個項目：硬體故障診斷。」
「王總，我們真的要做這個？」課題組成員有點猶豫，「這可是要動硬體的……」
「從軟體診斷開始。」王恪說，「通過系統日誌、錯誤代碼、用戶描述，推斷可能的問題。不需要百分百準確，能覆蓋80%的常見故障就行。」
他頓了頓：「記住，專家系統的核心不是替代人，是輔助人。讓新手也能像專家一樣解決問題，這才是價值。」
課題組成員記下了。
深夜，王恪再次獨自坐在書房裡。
系統界面展開，情緒點的數字在平穩增長——來自研發人員的興奮、成就感、求知慾……
但更讓他在意的是，界面下方出現了新提示：
【檢測到知識傳播與技術創新，觸發隱藏成就：「薪火相傳」】
【獎勵：知識傳授效率提升30%，團隊學習速度提升20%】
這個獎勵很實在。王恪能感覺到，現在他講解技術概念時，聽眾理解得更快，記得更牢。研發團隊的學習曲線明顯變陡了。
他關掉界面，看著窗外的大海。
1983年就要過去了。這一年，明遠經歷了太多：337調查、商業間諜、金融戰、全球擴張、技術突破……
但王恪知道，真正的挑戰還在後面。龍芯即將流片，方舟三代正在設計，家電業務剛剛起步，海外布局剛剛展開。
而他現在手裡，多了兩張王牌：資料庫和人工智慧的種子。
雖然只是種子，雖然還很弱小，但只要精心培育，總有一天會長成森林。
他想起前世，中國在資料庫和人工智慧領域追趕得多麼辛苦。Oracle、IBM、微軟壟斷了市場，制定著標準。中國公司要麼用他們的產品，要麼在低端市場掙扎。
但現在，1983年，一切都還早。
如果明遠能率先建立起自己的資料庫標準，如果能提前布局人工智慧的底層技術，如果能把這兩項核心技術牢牢掌握在中國人手裡……
那麼，三十年後，世界會是什麼樣子？
王恪不知道答案，但他想去看看。
他拿起筆，在筆記本上寫下：
「1984年目標：
方舟資料庫1.0正式發布
專家系統工具包原型完成
龍芯流片成功
家電市場份額突破30%
歐洲研發中心成立」
寫完了，他看著這五條目標，笑了笑。
貪心嗎？有點。
但時間不等人，時代不等人。
他必須貪心一點，跑得快一點，才能在那個未來到來時，讓中國站得高一點。
窗外的海，潮起潮落。
而書房裡的燈，又亮到了很晚。