基於過程的質量控制

我現在越來越認為， Agent take 開發需要依賴於一套足夠的質量控制過程來保證。這就像製造業中的 QA 一樣，對關鍵部位進行抽樣，或者是對整個流程控制進行管控，來觀察自己的產出管線是否有保證一個比較良好的質量。一旦這樣的生產管線建立成功，質量就是可以成為能夠復刻的產品。

因為隨著 AI 程式碼的愈發膨脹，人類生核程式碼會變得越來越不可能。你像我寫個東西，整體下來設計加上程式碼產出，一共也就用了 28 個小時，寫了快 1 萬行。其質量出來還幾乎都是生產級的設計。那三個工作日耶，這個放平常，恐怕沒個半個月、一個月下不來。但是現在就可以壓縮到接近一週之內解決。這些程式碼，就算你給我一週的時間，讓我每天去 review，恐怕都不一定能 review 的完。如果按照 500 行 90 分鐘那樣的情況來看的話，哪怕是核心程式碼，恐怕都得拉出個兩三天去 review。因此， Agent take 開發時代， Review 會變得越來越不重要。我不是說它可以沒有，而是會變得越來越不重要，因為大部分程式碼你都沒有精力去 Review。QA 質量控制過程會變得越來越重要。

所以說我現在雖然也微操，但這個微操的層級顆粒度不再放在程式碼層面，而是放在了架構和邊界的層面。尤其是邊界，我認為邊界是非常重要的。邊界本身就像組塊一樣，也符合學習科學中對於人類工作記憶的研究。我們將大的東西，啊，應該說我們將小的細碎的東西，凝抽象成大的東西，將那些零散的東西抽象成組塊。只有這樣，我們的工作記憶才是可以承受的。因此，對於大量複雜的細碎的東西，最好的方法就是將其視作組塊。那麼，良好的程式碼開發，它的組塊應該是什麼呢？在我看來就是邊界。不同的程式碼邊界構成了一個小的模組，不同的小的模組構成了一個大的模組，不同的大個模組構成了整個架構。這就是一個又一個邊界所組成的組塊。

而在最小邊界之下的細碎程式碼，那些完全可以交給 QA 流程來管控，只要邊界測試整體上是通的。然後再加上仍然是過程哦，注意，上生產的過程也是一種過程，不是全量上，而是逐步的、分模組的、一點點的往上上，同樣可以保證，哪怕出了問題，也可以將損失控制在可行範圍內。 還有一個方面則是清晰的設計。以前我會認為微服務可能有點太高成本，但現在來看，微服務的優勢反倒體現出來了，那就是各個模組之間的彼此分離。我自己在開發的時候也注意到了。分離，尤其是對契約負責的架構設計，可以讓 Agent take 並行去進行開發。每個部分只要約定好介面跟契約，就可以直接開發自己的了，不會被阻塞。這是一個很大的優勢。

另一方面則是將 AI 的問題嚴格控制在契約的邊界範圍內，就保證哪怕單個 AI 出了問題，它的問題也不會擴散到外部。而只會在一個模組中發生，微服務也是一樣啊，哪怕這個倉庫真的掛了，也只是一個地方掛，而不會擴散到全局。因此 AI 時代對於那些高度去耦合的程式碼要求量一定會增長。

這些在過去看來可能有些過度設計的存在，在今天變成了質量保證的一個硬性環節。就比如說微服務，我們以前會說，哎呀，這開發成本啊、維護成本啊，都很高。但現在關鍵點在什麼？程式碼都能交給 AI 去寫了，架構才是最重要的。你說多幾個倉庫確實寫起來有點麻煩，但介面這種東西你交給 AI 去寫不就行了嗎？以前得手寫，那確實超級麻煩，但現在不會這樣了。因此當前時代體現出來結果就是，能夠保證質量的架構才是好的架構，尤其是能夠保證 AI 開發之下質量的架構才是好的架構。當然我這裡是從質量角度上來講的，具體到各個情況下肯定有自身的考量。但是在當前的時代，沒有哪個組織能夠眼睜睜的看著 AI 的高效率不用。比如說把一一個月的工作壓縮到一週，這對他來講是巨大的誘惑，或者說甚至形成了一種反向淘汰的選擇壓，沒有積極使用這套生產形式的企業就會被淘汰，因為它的開發週期時間太長，甚至質量也不見得比 AI 好到哪裡去。

總之就是過程會越來越重要，而一個良好的過程設計儘管需要根據情況來設計，但一旦設計好，後續將長期有效，會讓整個產出環境都受益。