網易云音樂前 CTO 曹偲：代碼越來越不重要，好的架構才是軟件工程核心

網易云音樂前 CTO 曹偲做了一款 AI Coding 產品 Toco AI。雖然是 Coding 產品，但他們想解決的問題不太一樣。

在他看來，「單純的代碼能力的提升不能解決領域內所有問題」。他們想把確定性和工程性帶入 AI Coding。

在 AI 程序員之外，他們專門打造了一個 AI 架構師，用來解決軟件工程的架構和可維護的難題。

「寫代碼本身不會帶來任何社會價值，只有代碼寫得好、容易維護，才能帶來社會價值。」

AI Coding 和工程的結合已經逐漸成為行業內的共識。

什么是 AI 架構師，Toco AI 又打算如何解決軟件架構和復雜性的問題？

在 Toco AI 產品開始內測前，我們跟曹偲聊了聊他的這次創業，以及對于 Coding 賽道的思考。

以下是 Founder Park 與 Toco AI 創始人曹偲的對話，經編輯整理。

Toco AI 官網：https://tocoai.cn/

采訪 | 萬戶

編輯 | 夏天

??關注 Founder Park，最及時最干貨的創業分享

超 19000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的 AI 產品曝光渠道

01把確定性和工程性帶入 Vibe Coding

Founder Park：為什么會選擇切入 coding 賽道？這個賽道已經很卷了。

曹偲：我做了差不多 10 年的 CTO，團隊也從 7 個人帶到了 700 個人。在 2016 年，我們團隊從 20 個人擴張到 70 個人的時候，我的身份也從技術經理向一個真正的技術管理者轉變。那時候我發現管理的抓手很少，我不可能去看所有人的代碼，團隊也分了很多組，怎么去協調和管理？當時有幾個點對我的技術管理理念影響很大。

第一，我認為架構決定了軟件開發的上下限而不僅是代碼。所以云音樂很早就有架構師委員會這樣的虛擬組織。

第二，一定要工具化，而不能只停留在口號上。現在很多架構理論或者最佳實踐，還都停留在文字層面，比如寫一些文檔。但文章每個人的理解不一樣，執行也不一樣，這是沒有意義的。如果有最佳實踐，我們一定要把它工具化。比如說 DDD，非常好的理論，前段時間也看到很多和它結合的 AI Coding 實踐，但問題在于這些實踐的落地往往都是經驗而非固化的程序，實踐中就會出現偏差、落地等一系列問題。

在 22 年的時候，我們在網易內部討論未來的技術發展，有同事就跟我說 GPT-3 特別強。當時我們就覺得 AI 時代的到來，很有可能會對整個研發體系造成非線性變化。如果 AI 繼續往前走，人與程序之間的交流，其抽象程度會變得越來越高，這也是大家一直想做的事。最早是打孔帶，后來是匯編，再到編程語言。

但認真想，編程語言也往往不是描述業務的最好方式，比如，描述一個歌單要分頁，人類說話可能就幾句，但在代碼里就很復雜：要去取數、拼裝數據、如何設置分頁參數、如何獲取下一頁、格式怎么定義……是一大堆分散在各種代碼里的東西去描述一個抽象的概念。那么 AI 時代的到來，有沒有可能讓軟件研發的范式發生根本性的變化，從對代碼的關注大量轉移到對架構的抽象上來。

這幾個點結合起來，在網易云音樂上市之后，我們選擇個人發展路徑時，就會去考慮 AI 時代如何更好地做研發這件事。

Founder Park：你們的產品主要是解決什么問題的？

曹偲：Cursor 算是一個概率性、freestyle 的工具。這類工具確實有它適用的好場景，適應面更廣。但是，軟件研發本質上是一個工程。工程就需要確定性、需要工程化的東西，而工程化就包含了規范、約束和嚴謹。我們希望把這些嚴謹性、確定性帶到 AI Coding 里面來。

這是我們很明確的差異點。

我們把建模方法論和建模工具引入 AI Coding 就是為了把確定性和工程性帶入軟件研發。而且也不會大幅提升使用成本，因為我們還是個端到端的工具，不是單純的建模工具。單純的建模工具不能交付產品，但因為有了 AI，你的建模工具就可以完整地交付整個需求。

Founder Park：和 Vibe Coding 類似，架構問題，如果是初學者用戶，沒有太多了解，會不會存在 AI 給出的東西，他沒法判斷好壞的問題？

曹偲：雖然我們把架構都歸結為很高大上的東西，但嚴格來說，架構分兩個方向：技術架構。技術架構可以被內化到引擎里，由 AI 輔助解決很多事情，這個大家不太需要關心。特別對于一群中小微企業來說，他們對性能這些東西的考量的場景并不多，也不需要超出他的范圍去理解技術架構。

而業務架構，最熟的反而是產品經理和了解業務的人，不完全是程序員。這部分東西，經過 AI 和我們產品的解釋，反而更容易理解了。

初學者只是需要一定的時間去理解，因為任何一個時代的工程工具使用都不可能是完全無門檻的。就像在移動互聯網時代，很多產品經理也需要學點 SQL 一樣，那你最起碼得看懂建模這件事。它是一種異化的表達，不可能說因為有了 AI，你就什么都不用學了，這個邏輯是不成立的。

架構本身就是對業務的抽象方法而已，并不代表它是一個高大上的東西。提架構，并不是說我們覺得門檻高，把架構普世化、平民化、內嵌化，才是最重要的事情。

Founder Park：有點類似于很多筆記軟件，一開始就強調它自己有一套做筆記的思路，這個思路本身才是重要的。

曹偲：對。我們更多的是啟發你。經驗足的人，他有自己的發揮空間；經驗不足的人，用我們的產品最起碼能得到一個合理的、能把思路抽取出來的過程。

