FDE 交付实战营

Appearance

第十二章 结业与就业 ​

12.4 把沙盘写成简历项目 ​

承前：12.3 讲了市场要什么、四轮面试考什么，这一节讲你手里最硬的那张牌怎么打——沙盘项目本身。12 周的青禾项目是一个完整的 To B 交付闭环：进场诊断、数据治理、Agent 构建、灰度放量、验收归因。它比"跟着教程做了个 ChatGPT 套壳"重一个数量级，但只有把它组织成可核验的证据，面试官才看得见这份重量。这一节讲三件事：什么样的作品证据才可信、代码仓库和演示材料怎么组织、简历和面试里怎么用 STAR 把项目讲成故事。

12.4.1 核心难题：项目是虚构的，证据链必须是真的 ​

先直面一个尴尬：青禾优选是虚构的教学沙盘，你没法说"我为某连锁超市交付过项目"。但这不等于项目没价值——**面试官从来不是在验你的客户名单，而是在验你有没有真实经历过交付的复杂性。**区分"背过答案"和"真做过"的，恰恰是那些只有亲历者才有的细节：为什么灰度要按门店哈希分层、W7 换帅那周为什么要冻结口径、复购率分母里那个双轨会员 ID 的坑是怎么踩平的。这些判断力痕迹伪造不出来。

所以这一节的方法论是：**把"真实性"锚定在你真正做过的工件上，而不是故事背景上。**你确实写了那些代码、跑了那些评估、画了那些架构图、做了那次答辩质询——这些是可核验的。你只需要在简历和口述里诚实地标注项目性质。推荐的标准表述：

"在结构化模拟环境（虚构连锁零售客户）中完成 12 周完整 To B 交付闭环，以下工件全部为本人产出。"

这句话放在 GitHub 仓库 README 的第一屏和简历项目的括号注里。诚实标注不但不减分，反而是加分项——它证明你理解 AI 交付的行业语境（知道什么是 FDE 该做的东西），这本身就是稀缺认知。面试官见过太多把教程项目吹成企业级落地的人，一个清楚标注边界、但工件质量扎实的候选人是稀缺品。

反面案例要避开：把沙盘包装成"某零售企业真实项目"。"某连锁零售企业（保密协议）"这种说法在追问下三分钟就穿帮——面试官问一句"客户团队几个人、叫你进场的发起人是什么角色、验收委员会上财务问了你什么"，编造的回答立刻露馅，而诚实是有细节的。这一行的信任逻辑和第 10 章验收一模一样：你嘴里的虚构是造假，嘴里的真实边界是职业成熟。

12.4.2 什么算"可核验的作品证据" ​

面试官核验一个项目的时间预算是 15 分钟以内——据全球技术人才委员会的职业建议，多数招聘方在 GitHub 页面上停留不到两分钟就会决定要不要往下看。所以证据的第一属性不是"多"，而是两分钟内可见的含金量。FDE 岗位的证据分四层，从硬到软：

作品证据金字塔（FDE 视角）

顶层：可复现的最终效果
  └ 评估集跑分记录、DiD 归因计算 notebook、
    验收汇报 PPT（含质询问答附录）
中层：生产级工程工件
  └ 工具调用执行器（重试/超时/审计日志）、
    护栏与兜底配置、trace/评估管道
底层：数据与诊断产物
  └ 会员 ID 双轨对账脚本、脏数据清洗管道、
    指标口径定义文档（YAML/README）
基座：过程证据
  └ 架构图、决策记录（ADR）、周报摘编

每层的核验方式不同：顶层的 DiD notebook 面试官可以亲手跑一遍；中层的执行器代码可以现场读；底层的对账脚本展示你处理真实脏数据的手感；基座的过程证据证明你会记录决策而不是只交结果。

其中最有差异化价值的是顶层。市面上会写 Agent 代码的人已经很多，但能在简历项目里拿出一份"对照组设计 + DiD 计算 + 敏感性分析 + 安慰剂检验"完整 notebook 的人凤毛麟角——因为这属于第 10 章讲的归因能力，绝大多数个人项目根本不涉及。**这一件证据直接把你和 95% 的"Agent 套壳"候选人区隔开。**同理，评估集（哪怕只有 200 条标注样例 + 一份跑分记录）证明你懂 12.3 说的行业新共识：evals 驱动的运营。这两个工件，比再写三个 demo 值钱。

一个自查标准：**每个声称的能力，都要有一个可点开的工件对应。**简历写"设计灰度发布与回滚机制"——好，仓库里有那个发布脚本的目录；写"建立三层指标口径"——README 里有口径定义文档的链接。写不出对应工件的能力，从简历里删掉。

