手册:构建对话框

误区一：用错误的单位描述目的地

构建对话中最浪费的往返沟通，大多源于瞄准了错误的高度，而且方向截然相反。有些人要求的比自己想要的少——“改善一下设计”“做得更好点”“这感觉不太对”。这些说法都是诊断而没有目标，于是下一版就成了猜测：可能加深了页头颜色，可能换了字体，可能重新组织了导航栏，你要等看到结果才知道到底发生了什么，甚至看完还是不明白。另一些人则矫枉过正，要求的比该要求的更多——他们指名要用 session cookie，或 CSS grid，或某个加载骨架屏组件，因为他们懂一点，想帮上忙。这种失败更隐蔽，代价却同样高。一旦你指定了具体实现方式，你通常就已经指定错了，或者最多也只是把解决方案的范围收窄到你个人已知的那部分——除非你是专职开发者，否则这个范围通常比构建器自己会尝试的方案要窄。而且，如果你指名的库或模式恰好是错误的选择，那就成了你引入的 缺陷，而如果从结果出发去构建，构建器本不会犯这种错误。

解决办法介于这两种失败模式之间：说出你看到的现象和你想要的变化，而不是产生这个变化的具体机制。“访客应该能在不注册账号的情况下完成预订”比一整段关于 session cookie 的描述要好，因为你真正想要的是消除这个阻碍，而实现方式很可能有三种你根本没想到的路径。“价格表让人看不懂”本身还是太单薄——具体哪里让人看不懂？——但“用户看不出年付方案更省钱，把折扣信息放到价格旁边，而不是藏在小字里”就给了构建器一个具体的着力点。如果你自己也不知道该怎么改，那也没关系，说清楚哪里不对，让它来提出方案。真正行不通的，是没有任何锚点的模糊不满，因为那会让后面每一版都变成猜谜游戏。

误区二：对聊天里的总结做出反应，而不是对实际结果

第二种常见的失误，是针对聊天里对变更的文字总结做出回应，而不是针对实际改动本身。有人读到“把日程表挪到了单独的页面，并把页头颜色调深了”，脑中形成一幅画面，然后针对这幅想象出来的画面写反馈，而不是针对真实的网站。大多数“这里做错了”的抱怨，追根究底其实是“我还没打开预览”——结果其实没问题，或者接近没问题，真正的异议其实是针对一个假设。打字之前先点开看一眼，最多花三十秒，而跳过这一步，正是那些本不该发生的往返沟通里最大的成因。即使是在会议中用手机审阅，也先瞥一眼预览——针对“对描述的描述”给出的反馈，误差会迅速累积。

另一个相关的错误是把互不相关的需求捆绑到一条消息里，导致无法分辨到底是什么原因造成了什么结果。你完全可以在一条消息里叠加多个诉求并在一个新版本中全部实现——一次构建同时修复页头、调整日程排版、优化移动端导航，比拆成三次单独的差异更容易审阅，因为你评估的是网站的一个连贯状态，而不是三次相对不断变化目标的增量。问题出现在这些需求彼此无关的时候。把日程页的整体改版和全局配色改动捆在一起，如果结果有哪里感觉不对，你根本无法判断是哪个改动造成的——是新布局让页面难以阅读，还是新配色的问题？理清这一点需要再发一条消息，再走一整轮才能把变量隔离出来。把"关于日程页的所有内容"放在一条消息里，把"配色方向"放在下一条里——尽管没有什么阻止你把它们合并——这样每个版本都保持为一次清晰的对比，你可以撤回或调整需要处理的那一处，而不必因为某一部分没达到预期就丢弃一个整体不错的版本。

错误三：把每个版本都当作一次性的东西

第三个错误是忘记版本卡片不是一张收据，而是一个可用的工作对象，并因此错过它实际提供的能力。每一轮完成后生成的卡片都带有一个实时的预览——一个真正运行中的实例，而不是一张截图，因此点击其中的按钮会执行和生产环境中一样的动作。还有一个代码标签页可以浏览每个被改动的文件，如果你懂技术、想核实某个具体点（这个表单真的提交到了正确的接口吗？），这就很有用，不必等聊天回复来确认。下载可以获取原始文件。而操作菜单则是版本不再只是草稿的地方：将它发布上线、如果是应用则构建原生安装包、将它上架到应用商店、将整个项目另存为模板供以后构建使用，或者独立部署。

跳过这一切的人最终会靠回忆去判断旧版本里的按钮到底是不是蓝色的，而不是直接打开旧版本看一眼——因为把卡片当作一次性用品的后果正是如此：为一个只需点一下就能看到的东西去依赖记忆。版本4不会因为版本7上线就被归档或冻结。它的预览依然在运行，代码标签页依然可以浏览，操作菜单依然可用，永远如此。对比两个版本不是去读一份差异报告，而是把两个预览并排打开，逐一点击查看。卡片上还带有该次构建的验证记录——即自动化流程在把结果作为"完成"交给你之前，确认它确实可用的记录——该记录是针对这个具体版本的，这也是旧卡片保持可用如此重要的另一个原因：如果版本6验证通过而版本7没有，你可以把两者放在一起比对，而不必仅凭聊天里一句"修好了"就全盘相信。

同样那种"把工作流程当作可以略过而非真正使用的东西"的习惯，也体现在忽略每次构建后聊天提出的后续建议上。这些建议不是通用的填充内容，而是从这次构建本身提炼出来的，因此往往能捕捉到你自己一轮检查中可能遗漏的东西：一个没人设计过的空状态、一个提交后没有确认提示的表单、一个在桌面端正常但移动端拥挤的页面。采纳与否并非强制，但浏览一下这些建议不费什么功夫，如果你没有时间逐页点击检查，它们也是一种合理的替代性质量检查手段。