?????? 這篇博文真的很長，不過挺有意思。關于智能機器人的發展前景還是很廣的，因為每一步都異常艱難，而什么時候可以終止還無法預料，所以程序員沒辦法失業啊！

轉自于圖靈社區：http://www.ituring.com.cn/article/346

??????? 某天看到一篇博文，《一百年后，人類怎樣編程？》，只是這個題目，就勾起心中無限感慨。文章沒細看，內容大致是分析各種語言，以及其中各種語言現象，今后的發展趨勢。我對于語言的進步一直不感冒，對5年前就有很多人推崇的Ruby，至今也懶得抬眼皮看看，8年前被迫用過幾天Perl，我就斷定這是最糟糕的編程語言之一，因為它標榜自由，卻又沒法真正自由。時至今日，我仍然只用C++，C#，Java這三種語言，如果SQL也算的話就是四種。對于達到一定程度的程序員而言，語言已經不重要了，不管做什么功能或者什么平臺，只要不是初次上手，都應該有50%以上的代碼可以自動生成出來，另外利用開源代碼和商業化構件完成30%以上的工作，真正需要自己手工編寫的部分絕對不應超過20%。不論是自動生成的代碼，還是開源代碼或構件，最大程度的可理解性和通用性是首要追求的目標，因此最通用的，和使用人數最多的語言才是最好的語言。語言的進步對于提高編程效率確有一定幫助，我自己也深有體會，六年前我做C#項目的時候不得不自己寫了對IList進行查詢的功能，兩年之后，LINQ成了語言自帶的標準功能，后來的程序員顯然可以節省開發這個功能的時間。但是，語言帶來的效率提升，遠遠不如思考方式變化引起的編程效率飛躍來得大。

???????從第一天編程開始，我就不喜歡這個工作，看到同事飛快地打鍵盤，屏幕不停地吐出一行行程序，覺得這件事實在傻透了，她編的是FOXPRO，又是一種我很看不起的語言。她編的功能，無非就是橫豎畫上幾根表格線，然后把一些數字和文字填到正確的格子里去，這就是公司里的編程高手所做的事情。我曾經驚訝于這么傻的事情竟然真的需要人來做，可是如果不用人做，又能怎樣呢？那時幸虧我利用一點小聰明，在還沒有開始從事這種傻工作的時候，就改去研究解密算法了，后來又混上了設計師，小經理，總算沒有傻掉，那時心里不免暗自得意和慶幸。

???????2000年，有幸目睹了一位當時國內最牛程序員的一次編程作業，從此徹底顛覆了我的想法。先說說牛人的業績，一個工作日，基本沒加班，完成一個復雜C/S軟件的服務器端，用統計小工具數數代碼，三萬多行。這個軟件經過簡單的測試，第二天就上線實際運行了，每天數千人訪問，沒出過大問題。再說開發過程，開發環境是VS6.0，牛人很少動鼠標，大概嫌耽誤時間，各種快捷鍵運用，讓人眼花繚亂，程序基本上不是寫出來的，而是粘貼過來，重新排列組合一番，再敲上幾個語句補充修正一下，就算大功告成。搞定一個程序塊的時間，基本上跟一般人寫一條語句的時間差不多。整個工作過程中，看不出明顯用于思考的時間，只要不離開座位，鍵盤的聲音就一直連續不停。我想牛人之所以牛，關鍵就在這里，像運用語句一樣運用語句塊，程序不是寫出來的，而是裝配起來的，就產生了如同手工組裝勞斯萊斯與模塊化裝配豐田之間的巨大生產率差異。我那時和牛人不在同一層辦公，平時很少機會接觸，又一次在樓下食堂吃飯正好坐鄰桌，聽到牛人講起一件往事，牛人多年來，不論在哪里工作，都要帶一塊自己的硬盤，里面有幾GB以往做的程序--他的 code base ，有一次這個硬盤突然卡殼了，牛人就跟老婆說，咱們準備回老家改行干別的吧，結果沒過太久，那個硬盤自己又恢復了，所以牛人終于沒有回老家去。可見，如果沒有 code base ，牛人立刻就不牛了。后來我又見過不少優秀程序員，使用自己的 code base 裝配出一個個巨大復雜的程序，這種做法局限性也很明顯，自己的 code base 終究有限，總有不夠用的時候。既然如此，利用別人的 code base 不就解決問題了嗎？理論上是這樣，但現實中卻完全不是這么回事，我很少見到大量利用別人 code base 的編程高手，倒不是這些高手清高，而是他們常常覺得與其看懂人家的程序，還不如自己寫來得快，節省一點打字的時間，就要為了適應別人的思路花更多時間思考，得不償失。可以說，到了這個程度，code base 的大小基本上決定了水平的高低，頂級的牛人都有上百萬乃至數百萬行規模的code base ，俺到今天才攢了50萬左右，離牛人們還差得很遠。按照這個道理，只要時間足夠長，總會有一些牛人可以積攢一個足夠大的 code base ，窮盡當代人類能夠想象到的所有程序，這個時候就沒有編寫，只有裝配了。如果軟件由編寫變成裝配，那么接下來一個自然的發展就是裝配也要自動化，2000年的時候，代碼自動生成工具還不發達，到2005年，基于模板的代碼生成工具已經遍地開花了。然而這一切似乎只是歷史的重復，模板語言似乎變成了又一種高級語言，仍然需要人工編寫，導致牛人們的 code base 當中又多了一些這種模板而已。而且也總有一些例外情況，用模板做起來復雜無比，還不如干脆留著手工完成。

