上一講，我們一起通過(guò) ChatGPT 做了一個(gè)小應(yīng)用。不過(guò)，這個(gè)過(guò)程并不是一個(gè)“自動(dòng)檔”的。我們嘗試一步一步輸入我們的需求，給到 ChatGPT，并根據(jù)拿到的指示嘗試運(yùn)行代碼。通過(guò)和 ChatGPT 不斷地交互，我們最終完成了一個(gè)小應(yīng)用。

雖然這在我們探索性地開(kāi)發(fā)一些功能的時(shí)候，已經(jīng)極大地提高了我們的效率。但是這個(gè)過(guò)程并不能做成一個(gè)產(chǎn)品。我們理想中的產(chǎn)品應(yīng)該是“自動(dòng)檔”的，我們只要用自然語(yǔ)言輸入自己的需求，對(duì)應(yīng)的代碼就自動(dòng)寫(xiě)出來(lái)了。如果中間出現(xiàn)了錯(cuò)誤，AI 可以自己拿到反饋來(lái)更正，而不需要我們?nèi)斯とソ槿胝{(diào)試，或者復(fù)制粘貼。

先讓 GPT-4 寫(xiě)個(gè)代碼

這個(gè)思路聽(tīng)起來(lái)似乎有些科幻，但是隨著 GPT-4 的發(fā)布，以及未來(lái)模型能力的進(jìn)一步增長(zhǎng)，這其實(shí)并不是遙不可及的。不過(guò)，這個(gè)時(shí)候你應(yīng)該還只有 GPT-3.5 的 API 權(quán)限。所以這一講，我們還是先把目標(biāo)放低一點(diǎn)，先來(lái)通過(guò)大語(yǔ)言模型，幫我們自動(dòng)寫(xiě)單元測(cè)試代碼。整個(gè)過(guò)程仍然是一個(gè)自動(dòng)檔的體驗(yàn)，只是能夠提供的能力還相對(duì)比較簡(jiǎn)單，僅限于為現(xiàn)有代碼提供單元測(cè)試而已。

這個(gè)想法，源自 OpenAI Cookbook 提供的 AI 寫(xiě)單元測(cè)試的示例。但是那個(gè)例子里面的代碼，已經(jīng)不能使用了，因?yàn)閷?duì)應(yīng)的 code-davinci-002 模型已經(jīng)被 OpenAI 下線了。但是例子里，分步驟分析問(wèn)題，通過(guò)多個(gè) Prompts 來(lái)完成單元測(cè)試的想法，還是非常有借鑒意義的。

相信學(xué)完這一講之后，隨著你拿到 GPT-4 的 API 乃至未來(lái)可能會(huì)出現(xiàn)的 GPT-5，你都完全可以用同樣的方法完成更復(fù)雜的“自動(dòng)寫(xiě)代碼”的程序。

設(shè)計(jì)一個(gè)有些挑戰(zhàn)的小題目

要寫(xiě)測(cè)試，我們要先有一個(gè)程序。為了避免這個(gè)題目本身就在 AI 的訓(xùn)練數(shù)據(jù)集里面，它直接知道答案，我們就不選用像 Leetcode 這樣的題庫(kù)了。我用了這樣一個(gè)我覺(jué)得很有意思的小題目，也就是讓 Python 根據(jù)我們輸入的一個(gè)整數(shù)代表的秒數(shù)，格式化成一段自然語(yǔ)言描述的時(shí)間。比如，輸入 1 就返回 1s，輸入 61 就返回 1min1s。

需求：

用Python寫(xiě)一個(gè)函數(shù)，進(jìn)行時(shí)間格式化輸出，比如：
輸入  輸出
1  1s
61  1min1s
要求僅需要格式化到小時(shí)(?h?min?s)，即可

題目有了，我們還需要一個(gè)正確的解題程序。我們今天的重點(diǎn)不是怎么用 AI 刷題，所以我們不如直接讓 ChatGPT 幫我們把程序?qū)懞谩?/p>

這是對(duì)應(yīng)的 Notebook 里面的代碼。