02

架構和可維護性是軟件的必備特質

Founder Park：舉一個典型的客戶案例場景？

曹偲：一類是小型的 SMB 企業，需要做有長期規劃的業務。比如它做自己的電商管理系統，但它可能沒有能力引入一位核心架構師，用我們的產品就等于內嵌了一個架構師，可以用業內比較好的最佳實踐，從頭到尾構建一個良好架構的電商系統。但如果他全程用 Cursor 自己去探索，很多人如果完全對架構不熟，做出來的東西在我們看來其實并不是一個真正的軟件，只是一個功能的實現。

第二類就有點違反大家的直覺，就是在很多中大型系統，現在 AI Coding 的落地其實并不好。他們也可以用 Toco 來逐步地去重構或構建新的模塊。

早些年我在云音樂架構治理時，整個 CI/CD 和架構里其實沒有原始的一手數據。研發過程是缺少數字化的，除了代碼和不準確的需求，大量信息都是丟失的，基本上用戶的 CI/CD 流程很難完全自動化。而 Toco 這種以架構驅動的平臺，某種程度上說，想做的就是幫助研發過程本身做到數字化管理。

所以，最典型的兩個客戶，對于 SMB，內嵌了一個架構師；對于中大型系統，它是一個很好的工具，可以維護你的架構不被劣化，同時協助團隊持續協作。

Founder Park：你們和 Cursor、Claude Code 的區別是？

曹偲：產品的更大區別在于視角和解決的場景不同。

我們更多是在探索一條軟件工程的端對端實現，于是找到一條可以建模的垂直賽道來做這件事。但就目前來看，服務端有標準化的建模，其他的研發領域，比如算法或者 iOS 開發，還沒有一套非常標準化的建模方法，所以在該垂直領域我們把行業里的最好理論和我們的最佳實踐都固化下來做了一個建模驅動的端對端研發工具。

在該賽道里，我認為我們是更優的解決方案，一個更高維度的產品。Claude Code 和 Cursor 更關注的是具體的代碼實現，當然也可以用人來組織上層架構，但那不是原生的，而且每個人的理解會有偏差，也并非最佳實踐。我們把團隊優秀的最佳實踐與行業公認的理念相結合，做到了端到端交付。

Founder Park：架構做完之后，后續寫具體模塊的時候，可以不用 Toco，切換到 Cursor 來寫嗎？

曹偲：你可以隨時用其他產品來維護這個項目，但如果想一直獲得 Toco 提供的架構和代碼一致帶來的便利，就需要一直使用 Toco。而且我們的產品本身也是端對端的，在編碼的 AI 實現上，效果是和其他產品齊平，甚至由于有設計作為更好的上下文，會表現得更好。

你可以從 Toco 遷移到 Cursor，但很難再從 Cursor 遷移回 Toco。因為好的架構一定是有約束的。最好是彼此有一個約定，遵循社區的約定。

Founder Park：現階段產品的核心用戶群會是一群什么樣的人？

曹偲：可以把視野拉長一點看。

我們團隊想做的，是成為像 Spring 之于 Java，K8s 之于運維那樣的東西。作為行業最早關注 AI Coding 中抽象落地的團隊，希望去引領抽象層的定義。想想 K8s，原來的運維不是那樣運維機器的，而是用各種命令，很隨意，那時候運維也不是工程化的。Spring 之前的 Java，你用 Struts 也好，自己寫框架也好，很多東西都不統一。我們最終是想成為 AI Coding 在軟件開發中的抽象層，這是我們更長遠的目標。

所以，我們真正面向的用戶會是做這一類研發的所有開發者。但是前期，更能理解我們的人，我相信是一些資深開發者。因為他們對這個感觸更痛。

Founder Park：理論上，只要是參與或創造一個復雜軟件工程的開發者，未來都是這個軟件的目標用戶。

曹偲：對，再補充一點，這里面還有一個很違反常識的東西，就是沒有嚴格意義上的復雜軟件和簡單軟件。只要軟件一直在用，它一定會變得非常復雜。哪怕做一個會議室管理系統，一開始建兩個表、寫兩個接口就行。但只要它一直被用，就會多出很多東西，比如議程管理，然后議程會有取消，取消之后又會引發很多其他事情。

一個軟件只要被反復使用，特別是業務軟件，它就會越變越復雜。所以我們覺得，良好的架構并不是只為大型軟件準備的，它是一個軟件本身應該必備的東西。只是需要有手段讓更多的軟件具備低門檻、低成本的好架構。

或者可以這么理解，所謂的架構，就是對業務邏輯一個更合理的還原。從這個角度看，就不應該特意去區分大型和小型軟件。只是說，大型軟件不這么做一定會死，而小型軟件還可以通過「搭飛線」的方式撐到它變大為止。問題就在于此，并不是說小軟件就完全可以不重視架構。

Founder Park：也就是說，軟件本身就代表著要有架構、有可維護性這個特質。

曹偲：對，除非是一些生命周期很短的軟件，就可以不用關心。比如我就用一次，或者它是個腳本。為什么腳本從來不提架構？因為腳本的生命周期往往很短，而且它的工作場景不會發生劇烈變化。但業務系統只要被長期使用，它的工作環境就一定會變化，就一定會有很多變革出來。

Founder Park：在你們目前的內測場景里，最能體現你們產品能力的，有沒有一些特別的場景或者行業？

曹偲：它目前最擅長的肯定是業務系統的服務端。當然，我們后續也會去延展，去做前端或者 BI 這一側的解決方案。按照自動駕駛來類比的話，Toco 是一個封閉賽道的 L4，解決某類問題從架構開始的更高維度落地，而 Cursor 可能是一個全場景的 L3，它不會關心到某一個具體場景的更高程度抽象。

