作品集验收清单
这份清单用于检查你的阶段项目或毕业项目是否已经从“练习代码”升级为“可以展示的作品”。作品集项目不一定要功能很多,但必须能运行、能解释、能评估、能复盘。
一分钟快速检查
如果时间很少,先检查这 8 项:项目有没有 README,README 里有没有运行命令,别人能不能按命令跑起来,有没有示例输入输出,有没有截图或演示,有没有评估方式,有没有失败样本,有没有下一步计划。
只要这 8 项 缺了 3 项以上,项目通常还不适合放进作品集。它可能是一个有用练习,但还没有形成可展示成果。
README 检查
| 检查项 | 合格标准 |
|---|---|
| 项目背景 | 能说明用户是谁、问题是什么、为什么需要 AI |
| 功能清单 | 能列出已经完成的功能,而不是只写计划 |
| 运行方式 | 有明确命令、依赖安装方式和环境说明 |
| 示例输入输出 | 至少给出 1 到 3 个真实样例 |
| 项目结构 | 能解释主要目录和文件的作用 |
| 技术选择 | 能说明为什么使用当前模型、框架、数据库或工具 |
| 已知限制 | 主动说明系统不擅长什么、哪些场景还没覆盖 |
| 下一步计划 | 有具体迭代方向,而不是泛泛写“继续优化” |
README 的目标不是写得很长,而是让别人不用问你也能理解项目。尤其是运行方式和示例输入输出,必须具体到可以复现。
可复现性检查
| 检查项 | 合格标准 |
|---|---|
| 依赖记录 | Python 项目有 requirements 或 pyproject,前端项目有 package.json |
| 配置说明 | API Key、模型名称、路径、端口等配置有说明 |
| 数据说明 | 示例数据来源、格式和字段含义清楚 |
| 最小运行命令 | 有一条命令能跑通最小闭环 |
| 错误处理 | 常见缺依赖、缺 key、缺文件错误有提示 |
| 环境隔离 | 不依赖个人电脑上的隐藏路径或临时文件 |
如果项目只能在你自己的电脑上运行,就还不算作品集项目。作品集项目至少应该让别人能根据 README 复现最小版本。
AI 能力检查
| 项目类型 | 需要检查什么 |
|---|---|
| 机器学习项目 | 是否有 baseline、训练/测试划分、指标、错误样本分析 |
| 深度学习项目 | 是否有训练日志、验证指标、训练曲线、过拟合分析 |
| Prompt 项目 | 是否记录 Prompt 版本、输入输出样例、失败案例和改进过程 |
| RAG 项目 | 是否有文档来源、切分策略、检索结果、引用检查和评估问题集 |
| Agent 项目 | 是否有工具定义、执行轨迹、停止条件、权限边界和失败恢复 |
| 多模态项目 | 是否说明输入格式、生成/理解流程、人工审核和质量标准 |
不同类型项目的验收重点不同。不要用同一套标准检查所有项目。RAG 项目的核心不是界面漂亮,而是检索和引用可靠;Agent 项目的核心不是步骤很多,而是执行可追踪、权限可控制。
工程化检查
| 检查项 | 合格标准 |
|---|---|
| 日志 | 能 看到关键请求、模型输出、工具调用或错误信息 |
| 参数配置 | 模型、路径、阈值、检索数量等关键参数可配置 |
| 模块拆分 | 数据处理、模型调用、业务逻辑、评估代码不要全部混在一起 |
| 测试样例 | 至少有固定样例用于回归检查 |
| 成本意识 | 对 token、延迟、调用次数或资源消耗有基本记录 |
| 安全边界 | 高风险工具调用、文件写入、外部请求等有控制 |
工程化不等于把项目做复杂,而是让项目更稳定、更容易排查、更容易继续迭代。一个结构清晰的小项目,比一个难以复现的大项目更适合作品集。
评估与复盘检查
| 检查项 | 合格标准 |
|---|---|
| 测试集 | 有固定问题、样本或任务列表 |
| 指标 | 至少有一种能衡量效果的方式 |
| 成功样本 | 展示系统在哪些场景表现好 |
| 失败样本 | 展示系统在哪些场景失败,并说明原因 |
| 边界样本 | 展示系统在模糊、长输入、缺信息或异常输入下的表现 |
| 改进计划 | 根据失败原因提出具体下一步 |
不要害怕写失败样本。作品集项目里,失败样本和复盘经常比成功截图更有价值,因为它们能证明你真的理解系统边界。