review-an-app

审查应用

查看一个已存在的应用，并指出它哪里做得不对。不是指出一个不同、更大、更成熟的应用会有什么，而是指出这个应用自身哪里出了问题。

这不是代码审查，也不是部署门禁。 /code-review 会读取待处理的差异，并且看不到当前分支之前就已存在的问题。deploy-an-app 会判断一次部署能否顺利上线。start-an-app 的评审者会根据应用刚搭建时写下的构建清单进行衡量。这三者的依据都不是应用本身，因此一个运行了六个月的应用会逐渐偏离它们的审查范围。这项技能审查的是应用本身，以及它现在的状态。

基本原则

• 应用本身就是它的规格。 这里没有构建清单，唯一的衡量依据是应用自身的声明——落地页宣传了什么、文档指导了什么、隐私政策承诺了什么、站点地图邀请爬虫访问什么，以及按钮渲染时暗示了什么。发现的问题是应用的声明与实际行为之间的矛盾。其他任何内容都只是建议，而建议不算发现。
• 缺失不算发现。 “没有速率限制”“没有测试”“可以考虑添加结构化数据”——这些都不是应用做错的事，而是更大型应用才会具备的东西。让这项技能失去价值最快的办法，就是让它罗列成熟产品通常会有的功能；这样的报告只会被匆匆看一遍，再也无人理会。
• 只读。 这项技能不会编辑应用。它会运行读取信息的命令，也可能启动应用进行探测，但不会做任何修改。修复是单独且明确的请求——仅限第 6 步，并且只有用户提出要求时才进行。
• 关注后果，而非模式。 每项发现都要说明影响了谁，以及会造成什么后果。“此查询没有按用户范围筛选”只是一个模式；“任何已登录账户只要修改 URL 中的 id，就能读取其他所有账户的发票——src/app/invoices/[id]/page.tsx:14”才是发现。如果无法描述外部如何触及这个缺陷，它就还不算发现。
• 未运行的检查要明确指出，绝不能声称已通过。 这是本系列技能一贯遵循的规则。如果应用无法启动、缺少密钥，或某个路由需要浏览器才能检查，就要说明因此无法进行哪些检查，以及需要什么条件才能进行。沉默会让人以为检查通过了。
• 绝不能得出应用安全的结论。 任何审查都无法证明这一点。诚实的结尾要说明检查了什么、没检查什么；“未发现漏洞”是这项技能绝不能写出的句子，因为之后有人不再继续检查时，可能会引用这句话。
• 用户的选择不算发现。 你会选择不同的技术栈、不喜欢某种设计，或有意让应用不出现在搜索结果中——这些都不代表做错了。如果某项选择看起来像是意外，就报告它是意外的证据，而不是报告这项选择本身。
• 绝不编写或接受版本号。 命令中不行，正文中不行，固定软件包版本也不行。如果某项检查依赖会变化的内容——AI 爬虫的 user-agent 标记、公告数据库、框架的文件约定——就在审查时核实。
• 视角获取证据，不获取访问权限。 它们不能共用端口或浏览器，而且能够运行命令的视角会把预算花在运行命令上。在第 2 步一次性收集信息，交给它们阅读即可。

步骤 1 — 了解应用

在决定检查什么之前，先弄清楚这个应用是什么。花 10 分钟了解情况，就能排除大部分干扰；因为熟悉应用的检查视角不会去查找应用并不具备的支付功能的 Webhook 验证。

通过代码而非提问来确认：

• 技术栈。 查看 package.json、框架、路由器、ORM 和身份验证库。这项技能针对 start-an-app 构建的技术栈编写——Next.js App Router、Better Auth、Drizzle、Postgres 或 SQLite。如果遇到其他技术栈，请在报告中明确说明，并指出哪些检查因此受到影响。 假装能全面覆盖自己并不熟悉的技术栈，不如缩小检查范围并说明能力边界。
• 应用包含哪些功能分支。 登录、电子邮件、上传、支付、AI、后台任务、通过 MCP 访问 Agent、文档、法律页面、同意横幅。每项功能都会启用检查视角中的一个部分；更重要的是，也会让其他部分不再适用。
• 应用是否需要被发现。 查看 robots.ts、robots.txt 和根布局的元数据。这决定了可发现性检查视角的整体方向；如果判断反了，就会得到一份建议优化内部工具的报告。
• 应用声称提供什么。 查看着陆页、文档、法律页面和定价信息。这就是应用的规格说明，因此请先读这些内容，再据此进行检查。

然后用两行说明接下来要检查什么，以及将启用哪些检查视角。如果用户只要求检查一个视角，就只运行该视角。

步骤 2 — 一次性收集证据

references/evidence.md 中列出了相关命令：路由清单、应用能否运行、探测检查，以及需要捕获的内容。三个检查视角会读取同一份捕获结果，因此只需收集一次；开始运行任何一个视角之前，必须确保证据完整。