12.4.3 代码仓库的组织：为"15 分钟审阅"而设计 ​

仓库不是给自己看的，是给一个时间有限的陌生面试官看的。组织原则只有一条：**让人不 clone 就能看懂 80%。**这来自开发招聘社区的普遍共识——README 是项目的第一道门，多数审阅发生在 GitHub 网页上。

推荐的仓库结构（青禾沙盘示例）：

qinghe-agent-delivery/
├── README.md            ← 第一屏决定生死（见下）
├── docs/
│   ├── architecture.md  架构图 + 分层决策理由
│   ├── metrics.md       指标口径定义（三层）
│   ├── attribution.md   DiD 归因方法 + 结果
│   └── adr/             决策记录：为何语义层独立等
├── semantic/            数据对账与清洗管道
│   ├── id_resolution/   会员 ID 双轨归一脚本
│   └── dbt/             指标模型（如用 dbt）
├── agent/
│   ├── executor/        工具执行器（重试/审计）
│   ├── guardrails/      护栏配置与测试
│   └── prompts/         版本化 prompt
├── evals/
│   ├── dataset/         评估集 + 标注规范
│   └── reports/         跑分记录（历次对比）
└── analysis/
    └── did_attribution.ipynb  归因 notebook

README 第一屏的黄金结构——四个问题按顺序回答：这个项目是什么、解决什么问题、效果如何（数字）、我怎么核验你的说法。据技术求职社区的 README 写作指南，招聘方打开仓库后的动作序列基本固定：看最近一次提交时间（陈年仓库直接扣分）→ 点开最好项目 → 读 README → 点 demo。所以：

markdown
# 青禾优选会员复购 Agent —— 12 周 To B 交付沙盘

结构化模拟环境（虚构零售客户）中的完整前置部署交付闭环：
进场诊断 → 数据治理 → Agent 构建 → 灰度放量 → DiD 归因验收。

**关键结果**（详见 analysis/did_attribution.ipynb，可复现）：
- 处理/对照 DiD 净效果 +1.5pp 复购率（含安慰剂检验）
- 评估集 200 条，Agent 任务成功率 87%（三次迭代记录在 evals/reports/）
- 工具执行器：重试/幂等/审计日志全覆盖，含故障注入测试

**三分钟导览**：docs/architecture.md 的分层图 →
agent/executor 的接口设计 → 归因 notebook 从头跑一遍。

另外两条工程卫生，据 GitHub 作品集最佳实践：commit 历史要像变更日志——一个 "final code" 大提交是红旗，把它拆成有逻辑的序列（"增加工具执行器的重试逻辑"、"评估集 v2：补充长尾场景"），你的提交历史本身就在讲工程习惯；每个核心模块配最小测试——不要求覆盖率数字，但执行器的幂等性测试、护栏的边界用例，这几个关键测试的存在就是生产意识的信号。

12.4.4 文档与演示材料：两条并行的证据线 ​

代码仓库之外，还有两条线让证据立体化：

文档线（给"会读文档的人"）。除了仓库内 docs/，准备一份 10 页以内的项目白皮书（PDF）——它就是第 10 章验收报告的个人版：三层判断结论、归因方法、已知问题与残留风险。这份文档直接复用 12.1 答辩的主件结构，几乎零额外成本，但在面试里威力巨大：当面试官问"你们的效果怎么算的"，你递上的是一份带口径附录和敏感性分析的文档，而不是一段口头解释。会带文档进面试的候选人，暗示了 TA 会在客户现场带文档——这正是 FDE 的行为模式。

**演示线（给"要看见的人"）。**一段 3 分钟的录屏 demo（剪辑过、带字幕）比现场 demo 安全十倍：不受网络和 API 稳定性威胁，可控制展示的路径。内容组织成一条业务故事线而非功能巡礼："王店长的周一早晨：打开助手 → 收到流失预警名单 → 一键生成回访话术 → 看到上周挽留结果"——注意，这就是第 10 章说的"数字说服财务，故事说服决策者"在求职场景的镜像。demo 存到仓库的 docs/demo/ 或视频平台，README 里给链接。

三个材料（仓库、白皮书、demo）在简历项目条目下各占一行链接。面试官三选一深入，都通向同一个可信的内核。

12.4.5 简历条目与 STAR 描述：把工件翻译成语言 ​

简历上这个项目的标准条目形态（含诚实标注）：

