「参与」还是「主导」:开源插件目标一键复现阿酥百万offer简历

AI代码蜂巢X

探索编程的无限可能

编辑：嘉禾

事情得从 3 月说起。

把「参与」写成「主导」，在国内互联网不是新鲜事，存在了少说十几年。潜规则是没人回头查。实习生本来就摸不到核心模块，一个普通背景的年轻人想在千军万马里被看见，把边角料往核心上靠一点，这个动机不难理解。以前这么干效率高、成本低，赌的就是招聘方懒得核实。

开源把这个赌注改了。commit 是谁提交的、动了哪几个文件、PR 过没过 review、贡献者列表里排第几，全部记在公开页面上。前同事不用查内部仓库，打开 GitHub 就有。包装的容错空间，一下被压掉了。

经济学里有个挺老的概念叫信号理论，Michael Spence 1973 年提的。说的是在信息不对称的市场上，学历、履历这些之所以有用，是因为它们构成信号，而信号的价值取决于伪造成本。伪造成本一旦低于它带来的收益，信号就会贬值，最后所有人都得去找新的信号。简历上每一行字都是这个逻辑，只不过过去校验成本太高，这个机制一直没跑起来。

开源贡献记录把它跑起来了

所以这轮讨论后来从「她到底行不行」滑向了另一个问题，筛选流程为什么会放过一个本可公开核验的信号。牛客和脉脉上有人整理了可能的变化方向，开源经历要拿去比对 commit 记录，网红人设从加分项变成需要额外核验的项，背调往实习经历延伸，现场编码的权重上升。这些都是社区里的个人观察，不是哪家公司的政策。但方向不难判断，求职表达里能被验证的部分在变多，能含糊过去的空间在变少。

在这件事发酵后大概一周，2026 年 8 月 12 日，一个叫 ASu-skills 的仓库在 GitHub 建了起来。

它把求职流程拆成了九个入口，按阶段看会更清楚。

准备阶段三个

/contributor 帮你找并完成一条可验证的开源贡献，这里有个细节挺关键，未合并的 PR 只能记成「协作中」，不许写「已被采用」。/evidence-recap 把 AI 编程对话和交付记录整理成证据链。/project-guide 把已有项目仓库拆成源码导学、面经和阅读路径。

表达阶段两个

/great-resume 做岗位定位和经历改写，/make-resume 出可编辑的 HTML 简历和 PDF。

投递阶段三个

/job-match 拿 JD 对照真实经历，输出要求与证据的对照矩阵和硬性门槛。/job-apply 连浏览器填申请表，但它会停在提交按钮之前，不会替你投出去。/offer 管投递、测评、面试、Offer 的状态。

/interview 独立在外，从简历里抽出需要验证的主张，一次只问一个问题，答得含糊就继续追。

九个入口串起来是一条完整链路，也可以单独调用其中一个。

真正值得看的是它怎么处理「参与」和「主导」这三个字的差别。它把争议点本身变成了一组可校验的数据结构，全程没有对争议表态。

载体是一个 claim-evidence ledger，项目里叫「主张—证据账本」。每条简历表述记成一条 claim，先定档，再定状态。定档用 responsibility_level，只有四个允许值：参与、负责模块、主导方案或交付、项目负责人。定状态用 verification_status，同样四个：已确认、待确认、已过期、不采用。

字段不难，规则才是关键。这些规则的方向是一致的。

举个具体的。两份材料里的 GPA 分别是 3.70 和 3.73，账本不允许新增两条互相矛盾的「已确认」，只能保留一条，把两个来源并列写进 sources，状态置为「待确认」，冲突写进风险字段。

第二道关是往下传导。只有「已确认」的主张能进入正式简历，带「待确认」的表述在草稿里必须保留 【待补】 占位，导出最终 PDF 之前要么删掉，要么补齐。

第三道关专门管时间。账本单设了「已过期」一档，用来处理在读年级、论文在投状态、Star 数这类会变的事实，过期之后不能再当最新事实用。

三道关之后还有一份交付检查：团队成果不能自动变成个人成果，对外材料的每条强主张都要能回指一条账本记录。

还有一条更有意思。账本里有个 interview_details 字段，要求填上这条主张能在面试追问里展开的决策、难点、验证和结果。翻译一下，一句「主导」要写进简历，你得先能把它讲到被追问三层。

项目还配了个零依赖的校验脚本 validate_claim_ledger.py，查 JSON 结构、必填字段、枚举值、重复 ID 和日期格式。

docs/ 底下那份端到端案例也值得看。它用虚构人物「林舟」走完九个入口，文件开头就声明人物、学校、项目、仓库、公司全是虚构。案例里如实保留了这位虚构候选人的短板：只有 3 名课程组成员用过，没有公开用户量，英语成绩待确认。还专门写了一条，不得把「待补充」自动改成更好看的事实。

用虚构样本演示合规流程，这个取舍挺克制。九个入口的完整链路都能看到，但没有任何一份可以直接照抄的包装模板。

README 里那节「事实边界」一共 7 条，其中几条几乎是照着这次争议写的：只有有证据时才使用「主导」「负责人」「Owner」，不把计划要做的事写成已经完成，不把 AI 生成的代码成果算作未经证实的个人能力。

入口清单被收敛到根目录的 skills.registry.json，由 npm run sync:skills 生成六个宿主的插件清单、安装脚本和 README 总览，CI 再用 --check 校验一致性。

六个宿主、九份 skill 目录、多份安装文档，靠手工维护漂移是迟早的事。把清单变成数据、把同步变成构建步骤、把一致性交给 CI，是常规做法，只是个人项目通常会跳过这一步。

Claude Code 两条命令：

用 Codex 的话，把仓库链接发给它、说明要装插件就行。TraeWork、Qoder、OpenCode、WorkBuddy 各有各的入口，README 里写着。

那这东西到底值不值得装。

先看它实际做了什么：把无法核验的表述挡在最终文件之外。换成流程语言，它把求职表达从修辞问题转成了证据问题，而证据问题的可接受答案数量有限，通常只有一个。

这个方向跟「简历包装」给人的联想是反的。工具约束不了招聘方，能约束的只有求职者这一侧，而约束的方向是收紧。

边界也很清楚。校验脚本只检查结构确定性与状态矛盾，它不知道你的经历是不是真的，也不会联网核对那个 PR 究竟合没合。它是一层流程约束，替代不了背调。

至于招聘端会不会真的更看重可核验证据，取决于面试环节有没有人真的打开那个 commit 页面。工具能管的只有求职者这一半。

回到最开始那三个字。参与，还是主导。

这套东西没有替任何人回答这个问题，它只是把答案从「你敢不敢写」换成了「你答不答得上来」。前者是修辞，后者是事实，而事实这一侧能腾挪的空间要小得多。

你现在的简历里，有几句话在被追问三层之后还站得住？

有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING