AI 原生系列 · 07

别再死记硬背面试——编译它

一分钟速览——读完你能带走什么

职位描述就是源代码。解析它、落地核实它、把它和你实际做出来的东西链接起来——让链接器报的错，替你写出备考计划。这就是「编译面试法」，逐条术语，一条不落。

职位描述就是源代码。解析它、落地核实它、把它和你实际做出来的东西链接起来——让链接器报的错，替你写出备考计划。约 8 分钟读完。

整套方法其实就是一个循环：解析 → 落地核实 → 链接 → 让报错替你写计划。（这里有动画——等它一秒。）

第一份简历，就是一堆漂亮但没被验证过的说辞

1482 年，一位三十岁的求职者给米兰公爵写了一封信。这封信是已知最早的简历，列了十条编号的说辞：I can dry up the water of the moats. I can build unbreakable bridges. I can make cannon.（中译：我能把护城河的水排干。我能造出坚不可摧的桥。我能造大炮。） 而他后来真正闻名于世的绘画，只排在第十条。

Leonardo da Vinci 写这封信的时候，实际排干过的护城河数量：约等于零。历史上第一份简历，干的就是简历一直在干的事——不带证据地投射能力。最终让他成名的不是这封信，而是那些笔记本：七千页的图纸、测量数据和实验记录。信在「宣称」，笔记本在证明.

Leonardo's 1482 letter (claims, stamped CLAIMED) versus his notebooks (receipts, stamped OBSERVED) — 1482年：信里说「I can dry up the moats.」（中译：我能抽干护城河的水。）而笔记本，才是五个世纪后我们依然相信他的原因。

五百四十四年后，大多数面试准备依然是在写信：死磕框架文档、硬背术语表、反复练习怎么形容自己。我想提议一种笔记本式的方法，2026 年更新版——它的起点，是把职位描述本身当作一样东西去运行.

心智模型：职位描述就是源代码

这就是整套方法，简单到十二岁小孩都能懂：

JD 就是一份食谱。不要死记整本菜谱——读懂这份食谱，看看自己的食材柜里有什么，只去采购缺的那部分。

下面是同一套方法戴上工程师帽子之后的样子，也是我实际在跑的版本（就是本页顶部那个动画）：

解析（Parse）。 职位描述是一段散文，但它编码了一份规格说明。提取这个岗位真正要求的东西——能力集群、点名的工具、资历要求。
核实（Ground）。 确保每个提取出来的概念，都对应一个有真实定义的东西——而不是关键词带来的一种感觉。
链接（Link）。 拿每一条要求去对照你真正做出来的东西——公开仓库、能跑起来的演示、有提交记录的东西。
读错误信息。 链接不上的部分，就是你的备考计划。不是「什么都学一遍」，而是精准地把缺的那块补上。

四个动词，神奇之处在于每一个都能真正执行——这可不是给隐喻披件工装、装装样子。这就说到该展示实际操作的部分了。

逐条对照：厨房比喻对应的是真实机器

一个无法映射到可运行代码上的心智模型，只是摆设。所以下面是逐条对照的映射——每一行都在一套开源工具链里实现，今天就能克隆下来跑：

Term-by-term mapping: read the recipe → deterministic parse; check ingredients are real → retrieval grounding with provenance URLs; check the pantry → link against public repos; write the shopping list → gap report and SMART artifact — 左边一列给十二岁小孩看，右边一列给做代码审查的人看。同一个想法，没有一句虚的。

「读懂食谱」＝确定性解析。 编译器会拿 JD 去比对一份精心整理的能力分类体系——六个集群，比如智能体系统设计和 现代 AI 技术栈，外加一个具名工具库。匹配发生在词边界上，所以「rust」绝不会在「trust」内部被误判命中。整个过程是确定性且离线的：同一份 JD 输入，得到同一份画像输出，不掺杂任何大模型的情绪。

「检查食材是否为真」= 检索核实。 每个提取出的概念，接下来都会与开放数据源做核实——用 Wikipedia 与 Wikidata 核对定义与关系，用 ESCO（欧盟的开放技能分类体系）核对技能。最终生成的知识图谱里，每个节点都必须带有真实定义和溯源链接（provenance URL），这是硬性契约：没有 http(s) 来源，就没有完整节点。如果检索无法确定某个术语，该节点就会标薄并打上标记——绝不弄虚作假。一个无法追溯到来源的知识图谱，不过是一堆自信满满的剪贴画。

