43个插件砍掉22个,要卖的功能12个站只跑通4个

两次翻车都不在「AI会不会写」，在「边界没人写」。功能没在真实站点验完就写进了付费承诺，脚本没写退出条件就一直挂着。

一个插件组合、一条发布链，两件不相干的事，卡点长在同一个位置：动手之前没给「什么算做完」定标准。

先看这两笔账。

一、43个插件下架22个，要卖的那个功能12个站只有4个跑通

通过审核只能证明它符合商店规则，证明不了它真的能用。

第一笔账来自dev.to上一位日本独立开发者ktg0215。到2026年9月底，他一个人上架了43个Chrome扩展，下架22个，留下20个在线，其中只挑2个做四周售卖测试。

他的方法和AI有关也很坦诚：自己不写代码，用日语给Claude Code下指令让它写。选品的逻辑更直接——让AI列出「看起来容易进入」的候选，挑一个做；卖不动就再做下一个，指望总有一枪能中。

结果一枪没中。他自己总结的转折点是：到某个阶段，「运维」——同时开好几个终端——变成了主要工作。并行铺得越多，每个的缺陷越显眼，他忙着修的全是不赚钱的东西。

最能说明问题的是被他砍掉的那个DataPick。原本要卖的功能是「和上一次抓取做diff」，他在真实页面上跑了按站点写的读取器：12个站点里只有4个能返回带名字的行，另外3个返回0行、4个名字是空的、1个页面根本读不出来。

他的处置是：把这8个站点从选项里藏起来，把这个功能从付费承诺里删掉，重新发版。

留下来的两个，数据也不好看：Procshot有1个订阅，SnapReply是0。他的判断标准是先写死的——同类免费扩展占主流就砍，对手只有付费的就留，因为那说明有人愿意付钱。四周后再看结果，标准不因为结果而改。

他还留了一句话，凡是靠AI快速出货的人都该抄下来：开发到了「完成」、东西也成型了，缺陷却在之后不断冒出来；这些缺陷甚至通过了我自己的检查、通过了商店审核、上线了。通过审核不等于真的能用。

二、一条发布链卡了10小时，三个坑一个都不报错

真正耗掉十小时的不是bug，是「看着没报错，于是一直等」这个判断。

第二笔账是掘金作者「用户84255813087」记的一次事故。

事故发生在凌晨两点。四平台连发的脚本按经验二十分钟能收工。第二天中午他回来一看，它还停在第三步，进度条一格没动。终端最后一行停在CONTENT_OK，再往下没了。进程没崩、没报错，CPU占用十七秒，安安静静挂在那儿。

三个坑，共同点是都不报错。

第一个，脚本跑完了进程没退出。脚本内部开了CDP的WebSocket去驱动浏览器，业务逻辑结束后既没关连接，也没调process.exit()。Node事件循环里还挂着一个活跃socket，进程就永远不会自然退出。在交互式终端里看不出来，你以为命令跑完了；但在链式脚本里是致命的，上一步挂住，后面永远不执行。

修复是两条硬规则：自研脚本一律显式退出；加超时兜底，用setTimeout配.unref()，让定时器本身不阻止正常退出，只在「该退没退」时兜底。

判断是不是僵尸，他给了三个特征，中两条就基本能定性：终端输出卡在某一行不再增长、命令却不返回；进程存在、CPU几乎不动、也不退出；后续步骤完全没开始。现场确认看启动时间——挂住的那个进程时间戳就是昨晚02:33，一眼认出来。

第二个坑是浏览器生命周期。他习惯分两步走：先起浏览器调试端口，再跑脚本。可第一步的命令一收尾，浏览器就被环境收走了，第二条命令去连9333直接ECONNREFUSED。解法是把启动和操作塞进同一条命令里，中间再留一段sleep等端口就绪。同一个逻辑还藏在细节里：新建标签页要用PUT请求/json/new，用GET会被Chrome拒绝，而且是静默失败，返回的不是JSON，解析出来是空，很容易误判成「建标签失败」。

第三个坑排查最久：后台标签的输入被吞掉。脚本跑在后台标签，文字怎么也输不进去，insertText、keyDown都像石沉大海。原因是Page.bringToFront只把标签切到前台，页面的visibilityState仍是hidden，前端框架（尤其React）会直接丢弃输入事件。要的是焦点模拟，不是把标签切前面。

最后一层是他把「平台限流」当调度资源来排期：日限额度的平台写00:05而不是00:00，滚动限流的任务按上次发布时间加24小时再加10分钟。边界踩点失败的概率很高，留缓冲比算得准更重要。

三、两笔账的共同点

两件事的规模完全不同：一个人的产品组合、一条自动化脚本。

但失败的位置一模一样——都是「人以为说清楚了」的那一格。

插件那边，12个站点里只验证过4个，功能就写进了付费承诺；脚本那边，写完了要干的事，没写「干完之后怎么结束」。

这两处都不是「写不出来」。插件那边的代码写出来了、商店审核也过了，缺的是「跑不通的站点怎么处置」；脚本那边该做的事都做完了，缺的是「做完之后怎么结束」。

写出来的东西没有一处是错的，错在没人写下「什么算做完」。这就是为什么两次都要等事情烂在那儿，才被发现。

所以真正要补的不是提示词，是三样东西：

一是每个约束都配一个反向约束。写「做完之后退出」，就要同时写「到点没退出就强制结束」；写「这个功能可用」，就要同时写「跑不通的站点从承诺里删掉」。

二是验收标准要在真实环境里跑一遍再承诺。12个站点跑通4个，说明的不是这个功能可用率33%，是它还不该出现在付费清单里。

三是给自己留一个「它在等什么」的检查动作。自动化任务超过预期时间还没返回，先怀疑挂起，别怀疑接口；这一条能省下的不只是一次十小时。

两笔账里最贵的成本，都不是返工本身，是那个「看起来没问题」的中间状态被当成了没问题。