選題、做完、寫清楚

這門課的第一部分，我們一起做了 RepoBot：一個給 httpx 答疑的助手，從 v1 的命令列聊天程式，一直做到 v4 的網頁服務，有檢索、有智慧體、有評估、有護欄。

畢業專案是讓你獨立地再走一遍這條路，只是這次題目由你自己定。這一課不教新的技術，講的是怎麼把一個專案真正做完。

選題

一個好的畢業專案題目，滿足這幾個條件：

• 你自己或者身邊的人真的會用。有真實的使用者，你才知道它好不好用，也才有動力做完。
• 有明確的對錯。答案對不對、分類準不準、抽取的欄位全不全，能檢查。"寫一首好詩"這種題目很難評估，不適合作畢業專案。
• 兩到四周能做完第一個能用的版本。寧可做小，也要做完。
• 資料你拿得到，也有權使用。公開的文件、自己的筆記、開源的資料集都可以。公司內部的資料，先確認能不能用、能不能放進 API。

幾個可以參考的方向，每個都對應課程裡的某幾個模組：

题目                                    主要用到
给你常用的一个开源库做答疑助手          RAG（04）、评估（06）
读懂一个代码仓库、回答"这个函数在哪里   智能体和工具（05）、MCP（05 第 7 课）
被调用"的助手
从简历、合同、发票里抽取固定字段        提示词和 JSON 输出（02）、评估（06）
把客服工单自动分类，并给出建议回复      提示词（02）、模型评委（06），可能用到微调（10）
在某个领域的文字上训练一个小模型        第 09 模块，外加第 08 模块第 6 课的过拟合检查
（比如宋词、对联、自己的聊天记录）

不要選"做一個通用的 AI 助手"這種題目。它沒有邊界，永遠做不完，也沒法評估。

第一步：寫下做完的標準

動手之前，先寫一個 GOAL.md，只回答三個問題：

1. 給誰用，解決什麼問題。一句話。
2. 做完是什麼樣子。寫成可以檢查的幾件事，就像這門課每個模組開頭的"學完的標準"。比如："能回答 httpx 文件裡的使用問題，20 道評估題答對 16 道以上，每個回答帶出處""平均每個問題的花費不超過 0.01 元"。
3. 明確不做什麼。比如"不支援上傳圖片""只支援中文"。

這個檔案決定了你的專案什麼時候算完成。沒有它，專案很容易越做越大，最後什麼都沒做完。第 07 模組第 3 課講過同樣的道理：先定驗收標準，再動手。

第二步：先做評估集

在寫任何功能程式碼之前，先準備 20 到 50 道評估題。

這聽起來本末倒置，但它是整個專案裡最重要的一步（第 06 模組第 1 課）：

• 寫題目的過程會逼你想清楚，使用者到底會問什麼，什麼樣的回答算好。
• 有了評估集，每做一個改動，都能用一條命令知道效果是變好了還是變壞了。
• 最後寫 README 時，你有真實的數字可以寫，而不是"效果很好"。

題目要覆蓋正常的問題，也要有邊界情況、應該拒絕回答的問題、以及可能被濫用的輸入（第 06 模組第 5 課）。

第三步：做出最簡單的能用版本

先用最簡單的辦法做一個版本，跑一遍評估集。

RepoBot 的 v1 故意不查任何資料，就是為了看清楚"最簡單的辦法"能做到什麼程度，以及它在哪裡失敗。這些失敗告訴你下一步最該做什麼：如果它是因為不知道資料而答錯，加 RAG；如果是因為需要多步查詢而答錯，考慮智慧體；如果只是格式不穩定，先改提示詞。

不要一開始就用上所有學過的技術。第 05 模組第 1 課說過，能用簡單的工作流解決的問題，就不要用智慧體。每加一樣東西，都要有評估結果說明它確實讓效果變好了。

第四步：小步改進

之後的每一步：

1. 看評估結果裡失敗的題目，找出最主要的一類失敗。
2. 針對這一類失敗做一個改動。
3. 再跑一遍評估集，記下結果。
4. 用 git 提交，在提交資訊裡寫上評估結果的變化。

