我付钱让人按我的 README 操作
花钱请人像照着脚本一样去执行项目的 README，能暴露出开发者文档里潜藏的多少假设、遗漏和干扰。评论者认为，README 应当清楚说明软件做什么、列出前置条件，并提供一条最简的端到端上手路径；同时，很多人批评表情符号堆砌、内部笑话，以及掺入 AI 生成的“垃圾内容”会掩盖关键信息。也有人指出，这种真实用户测试很像 UX 可用性实践，并且能补充自动化检查或基于 LLM 的审阅，但后者仍然无法像人类那样判断清晰度、乏味感或困惑程度。
对“付钱让人按我的 README 操作”的总体反应
- 许多人认为，这只是把标准可用性测试应用到技术文档上。
- 不少人赞赏这个想法，并表示类似的内部做法（用 README 让新员工上手、记录摩擦点）能很快发现很多问题。
- 也有人认为，只要在一台干净的机器上严格照着自己的说明做，通常自己就能发现大多数问题。
细节程度与前置条件
- 很多人强烈认为，README 经常遗漏关键的“第一步之前的步骤”（例如安装 php-fpm、运行时或工具）。
- 普遍共识是：即使你不逐一解释每个依赖如何安装，一个清晰的“前置条件”部分也很重要。
- 关于要追溯到多前面存在争论：有人希望从
git clone开始就给出命令；也有人指出，你不可能把所有操作系统/包管理器都列一遍。
风格：简洁、结构，以及软件到底做什么
- 常见抱怨是：很多 README 从头到尾都没清楚说明项目是做什么的，只是在讲怎么安装，或者堆砌流行词。
- 许多人更喜欢简短、以任务为导向的 README，把它当作进入更丰富文档的入口，而不是长篇“小说”或 FAQ。
- 像 Diataxis 这样的框架，以及教程 vs. 参考文档的区分，被认为有助于组织文档结构。
语气：表情符号、笑话和个性
- 过度使用表情符号普遍不受欢迎；很多人会把表情符号很多的 README 与 LLM 生成内容或幼稚风格联系起来。
- 对一些人来说，只要不妨碍理解，轻度幽默是可以接受的；但另一些人认为，笑话和文化特定引用会让人困惑，不值得承担这个风险。
- 不少人指出，作者觉得好笑的东西，读者往往并不买账。
人类 vs. AI/智能体在文档测试中的作用
- 有些人认为 LLM 和智能体擅长：
- 在沙盒环境中按步骤执行指令。
- 发现缺失步骤和不一致之处。
- 但人类仍被视为必不可少，因为他们能：
- 判断枯燥程度、清晰度和整体体验。
- 揭示隐含假设、令人困惑的措辞，以及文化/知识鸿沟。
安装摩擦与自动化
- 很多人抱怨项目即使有 README 也“就是跑不起来”。
- 容器化（Docker）和环境工具（Nix、direnv）因其可复现、低摩擦的配置方式而受到称赞。
- 也有人认为，真正打磨好的软件应该自动化安装配置，而不是过度依赖手写 README。