我记得有一次，页面刚跑起来的时候，人最容易松一口气。左边是导航，右边有表格，有按钮，有弹窗，颜色也搭上了，看着已经像个能交差的产品。可鼠标真点下去，问题就开始冒头了：没有数据时显示什么，按钮点完是停在原页还是跳转，弹窗关掉后用户还找不找得到刚才那条记录。那一刻我才更愿意承认，Codex 真正厉害的地方，不是把空白页变成第一版，而是它逼着人面对一个更现实的问题：你到底知不知道这个原型要拿来干什么。
很多人一开始会把注意力放在“它能不能直接生成一个页面”。这个想法不奇怪，因为从零开始最难受的，就是面对空白。Codex 在这件事上确实很能打，一句话目标、一个大概场景、几个页面名称，它就能很快给出一版能看的东西。问题也恰好出在这里：第一版太快了，快到人会误以为难点已经过去。其实真正卡人的，不是“写不写得出来”，而是“接下来怎么判断这版是不是朝对的方向走”。
我后来发现，围着这个词搜索的人，表面上像是在问“怎么生成”，其实更像是在问“为什么我已经有页面了，还是觉得不对劲”。这个感觉很真实。原型看起来像房子的样板间，灯光很好，沙发摆得也顺，可你真住进去才知道，门顺不顺手，水通不通，插座够不够。这也是我理解 Codex 做原型最合适的角度：它不是替你把产品想完，而是先把样板间搭出来，让你有地方去检查那些原来只停在脑子里的想法。
难点不在“生成”，而在“你拿什么验”
很多人卡住，不是不会提需求，而是提完以后没有验收尺子。你让 Codex 做一个“后台管理系统”，它当然能给你菜单、列表、筛选框、详情页，甚至还能配上看起来挺专业的图标和间距。但这类页面的问题，常常不是首屏难看，而是路径不通。比如一个运营人员到底是先搜用户，再看详情，再改状态，还是先看异常列表，再批量处理？如果这个路径你自己都没想清楚，工具写得越快，后面返工越快。
这也是为什么我现在看原型，不太会盯着截图问“像不像”。我会连续追问几件事：这个页面是谁来用，他进来第一眼要找到什么，他做完一件事以后下一步去哪，出错时会不会慌。你会发现，真正能拉开差距的，不是按钮圆角，也不是渐变背景，而是这些很朴素的问题。看起来是在验 UI，其实是在验业务理解。不是在看“有没有页面”，而是在看“这个页面能不能接住一个真实的人”。
漂亮只是开始，状态才是原型的骨架
有个判断挺准：页面好看只是开始，交互状态和空数据才更容易漏。这个用法很实在，因为它一下子把注意力从“展示层”拽回到“使用层”。很多第一版原型像橱窗，默认一切顺利：有数据、有权限、网络正常、用户知道自己要做什么。可真实场景不是这样。用户可能什么都没搜到，可能填错了内容，可能刚点保存就断开，可能这条记录已经被别人改过。
所以我会把“状态”当成原型有没有站住的判断标准。一个页面至少得想清楚几种状态：正常时长什么样，空的时候怎么办，加载时用户看见什么，报错时给不给退路。这听起来像细节，其实不是。它更像人体的骨架，不显眼，但没有它，外面那层皮就只是摆设。如果你是第一次用 Codex 做 Web 原型，很容易被第一版的完整感骗到，以为“有了”。可很多时候只是“像有了”。看起来是一个产品，其实更接近一张布景板。
我见过一种很常见的误差：人把“能点开弹窗”当成“交互完成了”。其实弹窗打开只是开头，里面填错怎么办，提交后列表刷不刷新，关闭后用户会不会丢失刚才的位置，这些才是交互真的落地。Codex 可以帮你补结构、补组件、补页面，但哪种状态是关键状态，还得人来挑。说直接一点，工具负责把门窗装上，人负责判断这扇门是不是开在该开的地方。
我会把原型拆成五轮，不跟第一版较劲
我现在更愿意把原型当成五轮往前推，而不是一口气求成。这个思路帮我省下来的，不只是时间，还有判断力。因为你一旦把目标拆开，就不会被“这一版怎么还不完美”拖住。
第一轮其实很轻，只要一句话目标。不是“大概做个教育平台”，而是“让班主任在三分钟内找到某个学生最近一周的异常情况”。这两句话看起来差不多，后者却直接决定页面重心。第二轮才去搭骨架，首页、列表、详情、操作入口这些地方先站住。第三轮我会盯关键状态，把刚才说的空白、报错、加载、禁用这些情况一一补上。到这一步，原型才开始像一个能被试用的东西。
再往后，真数据测试就很关键了。这里的“真数据”不一定是真实线上数据，而是接近现实的数据长度、字段脏乱程度、异常值。很多原型一上假数据就显得很好看，名字都差不多长，数字都整整齐齐，列表也刚好排满。换成真实业务后，超长标题、缺失字段、重复状态一下子就把版面打乱了。你会发现，问题不是 Codex 不会写，而是你给它的世界太干净了。
收尾那一轮才是细节打磨。我会把这轮放到路径跑通之后，不是因为细节不重要，而是因为太早磨细节，很容易在错误方向上越磨越亮。字体、留白、按钮层级这些都该改，但前提是路径已经通了。真正省时间的方式，是让工具做能检查的小事，人负责判断要不要继续。这句话听着普通，用起来却很稳，因为它把人和工具的边界分清了。
别只盯着截图好不好看，要沿着人走一遍
我越来越觉得，判断一个 Web 原型靠不靠谱，最朴素的方法就是沿着用户路径点一遍。不是站在设计稿外面看，而是假装自己就是那个会用它的人。你从哪里进入，要查什么，改什么，提交后想确认什么，做错了还能不能回来。这个过程像走迷宫，走通了，原型才算真的通；中间哪怕只堵一处，用户也会停下来。
这张图里的比喻我很认同。原型像样板间，不是说它虚，而是提醒人别被表面骗了。样板间吸引人的，是一眼看上去舒服；真正决定能不能住下来的，是那些平时不太会主动展示的部分。Web 原型也是这样。首屏颜值有用，但它更像把人请进门；能不能留下来，要看门后的流程是不是顺，功能之间有没有断层，状态切换是不是让人心里有底。
说到底，Codex 从零做 Web 原型这件事，难点不在“它会不会生成第一版”。今天这个问题基本已经不是门槛了。更大的门槛，是人能不能在第一版出来以后，不急着把它当成果，而是把它当成一个可检查的起点。你越早这样看，越不容易掉进“明明改了很多，结果还是像模板”的坑里。
我现在看这类原型，脑子里会留一个很简单的判断：它是不是正在更接近真实业务，而不是更接近一张漂亮截图。前者需要页面状态、用户路径、数据现实感一起往前走；后者只需要首屏像样。两条路开头有点像，走几步就完全不同。真正难的，也正是在这里。
暂无评论内容