AI 时代的小软件,为什么一定要上架?

导读：AI 可能降低小工具的开发成本，上架、支付、发现与建立信任的成本却不会自动同步下降。这类新增的长尾软件，需要与自身规模相称的分发方式。

概念版画：分散的软件发布节点，通过多条路径被发现，没有统一上架中心。

上一篇《AI 让那些“不值得做”的软件有了机会》谈到，AI 可以降低一部分小工具的实现和迭代成本，让过去不值得专门投入的需求，也有了被满足的可能。

这篇文章讨论的，正是这类在 AI 时代更容易做出来的长尾软件，并不是泛指过去所有的小软件。新的矛盾是：开发成本可能明显下降，但上架、收款、获得曝光和建立信任的成本，并不会自动按同样的幅度下降。做出工具之后，如何让别人安全、方便地用起来，反而可能成为更重的负担。

这里说的“上架”，主要是把软件提交到 Apple App Store、Google Play、设备厂商或第三方经营的应用市场，并不是说每个作者都要自己搭建一家商店。自己建站销售、收款当然也是一种选择，但它和向现成商店提交应用，是两条不同的路径。

如果我只是用 AI 做了一个只有几十个人可能需要的软件，为什么还要准备商店物料、适应上架规则、经营一个产品页面，再想办法获得曝光？即便免费，上架和后续管理也有成本。我可能只想把它放在一个公开的位置，让需要它的人的 AI 找到它。

长尾软件需要的，也许不是另一个更聪明的商店，而是一种不必先上架商业市场、也不必自建销售渠道的发布方式。

我做过 GloWalk^[1] 和 一笺^[2]，前者面向夜间行走，后者是一款中文风格的便签应用。它们有明确的产品形态，也采用了应用商店这条路径。但这不意味着每一个更小的工具，都值得重复同样的过程。

比如，一个处理特定文本格式的小脚本，或只在浏览器里完成某种转换的页面。作者自己用得上，顺手分享给同样需要的人，就已经有意义。它未必需要账号体系、支付入口、精美截图，更不一定需要成为一门生意。

AI 可以减少编写代码的工作，却不会自动替作者完成审核、支付接入、发现和推荐，也不能省掉安全验证与后续维护。这里的分发成本，不只是把文件传到网上，而是让合适的人找到、信任、取得并持续使用它所需的投入。

这些负担以前就存在。变化在于：当实现一个小需求变便宜，仍然存在的固定负担在总成本中会显得更重。并非所有开发都会因 AI 变便宜，也不是分发环节完全无法自动化；但两者不必同步下降。对这类新增的长尾工具，现成商业市场的流程就可能超过它本身的规模。免费也不一定解决这个问题，因为稀缺的可能是作者的注意力和时间，而不是售价。

现成商店能提供支付、分发和一定的信任基础，开发者不必从头搭建交易系统。但通常仍要准备产品资料，满足所在平台和地区的审核、隐私及合规要求，并应对后续更新与规则变化。具体负担因平台、地区和软件类型而异，不是所有商店都一样。

自己建站销售，可以少受一部分商店上架流程的约束，却要处理收款、订单、退款和授权交付等问题。接入现成支付服务能省下一些工作，但不等于这些事情都消失了，也不等于不再有隐私、税务和消费者权益等责任。

对于一个只服务很少人的小工具，两条路的固定成本都可能超过作者愿意投入的精力。免费分享可以不需要收款，却未必值得专门走一遍商店流程。因此，我想讨论的不是“应该选择哪一家商店”，而是能否保留一条更轻的路：公开工具及其必要说明，让需要它的人或 AI 找到它，而不是先把它变成一项零售业务。

独立发布并不新鲜。代码仓库、个人网站、可下载的软件包一直都在。GitHub Pages^[3]也早已允许开发者从仓库发布静态网站。它们证明，公开一个项目，并不天然需要商业应用市场。

独立发布并不是 AI 发明的。真正值得讨论的是，AI 一方面可能增加小工具的供给，另一方面也可能成为发现和使用它们的入口。生产方式已经在变，分发方式是否也能跟着变？

过去，作者要设法让人看见，再让人理解这个工具。未来，用户可以先告诉自己的 AI：“我有这样的数据，要做这样的处理，不能联网，也不想装一个很大的软件。”AI 再去公开网络中寻找现有工具。

这里的“随便放在那里”，不应当理解为扔下一个没有说明的文件。它更像是：发布地点可以自由，说明方式应当可理解，可信程度需要有证据。

