我一直很喜欢“开源”这个词。它代表着分享与自由，但过去总是高频出现在程序员之间、代码世界之中。好在，现在是AI时代，万年文科生的我也可以开源一次了。
之前已经介绍过我发布的Skill，现在聊聊这些Skill——或者我更愿意称之为“作品”——应该以什么方式呈现。因为不只是Skill，后续我也会继续根据个人经验与实践，结合百家之所长，发布Workflow、Hook、Loop等不同类型的AI作品。
一般来说，做完第一个可以公开的Skill以后，最常见的处理方式当然是放到GitHub。但是，从用户角度看，GitHub经常需要架梯子，访问并不方便；从我个人的角度看，我需要的也不只是另一个下载页面，而是一个个人AI作品集。
它既要把我已经完成的Skill、Workflow和其他AI工具长期沉淀下来，也要让公众号读者能够以更低的门槛了解、获取和使用。作品公开以后，公众号留言和私信还可以把真实反馈带回来，促使我继续修正、迭代和改进。
而且，建立网站这件事本身也是目标之一。对于一个非专业开发者来说，从零确定需求、设计页面、生成和调试代码，到选择、购买域名并最终发布，是AI时代最直接的一次实操训练。
于是，我把这些目标放在一起，做了z-skill.com：一个连接公众号和GitHub的个人AI作品集网站。
这个作品集里现在有什么
目前，z-skill.com已经公开了六项作品。其中，多格式转Markdown、微信公众号文章读取和网页内容批量读取是正式版；登录态网页检索、知识卡产出与调用和法律实务文章写作仍处于公开候选阶段，还需要继续验证和迭代。
网站的使用路径很简单。
打开首页，首先看到的是最近发布的三项作品。如果想查看完整内容，可以进入工具目录，根据类型和状态进行搜索与筛选。找到感兴趣的作品以后，再打开详情页，查看它具体解决什么问题、当前是什么版本、在哪些环境中做过测试，以及存在哪些限制和隐私风险。
确认作品适合自己以后，可以复制页面提供的安装Prompt，让支持相关操作的Agent阅读说明并完成安装，也可以直接下载ZIP文件。熟悉GitHub，希望进一步查看源码、测试记录和历史版本的读者，则可以从详情页进入对应的GitHub仓库。
每个作品都是一本详尽的说明书
我希望z-skill上的每个作品，都不只是一个可以下载的ZIP文件，而是一本尽可能详尽的说明书。
打开作品详情页，首先要能够看明白它解决什么问题、适合在什么场景下使用。接下来，还应当说明当前版本、安装和使用方式、已经测试过的环境与能力，以及仍然存在的限制、风险和待验证事项。
这些信息并不都属于作品的“优点”，但它们同样会影响读者是否使用。一个作品能够成功处理哪些任务固然重要，在哪些情况下可能失败、是否会调用第三方服务、数据会不会离开本地，也应当在安装和下载之前说清楚。
例如，多格式转Markdown已经作为正式版发布，但“正式版”并不意味着所有格式、所有环境都已经验证通过。网站会同时展示已经完成的测试和明确的失败项，让读者根据自己的文件类型和使用环境作出判断，而不是只看到一个笼统的“支持多种格式”。
我理解的作品交付，不是把文件上传以后就结束了。功能本身、安装方法、测试结果、失败情况、隐私边界和已知限制，合在一起，才构成一个相对完整的作品。
公众号、网站和GitHub，各自负责什么
做完z-skill以后，我对这三个载体的分工也逐渐清楚了。
公众号负责讲述。一个作品为什么会出现，它来自什么真实需求，中间经历了哪些尝试，我最终形成了什么判断，这些内容更适合通过一篇完整的文章展开。读者在这里看到的，不只是一个工具，也包括工具背后的经验和思考。
z-skill负责展示和交付。它把作品集中放在一个入口中，用相对直观的方式说明用途、版本、测试情况、限制和隐私风险，帮助普通读者判断作品是否适合自己，并完成安装或下载。
GitHub则负责保存权威版本。源码、版本记录、测试文件和历史发布都留在那里。对熟悉GitHub的读者来说，可以进一步核查作品的具体内容；对我来说，它也是每个作品持续维护和更新的基础。
三者并重。公众号解决的是“为什么做”，z-skill解决的是“这是什么、是否适合我、怎样获取”，GitHub解决的是“权威版本和技术细节在哪里”。
它们连接起来以后，一件AI作品才有了一条相对完整的发布路径：先把经验讲清楚，再把作品交付出去，最后保留可以持续维护和核验的版本。