面试三件套 II — 作品集三件套改写与 45min POC 演练

日期: 2026-10-10 阶段: Phase 4 - 自建 Agent 平台×求职冲刺 标签: #portfolio #three-piece-narrative #poc-demo

核心问题

Day 117 把面试白板的八域和 roleplay 准备好了。但面试官在见你之前，先看的是作品集本身——而 2026 的招聘经理「spend more time on your GitHub than your resume」，且「prioritize developers who have shipped AI systems that work under real conditions — not demos that survive a Tuesday afternoon presentation」（2026 招聘口径）。本计划的三大作品（AML Copilot / agent-arch lab / dsdb-lab）笔记数高达 120 篇，但招聘经理不看笔记数。今天回答三个问题：

1. 作品集叙事怎么改？ 本计划立的铁律是「产品结果 + eval 数字 + 单位成本」三件套。要把每个作品的 README 从「我做了什么」改写成「它达成了什么结果、eval 数字是多少、单位成本是多少」。
2. 45min POC 怎么演？ SA/FDE 面试常有现场或 take-home 的 POC（Proof of Concept）环节——45 分钟搭一个能跑的小 agent，证明你能在客户现场快速交付。
3. demo 视频怎么录？ 「Recording a 2-minute Loom video ... showing terminal output, and explaining one interesting failure you encountered and how you fixed it puts you ahead of 90% of applicants」（2026 口径）。讲述稿怎么写。

核心是把 120 天内功，压缩成招聘经理 5 分钟能看懂、且看了就想约面的形态。

关键内容

A. 三件套叙事模板：产品结果 + eval 数字 + 单位成本

2026 的招聘经理评作品集，看的是「production signals — how you handle failures, structure data, connect systems, and ship working software, not just a Jupyter notebook with model.predict()」（2026 口径）。本计划的三件套铁律正是为此设计。每个作品的 README 顶部必须是这个结构（而非技术栈罗列）：

# <作品名> — 一句话产品定位

## 它达成了什么（产品结果）
- 对谁、解决什么真实问题、上线/可演示状态

## eval 数字（证明它真的行）
- <任务指标>：recall / FPR / faithfulness / κ ...（带基线对比）
- <可靠性指标>：p95 延迟 / 成功率 / 漂移监控阈值

## 单位成本（证明它经济可行）
- $X / 案（或 / 千请求），token 分解，对比 build-vs-buy

## 怎么做的 + 一个有意思的 failure（证明你真撞过墙）
- 架构一图；一个踩坑 + 怎么修的

## 局限与 v2（诚实）
- 已知边界 + 下一步演进

三大作品逐个套进三件套（本计划真实作品，数字为实测/演练量级，投递前 W4 用实测回填）：

反直觉洞察①（招聘经理 5 分钟看 demo 和数字，不看笔记数）：本能会想「我写了 120 篇笔记，这是工作量证明」。但 2026 招聘经理「spend more time on your GitHub than your resume」，且对作品的判断在前 5 分钟看 README 顶部和 demo 视频时就已形成。120 篇笔记是内功，不是简历卖点——它们应折叠在仓库深处供深聊时调取，README 顶部必须是「结果+数字+成本」。叙事铁律：能跑的系统 + 三个数字 > 三百页文档。把笔记数当卖点是新手最大误区。

另一条 2026 强信号：「Two or three deep, well-documented projects with genuine evaluation work will outperform ten surface-level implementations every time」（agenticcareers 2026）。本计划恰好三大作品，每个都有 genuine evaluation——符合「深度三件 > 浅度十件」。叙事时主动收敛到三件，不堆砌边角 demo。

B. 45min POC 演练：客户现场快速交付的肌肉

SA/FDE 面试常考 POC：给一个客户场景，45 分钟搭出能跑的最小 agent。这考的不是「写得多全」，是「能不能在约束下交付一个有 eval 的可跑系统」。45min POC 的时间盒：

