产品需求里的按钮之争，先让 AI 画 3 个能点的版本

同一个产品需求，放在聊天框里通常会变成一场很熟悉的拉扯。

「升级按钮要放右上角吗？」

「我觉得固定在底部更安全。」

「如果用户先看到上下文，会不会根本不需要那么多字段？」

三个人都没错，问题是这几句话里没有任何一个东西能点。你只能拿着脑内想象的界面，去猜另一个人脑内想象的界面。聊到后面，大家开始讨论按钮颜色、文案和圆角，真正没解决的其实是信息该先出现，还是操作该先发生。

我这次拿了一条完整的演示需求来试 Matt Pocock 的 prototype Skill。不是做登录页，也不是换三套配色。需求是，在客服的既有工单页里升级一条支付故障，客服必须不跳页地带上用户影响、复现路径和 on-call 接手人。

它要回答的不是「这个页面漂不漂亮」，而是「这件事该怎样被看见和完成」。

官方的 UI 分支给得很直接。默认做 3 个结构差异足够大的方案，用 ?variant= 保持同一路径切换，再放一条悬浮底栏。它还特别提醒，不能把三张卡片换个颜色就叫三个方案。这个约束很重要，AI 最擅长把同一个想法润色三遍，人最容易误以为自己比较了三个选择。

想自己试，官方仓库给 Codex 的接入方式是下面两行。

codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocock

接着别只说「帮我做个好看的页面」。把原型到底要回答什么写窄一点，例如「为当前工单页做 3 种升级交互方案，用 ?variant= 切换，比较处理速度、影响判断和上下文连续性」。AI 才有机会把分歧画成不同结构，而不是给你三张换底色的海报。

我没有把它接进生产项目，而是做成了一份明确标注为 PROTOTYPE 的单页。无持久化，不接真实通知，数据全是演示数据。浏览器里切到每个方案，当前方案、优先级、接手人和影响判断都会直接显示出来。它是一份拿来问问题的代码，不是一条准备上线的功能。

同一条需求，三种完全不同的主张

第一个版本是「右侧工作台」。左边保留客户消息和告警，右边是一块始终在场的升级表单。它的主张很朴素，客服已经知道要升级时，不要再带他去走流程，给他一块能一次填完和提交的地方。

方案 A。按钮在表单最末端，适合高频、熟练的处理者。

这个版本很像多数团队第一反应会画出来的页面。它也不差，甚至对熟手很顺。可点开之后才能意识到一个问题，优先级、影响范围和复现都压进了同一块编辑区。新人可能会把「影响 18 个会话」当成一条普通备注，然后很自信地点下「升级并通知 On-call」。

第二个版本故意反过来，把按钮往后推。页面先问「这次故障正在伤到谁」，让人从四种影响范围里选一个。选完后，右侧才把会发出去的内容汇总出来，然后才开放确认。

方案 B。按钮不是被藏起来，而是被放到判断完成之后。

这版最有意思的地方，不是绿色进度条，而是它把团队真正担心的事暴露出来了。大家并不是在争按钮离手指多远，大家是在争「客服有没有在按按钮前做出影响判断」。一旦这句话被写出来，讨论立刻从审美变成产品规则。要不要把 P1 建议自动带出，少量会话失败能不能不升级，都是可以继续落在页面上的问题。

第三个版本又换了一个假设。也许这个团队的客服并不缺提交入口，缺的是在升级前看完整时间线。于是我保留事件流，让失败、用户反馈和告警按发生顺序摆在眼前，再把升级操作做成时间线末端的接管卡片。

方案 C。按钮紧挨证据，适合上下文比录入速度更重要的处理场景。

你会发现，三个版本里按钮的位置都说得通。

方案 A 把它放在表单底部，因为假设用户已经判断完成。方案 B 把它放在影响判断之后，因为假设错误升级的代价更高。方案 C 把它放在时间线末端，因为假设交接质量取决于上下文连续性。

这就是可点原型比聊天框更快的原因。聊天框里的「放右边」没有前提。界面上的「放右边」连同它前面的信息、它禁用和可用的时机、它会带走哪些内容，一起摊在了桌面上。

真正省掉的，是抽象词来回翻译

产品讨论很容易掉进一种假忙。有人说「操作要更直接」，设计师理解成减少字段，工程师理解成减少一次请求，客服理解成不用跳页。四个人都在认真，但四个人说的可能不是同一个「直接」。

有了三个可切换版本，反馈会自然变得具体。

你不会再说「我觉得 B 不够直接」。你会说「我想要 B 的影响判断，但接手人仍然留在 A 的右栏」。

你也不会泛泛地说「C 信息太多」。你会指出「时间线保留，升级卡片得避开临近的告警节点」。

这种反馈可以直接变成下一轮实现的输入。它少了一层把中文形容词重新翻译成布局的损耗。AI 的速度在这里不是它帮你猜对按钮位置，而是它把三个可反驳的假设放在同一个页面里，让人快速淘汰两个。

prototype Skill 的一个小细节也很实用。切换器会更新 URL 参数，所以每个版本都有稳定链接。开会时不需要靠「刚才那个蓝色的」来定位，发 ?variant=B 就是同一个画面。它还要求方案切换时把相关状态露出来。我在页面顶部保留了当前方案、优先级、接手人和影响判断。这个小小的状态框有点像调试日志，丑一点没关系，它能阻止大家在讨论 UI 时悄悄讨论成了两套业务规则。

这套方法不替你做决定

这里有个边界得先说清。三个方案不是用户研究，更不是投票器。它只能把假设做成可感受的东西。

这次原型我还用浏览器脚本验证了三件事，A、B、C 能通过底栏和左右方向键切换，?variant= 会跟着变化，C 的升级操作只显示演示反馈，不会发真实通知。它证明的是原型可运行，不是某个布局已经被用户证明更好。

真正要定版时，仍然得回到现场。客服处理 P1 的频率有多高，误升级要谁收拾，on-call 最缺的是结构化字段还是上下文，才是 A、B、C 该由谁胜出的依据。prototype 的规则也把这件事说得很克制，选出赢家后，把决定折回正式代码，其他版本和切换器留在一次性的分支里，不要把它们当生产组件养下去。

但在定版之前，我很愿意先花十分钟让 AI 把三个能点的版本摆出来。比起在聊天框里为一个不存在的按钮辩论半小时，这种浪费要便宜得多。

如果是你来选，这条工单升级流程更该优先保护处理速度，影响判断，还是上下文连续性？