14 个应用上线两周，总浏览 31 次：我才明白「发布」和「分发」是两件事

先给数字，不给结论。

我在一个刚上线的「AI 应用」平台上做了 14 个应用，全部审核通过、全部有独立可访问的 URL。两周后我拉了一次接口，把每个产品的浏览、投票、分享都读出来：

• 14 个应用，总浏览量 31 次
• 总投票 3 票，全部集中在同一个作品上
• 剩下 13 个，浏览量是 0 到 4

同期平台的全站数据是：430 个作品、55,165 次浏览、2,073 个用户。也就是说，平均每个作品能分到 128 次浏览——但那是因为 84% 的浏览集中在 19 个上个月发布的老作品里。新作品的中位浏览量，是 2。

这篇文章不是抱怨平台。平台没欠我什么，它给了托管、给了审核、给了榜单。我要写的是我自己在这两周里踩到的三个认知坑，以及踩完之后我改了什么。

---

一、「发布成功」是平台给的，不是你拿到的

第一次提交的时候，看到「已发布，待审核」，我确实高兴了一下。第二天状态变成 approved，我更高兴了——这意味着它进了公开列表，谁都能搜到。

然后我发现「能搜到」和「有人搜」之间，隔着一整个宇宙。

我的判断错在一个很朴素的地方：我把「动作完成」当成了「结果发生」。 提交是动作，审核是平台的动作，这两件都完成了；但「有人打开」是第三个动作，它属于别人，而我从来没为它做任何事。

更具体的证据：一个作品拿到 14 次浏览、3 票——它是我所有作品里唯一有活人数据的。为什么是它？因为它是「开发者工具」，而这个平台的用户就是程序员。同一个平台，选题对不上人，浏览就是 0；选题对上了，就有 14。 差别不在质量，在「谁会觉得这东西跟自己有关」。

二、托管在别人域名下的东西，会跟着规则一起归零

做的第三天，我去拉活动列表，接口返回了一个空数组 []。

前一天它还有内容。那一天，我 14 个应用所属的「活动」消失了——随之消失的是这个活动的榜单、奖金池、分类归档。我的应用 URL 还是活的，但它们从「某活动下的参赛作品」变成了「一个没人认领的页面」。

这件事让我第一次认真想清楚一个问题：我到底拥有什么？

• 我拥有那 14 个 HTML 文件（在本地硬盘里，这个是真的）
• 我不拥有它们的 URL（平台给的）
• 我不拥有它们的曝光位置（平台的榜单算法，而且这个算法带 0.4 的衰减地板——老作品永远跌不到 0，新作品永远追不上）
• 我不拥有任何人来不来的决定权

所以从那天起我改了一件事：每个工具都必须是一个能单独拷走、双击就能打开的 HTML 文件。 不联网、不上传、不依赖平台的任何接口。平台倒了，工具还在；换个地方托管，只是换个链接。

顺带说一句，这也是这类工具本来就该有的形态——它们要填的是工资、合同、聊天记录、房东姓名，这些数据最不该上传到某台别人的服务器上。

三、我用「票」当需求的代理指标，但票可以不打就投

这是我踩得最深的一个坑。

榜单上有些作品的票数比浏览量还高。一开始我以为是数据错了，后来发现投票入口在作品卡片上，是打星级评分——不用打开应用就能投票。

全站 2,673 票里，有超过一半来自「票数 > 浏览数」的作品。这意味着这个榜单测的不是「这个东西有没有用」，而是「作者拉了多少人过来点星星」。

任何能被不使用者打的分，测的都不是使用。 这句话后来成了我判断所有平台激励机制的尺子：先看这个指标能不能在不产生真实使用的情况下被刷出来。能，就当它不存在。

---

四、所以我做了一件更笨的事

我把手上真正有用的五个工具，搬到了一个我自己能控制的静态站上。一个工具一个 HTML 文件，一个落地页把它们串起来。

三个是给普通人的（都跟钱有关）：

工具	它回答的问题
押金体检	房东该退我多少？扣的每一笔有没有条文依据？
投诉信工厂	被坑了该找谁、凭什么、多久该升级？
劳动仲裁算盘	公司到底欠我几笔，哪一笔快过时效？

两个是给写前端的人的：

工具	它做什么
AI 生成 H5 修复台	12 类运行时体检 + 4 类自动修
H5 体检器（旧版）	只体检不修，先看问题清单

地址：https://samforce2003.github.io/yingzhang/
源码：https://github.com/samforce2003/yingzhang

落地页上我专门写了一节「它不做什么」，比「它能做什么」写得还长：不预测结果、不给「你应该去仲裁」这种结论、不覆盖地方细则、不构成法律意见。金额一律给区间，文书一律给草稿。

写这一节不是免责声明，是产品的一部分。一个把「你一分钱都拿不到」写在第一屏的工具，会让本该维权的人直接放弃。 工具的默认值，本身就是一种建议。

五、顺手做的一次体检：221 个 AI 生成的页面

搬工具的过程里，我把手上一批 AI 生成的前端页面（221 个）跑了一遍运行时体检，结果比我预想的更整齐：

问题	命中	占比
用了 100vh 做全屏高（移动端地址栏一收就塌）	53	24%
裸调 localStorage（无痕模式直接抛异常）	22	10%
onclick 指向未定义的函数（死按钮）	19 处	—
缺 viewport meta	2	1%
至少命中一条运行时问题	69	31%
真的抛了 pageerror	0	0%

最后两行放一起看才是重点：31% 有问题，0% 会报错。

AI 写的页面最典型的失败不是「崩」，是「不崩，但不对」。它长得像能用的东西，点下去没反应，你在手机上打开发现底部被切掉一截，而控制台是干净的。这类错误不会给你任何提示，只会安静地把用户弄走。

所以我后来给自己定了一条：凡是「看起来对的错」，都要专门去找。 引法条要回原文抄，不凭记忆；算金额要写死期望值再对，而且先怀疑期望、再怀疑实现——我有一次是期望值写错了、代码是对的，如果我当时的反应是「改代码让它等于期望」，就会把一个正确的工具改成一个会骗人的工具。

---

六、现在还是 0 个真实用户

诚实地讲：这篇文章发出来之前，这个站点的真实用户数是 0。我做的所有东西，到现在为止，还没有一个人真的用它办成过一件事。

我不打算把这个说成「即将爆发」。我只说清楚我改了什么：

从「在别人的平台上发布，然后等」，改成「做一个自己能控制的东西，然后把门牌挂出去」。

这篇文章就是挂门牌的第一步。

如果你正在被裁员、正在退租、正在为一个退不掉的预付卡生气，那三个工具可以直接用，不用注册、不用填手机号，右键另存下来断网也能用。如果你在写前端，那两个体检工具可以省你几次「上线才发现」的时间。

如果哪个条文我引错了，请在仓库开 issue——这类错误不会报错，只会给一个看起来很像真的结果，那是最该被挑出来的那种错。