???????計算機是否可以自己組裝程序呢？現在看來，似乎已經很接近了，至少從UML生成代碼框架已經很成熟了，而框架里面需要填入的東西，正是 code base 的內容。現在缺少的，只是找到正確的代碼塊，作一些必要的修正，填入框架中正確的地方的問題。如果 code base 中所有的代碼塊都有正確的形式化描述，代碼框架的每一處地方也都有這樣的形式化描述，把二者做一個匹配不就完成了裝配工作了嗎？至于需要必要的修改的地方，通常用編譯器檢查就能找到。如果真是這樣，那么這件事早就成功了，像IBM這樣的公司，一直就想做成這件事，而且他們并不乏完成這些工作所需的任何資源。

???????然而，時至今日，軟件開發不管怎么自動化，總是有一些例外，需要程序員去手工處理。這些例外情況，通常無關乎高精尖，而是些很普通的問題。在八年以前，我還沒有接觸知識表示和人工智能的時候，這個問題一直在腦中揮之不去。2003年，偶然接觸到cyc項目，這又一次徹底顛覆了我的想法，因為這個cyc剛好能作一些看起來很簡單，卻又非要人工才能處理的事情，而且這些事情并不像看上去那么簡單，一個簡單的推理常常要調用成千上萬條斷言。當然cyc并不是一個真正的常識處理系統，它固然是十余年積累的成果，也有很多閃光的思想，但是局限性也很明顯。不管怎樣，它為我開啟了一個全新的視野。人工智能是個很大的領域，其中有很多天才的創見，要理解它的全部內涵，是件艱巨漫長的工作。然而，有一件事情從開始的時候就能得出結論，那就是，如果計算機真的具有了與人類相當的智能，那么必然就不再需要人來為它編程序，那個時候，就是程序員這個職業壽終正寢的時候，當然，整個軟件產業也將不復存在。所以，程序員以及軟件產業的生存，其實就寄托于那些為數越來越少的，必須人來處理的“例外”情況。

???????我們現在就來關注這些例外情況，因為它們是如此重要，將會決定各位以及產業的命運。

???????軟件是什么呢？計算機發展的早期歷史上是沒有軟件的概念的，那時候只有程序，每個用戶就是他自己的程序員，編寫程序滿足他自己的需求。這個時候的程序員，不需要需求調研，不需要劃分工作階段，總之一句話，想怎么干就怎么干，他們也不會考慮復用，因為程序只是他們個人想法的表達，沒有想法的時候想也沒用，一旦有了想法，兩下就寫出來了，即使需要借鑒以前的想法，從腦子里調出來比從故紙堆翻出來也快捷得多。也許軟件與程序的不同就在于此，軟件是做給別人用的，程序是寫給自己用的。軟件是伴隨著不會編程的“業余”用戶的產生而出現的。開發軟件與寫程序第一個不同的地方就是要做需求調研，不管做多簡單的軟件，都要調研。有的時候，程序員看似沒有做，其實是他和用戶已經很熟悉，用戶的需求早已經都記在腦子里了。用戶有需求就表明用戶有一些需要計算的問題，這些問題可以由計算機做，當然也可以由人來做，事實上computer最早指的是拿著紙筆或者計算尺工作的計算員們。如果由人來完成計算，用戶通常需要告訴計算員計算的公式和流程，然后提供初始數據，如果這位計算員經驗豐富的話，有時候不必如此羅嗦，只需要告訴他算什么題目就可以了，計算員自己知道公式和流程，或者即使當時不知道，也可以自己找資料學習。使用計算機就享受不到如此的便利了，計算機不會自己學習查資料，即使硬盤里存有以往的計算程序，它也不會自己去使用，一定要人手工調出來運行。人與計算機的根本差別不在于處理信息的能力，而在于處理信息的主觀能動性。

