从静态清单到可交互工具：交付顾问用 AI 提升车主验车体验
小米技术 · 软件开发
小米技术 2026-11-06 17:00 北京 在海南一家汽车门店里，一位交付顾问，借助 AI 做出了一套验车工具，并逐步投入真实使用。本文记录的，不只是“AI 帮忙写代码”，而是一线业务场景里的真实问题，如何一步步被做成可交互、可验证、可持续迭代的现场工具。从静态验车清单，到能够跟着用户操作流程“动起来”的小程序，变化的不只是产品形态，还有 AI 与业务经验之间的协作方式。 01 第一轮：从一线经验到软件流程 在汽车门店的交付流程中，验车一直是用户投入时间和注意力较多的环节。尤其在海南，待交付车辆普遍需要经历陆运和海运，很多人在提车前都会提前保存社交平台上的验车清单，到现场再逐项核对。这已经成了不少用户提车前的习惯动作。 刘润生是海南一家汽车门店的交付顾问。长期的一线工作中，他注意到，大家真正遇到的问题并不只是“知道检查什么”，而是到了现场之后，检查路线容易来回折返，检查到一半也很难确认哪些已经完成、哪些还没看；发现异常后，照片、备注和最终记录之间也缺少顺畅衔接。 他开始思考，能不能让整个验车过程更连贯一些，给用户带来更多便利。 静态表格虽然能列出检查项目，却并不真正适合现场使用。很多时候，用户需要一只手拿手机、另一只手围车检查，表格字小不易阅读，还要不断在车辆、手机和检查流程之间来回切换。 于是，他开始尝试把验车清单做成一个名为“提车不踩坑”的小程序。用户能够按顺序逐项检查车辆；发现问题时，直接记录备注和照片；检查结束后，自动生成报告，并保留历史记录。 在他的设想里，这个工具的重点并不是再增加更多检查知识，而是让用户到了现场之后，知道下一步该做什么，并且能够顺着流程自然完成检查。但真正进入开发之后，新的问题很快又摆在了面前：不会写代码，也没有开发经验。软件怎么安装、环境怎么配置、页面怎么跑起来，此前几乎都没有接触过。最先能做的事情，是把整理好的验车流程、检查项和页面想法描述给 AI，希望先实现一个基础版本：用户能够逐项检查车辆、记录异常，并生成完整报告。剩下的环境配置、项目初始化和页面搭建，则交给 AI 一步步协助完成。 在 AI 的协助下，第一个可交互版本很快跑了起来。当页面第一次真正出现在手机上时，刘润生第一次感觉到，这个原本停留在想法里的工具，开始变得具体了。 小程序早期开发页面，已经已经有了简单版、详细版的雏形 页面真正能够操作之后，问题也开始变得具体。最先暴露出来的，是检查路线问题。最早版本里的检查项，会在车辆左右两侧之间不断跳转。用户刚检查完左侧，下一项可能又回到右侧；绕到另一边后，后续项目又跳回来。单看每一项都没问题，但真实使用时，人会被清单“带着绕车”。 于是，他重新按现场动作梳理流程：前保、左侧、后保、右侧，让检查能够沿着车辆自然推进；再把新的绕车路线和页面逻辑描述给 AI，调整检查项顺序与页面状态。调整之后，检查项不再频繁跨侧跳转，整个检查流程终于顺了下来。 但检查路线理顺之后，问题并没有减少。最初，刘润生以为页面能跑起来之后，后面更多只是“补功能”；但真机测试开始后，问题很快从页面布局延伸到状态同步、数据保存、流程恢复和版本一致性。 那段时间，他经常拿着手机在现场边操作边测试。有些问题只有真实使用时才会暴露，比如滑动状态错乱、返回路径异常、键盘弹出后遮挡输入区域。输入法问题就是其中一个典型例子。为了让页面更轻，他尝试过悬浮胶囊式导航。但填写备注时，输入法弹出后会遮挡输入区域，用户很难顺利写完内容。他并不知道是哪段代码出了问题，只能把截图、操作路径和现象一起发给 AI：“点击备注后输入法弹出，输入区域被遮挡；发现异常后，用户没办法顺利写完备注。” AI 修改了几轮，问题依然存在。他一度考虑放弃悬浮胶囊导航。后来，他换了一种表达方式：“允许输入法压着悬浮胶囊。”这次调整解决了当时版本中备注输入被遮挡的问题。这句话虽然不是技术方案，却明确了业务优先级：导航栏是否被遮挡不是核心问题，备注必须能够顺利写完才是。AI 可以提出实现方案，但在这个场景里，先保障哪一步体验，需要他根据现场使用来明确。 这次调整之后，他和 AI 的协作方式也开始发生变化。很多时候，他并不知道应该修改哪段代码，但知道用户会在哪一步停下来。反馈不再从代码出发，而是从用户卡点倒推，逐渐形成了一套固定的说法：问题出现在哪一步、用户刚刚做了什么操作、实际结果是什么、预期结果应该是什么、哪些部分已经改善、哪些问题仍然存在。 这套反馈方式，在第一轮里更多是在帮助迭代更快；到了第二轮，它开始变成规则。 ▍ 从单点问题，到完整流程验证 随着功能的完善，新的问题不断暴露出来：切换详细检查模式后，报告进度没有同步更新；完成检查后自动进入报告，用户返回时又被重新跳回报告页面；悬浮导航上滑时出现重影；不同屏幕尺寸下，按钮文字被挤压；异常状态下，照片和备注无法顺