做求职项目时，很多人的第一反应是问 AI：“现在做什么项目容易写进简历？”
这个问题看似直接，其实少了最重要的前提：你想投什么岗位，你真正缺的又是什么能力。
如果不先回答这两个问题，很容易做出一个功能不少、技术名词很多，却和目标工作没有直接关系的项目。它可能适合截图，却经不住面试官连续追问：为什么这样设计？数据怎么流转？失败时怎么处理？
我把自己的这套做法整理成了 「简历焚诀」。它不是简历包装教程，而是一条从目标岗位、能力缺口、真实项目到面试证据的完整链路。
先烧掉两个错误顺序
第一个错误顺序是先选热门技术，再想办法把它们塞进项目。
比如先决定要做 Agent、RAG、向量数据库和异步任务，却不知道它们具体要解决什么问题。这会让项目很快失控，最后只剩下一张技术栈清单。
第二个错误顺序是把 JD 交给 AI，让它直接“优化”简历。
AI 很擅长让文字看起来更完整，也容易顺手把“知道”写成“熟练”，把团队结果改成个人产出。表达变漂亮了，真实缺口反而被藏了起来。
正确顺序应该是：
目标岗位
→ 真实简历
→ 能力缺口
→ 项目地图
→ 最小可验证链路
→ 代码与测试证据
→ 更新简历先拆 JD，不要急着开编辑器
先把求职方向缩小，比如 AI 应用全栈、AI Agent 或 Node.js 后端。然后收集三到五个真正想投的完整 JD，不只记岗位名称和几个技术词。
整理 JD 时，要看的不是 React、Python 或 RAG 分别出现了几次，而是这些公司需要人解决什么问题：
- 是否要独立完成前后端闭环？
- 是否要接入模型、工具调用或外部数据？
- 是否要处理持久化、任务状态、并发与失败恢复？
- 是否要负责测试、部署和线上可观测性？
技术词只是表面，工作问题才是真正的能力要求。
保留一份“没有美化”的简历
在让 AI 提项目建议之前，先写一份完全基于现实的简历。做过什么就写什么，不追求每一行都和 JD 对齐。
再把 JD 与这份简历放在一起比较，把差异分成三类：
| 缺口 | 处理方式 |
|---|---|
| 做过，但简历没有说清楚 | 补充准确描述和可验证证据 |
| 知道概念，但没有真实实践 | 放入求职项目的练习范围 |
| 完全没接触过 | 先承认不会，再评估投入价值 |
这一步的价值不是寻找更多关键词，而是防止自己把“简历上有这个词”误当成“真的具备这项能力”。
先要大地图，动手时只做一条竖切
找到能力缺口后，可以让 AI 先设计一张完整的项目地图：项目解决什么问题，哪项功能对应哪条 JD 要求，架构如何拆分，最小版本是什么，每个阶段如何验证。
这张地图可以很大，但第一次动手必须很小。
以 ModelForge Agent 为例，它用一条最小链路把多项能力串了起来：
用户描述目标
→ 模型选择类型化工具
→ Node.js 服务校验参数并执行
→ 场景状态发生变化
→ 前端渲染真实结果它不需要在第一天支持完整的 3D 建模。只要能创建物体、修改位置或材质，就已经可以同时练习 Agent Loop、Function Calling、Schema 校验、服务端状态和前端反馈。
所谓“两天做一个项目”，不是两天内伪装成某个领域的专家，而是用时间限制强迫自己只保留核心闭环：
| 时间 | 目标 |
|---|---|
| 第一天 | 画清数据流，搭出最小骨架，用固定数据跑通核心执行链路 |
| 第二天 | 接入真实模型，补失败路径、测试和最小文档 |
到时间了，如果核心链路还不稳定，应该删功能，而不是继续堆技术名词。
Codex 可以写代码，但不能替你做判断
在这种项目里，让 Codex 直接搭骨架、改代码、跑测试并不是问题。真正危险的是把整个目标变成一句“帮我做个 AI Agent”，然后只验收页面能不能打开。
更可靠的协作边界是：
- Codex 负责调研、搭建、实现、测试和记录。
- 人负责目标、范围、技术取舍、验收标准和最终判断。
- 每次只推进一个可验证步骤，不让 Agent 顺手扩大需求。
- 第一次出现的概念要说明全称、作用位置和失败影响。
不一定要亲手敲完每一行代码，但必须能回答：现在为什么做这一步，它是不是最小方案，结果是否真正通过，AI 的解释有没有和代码对上。
每一步都要留下证据
“页面出来了”不等于项目完成。每个步骤至少要记录四件事：
改了什么
为什么这样改
怎么证明它有效
这一步还没有解决什么一次真实的排错记录，比“熟悉 Zod”更有价值。例如可以记录：
失败：模型生成的非法参数进入了业务执行层
诊断：模型输出被当成了可信数据
修改：在工具调用与执行器之间加入 Schema 校验
结果：非法参数被明确拒绝，错误可见，失败路径有测试覆盖这种“失败 → 诊断 → 修改 → 结果”就是面试故事的原材料。它不需要另外编，因为本来就是开发过程的一部分。
五个问题，决定它能不能写进简历
项目做完后，可以用五个问题检查自己：
- 不看代码，能不能画出核心数据流？
- 能不能解释一个关键技术选择，以及没选另一个方案的原因？
- 能不能说清楚一次真实故障的现象、定位和修复结果？
- 当一个约束改变时，能不能判断原方案是否还适用？
- 能不能现场运行项目或测试，证明描述不是口号？
哪一题答不上来，就回到对应的代码和记录继续补，或者老实缩小简历中的描述。
不要写：
熟练掌握 AI Agent、Function Calling、Node.js 与 React，独立完成智能 3D 平台。
更好的写法是：
基于 Node.js 与 TypeScript 实现模型工具调用链路，用 Zod 校验工具参数，由执行器修改 3D 场景状态；通过版本校验拒绝过期写入，并用单元测试覆盖核心工具和失败路径。
后一种写法没有“精通”或“深入”，却包含了每个都能继续追问、也能回到仓库验证的动词。
代码完成后，再做一份面试包
项目的最后一步不是拍封面图，而是根据真实仓库整理面试证据：
README.md：项目解决什么问题，如何运行和验证。docs/architecture.md：核心数据流、模块边界和关键取舍。docs/build-log.md：按时间记录失败、诊断、修改和结果。docs/interview.md：从真实实现生成追问，再由自己回答。
只有到这时，才回头更新简历。每一句项目描述都应该能指向一处代码、一个测试、一份文档或一次真实的排错。
项目不必大，但经历必须属于你
AI 可以把搭骨架、写样板代码和查资料的时间压得很短，却不能替你拥有这段经历。
一个项目能不能写进简历，不在于它有多少个页面，也不在于技术栈是否足够热门。真正的标准是：面试官顺着简历中任何一个动词问下去时，你是否还有真实的代码、判断和结果可以继续讲。
这才是“经得住追问”。