readme-doc-writerlisted

## 何时使用 适用：用户要求新建或重写仓库的 `README.md`，例如「写 readme」「给这个项目写文档」「document this project」。目标是产出一份"过分详尽"的 README，让任何开发者几分钟内跑起来，并讲清系统如何运行、如何部署到生产。 一份合格 README 服务三个目的： 1. 本地开发——让陌生开发者在几分钟内把应用跑起来。 2. 理解系统——详尽解释应用如何工作。 3. 生产部署——覆盖部署与维护所需的一切。 不该用（负边界）： - 不是写 API 参考手册、教程长文、ADR/设计文档或营销文案——那些另起文件。 - 不替代真实环境的验证、测试或专家评审；README 只是说明，不保证命令在用户环境必然成功。 - 缺少必要输入（项目用途、部署凭据/URL、影响文档的业务背景）且无法从代码推断时，先停下来发问，不要臆造。 ## 步骤 ### 第 1 步：深度勘探代码库（动笔前必做） 写下任何一行文档前，先用 Read / Glob / Grep 摸清以下事实，不要凭框架默认值想当然： - 项目结构：根目录布局、语言/框架（看 `package.json` / `go.mod` / `requirements.txt` / `Cargo.toml` / `Gemfile` 等）、主入口、目录组织。 - 配置文件：`.env.example` / `.env.sample`、应用配置、凭据/密钥管理、`Dockerfile` / `docker-compose.yml`、CI/CD（`.github/workflows/` 等）、部署配置。 - 数据库：schema/迁移/种子数据、数据库类型与连接方式。 - 关键依赖：锁文件中的核心依赖，特别标注需要系统库的原生依赖（如 `pg`、`nokogiri`、`libpq`）。 - 脚本与命令：`bin/`、`scripts/`、Makefile、`package.json` 的 scripts、Procfile、Rake/任务定义。 ### 第 2 步：识别部署目标 按特征文件判定平台，针对性地写部署指引： | 特征文件 | 部署平台 | | --- | --- | | `Dockerfile` / `docker-compose.yml` | Docker | | `vercel.json` / `.vercel/` | Vercel | | `netlify.toml` | Netlify | | `fly.toml` | Fly.io | | `railway.json` / `railway.toml` | Railway | | `render.yaml` | Render | | `Procfile` | Heroku 及类 Heroku 平台 | | `serverless.yml` | Serverless Framework | | `*.tf` / `terraform/` | Terraform / IaC | | `k8s/` / `kubernetes/` | Kubernetes | 无任何部署配置时，给出通用指引，并推荐以 Docker 为默认方案。 ### 第 3 步：仅在关键处发问 只有当以下信息无法从代码确定时才问用户：项目到底做什么、具体部署凭据/URL、影响文档的业务背景。否则直接继续勘探并动笔。 ### 第 4 步：按固定骨架写 README 按顺序写以下小节，缺项可省但顺序勿乱： 1. 标题