把每一步的評估結果記在一張表裡。寫 README 時，這張表就是最有說服力的內容：它說明了每一個設計決定都有理由。

版本    改动                          答对      平均花费/题   平均耗时
v1      直接问模型                    7/20      0.002 元      2.1 秒
v2      加上 RAG（向量检索）          13/20     0.004 元      3.0 秒
v3      改成混合检索 + 重排           16/20     0.004 元      3.4 秒

（上表是一個格式示例，不是真實的資料。你的表裡要填你自己跑出來的數字。）

第五步：上線前的檢查

如果你的專案要給別人用，對照第 06 模組檢查一遍：

• 金鑰沒有寫在程式碼裡，也沒有提交到 git。
• 有輸入長度限制和呼叫頻率限制，不會被人刷掉你的錢。
• 日誌裡能看到每個請求的步驟、耗時和花費，但不記錄使用者的敏感資訊。
• 有輸入和輸出的護欄，並且用評估集確認它沒有誤傷正常的問題。
• 如果用了智慧體，它能呼叫的工具的許可權是最小的（第 05 模組第 8 課）。

第六步：寫 README

一個專案做得再好，別人看不懂、跑不起來，就等於沒做。README 至少要有這些：

• 一句話說明：它是什麼，給誰用。
• 效果：一兩個真實的使用例子（真實執行的輸出，不要編造），加上評估結果的表。
• 怎麼執行：從克隆程式碼到看到結果的完整步驟，別人照著做一遍就能跑起來。要寫清楚需要哪些環境變數，大概花多少錢。
• 怎麼設計的：整體的結構，關鍵的幾個決定和理由（為什麼用 RAG 而不是微調，為什麼選這個模型）。
• 做不好的地方：評估集裡還答錯的題目是什麼型別的，已知的限制。

最後一項最容易被省略，但它是最能體現你水平的部分。能清楚地說出自己的系統在哪裡會出錯，說明你真的理解了它。第 06 模組的 RepoBot v4 就在 README 裡列出了"上線前還缺哪些東西"。

寫完之後，找一個沒見過這個專案的朋友，請對方只看 README 把專案跑起來。對方卡住的每一個地方，都是 README 需要改的地方。

講給別人聽

最後，試著用五分鐘向別人講你的專案。可以借用 Start AI Engineering 課程總結的一套問題來組織（第 03～06 模組的專案課結尾也用過）：

1. 它解決的是什麼問題？誰在用？
2. 輸入是什麼，輸出是什麼？
3. 為什麼選擇這個方案，而不是更簡單或者更復雜的？
4. 你怎麼知道它好不好？數字是多少？
5. 每次呼叫花多少錢、多長時間？
6. 它會在哪裡出錯？出錯了會怎樣？

能把這六個問題回答清楚，你就不只是"會呼叫大模型"，而是能獨立做出一個可靠的 AI 應用了。這也是這門課從第一課開始想要帶你到達的地方。

練習

1. 寫下三個候選題目，按本課"選題"的四個條件給每個打分，選出一個。
2. 為你選的題目寫 GOAL.md 和至少 20 道評估題，然後再開始寫程式碼。
3. 做完之後，把 README 交給一個沒見過這個專案的人，記錄對方在哪些地方卡住了，並修改 README。

自測

1. 為什麼要在寫功能程式碼之前先準備評估集？

寫評估題會逼你想清楚使用者會問什麼、什麼樣的回答算好；有了它，每個改動都能用一條命令判斷效果是否變好；最後寫 README 時也有真實的數字。沒有評估集，就只能憑几個例子的感覺判斷，很容易誤判。

2. 為什麼建議先做一個最簡單的版本，而不是一開始就用上 RAG、智慧體這些技術？

最簡單的版本能告訴你問題到底出在哪裡：是缺資料、需要多步操作，還是隻是格式不穩定。根據失敗的原因再選技術，每加一樣東西都用評估結果證明它有用，避免把系統做得不必要地複雜。

3. README 裡為什麼要寫"做不好的地方"？

它告訴使用者在什麼情況下不能依賴這個系統，避免誤用；也說明作者真正理解自己的系統，知道它在哪裡會出錯。只寫優點的 README 反而讓人難以信任。