???????自從引入了客戶，引入了需求，軟件開發開始變得復雜了，最早的客戶還比較好應付，他們都是懂一些計算機技術的人，那時候完全不懂的人根本不會想到用計算機做事情。最初的需求都很具體，輸入什么，做哪種計算，結果怎么輸出，都講得清清楚楚，所以最初搞需求分析的人都畫數據流圖，只要數據流清楚了，軟件就確定了，今天的程序員就沒這么幸運了，工作流程、訪問權限、用戶體驗等等，撞得滿頭都是包，如果光盯著數據流圖的話，什么也做不出來。那時候的分析員和設計師基本上是同一個人，因為沒有什么好設計的，就是把功能分解一下，列張表1234寫出來，再往后稍微復雜一些，所謂結構化方法，也就是功能多了一些，列表不好使改用層次樹。今天的設計師，最慘的時候UML14種圖全都畫遍，可能也還有沒描述清楚的地方。

???????軟件出現之后，因為商業的驅動，很快就泡沫一般膨脹起來，各位今天目睹了各種泡沫之后，大概會總結出來一條規律，凡是泡沫一定沒有好結果。軟件一旦開始膨脹，所需的人工自然不斷地加倍，于是以IBM為代表（IBM確實養了不少杰出的科學家，但是養了更多豬頭，當科學家和豬頭一起研究問題的時候，通常豬頭不會變成科學家，而科學家卻會變成豬頭），采用了工業時代提高效率的不二法則--增加人手，擴大規模，精細分工，流水作業，至于結果嘛，各位學過軟件工程第一課的話，恐怕就知道他們的事跡了。

???????扯IBM的糗事看似和我們的主題沒多少關系，其實當中有著深刻的聯系。我們前面所說的那些可以自動處理的部分，他們用人工都做得很完美，而在那些例外的地方，卻幾乎無例外地犯錯誤。那么，里外到底是什么呢？為何總是揮之不去呢？要解決這個問題，我們就需要從更深層次挖掘軟件的本質。不管怎么說，軟件的核心功能就是計算，那么計算是什么呢？今天互聯網上充斥著各種各樣的計算，僅僅用數學來概括是不足以涵蓋其外延的。在數字系統之外，也存在各種各樣的計算，比如模擬計算機的計算，軍事上的兵棋推演，商業上的決策方法等等。

???????? 如果要概括所有這些計算共同的特征，就只有三點：第一，都有一組初始的數據，代表著某個現實的或者抽象的系統在某一時刻的狀態；第二，都有一組理論或者公式（或者二者兼具），規定了各個數據如何相互作用；第三，經過計算的過程，最終都得到另一組數據，描述系統在另一時刻可能的狀態。如果把第一、第二兩條中的要素加在一起，稱之為一個模型的話，計算就相當于模型的一次推演。模型推演是人腦最基本的思維方法，人類發明計算機來分擔思考的負擔，因此計算機當然必須能夠擔負這樣的計算工作。然而計算機并不懂得什么是模型，只是一個執行程序的機器，因此必須由人來將模型程序化，軟件簡單地說就是程序化了的模型。面向對象的方法其實就是一種模型表示法，而近年更有人提出模型驅動的開發，這都與軟件的模型性質密不可分。