[0-5min  对齐] 确认任务、成功判据、可用工具。先写下「怎么算成功」
                ← 不写成功判据直接编码 = FDE 大忌（无法证明它行）
[5-10min 骨架] orchestrator + 1 个工具 + 1 个 guardrail，最小闭环跑通
[10-30min 主体] 接真实数据/工具，让它端到端产出一次结果
[30-40min eval] 写 3-5 条 golden case，跑出一个数字（哪怕 recall=3/5）
                ← 这一步是 90% 候选人跳过的，做了就赢
[40-45min 讲] 讲架构、讲那个数字、讲一个已知局限 + v2

POC 的最小可跑闭环（伪代码，现场能默写）：

def poc_agent(task, tools, golden):
    # 1) 成功判据先行
    success = lambda out: judge(out, task.rubric)  # 有判据才有 eval
    # 2) 最小 orchestrator 闭环
    for step in range(MAX_STEPS):            # bounded：防无限循环
        action = llm.plan(task, history)
        if not validate(action, tools): continue   # guardrail：参数校验
        result = sandbox(action)             # 沙箱执行
        history.append(result)
        if task.done(result): break
    # 3) 当场跑 eval，给一个数字
    passed = sum(success(poc_agent(g.task, tools, None)) for g in golden)
    return f"recall={passed}/{len(golden)}, steps≤{MAX_STEPS}"

反直觉洞察②（POC 写 eval 比写功能多加分）：候选人本能把 45 分钟全花在「让功能更全」，结果交一个没有任何数字证明的 demo。但 FDE/SA 的工作本质是「向客户证明这玩意儿真的行」——一个有 3/5 golden 通过的小 agent，胜过一个看着很全但无法证伪的大 agent。45min POC 留 10 分钟写 golden+跑数字，是最高 ROI 的时间分配。这直接呼应本计划 Phase 1 立的「eval 先行」。

C. demo 视频与讲述稿：2 分钟领先 90% 申请者

2026 口径：录一段 2 分钟 demo 视频，「showing terminal output, and explaining one interesting failure you encountered and how you fixed it puts you ahead of 90% of applicants」。讲述稿（voiceover script）的结构：

[0:00-0:20] 钩子：一句话产品定位 + 给谁解决什么真问题
            「这是给 AML 分析师的 SAR Copilot，把单案处理从 X 小时压到 Y 分钟」
[0:20-0:50] 跑给你看：真实跑一次，terminal/UI 出结果（不是 PPT）
[0:50-1:20] 三个数字：recall/FPR/κ、p95 延迟、$X/案 —— 屏幕上指出来
[1:20-1:50] 一个 failure：「这里我踩过坑——reflection 没封顶成本爆了，我加了 bounded 检查点」
[1:50-2:00] 收尾：v2 一句 + 仓库链接

讲述稿三条铁律：

• show, don't tell：必须真实跑一次出结果，不能截图/PPT。2026 招聘经理专门防「demos that survive a Tuesday afternoon presentation」——录屏跑通就是反「PPT 工程师」的证据。
• 数字要指着说：屏幕上把 recall、$X/案、κ 用光标圈出来念，比口播「效果很好」强十倍。
• 必讲一个 failure：这是 2026 明确的「领先 90%」动作。讲一个真坑 + 怎么修的，证明你在生产里趟过水。

量化对照（不同作品集形态的招聘经理反应）：

设计要点/决策表

对本项目的落地

