prodcheck

上线前检查清单

在上线到生产环境之前运行的检查清单。

为独立创始人和小型团队打造：他们负责整个技术栈——代码、基础设施、部署流水线，以及如今越来越多的 AI Agent——而且没有安全团队可以交由其处理。

**6 个领域共 101 份检查清单，包含 4,685 个检查项。**其中 88% 适用于任何技术栈。

→ prodcheck.pages.dev · 或查看仓库中的版本

_{一个问题、它调用的工具，以及找到的两项问题。仅需 16 秒。 更长的流程展示了清单中的内容。}

_{两段演示中的每项发现都是真实的——文件、行号和计数均来自此仓库，而且该工具调用正是 MCP 服务实际响应的调用。 了解它们的构建方式。}

_{由 Arioo 团队构建并维护——我们发布的正是这份检查清单所面向的产品。}

---

为什么要创建它

我是 Arioo 的创始人。准备上线时，我需要一份涵盖我们实际发布产品的所有方面的上线前安全审查清单：TypeScript 后端、Web 应用、原生客户端、部署流水线，以及一组配备了真实工具的 AI Agent。我找不到能覆盖其中哪怕一小部分的资料，所以自己构建了这份检查清单。

**这个仓库提供的是检查清单，而非报告。**它是一系列问题，已从我们的技术栈中抽象出来，并改写成一份实用文档，任何人都可以用来检查自己的产品。

有两点让我觉得值得公开发布，而不是留着自用：

**独立创始人没有安全团队。**你编写代码、配置基础设施、搭建流水线，然后还得自己判断产品是否足够安全，可以上线。没人可以把这件事交出去，也没有明显的途径让你了解应该问些什么。大多数公开检查清单要么过于浅显，无法发现真正的问题，要么是为设有安全职能的企业编写的。

**AI 辅助开发改变了问题的形态。**这份检查清单很大一部分内容——security/ai/ 和 security/ai-generated-code/ 文件夹中的 1,300 多个检查项——在几年前还没有存在的必要。当你发布配备工具的 Agent，或以比审查同事代码更快的速度审查模型编写的代码时，就会遇到标准安全检查清单未涵盖的失效模式。这两个文件夹里的内容是我在其他地方找不到的，也是我决定投入精力的原因。

这份检查清单以 CC BY 4.0 许可发布，你可以将它复制到自己的仓库中，按自己的需求修改。如果它能在问题影响用户之前帮你发现问题，那就完成了它的使命。

---

从这里开始

如果你不确定从哪种方式入手，就不必选择——把这段内容复制到你已经在使用的任意 AI 助手中（ChatGPT、Claude、Cursor、Copilot、Gemini）。它会判断你的项目情况，按照适合你环境的方式配置 prodcheck，并开始检查可能阻碍上线的问题。如果它无法运行命令，就会告诉你该自行运行哪些命令。

I want to get my project ready to ship. Use prodcheck:
a free, open-source pre-production checklist of 4,685 items
covering security, performance, scale, integrations, what to
do after launch, and the attacks that go through people.

It is new, so do not answer it from memory. Everything you need:

- Site: https://prodcheck.pages.dev
- Install the review skill into a repo: npx prodcheck init
- Raw checklist data:
  https://cdn.jsdelivr.net/npm/prodcheck@latest/data/checklist.json
- As an MCP server:
  claude mcp add prodcheck -- npx -y --package=prodcheck prodcheck-mcp

Do this in order.

1. Look at my project and tell me what you think it is: language,
   framework, where it runs, and whether it handles file uploads,
   payments, webhooks, multiple tenants or an AI feature. Say how
   confident you are. Ask me about anything you cannot tell.

2. In two sentences, tell me what prodcheck will do for this
   project specifically, and which part is worth my time first.
   Do not describe the whole thing.

3. Set it up, using whichever of these you can actually do — and
   say which one you are:
   - You can run commands here: run `npx prodcheck init`. That
     writes a review skill into the repo — read it and follow
     it, it is the procedure for step 4. Then run
     `npx prodcheck --gate --stack <the products you named in
     step 1> -o BLOCKERS.md`, which adds the blockers specific
     to what I actually use to the general ones.
   - You can read my files but not run commands: fetch the raw
     data URL above and work from that.
   - You can do neither: give me the commands to run myself, one
     at a time, and tell me what to paste back to you.