???????僅僅認識到軟件具有模型的性質還不夠，首先，模型本身是復雜的，雖然所有的模型都可以用一組規律加一組數據來概括，但是實際做過系統的人，特別是做行業系統的人都知道，行業知識本身就是復雜的，相互之間常常有說不清道不明的關系，如果不是自己真正理解了這些知識，僅僅以書本和專家言語為基礎，做一些表面（形式化）的推理，是幾乎一定會出錯的。其次，初始數據也不是簡單的，今天的系統，數據來源多種多樣，精度、可信度各不相同，非結構化的數據常常見到，單是把這些數據轉換到適合模型推演的形式，就要費九牛二虎之力。第三，模型代碼化本身也不是件輕松的工作，今天的計算環境空前復雜，各種平臺，各種支撐系統都要考慮，今天的架構師要掌握的知識比以往任何時候都多。最后，軟件雖然以模型為核心，但絕不僅僅是模型，為了讓模型進行有用的工作，各種輔助系統也必不可少。

???????輔助系統相對獨立，我們先從這里說起。軟件中最重要的輔助系統就是人機界面，人機界面到底有多重要，看看微軟如何發家，以及今天微軟Google為什么打破頭就知道了，只要真正的人工智能還沒有實現，人機界面就是最有利可圖的領域。然而剛入行的程序員通常都不理解這一點，我自己十多年前也只喜歡編寫命令行程序和系統服務，功能復雜不要緊，只要界面少到沒有就好。人機界面常常被認為是美工們的工作范圍，是沒有技術含量的體力活，然而事實總是無情地教訓他們，最近編FLASH的平均工資已經高過編JAVA和C#的了，這就足夠說明問題了。程序員們之所以有這種偏見，主要是他們腦子里計算機技術裝得太滿，而應用場景少到幾乎不存在。人機界面是軟件中比較難以自動生成的部分，特別是如果追求個性化用戶體驗的話。我曾想過把用戶界面都做成主視角游戲的形式，人們可以自然地走進并探索賽博空間，或許比較接近用戶界面的終極形式。這當然還沒實現，如果實現了，以后老板們恐怕就再也搞不清楚員工是在工作還是在玩游戲了吧。在系統中，用戶界面的作用無與倫比，首先，不管做什么計算，用戶總是從用戶界面得到計算結果；其次，模型通常是反復滾動計算的，經常需要通過用戶界面輸入、補充或者修正數據；最后，模型未必完全由計算機實現，模型中有些部分常常不適合今天的計算機處理，比如說圖像內容識別，需要把這部分處理負擔轉移給人，然后人在把處理結果返回計算機，以便計算機繼續計算，這樣就變成了人機配合完成整個模型的計算，這種人機結合的地方也必然需要用戶界面。在軟件系統的所有部分中，人機界面可能將會是是程序員最后的領地。其他的輔助系統主要是人機界面以外的各種輸入輸出接口，這是最容易實現自動編程的領域，無需細說。

???????數據源的問題也相對簡單，而且有TBL等牛人一直在推動數據標準化和互操作，這件事情看起來是無需我們操心了。如果他們最終成功（我毫不懷疑這一點），最終任何數據都可以按對象組織起來，并且得到一個人類能看懂的標簽，而且標簽的編寫方法符合嚴格的形式化定義，我們只要等著到時候從w3c下載解釋程序就足夠了。至于這些對象該放到系統里的什么地方去，那就與他們無關了，是構造模型的人考慮的事情。

???????模型代碼化不僅取決于模型本身，更受計算環境的制約，這是絕大多數程序員所認可的“純技術”活，需要調動程序員最多的關于計算機系統的知識來完成。模型代碼化的工作包括寫出使計算機可以完成模型運算的代碼，以及把模型與周邊輔助系統銜接在一起的代碼。高手和軟件廠商通常都會編寫一些程序框架，以便抹去計算環境不同帶來的復雜性，讓程序員專心處理模型，語言虛擬機，應用服務器都屬于這一類。模型中有一些功能是比較容易自動編程的，比如各個對象的屬性定義和CRUD方法，這部分代碼的自動生成今天已經基本實現了。至于模型規則的代碼化，這個麻煩可就大了，要先解決了模型本身的復雜度才行。