def format_time(seconds):
    minutes, seconds = divmod(seconds, 60)
    hours, minutes = divmod(minutes, 60)
    if hours > 0:
        return f"{hours}h{minutes}min{seconds}s"
    elif minutes > 0:
        return f"{minutes}min{seconds}s"
    else:
        return f"{seconds}s"

可以看到，AI 快速給出了一個(gè)小程序，看上去沒(méi)啥問(wèn)題，能夠完成我們想要的基本功能。

既然 ChatGPT 可以寫(xiě)代碼，我們自然也可以讓它幫我們把單元測(cè)試也寫(xiě)好。

conda install pytest

這是對(duì)應(yīng)的 Notebook 里面的代碼。

import pytest

def test_format_time():
    assert format_time(1) == "1s"
    assert format_time(59) == "59s"
    assert format_time(60) == "1min0s"
    assert format_time(61) == "1min1s"
    assert format_time(3600) == "1h0min0s"
    assert format_time(3661) == "1h1min1s"

乍一看，我們的單元測(cè)試已經(jīng)寫(xiě)完了，那這一講就結(jié)束了嗎？當(dāng)然不是了。如果你是一個(gè)比較有經(jīng)驗(yàn)的程序員，你就會(huì)發(fā)現(xiàn)這個(gè)單元測(cè)試其實(shí)還是有好幾個(gè)問(wèn)題的。

1. 這個(gè)測(cè)試沒(méi)有考慮負(fù)數(shù)。如果我們輸入的是負(fù)數(shù)會(huì)怎么樣？

2. 沒(méi)有考慮非整數(shù)類型的輸入，如果我們輸入浮點(diǎn)數(shù) 1.0 會(huì)怎么樣？字符串“abc”會(huì)怎么樣？nil 這樣的空值會(huì)怎么樣？

3. 是即使是整數(shù)，我們還沒(méi)有考慮過(guò)，超過(guò) 24 小時(shí)的話，格式化后的結(jié)果是怎么樣的。

分解步驟撰寫(xiě) Prompts

所以，很多事情不是我們直接把問(wèn)題一塞，給到 ChatGPT 就能解決的。我們需要反過(guò)來(lái)自己思考一下，如果我們自己來(lái)為一段代碼寫(xiě)單元測(cè)試，我們會(huì)怎么做？

OpenAI 的示例里給出了一個(gè)很好的思路，那就是把問(wèn)題拆分成三個(gè)步驟。

1. 把代碼提交給大語(yǔ)言模型，讓大語(yǔ)言模型解釋一下，這個(gè)代碼是在干什么。

2. 把代碼以及代碼的解釋一起交給大語(yǔ)言模型，讓大語(yǔ)言模型規(guī)劃一下，針對(duì)這個(gè)代碼邏輯，我們到底要寫(xiě)哪幾個(gè) TestCase。如果在這個(gè)過(guò)程里，大語(yǔ)言模型規(guī)劃的 TestCase 數(shù)量太少，那么我們就重復(fù)第二步，讓 AI 多生成幾個(gè) TestCase。

3. 針對(duì)上面的 TestCase 的詳細(xì)描述，再提交給大語(yǔ)言模型，讓它根據(jù)這些描述生成具體的測(cè)試代碼。在這個(gè)過(guò)程中，我們還會(huì)對(duì)生成的代碼，進(jìn)行一次語(yǔ)法檢查，如果語(yǔ)法檢查沒(méi)法通過(guò)，我們就要讓 AI 重新生成一下。這個(gè)可以避免因?yàn)榇笳Z(yǔ)言模型的概率采樣不穩(wěn)定，導(dǎo)致生成的代碼無(wú)法運(yùn)行的問(wèn)題。

最后，我們來(lái)實(shí)際運(yùn)行一下這些代碼，看看我們的代碼能不能通過(guò)這些自動(dòng)化測(cè)試。

請(qǐng) AI 解釋要測(cè)試的代碼

那最后，我們就根據(jù)這個(gè)步驟一步步拆解，通過(guò) Python 程序來(lái)把整個(gè)過(guò)程“自動(dòng)化”掉。

