选题、做完、写清楚

这门课的第一部分，我们一起做了 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 反而让人难以信任。