我們不會和某個具體行業或場景綁定，我們能支持的能力在各行業中都有存在。

03

寫代碼不會帶來價值，交付產品才能帶來價值

Founder Park：Toco 也提供 AI Coding 的能力，和 Cursor、Claude Code 相比，會有能力上的差別嗎？

曹偲：無論是 Claude、Cursor 還是我們，基礎的編碼能力都來源于大模型本身，這點是對齊的。大模型也會出現錯誤的代碼，這也是我們為什么希望把更多的確定性帶到軟件開發里來的一個很大原因。而且我理解軟件開發這件事，不是給每個人提供一個扳手就解決問題，這是 Cursor 類產品的核心場景，但真正的現代化是生產線的現代化，我們不僅要把目光放在頂級大牛和一些新入者的反饋上，這在研發群體里面并不是多數。更應該考慮新的革命到來的時候，整個社會有沒有更進一步用好工具的空間。

Founder Park：有扳手不代表生產力就進入了現代化流程。生產力進步的核心在于有了一個大型的、現代化的流水線作業，這才是提效的根本。

曹偲：我的理解是這樣的。2025 年可以說是 AI Coding 最火的一年。AI Coding 是一個非常偉大的范式變化，大家也看到了一些很 fancy 的機會，但是，2025 年寫的這些代碼，到 2026 年就要去改、去維護，甚至線上會出現 bug。那明年就會有更多的聲音提出來，如何讓 AI Coding 更好地在軟件里應用？

因為它是個工具，我們不能把它當成棒棒糖。寫代碼本身不會帶來任何社會價值，使用工具的愉悅只是第一步，只有代碼寫得好、容易維護，才能帶來社會價值。大家的興奮感會逐漸從寫代碼時的興奮，轉變為如何讓這個東西可持續地為寫代碼這件事提供長期價值。我們會發現，像谷歌、Netflix 的工程主管，或者 Martin Fowler，都在提 AI Coding 和軟件工程的結合。雖然每個人的思路可能有點區別，但這個大方向不會變。

假設你是最終的消費者，是來吃拉面的，你絕對不只是希望廚師做飯的時候很開心、很興奮，更關注的是拉面好吃管飽，希望他很嚴謹地做這件事。我們最終服務的是吃拉面的人，這是 AI 的本質問題，最終也要讓吃拉面的人很開心。軟件本身是追求確定性的，酷炫的東西不應該是軟件的制作過程，而應該是軟件工程帶來的長遠變化。

Founder Park：這是否意味著，今年行業內會更加意識到，代碼本身可能正變成軟件工程里最不重要的那部分？因為 AI 已經能幫我們寫代碼了。反倒是代碼之上的東西，比如架構，開始變得越來越重要了。

曹偲：我越來越覺得一些模式化的代碼將越來越不重要。Java 也好，Go 也好，Python 也好，其實都是在表達同樣的問題，學習門檻也很低，可以快速抹平。

但架構、特別是業務架構為什么這么重要？架構其實是我們對現有真實世界的理解，甚至還要加上預測性的理解。因為很多軟件的維護性和考量點在于它的擴展性，而所謂的擴展性就是對未來的一個預判。比如，這個會議會不會變成一個很大的會議？還是一直都是三個人開會？這里面的性能要求是不一樣的，設計也會不同。

我不認為 AI 在這里起主導因素，它可以起輔助作用，告訴你有哪些選項，但真正了解業務本身的一定是人，而不是 AI。所以我認為，以后用什么語言和框架表達都會越來越不重要。越來越重要的是對業務的描述、理解，甚至是長期的規劃。

原來你會很關心機器是怎么運作的，后來你關心 if-else，也就是邏輯是怎么運作的。最后，你會不太關心邏輯怎么運作，而更關心業務是怎么運作的。這是 AI 帶來的范式性變化。

Founder Park：2025 年的 AI 已經能夠解決寫代碼的事情了，能力上升之后，解決不了做架構的事嗎？

曹偲：我覺得不是說它不能做，而是主導者一定還是人。舉個例子，AI 能了解醫院大概是怎么運作的，但它能了解這個醫院是怎么運作的嗎？它沒法了解。它能預測這個醫院以后想要怎么樣嗎？它也沒法預測。

技術架構會隨著我們和 AI 的能力繼續黑盒化，但業務架構其實就是精準還原現實, 是很難被 AI 取代的, 這將是 AI 最后一塊可以完全接管的領域。

Founder Park：現實世界的邏輯沒有那么簡單。

曹偲：真實世界不是線性的，你想，網易云音樂跟 QQ 音樂都是音樂產品，它的理念一樣嗎？不一樣。我能不能賣一個工具，說網易云音樂和 QQ 音樂都用一套工具去解決？不行，它們的曲庫管理都不一樣，哪怕最標準化的東西邏輯都不太一樣。

Founder Park：也就是說，今天的 AI 可能已經能夠解決所謂的技術架構問題了，但是對于業務邏輯和整個產品的業務架構，這是一個很復雜、跟當下的產品策略、團隊目標、甚至現實環境都強關聯的東西。簡單來說，在未來的幾年內，AI 沒有辦法獲取到足夠多的上下文來理解這些，最終的決策權核心還是在人類手里。

曹偲：對，我覺得方向盤永遠都在人的手上，但是剎車、油門這些很有可能交給 AI。因為有些東西它的控制變量比較少，只要判斷會不會撞上東西，就可以控制剎車。但是我想去哪里，這個事情在大多數軟件研發中可能永遠都得我自己說了算。

Founder Park：其他的軟件是不是也可以解決技術架構的難題？

