该问的话

自己验证

• 它说做完了，看一眼它改了哪些文件，是不是都在你说的范围里。
• 新开一个对话，先问它“我们之前定了哪些要求”。答不上来很正常，把那份要求文件交给它。

自己验证

• 拿你写下的“怎样算好”逐条对一遍，每一条都做到了，才算做完。
• 页面上的每一句话，都能在你给的素材里找到出处。

自己验证

• 按出问题时的步骤原样再做一遍，确认真的好了。
• 看看有没有别的地方跟着变了：文字、位置、按钮。

自己验证

• 亲手数一遍总数，和你要求的对上。
• 开头、中间、结尾各抽几样，打开看。

自己验证

• 改之前，把整个文件夹复制一份，名字里写上日期。
• 改完把新旧两版并排打开，找出多出来和少掉的地方。

自己验证

• 翻一遍对话记录，看有没有发出去过密码或密钥；有的话，马上去作废、换新。
• 看一眼授权给它的文件夹，里面有没有不想让它看到的东西。

自己验证

• 用一台不是你自己的手机打开网址，从头点一遍。
• 换一个浏览器打开小工具，看数据还在不在。原来的浏览器先别清理，数据可能只在那里。

自己验证

• curl -sI 你的网址：看 server、cf-ray、x-vercel-id 这类响应头，确认真正的托管方。
• 在代码仓库的提交记录上看检查结果：每个平台各占一栏，分清哪一栏才是线上。
• 打开浏览器开发者工具的“网络”面板，看页面向哪些地址发了请求：它们就是这个网站依赖的后端和第三方服务。

自己验证

• lsof -nP -iTCP:端口号 -sTCP:LISTEN：查端口上是哪个进程。
• ps -o pid=,lstart=,command= -p 进程号：看它什么时候、用什么命令启动。
• 上线前按线上的方式构建一次，再在本地预览构建结果（比如 npm run build 之后 npm run preview），别只看开发服务器的效果。

自己验证

• dig +short 你的域名：看域名解析到了哪里（经过 Cloudflare 代理时，只会看到 Cloudflare 的地址）。
• curl -sI https://你的域名：看是谁在回答、状态码是多少。
• curl -s https://你的域名/api/某个接口 | head -c 200：看返回的是不是后端给的数据，而不只看状态码。

自己验证

• curl -s 你的网址 | grep "正文里的一句话"：能搜到，才说明正文在 HTML 里。
• 右键“查看网页源代码”（不是开发者工具里的元素面板，那里显示的是 JavaScript 运行之后的样子），看 <head> 里的标题和描述是不是这一页自己的。
• curl -I 你的网址/一个不存在的路径：第一行应该是 404。

自己验证

• curl -I https://你的网站/根本不存在的地址：第一行应该是 404。
• curl -s https://你的网站/healthz：看返回的是不是后端给的那段状态，而不只看状态码。
• curl -sI https://你的网站/某个旧地址：搬走的地址应该返回 301 或 308，并指向新地址。

自己验证

• 把页面上所有看起来能点的东西都点一遍：链接、按钮、标签页、复制图标。
• 对每个数字和状态问一句"它从哪来"，在代码里找到它的数据来源。
• AI 声称"已检查"的地方，自己打开页面实际看一遍，别只看它的报告。

自己验证

• 把参考和改完的页面并排打开，关键数值（版心宽度、正文宽度、标题字号）用开发者工具各量一遍。
• 检查范围：你说的"整体"，AI 改到了几类页面？逐类打开看。
• 验收时拿参考来比，不要拿 AI 自己写的规范来比。

自己验证

• 把页面上所有像链接、像按钮的东西都点一遍，记下没反应的。
• 对每个数字问一句"它从哪来"，在代码里找到它的数据来源。
• 把配图放到实际显示的尺寸下逐张看，不要只看缩略图或脚本报告。

自己验证

• git status --short：提交之前完整看一遍，不要只看前几行。
• git ls-files -z | xargs -0 du -h | sort -rh | head：找出仓库里最大的几个文件。
• git ls-files data/：看某个目录下到底跟踪着哪些文件。

自己验证

• 读构建日志时先看开头：构建机用的是哪个版本的 npm 和 Node。
• npm ls 包名：看一个包是被谁带进来的、装的是哪个版本。
• 推送前在一份干净的副本里跑一遍 npm ci 和构建，模拟线上的安装方式。

