readme-generatorlisted

# GitHub README Generator README 是项目的第一张作品集页面。它不是说明书的目录，也不是功能清单的容器。它要在很短时间内回答三件事： 1. 这是什么。 2. 为什么值得看。 3. 我怎么开始使用。 本 Skill 的目标是生成 **100 分 README 作品**：清楚、有审美、克制、可信，能让项目像一个完整作品一样被理解。 --- ## 第一性原理 README 是信任入口和路径入口，不是完整文档。它应该帮助第一次打开仓库的人做出快速判断： 1. 这个项目解决什么问题。 2. 它适不适合我。 3. 我是否能马上运行、安装或继续了解。 1w star 以上开源项目通常不是靠信息量取胜，而是靠清晰的首屏、直接的上手路径、可信的文档入口和克制的社区信息取胜。图片、徽章、作者信息和设计理念都只是辅助；一旦它们拖慢理解，就是噪音。 本 Skill 的核心取舍：README 先讲清项目，再做美化；视觉服务理解，不替代理解。 --- ## 作品标准 用下面的评分表约束所有输出： | 维度 | 分值 | 判断标准 | |------|------|----------| | 15 秒理解 | 25 | 首屏能看懂项目名、价值、适用对象 | | 项目故事 | 20 | 不是堆功能，而是讲清背景、动机和结果 | | 视觉表达 | 20 | 图片像作品，不像小字流程截图 | | 快速开始 | 15 | 安装和使用路径短、明确、可复制 | | 可信产物 | 10 | 展示真实输出、能力边界或结果 | | 克制降噪 | 10 | 去掉重复、口号、过度解释和装饰 | 低于 90 分的 README 不交付；先删噪音、放大重点、重排叙事。 ### 高星项目基线 默认向高星开源项目学习这些结构： - 项目名 + 一句话价值主张。 - 少量必要 badge，不堆状态装饰。 - 快速开始或文档入口靠前。 - 示例只在能降低上手成本时出现。 - 贡献、社区、安全、许可证简洁清楚。 - UI / 产品项目可放截图；库、SDK、基础设施项目少图或无图。 不要把 README 写成设计宣言、完整说明书、功能墙、社交名片或内部工作流报告。 --- ## 设计原则 ### 必须坚持 - H1 必须是项目正式名称，紧跟一句价值主张。 - README 开头先讲项目价值，再放安装细节。 - 图片只表达一个重点，但应该承担项目名片功能：让读者一眼看到项目名和定位。 - 默认最多两张图片：一张封面，一张核心能力或结果图。 - GitHub 会缩小图片显示，图片里的主文案必须按海报字号设计。 - 对功能的描述要具体，但不夸张；能用结果说明就不要自夸。 - 对作者和许可证保持简洁，不做社交名片堆砌。 ### 必须避免 - ASCII 艺术标题。 - emoji 装饰标题或作者表格。 - 大段“我们很专业”的空话。 - 6 个以上小卡片堆在一张图里。 - 流程图里塞满阶段、命令和小字说明。 - 把第三张流程图当作默认产物；工作方式通常用正文讲更清楚。 - 把 Image Gen 当作长文排版工具。 - 把 README 写成完整产品手册；详细文档应放到 `docs/`。 --- ## 总体流程 ``` Phase 0 项目阅读和模式识别 Phase 1 项目故事提炼 Phase 2 视觉生成方式选择 Phase 3 作品级视觉资产生成 Phase 4 README 组装 Phase 5