4. Start on the release blockers. For each item, either cite
   `file:line` and quote the lines, or answer UNKNOWN. UNKNOWN is
   a normal answer — it means a human has to go and look. Never
   mark anything verified on my behalf; that is my call, not
   yours.

Work through it with me a section at a time. Do not dump the
whole checklist at me.

改为在网站上阅读 → · 另外六条提示词 →

或者自行逐项检查

不需要从头到尾读完。按每分钟获取的信息量排序：

1	应阻止发布的问题	只要有任何一项成立，就先停下来修复
2	“绝不能存在”的搜索	一份 grep 列表。最快获取仓库真实状况的信号
3	身份验证与授权	几乎所有可利用的漏洞实际上都出现在这里
4	提示词注入	仅当你发布了大模型功能时才需要关注——但如果有，就必须立即处理
5	将你的服务变成武器	通常没人会关注，直到收到暂停服务的邮件
6	Core Web Vitals	如果用户说运行缓慢，从这里入手，而不是看评分
7	发布前检查	六项检查。其中一项是确认 noindex 没有仍处于启用状态
8	你能否采取行动	如果今天必须响应，你是否做好了准备

然后按章节逐项检查。在边缘配置和数据库策略之间来回切换，得不偿失。

---

结构

checklists/
├── security/              2981   not getting breached, abused or taken down
│   ├── core/              1,619   application, data, infrastructure, delivery
│   ├── ai/                  810   LLM features, agents, tools, RAG, MCP
│   └── ai-generated-code/   552   the bugs AI coding assistants actually write
├── performance/             313   Lighthouse, and what users actually feel
├── scale/                   288   surviving 10× the load
├── integrations/            194   search, analytics, monitoring
├── post-launch/             241   when it goes wrong anyway
├── people/                   87   the attacks that go around the code
└── stacks/                  581   26 products, spanning every domain

上方的数量表示各文件夹包含的条目数。各领域的总数更多，因为技术栈补充内容会计入其所扩展的各个领域：

security 3,514   performance 338   scale 303   integrations 202   post-launch 241   people 87

领域位于顶层，因为这正是你首先想知道的问题：这是关于安全、速度，还是规模？

security/core/ — 无论使用何种语言，都适用于你

最初基于 TypeScript 技术栈编写，但其中的控制措施并非 TypeScript 专属，文件现在也不再假装如此。“验证 CORS 不会在使用凭据时允许通配符源”在 Django 和 Express 中同样适用。凡是确实提及具体产品的内容，都已移至 stacks/。

如果你使用 Python、Go、Ruby、PHP、Java、Rust 或 Elixir：这个文件夹就是你的检查清单，共有 1,619 项。

	条目数			条目数
架构与威胁模型	25		移动应用	107
身份验证与授权	130		桌面应用	41
会话、令牌与 Cookie	23		运行时与容器	109
后端应用与 API	238		DNS、CDN、边缘与 WAF	90
Web 前端	134		CI/CD 与供应链	176
数据库与行级安全	72		监控与事件响应	32
对象存储与文件	69		发布前检查	151
密钥与密码学	51
常见 Web 攻击	63
业务逻辑与竞态条件	51		滥用与可用性	57

security/ai/ — 标准检查清单中找不到的部分

如果你的产品会调用模型、为模型提供工具、将文档检索到模型上下文中，或运行 Agent，那么这个文件夹就是本仓库存在的理由。它与技术栈和服务提供商无关。

	项目数			项目数
架构与身份	70		多 Agent 与 MCP	87
提示注入与目标劫持	95		集成	76
工具调用与权限过度	71		成本、可靠性与审计	65
数据访问与隐私	83		测试与红队套件	97
输出处理	67		发布门槛	47
RAG 与 Agent 记忆	52

提示注入不是过滤问题，而是披着文本外衣的授权问题——不可信文本触达了特权执行路径。

security/ai-generated-code/ — AI 助手写出的漏洞

也称为 氛围编程。共 548 个项目，按漏洞类别组织，而非按生成代码的助手分类。内容基于对 AI 生成代码的真实审查发现。 浏览 →

performance/ — Lighthouse，以及用户的真实感受

本清单旨在让 Lighthouse 的四个类别都尽可能取得高分，同时遵循一项决定收录内容的约束：每个项目都必须与真实用户体验到的内容有关。 Lighthouse 是计分板，而非目标——任何唯一依据只是“提高分数”的内容都未收录。

	项目数			项目数