一个稳定地址、一份清楚的说明，描述它解决什么问题、怎样运行、输入输出是什么、有哪些限制；再提供版本、许可证、数据去向和作者身份。对于更需要自动化调用的工具，可以补上结构化描述和测试样例。作者不必为每个平台重写一套营销材料，多个发现服务也能读取同一份信息。

我想象中的下一步，是软件在自己的公开地址放置一份机器可读的能力清单，由爬虫、订阅或公开链接发现；多个索引交换发现记录，而不是要求作者先去一个中心注册。别的软件和 AI 可以据此提供使用入口，或在许可证允许时把组件组合、改造成新的工具。

工程上，这需要约定能力描述的格式和发现方式，区分稳定身份与具体版本，标明接口、依赖和权限，并能获知更新、撤回和失效。索引不能把旧版本的测试结果挪给新版本，用户也需要知道当前运行的究竟是哪一份代码。目录是可替换的发现服务，不该成为发布资格的授予者。

这是我期待的机制，不是已经存在、全网通用的一套规范。写好描述也不保证被收录，更不保证得到推荐。索引覆盖、更新和反垃圾仍然需要有人做。

概念插画：独立发布的工具附有能力说明，不同发现者提供使用入口；需要改造时仍须遵守许可。

MCP Registry^[4]提供了一个有限但有启发的例子：它登记服务器的元数据，供下游目录和聚合服务使用，软件本身仍位于相应的包仓库或服务端。它服务于特定工具生态，而且仍有登记流程，不能当作“免中心注册”的实现。它能说明能力描述与托管分离已经可行，不能证明分布式发现问题已经解决。

值得借鉴的是这个拆分：发布位置、索引目录、推荐服务和实际运行，不必由同一家平台包办。

作者可以选择托管位置；不同索引发现和整理它；用户自己的 AI 根据需求选择。垂直社区也可以维护经过人工筛选的小目录。商业市场仍然能提供支付、审核和支持，但它应是一种服务选择，而不是让一个小工具被看见的必经之路。

开放发现也不等于软件必须开源或免费。源码、使用权和发现信息是不同层次。能否修改、再分发或商用，要看实际许可证，不能因为 AI 找到了它，就默认什么都能做。

这种机制最实际的价值，是减少重复劳动。

同样一个需求，AI 可以先找已有工具；足够好就直接使用，有差距就配置、组合，或在许可范围内修改。没有合适的，再从零开发。

已有软件积累的往往不只是代码，还有边界情况、错误处理和使用经验。从零生成一个能跑的版本，与接手一个打磨过的工具，并不是同样的起点。不过，一个无人维护、依赖复杂的旧项目也可能比重写更贵，不能机械地认为复用总是划算。

用户要比较的应是完成任务和后续维护的总成本，而不是哪条路径生成代码最快。

应用商店承担的一部分工作，不会因为不再上架就自动消失。身份、恶意软件、依赖污染、更新和撤回，仍然有人要负责。

AI 可以检查说明、源码、权限和已知风险，但不能凭一次审阅宣布安全。SLSA 的来源证明^[5]可以帮助核查软件从哪里来、怎样产生，也不证明它没有漏洞。

更合理的做法，是让每项推荐附带可追溯的理由：核对了哪个版本，哪些能力经过测试，哪些只是作者自述；先用脱敏样本有限试用，安装、付费和开放数据由用户授权。README 或工具说明里的文字也只是待检查的材料，不能变成指挥 AI 的命令。

这里也有平台边界。网页工具、脚本和原生手机应用的分发条件不同。Apple 的审核规则^[6]及相应分发要求，不会因为 AI 找到了一个下载地址就失效。开放发现不是绕过安装限制的通行证。

不要求每个作者上架商业市场或自建销售渠道，不等于托管、索引和维护没有成本。

作者可以只是分享自用成果，也可以接受赞助、出售服务或收费授权；索引可以由社区维护，也可以通过订阅支持。重要的是允许不同层次分别获得回报，而不是强迫每个小工具先证明它有足够大的市场。

最大的风险是，开放网络最终又被几个 AI 入口重新集中起来。推荐只认熟悉的大产品，或悄悄由广告和佣金决定，那不过是把商店榜单换成了对话答案。

因此，发现记录应能迁移，推荐理由应可追问，赞助应明确标示，用户也应能换一个索引或代理，而不丢掉自己的选择。

我并不期待应用商店消失，也不是说过去的小软件都应该换一种分发方式。我期待的是：当 AI 让更多微小需求值得实现时，这些新出现的工具，不必因为分发负担没有相应减轻，就被迫先包装成一门生意。

AI 如果能帮助人们做到这一点，长尾软件得到的就不只是更便宜的生产工具，还有一种与它的规模相称的生存方式。