AI 软件开发实战课（六）：让 AI 输出页面草稿，但保留人为判断权

“AI 软件开发实战”系列第六期：借助 UI/UX Skill 输出设计语言与界面建议，再结合真实使用场景、产品边界与无障碍要求逐条筛选，防止把首版好看方案直接当作最终答案。

上一篇搭好工程架构后，邻行已经清楚系统如何存数据、处理并发、推送提醒以及保护隐私信息。

下一步要回答的是：用户真正看到什么、先做什么，以及怎样确认自己没理解偏。

本环节调用的是 ui-ux-pro-max。它能从本地设计资料中检索产品形态、风格、色彩、字体、触控、表单、导航与无障碍要点，也能产出一整套设计语言。

乍一听好像只要把需求丢给 Skill，等它吐出页面就行。

但跑出来的第一版结果是这样的：

这套方案并不丑。

只是它不属于邻行。

邻行包含“社区”和“车找人、人找车”字段，设计检索自然会拉到社区论坛、会员社区与网约车。

可邻行并不是这些产品：

若仅凭关键词相似度挑选设计，很容易把产品根本没做出来的能力也画进页面。

比如一张大地图会让人顺理成章期待实时位置与路径规划；一个特别显眼的圆形“叫车”按钮会让人期待立即派单；“活跃成员”头像墙会让人以为这是个公开社交圈子。

视觉并不是中性的装饰。它会暗示产品能做什么。

所以这次把 Skill 产出当作备选素材，而不是拍板结论。

在挑颜色与卡片之前，先从产品规划里整理出用户必须完成的动作：

这些动作决定了信息架构。

成员页最终采用五项导航：

大厅承担找信息，候选承担判断与联系，发布是结构化入口，提醒负责异步回报，我的承担状态与设置。

没有单独的地图、聊天、订单与钱包入口，因为产品本来就不提供这些能力。

移动产品常把最重要的操作做成底部中央的超大悬浮按钮。

邻行确实希望用户方便发布，但若按钮长得像网约车的即时呼叫，就会制造错误预期：点完似乎该立刻有人响应。

因此“发布”放在五项导航的中央，却与其他导航保持相同尺寸。真正的主操作落在发布页面内部。

这遵循了两条准则：

视觉强调不能超过产品承诺。

微信群原始消息很短：

结构化页面不能因为数据库字段变多，就把一条信息塞成扫不动的大表格。

大厅卡片固定使用这个顺序：

用户最在意的是角色、路线、时间与状态，所以它们靠前。短编号仅用于指代这一条信息，并不充当用户身份。

页面不展示发布者账号、固定昵称、头像或累计发布次数。这既让卡片更简洁，也避免在联系方式互换前稳定追踪同一人的通勤规律。

产品规划评审时曾发现一个歧义：

用户可能会问：我明明 08:35 还能出发，为什么 08:20 就不等了？

这里的两个时间并不同义：

如果页面只是并排摆出三个时间输入框，用户很容易把它们当成重复字段。

发布页改为渐进展示：

默认只需填一个预计时间；想精确的人再展开修改区间。截止时间单独成组并写清后果。

这比在输入框旁放一个问号图标更直接，因为关键规则不该藏在悬浮提示里。

多步向导能让每页看起来很干净，但也带来返回、丢失与理解整体信息的成本。

邻行的字段其实不多，最终采用同一页面的三组结构：

只有车找人时才显示座位；只有用户选择修改时间区间时才展开两个边界字段。

这就是渐进披露：默认路径保持简洁，必要时再展示复杂选项。

表单仍必须满足：

设计系统给的不是一张静态图，而是每种状态下的交互规则。

邻行只能判断两条信息值不值得互相查看，不能保证双方具体位置合适，更不能保证最终同行。

候选详情因此先解释原因：

主标题是“可能同路”，而不是“匹配成功”。

系统把已知的原因说清，也把未知的具体位置交给双方确认。