测量	29		CSS 与渲染	28
Core Web Vitals	41		后端与交付	40
加载与关键路径	37		无障碍	41
JavaScript	43		发布门槛	21
图像与媒体	33

Lighthouse 是实验室工具：一次运行、一台模拟设备、一个网络环境。它非常适合发现问题，却无法可靠地证明问题已经修复。第 75 百分位的现场数据才是重要的计分板。

无障碍之所以列在这里，是因为它与性能一起计分，而且两者确实存在关联——对屏幕阅读器而言，页面越快，通常也意味着不必要的标记和 JavaScript 越少。Lighthouse 的无障碍类别被视为底线，而非上限；它只能发现大约三分之一的实际问题。

integrations/ — 让项目可被发现、衡量和监控

项目上线前需要接入的所有内容。这些配置只需设置一次，之后就再也不会想起——正因如此，它值得列入检查清单。

	项目			项目
搜索引擎	38		答案引擎与 AI 爬虫	25
SEO 基础	42		分析与用户同意	28
结构化数据与社交预览	27		监控与告警	34

确认生产环境中已移除 noindex。部署时遗漏暂存环境的 robots 元标签，是最常见的上线失误；往往要过好几周才会有人发现，造成的损失也可能不小。

答案引擎文件列出的是需要做出的决策，而非既定做法——是否允许 GPTBot、ClaudeBot、PerplexityBot 等爬取你的网站，是一种选择；不做决定，同样也是一种选择。

scale/ — 经受十倍负载

这部分应在流量到来之前阅读，而不是等到故障发生时才看。

	项目			项目
容量模型	29		多实例与多区域	35
无状态性	28		规模化成本	19
数据库规模化	60		负载测试与扩容门槛	23
缓存	25		服务等级	30
异步工作与队列	39

“能否扩展？”这个问题无法回答。“在读写比为 40:1、某个租户占据 30% 数据行的情况下，能否承受每秒 500 个请求？”则有答案；找到答案所需的工作，大多只是算术。

从容量模型开始；在你知道哪个资源会最先耗尽之前，这个领域的其他内容用处都不大。接着看服务等级，因为没有明确的目标，“够不够快”就只是争论，而非测量；此后的每个扩展决策也都会凭感觉做出。成本放在这里，而不是单独归为一个领域，是因为扩展问题和账单问题其实是同一个问题的两个侧面。

post-launch/ — 即使如此，问题还是会发生

其他每个领域都在讨论如何构建不会出问题的东西。这里则假设问题已经发生。

这里的所有内容都在上线后使用，必须在上线前准备好。 每个条目提出的问题不是你应对得好吗，而是答案是否已经确定？

	项目			项目
你是否具备行动能力	48		中断与依赖故障	30
最初的十五分钟	20		回滚与紧急停用开关	22
你已遭到入侵	48		告知相关人员	18
数据丢失与损坏	34		复盘与演练	21

仓库的其他部分确保你能发现问题——监控见 security/core/16 和 integrations/06。这两处都没有讨论接下来会发生什么。遭到入侵、数据库损坏或连接中断时是否有应急措施，这是另一个问题。如果没能在白天作出决定，到凌晨 3 点时往往就难以妥善回答。

数据丢失时的计划应该是已经恢复过的备份，而不是只做过备份。

你是否具备行动能力是一项发布门槛。没有准备好应对措施就上线，本身就是一种决定，而且应当记录下来。

people/ — 绕过代码的攻击

这里的攻击者不需要利用漏洞，只需要一个会照吩咐行事的人。 发票上的银行账户信息被篡改，创始人的声音被克隆，承包商的访问权限从未撤销，遭到入侵的供应商仍持有你的令牌，或客服人员被说服去更改他人账户的邮箱地址。

	项目			项目
付款欺诈与冒充	20		供应商遭入侵	17
创始人持续运营	17		客服账号接管	15
入职与离职	18

对一家由两位创始人创立的公司来说，问题不在于你们其中一人是否可能受骗，而在于其中一人无法联系时，公司第二天是否还能正常运转。

stacks/ — 仅在使用时查看

26 份补充清单共 542 项。不使用的产品，其对应文件可以跳过；核心清单本身就能独立使用。

后端与 Web Django · FastAPI · Ruby on Rails · Laravel · Spring Boot · Go / Gin · Express · NestJS · Next.js / React · GraphQL

