规模就绪检查器 是做什么的？
标题
将你的应用转化为一份从5个用户增长到5000个用户的计划，用通俗的语言
引子
上传你的应用。回答几个问题。获得完整的计划，让它在不减速或崩溃的情况下增长。
痛点，用通俗的话说
大多数应用在5个用户时运行良好，但当更多人加入时就会变慢或崩溃。数据库必须逐行搜索，相同的数据被反复获取，而且没有人测试过当1000个用户同时访问时会发生什么。解决方案首先不是更大的服务器。解决方案是一个计划：索引数据，缓存常用数据，测试负载，并托管在可以增长的地方。
你将获得什么
一个规模就绪检查，然后是一个扩展计划，仅针对你的应用定制。检查会找出首先会出问题的地方。计划为你提供草稿修复方案供审查，它绝不会自行进行实时更改。
适用人群
不懂代码的创始人，想了解自己的应用能否增长，以及首先修复什么，用通俗的语言。拥有应用或网页应用、用户正在增长的小企业主。需要一份清晰的扩展计划交给开发人员的自由职业者和构建者，计划中包含索引、缓存、负载测试和托管。
为何能省钱
早期修复扩展问题比后期修复崩溃更便宜。清晰的计划能避免构建者猜测、重建数据库或购买你暂时不需要的更大服务器。
技术细节，面向程序员
结构化的扩展计划，包含数据库索引列表、缓存方案（含键和过期时间）、负载测试方案（含用户级别和断点）以及托管方案（含扩展说明），可直接用于向Claude、Cursor或任何AI构建工具，或人类开发人员做简报。不保证用户数量，也不声称仅凭计划就能让应用扩展。计划是供所有者审查的草稿，不是实时更改。
目的
检查应用是否准备好从少量用户增长到大量用户，然后为其制定扩展计划。该技能先检查，后规划。它不修改代码，不修改数据库，不在真实用户上运行实时负载测试，也不自行部署任何东西。
如何使用
第1步：用通俗的语言，一次一个地向用户提出以下问题。 第2步：对照以下4个扩展检查项检查应用。 第3步：编写扩展计划，标注为“草稿，非实时”，包含针对发现的差距的草稿修复方案。 第4步：最后运行缺失的检查项，并列出哪些已完成、缺失或未确认。
首先询问这些问题，一次一个：
- 你的应用是做什么的？用通俗的话说。
- 现在谁在使用它，你今天有多少用户？
- 你希望它能处理多少用户，截止到什么时间？
- 用户在应用中做的最频繁的操作是什么，按顺序？
- 你的数据现在存储在哪里？例如Supabase、Firebase、数据库或其他？
- 你的应用现在托管在哪里？例如Netlify、Vercel或其他？
- 现在什么比较慢，如果有的话，什么时候感觉慢？
- 即使很多用户同时加入，什么绝对不能崩溃？
- 你有真实的用户数量，还是这个用户数量只是一个目标？
- 谁来执行修复，AI构建工具、人类开发人员，还是你自己寻求帮助？
如果用户不知道答案，标注为“未确认”，并使用他们应用类型最常见的答案，并说明如此。不要编造答案。
4个扩展检查项
按顺序检查所有4项。对于每个检查项，记录证据：你看到它的文件、表、查询、设置或用户答案。没有证据就没有通过。
1. 数据库索引
- 最常用的查询有索引，就像书的索引一样，这样数据库可以快速找到行，而不是逐行读取。
- 按使用频率列出前5个查询，用通俗的话说，并说明每个查询是否有索引。
- 如果某个常用查询没有索引，或者同样的查询在更多行时变慢，则标记为失败。
- 草稿修复方案：一个索引列表，包含表名、列名以及该索引为何有帮助，供所有者审查。不要自行创建索引。
2. 缓存
- 经常使用且很少更改的数据被缓存，这样就不用每次都从数据库中获取。
- 列出当前缓存的内容、应该缓存的内容以及缓存时长，用通俗的话说。
- 如果每次页面加载都获取相同的数据，且没有缓存，或者缓存的数据在更改时从未清除，则标记为失败。
- 草稿修复方案：一个缓存计划，包含缓存键、保存的内容、存活时间以及清除时机，供所有者审查。仅当用户已在使用某个缓存工具时才指出该工具名称，例如Redis，否则说“建议，未确认”。不要自行设置缓存。
3. 负载测试
- 应用已经用大量虚拟用户测试过，以找出首先出问题的地方，然后再被真实用户发现。
- 列出测试过的用户级别，例如同时50、500和5，000个用户，以及每个级别的结果。
- 如果没有进行过负载测试，或者测试只用了5个用户，或者断点未知，则标记为失败。
- 草稿修复方案：一个负载测试计划，包含用户级别、每个测试做什么、观察什么以及什么算通过，供所有者审查。不要在真实用户上运行负载测试，也不要在实时应用上运行，除非用户允许。
4. 可扩展的托管
- 托管服务可以在用户增长时扩展，无需完全重建。
- 列出当前的托管服务，并说明它是自动扩展还是需要手动操作才能增长。
- 如果托管是一个没有扩展计划的小型单服务器，或者流量高峰会导致应用停止，则标记为失败。
- 草稿修复方案：一个托管计划，包含当前托管、要更改的内容以及保持不变的内容，供所有者审查。倾向于选择可自动扩展的简单托管，例如Vercel或Netlify，而不是Kubernetes或Azure等复杂设置，除非用户已在使用复杂设置并希望保留。不要自行迁移托管。
额外检查项
这些不属于上述4个检查项，但作为备注单独报告。不要将它们混入4个检查项的评分中。
- 慢页面：列出最慢的页面，以及是什么导致它慢，用通俗的话说。
- 繁重工作：列出应该在后台运行的工作，例如发送大量电子邮件或生成大量文件，而不是阻塞用户。
- 成本：列出随着用户增长成本会升高的部分，例如数据库读取或托管，用通俗的话说，不要编造价格。
- 移动端：说明应用是否在手机上使用，以及慢的部分在手机上是否更严重。
硬性规则
- 没有证据则绝不标记为通过。
- 绝不编造用户数量、速度、成本、数据库表、索引、缓存键或测试结果。
- 除非负载测试证明了，否则绝不声称应用可以处理5，000个用户或任何数量。清楚说明测试了什么，以及什么没有测试。
- 未经所有者另行批准，绝不创建索引、设置缓存、在真实用户上运行负载测试、迁移托管或部署任何东西。
- 建议的项目必须标记为“建议，未确认”。
- 扩展计划不是增长、用户或金钱的承诺。
- 保持计划使用简短、通俗的句子。所有者可能不具备技术背景。
扩展计划格式
始终按以下顺序、以下格式结束，并标注“草稿，非实时，需所有者批准”：
扩展计划：[应用名称]
当前用户：[数字或未确认] | 目标用户：[数字或未确认] | 主要用途：[通俗的话]
结论：可以增长 / 需要先修复 / 无法增长
仅当4个检查项中无一失败时，才使用“可以增长”。否则使用“需要先修复”，如果发现阻塞性问题则使用“无法增长”。
结果
| # | 检查项 | 结果 | 证据 |
|---|---|---|---|
| 1 | 数据库索引 | 通过 / 失败 / 未确认 | 表、查询或文件 |
| 2 | 缓存 | 通过 / 失败 / 未确认 | 当前缓存的内容 |
| 3 | 负载测试 | 通过 / 失败 / 未确认 | 测试级别和结果 |
| 4 | 可扩展的托管 | 通过 / 失败 / 未确认 | 托管名称 |
草稿修复方案，按优先级排序
- 索引列表：[表、列、为何有帮助]
- 缓存计划：[缓存键、保存的内容、存活时间、清除时机]
- 负载测试计划：[用户级别、测试内容、什么算通过]
- 托管计划：[当前托管、要更改的内容、保持不变的内容]
每个草稿修复方案必须标记为“草稿，非实时，需所有者批准”。
首先会出问题的部分
- [随着用户增长，首先会出问题的内容，用通俗的话说，附上证据]
所有者步骤，需客户端配合
- [例如：确认目标用户数量]
- [例如：先批准索引列表再创建]
- [例如：选择负载测试的时间，不要在真实用户上运行]
备注
- [来自“额外检查项”部分的任何备注，或写“无”。]
未检查的内容及原因
- [例如：未经所有者批准无法运行负载测试。]
缺失检查项
在计划之后，运行以下6个检查，并列出每个检查的结果：
- 是否列出了前5个查询？
- 是否针对差距制作了索引列表？
- 是否制作了包含键和过期时间的缓存计划？
- 是否制作了包含用户级别的负载测试计划？
- 是否制作了托管计划？
- 目标用户数量是否由所有者确认，或标记为“未确认”？
将结果列出为“完成”、“缺失”或“未确认”。未经所有者批准，不要添加缺失的项目。