screenshot-critique

截图评审

在接受视觉成果前，先让一个未预先了解背景的子 Agent 再检查一遍。 此流程用于查找视觉缺陷，而非像素指标；如果还需要数字，请搭配 compare-screenshots 使用——即使只有一张截图、没有可供比较的图像，也可以使用该工具，其场景指标会说明画面中是否有内容。

工作流

1. 捕获或找到正在评审的准确 PNG/GIF 帧。
2. 保留原生尺寸证据，并为每个关键特征制作 2x-4x 的补充裁剪图，另附完整截图。包含完整的端点和淡出效果；几何形状发生变化后，重新检查裁剪边界。裁剪所选单位、城市/城镇堆叠、旗帜/旗杆、 阴影、选中环、标签/图标、道路、地形特征、水域以及任何容易出现伪影的区域。如果反馈涉及“太淡”“顺序错误”或“不符合透视”，则必须提供裁剪图。
3. 使用 fork_context: false 启动一个全新的检查者；只传入完整图像、裁剪图和简短、中立的任务说明。评判保真度时，附上已批准的参考图和用户要求；不要提供历史记录、实现细节、先前的评审结论或预期答案。
4. 要求指出具体可见的缺陷，并标注置信度。列出可能的风险类别：单位/道具深度排序、图层、阴影、选中标记对比度、地平面透视、旗帜/旗杆连接、标签样式和图标可读性、模糊、缩放、光照、伪影、模型缺失、地形特征可读性、道路、水域以及整体浏览可读性。
5. 使用 scripts/receipts.mjs 检查返回的评审意见。它标记的每个数字，都是评审意见无法提供命令来证明的主张；它标记的每个文件，都是评审意见提及但从未写入的文件；在这些内容进入决策前，请删除相关主张或自行重新测量。
6. 将子 Agent 的评审意见与自己的检查结果进行比较。重合的内容视为高优先级证据。置信度高的新发现应作为待检查的 Bug，而不是可忽略的审美意见。
7. 在宣称截图已通过验收前，将可执行的发现记录到规范、视觉报告或后续任务计划中。

子 Agent 提示词

使用此格式，替换方括号中的表面，并附上本地图片：

Fresh visual critique task. You have no project backstory and should only
inspect the supplied screenshots and crops. First inspect the full screenshot
for context, then inspect each crop at zoomed scale. Look for concrete
visual/layout defects in [surface], especially unit/prop depth ordering,
layering, shadows, selection-marker contrast, ground-plane perspective,
flag/pole attachment, label style/icons, blur, scale, lighting, artifacts,
missing models, terrain feature readability, roads, water, and scan
readability. Do not assume these are correct. Return a concise list of issues
you can see, with confidence and whether the issue is visible in the full image,
the crop, or both.

Describe what you see in words. You are looking at these images, not measuring
them, so state no pixel value, luminance, percentage, ratio, count, or offset
unless you ran a command that produced it and you quote that command and its
output beside the number. "The hem reads clearly darker than the floor beside
it" is a finding; "44.0 versus 33.6" without a receipt is a fabrication. The
same goes for files: name no artifact you did not create with a tool you
actually have.

启动配置：

• agent_type：explorer
• fork_context：false
• 将截图作为 local_image 项附加
• 除非用户明确要求，否则不覆盖模型
• 需要返回数字时，授予测量工具权限——参见 Receipts

证据凭据

批评中的数字要么是有凭据的数值，要么是猜测，一旦写下来，两者便无法区分。给 Agent 图片并要求它找出缺陷，它就会用提问所设定的语气作答：问它下摆暗了多少，它就会给出亮度均值，因为答案就是这种形式——而不是因为它测量过。有时估算接近事实，有时却会颠倒结论；报告中没有任何信息能让你分辨，而它恰恰因为是数字，读起来像是最有力的证据。同样的本能也会让它说自己写了哪些裁剪图并把它们倾倒出来。