def gpt35(prompt, model="text-davinci-002", temperature=0.4, max_tokens=1000, 
          top_p=1, stop=["\n\n", "\n\t\n", "\n    \n"]):
    response = openai.Completion.create(
        model=model,
        prompt = prompt,
        temperature = temperature,
        max_tokens = max_tokens,
        top_p = top_p,
        stop = stop
        )
    message = response["choices"][0]["text"]
    return message

code = """
def format_time(seconds):
    minutes, seconds = divmod(seconds, 60)
    hours, minutes = divmod(minutes, 60)

    if hours > 0:
        return f"{hours}h{minutes}min{seconds}s"
    elif minutes > 0:
        return f"{minutes}min{seconds}s"
    else:
        return f"{seconds}s"
"""

def explain_code(function_to_test, unit_test_package="pytest"):
    prompt = f""""# How to write great unit tests with {unit_test_package}

In this advanced tutorial for experts, we'll use Python 3.10 and `{unit_test_package}` to write a suite of unit tests to verify the behavior of the following function.
```python
{function_to_test}


Before writing any unit tests, let's review what each element of the function is doing exactly and what the author's intentions may have been.
- First,"""
    response = gpt35(prompt)
    return response, prompt

code_explaination, prompt_to_explain_code = explain_code(code)
print(code_explaination)

在第一步里，我們的代碼做了這樣幾件事情。

首先是定義了一個(gè) gpt35 的函數(shù)，對(duì)調(diào)用 GPT3.5 的模型做了簡(jiǎn)單的封裝。其中有 2 點(diǎn)需要注意。

1. 我們默認(rèn)使用 text-davinci-002 模型，這是一個(gè)通過(guò)監(jiān)督學(xué)習(xí)微調(diào)的生成文本的模型。因?yàn)檫@里我們希望生成目標(biāo)明確的文本的代碼解釋，所以選用了這個(gè)模型。

2. 我們對(duì) stop 做了特殊的設(shè)置，只要連續(xù)兩個(gè)換行或者類似連續(xù)兩個(gè)換行的情況出現(xiàn)，就中止數(shù)據(jù)的生成。這是避免模型一口氣連測(cè)試代碼也生成出來(lái)。那樣的話，我們沒(méi)法對(duì)測(cè)試代碼的生成提出具體的要求。通過(guò) stop，我們可以確保在第一步，只解釋現(xiàn)在的功能代碼有什么用。

然后，我們通過(guò)一組精心設(shè)置過(guò)的提示語(yǔ)，讓 GPT 模型為我們來(lái)解釋代碼。我們?cè)谔崾菊Z(yǔ)里做了 4 件事情。

指定了使用 pytest 這個(gè)測(cè)試包。

把對(duì)應(yīng)要測(cè)試的代碼，也提供給了 GPT 模型。

告訴 AI，要精確描述代碼做了什么。

在最后一行用 “- First” 開(kāi)頭，引導(dǎo) GPT 模型，逐步分行描述要測(cè)試的代碼干了什么。

輸出結(jié)果：

 we use the `divmod` built-in function to get the quotient and remainder of `seconds` divided by 60. This is assigned to the variables `minutes` and `seconds`, respectively.
- Next, we do the same thing with `minutes` and 60, assigning the results to `hours` and `minutes`.
- Finally, we use string interpolation to return a string formatted according to how many hours/minutes/seconds are left.

運(yùn)行第一步的代碼，我們可以看到，AI 回復(fù)了幾個(gè)步驟，詳細(xì)地描述了我們格式化時(shí)間的代碼是怎么做的。

請(qǐng) AI 根據(jù)代碼解釋制定測(cè)試計(jì)劃

接下來(lái)，我們就根據(jù)生成的這個(gè)詳細(xì)描述，請(qǐng) AI 為我們制定一下具體的測(cè)試計(jì)劃。

