有輸入就要有輸出
上一篇文章中，我故意漏掉了一個(gè)手法沒(méi)有講。具體是什么樣的手法呢？其實(shí)在實(shí)施的過(guò)程中，我發(fā)現(xiàn)把主干流程的邏輯講的再清楚，他生成的時(shí)候還是會(huì)有很多錯(cuò)誤，改進(jìn)自己的描述已經(jīng)讓我覺(jué)得有些煩躁了。我不由得想起了2023年1月，ECM發(fā)了一篇文章：《The End of Programming》以呼應(yīng)ChatGPT的誕生，在文章的最后寫道:
我們正在迅速走向這樣一個(gè)世界：計(jì)算的基本構(gòu)件是有脾氣的、神秘的、自適應(yīng)的代理。
好家伙，克蘇魯神話的味都出來(lái)了，世界的底層是混亂與瘋狂是嗎？所以ChatGPT就是是活化的隱匿賢者？_
玩完梗我們回來(lái)看這個(gè)事情啊，突然我意識(shí)到，是不是我之前的prompt還缺了一些東西？我只給了輸入和主干邏輯，我沒(méi)有給他輸出啊。在我的視角里，可能這個(gè)輸入通過(guò)這個(gè)主干邏輯只能有一種結(jié)果，但是對(duì)于AI來(lái)說(shuō)，也未必?。▌e說(shuō)AI了，我跟另一個(gè)初級(jí)開(kāi)發(fā)這么講，他都未必能寫出一種結(jié)果來(lái)，只能說(shuō)這個(gè)行為表現(xiàn)太人類了）。如果我把輸出也給他是不是可以讓他寫的更好一點(diǎn)，于是我把我的prompt改成了下面的描述：
我想用nodeJS用下面的yaml描繪的數(shù)據(jù)結(jié)構(gòu)得到一個(gè)新的數(shù)組:
base:
steps: 10
batch_size: 1
poly:
- template_prompt:
template: >
a cat,
${ chara }
${ facial_expressions }
meta:
- chara: # 這里改成了數(shù)組
- Abyssinian,
- cat_in_boots,
facial_expressions:
- (smile:1.5),
- (smile:1.2),
- smile,
steps: 20
可能的輸出：
[
{
steps: 20,
prompt: 'a cat,\nAbyssinian,\n(smile:1.5),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\nAbyssinian,\n(smile:1.2),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\nAbyssinian,\nsmile,\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\ncat_in_boots,\n(smile:1.5),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\ncat_in_boots,\n(smile:1.2),\n',
batch_size: 1
},
{
steps: 20,
prompt: 'a cat,\ncat_in_boots,\nsmile,\n',
batch_size: 1
},
]
要求：
- 假設(shè)上面的yaml轉(zhuǎn)成json的轉(zhuǎn)換代碼我已經(jīng)寫完了
- 我需要遍歷poly下的所有的頂層元素
- 遍歷過(guò)程中，要處理template_prompt元素的子元素：
- 從template中讀取作為模版。
- 讀取meta中的屬性，因?yàn)閷傩钥赡苊看味疾灰粯?，是不確定的，所以不能硬編碼。
- 然后基于meta中的屬性，把template作為 string literal 解析，這個(gè)解析代碼我已經(jīng)有了，假設(shè)名為render_string_template，可以不實(shí)現(xiàn)，留一個(gè)函數(shù)接口即可。
- 要遍歷組合meta中的每一個(gè)屬性組形成一個(gè)數(shù)組，
- 每一個(gè)屬性組可能只需要看做一個(gè)對(duì)象，當(dāng)且僅當(dāng)每一個(gè)屬性值都為單值
- 每一個(gè)屬性組可能也需要展開(kāi)，當(dāng)且僅當(dāng)任何一個(gè)屬性值有多值，比如 facial_expressions 有一個(gè)值，chara有兩個(gè)值，那么應(yīng)該生成1*2也就是兩組屬性放入這個(gè)數(shù)組中，這個(gè)數(shù)組和template會(huì)被傳入render_string_template函數(shù)，最后會(huì)獲得兩個(gè)prompt字符串
- 將生成的個(gè)prompt字符串?dāng)?shù)組和template_prompt元素之外的其他元素合并成一個(gè)對(duì)象，要求在同一級(jí)別。prompt字符串?dāng)?shù)組有幾個(gè)元素，就會(huì)合并成幾個(gè)對(duì)象，并放入一個(gè)新數(shù)組中，我們稱之為ploys。
- 繼續(xù)遍歷，直到遍歷完所有頂層元素，所有元素都放入了polys中。polys是一個(gè)一維數(shù)組。
- 將ploys中的每一個(gè)元素與base中的屬性合成一個(gè)新的對(duì)象，base的屬性展開(kāi)與prompt屬性同級(jí)，當(dāng)ploys中的每一個(gè)元素的屬性名與base中的屬性名相同時(shí)，覆蓋base中的屬性。這些新對(duì)象組合出的數(shù)組就是我要的數(shù)組
果然就得到了預(yù)期的結(jié)果。
這一個(gè)動(dòng)作，讓我打開(kāi)了思路，用輸入+輸出框住它生成的邊界還是挺好用的。輸入+輸出框住邊界？這不就是測(cè)試嗎？
停下來(lái)想一想
從我們的體驗(yàn)來(lái)看，確實(shí)啊，ChatGPT生成的是有點(diǎn)不穩(wěn)定。《The End of Programming》說(shuō)的沒(méi)錯(cuò)，底層確實(shí)有點(diǎn)混亂與瘋狂的味道，起碼不太穩(wěn)定。但這事也就聽(tīng)起來(lái)很嚇人，說(shuō)實(shí)在的，人就比ChatGPT穩(wěn)定多少呢？我這個(gè)人比較粗心大意，我寫代碼的時(shí)候也經(jīng)常腦子一抽，寫出一些事后看自己都想抽自己的腦殘錯(cuò)誤，所以我自打聽(tīng)說(shuō)了TDD，很快就變成了堅(jiān)定地TDD原教旨主義者，沒(méi)有TDD的世界對(duì)我們這種人來(lái)說(shuō)本來(lái)就是混亂與瘋狂的，要說(shuō)駕馭軟件開(kāi)發(fā)過(guò)程中的混亂與瘋狂，那你是問(wèn)對(duì)人了。
那么回顧一下TDD是什么？下面是一個(gè)復(fù)雜版
基本上就是，先寫一個(gè)測(cè)試用例，然后執(zhí)行，得到期望的失敗，什么是期望的失敗呢，比如說(shuō)，你寫了一個(gè)add函數(shù)，接受兩個(gè)參數(shù)，然后你寫了一個(gè)add(1,1)，你期望的失敗可能是返回某個(gè)值，他不等于2，實(shí)際你執(zhí)行的時(shí)候呢，報(bào)錯(cuò)，說(shuō)add函數(shù)不存在，這就不是你期望的失敗。你要調(diào)整環(huán)境到你期望的失敗，然后開(kāi)始寫實(shí)現(xiàn)，寫完實(shí)現(xiàn)再執(zhí)行，如果測(cè)試不通過(guò)了，就接著改實(shí)現(xiàn)，直到通過(guò)。如果通過(guò)了，就問(wèn)自己要不要重構(gòu)，如果要重構(gòu)，就改實(shí)現(xiàn)，改完的還要通過(guò)測(cè)試，如果不想重構(gòu)了，那就寫下一個(gè)測(cè)試用例?？傊褪沁@么個(gè)往復(fù)循環(huán)的流程。
如果上面那個(gè)復(fù)雜版讓你覺(jué)得很暈?zāi)?，可以看這個(gè)簡(jiǎn)單版：
紅表示測(cè)試執(zhí)行失敗，綠表示測(cè)試執(zhí)行通過(guò)，重構(gòu)就不用解釋了。所以永遠(yuǎn)是綠了重構(gòu)，重構(gòu)完可能紅可能綠，紅了就讓他變綠。只有變綠后，可以開(kāi)始下一次循環(huán)。
上面這些圖講的是TDD的過(guò)程，我個(gè)人覺(jué)得更核心的是，在實(shí)現(xiàn)代碼的這個(gè)過(guò)程中，你同時(shí)生產(chǎn)了一套自動(dòng)化測(cè)試，他可以在你將來(lái)不管是加新功能還是修Bug還是重構(gòu)，都不會(huì)陷入按下葫蘆起來(lái)瓢的窘境。那么在ChatGPT的時(shí)代，這個(gè)方法還能用嗎？總感覺(jué)哪里需要修改一下，不過(guò)沒(méi)關(guān)系，我們先走起來(lái)，邊走邊想。
想好了，繼續(xù)出發(fā)
那么既然是TDD，應(yīng)該先寫測(cè)試，但是我實(shí)現(xiàn)都寫完了啊。算了，這也是大多數(shù)項(xiàng)目的現(xiàn)狀，那就先補(bǔ)個(gè)測(cè)試吧。但是補(bǔ)測(cè)試是個(gè)很煩的事情啊，我靈機(jī)一動(dòng)，要不……讓ChatGPT給我搞？它能行嗎？誰(shuí)知道呢，試試又不花錢。
于是我就說(shuō)：
給下面代碼設(shè)計(jì)一些測(cè)試用例：
module.exports = function render_my_yaml_dsl(data) {
const vm = require('vm');
// 定義一個(gè)函數(shù)用于渲染字符串模板
function render_string_template(originalScriptTemplate, intention) {
// console.log(intention);
// 省略渲染代碼
const execScriptTemplate = "`" + originalScriptTemplate + "`";
const script = new vm.Script(execScriptTemplate);
const execScript = script.runInNewContext(intention);
// console.debug(execScript);
return execScript;
}
// 定義一個(gè)函數(shù)用于展開(kāi)屬性組合
function expand_attributes(attributes) {
const result = [];
attributes.forEach(obj => {
Object.values(obj).forEach(val => {
if (Array.isArray(val)) {
val.forEach(v => {
result.push({ ...obj, [Object.keys(obj).find(key => obj[key] === val)]: v });
});
} else {
result.push(obj);
}
});
});
return result;
}
const polys = [];
for (const poly of data.poly) {
const { template_prompt, ...other } = poly;
const { template, meta } = template_prompt;
const variableGroups = expand_attributes(meta);
const prompts = variableGroups.map(variables => render_string_template(template, variables));
for (const prompt of prompts) {
polys.push({ prompt, ...other });
}
}
const result = polys.map(poly => ({ ...data.base, ...poly }));
return result;
}
是的就是這么任性，代碼直接扔給他。然后我得到了下面的回復(fù):
以下是一些可能的測(cè)試用例：
- 當(dāng)輸入?yún)?shù) data 為空對(duì)象時(shí)，函數(shù)是否能正常運(yùn)行并返回一個(gè)空數(shù)組？
- 當(dāng)輸入?yún)?shù) data.poly 為空數(shù)組時(shí)，函數(shù)是否能正常運(yùn)行并返回一個(gè)空數(shù)組？
- 當(dāng)輸入?yún)?shù) data.poly 不包含任何屬性組合時(shí)，函數(shù)是否能正常運(yùn)行并返回一個(gè)包含原始數(shù)據(jù)的數(shù)組？
- 當(dāng)輸入?yún)?shù) data.poly 包含一個(gè)屬性組合時(shí)，函數(shù)是否能正常運(yùn)行并返回一個(gè)包含根據(jù)屬性組合渲染的數(shù)據(jù)的數(shù)組？
- 當(dāng)輸入?yún)?shù) data.poly 包含多個(gè)屬性組合時(shí)，函數(shù)是否能正常運(yùn)行并返回一個(gè)包含根據(jù)所有屬性組合渲染的數(shù)據(jù)的數(shù)組？
- 當(dāng)模板中的字符串模板包含模板變量時(shí)，函數(shù)是否能正常運(yùn)行并渲染模板變量？
- 當(dāng)模板中的字符串模板包含 JavaScript 代碼時(shí)，函數(shù)是否能正常運(yùn)行并執(zhí)行 JavaScript 代碼？
- 當(dāng)屬性組合中包含數(shù)組時(shí)，函數(shù)是否能正常運(yùn)行并正確展開(kāi)屬性組合？
- 當(dāng)屬性組合中包含對(duì)象時(shí)，函數(shù)是否能正常運(yùn)行并正確展開(kāi)屬性組合？
- 當(dāng)輸入?yún)?shù) data.base 中包含對(duì)象時(shí)，函數(shù)是否能正常運(yùn)行并將 data.base 和渲染的屬性組合合并為一個(gè)對(duì)象？
我嘆了口氣，我在期望什么，果然是這么泛泛的片湯話嗎？這玩意還用你告訴我？而且，你這里面還有些不是我想要的啊。唉……心中抱怨了一陣后，我還是不死心，我繼續(xù)說(shuō)：
分別準(zhǔn)備一些數(shù)據(jù)
這個(gè)要求仿佛打開(kāi)了潘多拉的盒子，我得到了下面的輸出：
以下是可能的數(shù)據(jù)準(zhǔn)備：
- 空對(duì)象：
const data = {};
- 空的 poly 數(shù)組：
const data = {
poly: []
};
- 包含一個(gè)屬性組合的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${name}: ${price}',
meta: [
{ name: 'color', value: ['red', 'blue'] },
{ name: 'price', value: [10, 20] }
]
},
id: 1
}
]
};
- 包含多個(gè)屬性組合的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${name}: ${price}',
meta: [
{ name: 'color', value: ['red', 'blue'] },
{ name: 'price', value: [10, 20] }
]
},
id: 1
},
{
template_prompt: {
template: '${name} (${size}): ${price}',
meta: [
{ name: 'size', value: ['S', 'M', 'L'] },
{ name: 'price', value: [30, 40, 50] }
]
},
id: 2
}
]
};
- 包含模板變量和 JavaScript 代碼的字符串模板的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${name}: ${price + tax}',
meta: [
{ name: 'color', value: ['red'] },
{ name: 'price', value: [10] },
{ name: 'tax', value: [2] }
]
},
id: 1
}
]
};
- 包含數(shù)組和對(duì)象的屬性組合的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${name} (${color.name}): ${price}',
meta: [
{ color: { name: 'red', code: '#ff0000' }, price: [10] },
{ color: { name: 'blue', code: '#0000ff' }, price: [20] }
]
},
id: 1
}
]
};
- 包含屬性值為數(shù)組，但未包含數(shù)組元素的屬性組合的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${name} (${color}): ${price}',
meta: [
{ color: ['red'], price: [10] },
{ color: ['blue'], price: [20] }
]
},
id: 1
}
]
};
- 包含模板變量為屬性值的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${props.name}: ${props.price}',
meta: [
{ props: { name: 'Product B', price: 30 } }
]
},
id: 1
}
]
};
- 包含 render_string_template 函數(shù)中 console.log 調(diào)用的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${name}: ${price}',
meta: [
{ name: 'color', value: ['red', 'blue'] },
{ name: 'price', value: [10, 20] }
]
},
id: 1
}
]
};
console.log(render_my_yaml_dsl(data));
- 包含 expand_attributes 函數(shù)中未包含數(shù)組的屬性組合的數(shù)據(jù)：
const data = {
base: {
id: 1,
name: 'Product A'
},
poly: [
{
template_prompt: {
template: '${name} (${color}): ${price}',
meta: [
{ color: 'red', price: [10] },
{ color: 'blue', price: [20] }
]
},
id: 1
}
]
};
這一刻，我仿佛聽(tīng)到了什么出現(xiàn)裂紋的聲音，是我的飯碗嗎_。
我曾經(jīng)愚蠢的以為，當(dāng)我們有了ChatGPT這么強(qiáng)大的工具后，我們只需要寫測(cè)試就可以了，讓他去寫實(shí)現(xiàn)，而我沒(méi)有發(fā)現(xiàn)這個(gè)邏輯里面一個(gè)愚蠢的漏洞，一個(gè)AI都能寫實(shí)現(xiàn)了，為什么他寫不了測(cè)試呢？反過(guò)來(lái)講，有很多客戶問(wèn)我有沒(méi)有自動(dòng)生成自動(dòng)化測(cè)試的工具，因?yàn)樗麄儾幌雽憸y(cè)試，現(xiàn)在也一樣尷尬了。好消息是，有，壞消息是，實(shí)現(xiàn)他也能寫。
激動(dòng)了一會(huì)，我漸漸冷靜下來(lái)了，沒(méi)事沒(méi)事，這測(cè)試沒(méi)法直接用啊，對(duì)吧，你看這測(cè)試難道還能扔給一個(gè)框架讓他自動(dòng)運(yùn)行嗎，那不是還要寫一個(gè)專用框架………………想到這，我意識(shí)到……好像……我在第一篇的時(shí)候干過(guò)這事……然后我懷著忐忑的心，寫下了下面的prompt：
我們的文件夾結(jié)構(gòu)如下所示
. ├── index.js └── test ├── cases │ ├── 1.input.json │ ├── 1.output.json │ ├── 2.input.json │ ├── 2.output.json │ ├── 3.input.json │ ├── 3.output.json │ ├── 4.input.json │ └── 4.output.json └── index.jsindex.js 是一個(gè)函數(shù)，大概如下:
module.exports = function render_my_yaml_dsl(data){
//....
}
test/cases下是所有的測(cè)試數(shù)據(jù)，input和output為一組，比如1.input.json存儲(chǔ)了一個(gè)測(cè)試的描述和given數(shù)據(jù)，1.output.json存儲(chǔ)了一個(gè)測(cè)試的expect數(shù)據(jù)。兩者在.input或.output之前的字符串完全相等為一組。
input.json數(shù)據(jù)結(jié)構(gòu)為：
{
"desc": "測(cè)試用例描述",
"data": { //具體的測(cè)試數(shù)據(jù)
}
}
output.json則全部為具體的測(cè)試數(shù)據(jù)
基于這個(gè)文件夾結(jié)構(gòu)寫一個(gè)測(cè)試框架，放在test/index.js里，要求：
- 可以遍歷test/cases下的文件，分組執(zhí)行且互相不干擾，也就是其中一組失敗了也會(huì)繼續(xù)運(yùn)行下一組，只是會(huì)打印出錯(cuò)誤信息。
- 可以在上層文件夾執(zhí)行
node test來(lái)執(zhí)行- 讀取文件的fs，要使用const fs = require('fs/promise')引入。
- 用assert庫(kù)進(jìn)行斷言
- 每執(zhí)行一個(gè)測(cè)試，要打印一個(gè)提示，提示的部分內(nèi)容要來(lái)自input.json 中的desc
給出這個(gè)代碼
然后我得到了下面的代碼：
可以使用以下代碼實(shí)現(xiàn)測(cè)試框架：
const assert = require('assert');
const fs = require('fs/promises');
const path = require('path');
const render_my_yaml_dsl = require('../index');
const testDir = path.join(__dirname, 'cases');
async function runTests() {
const files = await fs.readdir(testDir);
for (const file of files) {
if (!file.endsWith('.input.json')) {
continue;
}
const caseName = path.basename(file, '.input.json');
const input = await fs.readFile(path.join(testDir, `${caseName}.input.json`), 'utf8');
const output = await fs.readFile(path.join(testDir, `${caseName}.output.json`), 'utf8');
const { desc, data } = JSON.parse(input);
console.log(`Running test "${desc}"`);
try {
const result = render_my_yaml_dsl(data);
assert.deepStrictEqual(result, JSON.parse(output));
console.log(`Test "${desc}" passed`);
} catch (error) {
console.error(`Test "${desc}" failed`);
console.error(error);
}
}
}
runTests();
解釋：
- 首先引入 assert 和 fs 模塊，并且導(dǎo)入需要測(cè)試的函數(shù) render_my_yaml_dsl。
- 定義測(cè)試文件夾路徑 testDir。
- 創(chuàng)建一個(gè)異步函數(shù) runTests 來(lái)遍歷測(cè)試文件夾下的所有測(cè)試用例。
- 使用 fs.readdir 異步讀取測(cè)試文件夾下的所有文件，然后遍歷文件數(shù)組，只選擇以 .input.json 結(jié)尾的文件，跳過(guò)其他文件。
- 通過(guò) path.basename 函數(shù)獲取測(cè)試用例的名稱，然后使用 fs.readFile 異步讀取該測(cè)試用例的輸入和輸出文件，并使用 JSON.parse 解析 JSON 格式的數(shù)據(jù)。
- 在控制臺(tái)中打印正在運(yùn)行的測(cè)試用例的描述 desc。
- 使用 try...catch 語(yǔ)句運(yùn)行測(cè)試用例，并使用 assert.deepStrictEqual 函數(shù)斷言測(cè)試結(jié)果是否與期望值相等。如果測(cè)試通過(guò)，打印成功信息，否則打印錯(cuò)誤信息。
- 最后調(diào)用 runTests 函數(shù)運(yùn)行測(cè)試。
這一刻我終于確信，那確實(shí)是飯碗出現(xiàn)裂紋的聲音。(雖然上面的只有輸入，但是后來(lái)我讓他給出輸出，他也給出了，反正測(cè)試框架都有了，大不了跑一遍就有了所有的輸出了嘛，所以這不是啥大問(wèn)題。)
有了這個(gè)框架之后，我工作流程大概變成了這么個(gè)節(jié)奏：
- 告訴他，我要擴(kuò)展新功能，然后扔給他舊代碼，接著告訴他這里是新新功能需要的輸入，我期望的輸出是什么。邊界是什么，現(xiàn)在給我代碼。
- 然后執(zhí)行新加的測(cè)試，
- 如果新測(cè)試不通過(guò)，就讓他重新生成.
- 如果新加測(cè)試通過(guò)了，但是舊的測(cè)試廢了，就把就廢了測(cè)試配上代碼給他，告訴他代碼有Bug，這是以前的輸入，期望的輸出是什么，你現(xiàn)在的輸出是什么，讓他改代碼。
整個(gè)過(guò)程就很像TDD的紅-綠循環(huán)，雖然重構(gòu)沒(méi)有了，但是紅綠循環(huán)還是有的。
而更過(guò)分的是，一開(kāi)始新功能需要的測(cè)試用例我都懶得自己寫，我就大概告訴他要搞個(gè)什么樣的擴(kuò)展，給他代碼和舊得測(cè)試用例結(jié)構(gòu)，讓他給我寫個(gè)新的測(cè)試用例。然后就給我寫出來(lái)了。（也不總能很完美，但是就是需要改也比以前快了不知道多少，關(guān)鍵不用去想那些繁瑣的細(xì)節(jié)也是提供了一定程度的情緒價(jià)值。）
按照我的工作流程畫個(gè)人在回路是這樣的：
總結(jié)一下
開(kāi)篇我們從一個(gè)上一篇漏掉的關(guān)鍵手法開(kāi)始，了解到輸入和輸出配合可以讓ChatGPT寫出的代碼更靠譜，而且對(duì)于主干流程的描述可以不用那么復(fù)雜。
接著我們發(fā)現(xiàn)，這確定了輸入輸出就很像測(cè)試，那么我們是不是可以用測(cè)試驅(qū)動(dòng)的方式驅(qū)動(dòng)ChatGPT開(kāi)發(fā)呢？經(jīng)過(guò)一番嘗試我們得到了一個(gè)可以用于ChatGPT的類TDD工作方式。并畫出了整個(gè)人在回路。
這個(gè)回路很像TDD，但在這個(gè)回路里，我們既不需要寫測(cè)試，也不需要寫實(shí)現(xiàn)，我們主要的工作是保證ChatGPT在按照整個(gè)TDD的流程在寫代碼。因?yàn)門DD屬于XP（極限編程）的核心實(shí)踐，所以我們開(kāi)玩笑說(shuō)，參照Scrum Master，我們以后可以叫自己XP Master。被人提醒Master會(huì)被沖，那我們就叫自己 XP Shifu 吧。（典出功夫熊貓_）
目前受制于GPT3.5的3000多字的限制，只能一個(gè)個(gè)用例讓他改，等GPT4的3萬(wàn)多字成為常態(tài)后，這個(gè)工作方法只會(huì)更強(qiáng)大，甚至可以考慮某種程度的自動(dòng)化。因?yàn)槲覀兛梢钥吹?，人在回路上只有一個(gè)環(huán)節(jié)需要人參與，其他的都可以不需要。這就是我們上篇文章中提到的，可以自動(dòng)化的一種思路，有想做工具的可以考慮一下，我還挺需要這么個(gè)工具的。
整個(gè)用ChatGPT編程的思路到這里主干就講的差不多了，接下來(lái)我們會(huì)講一些細(xì)分場(chǎng)景的套路。然后如果有時(shí)間的話，就把派發(fā)引擎和自動(dòng)化工具也試著做一做，把過(guò)程文字直播在這里，感興趣的可以關(guān)注一波：）