曹偲：并不是只有我們解決技術架構。我們是一個架構工具，把架構的流程嵌入進來。我們絕對不敢妄稱只有我們關心架構，其他人就不關心。Cursor 當然也能做架構，但它的隨意性很強，也不是最佳實踐。如果你是個非常資深的人，可以自己去控制，那當然很好。但如果你對這塊本身就不熟，你也無法評判好壞，就有可能自己跟 AI 一起掉到溝里去。它也是非約束性的，它描述的東西會產生漂移, 代碼會和架構不一致。

04

對 AI 抱有敬畏之心，才有可能用得更好

Founder Park：很好奇，為什么大家會突然覺得寫代碼是一件很酷、很爽的事？就像做飯、寫文章一樣，很少有人吹噓過程很爽。這種說法在編程行業里以前就有，還是因為 AI 才出現的？

曹偲：雖然我們都自嘲是「碼農」，但這不完全是現實。

首先，編程行業讓大家更為興奮的一個原因，是因為它是通往數字世界必不可少的鑰匙。它本身就是一件改變世界的事，所以大家很容易興奮，而且這是一個增量市場。特別是像大模型出來的時候，因為大模型本身也是程序。

其次，雖然我們自嘲是碼農，但相對來說我們還是一些高知群體，這些人有很多自我價值實現的訴求。所以會去尋找編程帶來的快樂，但這和約束其實并不矛盾。今天有人會去把 C 的編譯器重新寫一遍嗎？沒有的。大家會更關心更高層的快樂，比如我如何組織我的業務。原來我很多精力都關注在我的匯編里這個順序換一下就能提升一倍效率，所有注意力都在那上面。今天也是一樣，在這個轉型期，一定還有人說，我不要這樣寫代碼，怎么爽怎么來。

研發圈有個很經典的段子，大家為換行前面到底是 Tab 還是四個空格吵了那么久。但如果有一天代碼完全不是你寫的，如果 AI 寫成了四個空格，你還強行用 prompt 去約束它一定是 Tab 嗎？沒有必要。在這個范式變化中我們就會理解，如果可以把架構、把很多東西固化到軟件里交給 AI，我們就可以更多地關心業務的走向，這才是更難的。比如，這套醫院系統可不可以支撐更好的醫患體驗？銀行系統是不是可以滿足更好的金融管理需求？

人的關注點也是在不斷變化的，只是在這個轉變過程中，未必那么多人會第一時間反應過來，他可能還會關心，我的匯編是不是比別人寫得好一點，哈哈。

Founder Park：今年這一波 coding 產品出現，大家在討論程序員會不會被取代，其實他可能不是真的被取代，而是這一波技術在進步引導大家，不應該把精力關注在怎么寫出更漂亮的代碼上，而是要往前走，去關注怎么做出好的架構，或者說在 AI 的輔助下，把人的能力放在更適合人做的事情上。

曹偲：是的。你想想看，我們作為程序員，一天手動能寫 400 多行代碼。而且很多時候都是在慣性編程。特別是像我們這些做架構、做程序很久的人，很多時候從想好一件事到實現，中間有很長的時間都是在寫代碼。AI 來了之后這個過程就會變成，我想好了，執行速度會非常非常快。

我認為這是范式性變化。中間會不會造成一些失業？這是個社會轉型的問題。人在他所有的智能被其他東西取代之前，人所做的事情一定是越來越抽象，越來越滿足自己高層次的需求，關注「what」而不是「how」，這是一個大的發展趨勢。至于過程中產生的社會問題，或者對人的技能要求變化，這是由整個社會去決定的。

Founder Park：確實。現在所有行業都會面臨這樣的問題，我們這種寫文章的也會擔心，AI 都可以直接寫文章了。

曹偲：對，所有行業，不光是編程。相信你們行業感受應該更深。我有很多新聞系的同學和好朋友，他們會覺得新聞學已經完全被 AI 和移動互聯網顛覆得面目全非了。但是你會發現，它只是換了一些要求而已，依然還是有些人做得很好，有些人做得不太好，并不是有了 AI 大家都可以變成一個水平。只是說，它沒有那么多科班要求了，它更要求你去挖掘一些別人挖掘不到的點。這個邏輯，我感覺今時今日的 AI 還沒有這個能力。

Founder Park：對于「寫」本身的要求會降低，但是對于你要「表達什么」這件事，回到了人類更主動的事情上，這和架構有點類似。

曹偲：對。而且時至今日，AI 還有很多東西不是很嚴謹。如果你是一個盲目的 AI 信奉者，最起碼在很長一段時間內，并不會做得比別人更好。反而是你對 AI 抱有敬畏之心去使用它的時候，才有可能做得比別人更好。絕對不是說，我比別人更相信 AI，所以我會用得更好。

05

可能不會再有新的編程語言了，但沒有影響

Founder Park：如果 AI 再發展，代碼語言之爭，或者技術棧之爭還會有嗎？

曹偲：很明顯，語言和技術棧會慢慢地消亡掉。消亡不是說它沒了，而是會慢慢地黑盒化。當然這個過程可能會比想象中要久一點。

開發到底是用 Go、Python 還是 Java？其實這不只是語言的問題，而是背后一套生態體系的問題。這也是在變化的，但并不是說一瞬間大家就不關心了，這做不到。我們不需要把社會的演進看成是一個今天有個新技術，明天就全變了的過程。但是從長遠來看，用 Java 寫還是用 Go 寫，其實都不是最核心的，它只是一種實現而已。

Founder Park：如果一個行業沒有新語言誕生，會有影響嗎？

曹偲：我認為不會有影響。語言已經基本上圖靈完備了，除非是計算科學的底層發生變化，比如量子計算出現。目前，描述事情的方式沒有很大的問題，有問題的是如何組織和維護這個東西，以及如何去表達業務甚至是算法的抽象，那是數學和邏輯學的問題，是人要去突破的。