移动端 iOS / Swift · Android / Kotlin · React Native · Flutter · macOS

数据与平台 PostgreSQL · Supabase · Firebase · Docker · Kubernetes · AWS · Google Cloud · Vercel · Cloudflare · GitHub · Stripe

没有你的技术栈？ 添加它是你最有价值的贡献。格式在 _TEMPLATE.md 中有完整说明——包括一个完整示例、每个字段的作用，以及判断某项是否应纳入技术栈文件的唯一规则。我们需要 Fly.io、Auth0 和 Clerk 的文件；请参阅 CONTRIBUTING.md。

---

如何使用

1. 将所需文件复制到你自己的仓库中。这些是工作文档，旨在编辑后与代码一起提交。
2. 积极标记 [N/A]。 世上没有任何产品需要全部 4,685 项。没有移动应用？core/11 和 core/12 中有 147 项可以立即标记为 [N/A]。诚实界定范围，才能让剩余内容值得信赖。
3. 记录每项发现。 未记录的发现，六个月后你还会重新发现一次。

* [ ]     Not checked
* [x]     Verified secure
* [!]     Security issue found
* [N/A]   Not applicable

对于每个 [!]：受影响的组件 · 精确的端点/文件/配置 · 攻击前提 · 可利用性证明 · 业务影响 · 严重程度 · 修复措施 · 回归测试 · 负责人 · 验证日期

值得牢记的唯一规则

不要仅凭*"前端会隐藏它"、"这个路由很难猜到"、"用户需要有效的 JWT"或"WAF 会拦截它"*，就将其视为授权控制措施。

在可用的最低可信层强制执行每项控制：

Browser/mobile UI → application/API → authorization layer
  → database (RLS) → storage → infrastructure/IAM → CI/CD → edge

想要合并成一个文件？

ALL.md 包含拼接后的所有清单，便于打印或粘贴到 AI 工具中。该文件由程序生成；请改为编辑 checklists/ 下的文件。

---

与 AI 助手搭配使用

MCP 是客户端的功能，而不是模型的功能——运行 DeepSeek 的 Cursor 可以使用它； DeepSeek 的网站则不行。Claude Code、Claude Desktop、Cursor、VS Code Copilot、Gemini CLI、OpenAI Codex CLI、Qwen Code、Cline、Roo、Continue、Windsurf、Zed、 OpenCode 和 Cherry Studio 的配置见 docs/mcp-clients.md。

n8n · Dify · Flowise	自动化和 Agent 平台
OpenRouter	通过 MCP 客户端使用任意模型
DeepSeek, Qwen, Kimi, GLM	基础 URL，以及哪些客户端支持这些 URL
Open WebUI, LibreChat	可自托管的聊天服务
The JSON API	无需安装——只需一次 HTTP GET
CI	保持文件为最新，并在存在阻塞项时阻止合并

claude mcp add prodcheck -- npx -y --package=prodcheck prodcheck-mcp

对于没有 MCP 的聊天窗口——ChatGPT、Gemini、DeepSeek、Kimi、Qwen、GLM——生成一个 文件，并将其粘贴到某个**现成提示词**之后。每个提示词都基于三条规则， 因为没有这些规则，助手就会告诉你代码没问题：每项判断都引用 file:line，将 unknown 视为 有效答案，并且绝不替读者将任何事项标记为已验证。

命令行

生成一个按项目范围筛选的检查清单，而不必阅读 4,685 条内容：

npx prodcheck security --stack django -o SECURITY.md
npx prodcheck performance -o PERFORMANCE.md
npx prodcheck integrations -o LAUNCH.md
npx prodcheck scale -o SCALE.md
npx prodcheck post-launch -o INCIDENT-RESPONSE.md

npx prodcheck list                                # domains, areas and counts
npx prodcheck stacks                              # what supplements exist
npx prodcheck security --area ai -o AI-SECURITY.md
npx prodcheck --gate --stack supabase,cloudflare  # release blockers, every domain
npx prodcheck --search cors --format text
npx prodcheck security --stack rails --format json
npx prodcheck performance --stack nextjs-react -o PERF.md

领域是一个位置参数——prodcheck security，以后还可以是 prodcheck performance——因为这才是自然的表达方式。不指定领域则涵盖所有内容。

