我一直在IT企業的研究部門任職，迄今經歷了三家公司：NEC、微軟、華為。工作都是既有基礎研究，又有產品開發。其實，這兩者既有密切聯系，性質上又迥然不同。前者在于發現或發明普適性的理論與方法，后者在于開發實用性的系統與工具。可以說，前者需要的思維方式、基本技能與素質是科學家的，而后者是工程師的。我經常提醒自己，一定要明確在具體項目中自己到底帶著什么“帽子”在工作，是科學家，還是工程師？

我曾經將如何成為優秀科學家的體會整理成若干篇博文發表，而本文來談談如何成為優秀工程師的一些心得。我認為，做工程時應該遵循五項原則，并在實際的工作中把它們作為行為 指南。這些原則是：面對問題、解決問題，系統地解決問題，站在用戶角度看問題，以最小的代價獲得最大的效益，磨在細處。在這里做一總結，僅供大家參考。

面對問題，解決問題

西方有句諺語：“當手中拿著榔頭的時候，你會覺得看到的東西都像是釘子”。根據自己的喜好、特長、習慣來解決問題是工程師的大忌。做工程時最重要的是要面對問題、解決問題。可取的策略應該是探明問題的本質，弄清問題的機理，用最直接、最有效的辦法解決問題。經驗告訴我們，拐彎抹角地解決問題，效果總是不好的。做工程時并不一定需要理論。只要能夠有效地解決問題，其實什么方法都行。“不管白貓黑貓，捉住老鼠就是好貓”在這里也是適用的。當然有理論指導的方法 往往更能抓住問題的本質，以其為工具常常能把問題解決得更好。

在NEC工作時，我曾參加一個自然語言研究小組的立項會議。他們建議開發語音 系統來幫助用戶遙控電視機，因為現在的遙控器操作都過于復雜，不利于老人與兒童使用。用語音聲控電視，當然是很好的想法，現在仍有許多企業在進行這項應用 的開發。印象特別深的是他們斷言，除了通過語音的辦法，不存在其他解決方案。當時，我也認為他們的想法很有道理。

不料，沒過幾個月，日本的其他幾家電器公司推出了用編碼遙控電視的方法，更簡單、更實用。遙控器的操作主要靠數字輸入，每個電視節目都配上一個編碼，報紙每天將編碼在電視節目欄中公布，用戶只要輸入編碼即可觀看或錄制相應的節目。

這件事對我的內心產生了很大的震動，自問為什么NEC的同事們只想到自然語言這條路，而忽視了其他路？不正是因為他們手里拿著自然語言這個榔頭的緣故嗎？

系統地解決問題

動畫片《沒頭腦與不高興》描寫了兩位少年：“沒頭腦”與“不高興”。“沒頭腦”做起事來總是丟三落四，“不高興”待人處事總愛別別扭扭。不久，“沒頭腦”當上了工程師，“不高興”當上了演員。“沒頭腦”設計了一座一百九十九層高的少年宮，樓建好以后，才發現忘記了設計電梯。孩子們為了在這個大樓頂層的劇院看 戲，需要帶著鋪蓋、干糧爬一個月的樓梯，害人不淺。其實，我們在日常生活中也能看到不少“沒頭腦”的作品。工程師需要構建的一定是一個系統。系統一定需要 全面、整體、有機的設計，不能有缺陷與差錯。切忌成為“沒頭腦”的工程師。

在微軟，與唐朝暉博士等合作開發了SQL Server 2005中的文本數據挖掘功能。其中的Term Extraction工具可以從數據庫中的英文文本中自動抽取名詞短語。這個工具的輸入通常是英文文本，看似單一，但設計這個工具時，必須考慮處理其他非 正常輸入，應對所有可能，比如，亂碼、非英文、特殊字符、全文本大寫、不含標點符號文本，等等。記得開發團隊一起構建了一張巨大的邏輯圖表，將所有可能的 輸入列出，準備處理方案，力圖做到“兵來將擋，水來土掩”。這個項目確實鍛煉了大家系統解決問題的能力。

站在用戶角度看問題

