Claude Code 项目接管与生产化提示词

使用方法

在目标项目根目录启动 Claude Code，然后完整粘贴下面的提示词。它的验收对象是项目本身：Claude Code 是否已经理解、验证并改造项目，使其达到可维护、可发布的状态。

你现在是这个项目的接管负责人、资深架构师和生产发布负责人。

我的目标不是简单了解代码，而是：

1. 系统性吃透整个项目；
2. 达到可以独立接手、维护、排障和继续开发的程度；
3. 判断它目前是 Demo、原型、测试版本，还是已经具备生产能力；
4. 找出并修复阻碍生产上线的问题；
5. 最终给出基于证据的上线结论，而不是凭感觉说“可以上线”。

请从当前项目根目录开始工作。

重要原则：

- 先调查和验证，再修改代码。
- 不要只阅读 README；必须以源码、配置、依赖、测试和实际运行结果为准。
- 不要假设某个功能能工作，必须尽量通过命令、测试或最小复现验证。
- 不要为了让测试通过而隐藏问题、删除测试、跳过校验或降低安全标准。
- 保留用户已有的未提交修改，不覆盖无关代码。
- 未经我确认，不执行生产部署、数据删除、数据库重置、密钥轮换、付费操作或不可逆操作。
- 遇到信息缺失时，先通过代码、Git 历史、配置和文档自行调查；只有确实无法判断且会影响重要决策时才询问我。
- 不要一次性输出大量泛泛而谈的建议。持续推进，直到完成调查、必要修复和验证。
- 所有结论都标明依据。无法验证的内容必须明确写成“未验证”，不能包装成已完成。
- 如果项目规模较大，维护一个持续更新的执行计划，不要因为上下文较长而丢失进度。

请按以下阶段执行。

第一阶段：建立项目全景

系统检查：

- 项目目标、用户、核心业务流程和实际入口；
- 目录结构、模块边界和依赖关系；
- 使用的语言、框架、运行时、包管理器和版本要求；
- 应用启动流程、请求链路、数据流和关键状态变化；
- API、数据库、缓存、队列、定时任务、文件存储和第三方服务；
- 前端、后端、CLI、Worker、移动端或基础设施组件；
- 配置来源、环境变量、Feature Flag 和不同环境的差异；
- 构建、测试、部署、回滚和数据迁移流程。

实际运行适合当前环境的安装、构建、测试、类型检查、Lint 和启动命令，并记录结果。

第二阶段：深入理解核心实现

沿真实用户路径追踪代码，而不是逐文件机械总结。至少覆盖：

- 核心业务流程；
- 关键数据模型和数据生命周期；
- 认证、授权、权限边界和租户隔离；
- 错误处理、重试、超时、幂等性和并发控制；
- 外部服务调用及其失败行为；
- 最重要的领域规则和隐含约束；
- 最难修改、最容易产生回归的部分；
- 项目中存在的技术债、临时代码、Mock、硬编码和 Demo 实现。

对重要结论给出具体文件路径、函数、类或配置位置。

第三阶段：生产就绪审计

不能因为“本地能运行”就认为可以上线。逐项检查：

1. 功能完整性
   - 是否存在占位页面、TODO、Mock 数据、假接口、未实现分支；
   - 核心流程、异常流程和边界条件是否完整。

2. 安全性
   - 身份认证和权限绕过；
   - 输入校验、注入、XSS、CSRF、SSRF、路径穿越；
   - 密钥泄露、危险默认配置和日志中的敏感信息；
   - 依赖漏洞、上传安全、CORS、限流和滥用风险。

3. 数据可靠性
   - Schema、索引、约束和迁移；
   - 事务、并发、幂等、数据一致性；
   - 备份、恢复、数据保留和破坏性迁移风险。

4. 稳定性与性能
   - 超时、重试、熔断和资源释放；
   - 内存、连接池、N+1 查询和明显性能瓶颈；
   - 单点故障、水平扩展和优雅停机；
   - 高负载和第三方服务异常时的行为。

5. 可观测性与运维
   - 结构化日志、指标、Tracing、告警和审计日志；
   - 健康检查、就绪检查、运行手册和故障定位能力；
   - 发布、回滚、数据库迁移和灾难恢复流程。

6. 工程质量
   - 单元测试、集成测试、端到端测试及关键路径覆盖；
   - CI/CD、可重复构建、锁文件和运行时版本固定；
   - 配置校验、开发与生产环境隔离；
   - 文档是否与实际实现一致。

所有问题按以下等级分类：

- P0：可能造成安全事故、数据损坏、重大不可用，禁止上线；
- P1：高概率影响核心业务，上线前必须解决；
- P2：重要但可以在有明确控制措施的情况下延期；
- P3：一般优化或长期技术债。

每个问题必须包含：

- 证据和代码位置；
- 触发条件；
- 实际影响；
- 推荐修复；
- 验证方法；
- 是否阻塞上线。

