今天要解决的问题
二十天前开始作品篇时，我们给自己定的目标是：做两个「只有你做得出来、招聘方能在线点开试用」的作品。到昨天为止，两个都上线了。Agent Loupe 证明你会做工具、懂 Agent 内部；BillSleuth 证明你能理解一个陌生业务，把 Agent 做到可以给财务同事用的程度，而且能拿数据说明它有多可靠。
但上线不等于被看到。招聘方，尤其是看大量简历的那一层，花在一个作品上的时间以分钟计。今天做的事情，就是把这二十天的东西压缩成他们在两分钟、五分钟、四十五分钟里分别能看懂的版本。
学完今天，你应该有这些产出：
- BillSleuth 的案例页，按模板填好，数字全部来自 Day 127 和 Day 128 的结果表。
- 一个两分钟的演示视频，按逐秒脚本录。
- 一段五分钟以内的项目讲述，用 FDE 面试的四段式，能应对三类追问。
- 两个作品的简历条目，中英文各一版。
- 个人网站上的作品集页。
- 一份按岗位类型拆开的投递清单，知道每类岗位该用哪个作品打头。
预计用时 5–6 小时，其中录视频和反复改讲稿占一大半。前置:Day 54(SupportPilot 包装)、Day 56(简历)、Day 105(AgentOps 包装)、Day 120(Agent Loupe 包装)、Day 127–129。
三种时长，三种版本
同一个项目，你要准备三个长度：
两分钟版是视频和案例页的首屏。看的人可能是 HR、招聘经理，或者正在刷 LinkedIn 的工程师。他们只想知道：这是什么、能不能用、做的人水平如何。
五分钟版是面试开场「讲讲你做过的项目」。对面是工程师或者技术负责人，他们会边听边找可以追问的点。
四十五分钟版是深挖面或者系统设计面，对面会挑一个点一路往下问：为什么用 SQLite、幂等键为什么带金额、评测集的根因分布怎么定的。这个版本不用背稿子，你需要的是对每个设计决定都能说出理由和替代方案。Day 126 到 Day 128 每篇的「资深面试题」就是在练这个。
今天主要写前两个版本。
BillSleuth 案例页
案例页放在你的个人网站上，和 Day 120 Agent Loupe 的案例页并排。结构按招聘方阅读的顺序排，最重要的放最前面。下面是模板，方括号里的内容替换成你自己的数字，每个数字都要能在你的评测报告里找到出处,区间一起写：
# BillSleuth:会查账的计费争议调查 Agent
[在线试用](https://你的域名) · [源码](https://github.com/你/billsleuth) · [2 分钟演示视频](链接)
客户问「为什么这个月多扣了钱」,BillSleuth 自己查订阅、发票、付款和税率，
用参考计费引擎复算，找出原因，给出每个数字都有出处的解释；
确认多收时起草贷记单，交给人工审批。数据全部虚构。
## 结果(100 个场景 × 4 次，模拟客户，[日期])
| 指标 | 结果 | 95% 置信区间 |
| 成功率(根因、差额、动作全对) | [ ]% | [ ]%–[ ]% |
| pass^4 | [ ] | — |
| 误冲正率 | [ ]% | [ ]%–[ ]% |
| 数字幻觉率 | [ ]% | — |
| 单次调查成本 / 耗时 P95 | ¥[ ] / [ ] 秒 | — |
## 它怎么工作
[一张架构图:调查流程 → 工具层(只读 + 复算 + 起草)→ 审批 → 签发]
- 每个结论里的金额都要能追溯到某次工具调用，追溯不到就打回重写
- 模型只有只读工具；贷记单由代码按校验过的结论起草，调查图在审批节点暂停，批准和签发只有人能做
- 幂等键由案件号、发票号、金额推出，并发和流程重放都只会产生一张草稿
## 评测怎么做的
- 100 个场景:12 类根因 80 个，账单其实没错的 20 个(专门测误冲正)
- 模拟客户有四种人设，会记错金额、会着急、会追问
- 全部规则判分，按数据库最终状态判断有没有误冲正
- 每题 4 次，报 pass^k;每个比例带按场景聚类的置信区间
## 迭代记录
| 版本 | 改了什么 | 为什么 | 成功率 | 对上一版 |
| v1 → v2 | 复算结果加 overpaid、duplicate_of | 重复开票时贷记单开在哪张取决于发票号顺序 | 组件级:开错 7/160 → 0/160 | ... |
| v2 → v3 | 场景加 customer_goal(评测改动) | 模拟客户从不追问 | 不可比 | ... |
| ... |
## 做砸过的事
- [比如:冒烟时厂商排队超时，没设超时的子进程卡了十几分钟，进程池坏掉后剩下的任务全挂]
- [比如:端到端全对，但重复开票的贷记单开对是靠模型列发票号的顺序]
## 没做什么(以及为什么)
- 不接真实支付网关；重复扣款简化成贷记单，真实系统应该退掉那笔付款
- 不做作废重开，交给人工几点说明。
结果放在第二屏，架构放在第三屏。 工程师看作品，第一个问题是「效果怎么样」,第二个才是「怎么做的」。很多人的作品页一上来就是技术栈和架构图，招聘方要翻到底才知道它到底好不好用。
「做砸过的事」一定要写。 这一节最能区分做过和没做过的人。Day 127 冒烟时的排队超时和进程池崩溃、Day 128 读成功运行时发现的「侥幸」，写出来比一份完美的报告可信得多。面试官也会顺着这一节追问，这正好是你最熟悉的地方。
「没做什么」也要写。 这一节让懂行的人知道你清楚自己的边界。重复扣款严格说应该退款而不是开贷记单，做过支付的面试官一定会注意到；你先写出来，就从「他不懂」变成了「他知道，但有意简化了」。
数字只写你跑过的。 冒烟的 12 次运行不要写进案例页，样本太小，区间宽到没意义。正式评测没跑完之前，结果那一节宁可写「评测进行中」。
两分钟演示视频
录屏加旁白，不露脸也可以。下面是逐秒脚本，旁白尽量口语，别念 PPT:
| 时间 | 画面 | 旁白要点 |
|---|---|---|
| 0:00–0:12 | 演示页首屏，选中「重复扣款」场景 | 「这是 BillSleuth,一个查账的 Agent。客户问为什么被扣了两次钱，我们看它怎么查。」 |
| 0:12–0:45 | 点开始，步骤一条条出现 | 不解释每一步，只点两三个关键的:「它先找到这张发票，再看付款记录，发现同一天有两笔成功付款。」 |
| 0:45–1:05 | 复算对比表出现，镜头停在差额和扣款合计 | 「复算结果里，发票本身没错，差额是 0;但实际扣款合计是两笔。多收的 123.60 是从工具结果里来的，不是模型算的。」 |
| 1:05–1:25 | 结论和证据链 | 「回复里每个金额都能在右边的证据链里找到出处。找不到的话，系统会打回让它重写。」 |
| 1:25–1:40 | 切到审批命令行或审批页面，批准 | 「它只能起草贷记单，批准和签发必须是人。」 |
| 1:40–1:55 | 切到案例页的结果表 | 「100 个场景、每个跑 4 次，成功率 [ ],误冲正率 [ ]。」 |
| 1:55–2:00 | 案例页链接 | 「源码和评测方法都在这里。」 |
录之前先把要演示的那次调查跑几遍，挑一次步骤少、速度快的。真实调查要 15 到 25 秒，视频里可以把等待模型的那几秒加速，但要在画面角落标一下「2 倍速」,不要让人误以为它就是这么快。
不要演示「账单没错」以外的失败场景。视频的任务是让人在两分钟内相信它能用；失败和局限写在案例页上，面试时讲。
FDE 面试里怎么讲这个项目
FDE(Forward Deployed Engineer,前沿部署工程师)这个岗位来自 Palantir,意思是把工程师派到客户那边，直接在客户的环境里把产品落地。2025 年以后，做大模型和 Agent 的公司普遍在招这个岗位，a16z 那篇文章把它称为创业公司里最热门的职位，SVPG 也专门写过一篇讲这个角色和产品经理的关系，链接在文末。
我们在 Day 59 和 Day 110 讲过一般的面试准备。FDE 面试的不同在于，面试官更关心「你能不能在一个陌生的客户环境里把事情做成」,而不只是「你的代码写得好不好」。所以讲项目时，我建议用四段式：
一、客户场景。 不是「我做了一个计费 Agent」,而是「一家 SaaS 公司的客服每天收到几十封『为什么多扣钱』的邮件，每封要账务同事花十几分钟查。」先讲清楚谁痛、痛在哪。BillSleuth 是虚构的公司，你可以直接说是虚构的，但场景要具体。
二、方案。 讲两三个关键决定，每个都带一句「为什么」。比如：「Agent 不自己算数，复算交给一个参考计费引擎，因为计费差一分钱都是错。」「模型碰不到写操作，贷记单由代码按校验过的结论起草，签发必须人来做，因为这是唯一会让钱出去的动作。」「回复里的每个金额都要能追溯到工具返回，追溯不到就打回。」不要把技术栈从头念一遍。
三、指标。 你怎么知道它能用？讲评测集怎么构造(两成账单没错的场景专门测误冲正)、看哪几个指标、结果是多少、区间多宽。然后讲一次迭代：「冒烟全对，但我读了成功的运行，发现重复开票时贷记单开在哪张，取决于模型列发票号的顺序。我写了一个不调模型的组件级评测，穷举 80 个场景的正反两种顺序，开错 7 次；在复算工具的返回里加了两个字段以后降到 0。」这一段是整个讲述里最有说服力的部分。
四、取舍和下一步。 「重复扣款我简化成了贷记单，真实系统应该退款。」「如果要上生产，我会先只开放解释能力，贷记单全部人工审核，同时线上抽样复核。」这一段告诉面试官你知道玩具和生产的距离。
整个讲述控制在五分钟以内。下面是一个大约三分钟的示范，你可以照着改成自己的话：
我做过一个叫 BillSleuth 的计费争议调查 Agent。场景是 SaaS 公司的客服经常收到「为什么多扣钱」的问题，每个都要账务同事去查订阅、发票、付款和税率，很费时间，而且查错了直接影响收入。
我做了三个比较关键的设计。第一，Agent 不自己算钱，复算交给一个参考计费引擎，按天折算、税率生效区间、四舍五入都在代码里。第二，Agent 的回复里每个金额都必须能追溯到某次工具调用，有一个校验器专门检查，追溯不到就打回重写。第三，模型手里只有只读工具，要冲正时由代码按校验过的结论起草贷记单，然后整个调查流程暂停，等主管在命令行或网页上批；起草用案件号、发票号、金额做幂等键，所以重试、追问、流程恢复时的重放都只会产生一张草稿。
评测上，我造了 100 个场景，其中 20 个是账单本身没错、客户误解的，专门用来测它会不会讨好客户乱冲正。客户由一个 LLM 扮演，有几种人设，会记错金额。全部用规则判分，每个场景跑 4 次，看 pass^4 和按场景聚类的置信区间。
迭代时有一次印象很深。端到端冒烟是全对的，但我去读了成功的运行，发现重复开票那个场景对得很侥幸：复算工具对两张发票都说「金额没错」,贷记单开在哪张，取决于模型把哪个发票号写在后面。我写了一个不调模型的组件级评测，把 80 个该冲正的场景、两种发票号顺序都试一遍，开错了 7 次。问题的根在工具：它只算发票行的差额，重复开票和重复扣款的多收要模型自己推。我在复算结果里加了「付款层多收」和「这张是哪张的重复开票」两个字段，再跑一遍，0 次开错。
如果要上生产，我会先只开放解释，贷记单全部人工审，同时上线抽样复核，等误冲正率在真实流量上稳定了再放开。
注意这段话里没有一个技术名词是硬塞进去的。LangGraph、SSE、SQLite 都没提，面试官想问自然会问。
FDE 面试常见的追问方向，我按 BillSleuth 能怎么接，列三类：
| 追问方向 | 典型问法 | 用 BillSleuth 怎么接 |
|---|---|---|
| 客户环境 | 「客户的计费系统是自研的，字段和你的完全不一样，你怎么接?」 | 工具层是唯一和数据打交道的地方，换客户就是换工具实现；参考引擎要按客户的计费规则重写，先拿客户历史上已确认的几十个争议做验收 |
| 可靠性 | 「客户说上线一周有一张贷记单开错了，你怎么查?」 | 审计日志找到那次调查的全部工具调用，Agent Loupe 回放 trace,看是哪一步的证据被误读；复现后加进评测集，修完跑回归 |
| 取舍 | 「为什么不让 Agent 直接退款?」 | 起草和签发分开，Agent 能触发的动作全部可撤销；真要提高自动化程度，按金额分层，小额走单人审批，再小的考虑抽样复核 |
简历条目
简历上每个作品两到三行，结构是「做了什么 + 关键设计 + 数字」。数字等你正式评测跑完再填。
中文版:
- BillSleuth · 计费争议调查 Agent(个人项目，[链接]):用 LangGraph 和 MCP 实现自动查账的 Agent,结论中所有金额可溯源至工具调用；贷记单由代码按校验过的结论起草，图在审批节点暂停等人工批准，幂等键保证重放和并发不重复开单。构建 100 场景评测集(含 20% 无错场景测误冲正)与 LLM 模拟客户，成功率 [ ]%(95% CI [ ]–[ ]),误冲正率 [ ]%;通过错误分析迭代 [ ] 版，将漏冲正从 [ ] 降至 [ ]。
- Agent Loupe · Agent 运行记录调试器(开源，[链接]):React + TypeScript 实现的 trace 回放工具，支持 OTel GenAI 与 Langfuse 导入、两次运行逐步对比(LCS 对齐)、从任意步骤改参数重跑(录制回放工具结果)、失败步骤一键转评测用例；万步 trace 首屏 [ ] 秒。
英文版:
- BillSleuth — billing dispute investigation agent ([link]): Built an agent that investigates “why was I overcharged” tickets end to end. Every amount in its answer is traced to a tool call; it can only draft credit notes, which require human approval, with idempotency keys preventing duplicates under retries. Evaluated on 100 scenarios (20% no-error cases to catch wrongful credits) with an LLM customer simulator: [ ]% success (95% CI [ ]–[ ]), [ ]% wrongful-credit rate; [ ] error-analysis iterations cut missed credits from [ ] to [ ].
- Agent Loupe — debugger for agent traces (open source, [link]): React/TypeScript tool to replay agent runs step by step; imports OTel GenAI and Langfuse traces, aligns two runs for step-level diffs, re-runs from any step with recorded tool results, and turns failed steps into eval cases. First paint for a 10k-step trace: [ ] s.
Day 56 讲过的原则在这里同样适用：不夸大，不写「精通」;数字带口径；个人项目就写个人项目，不要包装成公司项目。
个人网站上的作品集页
如果你一直在用这门课的网站结构，作品集页可以这样排：
- 顶部一句话介绍自己：做什么方向、几年经验、在找什么样的岗位。
- 两张作品卡片并排：截图或动图、一句话说明、三个链接(在线试用、案例页、源码)。BillSleuth 在左，因为它的结果数字更直观；如果你主投平台或工具类岗位，就把 Agent Loupe 放左边。
- 下面是 SupportPilot 和 AgentOps,作为「课程项目」单独一栏，和两个作品分开。招聘方能区分「跟着教程做的」和「自己设计的」,混在一起反而会拉低后者的分量。
- 最底部是联系方式。
两个作品之间做一个联动:BillSleuth 演示页上「下载 trace,拖进 Agent Loupe 回放」那个链接，在作品集页上也做一个入口，比如「看一次真实调查在 Loupe 里长什么样」。这个联动本身就能说明你的两个作品不是孤立的玩具。
两个作品分别对准哪些岗位
2026 年 10 月 15 日，我抓了两批公开的岗位数据(LinkedIn 公开职位和各公司招聘系统的公开接口)。这里只摘和投递决策有关的部分，数字只代表那一天在招的岗位，你自己投之前最好按同样的方法再抓一遍最新的。
第一批：可以远程的 FDE 及相近岗位，88 条。 来源是 LinkedIn 公开职位、几十家 AI 公司的招聘系统接口、Hacker News 当月的招聘帖。几个结论：
- 「远程」大多是限定国家的远程：只招美国 36 条，只招欧洲或英国 16 条，只招美洲 11 条，亚太 14 条(大多数也限一个国家),写明全球都能做的只有 5 条。人在中国大陆或东南亚的话，真正能投的很少。
- 标了美元年薪区间的 26 条，区间中点的中位数是 $218,750,但其中 19 条只限美国，这基本是美国的价格。
- 和 10 月 12 日那批海外 Agent 工程师的 JD 对比,FDE 岗对 Agent 内部机制要求低得多:RAG 25% 对 54%,工具调用 10% 对 39%;但更看重部署(65% 对 53%)和 TypeScript(47% 对 34%)。八成要面向客户，四成多提到出差，写了出差比例的大多在 20% 到 50% 之间。
第二批：外企在中国大陆招的 AI 应用类工程岗，131 条，62 家公司。 几个结论：
- 量不大，而且集中:NVIDIA、Microsoft、Google 三家占四分之一。城市以上海为主(49 条),深圳 28 条，北京 24 条，而北京的 24 条全部来自四家公司。
- 真正叫 FDE 的只有 3 条，主体是 AI 应用工程师(90 条)和 Solutions Architect / Customer Engineer(35 条)。
- 131 条里没有一条写了薪资；英文 JD 或明确要求英语的合计 82%;年限中位 5 年，Solutions 类中位 10 年。没有一条写明可以远程。
- 和国内互联网公司的 Agent 岗相比，外企 JD 很少细问 Agent 机制(上下文工程 23% 对 52%,工具调用 27% 对 55%),更像在招「会用大模型的软件工程师」。
把这些数据和两个作品对上，投递策略大致是这样：
| 岗位类型 | 打头的作品 | 理由 |
|---|---|---|
| 海外 FDE / Solutions / Deployed Engineer | BillSleuth | 客户场景、落地、评测、取舍，正是 FDE 的工作；面试讲四段式 |
| 外企在华 AI 应用工程师 | BillSleuth,配英文案例页 | 外企更看工程基础和英语，案例页和讲述都要有英文版 |
| 外企在华 Solutions / Customer Engineer | BillSleuth | 但这类岗位年限中位 10 年，要的是面向客户的云架构经验，作品只是加分项 |
| 国内互联网 Agent 工程师 | 两个都放，技术细节多讲 | 国内 JD 更细问 Agent 机制，Agent Loupe 的上下文可视化、BillSleuth 的工具设计和证据链都是好话题 |
| Agent 平台、开发者工具、可观测方向 | Agent Loupe | 工具和平台岗看重前端工程、性能、对 trace 的理解 |
两个现实提醒。第一，全球远程的 AI FDE 岗非常少，样本里只有个位数，不要把全部希望放在这一类上；亚太的岗位大多要求你住在新加坡、印度、韩国或澳洲中的某一个，搬家或者先在国内外企积累几年，都是更现实的路径。第二，两批数据都是一天的快照，岗位每周都在变，投之前自己再搜一遍。
作品篇自检清单
| 项 | 标准 |
|---|---|
| Agent Loupe 在线可用 | 公网链接能打开，预置样例能回放 |
| BillSleuth 在线可用 | 公网链接能打开，能跑一次完整调查 |
| 两个作品的源码 | 公开仓库，README 有快速开始，uv run pytest 或 pnpm test 能过 |
| BillSleuth 正式评测 | 100 场景 × 4 次的结果表填满，带区间 |
| 改动日志 | 至少三次迭代，每次有对上一版的配对比较 |
| 两个案例页 | 结果在前、架构在后，有「做砸过的事」和「没做什么」 |
| 两段演示视频 | 各两分钟以内，加速的地方有标注 |
| 项目讲述 | 能在五分钟内讲完四段式，录音听过至少一遍 |
| 简历条目 | 中英文各一版，数字带口径，都能在报告里找到出处 |
| 作品集页 | 两个作品并排，课程项目单独一栏，trace 联动有入口 |
| 投递清单 | 按上面的岗位类型拆开，每类至少 5 个具体岗位 |
动手练习
- 按模板写 BillSleuth 案例页，放到个人网站上。所有数字从 Day 127、128 的结果表里抄，抄的时候顺手检查一遍区间。
- 按逐秒脚本录两分钟视频，传到 B 站或 YouTube,嵌进案例页。
- 把四段式讲述写下来，大声读三遍，录一遍音，听回放，把卡顿和多余的技术名词删掉。
- 找一个朋友扮演面试官，从上面三类追问里各挑一个问你，每个回答不超过两分钟。
- 写中英文简历条目，替换掉 Day 56 简历里的项目经历部分。
- 搭作品集页，加上两个作品之间的 trace 联动入口。
- 按上面的岗位类型表，自己在 LinkedIn 和目标公司的招聘页上搜一轮，每类挑出至少 5 个具体岗位，写进投递清单。
**验收标准:**自检清单全部达标；一个没看过这个项目的人，看完两分钟视频能说出它是做什么的、怎么证明它可靠；你能在不看稿的情况下五分钟内讲完四段式。
名词解释
| 名词 | 意思 |
|---|---|
| FDE(Forward Deployed Engineer) | 前沿部署工程师，派驻到客户那边，在客户环境里把产品落地的工程师 |
| Solutions Engineer / Architect | 解决方案工程师 / 架构师，偏售前和方案设计，面向客户 |
| 案例页(case study) | 讲一个项目的问题、方案、结果和教训的页面 |
| 四段式 | 客户场景、方案、指标、取舍，FDE 面试讲项目的结构 |
| 作品集(portfolio) | 展示你自己设计和完成的项目的页面 |
| 限定国家的远程 | JD 写远程，但只接受某个国家或地区的居民 |
| 投递清单 | 按岗位类型拆开、写到具体岗位的投递计划 |
常见误区
案例页一上来就是技术栈。 招聘方先想知道效果，再想知道做法。结果放第二屏，架构放第三屏。
只写成功，不写做砸的事。 完美的报告看起来像编的。真实踩过的坑最能说明你做过，也是面试里你最能讲的地方。
把冒烟的数字写进简历。 12 次运行的成功率区间宽到没意义，被追问一句就露馅。正式评测跑完再写。
讲项目从技术栈开始念。 面试官想听的是你在什么场景下做了什么判断，而不是你用了哪些库。
视频里偷偷加速。 加速可以，但要标出来。被人发现视频和在线演示速度不一样，比慢一点更伤信任。
课程项目和自己设计的作品混在一起。 招聘方能看出哪些是跟着教程做的，混在一起会拉低自己设计的那部分的分量。
只投全球远程的 FDE。 数据里这类岗位只有个位数，要同时准备国内外企、亚太本地和国内互联网几条线。
学习资料
文档与文章
- a16z · Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups:讲为什么 AI 公司在大量招 FDE,以及这个角色在商业模式里的位置，20 分钟。
- SVPG · Forward Deployed Engineers:Marty Cagan 从产品管理的角度讲 FDE 和产品团队的关系，15 分钟。
- Palantir 博客《A Day in the Life of a Palantir Forward Deployed Software Engineer》:FDE 这个岗位的原始出处，讲日常工作是什么样的。这个页面对脚本访问返回 403,按标题搜索后用浏览器打开，15 分钟。
B 站视频
其他经典视频
- ZAUEY(Claire Zau)《The Rise of the Forward Deployed Engineer》(YouTube
EL2YIn5cLig):从投资人视角讲 FDE 为什么火起来，可以和 a16z 那篇对照看。
书籍
- Austin Kleon《Show Your Work!》(Workman, 2014):一本很薄的书，讲怎么把做事的过程公开出来，被人看见。整本一个多小时就能读完，读完你会更愿意写「做砸过的事」那一节。
- Gayle Laakmann McDowell《Cracking the Coding Interview》(CareerCup, 第 6 版 2015):不用刷里面的题，看讲「行为面试」的那一章。它推荐用情境、行动、结果(S.A.R.)的结构讲经历，和今天的四段式是一个思路，FDE 面试只是把「客户场景」和「取舍」拎出来单独强调。
开源项目与代码
- sierra-research/tau-bench:如果面试官问你的评测方法从哪来，这是最好的出处；README 和论文链接都在这里。
- promptfoo/promptfoo:被问到「怎么把评测接进 CI」时，可以提这个工具作为生产上的选择，并说明你为什么自己写了一套(需要按数据库最终状态判分)。
自测
- 案例页上「结果」为什么放在「它怎么工作」前面？
答案
招聘方和工程师看作品时，第一个问题是效果怎么样、能不能用，第二个才是怎么做的。结果放前面，他们在前两屏就能得到最关心的信息；如果一上来是技术栈和架构图，很多人翻不到结果就关掉了。
- FDE 面试讲项目的四段式是哪四段？每段的重点是什么？
答案
客户场景：谁痛、痛在哪，要具体。方案：两三个关键决定，每个带一句为什么，不要念技术栈。指标：怎么证明它能用，评测集怎么构造、结果和区间，再讲一次迭代。取舍和下一步：做了哪些简化、知道和生产的距离、上线会怎么分阶段。
- 为什么要在案例页上写「没做什么」?
答案
让懂行的人知道你清楚自己的边界。比如重复扣款严格说应该退款而不是贷记单，你先写出来，面试官的判断就从「他不懂」变成「他知道，但有意简化了」。它也能引导面试官去问你准备好的话题。
- 根据 2026 年 10 月的数据，人在中国大陆的工程师想找全球远程的 AI FDE 岗，现实吗？更现实的路径有哪些？
答案
很难。88 条可远程的 FDE 类岗位里，写明全球都能做的只有 5 条，而且不全是 AI 岗；大部分远程只限美国、欧洲或美洲，亚太的岗位大多也要求住在某一个国家。更现实的路径：投国内外企的 AI 应用工程师岗(上海最多，要英语),积累几年后再看海外；考虑搬到新加坡等亚太枢纽投本地岗；国内互联网 Agent 岗同时投；通过开源和技术写作让海外团队先认识你。
- 资深面试题(FDE):你被派到一家客户那里落地一个类似 BillSleuth 的 Agent,客户的计费系统是十年前自研的，字段命名混乱，还有很多只有老员工知道的特殊规则。你前两周会做什么？
答案
第一周以理解业务为主：找账务和客服各一两个人，拿最近几十个真实争议工单，逐个跟他们一起查一遍，记下每一步查了什么、用了哪些特殊规则，这些就是工具设计和参考引擎的需求；同时把数据访问理清楚：只读账号、哪些表、字段含义，先写一层只读工具，返回结构按 Agent 需要的来设计，而不是照搬客户的表结构。第二周搭最小闭环：用这几十个已经人工确认结果的工单做评测集，先跑「只解释、不冲正」的版本，和账务同事一起看错例；特殊规则能写成代码的进参考引擎，写不成的先列出来，让 Agent 遇到时转人工。要强调的取舍：前期不追求自动化率，追求「错了能被发现」;贷记单全部人工审批；每个结论的证据链给账务同事看，建立信任。还要尽早和客户定好验收标准(比如误冲正率上限)和上线分阶段的计划。
- 你的两个作品，投「Agent 平台工程师」和投「海外 FDE」时，分别怎么摆？
答案
投 Agent 平台工程师:Agent Loupe 打头，讲 trace 数据模型、万步渲染性能、对比算法、重跑时的录制回放，BillSleuth 作为「我也用它调过自己的 Agent」的佐证。投海外 FDE:BillSleuth 打头，用四段式讲客户场景、方案、评测和取舍，案例页和讲述准备英文版；Agent Loupe 作为「我会给客户做工具、能排查线上问题」的补充。
明天预告
作品篇到这里结束，主线课程也到这里结束。后面还有一组专题篇(Day 131–153),是 2026 年下半年对照公开课程和新发布补的 23 个主题，从 Day 131 · Agent Skills 开始，可以跳着读，每篇开头写了建议在哪一天之后读。
接下来的事情不再按天排：按投递清单每周投五到十个岗位，每次面试后把被问倒的问题补进对应作品的案例页或者 FAQ;BillSleuth 的正式评测和 Agent Loupe 的性能数字如果还空着，先把它们填上；两个作品各自挑一个方向继续深挖，比如给 BillSleuth 加多币种和年付，给 Agent Loupe 加 LLM 步骤的上下文可视化。这个领域变得很快，岗位数据也是一样，半年后再抓一次，看看哪些判断变了。
评论