def generate_a_test_plan(full_code_explaination, unit_test_package="pytest"):
    prompt_to_explain_a_plan = f"""
    
A good unit test suite should aim to:
- Test the function's behavior for a wide range of possible inputs
- Test edge cases that the author may not have foreseen
- Take advantage of the features of `{unit_test_package}` to make the tests easy to write and maintain
- Be easy to read and understand, with clean code and descriptive names
- Be deterministic, so that the tests always pass or fail in the same way

`{unit_test_package}` has many convenient features that make it easy to write and maintain unit tests. We'll use them to write unit tests for the function above.

For this particular function, we'll want our unit tests to handle the following diverse scenarios (and under each scenario, we include a few examples as sub-bullets):
-"""
    prompt = full_code_explaination + prompt_to_explain_a_plan
    response = gpt35(prompt)
    return response, prompt

test_plan, prompt_to_get_test_plan = generate_a_test_plan(prompt_to_explain_code + code_explaination)
print(test_plan)

我們整個(gè)測(cè)試計(jì)劃的提示語(yǔ)，同樣經(jīng)過(guò)了精心設(shè)計(jì)。我們先是對(duì) AI 做了幾個(gè)要求。

1. 我們要求測(cè)試用例，盡量考慮輸入的范圍廣一些。

2. 我們要求 AI 想一些連代碼作者沒(méi)有想到過(guò)的邊界條件。

3. 我們希望 AI 能夠利用好 pytest 這個(gè)測(cè)試包的特性。

4. 希望測(cè)試用例清晰易讀，測(cè)試的代碼要干凈。

5. 我們要求測(cè)試代碼的輸出結(jié)果是確定的，要么通過(guò)，要么失敗，不要有隨機(jī)性。

然后，我們的提示語(yǔ)并沒(méi)有立刻讓 AI 去寫(xiě)測(cè)試代碼，而是說(shuō)我們要舉幾個(gè)例子。這樣，AI 就會(huì)生成一系列的示例。我們對(duì)測(cè)試用例的提示是非常詳盡的，這也是我們前面第一步?jīng)]有直接讓 AI 生成測(cè)試用例的原因。因?yàn)槟菢拥脑?，我們沒(méi)法在提示語(yǔ)中間插入這些詳盡的要求。對(duì)具體的測(cè)試用例，只能寄希望于 AI 想得多一些。

最后，我們發(fā)給 AI 的提示語(yǔ)，則是既包括了第一步要求解釋代碼的內(nèi)容，也包括 AI 生成的對(duì)代碼的解釋，以及這里我們新增的對(duì)測(cè)試用例的要求，提供了非常詳細(xì)的上下文，這樣 AI 的表現(xiàn)也會(huì)更好、更有邏輯性。

輸出結(jié)果：

 Normal behavior:
    - `format_time(0)` should return `"0s"`
    - `format_time(59)` should return `"59s"`
    - `format_time(60)` should return `"1min0s"`
    - `format_time(119)` should return `"1min59s"`
    - `format_time(3600)` should return `"1h0min0s"`
    - `format_time(3601)` should return `"1h0min1s"`
    - `format_time(3660)` should return `"1h1min0s"`
    - `format_time(7200)` should return `"2h0min0s"`
- Invalid inputs:
    - `format_time(None)` should raise a `TypeError`
    - `format_time("abc")` should raise a `TypeError`
    - `format_time(-1)` should raise a `ValueError`

運(yùn)行了一下這個(gè)代碼，可以看到，AI 提供了很多測(cè)試用例。并且，里面考慮了好幾種情況，包括我們前面提到的負(fù)數(shù)這樣的特殊條件，也包括輸入字符串，以及 None 這樣的內(nèi)容。

不過(guò)，生成哪些用例其實(shí)是有一定的隨機(jī)性的。這個(gè)也是大語(yǔ)言模型的一個(gè)缺點(diǎn)，就是可控性差。有時(shí)候，AI 可能就只生成了 3 個(gè)用例，那樣的話就會(huì)有很多情況我們的用例覆蓋不到。