描述本身不存在太大的瓶頸，只是說描述效率高低、有類型還是無類型的問題。今時今日，這些的確還很重要，比如你用 TypeScript 還是 JavaScript，用有類型的 Python 還是無類型的 Python，因為它牽涉到維護性。但長遠來說，這些東西也會被慢慢地黑盒化。

Founder Park：那會不會在 AI 足夠強之后，效率高低的問題也變得不重要了？

曹偲：我的觀點可能會有一點差異。我覺得「黑盒化」這件事代表著大家已經找到了公約的最優解，而不是說它不重要會去用一個你以前認為不好的方式。就像匯編器不斷迭代，它生成的匯編我不敢說比人精心優化的要好，但基本上已經是到 95 分位的東西了。

黑盒反而意味著大家是會歸一的，而不是發散的。我們認為，只要到了這個場景，它就是這個最佳實踐。這反倒說明了上層抽象定義是更迫切的問題。

Founder Park：技術架構這個東西，存在所謂的創新或者范式大迭代嗎？

曹偲：沒有銀彈型的技術架構，這是一個事實。包括我們提到的 DDD、CQRS 也好，它更多的是起到規范作用，讓你更好維護，但并不代表用了這些你就不需要重構了，或者再也不會寫垃圾代碼了，這是不存在的。

我們可以看兩種東西，一種是算法，描述一個固定的輸入輸出，它一定會有個最優解，到那里就停掉了。但業務系統其實一直在描述我們日常生活的變化，只要人的社會行為發生變化，業務系統本身就一定會變化，所以它的復雜性是動態的。它不是一個有最終最優解的問題，可能是一個有局部最優解的問題。而今年的局部最優解，和你業務發生巨大調整之后的局部最優解肯定不一樣，所以才需要重構。

但是，盲目地重構，沒有任何工具，比如沒有像 Toco 這樣的架構工具，很有可能你抱著滿腔熱情干了一個月之后發現，還不如不改。沒有任何目的性，也沒有一個更好的工具能讓它重構之后變得更規整，并長時間保持這種規整，腐化的速度會很快，因為你沒有遵循一些最佳范式。

回到剛才的問題，技術架構這個東西有沒有繼續往前走？宏觀上我們有局部最優解，微觀上他也在不斷迭代。DDD 這個理論，已經是目前最好的理論之一了，但它其實是在 2000 年之前提出的，只是大家的實踐和落地花了很多時間。軟件的復雜性來源于邏輯的復雜性，這部分東西不可能被一個單純的架構解決。

稍微總結一下。首先，我們的架構最佳范式，基本上已經很長時間沒有發生過本質性變化了，這代表著它最起碼進入了相當長一段時間的最優解。但是，我們在實踐的過程中會碰到現實問題和執行力度的問題。有最佳實踐，但我沒有一個好的工具，理論是 A，我做出來的就是 A'，甚至是 A'''。這是我們更容易碰到的問題，理論本身在短時間內認為它就是最優解了。很多年了，行業里面沒有比它更好的，只有一些修補，沒有本質性的理論演進。

但是問題就在于，DDD 這類理論的落地都很差。架構落地的最大的問題是，在缺乏工具支撐時，所謂越好的理論越落地不了。因為所謂的好架構都是用更多的代碼去實現邏輯的隔離。如果去問很多架構師，他知道 DDD 嗎？他知道。但你說要去實踐 DDD 嗎？他一定是抱著懷疑態度去做這件事，因為沒有工具，實踐難度會比較大。我們的工具其實就是為了去解決或緩解這種問題。

06

不擔心競爭，希望大家一起來做大市場

Founder Park：因為在 AI 輔助下做架構，需不需要 Agent 對行業有更專業的知識，比如需要一些數據去訓練它，讓它更了解這些場景？

曹偲：我覺得要看長短期。

短期內，我們不要求 AI 的架構能做到滿分，這不現實。但它做到 80 分的水平其實不太需要額外的數據，現有的知識就夠了。但長遠來說，我們當然也希望產品發展的時候，會有更多累積的行業數據或者協同發展，讓它更容易做到 90 分。

目前的基準線就是 AI 給你出一個 80 分的東西，由人來控制和修改。如果以后想更加自動化，達到真正的 L4，那肯定還是要有行業積累的支持。但我覺得這應該不在大家 2026 年的規劃里，AI Coding 自身還沒成熟呢，在基礎還沒夯實之前，暫時不需要去考慮更下一步的問題了。

Founder Park：你們的產品會有數據飛輪嗎？

曹偲：肯定會有的。

首先，我們今天做這個東西，實質上還有一些技術問題。使用建模工具時，prompt 會比較長，需要教會 AI 使用工具。會通過后訓練、私有數據或者私有小模型來做。它會讓產品的內核變得越來越易用，現在可能是 80 分，以后可能可以做到 90 分。只是我們團隊目前還沒有專注在這一塊。

其次，如果底層基礎越來越夯實，從需求到完成研發的自閉環做得越來越好，那么往行業縱深發展就是一個終極命題。比如，銀行行業的東西能不能更快速地出來？這就帶來了更高層級的抽象。

其實，大家的邏輯思路是一致的，就是抽象層級更高了。使用者就像從一個編碼人員慢慢到一個總監，再到一個 CTO 或 CIO 的角色。我更多的是關心業務發展方向，然后 AI 就可以開始幫你抽象一些事情。抽象程度越來越高，其實跟人的組織也蠻類似的。CIO 肯定不是很關心某一個需求稿的抽象。一個業務總監關心的肯定不是代碼，而是某個具體業務的抽象。再到研發，他們可能關心的是還原到代碼的抽象。這其實是一個層層遞進的過程，那么 AI 就是幫助你把抽象程度越提越高。