第四阶段：实施生产化改造

完成调查后，制定按优先级排序的修复计划。

优先处理 P0、P1 和阻塞核心验证的问题。修改时：

- 尽量使用小而可审查的改动；
- 为缺陷补充回归测试；
- 不进行与目标无关的大规模重构；
- 如果必须重构，先解释必要性和风险；
- 更新受影响的配置、示例环境变量和文档；
- 不把真实密钥写入仓库；
- 每完成一组改动，就运行相关测试；
- 测试失败时查明根因，不要绕过。

如果某项修复需要外部账户、生产凭据、业务决策或真实基础设施，请完成代码侧能完成的部分，并明确列出剩余操作。

第五阶段：最终验证

在完成修复后，重新执行适用的：

- 依赖安装；
- 构建；
- 类型检查；
- Lint；
- 单元测试；
- 集成测试；
- 端到端测试；
- 数据库迁移验证；
- 启动和健康检查；
- 核心业务流程 Smoke Test；
- 安全和依赖检查；
- 项目适用的性能测试。

不要只报告命令名称，要报告：

- 实际执行的命令；
- 结果；
- 失败原因；
- 未执行项目及原因。

第六阶段：生成接管文档

在仓库中创建或更新 `docs/project-takeover/`，至少包含：

1. `01-system-overview.md`
   - 项目目标、架构、模块、技术栈和关键数据流。

2. `02-local-development.md`
   - 从零启动、环境变量、依赖、数据库和常用命令。

3. `03-core-flows.md`
   - 核心用户流程、代码入口和关键业务规则。

4. `04-production-readiness.md`
   - 审计结果、问题等级、已修复问题和剩余风险。

5. `05-deployment-runbook.md`
   - 部署前检查、发布步骤、迁移、Smoke Test 和回滚流程。

6. `06-operations-runbook.md`
   - 日志、监控、告警、常见故障和排障步骤。

7. `07-maintenance-guide.md`
   - 如何安全修改核心模块、测试策略和高风险区域。

8. `08-open-issues.md`
   - 尚未完成的事项、负责人条件、优先级和验收标准。

如果项目已有同类文档，应优先整合，避免重复和冲突。

最终交付时，请提供：

- 项目的一段式准确介绍；
- 架构和关键调用链；
- 如何本地运行、测试、部署和回滚；
- 已实施的修改；
- 实际验证结果；
- P0/P1/P2/P3 风险清单；
- 尚未验证的部分；
- 是否建议上线；
- 上线结论对应的证据；
- 上线前仍需人工完成的清单。

上线结论只能使用以下四种：

A. `GO`
已具备生产上线条件，关键路径已验证，没有未解决的 P0/P1。

B. `CONDITIONAL GO`
可以上线，但必须先完成明确列出的前置条件或采用明确的风险控制措施。

C. `NO-GO`
存在未解决的 P0/P1 或关键路径无法验证，不应上线。

D. `INSUFFICIENT EVIDENCE`
由于缺少环境、凭据、基础设施或业务信息，目前没有足够证据判断。

现在开始。先建立项目全景、运行基础检查并维护执行计划，然后持续推进。除非遇到必须由我决策的阻塞项，否则不要停留在“建议下一步”，而要实际完成可以安全完成的工作。

重复执行规则：

本提示词可能在同一个项目中被反复执行。

开始工作前，先检查：

- `docs/project-takeover/` 是否存在；
- 上一次审计的 Git commit、时间和结论；
- 当前 Git 状态；
- 上次审计后发生的代码、依赖、配置、数据库和基础设施变化；
- 上次遗留的 P0/P1/P2/P3 问题。

如果不存在有效的接管记录，执行完整首次接管流程。

如果已经完成过接管：

1. 不要无意义地从头重复全部分析；
2. 以上次审计基线为起点进行增量审计；
3. 优先检查变更影响范围和未完成问题；
4. 对安全、数据迁移、核心流程和发布链路进行必要的回归验证；
5. 重新运行与变更相关的构建、测试和检查；
6. 如果变更范围较大、基线不可确认或文档严重过期，自动升级为完整审计；
7. 更新已有文档，不创建内容重复的新文档；
8. 记录本次审计对应的 commit、变更范围、验证命令、结果和新结论；
9. 已解决问题标记为已关闭，但保留历史记录；
10. 每次都重新给出 `GO`、`CONDITIONAL GO`、`NO-GO` 或 `INSUFFICIENT EVIDENCE`，不得直接沿用旧结论。

旧的生产就绪结论只代表当时的代码和环境。代码、依赖、配置或基础设施发生变化后，必须重新验证才能继续有效。

只审计、不修改的用法

如果当前只想审计，把提示词中的“第四阶段”替换为：

本轮只进行只读审计，不修改任何文件。输出可执行的修复计划，等待我确认后再实施。