一条云声建议从复现到被采纳：把「点了没反应」写成可复现的工单

前两天我在华为云云声提了一条产品缺陷，标题是「云实验台『打开控制台』按钮点击无响应，无法进入实验环境」。两天后收到结果：预审通过，状态变成已采纳。整个过程没有技巧，只有几个笨办法，记下来给同样想提建议的人参考。

一、先确认这不是自己浏览器的问题

按钮点了没反应，第一反应往往是网络或者缓存。我的做法是把它做成可复现的事实：换一次无痕窗口、换一个浏览器内核、清一次缓存，再点同一处。三次都无反应，才敢说这是产品侧的问题，而不是我这边环境脏了。

复现的时候把能定位的信息都记下来：出现在哪个实验（实验名称和实验 ID）、实验台页面的标识串、当时的进度百分比和剩余时间、操作顺序是先点哪个再点哪个。这些东西写进去，别人接手时不用再问一遍。

二、标题写「模块 + 动作 + 结果」

标题里不要出现「严重」「紧急」「请尽快」这类词，它们不提供信息。有用的结构是：哪个模块、做了什么动作、出现了什么结果。比如「云实验台『打开控制台』按钮点击无响应，无法进入实验环境」，读完就知道是谁的哪个按钮、点了会怎样、后果是不能进环境。标题控制在六十多个字符以内，太长了列表里会被截断。。

三、正文按五段写，不要写成情绪日记

我的正文是这样组织的：

第一段写场景，说清楚在做什么任务、从哪个入口进来的。第二段写复现步骤，一步一步，编号，让别人能照着走一遍。第三段写期望结果——正常情况下点这个按钮应该发生什么。第四段写实际结果，包括按钮有没有任何反馈、控制台有没有报错、页面有没有跳转。第五段写影响和建议，说明这个缺陷挡住了什么，以及你希望怎么改。

这五段加起来三百多字就够了。关键是「期望」和「实际」要分开写，评审的人一眼能看出差距在哪。感受性描述（很难受、影响效率）可以留一句，多了反而稀释重点。

四、先搜再提，一条只写一个缺陷

提之前我在列表里搜过关键词，确认没人提过同样的问题。这一步能省掉被合并或者被驳回的时间。另外，一条建议只写一个缺陷：把三个问题揉在一起，评审时只能整体打回，谁也不知道该先修哪个。

还有一点容易被忽略：建议默认是公开的，提交时会提示内容将被公开。如果里面含账号、内网地址、业务数据，提交前先脱敏，只保留定位问题必需的标识。

五、结果与回头看

这次从提交到被采纳用了两天，中间只经历了一次预审。回头看，起作用的大概不是文笔，而是那三样东西：可复现的操作路径、可定位的环境标识、可执行的修复建议。缺陷报告本质上是给别人一份能复现的工单，把复现成本和定位成本降到最低，它就有更大概率被接住。

顺带说一句，这条建议被采纳后，成长中心给了 60 积分。但别为了积分去凑，凑出来的建议评审一眼就能看出来，既浪费时间也占别人带宽。真遇到问题，按上面的写法提，通常不会石沉大海。