這就是一個數據飛輪發展的方向。

Founder Park：如果今天大廠做一個這樣的產品，你們的壁壘是什么？

曹偲：第一，世界上沒有絕對的技術壁壘，無論是我們還是大模型本身，都是一個動態滾動的過程。我們絕對不會認為這是一個絕對的技術壁壘，但是它是一個相對的技術壁壘。我認為別人要做這件事情，花個半年、一年的時間還是要的。這個時間優勢，就可以去轉化成我們的競爭壁壘。

第二，非常非常歡迎所有的大廠來做同樣的事情。我們不覺得一家公司去做這件事情是很好的一件事。只有大家一起參與進來，無論是參與我們的方案，還是做自己類似的方案，我覺得這是一件好事情。而且這個市場會足夠大。

Founder Park：更像是說，現在需要更多人一起來做這個市場，甚至可以一起把用戶教育做好。因為「架構很重要」這個認知，在當下并不是一個很大眾的認知。

曹偲：對。只要我們剛才說的那個事實存在，就是在很多研發場景里面，AI Coding 的實際生產采納率才百分之十幾，大家就一定會去尋找新的出路。如何通過抽象去減輕軟件表達的復雜度, 只能回到架構和抽象上來。

Founder Park：所以，如果 AI Coding 足夠強大，它可能讓一些更小眾的需求被釋放出來。但那些小眾需求，最后都不一定需要用軟件的方式來解決，可能就是一個復雜的提示詞。那個場景更像是因為 AI 能力足夠強，讓一些即時性的、短期的需求更好被滿足了。它不應該再用傳統軟件的邏輯去看，因為它最終產出的也不是一個需要維護、需要規劃的傳統軟件。

曹偲：很有道理。很多人會問，AI 發展了之后，Coding 是不是會減少？我認為是不會的。

人類社會的數字化發展是一個往前走的過程。只要數字化進展不停，數字化里面的確定性部分存在，我認為 coding 這個事情就會長期存在。只是里面非確定性的表達，例如訂哪張機票交給大模型和 agent，而如何扣減機票庫存就必須交由 Coding。

07

用 AI-Native 的方式重做 UML

Founder Park：九十年代后期，當時流行所謂的 UML（統一建模語言），就是用一套很強的復雜系統約束好，代碼就變成一個很自動化或者很快就能生成的東西。我直覺上感覺跟 Toco 要做的東西有點相似，它們本質的區別是什么？

曹偲：首先，太陽底下沒有新鮮事，任何技術本質上都代表了人的一種思路。UML 這些東西，并不是說它本身思路有問題，而是它那個時代的環境并不太支撐這件事情能落地得非常好。

舉個云音樂的例子，云音樂有個叫「歌單」的功能，在云音樂之前，大家可能都是用榜單聽歌，所有人聽的歌都一樣。那歌單為什么在云音樂里這么成功？難道是因為在 PC 時代，十幾年來沒有人想過做歌單嗎？不是的，是因為那個環境里沒有個性化推薦。沒有個性化推薦，歌單會淪為一個比榜單傳播效率更差的東西。

所以，想法一直都會有，但是技術環境一直在發生變化。UML 本身所代表的思路，就是對業務理解的一個更高程度的抽象，我不認為今天有人會否認軟件需要抽象。抽象這個事情肯定沒有問題。但是在前 AI 時代，首先它的抽象度很難把控。我們今天把 80% 的信息模型化抽象了，20% 不去抽象。在沒有 AI 的時代，就很難做這種抉擇。要不要全部抽象成 UML？這會把它變成一種新的編程語言，就不太像抽象了。只抽象一半可不可以？那就會面臨另一半怎么辦，是自己手寫嗎？就會面臨這種兩難的抉擇。

第二個問題，如果沒有任何工具，今天有一個需求變更，到底是先改 UML 還是代碼？時間緊，肯定是先改代碼。這就導致兩邊不一致。當然，在一些傳統、時間不緊急、要求規則很強的領域，比如在日本，有 60-70% 的時間都在整理 Excel 表格。這種設計驅動開發的事情，哪怕在非 AI 環境下也沒有完全被拋棄，它還是有很大價值的。只是說在國內，特別是在一些快節奏的互聯網開發里，不太成立。

回過頭來說，軟件的復雜性是不是需要抽象來解決？我認為這是個本源問題。如果認為需要，在 AI 時代，我們就應該找一個更好的解決方案。本質上來說，我們就是希望在社區和產品里，去找到一條在某個范疇內比較好的描述方法。

假設今天 AI 無限強了，只要人還參與軟件開發，最大的問題是什么？是 AI 嗎？不是，是人如何跟 AI 通信。人和 AI 的通信帶寬要變寬，就一定得找更抽象的東西出來。回過頭來看我們之前的 DDD、UML，我們發現這里面的東西并不是全無道理，很多是講得通的，只是在那個環境里不能很好地發揮出來。就像你在 2005 年的時候去做歌單，你只能一個一個手動分發，而不可能通過機器學習去傳播。

Founder Park：當時的技術能力和需求，沒辦法很好地支撐那樣的想法。

曹偲：對。我認為我們去做技術理解的時候，一定要分清楚哪些是本源的東西，哪些是變的東西。UML 也好，AI 也好，Toco 也好，都是在解決問題的一些思路。這就帶來了技術的循環興起和衰落。但我認為抽象是不會衰落的。

Founder Park：是不是可以說，我們在用 AI native 的方式，把 UML 的理念重新變成一個更具可行性的產品解決方案？

