免费工具的维护成本怎么算

免费工具的成本几乎从不上线那天开始。开发是可控的一次性支出，维护不是：工具的成本等于"每月必须有人做的小事"的总数乘以月数。多数人低估的不是开发工时，而是那些没人算进排期的十分钟——核对一次数据源、跟一次依赖更新、回一条用户反馈。

更麻烦的是这类成本在报表上长什么样：它不出现在"开发完成"这个节点上，而是均匀地掉在之后每一个月的每周里。所以判断一个工具值不值得做，要在动手之前就算清维护账，而不是做完再算。同样要提前问的是用途：Google 在判断内容是否以人为本的自查清单里问过一句很适合用来筛工具的话：这是不是你愿意推荐给别人、或者希望别人收藏的那类内容。一个自己团队内部都不太愿意用的工具，通常也过不了这一关。

成本拆成六项，每项都要有归属

六项里最容易漏的是"内容与说明"。工具改了算法而说明文字没改，外部引用的就变成一份错误结论——这类错误不会被任何人报告给你。

抓取这一项决定工具页是不是真的存在

这一项要单列，因为它的判断依据不在你手里。Google 处理 JavaScript 应用分抓取、渲染、索引三个阶段：Googlebot 抓取到地址后先读 robots.txt 判断是否允许，然后把返回 200 状态码的页面全部送进渲染队列；渲染时用一个常新版本的 Chromium 执行 JavaScript，之后再从渲染后的 HTML 里解析一次链接并把发现的地址排队，同时用渲染后的 HTML 建索引。相关细节见JavaScript 与抓取的官方说明。

同一份说明里有一句直接的成本相关结论：官方仍然建议做服务端渲染或预渲染，因为这对你的用户和抓取程序都更快，而且并非所有爬虫都执行 JavaScript。工具页的分发渠道恰恰是最不执行 JavaScript 的那些——邮件客户端、各种阅读器、目录站、部分聊天工具。把计算完全放在前端，等于把工具的可发现性押在一半的分发渠道上，而这部分渠道你无法排查。

同一页还提醒：Google 只能发现带 href 属性的 <a> 元素形式的链接，单页应用要用 History API 而不是地址片段路由，并且要避免软 404（返回 200 但内容是"找不到"）。这三条都是工具页最常见的配置错误，排查顺序按同一份说明里给出的处理路径走。

怎么把成本算出来

1. 回溯四周，列出所有与这个工具有关的实际耗时，包括被打断的碎片时间。碎片时间最容易漏，而它恰恰是维护的主体。
2. 换算成人时与工时成本，用你自己的口径，不要用行业平均值。
3. 给每一项定频率：每周、每月、每季，或"触发式"。触发式要写清触发条件，例如"数据源改版""库出大版本""同类报错出现两次"。
4. 算月成本和可承受停摆天数。停摆天数要写进 SLA，不是写在心里。
5. 给每一项指定一个人。指定不到人的项，视为无法维护，写进停做条件而不是排期。
6. 每月对照一次。实际耗时比预估多出一半以上时，改设计而不是硬扛——通常意味着存在看不见的依赖。

什么时候该停掉或改造这个工具

五种情况属于例外。第一，连续三个月零自然外链、且非品牌点击极少——先别急着加功能，回去改它的用途，可引用的设计要点见做一个能被引用的免费工具要满足什么。第二，核心数据源不可持续：免费、无合同、随时可能关闭的接口不能作为唯一输入。第三，维护六项里有任何一项指定不到人。第四，工具只解决一个很窄的问题，读者用一次就够——改成文章里的一个可交互模块更划算，计算器页的设计取舍见可编辑的计算器页。第五，不要用结构化数据来省成本：Google 在结构化数据总则里说明，使用标记只是让某个功能可以出现，并不保证它会出现；而结构化数据的人工措施影响的是富结果资格，不影响页面在网页搜索中的排名。所以它省不了维护，只能让页面被正确理解。

还有一种情况不是"停掉"而是"降级"：工具本身没问题，但它是站内唯一入口、没有任何其它页面承接从它过来的读者。这时要补的不是一个功能，是一条从工具到相关内容的路径。

怎么验证成本算得对不对

每月对照四组数据：预估耗时与实际耗时；可承受停摆天数与实际停摆天数；用户报错条数；指向工具页的外链净增。

第二行值得单独记一笔：连续两个月实际耗时超过预估一倍以上，通常不是"人变懒了"，而是存在一个没被写进成本表的依赖——第三方接口、私有数据、某个人脑子里的规则。先把依赖找出来，再决定改不改设计，顺序反了会白花很多时间。