这种文案看起来没有“匹配成功”那样振奋，但更贴合真实能力。

产品已经定下：合法候选中一方发起后，双方同时获得对方微信号，不等待另一方二次确认。

这不算“双向确认”，但确实是“双向披露”。

所以按钮不能只写“查看对方微信”。点击后的确认层必须说清：

确认后，你会看到对方的微信号；你的微信号也会同步提供给对方。

同时说明这不代表已经约定同行。

披露完成后，页面提供“复制微信号”，也把微信号渲染成可选中的文本。若微信内置浏览器不允许 Clipboard API，用户仍可长按或手动选择复制。

降级方案不是开发阶段的补丁，而是设计阶段的一部分。

架构已经区分业务事件与外部发送结果，页面也必须保留这个差异。

若喵提醒超时，候选并未失败。页面应当写：

若第三方明确拒绝：

“结果未知”和“明确失败”不能都用同一个红色感叹号，也不能把站内已经成立的候选显示成失败。

颜色只是辅助，标题、说明与下一步才是完整状态。

Skill 推荐加载 Lora 与 Raleway，后续检索又找到 Noto Sans SC。

这些字体都有合理使用场景，但邻行主要在中国大陆的微信浏览器中运行。为一个通勤工具引入外部字体请求，可能造成字体阻塞、网络不稳定和中英文回退差异。

最终采用系统中文字体栈：

这不是拒绝视觉设计，而是把阅读速度、加载稳定和平台熟悉感放在品牌字体之前。

字体层级依然明确：页面标题 24px，卡片路线 18px，正文与输入 16px，辅助说明不低于 13px。时间与座位启用等宽数字特性，避免倒计时变化时页面抖动。

最终采用克制的蓝绿色：

每种角色与状态仍同时显示文字或图标，不能只靠颜色区分。

设计完成后实际计算了关键组合的对比度：

这些组合都超过普通正文 4.5:1 的 WCAG AA 要求。

“看起来挺清楚”不是验收依据，可计算的硬指标应当计算。

通勤途中单手操作时，小按钮与误触比页面缺少动画更影响体验。

设计系统规定：

邻行没有引入 GSAP 或页面滚动动画。当前页面只需要 150–200ms 的颜色与透明度反馈。

一个按钮是否在 100ms 内回应点击，比卡片能否漂亮地从下方飘入重要得多。

只画“列表里堆满漂亮数据”的页面，很容易让实现阶段把异常状态随便补补。

邻行对每个列表都定义了空白原因与下一步：

错误文案必须回答三件事：

浏览器离线时不允许提交交换、确认与状态修改，因为这些动作依赖最新状态。首版也不假装支持离线发布。

把这些状态提前写进页面设计，TDD 才清楚要去验证什么。

移动尺寸、WebKit 自动化与响应式检查能提前发现不少问题，但它们无法证明邻行已经在微信内置浏览器中通过。

设计文档因此单列 Gate B：

在真实设备跑完之前，只能说“设计已纳入考量”和“实现已可验收”，不能说“已经兼容”。

页面体验环节沉淀了三类事实源：

更重要的是，它记录了哪些 AI 建议没有被采用，以及为什么。

AI 提供了更宽的候选空间，也快速补齐了容易遗漏的触控、焦点、错误与响应式规则。产品事实则负责淘汰那些虽然常见、却暗示了错误能力的模式。

下一步将用 dev-harness 把产品规划、工程架构与页面设计拆成纵向开发任务。

每个任务都要回答：

到这一步，页面设计才真正变成开发输入，而不只是几张等着实现者猜测的效果图。

仓库：garrytan/gstack 地址：https://github.com/garrytan/gstack

仓库：Dev-Wiki/dev-harness 地址：https://github.com/Dev-Wiki/dev-harness

仓库：nextlevelbuilder/ui-ux-pro-max-skill 地址：https://github.com/nextlevelbuilder/ui-ux-pro-max-skill