編譯 | 伊風(fēng)

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

編者按：資深開(kāi)發(fā)者詹姆斯·拉米雷茲長(zhǎng)文分享，講述了他使用ChatGPT學(xué)習(xí)Go語(yǔ)言，導(dǎo)航Kolide API并構(gòu)建復(fù)雜的Steampipe插件的經(jīng)驗(yàn)。在這個(gè)過(guò)程中，他深化了對(duì)AI輔助編程的認(rèn)識(shí)。

開(kāi)發(fā)者（包括我自己在內(nèi)）更喜歡邊做邊學(xué)。這是我與LLM合作的指導(dǎo)原則之一，也可以說(shuō)是最重要的一項(xiàng)：因?yàn)槟阍诿嫦蛉蝿?wù)的教學(xué)時(shí)刻中獲取知識(shí)，學(xué)習(xí)不是前瞻性的——它是即時(shí)的和可觸摸的。

當(dāng)一位經(jīng)驗(yàn)豐富的開(kāi)發(fā)者與LLM合作時(shí)，它的機(jī)器智能支持和增強(qiáng)了你的人類智能。

對(duì)我來(lái)說(shuō)，好處是顯而易見(jiàn)的。在LLM時(shí)代為Steampipe編寫ODBC插件感覺(jué)比我之前沒(méi)有這種幫助時(shí)要容易得多。但這顯然是一個(gè)主觀評(píng)價(jià)，因此我在尋找一個(gè)機(jī)會(huì)與另一位插件開(kāi)發(fā)者比較筆記時(shí)，詹姆斯·拉米雷茲在我們社區(qū)的Slack中宣布為Kolide API構(gòu)建了一個(gè)新插件。

我邀請(qǐng)他告訴我他構(gòu)建插件的經(jīng)驗(yàn)，他很慷慨地和我一起進(jìn)行了一次長(zhǎng)時(shí)間的與ChatGPT的對(duì)話，他在對(duì)話中熟悉了三個(gè)新的技術(shù)知識(shí)領(lǐng)域：Kolide API、Go語(yǔ)言和Steampipe插件架構(gòu)。

作為一個(gè)額外的挑戰(zhàn)：雖然插件開(kāi)發(fā)者通常會(huì)為他們的插件目標(biāo)API找到合適的Go SDK，但這里并非如此。因此，需要為Kolide API創(chuàng)建一個(gè)Go包裝器，然后將其集成到插件中。

1、測(cè)試ChatGPT的Go能力

詹姆斯開(kāi)始進(jìn)行一些熱身練習(xí)。首先，為了測(cè)試ChatGPT的Go能力，他提供了一對(duì)他編寫的調(diào)用相關(guān)API /devices/ 和 /devices/ID 的Go函數(shù)，并要求對(duì)其進(jìn)行重構(gòu)，以隔離在兩者之間共享邏輯。

接下來(lái)，他探索了使用簡(jiǎn)單的可變參數(shù)與更復(fù)雜的函數(shù)選項(xiàng)模式來(lái)處理函數(shù)的可選參數(shù)，并確定簡(jiǎn)單的方法——使用一個(gè)Search結(jié)構(gòu)的切片來(lái)封裝Kolide的查詢參數(shù)的字段/運(yùn)算符/值樣式——就足夠了。他要求一個(gè)函數(shù)來(lái)將該Search結(jié)構(gòu)的切片序列化為一個(gè)REST URL，然后完善了ChatGPT提出的版本，創(chuàng)建了一個(gè)最終的serializeSearches，增加了對(duì)將友好名稱映射到參數(shù)并使用字符串構(gòu)建器的支持。

其中一些改進(jìn)，，包括使用字符串構(gòu)建器，都是由一個(gè)名為CodeRabbit的AI驅(qū)動(dòng)的機(jī)器人提出的，它提供了有用的代碼審查。他說(shuō)，這種反饋有助于你和你的團(tuán)隊(duì)專注于大局，因?yàn)樗幚砹思?xì)節(jié)，并經(jīng)常（雖然不總是）提供可提交的建議。

