作者 | Jared Toporek
編譯 | 徐杰承
最近幾個月，關于人工智能的驚人文章在互聯網泛濫。這也引發了很多人的擔心——軟件開發人員可能很快就會失業，被人工智能取代。他們想象所有的企業高管和產品研究人員將繞過大多數或所有的軟件開發人員，直接要求人工智能構建他們想要或需要的東西。但作為一個擁有15年一線開發經驗的人，我覺得這些擔心有點危言聳聽。
編碼可能是一項挑戰，但是我從來沒有在寫單一任務上花費過太多時間。一旦掌握了語法、邏輯和技術，這在大多數時候是一個非常簡單的過程。在軟件構建過程中，真正的問題通常集中在軟件應該做什么。創建軟件最難的部分不是編寫代碼，而是創建需求，而這些軟件需求仍然是由人類定義的。
等等，好像這是個錯誤
在我職業生涯的早期，為了幫助提高某個團隊的研發效率，我被安排中途接手一個項目——軟件的主要目的是在電子商務網站上配置定制產品。
我的任務是負責動態的條款和條件。有條件的關鍵詞取決于所購買產品的類型，以及由于法律要求客戶所在的地區。
在某種程度上，我認為我發現了一個潛在的缺陷，用戶將選擇一種產品類型，這將生成適當的條款和條件，但是在工作流中，它將允許用戶選擇不同的產品類型和預定義的條款和條件，這將違反在有客戶簽名的業務需求中明確約定的特性之一。
我天真地問客戶，“我應該刪除允許用戶覆蓋正確條款和條件的輸入嗎？”從那以后，我得到的回答就烙在了我的腦海里。他的原話是完全自信地說出來的：“這永遠不會發生。”
這是一位在公司工作多年的高級管理人員所說的，他了解公司的業務流程。更何況我有什么資格去質疑他，更別說他是一家付錢給我來制造這種產品的公司的高管了。
幾個月后，就在軟件上線前幾周，客戶端的一名測試人員發現了一個缺陷，并將其分配給了我。當我看到缺陷的細節時，我笑出聲來。這個Bug正是我所擔心的覆蓋默認條款和條件的事情，我被告知永遠不會發生的問題。
修復相對容易，錯誤的后果也很低，但這種經歷在我的職業生涯建設軟件中是一個反復出現的主題。我和大量的軟件工程師同事交談過，知道我并不孤單。問題如果不被發現，就總會變得更大，更難解決，修復成本更高，但是問題的根源通常是相同的:需求不清楚，不一致，或者是錯誤的。
圖片
2、人工智能:國際象棋/自動駕駛
人工智能的概念已經存在了很長一段時間近來高調的進步也引起了媒體的關注。我們可以說的是，人工智能在某些領域已經非常成功了。
早在20世紀80年代，人工智能就已經被應用于國際象棋。人們普遍認為，人工智能已經超過了人類在國際象棋中的能力。這不奇怪，因為國際象棋的參數是有限的)。
國際象棋總是從64個方格上的32個棋子開始，有很好的記錄和官方認可的規則，最重要的是有明確的目標。下棋只是遵循一個規則引擎。人工智能系統可以計算每一步棋的影響，以選擇最有可能的結果來擊敗對手的棋子或獲得位置，并最取勝。
人工智能一直非常活躍的另一個領域是自動駕駛汽車，制造商承諾自動駕駛汽車已經有一段時間了。但在絕大部分情況下，汽車仍需要主動監督；駕駛員可能需要將手放在方向盤上，自動駕駛功能目前仍然不是自主的。
像下棋的人工智能程序一樣，自動駕駛汽車在很大程度上也使用基于規則的引擎做決定。與國際象棋程序不同，如何在每種可能的情況下導航的規則沒有明確定義。在給定的行程中，司機會做出成千上萬個小判斷，比如避開行人、繞開并排停放的汽車、在繁忙的十字路口轉彎。做出正確的判斷意味著你最終會到達商場還是到達醫院。
在技術上，網站或服務的標準是5—6個9，也就是在99.999%(或99.9999%)的時間內可用。實現前99%的成本并不算高。這意味著你的網站或服務一年中可能會有三天(87.6小時)的停機時間。然而，每增加一個9，實現的成本就會指數級增長。當你達到99.9999%時，一年只能允許31.5秒的停機時間。它需要更多的計劃和努力，當然也更昂貴。獲得前99%可能不容易，但按比例來說，這比最后那一小部分要容易得多，也便宜得多。
無論自動駕駛離足夠好有多近，總有發生事故的風險。人類開車時，這些風險也會每天發生。我不知道政府可以接受的事故率和死亡率是多少，但自動駕駛想要實現大范圍普及，它至少要和人類做得一樣好。
之所以如此難以達到可接受的安全水平，是因為駕駛汽車比下棋需要更多的變量，而這些變量是無限的。前95%或99%可能是可預測的，也很容易解釋。然而，在那第之后有如此多的邊緣案例，并且每一個都可能是獨特的；道路上其他人駕駛的其他車輛、道路封閉、施工、事故、天氣事件等等。
讓人工智能模型解釋和識別這些異常和邊緣情況明顯更難，更重要的是如何在不發生事故的情況下做出適當的反應。每個邊緣案例可能共享一些特征，但它們很少相同，這使得人工智能更難確定適當的應對方式。
3、AI不能創造軟件，只能創造代碼
相比于下棋，創建和維護軟件與開車的邏輯更加接近，涉及的變量很多。當你在構建軟件時，你可能會有一個期望的結果，但它不太可能像國際象棋一樣單一。軟件總會面臨功能增加與錯誤修復，這是一個持續的過程。這并不像下棋，一旦贏了或輸了就結束了。
在軟件開發中，我們確實有一個工具可以讓我們的軟件設計更接近嚴格控制的國際象棋規則引擎:技術規范。在最好的情況下，規范會遍歷預期的用戶行為和程序流。用戶是這樣購買產品的:點擊這個按鈕，創建這個數據結構，運行這個服務。然而太多時候，我們得到的需求清單是功能規格、架構圖和不清楚的需求文檔，并被告知要在此基礎上做好判斷。
更糟糕的是，需求常常會發生變化或者被忽略。最近，我被要求構建一個可以讓用戶通過做有關自己身體感覺的選擇題來判斷是否感染新冠的功能。該應用程序將用于全球沒有可靠WIFI的地區。團隊希望我幫助構建一個可以通過SMS(手機短信)進行調查的應用程序。
起初我對此很感興趣，但當我聽到團隊描述他們想要什么時，我意識到這將是一個問題。對于零售公司來說，以1-10為標準詢問您再次光顧他們商店的可能性是一回事，這與用多項選擇題詢問關于用戶感染新冠時的癥狀的多步調查是非常不同的。我提出了這個過程中所有可能的失敗點，并希望團隊明確定義我們將如何處理所有問題的答案。
在明確所有這些問題之后，團隊得出了相同的結論——我們決定暫時放棄這項功能，這實際上是一個成功的結果。如果在提交無效用戶數據時沒有明確解決所有潛在的問題，那將造成是更大的浪費。
使用人工智能創建軟件背后的想法是讓這些利益相關者直接與計算機對話來創建基于SMS的調查，但AI并不會問一些試探性的問題，比如如何處理通過短信收集調查數據時可能出現的問題，它無法解釋人類可能會做錯的事情，也不知道該如何處理這些失誤。
為了利用人工智能構建一個功能性的軟件，你需要知道你想要什么，并且能夠清楚準確地定義它。盡管有時候我只是為自己寫軟件，但往往直到我真正開始寫代碼時，我才意識到其中的困難和挑戰。
4、瀑布vs敏捷，AI做不到的事
在過去的十年中，軟件行業已經從瀑布方法過渡到了敏捷。瀑布在編寫任何代碼之前會準確定義你想要的內容，而敏捷則提供了足夠的靈活性，因此開發者可以在編寫過程中進行調整。
但是事實，很多使用瀑布的軟件項目都失敗了，因為領導者認為他們知道他們想要什么，并認為他們可以準確地描述它并記錄它，但是當最終產品交付時卻并不是這樣。最終，敏捷軟件開發模式成為了這個問題的解毒劑。
人工智能最適合做的，可能是用更成熟的語言重寫我們已經擁有的軟件。目前仍然有很多機構使用非常古老的軟件，而這些軟件通常是由非常古老的語言所構建的，但是學習如何使用它們的程序員越來越少，這會是將來人工智能的一大優勢。如果你確切地知道你想要什么，也許你可以讓人工智能比人類程序員更快更便宜地生產軟件。我相信人工智能可以創造出比人類程序員更快的軟件，但那是因為有人在這個過程中發現了軟件應該做什么。
人工智能實際上在使用瀑布方式構建軟件方面做得更好，而人類通常并不擅長于此。但開發一款成功軟件的流程并不單單是將文檔交給一個研發團隊，然后由他們完全按照文檔進行編碼。人工智能可以做一些非凡的事情，但它不能讀懂你的思想，也不能告訴你你到底應該做些什么。