硬性规则：证据包中不得包含任何密钥。 证据包会交给子 Agent，并在报告中引用。只记录 .env 中的变量名称，绝不记录值；检查 git diff 和已提供的 HTML 是否泄露信息，但绝不整段粘贴。一份泄露了所检查密钥的审查报告，是这项技能造成实际损害的唯一方式。

步骤 3 — 运行审查视角

在一条消息中同时派发它们，让它们并行运行。 每个审查视角都是只读的，都会获取证据包，并有各自的简报。简报位于参考文件中：

审查视角	参考文件	涵盖内容
安全性	references/security.md	OWASP Top 10，基于此技术栈实际存在的问题
可发现性	references/seo.md	sitemap、robots.txt、llms.txt、元数据——是否正确且最新
偏差	references/drift.md	应用声称的内容与实际行为之间的差异

每个审查视角只使用自己的参考文件作为简报，不得使用其他内容——不得使用本文件，也不得查看其他审查视角的输出。一个审查视角若能看到另一个的发现，就会开始附和；三个相互附和的 Agent 看起来像是交叉印证，实际上只是回声。

此处的参考文件是为移交而编写的，这与 start-an-app 的规则恰好相反：其审查者绝不能看到构建应用时所依据的文件。区别在于文件的性质：那些文件是构建说明，交给审查者就会让他们沦为按清单检查的人。而这些文件是为审查者编写的。

无论哪个审查视角提交，每条发现都采用相同的格式：

问题 — 用一句话说明哪里出了问题。 位置 — path:line，或路由及其返回的内容。 矛盾之处 — 应用声称了什么，以及在何处声称。对于安全问题，则说明从外部到缺陷的路径。 确信程度 — 如果文件、命令或响应能够证实，则标为 saw it；如果看起来确实如此，但无法确认，则标为 suspect。 严重程度 — broken（当前有误，且有人受到影响）、at risk（目前能正常工作，但只是侥幸——缺少本应起保护作用的保障措施），或 worth knowing（情况属实、影响较小，无需采取行动）。

控制次要发现的数量，绝不删减严重问题。 单个审查视角给出超过约八条 worth knowing 的发现，说明它已经没有真正有价值的内容，开始凑数了。已确认的 broken 发现绝不能为了符合数量限制而删掉。

步骤 4 — 核实整合

审查视角的工作已经完成，但它们的判断目前都还不能直接采信。

• 对每条 suspect 发现都要先用命令重新核查，再写入报告。 这一步能将审查与猜测区分开来，而证据包已经包含了大部分所需内容。如果命令结果与发现不符，就删除该发现，并用一句话说明已核查并排除。
• 合并不同审查视角之间的重复发现。 隐私政策承诺删除数据，但实际没有任何机制执行，这是一个发现，而不是一个偏差问题加一个安全问题。保留最能说明后果的那一条。
• 删除无法指出矛盾或位置的内容。 到这一步，每条发现都应有 path:line、响应或应用自身页面中的引述。如果都没有，那不过是披着模板外衣的意见。
• 两个审查视角意见不一： 有 path:line 依据的一方胜出。如果双方都有依据，那就确实存在歧义，应在报告中合并为一条。
• 按后果排序，而非按审查视角排序。 报告应是一个有序列表。未经验证的支付 webhook 和过时的 llms.txt，不会因为它们来自不同 Agent 就归入同一章节。

步骤 5 — 报告

按严重程度从高到低排列，用通俗易懂的语言撰写，让不懂代码的人也能看明白。

先说明问题数量和大致情况——“有 4 个问题，其中 1 个很严重”——然后列出具体发现。每项都要说明问题是什么、出在哪里、为什么会影响用户，以及修复需要做什么。不要放一张空空如也的严重程度表；如果某个检查维度没有发现问题，用一行说明即可。这也是检查结果，而不是失败。

接下来，坦诚说明以下内容：

• 检查了什么，以及如何检查。 说明是否实际运行了应用，还是只阅读了代码——这两种方式得出的可信度大不相同，读者无法仅凭检查结果分辨。
• 没有检查什么，以及需要什么条件才能检查。 逐项列出浏览器、密钥、实际支付、生产域名等。
• 结尾绝不声称应用是安全的。 只说明本次审查检查了哪些内容。

如果问题列表很长，或者用户会分享报告，可以提议将其发布为网页，而不是只留在终端滚屏记录里。

步骤 6 — 仅在用户提出要求时修复

审查到步骤 5 即结束。如果用户随后要求修复：

• 先逐项修复已确认的 broken 问题，每修复一项都要验证。
• 修复只涉及问题所指明的文件。 不重构、不整理、不顺手做其他改动——这是某人正在使用的应用，不是脚手架。
• 需要修改架构的修复必须依次执行 db:generate、阅读生成的 SQL，然后执行 db:migrate。 绝不执行 push，绝不编辑已应用的迁移。
• worth knowing 列表中的内容一律不修复，除非用户明确指出要修复哪一项。
• 每次修复后都重新运行相关检查，并明确说明是否因此导致其他问题。