在PotatoChat提交产品评分时，先在应用或网页版定位到具体产品与版本，选择合适的星级与分类标签，然后用客观、按步骤排列的语言描述使用场景、详细复现流程与环境信息（设备型号、系统版本、网络类型等），列出实际结果与期望差异，附上截图或日志作为证据，填写联系方式并提交，记下工单号以便后续跟进与补充。
为什么要认真写产品评分？
很多人认为打个星、写两句就完了，但高质量的评分对产品改进、用户体验和社区健康都有实打实的价值。用费曼写作法想一想：如果你要把这个问题讲给完全不懂的人听，你会怎么说？把复杂的体验分解成简单的步骤、事实和因果关系，工程师、产品经理才能根据这些信息复现并解决问题。
评分对不同群体的价值
- 用户自己：更明确地表达问题，便于得到有针对性的回复和补丁。
- 产品团队：获得可复现的案例，加快定位与修复，提高产品稳定性。
- 其他用户：通过详实的评价判断产品是否适合自己的场景。
提交前的准备（四步法）
这部分按费曼法则把复杂准备工作拆成四个简单步骤，先做最容易的，再解决其他依赖。
步骤 1：确认产品与版本
- 在PotatoChat中打开目标产品页面，确认产品名称、子版本、发布时间或构建号（Build）。
- 若是多平台产品，标明你用的是iOS、Android、Windows、macOS还是网页版。
步骤 2：复现并记录环境信息
- 重现问题并记录每一步操作，不要省略看似“显然”的步骤。
- 记录设备型号、系统版本、网络类型（Wi-Fi/4G/5G）、是否登录、使用的语言区域等。
步骤 3：收集证据
- 截图：包含错误提示、异常界面或日志片段。
- 日志：如果能导出崩溃日志或控制台日志，优先附上（注意个人隐私）。
- 录屏：展示复现流程比纯文字更直观。
步骤 4：撰写文本（按模板）
把你的经历按“场景—操作—结果—期望—证据”这五部分写清楚，越结构化越好。
PotatoChat内的具体提交流程（通用版）
不同版本的PotatoChat界面可能略有差异，但核心字段和流程一致，下面是通用的操作路径。
- 打开App或网页版，进入目标产品详情页或“我的反馈/帮助”入口。
- 选择“提交评分/反馈”或“写评价”。
- 选择星级（通常1-5星）并勾选适用的分类标签（如：功能、性能、界面、文档、翻译/本地化等）。
- 在文本框中粘贴你准备好的内容（见下方模板）。
- 上传证据：截图、录屏、日志文件。
- 填写联系方式（邮箱/手机号/工单关联ID），确认是否公开或匿名。
- 提交后会返回一个工单号或反馈ID，记录并等待回复/跟进。
注意隐私与合规
- 不要在反馈中泄露敏感个人信息（如完整身份证号、支付信息等）。
- 如果需要上传含有个人信息的日志，先脱敏或与客服私下沟通传输方式。
高质量评分的写作模板（直接可复制）
下面给出几套模板，按情况选择并微调。记住越具体越有用。
1) 功能异常（必填字段）
场景：我在[使用场景，比如“发送实时消息”]时，执行[操作步骤1、步骤2]。
复现步骤：1) 打开App→2) 点击X→3) 输入Y→4) 点击发送。
环境：[设备型号]，[系统版本]，[网络类型]，[应用版本号/构建号]。
实际结果：[描述错误或异常，如“界面卡死，无响应，报错码XXX”]。
期望结果：[描述应该发生的情况]。
证据：附截图/录屏/日志。
联系方式：[便于联系的邮箱或工单ID]。
2) 体验建议（非必填，但有帮助）
场景：我在[场景]觉得[具体不便]。
建议：[比如“把按钮放在更显眼的位置”“增加默认关闭的提示”]。
理由：[为什么这样改会更好，预期提升是什么]。
替代方案：[如果有更好的实现思路可以写出来]。
好评与差评示例对比（写作风格示例）
| 高质量评分示例 | 低质量评分示例 |
| 场景、版本、复现步骤、实际/期望结果、截图/日志、联系方式都写清楚，说明复现频率“每次/偶发”，并建议优先级。 | “这个软件很差，老崩溃，别用。”（缺少任何可执行信息） |
评分语言与情绪控制（为什么重要）
写评分不是发泄渠道。情绪化的语言会让读者情绪性过滤你的信息，工程师更可能忽略挑衅式或侮辱性的内容。用事实、频率和影响范围来表达不满，能更快速得到响应。
- 不要写：“你们都不会做，这是垃圾”。
- 可以写：“在使用X功能时，遇到崩溃，频率约70%，影响付款流程，建议优先修复或临时提示用户避免某操作。”
后续跟进与最佳实践
提交评分后如何更有效跟进？做这几件事：
- 记录工单号或反馈ID，若有Ticket系统，通过ID跟进进度。
- 根据客服/开发要求补充日志或复现步骤，及时响应可以显著缩短解决时间。
- 当问题解决或有临时解决办法，回到原评分处更新状态或追加评论，标记“已解决”或“仍存在”。
- 如果你的反馈影响较大，考虑在社区或论坛留下复盘，帮助其他用户避免相同问题（注意不要泄露敏感信息）。
常见误区与如何避免
- 误区：只写“崩溃”而不写复现步骤。
避免方法：写出每一步具体操作，并说明是否可复现。 - 误区：上传一堆大量未做注释的日志。
避免方法：在日志旁写一两句指出可能相关的时间戳或关键错误行。 - 误区：把产品建议写成个人偏好（“我觉得按钮颜色不太好”）。
避免方法：说明为什么影响使用（可访问性、误触率等），最好有具体数据或场景。
如何让评分更符合“信息完整度≥95%”标准（按百度质量白皮书的思路）
信息完整度不是堆字数，而是结构化与事实化。把你的输入分为：基本信息、操作流程、环境信息、复现频率、证据与期望结果。这六项齐全，往往已经超过95%的信息完整度。
复核清单（提交前逐项核对）
| 是否标明产品与版本 | 是/否 |
| 是否写清复现步骤并可被他人按顺序重复 | 是/否 |
| 是否包含环境信息（设备/系统/网络） | 是/否 |
| 是否附上证据（截图/日志/录屏） | 是/否 |
| 是否说明实际结果与期望结果的差异 | 是/否 |
| 是否提供联系方式并保存工单号 | 是/否 |
实战小技巧（提高问题解决速度）
- 在标题中加入关键字：把核心问题用一句话写在标题里，比如“iOS 14 – 聊天界面发送图片崩溃（100%重现）”。
- 标明优先级：影响到付款/登录等核心流程的可以注明“P1 / 紧急”，便于客服优先处理。
- 分批次提交：如果同时发现多个不相关的Bug，分开提交，便于指派给不同小组。
- 保留旧版回滚信息：如果问题出现在新版本，写明老版本是否正常，这有助于判断回归。
写到这里，不妨现在就去把你最近遇到的那个小问题按模板整理一遍——你会发现，把一件复杂的体验拆成几个事实后，解决它比想象中容易得多。