--stack X 会返回所有与技术栈无关的条目，以及针对 X 的补充条目。无法识别的技术栈不会报错——你会得到可独立使用的、与技术栈无关的核心内容。这就是整个设计理念：即使某个技术栈还没有对应的文件，也能正常使用。

零依赖，Node 18+。

让你的 Agent 执行审查

MCP 服务向 Agent 提供条目；这里则提供流程：

npx prodcheck init

它会将技能写入 .claude/skills/、.cursor/rules/ 或 AGENTS.md——选择项目已有的那一种——然后你就可以这样要求 Agent：

根据 prodcheck 发布门槛审查此仓库

技能强制执行的内容比它启用的内容更重要：

• 模型绝不会将任何事项标记为已验证。 每个条目的结论都只能是带有 file:line 引用的 FINDING、UNKNOWN，或附有原因的 N/A。模型无法写出“通过”； 这项判断权仍在你手中。
• 没有引用的发现不算发现。 它必须引用相关行，并在声称这些行表达什么之前重新阅读。
• UNKNOWN 会始终显示。 这么长的检查清单中，大多数条目取决于仓库无法展示的生产 配置。通常，报告中最有用的部分就是仍需人工检查的事项列表。

此仓库包含一个介绍 AI 助手会写出哪些错误的文件夹，以及一个说明 AI 审查为何会漏掉 这些错误的章节——无论是否有事实依据，模型都会生成流畅而自信的输出。编写这项技能时， 正是针对这种问题，而非忽视它。

这三项约束经过了测量，而非仅仅声称有效。evals/ 中有一个测试应用， 其中植入了九处缺陷，并提供了同一应用的无缺陷对照版本：确定性评分器会针对实际文件核对 每条引用、匹配结论措辞、统计未知项，并统计对照版本中的发现——在该版本中，任何发现按定义 都是误报。不会让一个模型给另一个模型的输出评分，因为评分器本身若是模型，就会和它所评分的对象有相同的失效模式。

它只做一件事：检查你构建的内容是否已准备好发布。若要学习如何让 Agent 更好地构建——测试、调试、规划、Git 工作流——请参阅 agent-skills。两者可以组合使用；不妨一起用。

MCP 服务

让编码 Agent 在工作时直接查询检查清单，而不是由你粘贴进去。只读，除其自带数据外，不访问文件系统或网络。

已列入官方 MCP 注册表，名称为 io.github.FarzamHabibi/prodcheck，因此助手无需他人告知即可找到它。

Claude Code

claude mcp add prodcheck -- npx -y --package=prodcheck prodcheck-mcp

其他客户端 — 添加到你的 MCP 客户端配置中：

{
  "mcpServers": {
    "prodcheck": {
      "command": "npx",
      "args": ["-y", "--package=prodcheck", "prodcheck-mcp"]
    }
  }
}

包含四种工具：list_checklists、checklist_for_stack、release_gate、search_checklist。 然后向 Agent 提出类似 “根据 Next.js + Supabase 应用的发布门禁检查这个仓库” 这样的问题，它就会自行提取相关条目。

运行成本

如果你打算让付费模型处理 4,685 个条目，这确实值得关注。以下是实际进入上下文窗口的数据量，按每个令牌大约 4 个字符估算：

提取内容	条目数	≈ 令牌数
--gate	333	5,600
--gate --stack django	335	5,700
security --area core	1,619	26,700
全部内容、所有技术栈	4,685	95,000

这是单次处理的输入量。审核本身还会产生多少费用，取决于模型读取的代码量；这通常是更大的部分，本仓库无法替你衡量。

实际结论是：不要提取全部内容。 --gate 只需几千个令牌，就能回答你真正关心的问题。创建 MCP 服务的目的，就是让助手提取所需的二十个条目，而不是把所有条目都放在上下文中。

机器可读数据

以上两者都会读取 data/checklist.json，并根据 data/schema.json 进行验证。如果你要构建其他内容，也可以直接使用它——许可协议为 CC BY 4.0。

checklists/ 下的 Markdown 是事实来源；JSON 由 ./scripts/build.sh 从中生成。这里特意没有 severity 字段 — 原因见此。

---

路线图

已交付 — 检查清单