它還采取了更廣泛的視角來(lái)總結(jié)拉取請(qǐng)求，并評(píng)估關(guān)閉的PR是否解決了其鏈接問(wèn)題中陳述的目標(biāo)。

2、映射運(yùn)算符

詹姆斯繼續(xù)探討如何將Steampipe運(yùn)算符（如QualOperatorEqual）映射到Kolide運(yùn)算符（如Equals）。在這里，ChatGPT建議的方法也被證明是一種應(yīng)該丟棄的方法，完全可以采用一個(gè)更干凈簡(jiǎn)單的方法。

但正如詹姆斯在我們的采訪中確認(rèn)的那樣，由于你最終會(huì)對(duì)可拋棄的版本進(jìn)行迭代，因此能夠生成合理的迭代而不是手工編寫它們會(huì)很有幫助。在這個(gè)過(guò)程中，他正在學(xué)習(xí)基本的Go習(xí)慣用法。

詹姆斯：

Go中有do-while循環(huán)嗎？

ChatGPT：

沒(méi)有，但是……

詹姆斯：

Go中有三元運(yùn)算符嗎？

ChatGPT：

沒(méi)有，但是……

詹姆斯：

如何將內(nèi)容附加到map[string]string？

ChatGPT：

像這樣……

3、通過(guò)反射增強(qiáng)的訪問(wèn)者模式

在消化了基礎(chǔ)知識(shí)并為Kolide API開(kāi)發(fā)了一個(gè)Go客戶端之后，詹姆斯準(zhǔn)備著手處理插件開(kāi)發(fā)的真正工作：定義表，將從API包裝器返回的Go類型映射到管理對(duì)這些表的SQL查詢的Steampipe模式。

像所有的插件開(kāi)發(fā)者一樣，他從一個(gè)可以列出一組資源的表開(kāi)始，然后通過(guò)添加過(guò)濾器和分頁(yè)來(lái)增強(qiáng)它。在添加了第二個(gè)表之后，是時(shí)候考慮如何抽象出常見(jiàn)的模式和行為了。最終的結(jié)果是對(duì)訪問(wèn)者模式的一種優(yōu)雅實(shí)現(xiàn)。這里是對(duì)應(yīng)于表kolide_device和kolide_issue的Steampipe List函數(shù)。

圖片

這是所有插件表都使用的通用listAnything函數(shù)。

圖片

通過(guò)這種設(shè)置，向插件添加一個(gè)新表幾乎完全是聲明性的：你只需要定義模式，以及形成在SQL查詢中的where（或join）子句和API級(jí)別過(guò)濾器之間的橋梁的KeyColumns和相關(guān)運(yùn)算符。

然后，你編寫一個(gè)小的List函數(shù)，定義一個(gè)訪問(wèn)者，并將其傳遞給通用的listAnything函數(shù)，該函數(shù)封裝了查詢參數(shù)的編組、連接到API客戶端、調(diào)用API、將響應(yīng)解包成一個(gè)集合，并對(duì)集合進(jìn)行迭代以將項(xiàng)目流式傳輸?shù)絊teampipe的外部數(shù)據(jù)包裝器。

詹姆斯使用ChatGPT啟動(dòng)了Go中訪問(wèn)者模式的習(xí)慣實(shí)現(xiàn)。這意味著學(xué)習(xí)如何為訪問(wèn)者函數(shù)定義一個(gè)類型，然后聲明一個(gè)函數(shù)來(lái)滿足該類型。

每個(gè)表的訪問(wèn)者封裝了對(duì)API客戶端的調(diào)用，并返回一個(gè)接口。這都相當(dāng)通用，但是訪問(wèn)者的響應(yīng)是特定于包裝的API響應(yīng)的Go類型，這意味著必須為每個(gè)表編寫一個(gè)不同的List函數(shù)。如何避免這種情況？詹姆斯問(wèn)道：“res變量上的字段引用需要是在執(zhí)行時(shí)指定的可變類型。你能提出一個(gè)方法嗎？”

