“失控”

王俊煜

前兩天整理了一下今年春節之后的工作日志，發現大部分時間自己都在做同一件事情：測試評估兩個AI產品在上線測試過程中發現的問題。

這兩個產品所處的階段幾乎一樣，已經上線測試了，有小規模的真實用戶在使用。通過觀測這些用戶如何使用，我們發現了一些比較明顯的問題。在推向更多用戶之前，必須解決這些問題。

舉一個例子，其中一個產品主要面向海外用戶，我們只優化了英語的體驗，非英語用戶很容易遇到一個問題，即我們的AI會錯誤地將用戶輸入的文字翻譯成英語后保存。即使我自己的中英文讀寫都流暢，多了一次語言切換，還是給腦子增加了很大的額外負擔。本來我們這個產品追求的一個體驗就是讓用戶在思考中形成心流，這個問題出現時，會完全破壞這個體驗。

這個問題在產品上線前我們就知道，只是覺得不會經常遇到，解決起來應該也不難，就沒有花精力去解決。上線后我們發現，即使只是測試階段，非英語用戶也占了大多數，有接近一半的用戶在實際使用中遇到了這個問題。那就變成了一定要解決的問題。

還有幾個這種程度的類似問題也是在上線測試后才引起我們注意的，這本身也是上線測試的價值。

許多互聯網產品都會掛上“ 測試版”（Beta）的標志，上線請用戶幫忙測試。但其實除了上線測試，更直接、也是更傳統的對產品質量的保障，是團隊內部研發過程中的測試。一個產品的研發流程，大致分為規劃、設計、開發、測試、上線幾個階段，其中測試可能是被關注得最少的，至少過去我關注得不多。不過這可能也是我做事的一個特點，做初創企業更關心在什么事情上可以取得突破，就不太容易關注保障性的工作。

離開豌豆莢后，我的團隊規模一直很小，我也一直沒有再招聘全職的測試工程師，而是將其分散到各個職能。除了一部分自動化測試，產品功能主要依靠手工測試。出了幾次事故后，雖然還是沒有專業團隊，我還是花了一些精力引入了專業一些的流程。撰寫了測試手冊，里面收錄了幾百個功能測試點。每次測試時整個團隊分頭認領，花兩三個小時就可以在不同的系統、機型上勾完這些測試點，非專業團隊也可以用專業流程來辦事，準確又高 效。

自從引入專業流程，產品發布的時候我再也不會提心吊膽了。我自己在這個事情上還是花了不少時間的，所以可能也不能說我對保障性的工作關注得不多。只是我熱衷的是研究行業的最佳實踐，然后只要部署到位，就認為自己可以高枕無憂了。英語里有句話叫“trust theprocess”，在這里可以翻譯成“相信流程”，大概就是這個意思。

但AI產品的測試方法看起來不太一樣。這兩個AI產品本身的邏輯都蠻簡單的，復雜的都是大語言模型本身。要解決我上面提到的問題，一是涉及對我們使用的大語言模型更細致的調整，二是需要調整提示詞（Prompt）的設計。解決具體問題不難，但大語言模型輸出的是開放答案，本身有一些隨機性和不可預測性，有時候為了補西墻會不小心拆了東墻，修復了一個問題，卻帶來了新的問題。這個產品的測試，如果也想讓自己高枕無憂，就不是在過去的測試點清單上打勾就可以了。

此外，如果需要不斷提升產品的效果，不僅僅是保證不出現問題，也需要對AI的輸出做定量的評估。過去我們也做過搜索引擎，對算法的評估是類似的，同一個功能點需要測試許多不同的場景。但AI功能的輸出和用戶的交互歷史有關，如果使用純人工測試，意味著需要反復聊很多次天，這樣子變數非常多，不像搜索引擎一樣只需要輸入一個關鍵詞就可以評估。

所以，我又開始找某種最佳實踐。

回想了一下，自去年7月恢復工作以來，我的工作更像是程序員，而不是設計師，大部分的時間都在寫代碼。我上一次在工作中需要大量寫代碼，還是剛畢業的時候，17年前了。

之前在專欄中我也表達過，有時候難免會擔心，這算不算是職業生涯的倒退。當然，我也會認為，這可以帶給我信心，產品研發流程中的每個環節我都掌握了。我管自己叫程序員而不是軟件工程師，是覺得我的三腳貓功夫搭個草房子還可以，稱不上“工程師”。但在AI的幫助下，這半年我的編程水平還是有很大進步的，可能慢慢地可以搭一個木頭房子了。

做產品設計需不需要懂技術，是一個亙古不變的話題。在過去，我的答案是，如果你要創造新的東西，你還是需要知道面前這塊畫布的特性的。而在今天這個AI快速發展的階段，沒有人能準確說出AI的能力邊界。要了解這塊畫布，必須動手。

