拒绝AI胡编：一款"说不了谎"的求职信生成器是如何炼成的

当AI求职信开始"替你撒谎"

一位开发者在 Reddit 上分享了自己的真实经历：上个月他连续尝试了三款 AI 求职信生成工具，结果每一款都在"无中生有"。其中一款告诉招聘方他拥有"5年以上 Kubernetes 生产经验"，而他从未在生产环境中碰过 Kubernetes；另一款则声称他"领导过一个40人的工程师团队"，但他实际上从未管理过任何人。

这种"幻觉"（hallucination）看似能让简历更漂亮，实则是求职者的定时炸弹——面试时任何一个追问都可能当场拆穿。于是这位开发者干脆自己动手，做了一款名为 CoverCraft 的工具，核心设计原则只有一条：AI 无法声称任何无法追溯到你真实简历文本的内容。简历里没写的，求职信里就不会出现。

四个让AI"不敢说谎"的工程设计

真正有意思的不是"做一个求职信生成器"这件事本身，而是作者为了对抗 LLM 的幻觉倾向，在工程层面做的四处关键取舍。

1. 匹配评分不交给 LLM

大多数工具让模型直接吐出一个"95% 匹配度"的随机数字——这种分数既不可复现也不可信。作者把任务拆开：LLM 只负责分类（STRONG_MATCH / PARTIAL / MISSING），而最终分数由普通应用代码按固定公式计算：

score = (strong*1.0 + partial*0.6 + transferable*0.4) / total

这样一来，同一份简历配同一个岗位描述（JD），每次得到的分数完全一致，没有任何随机性。把"判断"留给模型、把"计算"留给代码，是一种值得借鉴的职责分离思路。

这种「判断与计算分离」的思路，对应软件工程中的「关注点分离」（Separation of Concerns）原则。LLM 本质上是概率采样器，每次输出都受温度参数（temperature）影响，相同输入可能产生不同结果。将数值计算托付给模型，等同于用骰子代替算盘——即便结果看起来精确，背后也没有可审计的逻辑链条。反过来，让模型只做「分类标签」这类定性判断，再由确定性代码接管量化环节，能同时获得两者的优势：模型的语义理解能力 + 代码的可复现性。这也是为什么金融风控、医疗诊断等高合规场景中，AI 通常被设计成「辅助人工决策」而非「直接输出结论」——职责边界的清晰划定，本身就是可靠性的来源。

2. 用 GitHub 提交记录为能力背书

简历上写"架构了一套多节点 Agent 系统"这类描述，听起来很唬人，但真假难辨。CoverCraft 通过 GitHub MCP 工具拉取用户公开仓库的真实提交历史，把能力声明锚定到具体的 commit hash 上。如果你声称精通 Kubernetes，但提交记录里没有任何相关痕迹，系统会直接标记出这个落差，而不是放任 LLM 绕过去把话圆回来。

GitHub MCP（Model Context Protocol）是 Anthropic 于2024年底推出的开放协议，允许 LLM 通过标准化接口调用外部工具与数据源，而无需为每个工具单独定制集成逻辑。在 CoverCraft 的架构中，Python MCP 服务器充当中间层，负责与 GitHub API 通信、拉取仓库元数据和提交历史，再将结构化结果传递给语言模型。这种架构的关键优势在于「事实外挂」：模型不再依赖训练时记忆的知识，而是实时查询用户真实存在的数字足迹。Commit hash 作为不可篡改的时间戳记录，具备天然的可审计性——任何人都可以访问对应的公开仓库加以核实，这正是将「能力声明」从主观描述提升为可验证证据的关键机制。

3. 对抗性"红队"审查夸大措辞

生成完成后，一个对抗性审查模块会介入，把被夸大的动词"降级"：比如 "spearheaded"（牵头主导）改成 "led implementation of"（负责实施），"pioneered"（开创）改成 "developed"（开发）——前提是原始简历不足以支撑那种强度的表述。这相当于给输出加了一道"去水分"的闸门。

「红队」（Red Team）一词源自冷战时期军事对抗演练，指专门扮演攻击方来检验防御漏洞的团队。在 AI 安全领域，红队测试已成为发布大模型前的标准环节——让一组人专门尝试诱导模型输出有害或错误内容，以此评估模型的安全边界。CoverCraft 将这一思路内化为自动化流程：第一个模型实例负责生成求职信，第二个模型实例则被明确指示以「挑剔审查者」身份介入，专门寻找表述与原始简历之间的夸大落差。两个模型实例相互对立，而非协作，这是 Multi-Agent 架构中「对抗性协作」（Adversarial Collaboration）的典型应用，也是提升生成内容可信度的有效工程手段。

4. 人工审批关卡

工具会通过实时网络搜索做公司调研，但这些信息不会自动注入提示词。它们以"卡片"形式先展示给用户，由你逐条批准或拒绝，杜绝了任何信息悄悄混进生成内容的可能。

技术栈：全部跑在免费额度上

作者公布了完整的技术组合：Next.js + Python MCP 服务器 + Gemini（针对 429 限流做了 fallback 与熔断机制）+ Tavily 搜索 + Langfuse 链路追踪。整套系统运行在各家的免费额度上，运营成本为 $0。

值得一提的是，这个项目作为一个独立注册的 MCP 服务器，被 M8ven 的 MCP Trust Index 收录并标记为"Verified Publisher"（已验证发布者），还有实时监控——据作者说这并非他主动提交，而是对方的爬虫自动发现并审计的结果。这在一定程度上为项目的真实性提供了第三方旁证。

Langfuse 是一个开源的 LLM 可观测性（Observability）平台，专门用于追踪、调试和评估语言模型应用的完整调用链路。在 AI 应用中，一次用户请求往往触发多个模型调用、工具调用和数据查询，若无专门的追踪工具，排查问题或优化性能几乎无从下手。Langfuse 记录每次调用的输入输出、耗时、Token 用量及成本，并支持将多个调用组织为可视化的「Trace」树形结构。对于 CoverCraft 这类多步骤 Agent 系统——涉及简历解析、GitHub 数据拉取、匹配评分、生成、红队审查等多个环节——链路追踪不仅是调试利器，也是日后迭代优化的数据基础。Langfuse 提供免费托管额度，与整套零成本技术栈的设计取向一致。

一个没有标准答案的产品哲学问题

作者在帖子末尾抛出了两个耐人寻味的问题，也正是整个项目的价值争议所在。

第一个问题：招聘时你真的会读求职信吗，还是说这种格式早就名存实亡了？ 这触及了求职信本身的存在意义——如果招聘方根本不看，再诚实的生成器也是屠龙之术。

第二个问题更尖锐：面对简历中缺失的技能，作者选择了"坦诚承认落差"而非"干脆跳过不提"，他自己也在反思这是不是个糟糕的决定。从博弈角度看，承认不足可能显得真诚，也可能在初筛环节被直接刷掉。这没有标准答案，取决于你面对的是看重诚信的招聘官，还是只做关键词匹配的 ATS 系统。

对AI产品设计的启示

抛开求职场景，CoverCraft 最大的参考价值在于它展示了如何系统性地约束生成式AI的幻觉：把确定性计算从模型中剥离、用可验证的外部数据源（GitHub commit）做事实锚定、用对抗性二次审查过滤夸大、以及用人工审批守住最后一道关。

这套"不信任模型、处处留证据"的设计范式，适用于任何对事实准确性要求高的AI应用——无论是法律文书、医疗建议还是金融分析。当行业还在为"模型越大越好"狂欢时，这类从工程纪律出发对抗幻觉的尝试，或许才是落地应用真正需要的方向。