王俊煜

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開始寫代碼之后的另外一個好處，是對產(chǎn)品品質(zhì)可以有更直接的影響。創(chuàng)新和品質(zhì)，大概就是我做產(chǎn)品最關(guān)心的兩個方面。

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

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

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

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

這也是和結(jié)果有關(guān)的。我們一直做的產(chǎn)品的定位還是對質(zhì)量有比較高的要求的，但過去很多年的一個困擾，是質(zhì)量無法達(dá)到理想狀態(tài)。當(dāng)然，坦白說，我覺得這個工作還是應(yīng)該由技術(shù)合伙人或者CTO來承擔(dān)，只是我們現(xiàn)在還太早期了，不一定需要這個角色。

說回如何測試AI產(chǎn)品，其實已經(jīng)有很多人發(fā)明了很多輪子?？瘫↑c說，可能大家都還不太知道AI能做什么，所以才把精力花在造輪子上了。

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

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

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

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

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

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