「检查食材柜」= 与实证材料做链接。 接下来，把每一项被要求的能力与你的公开成果做解析比对，就像链接器（linker）在库里解析符号一样。评测框架？会解析到一个仓库——它用 precision@k 给检索打分，并把结果接入 CI 门禁。安全护栏？解析到一个带签核清单的安全框架。工具集成？解析到一整排 MCP 服务器。每一次解析都是一张可以点开验证的凭证，而不是一个形容词。

「写购物清单」= 差距报告（gap report）。 凡是没能解析成功的部分，都精确、可证地指明了你接下来该准备什么。这不是教学大纲，这是一张购物清单。

三台望远镜：30 天、30 年、300 年

「靠谱」的意思是：在把备考时间押上去之前，先用三个缩放层级检验一下这套说法——它是不是当下热门？它是否扛住了时间考验？它是否是亘古不变的规律？出于这个原因，我用三台望远镜审视了这套方法。

Three panels: last 30 days (280% posting growth, 34.3% name LangChain, 57.3% agents in production), last 30 years (work samples beat credentials, ATS parsers, knowledge graphs), last 300 years (the guild masterpiece vs the résumé) — 新鲜信号、存活信号、文明尺度的信号——三者指向同一个方向。

30 天望远镜（够新吗？）。 智能体化 AI 岗位的招聘量同比增长了 280%——美国的招聘信息约有九万条——与此同时，传统的技术类入门岗位招聘却在萎缩。其中大约有 34.3% 的招聘信息点名要求 LangChain；这已经成了一项基本预期，而且 57.3% 的受访团队已经在生产环境中运行智能体。换句话说：JD 正在收敛成一份可描述、可解析的规格说明书。对编译器来说，这是好消息。

30年望远镜（它扛住了时间考验吗？） 1998年那份选拔方法元分析发现，工作样本测试是工作表现最强的预测指标之一——此后经历一场又一场重复验证战役，依然屹立不倒。招聘系统从上世纪90年代起就在把简历解析成关键词；三十年来，机器一直在编译你，然后决定录用还是拒绝。（真无情。）而这套方法只是把编译器反过来用——这次是你来编译他们。知识图谱——2012年那句「万物皆实体，而非字符串」——也早已挺过了炒作周期，变成了枯燥无趣的基础设施，而这恰恰是机器能得到的最高褒奖。

300年望远镜（它是亘古不变的法则吗？） 在简历出现之前的几个世纪里，行会招人只信一条规矩：要成为师傅，学徒必须拿出一件杰作——一件作品，由不会被蒙骗的人来评判。简历（1482年，见前文）其实是更晚出现、也更糟糕的发明：没有裁判的自我宣称。跨越每个世纪、每个行业都不变的规律是：作品比信件活得更久。

三台望远镜，一个结论：带作品来，别带形容词。

最好的备考产出，是一条报错信息

以下是我用这套方法处理一份真实招聘信息时发生的事——一个资深「智能体化AI工程师」岗位，正是30天望远镜所说正在激增的那一类。编译结果一开始相当讨喜：七个能力集群里命中六个，而且大多数符号都顺利链接到了公开仓库——编排循环、评测工具、一套智能体安全框架、一整排MCP工具。

然后链接器发话了：

A light terminal: jd-compile resolves most symbols against public repos, then reports undefined symbol: langgraph — the fix is one small shippable artifact, exit 0 — 六个集群已解析，一个符号未定义。这一行，比毫无重点地苦读一整周更有价值。

$ jd-compile agentic-ai-engineer.md --link ~/repos
resolved: orchestration ✓  evals ✓  guardrails ✓  mcp-tools ✓
ld: undefined symbol — langgraph

JD写着「尤其是LangGraph」。写了两遍。而我的作品集里LangGraph代码为零——因为我手上每一份编排类的作品，都是自己造的引擎。我把框架所抽象的那套机制，自己从头搭了一遍——这听起来很厉害，直到你意识到，这就像开着自己造的车去考驾照，却没有驾照。确实很有教育意义！但依然没有驾照。

