在過去的一年里，越來越多的生成式 AI 應(yīng)用來到了我們的日常，Copilot 似的 AI 大大改善了我們的工作和生活體驗(yàn)。而作為工程師，僅僅使用 AI 工具是不合時宜的，在恰當(dāng)?shù)臅r候，加入 AI 原生應(yīng)用的開發(fā)大軍，才是更適合被譽(yù)為 “夕陽產(chǎn)業(yè)” 從業(yè)人員的一種選擇。

而從我們構(gòu)建 ClickPrompt、AutoDev及其它 AI 應(yīng)用的過程來看，要設(shè)計好這一類 AIGC 的體驗(yàn)不是一件容易的事情。我們試圖從過去的一些經(jīng)驗(yàn)里做總結(jié)，并在此文中融入了我們的思考。從現(xiàn)有主流的 AI Copilot 型應(yīng)用、生成式 AI 的特點(diǎn)，兩個比較好的例子就是寫作與編程。前者有非常成熟的 Notion AI 作為示例，后者有不斷涌現(xiàn)的 GitHub Copilot、Cursor、JetBrains AI Assistant 等工具。

寫作是一個復(fù)雜還是繁雜問題？

也因此，對于這個問題來說，人們的答案是不一樣的。對于不經(jīng)常寫作的人來說，這必然是一個復(fù)雜問題；他們可能不知道從何處開始，如何組織思路，如何表達(dá)自己的觀點(diǎn)。他們可能感到困惑和無助。而對于經(jīng)常寫作的來說，多數(shù)情況下都是一個繁雜問題。

人們看待問題的方式不一樣，思考過程不一樣，也就導(dǎo)致了會產(chǎn)生不同的結(jié)果。同樣是 AI 輔助寫作工具的設(shè)計，可能會出多種不同的結(jié)果，從簡單的 zero-shot 的一鍵式生成，到根據(jù)不同寫作模板寫成，再到 Notion 結(jié)合不同的意圖生成。

所以，你問一個經(jīng)常寫文章的人，他可能就會這樣說寫作的步驟是這樣的：

1. 確定主題：首先，他們會選擇一個明確的主題或者話題來進(jìn)行寫作。這個主題可能是他們感興趣的領(lǐng)域，或者是與他們當(dāng)前工作、學(xué)習(xí)相關(guān)的話題。

2. 進(jìn)行調(diào)研：在開始寫作之前，經(jīng)常寫文章的人會進(jìn)行一些調(diào)研工作，以獲取更多關(guān)于所選主題的信息和背景知識。這可以通過閱讀相關(guān)文獻(xiàn)、文章、報告或者采訪專家等方式進(jìn)行。

3. 制定大綱：在收集足夠信息后，他們會制定一個大綱來組織自己的思路和結(jié)構(gòu)。這個大綱通常包括引言、正文和結(jié)論等部分，并且可能包含一些子標(biāo)題或者章節(jié)標(biāo)題。

4. 寫作草稿：接下來，經(jīng)常寫文章的人會根據(jù)大綱開始撰寫草稿。在這個階段，他們不必?fù)?dān)心語法錯誤或者完美表達(dá)，在思路流暢地展開為主。

• ……

但是，故事并非只到這里，你在寫作的時候，還涉及到文章的前言、總結(jié)等的內(nèi)容。如下是一個使用 AutoDev + ChatGPT 3.5 生成的前言：

隨著用戶體驗(yàn)的重要性不斷提升，開發(fā)團(tuán)隊(duì)將更加關(guān)注用戶需求和期望，通過用戶故事來指導(dǎo)開發(fā)過程。這種方法將幫助開發(fā)團(tuán)隊(duì)更好地理解用戶需求，提高產(chǎn)品質(zhì)量，并增強(qiáng)用戶滿意度。同時，隨著人工智能和機(jī)器學(xué)習(xí)的發(fā)展，軟件開發(fā)也將越來越注重個性化和智能化的用戶故事，以滿足不斷變化的用戶需求。

寫作從一個復(fù)雜問題變成繁雜問題是因?yàn)椋耗Ｊ交?。?jīng)驗(yàn)豐富的人腦子里有大量的模式，這些模式是隨著大量的練習(xí)自然而然形成的。要將這些模式從大腦中提煉出來，并非是一件容易的事，也因此師傅厲害，學(xué)生不一定能學(xué)到東西。

GitHub Copilot 輔助的是編程的什么？

我們在內(nèi)部進(jìn)行了一系列的 GitHub Copilot 培訓(xùn)，主要目的不是訓(xùn)練 IDE 插件如何使用，而是如何將 GitHub Copilot 與我們的工作流結(jié)合。諸如于，在經(jīng)典的 Thoughtworks 畢業(yè)生培訓(xùn)里，在培訓(xùn)某個語言語法之前，還有大量的練習(xí)是關(guān)于如何思考的，諸如于 Tasking。

