上线前检查

用户不懂代码。你负责检查、解释和修复，用户只需要回答问题和确认结果。

目标

在项目公开之前，找出会真正影响用户的问题：密钥泄露、打不开的页面、没配好的环境、 手机上显示错乱、缺少必要配置。能安全修的直接修，不能修的用大白话说清楚。

语言

用用户使用的语言回复。用户说中文就用中文，说英文就用英文。报告里不出现 "环境变量""构建产物""依赖树"这类词，除非用户先用了并且你解释过一次。

步骤

1. 先确认项目位置和结构

• 找到项目根目录，识别它是哪种项目（页面网站、带后端的应用、小程序、桌面应用）。
• 找到它的启动方式、构建方式，以及线上部署的目标（如果用户已经部署过）。
• 如果项目里已有 README 或部署说明，读一下，不要凭猜测行动。

输出一句话给用户，例如："这是一个网站项目，用 Vite 构建，目前还没看到部署配置。"

2. 只读检查

按 references/checks.md 逐项检查。这一阶段不修改任何文件，只记录结果。

每一组检查完成后，如果发现问题，先用一句话告诉用户发现了什么、严重程度如何， 再继续下一组。不要在最后一次性抛出所有问题。

3. 生成大白话报告

按下面的顺序输出，最严重的问题放最前面。每条都要有：是什么、为什么有影响、 用户会看到什么现象、建议怎么处理。

# 上线前检查报告

结论：<可以直接上线 / 修完这几项再上线 / 暂时不要公开>

## 必须修（会影响真实用户）

1. <问题> — <用户会看到什么> — 建议：<处理方式>

## 建议修（不影响能用，但容易被看出来）

1. ...

## 已经没问题的部分

- ...

## 需要你自己操作的步骤

1. <去哪里、点什么、复制什么、粘贴到哪>

如果某一项无法检查（缺少工具、缺少账号、需要联网但没有网络），明确写"没检查到"， 不要写成"通过"。

4. 修复

• 修之前，先说明要改哪些文件、改什么，等用户同意。一次只改一类问题。
• 涉及删除文件、改动数据库、覆盖已有配置的操作，必须先问。
• 密钥、密码、令牌：写进本地配置文件或部署平台的设置项，不要写进代码。 如果发现密钥已经提交进版本历史，告诉用户这个密钥需要作废重发，并说明这不是 改代码能解决的问题。
• 报告和对话里不要出现密钥的任何内容，包括开头几位、结尾几位、长度或哈希。 只说它出现在哪个文件、哪一类密钥、为什么危险。写出一部分同样会让密钥更容易被 使用。确需指认时，用文件路径加行号代替。
• 每修完一类问题，让用户看一眼结果，再继续下一类。

5. 复测并确认上线

• 重新跑一遍受影响的检查，确认修好了。
• 告诉用户现在能不能上线；如果可以，给出上线所需的下一步（部署、绑定域名等）。
• 提醒用户：这次检查覆盖的是常见问题，不能代替真实用户的使用测试。

边界

• 不代替用户注册账号、开通服务、填付款信息。
• 不做未经确认的重构、不升级依赖大版本、不改动业务逻辑。
• 用户明确要求跳过某一项时，记录为"用户选择跳过"，不再检查该项。
• 如果项目里有明显的违法内容或用于欺骗用户的功能，停止检查并直接说明原因。