自己验证

• git check-ignore -v .env：确认 .env 被 git 忽略了。
• 在会话记录和命令历史里搜一下密钥的开头几位，看它出现在了哪些地方。
• 到平台后台看一眼令牌列表：每把令牌的权限、过期时间、最后一次使用时间。

自己验证

• 对每个入口执行 curl -sI，看状态码、server 响应头和页面标题是否一致。
• 在代码仓库的提交记录上看检查结果，数一数每次推送触发了几个平台。
• 查看页面源代码里的 <link rel="canonical">，确认它指向正式域名，而且不会再被跳转。

自己验证

• 在地址栏里故意输入一个不存在的章节、术语或文章地址，看页面怎么回应。
• 打开开发者工具的控制台，把日志级别切到"全部"，看有没有被忽略的警告。
• 断开网络再操作一次，看接口失败时页面显示什么。

自己验证

• 用一个新注册的账号连续请求，确认第几次开始被拦下、返回的状态码是什么。
• 在数据库里看一眼计数表：每次请求都记下了吗？记在谁的名下？
• 到模型平台的后台看实际用量和账单，和自己的计数对一对。

自己验证

• 全项目搜索要删的名字，比如 grep -rn "var(--teal" src，确认每一处引用都有着落。
• 改动前后各构建一次，逐个文件比对构建产物，看哪些页面变了、为什么变。
• 打开用到这些样式的页面，在开发者工具里看计算后的颜色，是不是预期的值。

自己验证

• 差异不为零时，先把两张截图并排打开，找到差异的具体位置，再下结论。
• 同一个页面连续截两次、互相比对：如果差异不是 0，说明测量本身就不稳定。
• 随机挑几个不在清单里的页面，亲手打开看一眼。

自己验证

• 用 curl -N 直接请求流式接口，看数据是一段一段到，还是最后一次性到。
• 在浏览器开发者工具的“网络”面板里看这个请求的时间分解：等了多久才收到第一个字节。
• 回答到一半时点“停止”，再去服务器日志里看这次调用有没有提前结束。

自己验证

• 写一个测试：让 Agent 读取目录之外的文件、调用被禁止的工具，确认都被拒绝。
• 在 Agent 进程里打印它实际拿到的环境变量名（只打印名字，不打印值），看有没有宿主留下的。
• 把请求发到本地一个小服务上截下来，看请求里实际带的是哪个凭证（只看开头几位）。

自己验证

• 同一个请求连发几次，比较上报的 token 数稳不稳定。
• 到模型平台的后台，把一天的账单金额和自己数据库里的调用次数放在一起看。
• 看一眼计数表的结构：除了“谁、什么时候”，还记了什么？

自己验证

• 开一个新会话，只给它交接文档，看它能不能不问你就接着干。
• 在一个干净的目录里重新克隆一份，只照着说明文档从头走一遍。
• 收工前看一眼本机开着的端口和后台进程，确认每一个都有着落。

自己验证

• 合并之前，拉取最新的主分支，把自己的提交变基到它后面，再把构建和检查重跑一遍。
• 看一眼这次的提交动了哪些文件，是不是都在它负责的范围里。
• 换一个 AI 审查时，给它同样的规则文件和验收标准，让它打开页面看结果，而不只是读汇报。

自己验证

• 照你最初发现问题时的操作，自己复现一遍。
• 它说"没有"的时候，追问一句：要是有，这个检查找得到吗？
• 重要的改动，换一个 AI 或一个人，给同样的验收标准，独立查一遍。

自己验证

• 在一个干净的目录里重新克隆一份，只照着说明文档操作，看能不能跑起来。
• 故意拿掉一样必需的东西（资料目录、某个配置），确认启动时就报错，而不是等到第一次提问才出问题。
• 打印 Agent 进程实际拿到的环境变量名（只看名字，不看值），对照你打算交给它的清单。

自己验证

• 对每条"必须做到"的限制，发一个故意越界的请求，确认它真的被拦下，而不是只看提示词里写了没有。
• 列一张表：每条限制、放在哪一层、靠什么验证。没有验证办法的那几条，就是还没守住的。

自己验证

• 改提示词、换模型之后，先跑一遍评测，和改之前的通过率对比。
• 故意配错一个地址，看日志能不能让你在几分钟内找到它。
• 翻一遍反馈清单：标了"已处理"的每一条，都有一条对应的评测题跑通了吗？