Tasking 簡單來說，就是任務(wù)拆分。你所要面對的問題，類似于把大象放進(jìn)冰箱要幾步？在你關(guān)下冰箱之前，你需要一個哆啦A夢的縮小槍，才能把大象真正放進(jìn)去。但是，很遺憾的是 GitHub Copilot 并非是你的縮小槍 —— 你不能打開 IDE，把你的任務(wù)變成注釋和函數(shù)簽名，然后用 Copilot 直接完成你的代碼。

在編寫 CRUD 時，我們的過程是這樣的：

• 代碼修改點(diǎn)一。分析你的需求、任務(wù)，根據(jù)任務(wù)定位出修改點(diǎn)；然后，才是編寫你的第一部分代碼。

• 代碼修改點(diǎn)二。而由于，我們的代碼是模塊化的、類文件化的，所以你還需要定位下一個修改點(diǎn)，然后繼續(xù)你的第二部分代碼。

• 往復(fù)循環(huán)，直至你編寫代碼

• 測試并修復(fù)你的 bug。

這也是我們設(shè)計 AutoDev 的 AutoCRUD 的最初想法，結(jié)合 ChatGPT 分析改動點(diǎn)，找到改動點(diǎn)后由 AI 完成改動。

而如果我們結(jié)合上面的過程會，發(fā)現(xiàn) GitHub Copilot 更多的只是在幫我們：解決人類健忘的語法、不流暢的結(jié)構(gòu)化翻譯問題。也因此，它就更像一個和你結(jié)對的編程員。

IDE 如何結(jié)合好 AI 輔助編程？

既然，我們將 GitHub Copilot 視為一個高級一點(diǎn)的代碼補(bǔ)全工具，那么對比于 Notion AI 這一類的寫作工具，就會發(fā)現(xiàn)存在大量的機(jī)會能改善編程上的體驗(yàn)。

盡管，我們是在 JetBrains AI Assistant 項(xiàng)目之前，構(gòu)建了 AutoDev 應(yīng)用，但是由于 JetBrains 在這方面擁有更多的思考、豐富的 API 經(jīng)驗(yàn)，所以我們可以從他們的 AI 助手看到對于體驗(yàn)設(shè)計：

• 圍繞日常活動設(shè)計。開發(fā)者日常需要寫文檔、代碼檢視、編寫提交信息等等，都結(jié)合 AI 來實(shí)現(xiàn)對應(yīng)的功能。

• 針對不同場景設(shè)計。諸如于早先的 CI/CD、代碼解釋、語義化搜索等等。

當(dāng)然了，與 JetBrains 這一類通用型的工具相比，AutoDev 也在思考更符合于企業(yè)應(yīng)用開發(fā)的場景：

• 編碼規(guī)范化。即讓 AIGC 生成的代碼更符合企業(yè)需要。

• 團(tuán)隊(duì)協(xié)作 AI。即讓團(tuán)隊(duì)可以自定義自己的 AI，以輔助團(tuán)隊(duì)更好的進(jìn)行開發(fā)活動。

而如果我們再進(jìn)一步分析這些需求會發(fā)現(xiàn)，其實(shí)這些需求的本身是圍繞于個人、組織在日常活動中所出現(xiàn)的模式。再模式固化到工具中，以提升個人的體驗(yàn)與效率。

增強(qiáng)人類而應(yīng)用模式，還是取代模式？

最后，回到我們的問題上，問題的答案就變得非常有趣。人們對于 AIGC/GenAI 到底是否是 AGI 并沒有達(dá)到一致意見。

如果我們的工具定位的是取代現(xiàn)有的流程，那么必然我們應(yīng)該站在新的模式來考慮這個問題。諸如于，開發(fā)人員不應(yīng)該對 AI 生成的代碼進(jìn)行代碼檢視，而是應(yīng)該由另外一個 AI 去 review AI 生成的代碼。只是，我們并不敢篤定 AI 生成的代碼是準(zhǔn)確的，所以還需要人工介入。而 AI 也不代替我們?nèi)プ?，所以我們走的模式還是增強(qiáng)模式。

那么，既然我們的應(yīng)用意圖是：增強(qiáng)人類，那么理想的方式還是圍繞人類的習(xí)慣來構(gòu)建。我們需要去尋找這個行業(yè)的專家，將它們的日?；顒优c AIGC 緊密結(jié)合，并將專家的思維模式提煉出來，融入工具中。再輔助配合一些自定義的能力，以此來構(gòu)建 AIGC 時代的 AI 原生應(yīng)用。

總結(jié)

總而言之，在 AI 領(lǐng)域，我們需要在設(shè)計 AIGC 應(yīng)用時，更加關(guān)注個人習(xí)慣和思維模式，并結(jié)合專家知識和行業(yè)經(jīng)驗(yàn)來構(gòu)建更適合用戶需求的 AI 原生應(yīng)用。

PS：事實(shí)上，在寫完一篇文章的時候，我們應(yīng)該花點(diǎn)時間去校對與潤色，但是我一直忽略了這一步，這大概就是我的問題了。