GitHub上平均每个开发者维护着12个公开仓库，但能把它们变成像样作品集的人不到7%。剩下的93%要么在复制粘贴里耗尽耐心，要么干脆放弃——直到有人把MCP协议塞进了Notion的API缝隙里。
这个叫Lamefolio AI的工具，本质上是一场对"手工造轮子"的嘲讽。开发者提交GitHub账号，可选上传简历PDF或截图，Gemini 2.5 Flash（谷歌的多模态大模型）在后台跑完四轮对话，输出的是一份直接写进Notion数据库的完整作品集。没有模板挑选焦虑，没有"关于我"部分的尬写循环。
把流水线拆成5个"专科医生"
作者原本可以写成一个臃肿的单体服务。但他选择了服务导向架构——五个模块各管一摊，像急诊室的分诊台。
GitHub服务是纯粹的"数据搬运工"。直接调用Octokit REST接口，一个仓库一次请求，拉取元数据加深度信息。这里没有大模型参与，零token消耗，零幻觉风险。作者的原话是：「获取GitHub数据不需要LLM推理，这是纯数据活。」
创意部分交给Gemini。AI服务承担四项任务：解析简历（支持PDF和图片的多模态输入）、生成作品集结构、处理对话流、决定调用哪些Notion工具。最精巧的设计是函数调用循环——Gemini选择工具，编排器执行，结果回传，Gemini再决策。单轮对话最多迭代5次。
转换器负责把AI生成的结构变成Notion能识别的块格式。四种视觉模板可选，每种有独立的排版逻辑。最后是发布服务，对接Notion官方API。
关键决策：只有需要创造力的环节才上LLM，其余全部确定性执行。这直接砍掉了两类最烦人的bug——烧token和编URL。
MCP协议被用成了"双面间谍"
这个项目的野心不止于一次性生成。作者同时接入了Notion的官方MCP服务器和原生Client SDK，形成互补。
MCP（模型上下文协议，Anthropic开源的标准）在这里扮演扩展接口的角色。它允许外部工具以标准化方式暴露功能给AI模型，相当于给Notion装了一个通用插座。而核心的流水线——从GitHub拉数据到最终落库——走的是更稳定的SDK直连。
这种"双轨制"的微妙之处在于：MCP负责开放性，SDK负责可靠性。当用户想后续修改作品集时，可以通过MCP对话式操作；而初始生成这种对稳定性要求高的场景，用SDK兜底。
作者提到一个细节：编排器的错误传播机制。五个服务中任何一个失败，整个链条会带着具体位置信息中断，而不是像单体架构那样抛出一团模糊的500错误。
为什么说这是对旧工作流的"背刺"
传统作品集维护的痛点被拆解得很细。复制粘贴项目描述、技能栏格式化、半年一更的过时焦虑——这些被抽象成"数据同步问题"而非"写作问题"。
工具的定位也很克制：AI构建，用户拥有。输出落在Notion意味着完整的后续编辑权，不是生成一个封闭文件就结束。四种模板风格覆盖了从极简到视觉冲击的不同偏好，但核心逻辑是结构化的数据填充而非套壳美化。
技术选型上有意思的是对Gemini 2.5 Flash的用法。这个模型以速度和性价比著称，作者把它放在"需要快速迭代决策"的环节——工具选择循环。而重度的内容生成（简历解析、结构规划）同样由它承担，说明在多模态输入处理上，Flash的能力已经足够替代更大的模型。
一个未被明说的赌注：MCP协议正在成为AI工具链的"USB-C"。Notion官方支持MCP服务器，意味着这类集成不再需要hacky的爬虫或逆向工程。Lamefolio AI可能是第一批把这个协议用进生产级工作流的案例之一。
作者在提交文档里埋了一句：「开发者讨厌造轮子，但更喜欢掌控感。」这解释了为什么输出到Notion——一个用户已经熟悉、可以任意改造的协作平台——比生成一个静态网站更契合目标人群。
最后一个技术细节：整个流水线是顺序执行而非并行。作者解释这是为了错误可追溯，但也暗示了当前MCP生态的一个局限——跨服务的状态共享和事务一致性，还没有成熟的分布式方案。
当GitHub提交记录变成可自动同步的活数据，作品集维护会不会从"半年一更的大扫除"变成"随代码一起提交的常规操作"？
热门跟贴