談談對話式軟件開發(fā)
利用大語言模型生成代碼是改變生活的方式之一，但與它們就軟件開發(fā)過程進行交談也同樣重要。Jon Udell繼續(xù)探索大語言模型為程序員帶來的價值。
譯自 Let’s Talk: Conversational Software Development 。
以下是啟動了一次非常成功的人工智能ChatGPT交互的提示。
PROMPT:
I’ll give you a test script and the output it is testing, and ask about strategies to improve the test, OK? Here’s the script.
#!/bin/bash
set -eu
list_tickets() {
local output
output=$($command $subcommand run list_tickets 2>&1) || {
echo "Command failed with error: $output"
exit 1
}
echo "$output"
}
output=$(list_tickets)
count=$(echo "$output" | jq -r '.tickets_list | fromjson | length')
# Check if count is greater than 0
if [[ $count -gt 0 ]]; then
echo "PASS: list_tickets count is greater than 0."
else
echo "FAIL: list_tickets count is 0 or less."
fi一次過路人的見解
該提示是一個有意設置的樸實版本的bash腳本，我設想的腳本。我本來也打算在最初的提示中提供樣本輸出，但忘記這么做了。回想起來，不提供輸出而先讓ChatGPT專注于腳本本身可能是一個好主意。它的一些觀察包括:
RESPONSE:
While you’ve used set -eu to exit on any error or unset variable usage, consider using set -euo pipefail to also capture failures in any part of a pipeline.這是一個很好的關于在編碼時如何從LLM中隱性地獲取知識的例子。我之前對bash中的嚴格模式有一些了解，但不完整。因此我們暫停了一會兒來探索這個話題，我加深了知識，并記下考慮使用其他-o參數(shù) —— 尤其是 -x(xtrace) 和 -n(noexec) 用于調(diào)試。我們剛剛開始處理手頭的實際任務，但這個小小的繞道本身就很有價值。
讓我們來談談JSON
我現(xiàn)在回頭提供了樣本輸出:
PROMPT:
“tickets_list”: “[{\”associates_rdb\”:null,\”association_type\”:null,\”cc_email\”:{\”cc_emails\”:[],\”fwd_emails\”:[],\”reply_cc\”:[],\”tkt_cc\”:[]},\”created_at\”:\”2023-10-12T12:15:00+01:00\”,\”custom_field\”:{\”cf_reference_number_2939992\”:null},\”datetime_tc01\”:null,\”datetime_tc02\”:null,\”datetime_tc03\”:null,\”deleted\”:false,\”delta\”:true,\”description\”:\”world\”,\”description_html\”:\”\\u003cdiv\\u003eworld\\u003c/div\\u003e\”,\”dirty\”:0,\”display_id\”:17,\”due_by\”:\”2023-10-16T22:00:00+01:00\”,\”email_config_id\”:153000020300,\”frDueBy\”:\”2023-10-12T22:00:00+01:00\”,\”fr_escalated\”:true,\”group_id\”:null,\”id\”:153002218563,\”int_tc01\”:null,\”int_tc02\”:null,\”int_tc03\”:null,\”int_tc04\”:null,\”int_tc05\”:null,\”internal_agent_id\”:null,\”internal_group_id\”:null,\”isescalated\”:false,\”json_tc01\”:null,\”long_tc01\”:null,\”long_tc02\”:null,\”long_tc03\”:null,\”long_tc04\”:null,\”long_tc05\”:null,\”nr_due_by\”:null,\”nr_escalated\”:false,\”nr_reminded\”:false,\”owner_id\”:null,\”parent_ticket_id\”:null,\”priority\”:1,\”priority_name\”:\”Low\”,\”product_id\”:153000018092,\”requester_id\”:153002362554,\”requester_name\”:\”Jon Udell\”,\”requester_status_name\”:\”O(jiān)pen\”,\”responder_id\”:null,\”responder_name\”:\”No Agent\”,\”sl_escalation_level\”:null,\”sl_manual_dueby\”:null,\”sl_merge_parent_ticket\”:null,\”sl_product_id\”:null,\”sl_skill_id\”:null,\”sl_sla_policy_id\”:null,\”sla_state\”:0,\”source\”:2,\”source_name\”:\”Portal\”,\”spam\”:false,\”st_survey_rating\”:null,\”status\”:2,\”status_name\”:\”O(jiān)pen\”,\”subject\”:\”hello\”,\”ticket_type\”:null,\”to_email\”:null,\”to_emails\”:null,\”trained\”:false,\”updated_at\”:\”2023-10-12T22:05:04+01:00\”,\”urgent\”:false},{\”associates_rdb\”:null,\”association_type\”:null,\”cc_email\”:{\”bcc_emails\”:[],\”cc_emails\”:[],\”fwd_emails\”:[],\”reply_cc\”:[],\”tkt_cc\”:[]},\”created_at\”:\”2023-10-12T04:41:12+01:00\”,\”custom_field\”:{\”cf_reference_number_2939992\”:null},\”datetime_tc01\”:null,\”datetime_tc02\”:null,\”datetime_tc03\”:null,\”deleted\”:false,\”delta\”:true,\”description\”:\”Hello there, Our Report metrics over the last week is at zero and can’t be correct? Are you facing any issues?\”,\”description_html\”:\”Hello there, Our Report metrics over the last week is at zero and can’t be correct? Are you facing any issues?\”,\”dirty\”:0,\”display_id\”:6,\”due_by\”:\”2023-10-16T22:00:00+01:00\”,\”email_config_id\”:153000020300,\”frDueBy\”:\”2023-10-12T22:00:00+01:00\”,\”fr_escalated\”:false,\”group_id\”:153000077019,\”id\”:153002214584,\”int_tc01\”:null,\”int_tc02\”:null,\”int_tc03\”:null,\”int_tc04\”:null,\”int_tc05\”:null,\”internal_agent_id\”:null,\”internal_group_id\”:null,\”isescalated\”:false,\”json_tc01\”:null,\”long_tc01\”:null,\”long_tc02\”:null,\”long_tc03\”:null,\”long_tc04\”:null,\”long_tc05\”:null,\”nr_due_by\”:null,\”nr_escalated\”:false,\”nr_reminded\”:false,\”owner_id\”:null,\”parent_ticket_id\”:null,\”priority\”:1,\”priority_name\”:\”Low\”,\”product_id\”:153000018092,\”requester_id\”:153002465401,\”requester_name\”:\”Adam Doe\”,\”requester_status_name\”:\”O(jiān)pen\”,\”responder_id\”:null,\”responder_name\”:\”No Agent\”,\”sl_escalation_level\”:null,\”sl_manual_dueby\”:null,\”sl_merge_parent_ticket\”:null,\”sl_product_id\”:null,\”sl_skill_id\”:null,\”sl_sla_policy_id\”:null,\”sla_state\”:0,\”source\”:1,\”source_name\”:\”Email\”,\”spam\”:false,\”st_survey_rating\”:null,\”status\”:2,\”status_name\”:\”O(jiān)pen\”,\”subject\”:\”Issues with reports\”,\”ticket_type\”:\”Bug\”,\”to_email\”:null,\”to_emails\”:null,\”trained\”:false,\”updated_at\”:\”2023-10-12T04:41:13+01:00\”,\”urgent\”:false}]”
}在另一個情景下，我可能會花時間優(yōu)化格式化這個 JSON 輸出。但是 LLM —— 像編譯器和解釋器 —— 不關心這些。更棒的是，它們可以容忍會使傳統(tǒng) JSON 格式化程序死機的語法。如果你把上面的例子粘貼到傳統(tǒng)格式器，會遇到兩個問題。首先，如果不用花括號包裹就不是有效的 JSON。其次， tickets_list 的值不會是 JSON 對象，而是字符串，因為該值是 JSON 的字符串化表示。非常神奇的是，LLM “知道” 你的意圖并做出正確反應:
RESPONSE:{
"tickets_list": [
{
"associates_rdb": null,
"association_type": null,
"cc_email": {
"cc_emails": [],
"fwd_emails": [],
"reply_cc": [],
"tkt_cc": []
},
"created_at": "2023-10-12T12:15:00+01:00",
"custom_field": {
"cf_reference_number_2939992": null
},
...
}
]
}這是非常瑣碎的東西，但它是可能影響你的工作流程并浪費最好留給高級功能的認知資源的東西。在這一點上，我還進行了我稱之為可解釋性測試: LLM是否解釋了1) 代碼片段需要被花括號包裹，以及2) 嵌套的值需要被解析？以下是結(jié)果。
工具 | llm 提供者 | 解釋需要使用{} | 解釋tickets_list需要解析 |
chatgpt | openai | 否 | 是 |
copilot chat | 開放ai | 否 | 是 |
claude | anthropic | 否 | 否 |
cody | anthropic | 否 | 否 |
這引起我的興趣，因為雖然我知道 Copilot Chat 使用 OpenAI ，Cody 使用 Anthropic，但這不總是明顯的。各自的聊天界面增強了提示，使回復不同于從底層 LLM 獲得的回復。但在這個例子中，工具似乎與它們各自的界面行為一致。
讓我們來討論測試策略
ChatGPT 對 set -euo pipefail 的觀察只是我們可以探索的多個方向之一，但我把話題引回到了手頭的任務上: 完善我在最初提示中包含的測試腳本。該腳本測試的是 Freshdesk 票務系統(tǒng)的輸出結(jié)果，而天真的測試只是檢查我們正在測試的工具是否可以調(diào)用 Freshdesk 的 API 并返回多于 0 張票。更好的測試會是什么樣的呢？ChatGPT 的建議包括檢查優(yōu)先級和狀態(tài)是否與預期值匹配、空值或長列表的票務是否被優(yōu)雅處理，以及所有日期字段是否存在并包含有效日期。
我選擇了最后一種方法，ChatGPT 相應地修改了測試腳本。這需要編寫一個正則表達式來匹配日期，并在每張票的一組日期字段中循環(huán)應用該正則表達式。這感覺太復雜了，所以我要求將范圍限制為僅檢查一個日期字段: created_at。即使這樣仍然感覺太復雜，所以我們舍棄了循環(huán)，將測試簡化為僅檢查單張票中的有效日期。之后我們轉(zhuǎn)向了下一個話題。
讓我們來討論如何將測試推廣到一個測試套件
需要測試的用例有:
- 列出 Freshdesk 票據(jù)
- 創(chuàng)建新 Freshdesk 票據(jù)
- 刪除 Freshdesk 票據(jù)
- 檢索特定 Freshdesk 票據(jù)的詳細信息
- 更新 Freshdesk 票據(jù)
- 向 Freshdesk 票據(jù)添加注釋
我很少使用 bash 函數(shù)，但我覺得在這里它們可能會很有用，所以當看到一個將 bash 腳本結(jié)構(gòu)化為與六個測試用例對應六個函數(shù)的回復時，我很高興。“看起來不錯，”我說，“請給我一個完整的構(gòu)建如此結(jié)構(gòu)化的版本，并包含第一個測試。”
此時，一個在我身邊觀看的同事想知道是否對 LLMs 使用“請”和“謝謝”會帶來更好的結(jié)果。這打敗了我！我只是因為感覺很好才這樣做。這是一種危險的人格化嗎？也許吧。但即使它們是非人類，我也看不出欺負我的助手有任何益處。
然后同一位同事問及另一種從表格驅(qū)動測試的替代策略。我們問:
PROMPT:
We are wondering if it would be better to have a data structure for these tests instead of a set of loose functions, what do you think are the pros and cons?回應提到了優(yōu)點(可維護性、重用性、并行執(zhí)行、一致的日志記錄、清晰度)和缺點(額外開銷、復雜度、遷移時間、學習曲線)。它以這段總結(jié)結(jié)束:
RESPONSE:
Given that your test suite might grow or change over time, adopting a structured approach earlier can be beneficial. However, it’s essential to weigh the initial time investment against the long-term benefits. If you think your test suite will remain relatively small and static, the current loose function setup might suffice. But if you anticipate growth or frequent changes, the structured approach will pay off in the long run.由于我們處于快速原型設計階段，還沒有準備好對此測試策略進行長期投資，所以我們選擇保持松散函數(shù)的方式。但我們都覺得花幾分鐘考慮替代方法是非常有價值的。
讓我們來討論持久化票據(jù) ID 的方法
要編寫的下一個測試是創(chuàng)建票據(jù)的測試。ChatGPT 建議存儲票據(jù)的 ID 以在其他測試中使用，以測試讀取、更新和向票據(jù)添加注釋的功能。并且它編寫了一個將 ID 持久化到文件的函數(shù)。這讓我感到疑惑，并要求評估在文件和變量之間保存的權(quán)衡取舍。這里是對回復的摘要，以表格形式進行了修訂(感謝 ChatGPT)。
保存于文件 | 保存于變量 | ||
優(yōu)點 | 缺點 | 優(yōu)點 | 缺點 |
持久性 | 速度較慢 | 速度快 | 揮發(fā)性 |
進程間通信 | 復雜度高 | 簡單 | 限于單個腳本/進程 |
適合大數(shù)據(jù) | 需清理 | 無文件依賴 | 內(nèi)存限制 |
并補充了這個結(jié)論:
RESPONSE:
If you’re writing a single script, and the data doesn’t need to persist beyond the script’s execution, a variable might be simpler and faster.我甚至沒有考慮基于文件的替代方法。當 ChatGPT 使用那種方法時，它促使我考慮并討論不同方案的權(quán)衡取舍。由于我最終做了與使用 LLM 之前完全一樣的事，這次繞路就是無謂的嗎？我不這么認為。考慮替代方案總是有價值的。這次繞路花費的時間很少，且雖然它沒有改變我最終的做法，但過程感覺很有價值。
在為 get_ticket 函數(shù)編寫測試時，我們也有過類似的交互。檢查獲取的票據(jù) ID 是否與我們存儲的 ID 匹配就足夠了嗎？ChatGPT 在效率和徹底性之間劃清了界限，列出了進行更徹底檢查的選項，并建議對于基本的冒煙測試，優(yōu)先考慮效率是有意義的。同樣，我已經(jīng)會做更簡單的事了，所以這并沒有改變?nèi)魏螙|西。但盡管我知道我們當然是在進行冒煙測試，大聲說出來還是顯得很有幫助。
讓我們來討論 Bash
這里有一個交互極大地改變了結(jié)果。我們向測試套件添加了第三個測試，但只運行了前兩個。出了什么問題？調(diào)試過程與使用 LLM 之前一樣，但 ChatGPT 可以更快地在代碼中插入打印語句，因此速度快了很多。在進行幾次這種暴力試錯法后，我們?nèi)匀粺o法通過第二個測試。
然后我想到問: "關閉 set -euo pipefail 會有意義嗎?" 當我這樣做時，腳本就完整運行了 - 即所有 6 個測試都運行了 - 但第二個測試在本應成功的情況下失敗了。隨后我恍然大悟。我問: "我們應該從 test_create_ticket 返回 $TICKET_ID 嗎？" ChatGPT 提醒我一個我讀過但從未遇到過的行為:
RESPONSE:
In the context of bash scripts, when you return a number from a function, it’s analogous to an exit code.我的天啊！對了！我們需要該函數(shù)設置全局變量為所創(chuàng)建票據(jù)的值，但返回零以避免過早退出，同時保持嚴格模式仍然生效。這是最后的突破；在那之后，一切順利。
當橡皮鴨說話時
我不斷回到這一系列文章的第一個主題: 當橡皮鴨說話時。大聲思考總是有幫助的。理想情況下，你可以與一個人類伙伴一起這樣做。橡皮鴨雖然是個糟糕的替代品，但遠勝于一無所有。
與 LLM 對話不像這些選擇中的任何一個，這完全是另一回事;我們都在努力弄明白它如何發(fā)揮作用。要求 LLM 編寫代碼，神奇地出現(xiàn)代碼？這明顯是一個改變生活的事情。與 LLM 就你們合作編寫的代碼進行交談？我認為這同樣是一個不太明顯但同樣深刻的改變生活的事情。