所以，我們可以在生成用例之后，加一個(gè)步驟，檢查一下到底生成了多少個(gè)用例。如果太少的話，我們就讓 AI 再生成一些。我在下面給了一段示例代碼，通過(guò)“\n-”這樣一個(gè)換行加橫桿的標(biāo)記來(lái)判斷之前生成的測(cè)試用例數(shù)量，如果比我們?cè)O(shè)定的下限少，我們就再添加一段提示語(yǔ)，讓 AI 再生成一些。

這里的提示語(yǔ)，我們要特別提醒 AI 考慮一下測(cè)試罕見(jiàn)情況和邊界條件。

not_enough_test_plan = """The function is called with a valid number of seconds
    - `format_time(1)` should return `"1s"`
    - `format_time(59)` should return `"59s"`
    - `format_time(60)` should return `"1min"`
"""

approx_min_cases_to_cover = 7
elaboration_needed = test_plan.count("\n-") +1 < approx_min_cases_to_cover 
if elaboration_needed:
        prompt_to_elaborate_on_the_plan = f"""

In addition to the scenarios above, we'll also want to make sure we don't forget to test rare or unexpected edge cases (and under each edge case, we include a few examples as sub-bullets):
-"""
        more_test_plan, prompt_to_get_test_plan = generate_a_test_plan(prompt_to_explain_code + code_explaination + not_enough_test_plan + prompt_to_elaborate_on_the_plan)
        print(more_test_plan)

輸出結(jié)果：

 The function is called with a valid number of seconds
    - `format_time(1)` should return `"1s"`
    - `format_time(59)` should return `"59s"`
    - `format_time(60)` should return `"1min"`
- The function is called with an invalid number of seconds
    - `format_time(-1)` should raise a `ValueError`
    - `format_time("60")` should raise a `TypeError`
- The function is called with a `None` value
    - `format_time(None)` should raise a `TypeError`

根據(jù)測(cè)試計(jì)劃生成測(cè)試代碼

當(dāng)然，大部分情況下，生成的測(cè)試用例數(shù)都和我們前面的實(shí)際情況是一樣的。那我們就可以直接用原來(lái)的代碼、代碼的解釋以及測(cè)試用例，作為提示語(yǔ)，讓 AI 幫我們寫(xiě)具體的測(cè)試了。

這里的提示語(yǔ)也沒(méi)有什么稀奇的，其實(shí)就是把前面已經(jīng)生成的所有內(nèi)容拼接在一起，然后要求 AI 根據(jù)前面的內(nèi)容來(lái)寫(xiě)具體的測(cè)試代碼。唯一有一點(diǎn)值得注意的是，為了避免 AI 忘記一開(kāi)頭功能代碼的內(nèi)容，我們特地再在提示語(yǔ)的最后，再次給 AI 看了一下我們要測(cè)試的功能代碼。

def generate_test_cases(function_to_test, unit_test_package="pytest"):
    starter_comment = "Below, each test case is represented by a tuple passed to the @pytest.mark.parametrize decorator"
    prompt_to_generate_the_unit_test = f"""

Before going into the individual tests, let's first look at the complete suite of unit tests as a cohesive whole. We've added helpful comments to explain what each line does.
```python
import {unit_test_package}  # used for our unit tests

{function_to_test}

#{starter_comment}"""
    full_unit_test_prompt = prompt_to_explain_code + code_explaination + test_plan + prompt_to_generate_the_unit_test
    return gpt35(model="text-davinci-003", prompt=full_unit_test_prompt, stop="```"), prompt_to_generate_the_unit_test

unit_test_response, prompt_to_generate_the_unit_test = generate_test_cases(code)
print(unit_test_response)

輸出結(jié)果：

.
#The first element of the tuple is the name of the test case, and the second element is the value to be passed to the format_time() function.
@pytest.mark.parametrize('test_input,expected', [
    ('0', '0s'),
    ('59', '59s'),
    ('60', '1min0s'),
    ('119', '1min59s'),
    ('3600', '1h0min0s'),
    ('3601', '1h0min1s'),
    ('3660', '1h1min0s'),
    ('7200', '2h0min0s'),
])
def test_format_time(test_input, expected):
    #For each test case, we call the format_time() function and compare the returned value to the expected value.
    assert format_time(int(test_input)) == expected