蘋果公司的產品，如iPad，用戶界面非常簡單、直觀與易用。據說兩歲的兒童也能無師自通，自如地使用iPad。理由很簡單，蘋果的產品都是為用戶著想，站 在用戶的角度上設計的。正是因為如此，蘋果的產品能夠得到廣大用戶的喜愛和追捧。道理雖然簡單，但我們會發現，許多工程師在開發系統時常常做不到這一點， 所以做出的東西，根本不好用。

在NEC參加的第一個項目是個失敗的項目。目標是開發自然語言的用戶界面，自動將用戶輸入的日語問句轉換成 SQL語句，以便讓普通用戶很方便地訪問數據庫。這個項目的初衷很好，但面臨的最大挑戰是，語言的表現力極其強大，同樣一個意思，可以有許多種不同的說法。開發到最后，系統只能接受受限的自然語言輸入（當時還沒有基于統計學習解決問題的想法，也許可以通過大數據、統計學習的方法在一定程度上能夠解決這個問題，這也是自然語言處理今后研究的一個方向）。拿給用戶使用，反饋非常差，因為對用戶來說掌握受限的自然語言比掌握SQL語言還要困難。沒有能站在用戶 的角度上考慮問題導致了項目的失敗。

以最小代價獲得最大效益

汽車大王福特曾說：“對實業家來說，一條重要法則就是盡可能地以最低的代價生產出最高質量的產品，給工人發出最高的工資。”福特公司1908年出的 Model T汽車價格是825美元，當時沒有多少人能夠買得起，到1924年Model T價格降到290美元，成為一款大眾車，在美國每兩臺售出的汽車中就有一臺是Model T。

其原因是福特公司導入了生產流水線，大大地降低了生產成本。在流水線上，Model T的零部件被標準化，維修成本也大幅下降。工程與其他領域（如科學、藝術）的不同在于它必須考慮代價，包括開發的代價、推廣的代價、使用的代價和維護的代 價。工程師開發系統與工具時，必須權衡效益與代價，力圖以最小的代價獲得最大的效益。

我在微軟參與了Office 2007、Office 2010、Office 2012中SharePoint的開發，具體從事元數據抽取與企業搜索功能的開發。我所在的研究團隊開發了文件元數據自動抽取工具，有兩種方法實 現：CRF與SVM。CRF的精度比SVM高1個百分點，但就抽取部分的代碼量而言，CRF是SVM的若干倍。找SharePoint的架構師 Meyerzon商量，到底采用哪種方法好？Meyerzon毫不猶豫地答道：當然選SVM，因為它的精度只低1個百分點，但所需開發維護的代碼量卻少得 多。對產品來說，開發的代價是不能不考慮的因素。

磨在細處

對工程師而言，上帝就存在于細處！只有精雕細琢、潛心造作，才能做好工程項目。好的系統與工具是靠一點一滴打磨出來的。工程師必須在實際工作中不斷磨練自己的技能，以達到手藝精湛、技術嫻熟的境地，能夠像庖丁一樣游刃有余地解牛，像賣油翁一樣點滴不濺地倒油。

在NEC期間，一起工作的工程開發團隊的負責人叫濱田，從他那里學到了許多編程的技能。特別是在他指導下，開發了文本數據分析系統TopicScope中的核心算法。我不是編程高手，編程只有普通程序員水平，但同事們都說我的代碼寫得很好，條理清晰，結構合理，內容精煉。

這是因為我在濱田的影響下，花了很多功夫寫代碼。對項目的設置、文件的分配都反復斟酌，函數、變量的命名都細心推敲，對系統的執行效率都不斷優化。寫好了程序，過一段時間又拿出來檢查、評價、修改，直至不能找出毛病為止（可惜加入微軟以后，幾乎沒有時間再寫代碼，真希望今后能做一些編程工作）。

從實際工作做起

以上這些原則都很簡單，但真正做好卻并不容易，可謂“知之非難，行之惟艱”。重要的是在實際工作中努力依照這些原則去做，養成成為優秀工程師的習慣。培養自己直接解決問題，系統地解決問題，從用戶的角度解決問題，考慮效益與代價解決問題的能力。不斷提高自己的專業技能，在工作中努力做好細節。你一定知道一些優秀的工程師，他們甚至就在身邊，可以把他們作為榜樣，虛心向他們請教，學習他們的長處，不斷提高自己作為工程師的素質和能力。另外，敢于嘗試，不怕失 敗，在失敗中及時吸取教訓，總結經驗也是非常重要的。