我有不少 AIGC 项目、课程和创作材料，它们可以用来说明不同的能力。准备一个 AI 视频岗位的简历，和准备一个偏内容运营的岗位，选进去的项目、展开的篇幅，当然会不一样。
于是，写简历变成了几件连在一起的事：从材料里找经历，围绕岗位组织内容，留下对应的版本，再记录投递进度。只让 AI 帮我润色其中一段，解决不了这整条流程。
我现在用 Agent 整理材料和简历版本，用飞书多维表格管理岗位与投递状态，再通过飞书 CLI 把两边接起来。这里面最值得讲的，是每一步处理什么，以及处理完之后，究竟留下了什么。
先讲清楚：这三个东西分别做什么？
飞书多维表格，是我查看求职进度的地方。可以先把它理解成一张能放附件、切换视图的表：一行记录一个岗位，不同的列分别记录公司、岗位链接、简历和状态。飞书还有文档等能力，这篇先只讲我用到的这张表。
CLI，就是用文字命令操作软件的入口。它的全称是 Command Line Interface，中文叫命令行界面。我们平时打开飞书、点进表格、查看一行数据；通过飞书 CLI，也可以用一条命令请求读取记录，或者更新指定字段。
Agent 负责理解任务、拆分步骤，再调用工具完成它。我说要整理某批岗位，它需要判断该读哪些材料、找哪张表、填写哪些字段。CLI 负责执行相应操作，再把结果返回给 Agent。判断和执行，是这里的两种工作。
所以，我不需要把每个需求都翻译成命令。我用自然语言交代事情，由 Agent 调用 CLI；飞书里的记录，让我能回头检查它实际做了什么。
简历的内容和投递的进度，分开放
我的原始经历、项目材料和简历版本，主要保存在本地的个人品牌系统里。飞书这边有一张叫“简历整理”的多维表格，用来记录岗位，以及后续的简历附件和投递进度。
这个分法有一个很实际的原因：经历是可以反复使用的材料，投递则是一次具体的事件。同一段 AIGC 项目经历，可以出现在几份简历里；每份简历面向哪个岗位、后来有没有投出去，需要分别记。
| 我想查什么 | 表里记录什么 |
|---|---|
| 这是哪个机会？ | 公司名、岗位名称、岗位介绍附件、岗位链接 |
| 这次用了哪份材料？ | 简历附件 |
| 事情走到哪一步？ | 投递时间、投递状态、面试进度、备注 |
对创作者来说，这也适用于作品集：一份短片可以用于多个岗位，但递给对方的是哪一版作品集、哪些项目放在前面，应该有对应记录。否则，材料留得越多，下一次准备时越容易重新翻一遍。
一次简历任务，是怎样往下走的？
我把主要工作分给了三个 Agent 角色：岗位雷达找机会、整理完整的岗位要求；简历制作根据已有事实组织内容；投递管理负责把岗位和后续进展记录到飞书。我会先选定要继续推进的岗位，再让后面的工作往下走。
比如，为一个 AI 视频生成师岗位准备简历时，简历制作 Agent 要先读岗位要求，再从已有项目中挑选相关经历：哪些项目展开写，哪些只提一句，哪些暂时不放。我的本地系统里，已经有对应岗位的简历版本和版本记录。
这里的重点是“选择和组织”。同一个项目，面对不同岗位，可以强调视频制作，也可以强调工作流与协作；项目发生的时间、我的职责和实际做过的事，仍然要保持一致。
有了版本记录，我才能知道这一份简历为什么这么写。等到实际投递，再把对应材料和进度关联起来，回看时就能顺着岗位找到当时那一版简历。
一个真实例子：42 条岗位，写进表里以后呢？
2026 年 8 月 12 日，我的系统把一批已经筛选的岗位写入了飞书。同步记录中一共有 42 次新建，每条都记录了写入成功，并通过了读回核对。
“读回”很好理解：把内容写进去之后，再从飞书读取这条记录，检查写入的结果。它比一句“已经完成”多了一步确认。
但这 42 条记录，当时只填了公司名、岗位名称和岗位链接，还没有关联简历版本。它们说明岗位已经建档，不能算成 42 次投递。
这个区别会影响我怎么看进度。一批岗位整理完了，我下一步要做的是复核和选择；简历准备好了，要看是否能投；实际投递之后，才进入跟进。进度汇报得说清楚完成的是哪一步，光报一个数量，很容易让人误会。
CLI 具体怎么用？看一次“读”和一次“改”
读取是最容易理解的一步。Agent 要查看表里的岗位，可以调用类似下面的命令。Base Token 用来指定哪份多维表格，Table ID 用来指定其中哪张数据表；命令里的两个占位符，要换成自己的标识。
lark-cli base +record-list \
--base-token "<BASE_TOKEN>" \
--table-id "<TABLE_ID>" \
--limit 5 \
--format json \
--as user这条命令最多读取 5 条记录，以 JSON 这种结构化文本返回。Agent 可以从中继续找目标岗位。这里的 5 是本次读取的数量上限，不是表里一共只有 5 条。
修改时，还要先找到准确的那一行。在我 2026 年 7 月的审计记录里，一个春招岗位的投递状态从“未开始”改成了“寄”。这次只改状态，其他字段保持原值，然后重新读取确认结果。
“寄”这个字看起来很口语，但它也是我表里已有的状态，关联着黄色的整行填色规则。如果 Agent 自作主张换个说法，原来的颜色规则就可能对不上。工具要理解我的记录习惯，具体到一个字段的原文。
因此，投递管理 Agent 的操作顺序是：先看字段和现有记录，查重并定位到唯一一行，再修改需要变动的字段，最后读回核对。否则一句“帮我更新”，也可能变成重复新增。
有用的展示，要让我知道下一步做什么
我的表里已经用颜色区分状态：“下offer”对应绿色，“寄”对应黄色，“已下架”对应浅黄色。看表的时候，状态可以先被颜色提示出来，再去看具体记录。这里是 Agent 通过 CLI 更新数据，飞书按已有规则把它展示出来。
如果要进一步做统计，可以配置视图或仪表盘；前提是先把状态记准确。岗位已建档、简历已准备、已经投递，这几种状态混在一起，即使画出了图，也回答不了求职推进到哪一步。
我更希望一次汇报能告诉我三件事：这次新增或修改了什么，结果有没有核对，还有什么需要我处理。回到那批 42 条岗位，一个有用的汇报就是：岗位信息已写入并核对，简历尚未关联，请我复核后决定接下来推进哪些。
想照着做，先跑通一个岗位
刚开始做，可以先建一张小表，放公司、岗位、链接、简历附件、状态和备注，再把已有简历、项目材料交给 Agent。完成 CLI 安装和授权后，先让它读出表的字段和一条记录，确认找对了地方。
接着选一个真实岗位，把任务交代具体。比如可以这样说：
给 Agent 的任务示例先读取这个岗位的完整要求，从我已有的项目材料里挑选相关经历，说明为什么选它们。生成一份简历草稿，并记录版本。飞书里如果已经有这个岗位，就找到原记录；没有再新建。我还没投递，先保留这个事实，等我确认投递后再更新进度。
跑完这一轮，我会检查：选进简历的经历是否有依据，版本是否能找到，表里的记录是否准确。这几件事接得上，再增加批量整理和更多展示方式。
对我来说，这套工具的价值，是让整理过的材料、写过的简历和推进过的岗位都能接着用。这样，下一次面对一个新机会，我可以把时间放在判断“这次该拿什么经历说服对方”上。