这正是死记硬背会白白浪费一整周的时刻。差距报告开出的处方只有两步：

翻译，别唬人。 框架里的每个基本组件，都能对应到我早已用笨办法搭好的东西——状态图对应带计分的循环，检查点机制对应可续存的记忆库，人在回路中断对应硬性停止的审批闸门。知道为什么每个组件存在，才是资深级别的对话内容：检查点机制存在的原因，是一旦让墙钟时间渗进某个节点，可续存性就立刻崩溃。这一课我是吃过亏才学会的，所以我有资格在面试里讲出来。
把缺失的目标文件补上。 在真正的框架里做了一个小作品——四个节点，一个检查点机制，一条重试边，一道人类闸门——用半天时间就公开发布了。「你用过吗？」这个问题的答案，从此变成：「用过，仓库在这里，而且我自己的引擎还做了它做不到的事。」

一条报错。一个下午。 exit 0.

把它做成 SMART，然后让它复利

这个循环当得起这个缩写，没有半点勉强：

A rotating loop of five nodes — Specific, Measurable, Achievable, Relevant, Time-boxed — around the cycle compile → gap → artifact → recompile; side note: cramming resets, compiling accrues — 具体 · 可衡量 · 可达成 · 相关 · 有时限——飞轮效应是：你的差距报告每跑一次都会变短。

具体 ——每个差距对应一件作品，提前命名（“一个带检查点的四节点状态工作流”），而不是“把智能体能力练强一点”这种空话。
可衡量 ——重新跑一次编译，符号要么解析成功，要么失败。感觉良好不算证据。
可达成 ——半天工作量。如果一个差距要花一个月才能补上，那就不是面试准备了，那是职业选择问题；报告只是提前把它照了出来。这也算是一种用处。
相关 ——每件作品都要能锚定到 JD 里的某一行，面试现场可以原句引用。
有时限 ——在面试前完成，因为面试就是那个编译器挪不动的截止日期。

而这里正是它能永远碾压死记硬背的地方： 这个循环会复利增长。 你为 JD #1 造出的每一件作品，等 JD #2 拿来编译的时候，早已躺在你的作品库里了。你每跑一份新招聘信息，差距报告就会更短一分。死记硬背在每次面试后归零；而编译积累的东西只会越滚越多。这不是一种学习技巧——这是一项会自己生长的资产。

自己跑一遍（全部开源）

整套系统都是开源的——确定性核心，不需要 API key，编译这一步完全不用 LLM：

git clone https://github.com/wjlgatech/FDE-os
cd FDE-os
# 1. drop any job posting into course/target-jds/ as markdown
# 2. compile it → competency profile
python3 skills/jd-compiler/scripts/jd_compile.py compile course/target-jds/your-jd.md
# 3. deepen it → grounded knowledge graph + skills (Wikipedia/Wikidata/ESCO)
python3 skills/jd-compiler/scripts/jd_to_deepen.py course/target-jds/your-jd.md \
  --title "The Role" --url "https://the-posting-url"

然后做那唯一一步任何脚本都替你做不了的事：把每一项被要求的能力，拿去对照你自己真实公开的作品，老老实实问一句， 这到底能对应到一张收据，还是只是一个形容词？ 把每一个形容词都记下来。那份清单，限定时间去把它造出来，就是你这辈子做过的最好的面试准备。

要记住的那一句话

Leonardo da Vinci 需要七千页笔记本才能撑起十条自述。你需要的少得多——因为现在，这本笔记本会自己去对照职位要求。

别死磕整本菜谱。编译这道菜的做法，链接你的储物柜，然后精准补上缺的那一味。

AI-Native 系列更多文章

全部内容都在主页的「Writing」板块里。

本文属于 AI-Native 系列。jd-compiler 及其配套工具全部开源，见 github.com/wjlgatech/FDE-os——发布按钮握在你自己手里。资料来源： Leonardo's letter (Wikipedia) ·Stanford 2026 AI Index 招聘数据，来自 JobsByCulture · LangChain State of Agent Engineering ·Schmidt & Hunter (1998)。