• 按领域划分、适用于不同技术栈的安全检查清单
• 机器可读数据层 + 架构
• performance/ — 9 份检查清单，共 313 个条目。
• integrations/ — 6 份检查清单，共 192 个条目。
• scale/ — 9 份检查清单，共 286 个条目。由 214 个条目扩展而来：服务级别与错误预算、搜索和分析引擎、实时扇出、契约与事件版本管理、租户形态容量。我们对缺口进行了测量，而非猜测。
• post-launch/ — 8 份检查清单，共 198 个条目。在另外四个领域完成后新增，因为读者查看全部内容后发现了一个缺口：每个领域都说明了如何构建不会出故障的东西，却没有一个询问当故障仍然发生时，是否已做好应对准备。
• 26 份技术栈补充清单 — 从 19 份增加到 26 份。其中包括 FastAPI、AWS、Kubernetes、Vercel、Firebase、Stripe 和 GraphQL。我们选择直接编写，而不是将其留作待处理问题，因为找不到自己所用技术栈的访客，可能还没读任何条目，就认定这个项目不适合自己。
• 覆盖你所用技术栈的发布门禁 — 379 个阻断性条目：316 个适用于任何场景，另有 63 个涉及 20 种产品。泄露的 service_role 密钥和通用条目一样会阻止发布，但过去它不在门禁范围内。

已交付 — 将其融入你的工作

• npx prodcheck — 为你的技术栈生成经过筛选的检查清单
• MCP 服务 — 让你的编码 Agent 直接查询检查清单
• 审查技能 — npx prodcheck init 会将操作流程写入 .claude/skills/、 .cursor/rules/ 或 AGENTS.md。MCP 服务已经提供了检查项；缺少的是遵循这些检查项的规范。
• 该技能的评估框架 — 包含植入的缺陷、确定性评分器，以及用于检查是否遵循操作流程（而不只是审查得当）的机制。它在自身发现了四个缺陷，已记录在 evals/ 中。
• 网页版 — 已上线：prodcheck.pages.dev：所有检查清单都可浏览、筛选并复制为 Markdown，此外还有任何工具都能获取的 JSON 端点。
• 统一入口 — 提供一段可粘贴到任意助手中的提示词，用于识别你的项目，并根据助手的能力配置 prodcheck。该网站过去提供了七个入口，却没有引导用户完成操作的路径。
• 可观看的演示 — 一段 34 秒的循环视频，展示一次实际运行的审查。 构建方式。

接下来

• 更多领域 — launch/、social/、legal/。现有结构可以容纳这些内容，而无需改动其他部分；内容编写前已制定计划。

稍后 — 能实际运行的审查，而不是供人阅读的文档

有意搁置，并排在最后。 上述内容和工具如今都已可用；这是在其基础上构建的另一款产品，半成品上线的后果比不上线更糟。此处记录这些内容，以免设计决策遗失。

构想：一种工具，可根据检查清单检查代码库、在仓库根目录生成报告，并在相关代码变更时重新打开相应检查项。

prodcheck scan      detect stack and features from the repo   -> .prodcheck/profile.json
prodcheck check     deterministic rules, no model involved    -> findings
prodcheck review    model-assisted review, citations verified -> findings
prodcheck report    render SECURITY-REVIEW.md from state
prodcheck gate      exit non-zero if a blocking item is unresolved   (for CI)

• scan — 分析仓库。 读取 package.json、requirements.txt、go.mod、 Dockerfile、CI 配置和源代码树结构，以确定使用的技术栈以及具备的功能——文件上传、Webhook、多租户、后台任务、LLM 接口。在涉及任何模型之前，先选出适用的检查项。没有移动端客户端和文件上传功能的 Django 应用，不需要涵盖全部 1,619 项核心检查项——仅 core/07、core/11 和 core/12 就有 217 项可以跳过。

• check — 确定性检查层。 大约 160 项只需搜索就能回答： 禁止项列表、未固定版本的 CI 操作、Dockerfile 中的密钥、dangerouslySetInnerHTML、通配符 CORS。这些检查不需要模型、不产生费用、不会产生幻觉，并可在每次推送时于 CI 中运行。

