09｜页面能打开，不代表项目已经做好

本章任务：自己把功能试一遍，再请 AI 帮忙找问题；改完以后，把原来好用的地方也再试一遍。
准备材料：做到什么样算合格的说明、能运行的代码、专门拿来试的环境，以及编造的测试记录。
本章产出：实际试过的记录、AI 检查了什么的说明、问题清单，以及改好后的检查结果。

把“试过了”变成可以核对的记录

你报了一次名，成功了。能不能说报名功能没问题？还不能。

如果连点两次，会不会多出两条？截止后还能不能提交？换个账号，能不能看到别人的记录？这些事，刚才那一次成功都没试到。

测试，就是照着几种具体情况操作，看结果是不是你和甲方说好的样子。比如不填必填项就点提交，应该提示缺什么，不能保存一条空报名。

审查，则是让 AI 或懂技术的人看代码和设置，找可能出错的地方。比如发现代码只隐藏了按钮，却没有阻止别人直接发送审核操作。

一个是实际试，一个是检查写法。两种都需要，但谁也不能保证所有问题都找全了。

第一步：从已确认规则列出要试的情况

先翻开甲方确认过的规则，再列检查表。别让 AI 猜一套规则，按猜的去写，再按同一套猜法证明自己做对了。

比如已经说好“审核通过才占名额”，测试表就不能把“提交后立即占名额”写成正确结果。

这次试什么	具体怎么操作	应该看到什么
正常报名	用测试账号填好内容，提交一次	出现属于这个账号的待审核记录
重复报名	同一账号已有有效报名，再提交	不能多出第二条有效报名
截止后报名	使用已经截止的测试活动提交	被拒绝，而且没有新增记录
审核通过	用有权处理这个活动的后台账号点通过	保存为通过，报名端也能查到，名额正确
看别人的记录	用另一个测试账号尝试打开这条记录	看不到内容，也不能修改

还没说好的地方要先问。比如被拒绝后能不能重新报名，甲方没有回答，就不能由 AI 随手写一个预期答案。

每次试完，记下实际结果、用的代码版本、账号和活动条件。失败也要记，不要只保留通过的截图。

第二步：不仅检查页面，也检查处理程序是否真的拒绝

图解：权限必须检查实际请求与数据结果。 查看大图

权限，说白了就是“这个账号允许做哪些事”。比如后台账号只能审核自己负责的活动，不能换个活动编号就改别人的名单。

页面把按钮藏起来，只是让你看不到按钮。真正处理请求的程序还得再检查一次。这个程序叫后端，比如它收到“把第 23 条报名改成通过”后，得先判断当前账号有没有资格这样做。

请求就是页面发过去的话，例如“请给我第 23 条报名”。有些人不用页面上的按钮，也能发出同样的话，所以不能只保护页面。

你可以准备两个报名端测试账号，再准备权限不同的后台测试账号，请 AI 带着做这些检查：

• 账号 A 能看自己的记录，换成 B 能不能看？
• 把请求里的活动编号换掉，后台是不是仍然拒绝？
• 拒绝后，数据有没有被偷偷改掉？
• 错误提示里有没有顺便带出完整名单？

只在你明确有权测试的环境里，用虚构记录做。不会发这些测试请求时，可以让 AI 逐步解释操作，或者请懂的人帮忙；别去试别人的系统。

第三步：选择 skill 前，先看它到底能帮你做什么

Skill 可以理解为给 AI 配的一套工作说明和工具用法。比如某个检查代码的 skill，会要求它读改动、核对规则、列出问题，再尝试运行测试。

Skill 是工具，不是保证。 名字里写着“安全审查”，不代表它看到了所有代码，也不代表它真的运行过项目。

有些只能读文件，有些能运行命令，有些只查页面。AI 本身的能力、拿到的资料是否完整，也会影响结果。

使用前至少弄清这几件事：

你要问清楚什么	为什么要问
它看了哪些文件和哪次改动？	没看的部分，不能说检查过了
它知道哪些业务规则？	不知道“审核才占名额”，就可能把错的当对的
它能不能运行项目和测试？	只读代码和实际操作，能发现的问题不一样
哪些地方没有检查？	比如没看真实服务器上的设置，不能顺便宣布那边也安全
发现的问题有没有具体位置和试法？	你要能核实，不能只收到几个吓人的标签