#We use the @pytest.mark.parametrize decorator again to test the invalid inputs.
@pytest.mark.parametrize('test_input', [
    None,
    'abc',
    -1
])
def test_format_time_invalid_inputs(test_input):
    #For each invalid input, we expect a TypeError or ValueError to be raised.
    with pytest.raises((TypeError, ValueError)):
        format_time(test_input)

運(yùn)行一下這段提示語(yǔ)，我們就拿到了最終輸出的測(cè)試代碼?？梢钥吹?，這個(gè)測(cè)試代碼不僅有正常情況下的測(cè)試，也包含了異常輸入的測(cè)試。

通過(guò) AST 庫(kù)進(jìn)行語(yǔ)法檢查

不過(guò)這還沒(méi)有完，我們最好還是再檢查一下生成的測(cè)試代碼的語(yǔ)法，這個(gè)可以通過(guò) Python 的 AST 庫(kù)來(lái)完成。不過(guò)需要注意，檢查語(yǔ)法的時(shí)候，我們不僅需要生成的測(cè)試代碼，也需要原來(lái)的功能代碼，不然是沒(méi)辦法通過(guò)語(yǔ)法檢查的。

import ast

code_start_index = prompt_to_generate_the_unit_test.find("```python\n") + len("```python\n")
code_output = prompt_to_generate_the_unit_test[code_start_index:] + unit_test_response
try:
    ast.parse(code_output)
except SyntaxError as e:
    print(f"Syntax error in generated code: {e}")

很幸運(yùn)，我們一次就通過(guò)了語(yǔ)法檢查。那么接下來(lái)，我們就可以把對(duì)應(yīng)的整個(gè)測(cè)試代碼打印出來(lái)，執(zhí)行試一試。

print(code_output)

輸出結(jié)果：

import pytest  # used for our unit tests



def format_time(seconds):
    minutes, seconds = divmod(seconds, 60)
    hours, minutes = divmod(minutes, 60)

    if hours > 0:
        return f"{hours}h{minutes}min{seconds}s"
    elif minutes > 0:
        return f"{minutes}min{seconds}s"
    else:
        return f"{seconds}s"



#Below, each test case is represented by a tuple passed to the @pytest.mark.parametrize decorator.
#The first element of the tuple is the name of the test case, and the second element is the value to be passed to the format_time() function.
@pytest.mark.parametrize('test_input,expected', [
    ('0', '0s'),
    ('59', '59s'),
    ('60', '1min0s'),
    ('119', '1min59s'),
    ('3600', '1h0min0s'),
    ('3601', '1h0min1s'),
    ('3660', '1h1min0s'),
    ('7200', '2h0min0s'),
])
def test_format_time(test_input, expected):
    #For each test case, we call the format_time() function and compare the returned value to the expected value.
    assert format_time(int(test_input)) == expected



#We use the @pytest.mark.parametrize decorator again to test the invalid inputs.
@pytest.mark.parametrize('test_input', [
    None,
    'abc',
    -1
])
def test_format_time_invalid_inputs(test_input):
    #For each invalid input, we expect a TypeError or ValueError to be raised.
    with pytest.raises((TypeError, ValueError)):
        format_time(test_input)

看看自動(dòng)生成的測(cè)試幫我們抓了什么 Bug

我們可以把對(duì)應(yīng)生成的代碼，單獨(dú)復(fù)制到一個(gè) auto_unit_test.py 文件里面。然后去命令行里執(zhí)行一下 pytest 這個(gè)命令，看看結(jié)果是怎樣的。我這里，對(duì)應(yīng)的會(huì)有一個(gè)測(cè)試用例失敗，就是當(dāng)輸入是 -1 的時(shí)候，測(cè)試用例預(yù)期會(huì)遇到一個(gè) TypeError 或者 ValueError 的報(bào)錯(cuò)，但是實(shí)際并沒(méi)有。