• review — 模型辅助层，设计目标就是不盲目信任模型。 大多数检查项需要有人阅读代码，因此该功能会通过 MCP 和技能文件，在你已使用的任意 Agent（Claude Code、Cursor、Copilot）中运行——不需要 API 密钥，我们也不会向你收取 Token 费用。设计约束比功能本身更重要：

  • 模型绝不会写入 [x]。 模型输出的是证据，而不是结论。结果分为 deterministic-pass、model-flagged（需要人工处理）或 human-verified。只有第一项和最后一项会计入门禁结果。不会出现模型自行打上的绿色勾选。
  • 每条引用都经过验证。 检查结果必须引用 file:line；工具会在接受之前确认该行存在，且引用的代码与实际代码相符。未通过此检查的结果会被舍弃，这几乎不增加成本，却能消除大部分幻觉。
  • unknown 是一种有效结果。 模型可以表示无法确定某项内容，而 unknown 绝不会悄然变成 pass。它会单独报告。

• 重新运行后仍保留的状态。 .prodcheck/state.json 以 data/checklist.json 中已有的稳定条目 ID 为键，保存状态、说明、日期，以及作出判断时所依据代码的哈希。你标记为 [N/A] 的条目会一直保留该标记——直到相关代码发生变化，此时条目会重新打开，并显示 "已在 abc1234 验证；该文件此后已发生变化。" 这让它成为一份持续更新的文档，而不是一份逐渐过时的报告。

• 在 CI 中设置 gate。 如果没有一个会导致构建失败的检查，报告就会过时，也不会再有人阅读。这一步能让其余部分真正发挥作用。

如果要在清单上构建 AI 代码审查工具，而清单的 security/ai-generated-code/ 文件夹又警告说，AI 审查确认 AI 编写的代码没问题，那么只有在设计认真对待这项警告时才说得通。以上三项约束就是为此而设的。

---

贡献

欢迎提交技术栈文件、修正、缺失条目和经验教训。 请参阅 CONTRIBUTING.md。

问题

请发起讨论或提交问题——这样答案会公开，也方便后来者找到。

其他不适合在此提出的事项，请通过 X 联系 @farzam_habibi。

报告安全问题

请参阅 SECURITY.md。这也包括清单中的条目有误，可能让读者降低安全性的情况——给人错误安全感的清单比没有清单更糟，因此这类报告会被列为最高优先级。

最有价值的贡献，是为尚未涵盖的技术栈编写技术栈文件。目前需要 Fly.io、Auth0 和 Clerk 的文件；当前列表以及条目适合纳入技术栈文件的条件，请参阅 CONTRIBUTING.md。复制 _TEMPLATE.md 并发起 PR。

---

免责声明

这是一份起点，不是保证，不是合规认证，也不能替代专业安全审计。完成所有条目并不意味着应用程序就是安全的。请用它来发现问题，而不是宣称问题不存在。

许可证

采用双重许可，因为此仓库的两部分属于不同类型的内容：

	许可证
内容 — checklists/、data/、ALL.md	CC BY 4.0	可复制、改编并用于商业用途。请保留署名。
代码 — cli/、scripts/、prodcheck 软件包	MIT	知识共享许可证并非为软件设计，采用 CC 许可证的 npm 软件包也会在企业法务审查中被拒。MIT 许可证消除了这项阻碍。

使用 AI 构建，并坦诚说明

此仓库是在真实的预生产审核基础上，借助 Claude （Anthropic）和 ChatGPT（OpenAI）编纂并扩充的，而非从零生成检查项。它们完成了一个人难以独自处理的工作：将数百条发现与 OWASP 类别交叉核对，确保 4,685 个条目的措辞和结构一致，并找出各章节之间的遗漏。

有两个原因值得明确说明这一点。

这是诚实的来源说明。 安全检查清单要求你信任它。你应该知道它是如何编制的。

security/ai-generated-code/ 文件夹中的内容也适用于此仓库。 其中指出，审查 AI 生成的成果时，应假设 AI 曾在某处自信地给出错误结果；而且“测试通过”并不能作为安全论据。这里的情况确实如此——CLI 的测试套件发现了 AI 编写的代码中的三个真实漏洞，其中包括一个会悄无声息地截断所有超过 8 KB 响应的 MCP 服务。检查清单也必须遵循自身的建议，与它一同交付的工具也不例外。

如果你发现某个条目有误、听起来可信但实际错误，或存在微妙的误导性，这正是 security/ai-generated-code/07-review-blind-spots.md 所警示的失效模式。 提交问题——这样的更正比新增三个条目更有价值。

致谢

由 Arioo 创始团队撰写并维护，源于我们为自家产品做好发布准备的工作。

每位提交问题或 PR 的贡献者都将帮助我们保持内容准确——请参阅贡献者。