不要为了让工具检查，把真实密码和所有服务器权限一并交出去。先看说明，按这次需要给资料和操作范围。

第四步：让审查报告说清楚，凭什么认为有问题

图中提示词仅作为示例，不建议作为实际项目中的提示词使用。

图解：Skill提供方法，能力与覆盖范围仍需核实。 查看大图

仅作为示例，不建议作为实际项目中的提示词使用。

请按已经确认的报名与审核规则检查这次改动。先告诉我实际读了哪些文件、能运行哪些检查、哪些地方没看。发现问题时，说清在哪个文件、做什么操作会出现、会造成什么后果，并给出核实办法。先别自动修改。没有真的运行的测试请写“未执行”，不要把“这次没发现”写成“整个系统没问题”。

如果只收到一句“可能有权限问题”，继续要具体信息：哪个账号、访问哪条记录、预期应该拒绝还是允许、实际返回什么？

反过来，AI 说“没问题”也不代表没问题。它可能没拿到关键规则，没看到相关文件，也可能只是从头读了一遍，根本没试过请求。

一句结论看不出它漏了什么。检查范围、实际操作和结果，才是你能拿来判断的东西。

第五步：AI 指出的错误，也要先核实

AI 有时会误报，就是把没有问题的地方当成问题。比如它说“这里没检查权限”，但真正的检查在前面统一做过，只是它没看到。

先找到它指的代码，按它给的方法在测试环境试。能重现，再讨论怎么改；不能重现，要继续找条件，不能凭一句“我电脑没发生”就划掉。

核实到哪一步了	你可以怎样记
确实有问题	怎样操作会出现，和正确结果差在哪里
还拿不准	缺哪段资料，下一步准备看什么
确认是误报	哪段代码已经处理了，实际怎样试过
暂时不改	为什么暂缓，会影响什么，什么时候再处理

同样的操作，账号不同、数据状态不同，结果可能不一样。测试环境没有问题，真实运行环境也可能因为设置不同而出错。

涉及真实数据可能泄露、重要操作可能被乱改时，自己判断不了就带着材料找懂这方面的人问。没弄清楚之前，不要急着交出去使用。

第六步：改好以后，把以前好用的地方也再试一遍

图解：说是误报也要给依据；没做的检查要写明。 查看大图

动手前先存好当前代码。改完先按原来的步骤试，确认原问题确实没了，再试容易被这次修改牵连的地方。

比如你拦住了“后台账号审核别人的活动”，还要再试：它能不能正常审核自己的活动？名单查询和导出是不是也限制了？报名端还能不能看到自己的结果？

否则你可能堵住了一个错误，却把正常操作一起堵死了。

反复要做的检查，可以请 AI 写成自动测试，也就是用程序替你重复操作和比较结果。比如每次改完，自动确认“无权审核时不能改状态”。但你仍要看它比较的是不是正确结果，不能只数绿色的通过标记。

记录对应的代码版本。昨天那版试过，不代表今天改完的这版也试过。优先重试这次可能影响的地方，不必为了显得认真，把完全无关的检查无理由重做十遍。

练习：报告只写“存在越权风险”

越权就是做了本来不允许做的事。比如后台账号只负责活动 A，却能改活动 B 的报名。

现在报告只有这五个字，你准备补问什么？至少写出账号、活动、具体操作、返回结果，以及怎样证明数据有没有改变。

再想一下：程序说“不允许”，却在同一条回答里附上了完整名单。算检查通过吗？为什么不能只看“拒绝”两个字？

完成检查

• [ ] 每种要试的情况，都知道正确结果来自哪条已确认规则。
• [ ] 不只试页面，还检查了处理程序有没有拒绝不该做的事。
• [ ] 知道 skill 实际检查了什么，哪些没检查。
• [ ] AI 提的问题核实过；不成立的问题也有说明。
• [ ] 改完试过原问题，也再试过以前好用、可能受影响的地方。

本章带走： 试过哪些、结果怎样、还有什么没查清楚的记录。你可以说“这次检查没发现问题”，但不能把它说成“所有问题都不存在”。