有輸入就要有輸出

上一篇文章中，我故意漏掉了一個(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的誕生，在文章的最后寫(xiě)道:

我們正在迅速走向這樣一個(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ā)這么講，他都未必能寫(xiě)出一種結(jié)果來(lái)，只能說(shuō)這個(gè)行為表現(xiàn)太人類了）。如果我把輸出也給他是不是可以讓他寫(xiě)的更好一點(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)寫(xiě)完了

我需要遍歷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)定?！禩he End of Programming》說(shuō)的沒(méi)錯(cuò)，底層確實(shí)有點(diǎn)混亂與瘋狂的味道，起碼不太穩(wěn)定。但這事也就聽(tīng)起來(lái)很?chē)樔?，說(shuō)實(shí)在的，人就比ChatGPT穩(wěn)定多少呢？我這個(gè)人比較粗心大意，我寫(xiě)代碼的時(shí)候也經(jīng)常腦子一抽，寫(xiě)出一些事后看自己都想抽自己的腦殘錯(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ù)雜版

基本上就是，先寫(xiě)一個(gè)測(cè)試用例，然后執(zhí)行，得到期望的失敗，什么是期望的失敗呢，比如說(shuō)，你寫(xiě)了一個(gè)add函數(shù)，接受兩個(gè)參數(shù)，然后你寫(xiě)了一個(gè)add(1,1)，你期望的失敗可能是返回某個(gè)值，他不等于2，實(shí)際你執(zhí)行的時(shí)候呢，報(bào)錯(cuò)，說(shuō)add函數(shù)不存在，這就不是你期望的失敗。你要調(diào)整環(huán)境到你期望的失敗，然后開(kāi)始寫(xiě)實(shí)現(xiàn)，寫(xiě)完實(shí)現(xiàn)再執(zhí)行，如果測(cè)試不通過(guò)了，就接著改實(shí)現(xiàn)，直到通過(guò)。如果通過(guò)了，就問(wèn)自己要不要重構(gòu)，如果要重構(gòu)，就改實(shí)現(xiàn)，改完的還要通過(guò)測(cè)試，如果不想重構(gòu)了，那就寫(xiě)下一個(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)該先寫(xiě)測(cè)試，但是我實(shí)現(xiàn)都寫(xiě)完了啊。算了，這也是大多數(shù)項(xiàng)目的現(xiàn)狀，那就先補(bǔ)個(gè)測(cè)試吧。但是補(bǔ)測(cè)試是個(gè)很煩的事情啊，我靈機(jī)一動(dòng)，要不……讓ChatGPT給我搞？它能行嗎？誰(shuí)知道呢，試試又不花錢(qián)。 于是我就說(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)大的工具后，我們只需要寫(xiě)測(cè)試就可以了，讓他去寫(xiě)實(shí)現(xiàn)，而我沒(méi)有發(fā)現(xiàn)這個(gè)邏輯里面一個(gè)愚蠢的漏洞，一個(gè)AI都能寫(xiě)實(shí)現(xiàn)了，為什么他寫(xiě)不了測(cè)試呢？反過(guò)來(lái)講，有很多客戶問(wèn)我有沒(méi)有自動(dòng)生成自動(dòng)化測(cè)試的工具，因?yàn)樗麄儾幌雽?xiě)測(cè)試，現(xiàn)在也一樣尷尬了。好消息是，有，壞消息是，實(shí)現(xiàn)他也能寫(xiě)。

激動(dòng)了一會(huì)，我漸漸冷靜下來(lái)了，沒(méi)事沒(méi)事，這測(cè)試沒(méi)法直接用啊，對(duì)吧，你看這測(cè)試難道還能扔給一個(gè)框架讓他自動(dòng)運(yùn)行嗎，那不是還要寫(xiě)一個(gè)專用框架………………想到這，我意識(shí)到……好像……我在第一篇的時(shí)候干過(guò)這事……然后我懷著忐忑的心，寫(xiě)下了下面的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.js

index.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)寫(xiě)一個(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è)試用例我都懶得自己寫(xiě)，我就大概告訴他要搞個(gè)什么樣的擴(kuò)展，給他代碼和舊得測(cè)試用例結(jié)構(gòu)，讓他給我寫(xiě)個(gè)新的測(cè)試用例。然后就給我寫(xiě)出來(lái)了。（也不總能很完美，但是就是需要改也比以前快了不知道多少，關(guān)鍵不用去想那些繁瑣的細(xì)節(jié)也是提供了一定程度的情緒價(jià)值。）

按照我的工作流程畫(huà)個(gè)人在回路是這樣的：

總結(jié)一下

開(kāi)篇我們從一個(gè)上一篇漏掉的關(guān)鍵手法開(kāi)始，了解到輸入和輸出配合可以讓ChatGPT寫(xiě)出的代碼更靠譜，而且對(duì)于主干流程的描述可以不用那么復(fù)雜。

接著我們發(fā)現(xiàn)，這確定了輸入輸出就很像測(cè)試，那么我們是不是可以用測(cè)試驅(qū)動(dòng)的方式驅(qū)動(dòng)ChatGPT開(kāi)發(fā)呢？經(jīng)過(guò)一番嘗試我們得到了一個(gè)可以用于ChatGPT的類TDD工作方式。并畫(huà)出了整個(gè)人在回路。

這個(gè)回路很像TDD，但在這個(gè)回路里，我們既不需要寫(xiě)測(cè)試，也不需要寫(xiě)實(shí)現(xiàn)，我們主要的工作是保證ChatGPT在按照整個(gè)TDD的流程在寫(xiě)代碼。因?yàn)門(mé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)化工具也試著做一做

以上就是測(cè)試驅(qū)動(dòng)ChatGPT編程示例詳解的詳細(xì)內(nèi)容，更多關(guān)于測(cè)試驅(qū)動(dòng)ChatGPT編程的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！