7.8.3 项目：交付材料包

一个大模型项目最后并不只是“能跑”。

更重要的是：

别人能不能看懂目标、复现结果、检查评测，并从你停下的地方继续做下去？

项目交付材料包

最终包里应该有什么

一个合格的大模型项目包，至少应该包含：

README.md
一条可复现的运行命令
示例输入和输出
评测记录
一条失败案例分析
截图或图表
后续计划

这是一套最小集合，能让项目自己站住。

最容易检查的目录结构

这个结构故意做得很简单：

README.md 负责讲故事
examples/input-01.json 和 examples/output-01.json 证明任务存在
reports/evaluation.md 和 reports/failure_cases.md 证明评测和失败分析
screenshots/run-01.png 和 screenshots/before-after.png 证明项目真的跑过
src/ 保存可运行代码

可以直接复用的 README 模板

把下面这个提纲复制走，再填入你自己的项目内容。

# 项目名称

## 1. 目标
这个项目解决什么问题？

## 2. 任务范围
什么在范围内，什么不在范围内？

## 3. 基线
你先和什么最简单的方法做了比较？

## 4. 数据
数据从哪里来？一共有多少样本？

## 5. 评测
你用了哪些指标或人工检查？

## 6. 结果
哪里变好了？哪里还不行？

## 7. 失败案例
展示一条真实失败，并解释原因。

## 8. 运行方式
别人怎样复现结果？

## 9. 后续计划
下一步你准备改什么？

一个实用的评测记录模板

如果你的项目有固定测试集，可以把结果整理成这样的表：

案例	结果	备注
001 退款请求	领域化回答通过	比泛化 baseline 更完整地覆盖政策点
002 地址修改	规则化回复通过	结构比 baseline 更清楚
003 发票问题	新方法未通过	仍漏掉关键细节，需要补数据

这样以后对比版本会很方便。

一个真正有用的失败笔记模板

不要只写“模型不好”。

要写成这样：

# 失败案例：JSON 字段缺失

- 现象：输出有时会在 JSON 前面多加一段解释。
- 线索：长提示词时更容易出现。
- 怀疑原因：Prompt 对输出格式约束不够强。
- 排查方式：对比不同 Prompt 版本，查看原始输出。
- 修复动作：增加严格的 schema 提醒和短示例。
- 回归检查：再跑一遍固定测试集。

一条这样的笔记，往往比十张截图更有价值。

运行一次交付包完整性检查

在你说项目结束之前，把这个小脚本放到项目根目录，命名为 check_package.py：

from pathlib import Path

required = [
    "README.md",
    "examples/input-01.json",
    "examples/output-01.json",
    "reports/evaluation.md",
    "reports/failure_cases.md",
]

missing = [item for item in required if not Path(item).exists()]

if missing:
    print("missing:")
    for item in missing:
        print("-", item)
    raise SystemExit(1)

print("package_ready=true")
print("checked_files=", len(required))

运行：

python check_package.py

交付包完整后的预期输出：

package_ready=true
checked_files= 5

这个脚本不判断模型好不好，它只检查评审者是否拿到了复现和检查项目所需的最小材料。

好的交付长什么样

交付时，别人应该能很快回答三个问题：

这个项目解决什么问题？
我怎么复现它？
为什么这个方案比基线更好？

如果这三个问题都很容易回答，这个项目就适合放进作品集或团队评审。

最终检查清单

在关闭项目之前，检查这些项目：

README 是否说明了目标和范围
运行命令是否可用
基线和新方法是否都有展示
评测集是否固定
是否至少有一条失败案例
是否有截图或图表
是否写了后续计划

预期结果：别人打开这个包后，可以运行命令、检查示例和评测表，并在不追问缺失上下文的情况下理解下一步动作。

留下的证据

学完这一页，至少保留这张证据卡：

文件夹: prompts、evals、outputs、数据说明、README
运行命令: 如何复现结果
指标表: 基线结果和改进结果
失败备注: 已知薄弱案例和下一步动作
已准备审查: 其他人无需再问你就能检查证据

项目复盘要点与通过标准

好的交付包不依赖现场演示：README、固定评测表、失败备注和重跑命令应该自己讲清楚故事。
评测表要和基线对比，而不是只展示最终版本。否则评审者看不出到底改进了什么。
即使结果不错，也保留一条失败案例。它能说明你知道边界，也给下一个维护者留下入口。
当别人能在十分钟内复现运行，并说出下一步改进点时，本页就算通过。

总结

一个好的大模型项目，不只是一个能跑的脚本。

它还应该是一个可以被理解、被复现、被评测、被继续扩展的包。

当你能做到这些时，你就不只是“在学技术”了。你是在做别人真的能接着用的东西。