運用迭代方法論讓AI交付工業品質的軟體

我經常聽到一些朋友抱怨說AI寫的程式碼不行，不能用。我認為原因是他們沒有正確的採用迭代這個方法論。

迭代是通過多次嘗試，不斷的逼近一個固定的目標。

在軟體開發領域，迭代幾乎可以用於所有環節。我們從需求開始。

需求有幾個常見的問題:

需求本身品質很差，無法理解。比如”給我寫個女裝電商網站”。
需求接收者的理解和發送端的意圖不一致。這有可能是因為雙方的context不同。
需求在變動。比如提出者開始要求”你的軟體寫完了，給我弄個安卓版，macos版，和Win版，要相容Windows xp”，在得知成本後，他改成”做個web版算了”。

這幾個問題，都可以通過迭代來加以改善。我現在的 Requirements Analyst 角色對一個需求會做一個決策:

如果需求本身無厘頭，直接判定No further action。比如 A項目的需求填到B項目來了，或者”給我制定一個躺著發財計劃”之類的。
如果需求明確，則把自己的理解和行動計劃總結出來，並且作為comments發到issue管理系統（linear或者github issues）。這個文檔會作為後續所有其他角色，developer, troubleshooter, security engineer的行為依據。
如果需求有意義但是不明確，則AI提出問題，把單子狀態設定”等待澄清”，需求方則通過Issue comment予以解答。這個互動可以迭代多次，每一次都更讓雙方的理解更為一致。

以上第三條就是典型的迭代逼近，第一第二就是迭代的出口。有了這個流程，我們可以避免很多無效的工作。這個迭代發生於AI和產品經理之間。

但是當我們說需求明確的時候，是作為自然語言使用者這麼說。而自然語言的可執行性並不太好。因此，我的Synthetic Engineering team還有一個環節是把需求翻譯成測試用例。我的Analyst負責這個工作。 Analyst寫完測試用例程式碼後，直接提交一個PR，人類程式員負責review，重點關注程式碼形式的測試用例是否和自然語言表達的需求相一致。如果不一致，則把狀態置為Testcases Refining，並提出意見。之後AI Analyst根據意見予以修改。

這個迭代發生於AI和人類開發者之間。

在測試用例確定後，AI角色Developer開始工作。他的任務非常明確: 通過測試用例。我的實際經驗，即使在熟悉的項目中，第一次implementation能通過測試的概率非常低，總是會有這樣那樣的問題。這個時候，troubleshooter就入場，通過分析測試用例，修改的程式碼，和錯誤資訊，給出自己的修改意見，記錄在troubleshooting.md中。然後developer根據改文檔去修復。這個互動可以進行好幾次。

這個迭代發生於AI和AI之間。目前，我盡量不讓人類介入，但是後面也可能加上。

總而言之，AI不是阿拉丁神燈，你不能光憑一句咒語就讓你美夢成真。把 AI 視作和人類一樣聰明，博學，急躁，有時候偷懶的同事，更為準確。組織起這麼一批AI開發軟體，和組織人類工程師開發軟體一樣，需要有良好的軟體工程方法。