互聯網信息化咨詢/技術開發/整合營銷
請通過以下方式免費咨詢
提交
隨著各種有關 AI 發展的熱門文章大量涌現，我們這些軟件開發者深感擔憂，擔心不久的將來就會被 AI 取代，失去工作。有些人想象商務高管和產品經理將繞過大多數或所有的軟件開發者，直接要求 AI 按他們的需要創建他們想要的東西。作為一個已經花了 15 年時間根據這些人提供的規格來創建軟件的人，我很難對所有的擔憂認真對待。
編程雖然需要一定的基礎，但學起來也并沒有想象的那么難。一旦你掌握了語法、邏輯和技術，大多數時候你就可以按部就班編寫代碼了。真正困難和復雜的問題通常涉及到軟件應該滿足什么樣的需求，以及如何設計出優雅和高性能的方案。創建軟件最困難的部分并不是編寫代碼，而是創造需求、分析需求，而且這些軟件需求仍然需要由人類定義。
本文將討論需求和軟件之間的關系，以及如果 AI 要替代人類的軟件開發者，它需要具備什么樣的能力或條件。
在我軟件職業生涯的早期，我主動接受了一個項目的任務，并加入了團隊，以幫助提高團隊的工作效率。該軟件的主要功能是在電子商務網站上提供定制產品的配置服務。我被分配了生成動態的條款和條件的任務。條款和條件中包含的表述不僅依賴于購買的產品類型，還要根據客戶所在的美國州的法律要求進行調整。在開發過程中，我認為我發現了一個可能的缺陷。用戶會選擇一種產品類型，這會生成相應的條款和條件，但在工作流的后續過程中，軟件會允許用戶選擇不同的產品類型和預定義的條款和條件。這將違反商業需求中規定的一個特性，該需求已得到客戶的書面確認。我誠懇地問客戶，“我應該刪除允許用戶覆蓋正確條款和條件的選項嗎？”我清楚地記得他的回答。他肯定地說道：“那永遠不會發生”。
這位高級執行官在公司工作了多年，了解公司的業務流程，并且主動承擔了監督這個軟件的責任。我作為一個新人，怎么能質疑任何人，尤其是這是一家付錢讓我們為其構建產品的公司的高級執行官呢？我有些疑惑地搖了搖頭，但也沒有多想這件事。
幾個月后，就在軟件即將上線的幾周前，客戶方的一個測試員發現了一個缺陷，并把它指派給了我。當我看到這個缺陷的詳細情況時，我苦笑了一下。
我之前對覆蓋默認條款和條件的擔憂，我被告知永遠不會發生的事情，猜猜發生了什么？猜猜誰為此負責，誰被要求修復它？
修復這個問題相對簡單，而且“bug”的影響較小，但這種經歷在我開發軟件的職業生涯中一直反復出現。我與很多軟件工程師交談過，知道我并不是唯一一個遇到這種情況的人。問題變得越來越大，更難修復，從而導致成本也更高，但問題的源頭通常是一樣的：需求不明確、不一致或錯誤。
想要用 AI 取代程序員，客戶需要準去額描述他們想要什么。目前還做不到，我們還是安全的。
盡管人工智能的概念已經存在很長一段時間，但最近引人矚目的成就也引發了媒體，甚至過會的高度關注。人工智能在某些領域已經取得了巨大成功，第一個讓人想到的就是棋類游戲。早在1980年代，人工智能就開始應用于棋類游戲中。公認的是，人工智能已經超越了人類在棋盤上的水平。這并不令人驚訝，因為棋類游戲的變量是有限的（但是游戲還未被完全解決）。
棋盤游戲總是從 32 個棋子在 64 個格子上開始，有公認的明確的規則，最重要的是有明確的目標。在每一輪中，有有限的可能著法。下棋就是遵循規則系統。人工智能系統可以計算每一步的后果，選擇最有可能俘獲對手棋子、占領優勢地位，最終獲勝的走法。還有另一個人工智能非常活躍的領域 —— 自動駕駛汽車。制造商們一直承諾著自動駕駛汽車的推出。有些汽車有自動駕駛能力，但也有限制條件。在許多情況下，汽車需要持續監控；駕駛員可能需要雙手握住方向盤，自動駕駛功能并不是完全自主的。
就像玩棋的人工智能程序一樣，自動駕駛汽車在做決定時主要使用基于規則的引擎。不同于棋盤程序，如何在每一種可能的情況下導航的規則并沒有明確定義。在一次行程中，駕駛員可能需要做出數千個小判斷，比如避開行人、繞過雙停車，以及在繁忙的交叉路口轉彎。做出正確的判斷意味著區別在于安全抵達商場還是被送到醫院。
在科技行業，標準是可用性達到99.999%甚至99.9999% —— 一個網站或服務在 99.999%（或99.9999%）的時間內是可用的。達到最低的 99% 的成本并不高，這意味著你的網站或服務一年可以不可用超過三天——87.6 小時。然而每多一個 9，成本就呈指數級增長。當你達到 99.9999%的 時候，你一年只能允許 31.5 秒的停機時間。這需要更多的規劃和努力，當然花費也更高。獲得首個 99% 可能并不容易，但相比于那最后的微小部分，它在比例上顯然更容易也更便宜。
一年有 365 X 24 X 60 分鐘 = 525,600 分鐘
99% 可用性 -> 故障 5256 分鐘，87.6 小時
99.9% 可用性 -> 故障 526 分鐘，8.76 小時
99.99% 可用性 -> 故障 52 分鐘，少于1小時
99.999% 可用性 -> 故障 5.2 分鐘
99.9999% 可用性 -> 故障 0.52 分鐘，大約 31.5 秒
人工智能的水平再高，也不可能消除事故和死亡的危險。這些風險和后果每天都在人類駕駛員駕駛汽車的過程中發生。我不知道政府會接受何種程度的事故和死亡率，但我們必須期待自動駕駛汽車至少要比人類駕駛者有更低的事故和死亡率。
之所以難以達到可以接受的安全水平，是因為駕駛汽車涉及的變量比棋類游戲多得多，而且這些變量并不是有限的。最低的 95% 或 99% 可能是可預測的，也容易達到。然而，在最低的 99% 之后還有許多的邊緣情況，每一種可能都有一些共性，但每一種都是獨一無二的；還有其他由人類駕駛的路上車輛、道路封閉、施工、事故、天氣情況，或者在道路被鋪設新瀝青后，但道路的分隔線還未被畫上的情況下駕駛。使你的人工智能系統能夠處理和識別那些異常和邊緣情況，更重要的是如何避免事故并適當應對，這比較難。每一個邊緣情況可能有一些共性，但很少完全相同，這些變量使得人工智能更難確定適當的應對方式。
構建和維護軟件更像駕駛，而不是下棋。涉及的變量更多，規則基于判斷。當你構建軟件時，你可能有期望的結果，但它不太可能像棋類游戲那樣確定。軟件很少完善；功能會被添加，錯誤會被修復；這是一個持續的過程。然而與軟件不同，一旦棋局勝負已定，比賽就結束了。
在軟件開發中，我們確實有一個工具可以使我們的軟件設計更接近于棋類游戲的嚴格控制的規則引擎：技術規格。在最佳的情況下，規格說明了預期的用戶行為和程序流程。這就是用戶進行數字交易的方式：點擊這個按鈕，創建這個數據結構，運行這個服務。然而，我們往往得不到這樣的規格。我們經常被賦予一份清單，上面列出了功能規格的期望，草草畫在餐巾紙背面的線框圖，以及含糊不清的需求文檔，然后被告知要做出最好的判斷。
更糟糕的是，需求可能會變更或被忽略。最近我被要求幫助一個團隊構建一個能夠幫助人們獲取關于與 COVID-19相關的健康問題信息的東西。這個應用程序將面向那些沒有可靠 WIFI 的地區。該團隊希望我能幫助構建一個可以通過 SMS（手機短信）進行調查的應用程序。起初，我對能參與其中感到非常興奮。
然而，當我開始聽到團隊描述他們想要的東西時，我意識到這將是一個問題。對于一個零售公司來說，詢問你在1-10 的范圍內再次在他們的店鋪購物的可能性是一回事。但是通過多選問題詢問你可能表現出的 COVID 感染癥狀的多步調查則是另一回事。我從未說不，但我確實提出了在這個過程中可能出現的所有故障點，并希望團隊清楚定義我們將如何處理所有問題的方案。我們是否會使用逗號來分隔數字，將每個數字映射到一個答案？如果提交的答案并未映射到給出的任何選項，將會發生什么？
經過所有這些問題，團隊達到了同樣的結論。我們決定最好還是不要繼續進行。信不信由你，我會說這實際上是一個成功的結果。如果在提交的用戶數據無效時，所有潛在錯誤沒有明確的解決方案，那么繼續進行將更浪費。
使用 AI 來創建軟件的想法，是讓那些相同的利益相關者直接與計算機對話來創建一個基于 SMS 的調查嗎？AI是否會問一些探究性的問題，關于如何處理通過 SMS 收集調查數據可能出現的所有問題？它是否會考慮到我們作為人類在這個過程中可能做錯的所有事情，以及如何處理這些失誤？
為了從 AI 中生成一個功能完整的軟件，你需要知道你想要什么，并能夠清楚、準確地定義它。有時，在我開始編寫代碼之前，我未意識到一些潛在的困難和挑戰。在過去的十年中，軟件行業從瀑布方模型變為敏捷開發。瀑布方法在編寫任何代碼之前就準確定義了你想要什么，而敏捷則允許你在過程中進行調整。
許多使用瀑布法的軟件項目失敗了，因為利益相關者認為他們知道他們想要什么，并認為他們可以準確地描述和記錄它。然而，他們在最終產品交付時常常感到極度失望。敏捷軟件開發被視為是這一問題的解決方案。AI 或許最適合用于重構我們已有的、但需要使用更新硬件或更現代編程語言進行重寫的軟件。還有很多機構的軟件是用 COBOL 編寫的，但學習如何使用它的程序員越來越少。如果你確切知道你想要什么，也許你可以讓 AI 比一組人類程序員更快、以更低的成本開發軟件。我認為 AI 能夠比人類程序員更快地開發軟件，但這是建立在有人先搞清楚了軟件的功能和需求的基礎上的。
盡管瀑布法被親切地稱為“死亡行軍(death march)”，AI在使用瀑布法構建軟件時可能表現得相當好。在瀑布法中做得糟糕的是誰？是我們自己！軟件開發的關鍵是寫代碼前的大量工作，而不是把簽署的文檔交給程序員團隊編寫代碼的部分。人工智能可以把事情做得很出色，但它還不能直接讀取你的思想，也不能告訴你應該想要什么。
更多新聞
