周三下午，一个自由设计师把交付文件夹整理好了。logo、三张发布图、一份网站联系邮箱更新说明，文件名一个不差，看上去可以点发送了。

打开网易新闻 查看精彩图片

但打开一看：logo 是不透明的，两张发布图字节完全相同，那份"说明"里只有一段欢迎语，没有联系邮箱的操作步骤。文件名对，不等于交付对。

这就是 HandoffReady 想解决的问题。它是一张给网页/设计自由职业者和小型工作室用的"导出文件检查台"：把事先约定的需求、要发出去的原始文件和一份客户交付记录连在一起。本地运行的 Gemma 负责提出需求项和对应的支撑文件，审核的人确认范围、查看发现的问题，再记录哪些已完成、哪些还欠着。

它设想的付费形态是每次交付前跑一遍可重复的检查，并留下一份记录，方便向客户解释哪些工作还没收尾。整个过程不需要把客户搬进另一个项目管理平台。这只是个商业假设，不是已被验证的需求——目前还没有自由职业者试用、付费或可量化的节省记录。

一次故意留了尾巴的演示

演示走的是这样一条路径：先对着需求确认清单，一段精确的引用能帮人定位某条要求，但格式、数量、遗漏的细节仍要审核者自己核。然后检查文件包——两个发布文件字节相同，logo 里没有任何非透明像素，只有欢迎语的说明缺了客户要的联系邮箱步骤。

接着把 logo 换成修正后的原始文件。文件包一变，之前的审核就过期了，得重新查。最后导出一份新的客户记录：旧快照原样保留，新快照仍然记着重复图片和说明缺失这两个缺口。

结尾是刻意的不完整修正。三个文件名证明不了三张不同的设计，透明像素证明不了一个做对的 logo，一个看起来像模像样的文件也证明不了它满足了需求。真正有用的产出是一份交付记录，带着审核结论、未完成事项和支撑原始文件的身份信息——但文件本身要另外发，记录只解释审核，它不是交付物，也不等于客户验收。

为什么这种事要交给模型

常规检查能确认尺寸、格式、字节是否相同这类属性，但很难把一段改写过措辞的需求，连到一份文件名出人意料的说明文档上。Gemma 做的就是提出这种关联，并从散文式描述里抽出一份清单草稿。

一次评估在十份人工编写的合成文件包上比较了关联方法，共 27 个文件。在需求另行提供的前提下，一个锁定"文件名加已检查文本"的基线方法找出了 19 对关键支撑文件中的 13 对；Gemma 找出了全部 19 对，但同时给出两处错误的格式替换，被格式检查环节从同一批输出里剔掉了。

有一个具体例子：distribution.txt 里写着要在摊位入口附近和社区公告栏放一份通知，Gemma 把它连到了"传单摆放说明"这条需求上，基线方法漏掉了这一对。这点增益在这批数据上是多出六对支撑关系，它不代表通用准确率，也不证明自动抽取的流程已经完整。

抽取环节更弱：21 条强制义务里有 15 条达到预设的覆盖规则，六条提案漏掉了必需的格式细节。实际应用还曾把只有欢迎语的说明判为支持联系邮箱步骤——引用是真的，关联却没用。演示保留了这个错误，这也是为什么范围确认和人工审核是产品的核心。

人和开源的位置

这个项目的产品方向由作者本人定：选网页/设计自由职业者这个场景，坚持免费本地路线，要求一条带反复审核的完整交付流程。实现、测试、界面、评估和这篇文章有 AI 编程代理参与。下一步是把工具交到真正的自由职业者手里——脚本化的示例批准不算客户判断。

选本地开源模型还有一个现实理由：一份自由职业文件包里，可能有内容所有者没授权上传到外部 AI 服务。本地跑开放权重模型给了另一种选择，没有按次计费的模型 API 账单，但硬件、安装和电费仍然存在。开源也让边界可查：哪些属性被检查、哪条建议来自模型、来源证据怎么绑定、决策何时过期。

已验证的环境是 Apple Silicon macOS 上的单本地用户。应用不执行网站，也不认证视觉设计质量，本地存储未加密。下一个产品测试很直接：一个自由职业者能不能在很少帮助下完成一次真实交付，觉得导出的记录有用，并且愿意再用一次。