会员复购 Agent 交付沙盘 —— 结构化模拟 To B 环境（个人完整闭环，2025.X-2025.X） 仓库 / 白皮书 / 3 分钟演示：[三个链接]

  • 独立完成 12 周交付闭环：进场诊断发现三部门会员数不一致（80万/120万/76万），主导 ID 归一，统一口径分母
  • 设计并实现工具执行器（重试/幂等/审计日志），故障注入测试 100% 通过，支撑灰度放量
  • 建立评估集 200 条并驱动三轮 prompt 迭代，任务成功率 71%→87%
  • 设计华东/华南对照的灰度方案，DiD 归因净效果 +1.5pp，含安慰剂检验与敏感性分析

写法上有三个讲究：

**第一，每条 bullet 都是压缩版的 STAR。**行为面试界对 STAR 的共识是：Situation/Task 只占 15 秒铺垫，**重量在 Action（你具体做了什么）和 Result（可度量的结果），合计占一个回答的四分之三。**简历 bullet 同理——"设计并实现工具执行器（重试/幂等/审计日志）"是 Action，"故障注入测试 100% 通过"是 Result，两样都有才算完整条目。只有 Action 没有 Result 是"做过"，只有 Result 没有 Action 是"碰巧"。

第二，动词用"交付动词"而非"学习动词"。"独立完成""主导""设计并实现""建立"——FDE 招的是交付者。避免"学习了""探索了""了解了"，这些动词把你自己定位成学生。同理，每条 bullet 的主语默认是你个人，团队协作的条目要写清你的具体份额。

第三，数字全部可溯源。"+1.5pp"要能在归因 notebook 里找到，"87%"要能在 evals/reports 里找到——据量化简历的写作研究，带度量的条目获得的关注度显著更高，但代价是每个数字都变成一个承诺。面试官核验任何一个数字对不上，整张简历的可信度清零。这和第 10 章"数字必须有出处"是同一条纪律在求职场景的投影。

口述版 STAR（面试现场 90 秒），以归因能力为例：

  • S：沙盘验收阶段，复购率总体涨了 2.2 个点，但同期有大促，功劳说不清。
  • T：我需要把 Agent 的净效应从大盘里剥出来，且经得起"财务"质询。
  • A：利用灰度的区域节奏构造华东处理组/华南对照组，先做配平和平行趋势检查，做券核销归属期修正，再跑 DiD，并做了安慰剂检验和 ±1 个点的敏感性分析。
  • R：净效应 +1.5pp；我在答辩质询里被追问七个数据问题，答上五个、两个给了补查路径——这段经历让我理解了为什么效果口径必须事前写进合同附录。

注意 A 的细节密度——配平、平行趋势、券核销归属、安慰剂，四个只有做过的人才会脱口而出的环节。这就是"真实性锚定在工件上"的语言形态。

12.4.6 按面试轮次配置证据 ​

12.3 的四轮面试，每轮调用的证据不同，提前配好：

轮次面试官要看你递什么
R1 编码生产级手感executor/ 代码现场读：异常路径、幂等、审计
R2 系统设计决策理由architecture.md + ADR：为什么语义层独立、为什么审计进日志层
R3 问题分解拆解习惯口述进场诊断：三个会员数 → 数据先行 → MVP 克制
R4 客户模拟质询承受力白皮书 + 答辩质询复盘：承认-定界-给路径的实弹记录

最后一行的逻辑值得点破：12.1 的客户委员会质询就是你 R4 的实弹演习。把那次质询的问题清单、你的回答、事后复盘的改进点整理成一页附录——面试里讲"我被质询时的失误与修正"，比讲"我表现完美"可信十倍。展示失败的处理过程，是行为面试里最被低估的加分动作——它证明你有真实的压力经历和从中学到东西的能力。

12.4.7 要点总结 ​

  • 真实性锚定在工件而非故事背景：诚实标注"结构化模拟环境"，工件全部本人产出——编造客户背景三分钟穿帮
  • 证据四层：可复现的归因 notebook 与评估集跑分是最稀缺的差异化证据，比三个 demo 值钱
  • 仓库为"15 分钟审阅"设计：README 第一屏四问、commit 历史像变更日志、关键测试存在即信号
  • 两条并行证据线：10 页白皮书（复用验收报告结构）+ 3 分钟故事化录屏 demo
  • 简历 bullet 是压缩版 STAR：Action+Result 占四分之三，交付动词，数字全部可溯源
  • 四轮面试各配各的证据；讲"被质询的失误与修正"比讲完美更可信

参考资料 ​