• 让工具的能力与输出要求相匹配。 启动前，先读一遍自己的提示词，问问自己：你要求的每项结论分别由哪个工具得出？只有图片、没有 shell 的评审者只能报告它看到的内容。想要测量结果，就提供能执行测量的工具，并在提示词中明确指出；否则就别再要求测量结果。
• 没有对应命令的数字不算结论。 每个数值都必须附上生成它的命令及该命令的输出，并且两者要相邻，方便一起阅读。缺少这些内容的结论一律删除，不作降级处理。
• 要验证，不要相信验证者的眼睛。 阅读结论前，先对返回的报告运行 scripts/receipts.mjs——node scripts/receipts.mjs <report.md>——这样没有依据的数字就不会先一步显得可信。该脚本会以非零状态码退出，并打印每个缺少依据的数值，以及报告提到却未写出的每个文件。scripts/receipts.eval.mjs 是独立的评估脚本，会检查评估中编写的报告；这些报告的正确答案是按构造已知的，正反两方面都已固定：修改检查器后运行它，绝不要为了让失败案例通过而扩大对凭据的认定范围。
• 弄清楚哪一部分才是证明。 文件检查是证明：它会在磁盘上解析路径，并重新计算所述的 sha256，因此虚构的裁剪图会在这一步被识破。数字检查验证的是归属，而非执行情况——它只检查报告是否展示了一个运行中的命令，且其输出中包含该数字；即使整段命令记录是编造的，报告也能通过。静态文本中没有任何可读信息能区分虚构的记录与真实记录。因此，检查通过意味着结论有据可查且文件真实存在，不意味着命令确实运行过；当数字必须经得起检验时，请索要产物和哈希值。
• 序数描述依然是结论；数字则不是。 “明显更暗”“大约占面板的三分之一”“左边缘被裁掉了”都是观察者可以如实报告的内容。与其试图让它的计算更谨慎，不如引导批评采用这种表述方式。
• 实测流程应单独运行。 如果文字判断足以支持数字，就用 compare-screenshots 自行测量，或者在 shell 环境中按同一凭据规则重新运行评审者。绝不要让报告的作者自己复核数字来修补报告。

规则

• 宣布“已修复”前必须执行： 不要仅凭自己的检查就宣布用户报告的视觉问题已修复——刚刚做完修复，你的判断已经受到影响。先对候选截图进行无预设批评；你想轻轻带过的“轻微残留”，恰恰是这一步要找出的东西。（记录在案的失败：一个被宣布“已修复”的天空问题，经过无预设检查的 Agent 发现，填满整个天空区域的其实是地形网格的底面。）
• 复现报告者的取景方式。 用户提供了截图时，批评中必须包含按该取景方式截取的画面（相同的相机位置、缩放和地点，或尽可能接近且可复现的设置）——在用户取景方式下才会出现的缺陷，在你的取景方式下可能看不见。你选取的探查取景方式只能作为补充，绝不能取而代之。
• 批评前先证明改动确实生效。 先对候选截图和修改前的基线截图做字节或像素差异比较：批评一张没有变化的图，只能“验证”出没有效果。（记录在案的失败：一次调色操作从未进入生产渲染路径——前后截图逐字节相同，只有差异比较才发现了这一点。）
• 交付完整的截图集，不要挑选整理。 你截取的每个状态、每个视口，以及桌面端和移动端都要包含。选择要展示的截图，会带来无预设检查要消除的同一种偏差：你会挑出自己已经认为没问题的那些，而有问题的状态恰恰会被遗漏。若某个状态难以手动进入，就用确定性的方式驱动它并截图，不要省略。
• 没有可用的子 Agent 时，自己站到另一方立场。 对每个待评判的功能，先写一句话，依据截图中可见的内容，尽可能有力地说明它出了问题，然后再做判断。先写出这句话，才能进行对抗性检查；先下结论再找理由，就是这项技能要取代的预设检查。请在报告中附上这些句子，以便复核推理过程。
• 切勿告诉子 Agent 你预计它会发现什么缺陷。
• 使用当前的候选截图，不要使用过时的报告或基线截图。
• 不要依赖缩小后的整页报告来检查小型视觉元素。请附上玩家会查看的具体元素的局部裁剪：选中的军队或城市、标签或图标簇、旗帜、阴影、环形边缘、道路交叉口、地形特征区域、水域标签，以及可疑的调试或伪影区域。
• 如果子 Agent 发现某个局部裁剪暴露的问题在完整截图中不明显或难以看见，只要玩家能在游戏中缩放到该级别，就应将其视为真实的可用性缺陷。
• 对于动画，先附上一组简短且确定性的静帧；GIF 便于人工查看，但静帧更容易明确指出具体缺陷。
• 通过检查的总结不代表可以忽略已报告的小型不匹配或不确定性。请使用 Reference Landmarks 解决；第二种意见不能取代直接检查或回归关卡。
• 如果子 Agent 发现了主 Agent 漏掉的问题，请立即将该失效模式加入相关功能计划或视觉检查清单。