夜雨聆风
“AI 软件开发实战教程”系列第 6 篇：用 UI/UX Skill 生成设计系统和页面建议，再用真实使用场景、产品边界和可访问性逐项筛选，避免把第一份漂亮方案直接当成正确答案。
上一篇完成工程架构后，邻行已经知道系统要怎样保存信息、处理并发、发送提醒和保护敏感资料。
接下来要回答的是用户真正看到什么、先做什么，以及怎样知道自己没有理解错。
这个节点使用了 ui-ux-pro-max。它可以从本地设计资料中检索产品类型、风格、颜色、字体、触控、表单、导航和可访问性建议，也可以生成一份完整设计系统。
听起来像是把需求交给 Skill，等待它输出页面就可以了。
实际执行的第一个结果却是：
社区论坛式落地页； 紫色加绿色的社区配色； Lora 和 Raleway 字体组合； 夸张极简风格； 超大标题和大量留白； 滚动出现动画。
这套方案并不难看。
它只是不适合邻行。
1. 设计工具找到的是相似模式，不是产品答案
邻行包含“社区”和“车找人、人找车”，设计检索自然容易命中社区论坛、会员社区和网约车。
但邻行并不是这些产品：
它没有关注、评论、成员展示和社区活跃榜； 它没有价格、地图、实时位置和车辆调度； 它不追求让用户在页面里停留更久； 它的主要任务发生在通勤前，用户希望尽快发布或判断是否值得联系； 它最终把沟通交还给微信。
如果只按关键词相似度选择设计，很容易把不存在的产品能力也带进页面。
例如一张大地图会让人自然期待实时位置和导航；一个特别突出的圆形“叫车”按钮会让人期待即时派单；“活跃成员”头像墙会让人以为这是一个公开社交社区。
视觉不是中性的装饰。它会暗示产品承诺。
所以这次把 Skill 输出当作候选材料，而不是批准结论。
2. 先写出页面必须支持的真实动作
在选择颜色和卡片以前，先从产品规划整理用户必须完成的动作：
打开群里的链接 → 登录或使用邀请码注册 → 查找仍然有效的信息 → 发布车找人或人找车 → 理解时间窗口和匹配截止 → 查看可能同路的候选及原因 → 知道双方会互相披露微信号 → 复制微信号并返回微信 → 反馈是否已经约定同行 → 查看提醒和最新状态这些动作决定了信息架构。
成员页面最终采用五项导航：
大厅｜候选｜发布｜提醒｜我的大厅负责找信息，候选负责判断和联系，发布是结构化入口，提醒负责异步返回，我的负责状态与设置。
没有单独的地图、聊天、订单和钱包入口，因为产品根本不提供这些能力。
3. “发布”很重要，但不需要假装成叫车按钮
移动产品常把最重要操作做成底部中央的超大漂浮按钮。
邻行确实希望用户容易发布，但如果把按钮设计得像网约车的即时呼叫，会产生错误预期：点击以后似乎应该立即有人响应。
因此“发布”位于五项导航中央，却与其他导航保持同样尺寸。真正的主要操作出现在发布页面内部。
这遵循了两个原则：
导航回答“去哪里”； 页面按钮回答“现在做什么”。
视觉强调不能超过产品承诺。
4. 信息卡先回答路线和时间
微信群原始消息很短：
【车找人】【时间】17:50【路线】软件新城，中软、环普 → 悦城结构化页面不能因为数据库字段变多，就把一条信息变成难以扫描的表格。
大厅卡片固定成这个顺序：
角色标签 + 信息短编号 状态起点 → 终点日期 · 可出发时间窗口匹配截止 / 剩余座位下一步说明 >用户最关心的是角色、路线、时间和状态，所以它们优先。短编号只用来指代这一条信息，不承担用户身份。
页面不显示发布者账号、固定昵称、头像或累计发布次数。这不仅让卡片更简单，也避免在联系方式交换前稳定追踪同一个人的通勤规律。
5. 用页面解释两个容易混淆的时间
产品规划审阅时曾经发现一个歧义：
可出发：08:05–08:35最晚等到：08:20用户可能问：我明明 08:35 还能出发，为什么 08:20 就不等了？
这里的两个时间不是一回事：
可出发时间窗口表示双方什么时间出发都可以； 匹配截止表示到几点以后不再产生新候选，让用户还能决定是否改乘其他方式。
如果页面只是并排放三个时间输入框，用户很容易把它们当成重复字段。
发布页改为渐进展示：
预计时间 08:20系统生成：08:05–08:35 [修改范围]什么时候停止等候？匹配截止 08:05到时会提醒你当前结果，不再产生新候选。默认只需要填写一个预计时间；需要更精确的人再展开修改范围。截止时间单独成组并解释后果。
这比在输入框旁放一个问号图标更直接，因为重要规则不应该藏在提示里。
6. 发布表单为什么不拆成很多页
多步向导可以让每一页看起来很干净，但也会增加返回、丢失和理解整体信息的成本。
邻行的字段并不多，最终使用一个页面里的三个分组：
你要发布什么； 什么时候、从哪里到哪里； 什么时候停止等候。
只有车找人时显示座位；只有用户选择修改时间范围时展开两个边界字段。
这叫渐进披露：默认路径保持简单，需要时再显示复杂选项。
表单仍然必须满足：
每个输入有一直可见的标签； 输入字号至少 16px，避免 iOS 自动放大； 错误放在对应字段下面； 多个错误时顶部还有可跳转摘要； 提交后按钮立即显示“正在发布”并禁止重复点击； 离开未保存表单前明确确认； JavaScript 失效时核心表单仍能提交。
设计系统给出的不是一张静态图，而是每一种状态下的交互规则。
7. 候选页面不说“匹配成功”
邻行只能判断两条信息是否值得互相查看，不能保证双方具体位置合适，更不能保证最终同行。
候选详情因此先解释原因：
可能同路万科悦城 → 软件新城今天 08:05–08:20 有时间交集为什么推荐？✓ 同一天✓ 可出发时间有 15 分钟重合✓ 起点和终点属于兼容的大范围路线具体上车点和下车点仍需通过微信确认。主标题是“可能同路”，不是“匹配成功”。
系统把自己知道的原因说清楚，也把自己不知道的具体位置交给双方确认。
这种文案看起来没有“匹配成功”令人兴奋，却更符合真实能力。
8. 联系方式交换必须在点击以前说清后果
产品已经决定：合法候选中一方发起以后，双方同时获得对方微信号，不等待另一方二次批准。
这不是“双向确认”，但它确实是“双向披露”。
所以按钮不能只写“查看对方微信”。点击后确认层必须明确：
确认后，你会看到对方的微信号；你的微信号也会同时提供给对方。
同时说明这不代表已经约定同行。
披露完成后，页面提供“复制微信号”，也把微信号显示成可以选择的文本。如果微信内置浏览器不允许 Clipboard API，用户仍然可以长按或手动选择复制。
降级方案不是开发阶段的补丁，而是设计阶段的一部分。
9. 把提醒失败写成人能理解的状态
架构已经区分业务事件和外部发送结果，页面也必须保持这个区别。
如果喵提醒超时，候选并没有失败。页面应该写：
可能已经发送，请先查看微信。为避免重复提醒，系统没有自动重发。如果第三方明确拒绝：
微信提醒发送失败。这条提醒仍保存在站内，请检查喵码或稍后手动测试。“结果未知”和“明确失败”不能都用一个红色感叹号，也不能把站内已经成立的候选显示成失败。
颜色只是辅助，标题、说明和下一步才是完整状态。
10. 自动生成的字体方案也需要现实检验
Skill 推荐加载 Lora 和 Raleway，后续检索又找到 Noto Sans SC。
这些字体都有合理使用场景，但邻行主要在中国大陆的微信浏览器中运行。为了一个通勤工具引入外部字体请求，可能带来字体阻塞、网络不稳定和中英文回退差异。
最终采用系统中文字体栈：
-apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC","Hiragino Sans GB", "Microsoft YaHei", Arial, sans-serif这不是拒绝视觉设计，而是把阅读速度、加载稳定和平台熟悉感放在品牌字体之前。
字体层级仍然明确：页面标题 24px，卡片路线 18px，正文和输入 16px，辅助说明不低于 13px。时间和座位使用等宽数字特性，避免倒计时变化时页面抖动。
11. 颜色不是凭感觉通过的
最终采用克制的蓝绿色：
蓝绿色表示主要操作和车找人； 蓝色辅助区分人找车； 绿色表示成功； 橙色表示截止临近和发送结果未知； 红色只用于取消、删除和明确失败。
每一种角色和状态仍然同时显示文字或图标，不能只靠颜色。
设计完成后实际计算了关键组合的对比度：
主文字与浅色背景：15.10:1； 辅助文字与白色表面：6.35:1； 白字与主按钮：5.47:1； 白字与乘客蓝色：6.70:1； 白字与危险色：6.57:1。
这些组合都超过普通正文 4.5:1 的 WCAG AA 要求。
“看起来挺清楚”不是验收结果，可计算的要求应该计算。
12. 触控和深层链接比动效更重要
通勤途中单手操作时，小按钮和误触比页面缺少动画更影响体验。
设计系统规定：
所有触控区域至少 48×48px； 相邻操作至少间隔 8px； 底部导航预留手机安全区域； 固定导航不能遮住滚动内容； 深层链接登录后回到原目标页； 浏览器后退恢复大厅筛选和滚动位置； 横屏和 200% 缩放仍能完成核心操作； 减少动态效果时移除位移动画。
邻行没有引入 GSAP 或页面滚动动画。当前页面只需要 150–200ms 的颜色和透明度反馈。
一个按钮是否在 100ms 内回应点击，比卡片能否漂亮地从下面飘进来重要得多。
13. 同时设计空白、错误和弱网
只画“列表里有很多漂亮数据”的页面，很容易让实现阶段把异常状态随便补齐。
邻行对每个列表都定义了空白原因和下一步：
大厅没有信息：发布一条； 筛选后没有结果：清除筛选； 还没有候选：系统会持续查找，并在有候选或截止时提醒； 还没有提醒：解释站内提醒与微信提醒的关系。
错误文案必须回答三件事：
发生了什么； 用户刚才的数据是否已经保存； 接下来可以怎么做。
浏览器离线时不允许提交交换、确认和状态修改，因为这些动作依赖最新状态。首版也不假装支持离线发布。
把这些状态提前写进页面设计，TDD 才知道要验证什么。
14. 设计稿也不能冒充真机证据
移动尺寸、WebKit 自动化和响应式检查可以提前发现很多问题，但它们不能证明邻行已经通过微信内置浏览器。
设计文档因此单独保留 Gate B：
iOS 和 Android 微信打开邀请与详情； 登录后返回原页面并保持会话； 日期、时间和数字输入； 底部导航与安全区； 一键复制和手动复制； 返回微信的路径； 群分享标题和预览隐私； 系统字体放大、深色和横屏。
在真实设备完成以前，只能说“设计已经考虑”和“实现已准备验收”，不能说“已经兼容”。
15. 本节点真正交付了什么
页面体验节点完成了三类事实源：
一份设计系统：颜色、字体、间距、组件、动效、响应式和可访问性； 一份页面体验设计：信息架构、核心流程、文案、全部状态和微信验收边界； 一份产品验收映射：56 个场景分别落到哪些页面和设计证据。
更重要的是，它记录了哪些 AI 建议没有采用，以及为什么。
AI 提供了更广的候选空间，也快速补齐了容易遗漏的触控、焦点、错误和响应式规则。产品事实则负责淘汰那些虽然常见、却暗示了错误能力的模式。
下一步将使用 dev-harness 把产品规划、工程架构和页面设计拆成纵向开发任务。
每个任务都要回答：
用户完成了哪一个真实动作； 哪些产品与隐私规则必须同时成立； 对应 AC-01 到 AC-56 中的哪些验收场景； 第一条失败测试是什么； 自动化通过以后还有没有真机或人工 Gate。
到这里，页面设计才真正成为开发输入，而不只是几张等着实现者猜测的效果图。
16. 本篇验证摘要
页面以 375px 移动视口为起点，同时覆盖更宽屏幕、深色模式和减少动效偏好； 颜色、字体、间距、表单和状态反馈已经收敛为统一设计规则； 登录、发布、候选、交换和反馈流程都保留明确的用户决定，不用自动化替用户确认； 错误、空状态、加载和降级路径使用文字说明，不只依赖颜色或图标； 设计稿没有暗示地图、支付、计费或站内聊天等首版不存在的能力。
17. 附录：相关工具与仓库
17.1 gstack
仓库：garrytan/gstack 地址：https://github.com/garrytan/gstack
17.2 dev-harness
仓库：Dev-Wiki/dev-harness 地址：https://github.com/Dev-Wiki/dev-harness
17.3 UI UX Pro Max Skill
仓库：nextlevelbuilder/ui-ux-pro-max-skill 地址：https://github.com/nextlevelbuilder/ui-ux-pro-max-skill