• 改写三大作品 README 顶部：README.md（仓库根，AML Copilot 主作品）按 A 节模板重排——把现有技术栈段下移，顶部换成「产品结果 / eval 数字 / 单位成本 / 一个 failure / 局限」。eval 数字从 src/aml/evalBaseline.ts（recall/FPR 基线）和 src/aml/judgeCalibration.ts（κ）取；单位成本从 src/lib/Budget/CostMeter 取。agent-arch lab 与 dsdb-lab 各加一段 README 三件套头。
• 新建 docs/aipa/portfolio/three-piece-narrative.md：三大作品的完整三件套写法 + 投递用一页 pitch，作为「作品集主页」。把 120 篇笔记按 Phase 索引折叠在文末「深度档案」一节，供面试深聊调取——结构上明确「数字在前、笔记在后」。
• 新建 docs/aipa/portfolio/poc-playbook.md：把 B 节 45min 时间盒 + 最小闭环伪代码做成可现场默写的速查卡，golden case 模板复用 src/agent/eval/retrievalGolden.ts 的内嵌 golden 模式。POC 现场推理成本上限挂 Budget 守门。
• 录三段 demo 视频脚本：按 C 节讲述稿结构，为三大作品各写 2 分钟 voiceover script，存 docs/aipa/portfolio/demo-scripts.md。AML Copilot 的 failure 选「reflection 未封顶成本爆炸→加 bounded 检查点」（指 src/agent/durable/checkpointMachine.ts，与 Day 117 war story 同源，叙事一致）。
• 诚实标注：本笔记三件套表中的单位成本与 recall 数字为演练量级；README 改写时所有数字必须从实测取，标注采集日期；演练装置/视频中的示意数据须显式标「示意」。W4 用 AML Copilot 实测口径统一回填，禁止任何口头估值进入对外作品集。

参考资料

1. agenticcareers — 10 AI Agent Portfolio Projects That Will Get You Hired in 2026：README 含「what it does + 技术挑战 + demo 视频/live demo + documented evaluation results + honest limitations」；RAG 项目报 retrieval precision/recall + faithfulness + relevance；「two or three deep well-documented projects > ten surface-level」；DECISIONS.md 记录技术选型理由 (2026)
2. DEV Community / developia — 5 AI Portfolio Projects That Actually Get You Hired 2026 / The AI Hiring Revolution: Why Resumes Are Dead：招聘经理花更多时间在 GitHub 而非简历；优先 shipped under real conditions 而非「survive a Tuesday afternoon」；2min Loom 视频 showing terminal output + 一个 failure 领先 90% 申请者；README 写具体数字（如 p95 latency <200ms、错误率 <0.5%、CI <5min） (2026)
3. ai-infra-link — How Investors Evaluate Startup Engineering Teams in 2026：评估 capital efficiency（每单位产出的工程花费）；agentic 工具 usage-based token 成本 $200-$2,000+/工程师/月；ROI 计算须把 token 成本计入分母 (2026)
4. 本仓库 README.md / src/aml/evalBaseline.ts / src/aml/judgeCalibration.ts / src/lib/Budget / CostMeter / src/agent/eval/retrievalGolden.ts / src/agent/durable/checkpointMachine.ts（改写落点与数字来源）(2026-06)

SOTA 检查 (2026-06-11)

• 「shipped systems + eval 数字 + 单位成本」是 2026-06 作品集事实标准：agenticcareers、DEV、ai-infra-link 三方口径一致——招聘经理看 GitHub 多于简历、要 production signals、要把 token 成本计入 ROI 分母。本计划三件套铁律与之高度对齐。
• 「2min demo 视频 + 一个 failure」是当前明确加分动作：多个 2026 来源点名「领先 90% 申请者」；本笔记 C 节讲述稿据此设计，投递前必录。
• 「深度三件 > 浅度十件」持续有效：本计划恰好三大作品且各有 genuine evaluation，符合 2026 收敛叙事；避免为凑数堆边角 demo。
• 过时认知警示：「笔记/课程/证书多 = 有竞争力」过时——2026 是「shipped 系统 > 学历/证书」（呼应本计划 Google 2026-05 口径）；120 篇笔记是内功不是卖点，叙事必须把数字提到 README 顶部。
• 待跟踪：Q4 关注是否出现标准化的 AI 作品集评分维度（类似招聘平台的 portfolio scorecard）；READMEs 与 demo 数字在 W4 用 AML Copilot 实测统一回填后，重核一次单位成本口径是否与 CostMeter 当周计费一致。