readme-writinglisted

# README / 用户指南写作 ## 何时用 - 新项目的第一版 README / 用户指南 - 旧文档乱、读者看不懂、需从开发者笔记改成用户文档 - 软件改了 UI / 流程 / 报错 / 数字后回来同步（见「同步」） ## 总则（写每一段前对照） 1. 读者是聪明但无技术背景的人——只需要「点哪里、做完看到什么」。 2. 结论先行——标题、段首给结论，解释放后。 3. 可扫读——读者多数只扫标题与列表；段落短、一段一主题。 4. 精炼——只留必要内容；要求文档做到的，本文先做到。 5. 措辞统一——同一对象 / 按钮 / 概念全文同名同写法，不换说法。 6. 可兑现——承诺（隐私、许可、功能）必须真实；AI / 自动判断附一句免责。 ## 动笔前：读者画像 - 读者是谁、技术水平如何（会装软件？看报错？用命令行？） - 他最可能卡在哪：前置条件不满足 / 配图对不上 / 概念没解释 - 本文是「一次配置说明」还是「日常使用手册」——多数工具两者都要，分开写 开头一句话定位（+ 免责）： > 帮〔谁〕把〔输入〕做成〔交付物〕的〔桌面工具 / 网页 / 命令行〕。 ## 章节骨架（最终用户工具，按需增删） | # | 章节 | 写什么 | 要点 | |---|---|---|---| | 1 | 定位 | 帮谁、做什么、产出到哪 | 一段 + 免责（如有） | | 2 | 功能 | 2–5 条动宾短语 | 每条一句；有模式差异配对比表 | | 3 | 使用前提 | 硬性前置 | 一次列全，别藏进步骤中间 | | 4 | 安装 | 下载渠道 + 文件形态 | 文件名写全、能对上号；写明推荐哪种 | | 5 | 快速开始 | 一次性设置流程 | 小节标题用「第 N 步：一句动作」；每步 = 目标 → 做法 → 成功标志 → 配图放验证点 | | 6 | ⚠️ 注意事项 | 不照做必翻车的坑 | 独立编号；先命令式结论，再讲原因与正确做法 | | 7 | 日常使用 | 会用之后 | 概念、状态、常见操作；档位 / 等级用表格 | | 8 | 常见问题 FAQ | 报错与失败场景 | 标题用读者问法（原话问句或一句话主题）；答案 ≤3 句 / 条，最常见原因排前 | | 9 | 隐私与数据 | 打消疑虑 | 句句可兑现：不登账号、数据存本地、请求发往哪 | | 10 | 致谢 | 可选 | 一句话 | | 11 | 使用许可 | 条款 | 允许 / 署名 / 商用 / 再分发；附完整协议链接 | | 12 | 给开发者的话 | 可选，放最后 | 技术栈 / 模块 / 命令，普通读者读不到 | **变体**：CLI——把「安装 + 一条命令」提为快速开始，功能改命令表，少配图；库 / API——首页先给最小可运行示例，「成功标志」＝应得到的输出；英文——规则照用，换英文引号与美式标点，章节头用名词短语。 ## 行文 - **界面文案引用**：读者要找的字原样抄进「」并写明位置（点「保存设置」→ 绿字「设置已保存」）。 - **报错进 FAQ**：正文不堆报错原文；答案写「一句该怎么做 + 可选排查分支」。 - **术语就地解释**：首次出现给一句人话，不留到文末术语表。 - **符号**：中英文间留空格（纯中文专名除外）；夹中文的英文标点改中文标点；数值范围用全角「～」（防 Markdown 删除线）。 - **数字与软件实际一致**（档位、份数、速度）。 - **emoji 克制**：只在与真实状态一一对应时用（🟢🟡🔴 ↔ 连接状