要走的路還更遠

AI便簽工具的正式版終于開發完了。最后一步，將版本號修改為1.0.0，提交，發布。

斷斷續續地，這個“小”產品居然開發了一年多，遠遠超過了我最初的預期。除了一部分工作由閱覽室的兩位創始讀者兼職完成，大部分的設計、研發工作都是我自己動手完成的。這是我第一次從0到1地獨立完成一個產品的開發和上線，我也算是“獨立開發者”了—我并不以此為豪，因為如果純粹從商業角度考慮，這并不是一個具有性價比的理智決定。我沒有想過要將生命中整整一年的時間花在這樣的一個“小”產品上，而且還是以工程師的角色。這肯定不是我擅長的事情。

雖然如此，我還是很高興自己堅持把它做完了。完成一個事情，對我來說很重要。

那么，如果再做一次，會有什么區別？

回想2023年7月重啟閱覽室的工作，當時我的想法很簡單：每周做一個不同的產品原型，這樣子一個月可以做出4個，借此“熱身”，進入工作狀態。一開始決定自己來寫代碼而不是招人來做，是考慮到原型對代碼質量的要求不高，我作為一個三腳貓功夫的程序員在AI的輔助下完全可以勝任，另一方面是認為對于這個階段的AI產品來說，要做出創新和突破，設計和工程無法分開，需要一邊開發一邊摸索可能性。自己來做，雖然工程上沒有那么熟練，效率可能反而會更高一些，迭代速度更快（見2023年9月刊《一個不同的主意》）。

從原型制作階段的實踐來看，這些想法大體是對的。以可以上線邀請朋友來內測為標準，制作一個原型實際上大約要花一個月的時間，而不是一周，這當中的差異主要還是我高估了自己學習新技術和編寫代碼的能力，但應該還是比找人來做要快的。

AI便簽是其中的2號原型。原型制作完成后，我們覺得這個產品應該能在市場上占有一席之地，決定再花一些時間把它開發成可以正式發布的產品（2023年10月刊《解鎖創造力的驚喜》）。那是2023年9月，這個“一些時間”，當時我們的估計是一個月。

首先，一個再簡單的產品，只要它是一個完整的產品，就沒法太簡單。

拿這個AI便簽產品來說，最初的原型我只寫了千余行代碼，到現在，則已經超過萬行了。代碼量增加了10倍，核心功能其實沒有增加。那增加了什么東西呢？作為原型和作為一個供人使用、還打算賣錢的正式產品，要求多少還是有些區別的。舉個例子，這個產品有一個核心功能是將筆記保存到用戶的Notion賬號中，一開始為了節約開發成本，我們請用戶手動綁定Notion賬號，用戶需要在電腦上手動操作十余步，將兩串代碼復制粘貼到我們的輸入框中。能完成這個流程的用戶不足10%。現在，用戶只需要點擊兩次確認，就可以完成這個過程。代價，是2000多行代碼。

這是一個付費產品，我們需要開發對應的支付系統和權限管理；原型代碼的穩定性不足，用戶經常無法及時得到結果，也需要改進；還有語音輸入、幫助和新手引導、營銷用的官網、注冊表單……等等。做原型的時候不需要考慮這些，正式上線的時候都需要。

所以說，只要是個完整產品，就不要太輕視它的復雜度，這些“沒有不行”的功能，大概就要占90%的工作量。需求文檔中每個小小的點，都是工作量。

兩三周前的一天，我在制作產品的注冊表單。為了節約時間，我用的是現成的表單工具，即使是這樣，從早上開始做，等做完的時候天也已經黑了。回想一整天的工作，也沒有什么浪費時間的地方。只能說，這些工作本來就要花這么多時間，只是因為大部分的工作都由自己完成，這些工作量體現得更加明顯而已。

這些雖然占了工作量的大部分，畢竟還算是確定的工作量，做一件少一件。這一年中的大部分時間，并不是花在這類問題上的。

2023年9月，決定將原型開發成正式上線的產品時，我也清楚自己的工程能力不足以完成這項軟件工程工作，于是決定找專業的人來幫忙（2023年10月刊《解鎖創造力的驚喜》）。我在社交平臺上發布招聘帖后，有3位閱覽室的創始讀者以兼職的形式加入了我們，他們都是工程師。

我本來以為，從原型到正式產品是一個水到渠成的過程，對有經驗的工程師們來說，都是迎刃而解的“已知問題”。實際上，一個AI產品的開發，即使是在原型的基礎上將它完善成符合正式上線質量標準的產品，也有一些開發其他產品時沒有的挑戰。其中，我認為最重要的是大語言模型的輸出質量不夠穩定可靠的問題。來幫忙的幾位工程師之前都沒有開發過大語言模型應用，要解決這個問題，對他們來說也需要重新學習、探索如何解決（2023年11月刊《有不確定性，才可能創新，才能自由自在》）。