ChatGPT的建議是使用反射，以便像listAnything(ctx, d, h, “kolide_device.listDevices”, visitor, “Devices”)這樣的調(diào)用可以傳遞一個(gè)名稱（“Devices”），該名稱使listAnything能夠以一種與類型無(wú)關(guān)的方式訪問(wèn)響應(yīng)結(jié)構(gòu)的字段，例如這里的Devices字段。詹姆斯接受了這個(gè)建議。

圖片

有了這個(gè)，listAnything終于名副其實(shí)地成為了一個(gè)完全通用的Steampipe List函數(shù)。這個(gè)解決方案節(jié)省了反射的使用，并保留了Go在API層和Steampipe層中的強(qiáng)類型檢查。

4、LLM協(xié)助到底意味著什么？

這絕對(duì)不意味著一個(gè)LLM在回答類似“請(qǐng)為Kolide API創(chuàng)建Steampipe插件”這樣的提示時(shí)編寫了一個(gè)體現(xiàn)復(fù)雜設(shè)計(jì)模式的插件。

對(duì)我來(lái)說(shuō)，以及對(duì)詹姆斯來(lái)說(shuō)，大模型輔助編程意味著更有趣的事情：“讓我們討論一下為Kolide API編寫插件的過(guò)程。”這就像與一個(gè)橡皮鴨交談，以便大聲思考需求和策略（編者注：“橡皮鴨”（Rubber Duck Debugging）是一個(gè)流行的術(shù)語(yǔ)，它指的是一種調(diào)試技術(shù)，其中開(kāi)發(fā)者通過(guò)向一個(gè)假想的聽(tīng)眾（在這個(gè)比喻中是一只橡皮鴨）解釋他們的代碼來(lái)解決問(wèn)題）。LLM正是一個(gè)會(huì)回答的橡皮鴨。

有時(shí)候，回答是直接適用的，有時(shí)候不是，但無(wú)論如何，它們通?？梢詭椭愀逦厮伎?。

作為一名具有廣泛經(jīng)驗(yàn)的高級(jí)軟件工程師，詹姆斯本來(lái)可以自己解決這個(gè)問(wèn)題，但這可能需要更長(zhǎng)的時(shí)間。他本來(lái)會(huì)花費(fèi)大量的時(shí)間閱讀文章和文檔，而不是通過(guò)實(shí)踐學(xué)習(xí)。而且可能沒(méi)有那么多的時(shí)間！正如我現(xiàn)在從許多其他人那里聽(tīng)到的，LLM提供的加速往往是有了一個(gè)想法和能夠執(zhí)行它之間的差異。

詹姆斯還提到了一個(gè)我沒(méi)有考慮過(guò)的開(kāi)源角度。在LLM之前，他不會(huì)完全以公開(kāi)方式進(jìn)行這項(xiàng)工作?！拔視?huì)一直保持私密，直到我感覺(jué)更自信，”他說(shuō)，“但這一次從一開(kāi)始就是公開(kāi)的，我很高興它能夠公開(kāi)?！边@使得與Turbot團(tuán)隊(duì)更早地而不是更晚地進(jìn)行接觸成為可能。

這不是一個(gè)自動(dòng)化的故事，而是一個(gè)增強(qiáng)的故事。當(dāng)像詹姆斯·拉米雷茲這樣經(jīng)驗(yàn)豐富的開(kāi)發(fā)者與LLM合作時(shí)，它的機(jī)器智能支持和增強(qiáng)了他的人類智能。兩者共同努力——不僅僅是為了編寫代碼，更重要的是為了思考架構(gòu)和設(shè)計(jì)。

來(lái)源： 51CTO技術(shù)棧