照着六格检查缺哪格补哪格

一个十六万安装量的工具，作者亲口说自己一行代码没写。智能体写出了二十三万行、七千多个测试，靠口碑涨到今天，这成绩放传统团队里也够看。真正让它跨过那道坎的不是测试数量，是下面这张清单，从能跑走到能上线，中间隔着六道门。作者把这六道门摆成了可勾选的格子，谁的项目都能照着对，一格一格打勾就行。 第一步，开发与生产分开。代码仓库用 GitHub，至少两条分支，一个开发一个生产。数据库单独开生产实例，配迁移脚本和同步。登录与支付各挂生产账号，部署只从生产分支走。环境一混，事故就来了，这条是所有清单的第一条，别的都可以慢慢补，这条不能拖。 第二步，给所有写着无限的东西标上数字。套餐功能给明确上限，比如十个活跃房间。接口给上限，每分钟每个地址多少次 POST 调用写死。压测压到返回四二九为止，摸到墙在哪，心里才有底。心中有数才敢放量，否则无限只是一句广告词，账单来了才追悔，页面也崩了。 第三步，先写下意图，再让智能体动手。用户是谁、分哪些角色、哪些不做什么，全写进 AGENTS.md。价值主张、权限、流程、业务规则落成文档。人自己先审一遍，这是产品决策，不是文档作业。然后智能体照着文档写测试。没有这步，它测的是代码做了什么，不是代码该做什么，两边差着一个产品的距离，返工多半从这裂开。 第四步，到真浏览器里过一遍。每个角色开一个测试账号，让智能体跑关键路径，跑完之后自己再点一遍。作者的实测是十五到二十分钟。这二十分钟值回票价，一闪而过的东西智能体照样漏，人眼的余光反而是最后一道防线，这一关没法外包。 第五步，每次发布前审三遍。一条提示词带出三轮审查，安全看权限和用户输入，性能看真实负载下的查询，发现的问题分高中低排序，先修高的再放行。这跟前两天技能论文说的把关逻辑同源，放行前总得有人读结果，机器出报告，人做裁决。 第六步，上线后接着盯。用 UptimeRobot 这类工具盯着首页和数据库页，页脚挂个状态页，出了事用户先看到你诚实的一面。日志先用平台自带的，量大再上错误追踪，外加热力图看用户卡在哪，卡点就是下一轮要改的地方。监控不是装饰，它是清单里唯一在你睡觉时还在干活的那格。 作者最后留了句总结，换了技术栈工具可以全换，检查项一个都不能少。清单是通用的，工具是局部的，这个主次关系想反了就会陷入无尽的选型，选型焦虑大多这么来的。 我的看法是这张清单的含金量在于顺序，不是工具品牌。先环境，再额度，再意图，再人肉验证，再发布审查，最后监控，每一步都在给上一步兜底。跳步是新手最常见的死法，我见过太多卡在测试很全却没人写意图这一关。测试覆盖得再漂亮，测错了对象也白搭，这句要贴在工位上。 拿去对着自己的项目勾一遍，六格里缺哪格补哪格。工具真的随你换，人手不足就先做前四格，第第五格的发布审查哪怕手动也要执行，监控可以从一条存活探测起步。