由于這項工作需要不斷調整提示詞、參數、重新設計與模型的交互，和產品設計的意圖緊密相關，最后還是我自己完成的。今年從年初到夏天，我都在做這個工作，在2024年8月刊的《從60分到90分》中我做了詳細的記錄。

如果僅從結果的角度考慮，再來一次的話，我想，也許及時知難而退是效率更高的做法。只是未知的領域往往會引起我學習的興趣，這樣的一個挑戰反而對我來說充滿了吸引力。而一旦開始深入研究，能探究的東西又越多，就越來越難收場了。

解決這個問題的過程同樣是一個軟件工程工作，說到底我也還是沒能逃開，只能硬上。AI編程在過去這一年中有很明顯的進步。我剛開始開發原型的時候，主要是依靠AI局部補全代碼，今天的AI已經可以按照你提出的需求，憑空寫出來一個完整的應用了—但寫出來的代碼質量也只能說勉強能運行。我覺得今天的AI編程其實特別適合用來做一些“日拋型”的產品，比如給自己寫個一次性使用的數據處理腳本，給孩子寫個小游戲，或者，就像之前一樣用來做個產品原型，這些都可以全自動完成，效率和一年前相比可以說有10倍的提升。但我們在做的是一個有一定復雜度的、嚴肅的軟件工程項目，AI仍然很難獨立將代碼一次性寫對，這種情況下仍然需要開發者去理解其實現原理、給出更詳細和有針對性的指令。這對人的要求其實并沒有降低，因為你要作的是軟件架構、設計方面的決策，這甚至不是剛入門的工程師能完成的。

我只能說我努力去學了。我的學習習慣，往好的說是比較追求系統性，很難滿足于只得到一個不求甚解的答案，一定要搞清楚為什么；說不好的，就是太慢。

回頭來看，放棄可能是更理性的決定。某種程度上，我們這個AI便簽產品也在探索大語言模型的能力邊界。問題是，我的主要興趣實際是在產品交互上，花時間去探索這個邊界，以性價比考慮的話，是不太理智的。如果回到那個時候，如果確信大語言模型的能力無法輕而易舉地實現我想實現的效果，我應該果斷擱置這個產品，去做那些大語言模型已經被證明能做得很好的事情。等大語言模型的能力演進后，再回來。

如果僅僅追求效率，就應該盡量多做自己熟悉的事情，少做自己沒做過的事情。在過去幾年的工作中，由于我經常成為團隊瓶頸，答應的事情沒有辦法按時完成，我真的定量統計過，自己估算的時間和實際花費時間的差別。數據統計表明，在那些我最熟悉和擅長的領域，我所花的時間和預估的時間差別是最小的，甚至會比預估時間更快，例如產品策略、信息架構設計、界面設計等。而一個領域我越不熟悉，預估時間的偏差就越大。

這里面還有一個因素是，即使是一個自己不擅長的領域，我也很難放棄對質量標準的要求，這也導致我要花更多的時間去學習，每個問題世界上最好的解法是什么。雖然最后出來的效果往往都不錯，但就是過程所花的時間是不可控的。一個典型的例子，就是產品的視覺設計。前面說到的軟件工程問題、提升大語言模型的輸出可靠性問題，都屬于此類。

這個過程中最痛苦的還是工作量永遠沒有辦法預估。朋友問我什么時候能上線，我永遠都回答“下周”—我每次這么回答的時候，都是真的覺得眼前的工作量不多了。我猜這大概和在沙漠里看到海市蜃樓的感受是類似的，總是覺得終點近在咫尺，卻永遠走不到。這個狀態持續得久了，希望慢慢變成絕望，對自己的信心是很大的打擊，也容易迷失方向，不知道自己今天起床工作是為了什么，和目標結果有什么關系。我倒不擔心自己做得不夠好，只擔心做得不夠快，還沒有走到終點的時候就已經渴死了。這種情緒在過去幾年一直圍繞著我，在過去這一年中更加登峰造極。

當然，站在今天的角度，那些曾經不熟悉的事情，到今天都已經變成我掌握的技能了。就拿大語言模型的輸出可靠性來說，現在我可以說自己對于怎么做出一個質量較高的大語言模型應用，已經有明確的概念了。而且我也發現，大部分的產品團隊并沒有花時間去做這個事情，那么這就變成我的一個優勢了。

回想起第一個版本的原型，去年夏天的一個下午，我利用prompt在ChatGPT中模擬了設想中的交互場景，興奮地認為自己找到了一個新的產品方向，然后開始依葫蘆畫瓢地學寫代碼—如今真是已經走了很遠。

上線后，要走的路還更遠。