曹偲：是這樣的。還是那個歌單的例子，AI 對于這個東西而言，就像是一個機器學習的協同過濾算法，它可以讓一個很有價值的東西煥發新的生命力。

在 AI 時代，以 UML 為代表的抽象方法論反而會越來越重要。是不是不應該和 AI 去交流 10000 行代碼，而是三十個模型。

Founder Park：如果說再過幾年，代碼這一層會被黑盒化，那再往前走，AI 會把更復雜的東西也黑盒化嗎？

曹偲：精準描述問題是必不可少的，從這個角度說，建模不太可能會被黑盒化，因為自然語言有很多天然的問題，它不太適合去精確描述你的系統，除非你對系統的對錯不關心。如果要找一個準確性的表達，就得找一個準確性的語言。用一個不準確的語言，又能準確地表達你的需求，這是不太現實的。

除非你的要求就是，做一個會議系統，大概是我想要的就行, 如果你想做某個特定會議的系統，你就會對如何準確表達問題最感興趣。但這里面其實有很多細節問題。技術的細節，包括增刪改查這些，大家都會說非常簡單，但其實想做好是很難的。想做好一件事情永遠和做一件事情是兩回事，你哪怕做一個簡單的系統，想做好也不容易。

08

先成為一家產品公司，再成為行業標準

Founder Park：現階段先從 Java 切入，純粹是技術選擇嗎？

曹偲：因為涉及到建模引擎，所以就會有編程的部分。我們做了編程引擎，這個引擎需要翻譯成某種語言，把它翻譯成什么呢？我們可能優先去翻譯成 Java，因為 Java 的工程化理念跟我們更近。

其次，我們就是先從最頭部的開始覆蓋，那最多的肯定是 Java。

Founder Park：這樣更容易獲客，更容易找到要解決的問題？

曹偲：對，我們的思路是這樣的。往后延展一下，本質上來說，我們想先成為一個產品公司，再成為一種行業標準公司。Spring、K8s 某種程度上已經代表了一種行業標準。所以我們會去做開源，引擎內核部分，包括建模描述和建模的渲染引擎模板，都會在社區發布出來。當然可能要晚一點，因為我們代碼得整理得更 strong 一點才能發布。

我們的思路是，我們也是一種 Spec coding，只是一種更約束化、更專用、更準確的 Spec coding。最終它一定是個開放式的、全支持的，要用 Go 肯定可以用 Go，要用 C# 肯定可以用 C#，而且 AI 會讓這個泛化變得更快。

Founder Park：那你們和 Spec Coding 的區別？

曹偲：Spec Coding 跟我們有相似之處，也有不同之處。Spec 某種程度上也是讓上下文更約束、更規范、更抽象。但 Spec 有點偏過程式，很難說 Spec 是個設計。怎么保證文檔和最終的代碼是一個映射關系？Spec 怎么寫好？AI 寫還是你寫？用什么格式寫？最終還是得解釋這個問題。

當時我們在云音樂做架構師團隊，第一個問題就是，架構師應該產出什么樣的文檔？不是要不要架構，而是每個人的架構寫的方法又不太一樣。那 Spec Coding 是不是碰到同樣的問題？用什么樣的方法來寫 Spec？是不是需要有一些最佳實踐？這最佳實踐能不能被沉淀下來，成為一個固化的表達，還是就是自由發揮？

Spec 在用得很好的人手里可能會大放異彩，但在用得不好的人手里可能也就那么回事。

Founder Park：現階段，它的適用場景是改造一個很大的舊代碼庫，還是說它更適應開發一個新項目，從架構開始規劃？

曹偲：這個問題很重要，甚至會對我們的商業場景有一定限制。在典型的軟件工程里，這叫 Greenfield 和 Brownfield。一個是綠地，指被良好規劃、重新開始的項目；另一個是指一些陳年的、沒有被良好維護的代碼。

首先，在 Brownfield 上想做很好的迭代更新，其實邏輯上不成立，不是說 AI 變強了就一定能做好。大型系統，連人都很難維護。人很多時候解決這個問題都是在旁邊再開一條支路，不影響原來的東西，重新寫一個邏輯。我們聽過最離譜的線上事故，是把兩行不相關的代碼順序換了一下，然后線上直接出了 P1 事故。這件事不是 AI 的問題，也不是人的問題，是由它邏輯結構的混亂性造成的，這是個本源問題。

很多 CTO 反饋的 AI Coding 只有百分之十幾的代碼采用率，其實可以印證這件事。特別是在大型系統里面，長時間對架構的腐化、管理信息的丟失造成了這些問題。

所以我們認為，Toco 比較適合做 Greenfield 的項目，一開始會有一些限制。

但是，持續使用的軟件，本身就需要新建，或者需要一定的重構。因為業務系統在變化，它的最優解也在不斷變化。如果你是毫無目的地重構，很有可能就是擼起袖子來又掉到同樣的坑里去。如果你的 Brownfield，可以逐步地剝離一些常常需要變更、維護且比較重要的模塊出來，重構到新的、設計良好、被良好維護的體系上去，我們可以把它假設為「最后一次重構」——當然這個「最后」要打引號，絕對不是說以后不用重構了，而是說它的重構模式可以遷移到這種設計驅動的模式上來，那它的可理解性、可維護性就會高一個很大的檔次。

從長遠來說，如果 Toco 在新建和重構中有了行業共識，反而對我們的商業化空間有更大的想象力，這就比修修補補的工具有更大的市場空間。

Founder Park：也就是說，有了 Toco，反倒讓一些以前可能沒辦法，只能修修補補的系統，可以真正實現大家想要的重構。

