作品集打造：启动、打磨与呈现

开场钩子

选好项目后，第一步不是写代码，而是把选题时的调研变成看得见的计划——一个"可辩护"的项目。然后按"别人能看懂、能跑起来、能和你讨论"的标准打磨。这节课覆盖从建 repo 到面试深挖的全流程。

一、启动：先建计划，再写代码

仓库初始结构：

README.md
PROJECT_PLAN.md
src/
tests/
evals/
data/
.env.example

只建你真会用的目录。data/ 放样例数据或说明；不提交私有数据、凭据、条款不明的爬取内容。

把证据存进计划：目标领域、目标公司、JD 链接、公司博客、产品文档、公开数据集——用链接，别用模糊备注。这让项目可辩护：你能展示它为什么存在。

PROJECT_PLAN.md 骨架：领域 → 目标公司 → 证据（JD/博客/文档/数据链接）→ 问题（用户/输入/输出/失败模式/成功判据）→ 项目候选 → 选定项目。然后是构建计划：V1 范围、要展示的技术（LLM/RAG/agent/评估/测试/监控/部署）、架构、数据、评估、测试、监控、demo、README 要点。这一步用 AI 辅助没问题——但结果要对照你收集的 JD、博客、数据逐项核对。

界定 V1 必须做 / 不做：

必须：摄入一个小数据集；从 CLI/API/简单 UI 可运行；产出一种有用输出；处理一个正常用例 + 一个失败用例；测试与评估可从文档命令运行。 不做（示例）："V1 不支持多用户、流式响应、自动更新工单。它产出一份供人审核的草稿回复。"

初始技术栈用无聊的工具，除非某个工具能教你需要的技能：Python + FastAPI/Flask/Streamlit/CLI + SQLite/Postgres/文件；只在检索真需要时上向量库；pytest 测确定性行为 + 小评估脚本测 AI 行为；日志记模型调用、工具调用、成本、延迟。先建通一条端到端路径：样例输入 → 处理 → 模型调用/检索 → 校验 → 输出。别从仪表盘、账号体系、多提供方、复杂 agent 图开始。

二、打磨：三个支柱

README 是第一读者。要回答：解决什么问题？给谁用？输入什么？输出什么？怎么跑？怎么跑测试和评估？评估显示了什么？什么失败过/变过？重要文件在哪？首屏放：一段话摘要 + demo 截图/GIF/视频 + 安装/运行/测试/评估四条命令。别写营销文案——工作本身就是信号。

测试测确定性行为：解析器、分块、路由、schema 校验、API 响应、拒答规则、格式化。一条命令能跑（pytest），可以加个跑测试的小 GitHub Actions。

评估测 AI 行为。从 20–50 例开始，覆盖：易例、脏例、超范围请求、应拒答例、（需要来源时的）引用例。指标跟项目类型走：RAG 看答案相关性与引用正确性；抽取看字段准确率与 schema 合法性；agent 看工具选择准确率与任务成功率；多步系统看延迟、token、成本；安全敏感任务看拒答正确性。评估结果存进仓库（如 evals/results/2026-06-29.json）。

日志从本地文件起步：请求 ID、模型名、提示词版本、检索到的来源、工具调用、校验错误、延迟、token、成本、反馈。本地 JSONL 够用——只要你能打开它并讲出你从中学到什么。

Demo 选一种形态：live URL / 短录屏 / 截图 / 终端录制 / README 里的样例输入输出。别只依赖脆弱的 live demo。

分享前终检：README 讲清问题与用户；干净 clone 能跑起来；有 .env.example；测试过；评估命令能跑；样例数据合法可分享；没提交凭据；重要文件从 README 链接得到；局限写得诚实。

三、呈现：三种场合三种讲法

60 秒 pitch（"讲个你做过的项目"）：

我为小型 SaaS 团队做了一个工单分诊助手。它接一张新工单，检索相似历史工单和计费政策片段，起草带引用和升级标记的分类回复。我先写项目计划，再建了 API、检索流、评估集和 CI 检查。第一版在 50 个标注样例上 34 个胜过关键词检索基线，但在计费边界用例上仍会失败——我为这些用例加了拒答规则和回归测试。

结构：问题 → 用户 → 方案 → 证据 → ownership。给面试官"钩子"，别罗列库清单。

深挖（对应面试的项目深挖轮）：按 问题与用户 → 输入输出 → V1 → 架构 → 决策 → 评估 → 测试与监控 → demo 与影响 → 下一步 的顺序讲，每段停顿，当对话讲。

解释决策的句式：

我选 X 而不是 Y，是因为约束 Z。代价是 A。我接受它，因为 B。如果项目长大，我会改 C。

弱："我用了向量数据库。" 强："我先用关键词搜索当基线，前 50 个评估样例里 11 个同义改写的计费问题没搜到，所以加了向量搜索并保留关键词搜索做兜底。"

讲失败：每个失败按"什么坏了 → 怎么发现 → 改了什么"讲。好素材：第一个提示词回答超出了检索上下文；分块弄断了引用；评估集暴露了缺失的拒答用例；agent 在确定性代码就够时调了工具；live demo 太慢/太贵；UI 藏了日志里一目了然的错误。一个清晰的失败故事，常比一份打磨过的功能清单更能展示判断力。

讲 impact 时可以谦虚，这些全是强证据：评估优于基线；延迟或成本下降；有用户试过 demo；自动化了你自己的部分工作；甚至——项目证明了原始想法应该停掉。"效果不够好，但我能解释为什么"好过假装 demo 解决了一切。

Ownership 要精确："我写了计划、定了 V1、建了评估集"；"课程给了大任务，但领域、数据、架构、测试是我选的"；"队友做了 UI，我做了 API、检索和评估工具"；"AI 编码助手写了样板代码，但评审、测试、以及评估失败后的设计修改是我做的"。别把教程或小组项目说成独立作品，也别低估自己真实做过的决策。

对 FDE 的启示（1444 对标）

• T4 集成部署与安全运维：V1 界定法（必须/不做）+ 终检清单就是小型 AI 系统的交付规格——FDE 给客户做 PoC 时照此执行，避免"demo 很惊艳、上不了生产"。
• D4 知识沉淀与反哺复用：PROJECT_PLAN 的"证据链 + 决策记录"模式 = FDE 项目的过程资产模板；每次驻场交付都该留下一份能让下一个人接手的 repo。
• D3 价值验证与运营迭代："评估结果存进仓库 + 胜过基线"的呈现方式，就是给客户的验收报告模板——价值验证要落到可复跑的数字，不是截图。
• D2 沟通翻译与预期管理：60 秒 pitch 的五要素（问题→用户→方案→证据→ownership）同样适用于客户高层汇报。

本课自测

1. V1 的"必须做"清单有哪六条？"不做"清单为什么同样重要？
2. 测试与评估各测什么？评估集起步要覆盖哪五类样本？
3. 写出解释决策的四段句式，并用它重写一个你做过的技术选择。
4. 哪些东西可以当"强证据"？为什么"项目证明原想法该停"也算？