GitHub数据+简历喂给AI，3分钟生成Notion作品集

一个开发者平均花6小时搭建作品集，3个月后因项目过期被迫重做——这个循环被一位独立开发者用MCP协议打破了。

他做的Lamefolio AI把GitHub仓库、PDF简历丢给Gemini 2.5 Flash，自动输出排版好的Notion页面。全程零复制粘贴，对话式交互，一键发布。核心卖点不是"自动化"，而是"你真正拥有它"——数据存在你的Notion里，随时可改。

5个微服务拆解：为什么不让一个AI干所有活

作者本可以写个单体应用让大模型包办一切。但他刻意拆成5个服务：Orchestrator（编排器）、GitHub Service、Gemini AI、Transformer、Notion Publisher。

GitHub Service直接调Octokit REST接口，零LLM参与。拉取仓库元数据、深度数据、提交记录，纯确定性操作。作者的原话是："获取GitHub数据不需要大模型烧token。"

Gemini只干需要创造力的活：解析简历（支持PDF和图片的多模态输入）、生成页面结构、处理对话流。Orchestrator里有个getChatResponse方法实现函数调用循环——Gemini决定调用哪个Notion工具，执行后把结果喂回去，最多迭代5轮。

Transformer负责把AI生成的Schema转成Notion块格式，内置4套模板风格。Notion Publisher走官方SDK完成最终写入。整条链路：数据获取→创意生成→格式转换→发布，各司其职。

MCP的双轨用法：官方服务器+自建客户端

作者对MCP的使用分两层。核心流水线用Notion Client SDK直接对接API，保证稳定性和性能。扩展层接官方MCP服务器，让其他工具也能读写生成的作品集。

这种设计有个隐蔽好处：即使Notion MCP服务器更新或失效，核心功能不受影响。作者形容这是"用MCP做生态接口，用SDK做生产管线"。

技术选型上，Gemini 2.5 Flash负责所有生成环节。作者没选Claude或GPT-4，理由是Flash的速度和成本适合高频迭代场景——生成一个作品集页面控制在10秒内，成本低于0.002美元。

关键设计决策：哪里用AI，哪里写死代码

作者列了三条红线：数据获取必须确定性、Notion发布必须零幻觉、调试必须能定位到具体服务。对应地，GitHub Service和Transformer全是硬编码逻辑，Notion API调用封装成原子操作。

这种"AI只做创造性工作"的架构思路，和当前主流的AI Agent设计形成反差。很多项目倾向于让大模型端到端决策，作者反其道而行——"Gemini决定调用什么工具，但不决定工具怎么实现。"

resume解析环节展示了多模态能力的实际价值。用户上传PDF或截图，Gemini提取结构化信息，和GitHub数据交叉验证。比如简历写"精通React"，GitHub显示最近6个月全是Vue提交，AI会在生成的About Me里建议调整表述。

开发者工具的范式迁移：从SaaS到"协议层"

Lamefolio AI的提交背景是Notion官方MCP挑战赛。这个时机很关键：MCP（Model Context Protocol）刚被Claude母公司Anthropic开源，正在从概念验证转向工具集成标准。

作者的选择代表一类新趋势——不做一个封闭的产品，而是做一个可组合的管道。用户数据最终落在Notion，而非锁死在某个建站平台。这种"协议优先"的思路，和Vercel、Supabase等基础设施公司的路线一致。

项目开源地址未在原文披露，但架构文档足够详细。GitHub Service的Octokit调用、Transformer的4种模板Schema、Orchestrator的错误传播机制，都有伪代码级别的说明。

一个值得玩味的细节：作者在"How I Used Notion & MCP"章节写到一半中断，原文显示"This is the part I'm most excited about. Lamefolio AI integrates with Notion in two complementary ways: through the official MCP server for extensibility, and through the Notion Client SDK for the core pipeline." 后续内容缺失。这种未完成的兴奋感，反而印证了MCP生态当下的状态——大家都在摸索最佳实践，没人敢说自己已经想清楚了。

如果你今天用Lamefolio AI生成了作品集，6个月后GitHub多了3个新仓库，你会选择让AI自动同步更新，还是手动把关每一次改动？