之前介紹過IDEO的理論：產品創新需要同時滿足人的渴求、技術可行性和商業可持續性。AI帶來的是技術可行性的巨大變化，這是我作為產品設計師感到興奮的。挑戰則是，如果說設計師的工作是創造性地解決用戶的問題，由于技術的不確定性，設計方案也必須在研發過程中不斷調整。這時候，設計師多花點時間寫代碼、探索AI的能力邊界是應該的，這樣才能創新。

和半年前相比，不管是GP Ts，還是類似Coze、Dify這樣的工具，成熟度都有了很大提升。用它們都可以快速搭建出一個產品的雛形。但這些工具目前也只是照顧到大多數情況下需要用到的東西，做出一個60分的演示沒有太大問題，如果要設計更創新的體驗，或者需要提升到80分、90分，眼下還是需要自己寫代碼的。代碼，在這里就是一個設計工具。

但我的另外一個建議是不宜鉆研過深。如果技術思維過強，做事情容易過于從技術可行性出發，忘記用戶的問題是什么。

開始寫代碼之后的另外一個好處，是對產品品質可以有更直接的影響。創新和品質，大概就是我做產品最關心的兩個方面。

作為處女座，我做這些事情還是很愉悅的。2007年剛畢業的時候我以設計師和工程師的雙重身份入職Google，也接受了工程師的入職培訓。印象最深的是，導師說，你作為工程師不能花太多時間寫代碼，最多1/ 3，否則質量就會有問題了。剩下1/3要用來讀別人的代碼，也就是代碼審查，再花1/ 3的時間做程序的設 計。

我的很多工作習慣都是那時候養成的。我在Google的第一個項目是設計App Engine的管理后臺，這是Google第一個面向開發者的托管服務，當時還不流行“云”這個概念，它可能是Google Cloud最早的雛形。Python之父Guidovan Rossum恰好和我同一天入職，也加入了這個項目。我是剛寫下自己的第一行Python的新手，Guide是Py thon的發明者，但他也沒有特殊待遇，和我一樣需要先在入職培訓中通過Google的Python考試，才能持證上崗，有資格提交Python代碼。

Guido通過考試時在自己的周報中特意寫下了這件事，在當時傳為笑談。

過去我自己做的公司，像Google一樣的代碼審查從來沒有嚴格實施過，多數是走過場（“幫我過一下”）。據我所知，似乎也沒有哪個中國公司能做到。顯然，認真的代碼審查會讓開發節奏變慢，但是不是能有效提升質量，讓效率更高？今天我自己實際上手來做這個事情，對工程開發的方法更有體會了。

這也是和結果有關的。我們一直做的產品的定位還是對質量有比較高的要求的，但過去很多年的一個困擾，是質量無法達到理想狀態。當然，坦白說，我覺得這個工作還是應該由技術合伙人或者CTO來承擔，只是我們現在還太早期了，不一定需要這個角色。

說回如何測試AI產品，其實已經有很多人發明了很多輪子。刻薄點說，可能大家都還不太知道AI能做什么，所以才把精力花在造輪子上了。

細節略去不表，總之我額外花了幾周時間找到一個看起來不錯的輪子，把它安裝到了我們的產品中。這件事情最終花費的時間大大超出了我的預期。我永遠都覺得“下周可以弄完”。而且，由于這個過程中還是有挺多重復的工作的，盡管當中的許多可以由AI協助完成，還是花費了我很多時間。在這個過程中我還是時常懷疑，這是不是對自己時間的有效使 用。

如果再做一次，我相信是可以節省很多時間。有了經驗，可能就知道哪些事情可以跳過，這樣可以節約很多時間。但是不是一開始就可以不選擇這個方式？如果還是手工測試后就閉著眼睛上線，效果會有多大區別？

我此刻可能還沒有答案。尤其是我試用過的很多A I產品，包括大公司做的，其實都無法正常工作。這個月發貨的“首款人工智能硬件”AI Pin被The Verge稱為“可能是現代技術史上評價最差的產品發布”，我看了幾個測評，不需要嚴謹的測試，簡單試用你就知道它無法完成用戶期望它完成的工作。這些當然不是好的例子，我們不希望做這樣的產品。

但我們的兩個AI產品遲遲未能成功上線，每次有這種“失控”的感覺，我就容易變得煩躁起來。

現在，我的確會更直觀地理解，為什么研發項目的時間很難估算準確。很多年前我讀過一篇文章，文中拿從舊金山沿海岸線徒步到洛杉磯舉例，稱從地圖上看無非是四百多英里的距離，簡單的除法告訴我們，理論上7天可以走完。實際上呢？我沒有搜索到很準確的答案，有人說他的一個退役軍人朋友嘗試過，大概花了6個月。這當中的細節、不確定性，都是在地圖上無法看到的。

所以可能軟件工程的美妙就是要在未知中探索。商業也是一樣—如果我們不是要解決一個已知問題的話。