曹偲：對。這就看技術決策者，是想一直陷在泥濘之中，還是要做自身研發的數字化轉型和 AI 化轉型。否則，10% 的采用率，不會因為基礎模型的變化變成 30%、40%，它可能就永遠在那個水平了。無論有沒有 Toco，這都不是一個可以直接解決的問題。Toco 來了，會給你一個新范式，讓你的東西變成一個組織良好、更容易被抽象、理解和維護的東西。從短時間來看我們受到了限制，但從長時間來看，這是一個新的潮流。

回過頭來看，為什么 2015 年到 2020 年，大家要去做微服務拆分？且不談微服務是不是一定必要，大家花了那么多錢和精力去做，最起碼是認為架構上應該往這個方向演進。這個東西長期來看，對我們的價值是放大的，而不是變小的。大家會發現，還有很多存量的東西也需要用 Toco 來做，而不是一個 Cursor 就能解決所有問題。

Founder Park：這反倒是你們的一個優勢。Cursor 可能只是用來寫新代碼，但你們能把過去解決不了的重構問題給解決了。

曹偲：對，Toco 會幫你把規整這件事情做得更好。隨著我們商業化的進展，后面可能會去推一些重構模式。我認為它長遠帶來的想象空間其實反而是更大的。前期我們可能更多地去找一些志同道合的人，在一些新建場景或者新建模塊上使用。但如果是在老模塊上去改個 if-else，用誰都一樣，哈哈。

當我們逐漸成為一種行業標準或行業共識之后，大家就會發現，AI 時代需要 Toco 來管理我的系統，而不是可有可無的。如果大家都停留在老代碼上面，那 Cursor 跟我們之間不會有太大區別，采用率就一定還維持在 10% 多。

Founder Park：你們能支持的系統架構，比如在復雜程度上，有量化的分級嗎？比如能處理多少萬行代碼，或者多復雜的系統？

曹偲：如果用它來完全重構云音樂，是絕對沒有任何問題的。

云音樂的復雜程度，我不敢說是 top 0.01%，但是 top 0.1% 絕對有。我們當年開發人員近千人，而且做了十幾年，你可以想象它的復雜程度。

它沒有一個絕對的復雜度瓶頸。做個很小的會議室管理系統，一張表也可以用；做云音樂，幾千張表也可以用，這個絕對不是它的瓶頸。只是說，它做復雜系統的時候，還要進一步的改良和優化，這個是肯定要做的。我們會在不斷的實踐中，去適應各類場景。我們已經有比較復雜的合作廠商，只是目前還不方便透露，大概是對應到上市公司級別的這種軟件研發項目。

09

Cowork 很牛，但可能并不復雜

Founder Park：怎么看待 Anthropic 說他們用 Claude Code 十天寫出了 Cowork？

曹偲：首先，Cursor 和 Claude Code 一定是很牛的東西。我們并沒有否認說用它們做不出優秀架構或好產品。我們只是說，在大眾的協作活動中，你一定要考慮到使用人的協作水平、規模、環境。這樣就會需要一個更合理的工具。AI 是一個放大器，如果使用者本身就很牛，他做出來一個很強的東西，從來沒有人否認過這個觀點。

其次，Cowork 本身可能也不是一個特別復雜的東西，可能不會比 Toco 復雜。它牛歸牛，但復雜和牛是兩件事情。

Founder Park：對，應該沒有特別復雜，我感覺是基于 Claude Code，加了很多交互層面的東西。

曹偲：現在整個社區的聲音有點分裂。比如前段時間 Redis 的作者說以后不需要寫代碼，然后網友的評論是：「我們用的是同一款 AI 嗎？」哈哈。我不敢說誰說的是假話，很有可能大家說的都是真話。

只是，需不需要一個更適合拉齊大家水平的工具？有沒有一些東西可以繼續往前走，而不是永遠停留在這種分歧上面？如果工具層面沒有任何變化，這種分歧會不會永遠存在？這不就是工程要解決的問題嗎？把大家的水平拉齊。工程就是在原型完成之后，完成工業化生產的過程。

Founder Park：在 AI 時代做產品，和你們以前做產品，體感上有什么區別嗎？

曹偲：首先，AI 時代做產品會更快，這個沒有必要掩蓋。當年可能要引入視覺、交互等很多角色，現在如果只是做一些原型創意，很多職位都被取代了。

其次，我覺得萬變不離其宗。現在是 AI 應用的第一年、第二年，其實跟互聯網的第一年一樣，很多東西都在不斷碰撞和證偽。現在的成功，無論是什么意義的成功，我都很難把它標記為是一個真正的成功。

在能夠成為一個真正的 business，有穩定的用戶留存之前，很難把它定義為一個真正成功的產品。可以把它定義為一個很成功的創業，但很難定義為一個很成功的產品。

ToB 看影響力，ToC 看留存，這個總是不會錯的。如果不能滿足這些，只是講了一個故事，我認為它是個短暫的東西，或者只是個成功的生意，而不是成功的產品。

為什么會這么難？原來在移動互聯網時代，大家是在平地上建樓，操作系統廠商和應用廠商的分工很明確。今天我們是在沙地上建樓，會面臨基礎模型如何變化、應用的邊界在哪里等問題。在流沙上建東西，你既可能陷下去，也可能被扶起來，也可能因為一陣風被吹得很高，但實質上它可能只是一陣風而已。

Founder Park：模型能力會成為你們產品的一個卡點嗎？

曹偲：不敢說卡點，但肯定是一個制約點。今天所有的 agent，在真正解決復雜問題的時候還是有不足之處的，這是肯定的。但并不代表影響它的使用。如果模型變得更好一點，上下文的注意力更集中一點，肯定會帶來更好的用戶體驗。

Toco AI 處于內測中，歡迎各位有興趣的同學查看、交流

https://tocoai.cn/

轉載原創文章請添加微信：founderparker