py2rs-review-r6-ergonomics

name	py2rs-review-r6-ergonomics
description	[DRAFT] 第 6 轮审查：产品与人体工学。从用户视角审视批处理、缓存、国际化、自动恢复、UI/CLI 体验。只审查和分析，不写代码，输出报告给用户。

第 6 轮 · 产品与人体工学审查（R6）

DRAFT（草稿状态）。这一轮本质上不是“代码审查”，而是“产品 + UX 评审”。它的产物主要是一份 markdown 报告，以及几个可以被排入下一个迭代的建议。

脚手架猜想（可能会有）

• reviews/r6-<module>-ergonomics.md 报告模板 —— 固定栏目：现状摘要 / 建议清单（按影响×成本排序）/ 与前几轮联动 / 结论
• reviews/r6-<module>-todo.md —— 拆成若干可执行小任务，每一条都能单独做一个小 PR
• （可选）一个 scripts/ux_audit.py —— 扫描 CLI 的 --help、日志格式、错误信息可读性，输出一份清单式建议
• （可选）一个 docs/ergonomics.md —— 把多轮 R6 的观察沉淀成项目级的 UX 设计指南

这一轮最容易被做成“拍脑袋建议”，所以报告里的建议必须能被 R0~R5 的流水线在下一轮迁移时验证——否则就只是意见。

---

本 skill 与前 5 轮性质完全不同：不写代码、不改实现。 它从“最终用户”角度审视整个系统，把改进方向作为建议回传给产品负责人 / 架构决策。 身份更像“Staff Engineer + 产品经理”的联合评审。

0. 前置检查

• 存在 reviews/r0-<module>-signature.md ~ reviews/r5-<module>.md 全部齐全
• manifest/modules.yaml 中目标模块状态 ≥ verified

未满足则拒绝启动。

1. 本轮审查的维度

1.1 批处理与任务队列

• 现在需要用户“手动一次次调用”的操作，是否能变成批处理？
• 批量场景下是否有进度条、失败可重试、失败行可导出？
• 批量失败后，是否能从断点继续，还是必须从头再来？

1.2 缓存与增量更新

• 有没有明显“每次启动都重新扫描/重新下载/重新计算”的操作？
• 缓存失效策略是否合理？
• 用户是否能“清缓存并强制重新生成”？

1.3 错误与自动恢复

• 外部调用（网络 / DB）失败是否有自动重试与退避？
• 程序崩溃后，再次启动能否恢复到之前的状态？
• 日志里的错误信息是否能让用户自己定位问题，还是必须读源码？

1.4 国际化（i18n）与输出

• 错误消息 / 日志 / UI 文案是否硬编码为单一语言？
• 是否存在非 ASCII 文件名 / 内容被乱码处理的隐患？

1.5 主题 / 配置 / 默认值

• CLI：默认参数是否合理？是否有 --help / --version？
• 日志：默认日志级别的信息量是否合适？
• 配置文件：缺失配置时是否给出清晰的“我该怎么配”的提示？

1.6 性能体感（区别于 R4 的“算法性能”）

• 用户等待最久的操作是哪一步？
• 是否存在“UI/CLI 被卡住”的瞬间（主线程同步 IO）？
• 能否用 R3 引入的 async 能力在 R6 阶段改善体验？

2. 输出格式（严格 markdown，不写代码）

reviews/r6-<module>-ergonomics.md，结构固定如下：

# R6 人体工学审查 —— <module>

## 现状摘要
3~5 条，描述当前用户体验最痛的点。

## 建议清单（按影响 / 成本排序）
1. <建议 A>
   - 影响：高 / 中 / 低
   - 预估成本：大 / 中 / 小
   - 理由：...
2. <建议 B>
   ...

## 与其他轮次的联动
- 哪些建议其实是 R3（IO 并发）应该已经解决的？
- 哪些建议需要回 R5（架构）调整数据结构？
- 哪些建议其实是产品需求，应由产品负责人决定？

## 本轮结论
当前在“功能层面”已经可以交付；
在“体验层面”有如下 3 个最高优先级建议...

3. 允许与禁止

• ✅ 允许：读代码、读日志、读 manifest、读 reviews/r0-r5、分析、给出建议
• ❌ 绝对禁止：本 skill 直接修改任何生产代码
• ❌ 禁止：以“体验更好”为由推翻 R0 已验证的语义

4. 结束后如何推进

• 本 skill 的输出是一份决策输入，不是代码改动
• 用户 / 产品负责人决定哪些建议进入下一个迭代
• 真正落到代码时，由 Writer / Architect 分别负责，但必须走 R0→R1→…→R6 的同一条流水线（即把“要改的那一块”当作新一轮迁移）

5. 完成后 manifest 状态

• 不强制推进到 optimized（因为可能只是建议，不写代码）
• 只在 manifest/modules.yaml 中写入一条：

  reviewed_at: "..."
  review_rounds: ["r0","r1","r2","r3","r4","r5","r6"]
  

  表示该模块已走完完整 7 轮审查管线