先给别人一个点进仓库的理由
一段好的互赞邀请，能让读者知道你做了什么、适合谁、怎么试，以及你想交流什么。下面的模板可用于整理 README 开头或项目分享文字，请替换成真实内容。
用四句话，把项目说清楚
- 一句用途：你做了什么，它解决哪个具体问题。
- 一句场景：谁会在什么情况下用到它。
- 一个入口：仓库地址，以及最短的安装或演示路径。
- 一个问题：这次最希望听到哪方面的反馈。
例如，文档工具可以说“把 Markdown 文件整理成带目录的静态站点”，再说明它适合维护项目文档的开发者。项目还没做完也可以交流，把可用功能和当前限制分开写即可。
模板一：开发工具或小应用
工具类项目先说省掉了哪一步工作，再给出一个别人可以马上尝试的任务。
我做了一个 [项目名称]，用来 [具体任务]。
之前处理这个问题时，需要 [原来的步骤]；现在可以 [新的操作方式]。
适合 [目标用户 / 使用场景]。
仓库：[公开仓库地址]
试用：[演示地址或快速开始的位置]
当前限制：[暂不支持的情况]
想请大家看看 [一个具体问题]，也欢迎交流类似工具的使用经验。如果写“更快”，最好附上你实际观察到的流程差异；没有测量数据时，描述少了哪些操作即可，不必填一个性能百分比。
模板二：组件库、SDK 或代码库
这类项目的读者通常会先看能否集成。把运行环境、最小代码示例和文档入口写在前面。
分享一个 [语言 / 框架] 的 [库名称]，主要处理 [具体需求]。
最小用法在 README 的 [章节名称]，可以从 [示例文件] 开始看。
需要 [运行版本 / 依赖条件]。
仓库：[公开仓库地址]
文档：[文档地址]
目前已支持：[真实的核心能力]
希望听听大家在 [集成场景 / API 设计 / 错误处理] 上的意见。“轻量”或“易集成”最好配一个能看懂的例子。对 API 还不稳定的早期项目，直接说明版本状态，方便读者判断是否适合试用。
模板三：学习项目或技术实验
学习项目可以从你的探索过程展开。说明尝试了什么、哪里卡住，比把实验描述成成熟产品更容易得到有用的建议。
最近在学习 [主题]，做了一个 [项目 / 实验]。
目前实现了 [已经完成的内容]，主要想理解 [具体技术问题]。
在 [文件或模块位置] 尝试了 [实现方式]。
仓库：[公开仓库地址]
运行方法：[README 对应章节]
还没想清楚的是 [一个问题]。如果你做过类似尝试，欢迎交流思路。引用教程、开源代码或数据时，保留相应来源和授权说明。读者能分清哪些是练习参考、哪些是你自己的实现，也更容易围绕具体内容讨论。
有人回应之后，怎么继续聊？
- 先回应具体问题：别人反馈安装失败时，问清环境和报错，再检查 README 是否漏了一步。
- 把重复问题补进文档：多个人都问同一个用途或限制，说明介绍还可以更清楚。
- 给改进留下记录：修复后说明改了哪里，链接到对应的 Issue 或提交，让参与讨论的人看到进展。
- 按社区规则参与：使用对方允许的项目分享入口，避免反复粘贴相同邀请。