???????構造模型是人腦的一個基本功能，所以我們常常覺得這很容易。然而一旦交給計算機，其中的復雜性就顯現出來了。人腦中最簡單的模型是場景模型，也就是所謂的形象思維，具像思維。這是每個人在小時候，能夠使用語言進行抽象思維之前，唯一可用的思考模型，有一定思維能力的高級動物也具有使用場景模型的能力。場景模型是最常用的思考模型，在其他模型無法解決問題的時候，場景模型總是作為最后的手段。場景模型的推演是基于經驗的，因此只要能夠構造出來，就總是能夠有效地完成推演，而不必擔心沒有理論可用。然而場景模型并不簡單，世界上對場景模型認識最深刻的人群莫過于影視導演了，他們幾十年的功力都花在營造讓大多數人感到真實可信的場景上了，只要看看成為高水平的大導演的難度，就知道全面認識場景模型有多困難。今天的計算機系統是不具備像人類這樣的場景推演能力的，不過人工視覺的研究近年來進展很快，其中相當大的一部分就是解決計算機對視覺場景自動建模的問題，而視覺又是人類獲得場景信息的主要信息源，可以說只要解決了視覺場景的建模，機器理解場景就至少成功了一半。這方面我樂觀一點估計，20年后技術基本就成熟了。比場景模型高級一點的是語言邏輯模型，這種模型的理論都是用語言表示的，模型本身也都可以用語言精確描述出來，相比之下，場景模型雖然也可以用語言來描述，但是很難做到完全不丟失和歪曲信息，特別是當其中有些物體無法對應到被人們廣泛熟知的概念上的時候。語言邏輯模型的推演就是我們平常所說的邏輯推理，也就是用語言形成一條邏輯因果鏈的過程。這類模型因為本身就是形式化的，能用語言外在地表達，而且較少模糊與歧義，因此傳統人工智能領域研究得比較深入透徹，剩下的工作主要是與其他模型如何結合的問題。如果一個問題可以建立語言邏輯模型，那么一定比針對這同一個問題所建立起來的場景模型運算量小很多，這就是抽象的優勢，因此效率大大提高了。在場景模型和語言邏輯模型基礎上，人腦發展出了稱為“數學”的東西，這是更高級的模型系統，具有更高的推演效率，心理學家把感官信號稱為第一信號系統，這個系統對應著場景模型，把語言稱為第二信號系統，這個系統對應語言邏輯模型，照此推理，數學應該稱為第三信號系統才對。數學因為具有邏輯模型的抽象特點，因此很多數學問題可以形式化，非常適合計算機處理，然而，因為數學又有一些部分以場景模型為基礎，所以也有一些數學問題很難用計算機處理，這些不好處理的特例，恐怕要等計算機處理場景模型成熟起來之后才有望解決，我認為30年是個合理的預期。

???????在解決了模型自動構造的基礎上，就有希望創造出具有人類思維能力的計算機系統，然而，計算機比人腦還缺一樣重要的東西，我們前面說過，計算機沒有主觀能動性，因此處理信息的工作需要人來驅動。如果要象人腦那樣完成復雜的工作，計算機必須要自我驅動。今天的計算機有時候也能完成很復雜的計算任務，但是這是以軟件復雜性的極度增加為代價的，而這增加的復雜性，其實所做的只不過是把啟動程序時人類賦予的那個初始驅動力，不斷的轉換成各種形式，傳遞給各個計算單元而已。人類這種神奇的初始驅動力，來源于自身的生命力，或者說具體點，來源于人腦的情感欲望系統。生命力并不是什么神奇的東西，動物也都一樣具有，只不過地球上的人類以外的動物還都沒有聰明到能夠學會計算機，所以它們不能驅動計算機幫他們做事情。情感欲望在計算中所起的作用，至今一直都被學界忽視了，這個系統看似與理性無關，卻是產生智能所需的核心部件，人工智能至今沒有實現，恐怕和科學家們還沒有想到這一點大有關系。再說句題外話，這恐怕和研究信息技術的以男性為主大有關系，男性大多在情感上遲鈍，欲望又簡單直白，沒有深度，所以想不到這其中的關聯也在情理之中。未來的智能計算架構，應當是一大群計算單元，具備各種模型處理能力，在一個模擬人類情感欲望驅動機制的核心的驅動之下，不斷碰撞組合，相互競爭，優勝的計算單元獲得更多資源和信任，從而推動整個計算體系不斷進化，最終產生出智能。50年后，在我離開這個世界之前，或許能夠看到這樣的系統最終成熟起來。

???????模型的自動組合，其實就是軟件的自動組合，在有了這樣的系統之后，任何軟件都能自動組合出來，等到那一天，最后一位人類程序員就終于可以退休了。

總結

以上是生活随笔為你收集整理的AI:**消灭程序员需要一百年吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。