作品集与结业自查
学完之后手上有什么、怎么组织成面试官看得懂的仓库、简历怎么写
先说清楚:这里没有结业证书
自己发的课程证书在求职上几乎没有价值。面试官不会因为一张图给你加分,他只看两样东西:你的仓库能不能跑,以及你能不能讲清楚为什么这么设计。
所以这一页给的是作品集组织方法和能力自查表,不是证书。真要说有什么东西能当"结业凭证",那就是下面这个仓库本身。
你手上应该有什么
走完程序员基础版十周,这些东西是自然产出的,不需要额外做:
| # | 产出 | 来自 | 面试价值 |
|---|---|---|---|
| 1 | Agent OS 仓库(可运行、有测试、可部署) | 全程 | ★★★ 唯一硬通货 |
| 2 | ADR:为什么 Harness-first、否决了什么 | 第 1 周 | ★★★ 能拿出 ADR 的候选人极少 |
| 3 | 两个 Provider 的配对基准报告 | 第 2 周 | ★★★ 证明你做过量化选型 |
| 4 | Tool Runtime 红队测试(六条攻击路径) | 第 3 周 | ★★★ 安全意识的硬证据 |
| 5 | Native Harness + 20 条测试 + 事件快照 | 第 4 周 | ★★★ 技术含量最高的部分 |
| 6 | Chunk 尺寸对照实验报告 | 第 5 周 | ★★ 有数据的调优 |
| 7 | RAG 评测报告(含五道必须答不出来的题) | 第 6 周 | ★★★ 大多数人没测过拒答 |
| 8 | Native vs Mastra 九维度对照报告 | 第 7 周 | ★★★ 证明你能选型不只会执行 |
| 9 | 恶意 MCP Server 实验报告 | 第 8 周 | ★★★ 几乎没人想过这个攻击面 |
| 10 | 压测报告 + 事故复盘 Postmortem | 第 10 周 | ★★★ 真实故障经历极稀缺 |
| 11 | Runbook(五个故障场景) | 第 10 周 | ★★ 运维成熟度 |
打三星的那七项是差异化来源。 会搭一个 Agent 的人很多,能拿出配对基准、红队测试、拒答实验、事故复盘的人非常少。这几份文档的价值高于代码本身。
程序员进阶版再补:Pi 源码对照报告、Session 压缩保真度报告、framework exit drill 记录(抽签砍掉一个 Adapter 的耗时与能力缺口)、Multi-Agent 对照实验、模拟听证会记录。
仓库怎么组织
面试官打开你的 GitHub,平均停留时间不到两分钟。这两分钟里他要能判断出你值不值得约面。
agent-os/
├── README.md ← 90% 的注意力在这里
├── docs/
│ ├── architecture.md 系统图 + 容器图 + 威胁模型
│ ├── decisions/ ADR,按编号
│ ├── reports/ 所有实验和对照报告
│ └── runbook.md
├── packages/ 按周次演进的模块
├── examples/ 可跑的 Demo
└── .github/workflows/ CI 配置,证明测试真的在跑两个细节容易被忽略但很加分:CI 徽章(证明测试真在跑,不是躺着的)和 reports/ 目录(一眼看到你做过多少实验)。
README 模板
这是唯一必须写好的文件。照下面这个骨架填,不要写成技术文档:
Agent OS 仓库 README 骨架
作品集 · 直接抄走改
# {项目名} > 一句话说清这是什么、解决什么业务问题。不要写「基于 LLM 的智能 Agent 平台」这种,写「日本电商商品上架自动化,把人工 40 分钟的流程压到 5 分钟人工确认」。   ## 它能做什么 {三条,每条一句话,带可验证的结果} ## 30 秒看懂架构 {一张架构图。图比一千字有用} 原生模型协议 → Native Harness → RAG → Mastra Runtime → 生产治理 ## 快速跑起来 ```bash pnpm install docker compose up -d pnpm test pnpm dev ``` {必须真的能跑。面试官会试,跑不起来直接出局} ## 三个关键设计决策 1. **{决策}** — 为什么这么选,否决了什么方案,依据是什么 2. **{决策}** — 同上 3. **{决策}** — 同上 完整记录见 [docs/decisions/](./docs/decisions/) ## 实测数据 | 指标 | 数值 | 怎么测的 | | --- | --- | --- | | {比如 Provider 配对成功率} | {数字} | [报告链接] | | {比如 Rerank 前后 Recall@5} | {数字} | [报告链接] | | {比如 100 并发下 P95 延迟} | {数字} | [压测报告] | ## 踩过的坑 {两三条真实的失败和修复过程。这一节比"特性列表"有价值得多} ## 还没做的 {诚实列出边界。写这一节的人比不写的人可信}
「还没做的」这一节是反直觉但有效的。 它显示你知道自己的系统边界在哪,而不是以为自己做完了。面试官看到这一节,追问的方向会从"挑刺"变成"讨论"。
简历怎么写这个项目
不要写技术栈罗列。用结果导向的三句话结构:
大多数人这样写
技术栈:TypeScript、Mastra、LangGraph、PostgreSQL、Redis、pgvector
负责 Agent 核心逻辑开发与 RAG 系统搭建
换成这样写
通过统一 Policy 层将高风险操作拦截率提升到 100%,红队六条攻击路径全部阻断
建立 CI 评测门禁,线上回归缺陷下降 X%;100 并发压测 P95 延迟 Xms,单次 Run 成本 X 元
右边每个数字都来自你的报告,不要编。数字编错了,面试官追问细节时会当场露馅,比不写数字更糟。
三句话分别对应:做了什么系统、解决了什么具体问题、量化结果是什么。
结业自查
不看答案,用自己的话回答。答不上来的条目,回去补对应的周次。
四层预算(步数、Token、成本、时间)加三层检测(去重、循环检测、Validator)。能说出每层阈值怎么定的更好。
对应第 4 周。
拦在 Executor 层。工具会有几十个,靠每个自觉检查一定会漏。
对应第 3 周。
要能说出无答案检测的阈值和实测行为,最好有那五道必须答不出来的题的结果。能稳定说不知道比多答对几题更有商业价值。
对应第 6 周。
Trace Explorer,三次点击以内:找到失败的 Run、展开执行树、看具体错误和输入输出。需要跨系统拼日志说明关联字段没打全。
对应第 9 周。
高分答法是先承认防不住,再讲权限层兜底:输入侧检测但不指望它、外部内容标记不可信、工具权限最小化、高风险操作强制审批。声称能百分百防住会被扣分。
对应第 9 周。
必答题,答不上来说明没反思。参考方向:事件协议应该更早版本化、评测集应该第 5 周就开始建而不是第 9 周。
对应第 10 周。
八条全能答上来,你的准备程度已经超过绝大多数候选人。 答不上来三条以上,先别投简历,回去补。
30 分钟答辩结构
同样适用于面试的项目介绍环节:
| 时间 | 内容 | 目的 |
|---|---|---|
| 0–3 分钟 | 业务场景与要解决的问题 | 证明你从需求出发不是从技术出发 |
| 3–8 分钟 | 整体架构图讲解 | 建立全局认知 |
| 8–18 分钟 | 三个最难的技术决策,各讲清备选方案和否决理由 | 核心得分段 |
| 18–25 分钟 | 现场 Demo:steering / follow-up / cancel / approval | 证明真的能跑 |
| 25–30 分钟 | 踩过的坑与故障复盘,以及下一步计划 | 展示成长性和诚实度 |
8 到 18 分钟这一段决定成败。面试官最想听的不是你用了什么,是你否决了什么以及为什么。