你是不是也这样：项目吭哧吭哧做完了，真到要上线，反倒不敢了。
心里没底——怕有没查出来的问题，怕一上线就出事。
你也隐约知道，上线前，得让 AI 帮你好好查一遍：功能对不对、安不安全。
可真正卡住你的是：你不知道该怎么让它查。
一句“帮我测一下”甩过去，它到底查没查、查得全不全，你根本判断不了。
这一篇，就专门解决这个问题：怎么把话说到位，指挥 AI 替你把上线前该查的，一项项查到位。
更实在的是，下面每一步，我都会给你一段可以直接复制、发给 AI 的提示词。你不用自己琢磨怎么说，照着发就行。
在《部署篇：上线前的闭环测试》中我们讲了第一步——你自己动手，把功能粗粗走一遍。这一篇是第二步，也是更专业、更狠的一步：指挥 AI，把你那一遍够不着的深水区，替你趟一遍。
内容有点长，但只要你的项目打算真上线，强烈建议你耐着性子看完。
尤其是第五点，让 AI 扮黑客把你的接口攻一遍，那是最多人漏掉、也最容易出大事的一步。
一天一个 vibe coding 小技巧，这一篇我们讲：怎么指挥 AI，把上线前的测试做到位。
一、先让 AI 分清：到底该测什么
轮到指挥 AI 了，但你千万别一上来就甩一句“把所有功能都测一遍”。
那样它要么东一榔头西一棒子瞎测一通，要么把真正要命的功能给漏了。
你得先让它分清主次：哪些功能必须重点测，哪些可以先放一放。
判断的标准其实很朴素，就一句话：这个功能一旦出错，会不会动到“钱、权限、数据”这三样。
为什么是这三样？因为它们错了，是真会出大事的。
钱算错了，你要么赔钱，要么被用户投诉；
权限错了，普通用户能干管理员的事，或者能看到、改掉别人的东西；
数据错了，用户的资料、订单被弄乱甚至弄没了，很多时候找都找不回来。
像下单、支付、扣库存、改密码、改权限、删除重要数据，这些就是必须重点测的。而页面文案、颜色、排版这种，错了顶多不好看，可以往后排。
你可以把这段话直接发给 AI：
“请按业务重要性，列出我当前后端有哪些功能必须重点测试、哪些可以暂时不测。请逐个说明：这个功能一旦出错，会造成什么后果，是影响资金、权限，还是数据。不要追求全面覆盖，先帮我锁定真正高风险的部分，把清单列给我。”
它给你这份清单，你别急着往下走，先自己扫一眼：那些你心里清楚的要命功能，有没有被它漏掉。有漏的，当场让它补上。
这一步看着简单，作用很大：它能防止 AI 把力气浪费在无关紧要的地方，又漏掉真正的命门。
二、功能测试：别只测“能跑通”，要测“会不会算错”
锁定了测什么，接着说怎么测。
一个功能，要分三类情况来测，光测第一类是远远不够的。
第一类，正常情况：该成功的，要成功，而且结果要对。
这就是上篇说的“结果对不对”。比如下单以后，库存有没有减对数量、金额有没有算对，不能差一分钱。
第二类，边界情况：那些最容易出错的“临界点”。
什么叫临界点？就是那些刚好卡在边上的极端值。比如，库存只剩最后一个时，两个人同时来下单，会不会两个人都下单成功、把库存搞成负数？再比如，数量填 0、填负数、填一个超出上限的超大数字，它认不认？这些临界点，恰恰是 bug 最爱藏的地方。
第三类，异常情况：错误的、非法的请求，要能被正确地拦在外面。
比如没登录就直接来调用、在该填数字的地方塞一串 @#￥%、拿着别人的身份来操作——这些都该被挡回去，而不是照样放行。
你可以这样要求 AI：
“请为我清单上的每个关键功能，设计测试用例，覆盖三类情况：第一，正常且结果正确；第二，边界值，比如 0、负数、超大值、并发临界；第三，异常与非法输入。请重点说明，正常情况下，相关的计算结果和数据变化是不是正确的，而不要只看接口有没有返回成功。”
这里我必须重点提醒你一件事：三类里，最容易被 AI 糊弄的，恰恰是第一类。
AI 写测试的时候，特别爱偷懒，它经常只测“这个功能有没有给我返回一个‘成功’”，而不去测“返回的这个结果，到底对不对”。
一个“成功”的提示，绝不等于金额就算对了、库存就减对了。
所以你给它的指令里，一定要死死咬住这一句：我要的不是“有没有反应”，是“算出来的结果，到底对不对”。
三、把测试，变成一张能反复跑的“自动回归网”
到这儿，你大概觉得，测试这事总算干完了。可惜没有——前面测的，只能保证“此时此刻”没问题。
可你的项目，是会一直改下去的。
你今天测好了，明天让 AI 加个新功能，它可能又把今天好好的东西碰坏了。可你不可能每改一次，就把那几十条流程手动重走一遍——这既不现实，你也坚持不了几天。
所以，真正的解法是：让 AI 把前面这些该测的检查，全都写成测试代码，存起来。以后只要一条命令，它就能把所有测试，自动、完整地重跑一遍。
这件事，有个专门的名字，叫“回归测试”。
“回归”这个词你不用记，你就理解成：防止你的项目，改着改着，又悄悄退回到了以前出过问题的那个状态。
这一步，才是让你能一直放心改下去的关键。建好了这张网，以后每次 AI 一改完，你就让它把所有测试重跑一遍：
全部通过，你才能放心，这次改动没有碰坏老功能；只要有一个没通过，就说明踩到雷了，必须先解决，再往下走。
你可以这样要求：
“请把我们前面确认的这些测试，做成可以用一条命令自动运行的方式，并告诉我这条命令是什么、跑完之后我怎么看结果是通过还是失败。以后每次新增或修改功能，都要重新运行全部测试，把通过和失败的结果发给我。”
你完全不用看懂那些测试代码。你只要养成一个雷打不动的习惯：每次让 AI 改完东西，都追问它一句——“所有测试都重新跑过了吗？结果怎么样？”
四、当心 AI 写“假测试”来糊弄你
这里有个特别阴险的坑，你一定要小心。
AI 有时候，为了让你看到一片“测试通过”的绿灯、让你高兴，会写出“假测试”。
什么叫假测试？就是这个测试，不管你的代码到底对不对，它永远都会显示通过。
比如，它写了个检查，但根本没真正去调用你那个功能；又比如，它设的那个判断条件，怎么填都成立。
结果就是：测试报告上一片绿、全部通过，可它其实什么都没验。你看着特别安心，实际上一点保障都没有。
对没有技术背景的人来说，这种最难防，因为你压根看不出真假。
所以，你得用一个巧办法，逼 AI 自己证明它的测试是真的有用。这个办法，就是“故意改错”。
你可以这样要求：
“请检查我们当前的测试，是不是真实有效的。请逐个说明：每个测试到底验证了什么业务结果、有没有真正调用被测的功能。然后，请你故意在代码里制造一个错误，比如把某个金额故意算错，再跑一遍对应的测试，确认它这时候会失败、会报红。如果代码都改错了，测试却还能通过，那就说明这个测试是无效的假测试，必须重写。”
记住一句话：一个测试，只有在“代码出错时它真的会失败”，才算真有用。一个永远亮绿灯的测试，等于没有。
它解释的时候，要是你听不懂，就让它用大白话再讲一遍。一个你听不懂的测试，你也没法相信它。
五、安全攻防测试：让 AI 扮一回“专业攻击者”
前面那几步，重点都在“功能对不对”。但你的项目，只要有后端、有接口，就还得防一类人：专门来钻空子的。
这是上篇“走歪路”那一步的升级版，也是上线前最该做、却最少有人做的一项。
先解释一个词：接口。
你可以把接口，理解成你的前端页面和后端之间，传递数据的一根根管道。
普通用户，都是老老实实从你设计好的页面，点点按钮、走这些管道。但真正懂行、想搞破坏的人不会这样——他们用一些现成的工具，就能完全绕开你的页面，直接对着这些后端管道发请求、来回试探。你在页面上做的那些限制，对他们一点用都没有。
所以，光你自己当好人走一遍，远远不够。你得让 AI 换一个身份，去扮演那个坏人。
具体怎么做？你让 AI 别再当那个帮你写功能的助手，让它改当一名专业的安全工程师，站到攻击者的角度，对你的每一个接口挨个试探。
这里得多说一句：它到底怎么“试探”？AI 查安全，有两条路。一条是直接读你的代码，从源头看哪儿写得有漏洞；另一条是写出脚本，真的对着你的接口发一堆恶意请求，实打实地打一遍。这两条你都要让它走——代码先从头到尾审一遍，再真刀真枪打一遍，才算查得全。
你可以把下面这段话直接发给它：
“请你现在不要再扮演开发者，而是扮演一名专业的测试和安全工程师，对我的后端接口做一次全方位的攻防测试。请分两步：先审查我的后端代码，从源头找出下面这些问题；再尽量写出可运行的脚本，真的对我的接口发起这些请求，实测扛不扛得住。
请站在攻击者的角度，系统性地逐条尝试：
一、数据越权：把请求里的订单号、用户 ID 改成别人的，看能不能查到、改掉、删掉别人的数据；
二、功能越权：用一个普通用户的身份，去调那些本该只有管理员才能用的接口，看拦不拦得住；
三、身份认证：不登录、或者伪造、篡改身份凭证（比如 token）去调用接口，看能不能蒙混过关；
四、偷改字段提权：在提交的数据里偷偷多塞一个字段——比如把角色改成管理员、把价格改成 0、把金额改成负数——看后端认不认；
五、恶意输入与注入：在各个输入框里构造精心设计的恶意内容，尝试 SQL 注入、命令注入、脚本注入；
六、绕过前端限制：完全绕开页面，直接对接口发请求，看那些只做在前端的校验是不是形同虚设；
七、敏感信息泄露：检查接口返回的内容里，有没有带出密码、密钥、别人的手机号这类本不该暴露的信息；
八、资源滥用与防刷：对同一个接口（尤其是登录、发短信、下单）高频、超大、并发地请求，看有没有限流、会不会被刷爆。
请把发现的每一个问题都列成一份清单，逐条标明：风险高低、会造成什么后果，以及你是怎么复现的（发了什么请求、返回了什么）。注意：先别动手改代码。”
这段话里的名词你不用全懂，照发就行——它们是说给 AI 听的。你要盯住的，是它给你的那份清单。
而这里，请你特别留意提示词的最后一句——“先别动手改代码”。
这是这一整步里，最重要的一条纪律。
因为发现问题之后，正确的处理顺序，绝不是让 AI 顺手就给你改了。而是要走这么三步：
第一步，让它先把发现的所有问题，连同每个问题对应的最佳解决方案，一条一条，清清楚楚地列出来。
第二步，你和它一起，把这份清单逐条核对：这条到底是不是个真问题？它给的方案合不合理？要是按它说的改了，会不会反而牵连、破坏到别的地方？哪一条你看不懂，就让它用大白话给你讲明白。
第三步，等你核对清楚、确认无误了，再让它动手去改。
为什么非要多绕这两步？
因为 AI 要是一边测一边顺手乱改，特别容易越改越乱——为了堵一个小漏洞，把好好的功能改坏，最后你连它动了什么都不知道。
先列清单、再核对、最后才改，才能把局面牢牢攥在自己手里。这跟我在实战篇讲后端安全时反复强调的是一个道理：别信 AI 一句“我处理好了”，要让它把风险、方案、证据，一项项摊在你面前。
核对完之后，你可以这样让它改：
“针对我已经确认要修的这几条问题：【把你确认的几条列出来】，请逐条修复。每修一条，告诉我你具体改了什么、为什么这么改。全部改完后，把所有测试重新跑一遍，确认没有引入新的问题。”
最后再说一句：攻防测试涉及的越权、注入、密码、配置、数据库这些概念，我在实战篇那两篇后端安全里，已经讲得很细了。你要是看 AI 给的清单有点吃力，回头把那两篇补上，再回来指挥它，你心里会踏实得多。
六、也别走另一个极端：让 AI 测过头
把上面这些做完，你的测试基本就到位了。但最后，我得提醒你别走到另一个极端去。
测试，不是越多越好。
你一说要重视测试，有些 AI 就会滑向反面：拼命给你堆测试。它生成一大堆，把每个犄角旮旯都测一遍，测试数量的数字看着特别漂亮。
但你仔细看就会发现，它测的很多都是无关紧要的小东西，真正高风险的那几个业务，反而没测透。
而且测试堆得太多，还有个后患：以后你想改一点点代码，就得跟着去修一大片相关的测试，本来想图省事，结果反被它拖累。
所以，自始至终都要抓重点：关键业务，要测深、测对、测到结果正确；次要功能，够用就行，别恋战。
你可以这样要求：
“请审查我们当前的测试，是不是存在‘过度测试’：有没有为不重要的功能写了一大堆测试、有没有重复的或者没有意义的用例。请优先保证关键业务，也就是资金、权限、数据相关功能的测试深度，其余次要的，帮我精简掉。”
判断标准，还是那句老话：盯住真实的业务风险，而不是盯着测试的数量。
七、最后
测试这上下两篇就讲完了，说到底一个目标：上线前，把藏着的问题尽量揪出来。
方法就一个、两步走：上篇你自己把功能闭环走一遍，这篇再指挥 AI 把它测得更全、更深、更狠。中间就记牢一条纪律：AI 测出问题，先列清单、核对无误，才让它动手改。
最后一句实在话得说在前头：没有谁能保证项目上线后百分百不出问题，干了十几年的程序员，写的代码照样有 bug。我们费这劲做体检，不是追求“零问题”，而是把出大事的概率，实实在在压到最低。能做到这一步，你已经比绝大多数闷头上线的人，稳当太多了。