我們可以試著在 Notebook 里面調(diào)用一下 format_time(-1)，看看自動(dòng)化測(cè)試跑得對(duì)不對(duì)。

format_time(-1)

輸出結(jié)果：

'59min59s'

可以看到，輸入 -1 的時(shí)候，輸出變成了 59min59s，看來(lái) AI 生成的測(cè)試代碼的確幫我們捕捉到了一個(gè) Bug。

小結(jié)

到這里這一講也就結(jié)束了。我們也有了一段完整的，可以針對(duì)一個(gè) Python 函數(shù)生成一整套自動(dòng)化測(cè)試的功能了，而且它還真的幫我們抓到了一個(gè) Bug。生成整套測(cè)試代碼的過(guò)程里，我們不需要人工地復(fù)制粘帖任何內(nèi)容，全都是代碼自動(dòng)完成的，是一個(gè)“自動(dòng)檔”的過(guò)程。

之所以能做到這一點(diǎn)，是因?yàn)槲覀兦擅畹乩昧艘粋€(gè)方法，就是將一個(gè)問(wèn)題，拆分成多個(gè)提示語(yǔ)的步驟，循序漸進(jìn)地讓 AI 通過(guò)解釋代碼，構(gòu)造測(cè)試用例，最后再根據(jù)代碼的解釋和設(shè)計(jì)的測(cè)試用例，生成最終的自動(dòng)化測(cè)試。

多步提示語(yǔ)帶來(lái)的一個(gè)好處，就是我們的內(nèi)容是更加有條理、有邏輯的，也更符合我們平時(shí)寫(xiě)文字的方式，而不是一股腦地把各種要求都放在提示語(yǔ)的開(kāi)頭，這在解決復(fù)雜問(wèn)題時(shí)往往效果不好。

此外，我們這里使用的提示語(yǔ)也非常重要。正是因?yàn)槲覀兡軌蚍植襟E提示 AI，所以我們能在拿到代碼的解釋之后，讓 AI 考慮各種邊界條件。而 AI 也很給力，給出 -1、None 這樣的特殊輸入，讓我們的測(cè)試代碼最終真的抓住了程序里的 Bug。

回過(guò)頭來(lái)看，如果我們只是直接把代碼往 ChatGPT 里一貼，雖然也能生成測(cè)試用例，但是那些測(cè)試用例就比較欠考慮，不會(huì)涵蓋各種邊角的情況。

思考題

這一講的代碼有點(diǎn)長(zhǎng)，思考題部分需要做的事情也多一些。

1. 可以試著減少我們的提示語(yǔ)或者提示步驟，看看生成的測(cè)試用例有什么樣的變化。

2. 目前我們的代碼，是過(guò)程式地一步步給你演示整個(gè)測(cè)試代碼是如何生成的。如果語(yǔ)法檢查出錯(cuò)了，其實(shí)我們應(yīng)該要從頭開(kāi)始重試一遍，再生成測(cè)試代碼。你可以試著把整個(gè)代碼封裝修改，變成一個(gè)會(huì)自動(dòng)重試 3 次的函數(shù)。讓我們可以直接調(diào)用，來(lái)為 Python 代碼生成自動(dòng)化測(cè)試。

3. 我們這一講里的提示語(yǔ)是借鑒的 OpenAI Cookbook 里的樣例，你能不能自己嘗試總結(jié)一下，這些提示語(yǔ)有哪些值得借鑒的常用方法？

推薦閱讀

之所以我們要循序漸進(jìn)地提示 AI，讓 AI 生成例子再生成代碼，是因?yàn)楝F(xiàn)在的大語(yǔ)言模型，有一種叫做“思維鏈（CoT）”的能力。當(dāng)我們給出更詳細(xì)的推理步驟的時(shí)候，AI 的表現(xiàn)會(huì)更好。在 OpenAI Cookbook 里，專門(mén)有一章講解思維鏈能力，可以去好好研讀一下。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-831994.html

到了這里，關(guān)于13 ｜讓AI幫你寫(xiě)測(cè)試，體驗(yàn)多步提示語(yǔ)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！