从静态清单到可交互工具:交付顾问用 AI 提升车主验车体验

在海南一家汽车门店里，一位交付顾问，借助 AI 做出了一套验车工具，并逐步投入真实使用。本文记录的，不只是“AI 帮忙写代码”，而是一线业务场景里的真实问题，如何一步步被做成可交互、可验证、可持续迭代的现场工具。从静态验车清单，到能够跟着用户操作流程“动起来”的小程序，变化的不只是产品形态，还有 AI 与业务经验之间的协作方式。

01

第一轮：从一线经验到软件流程

在汽车门店的交付流程中，验车一直是用户投入时间和注意力较多的环节。尤其在海南，待交付车辆普遍需要经历陆运和海运，很多人在提车前都会提前保存社交平台上的验车清单，到现场再逐项核对。这已经成了不少用户提车前的习惯动作。

刘润生是海南一家汽车门店的交付顾问。长期的一线工作中，他注意到，大家真正遇到的问题并不只是“知道检查什么”，而是到了现场之后，检查路线容易来回折返，检查到一半也很难确认哪些已经完成、哪些还没看；发现异常后，照片、备注和最终记录之间也缺少顺畅衔接。

他开始思考，能不能让整个验车过程更连贯一些，给用户带来更多便利。

静态表格虽然能列出检查项目，却并不真正适合现场使用。很多时候，用户需要一只手拿手机、另一只手围车检查，表格字小不易阅读，还要不断在车辆、手机和检查流程之间来回切换。

于是，他开始尝试把验车清单做成一个名为“提车不踩坑”的小程序。用户能够按顺序逐项检查车辆；发现问题时，直接记录备注和照片；检查结束后，自动生成报告，并保留历史记录。

在他的设想里，这个工具的重点并不是再增加更多检查知识，而是让用户到了现场之后，知道下一步该做什么，并且能够顺着流程自然完成检查。但真正进入开发之后，新的问题很快又摆在了面前：不会写代码，也没有开发经验。软件怎么安装、环境怎么配置、页面怎么跑起来，此前几乎都没有接触过。最先能做的事情，是把整理好的验车流程、检查项和页面想法描述给 AI，希望先实现一个基础版本：用户能够逐项检查车辆、记录异常，并生成完整报告。剩下的环境配置、项目初始化和页面搭建，则交给 AI 一步步协助完成。

在 AI 的协助下，第一个可交互版本很快跑了起来。当页面第一次真正出现在手机上时，刘润生第一次感觉到，这个原本停留在想法里的工具，开始变得具体了。

小程序早期开发页面，已经已经有了简单版、详细版的雏形

页面真正能够操作之后，问题也开始变得具体。最先暴露出来的，是检查路线问题。最早版本里的检查项，会在车辆左右两侧之间不断跳转。用户刚检查完左侧，下一项可能又回到右侧；绕到另一边后，后续项目又跳回来。单看每一项都没问题，但真实使用时，人会被清单“带着绕车”。

于是，他重新按现场动作梳理流程：前保、左侧、后保、右侧，让检查能够沿着车辆自然推进；再把新的绕车路线和页面逻辑描述给 AI，调整检查项顺序与页面状态。调整之后，检查项不再频繁跨侧跳转，整个检查流程终于顺了下来。

但检查路线理顺之后，问题并没有减少。最初，刘润生以为页面能跑起来之后，后面更多只是“补功能”；但真机测试开始后，问题很快从页面布局延伸到状态同步、数据保存、流程恢复和版本一致性。

那段时间，他经常拿着手机在现场边操作边测试。有些问题只有真实使用时才会暴露，比如滑动状态错乱、返回路径异常、键盘弹出后遮挡输入区域。输入法问题就是其中一个典型例子。为了让页面更轻，他尝试过悬浮胶囊式导航。但填写备注时，输入法弹出后会遮挡输入区域，用户很难顺利写完内容。他并不知道是哪段代码出了问题，只能把截图、操作路径和现象一起发给 AI：“点击备注后输入法弹出，输入区域被遮挡；发现异常后，用户没办法顺利写完备注。”

AI 修改了几轮，问题依然存在。他一度考虑放弃悬浮胶囊导航。后来，他换了一种表达方式：“允许输入法压着悬浮胶囊。”这次调整解决了当时版本中备注输入被遮挡的问题。这句话虽然不是技术方案，却明确了业务优先级：导航栏是否被遮挡不是核心问题，备注必须能够顺利写完才是。AI 可以提出实现方案，但在这个场景里，先保障哪一步体验，需要他根据现场使用来明确。

这次调整之后，他和 AI 的协作方式也开始发生变化。很多时候，他并不知道应该修改哪段代码，但知道用户会在哪一步停下来。反馈不再从代码出发，而是从用户卡点倒推，逐渐形成了一套固定的说法：问题出现在哪一步、用户刚刚做了什么操作、实际结果是什么、预期结果应该是什么、哪些部分已经改善、哪些问题仍然存在。

这套反馈方式，在第一轮里更多是在帮助迭代更快；到了第二轮，它开始变成规则。

▍从单点问题，到完整流程验证

随着功能的完善，新的问题不断暴露出来：切换详细检查模式后，报告进度没有同步更新；完成检查后自动进入报告，用户返回时又被重新跳回报告页面；悬浮导航上滑时出现重影；不同屏幕尺寸下，按钮文字被挤压；异常状态下，照片和备注无法顺利保存。

这些需求并不是一开始就全部列好的，而是在页面能够操作、真实使用开始之后，才逐步显现。

有时，AI 会反馈问题已经修复，但刘润生在手机上重新操作，仍然能看到异常，只能继续补充：“实际上还是有的。”当问题从页面布局延伸到状态、数据和流程，他也开始意识到，迭代不能无限叠加，需要及时封版：一个版本进入收尾和测试阶段后，先把稳定版本做出来，再继续增加新功能。否则需求不断叠加，版本始终停留在“还可以再改一点”的状态，难以进入可验证、可使用的阶段，迟迟无法完成一轮完整测试。

项目从 1.0 迭代至 2.5，覆盖范围也不断扩大。除了新能源新车和燃油新车验车，还增加了日常检查、事故留证、燃油摩托车和电动摩托车等场景，并支持简单和详细两种检查模式、历史记录、照片备注和报告功能。其中，摩托车验车功能源于刘润生的个人兴趣；日常检查场景，则来自他对高频使用场景的思考：相比新车交付，代驾、租车等场景可能有更频繁的车辆检查需求。

第一轮结束时，他手里已经不再只是一个想法，而是一套能够运行的产品流程、一批实际使用中发现的问题，以及一批在真实使用里被不断逼出来的问题。AI 可以帮助把页面和功能快速生成出来，但软件真正复杂的部分，往往出现在真实用户开始连续操作之后。下一步要解决的，也不再是“继续加功能”，而是怎样把第一轮踩过的坑，提前变成规则、约束和验收条件。

02

第二轮：先定规则，再交付

▍迁移 App 前，先明确产品基线

小程序版本逐渐稳定后，刘润生将其正式上线，目前已有一些车主在真实提车场景中使用，反馈他也逐条记录了下来。

与此同时，他开始认真考虑迁移 Android App。相比小程序，App 可以承载更多图片、项目说明和界面细节，也有更大空间继续优化操作体验。但真正让他下定决心的，是第一轮踩过的那些坑：页面适配、状态同步、用户流程、数据兼容、测试遗漏……如果只是把页面重新做一遍，同样的问题很可能还会再出现。第二轮要解决的，是“怎么不再踩同样的坑”。

也是在这个阶段，他接触到了 Xiaomi MiMo-V2.6。真正吸引他的，是它在项目阅读、上下文承接和按规则执行上的能力：相比第一轮用的工具，它更容易读懂已有项目、承接前面的修改，并遵守约定的开发规则，不会每次都像“从零生成”。

这让他意识到，AI 协作可以换一种方式：先把经验整理出来，再带着约束推进开发。于是，正式迁移之前，他先整理了项目地图、已有功能、数据结构和核心流程，交给模型阅读，目标是先让模型理解“现在已经有什么”，避免重新生成一套“差不多的东西”。理解完现状之后，第一步也不是继续堆功能，而是先跑通一条完整链路：新建记录 → 开始检查 → 填写备注 → 恢复记录 → 生成报告 → 查看历史。核心流程稳定后，再扩展其他功能。

第一轮解决的是“功能能不能跑起来”；第二轮要解决的是“功能如何稳定交付”。

▍协作规则开始接近真实工程流程

第一次开发时，更多是在问题出现后推动 AI 修改；到了 Android App 阶段，开始把第一轮踩过的坑提前整理成规则和验收条件。例如，修改代码前先检查项目结构和 Git 状态；不通过删除原有功能规避问题；不用假数据掩盖错误；涉及数据模型时优先考虑兼容性；未实际完成构建和验证时，不直接标记完成。

界面修改则需要检查键盘遮挡、长文本、异常状态、加载状态和不同屏幕尺寸。每轮修改结束后，还要明确说明修改内容、测试结果、已知问题和未验证部分。

第一轮让 AI 帮忙写功能；第二轮开始要求 AI 按规则交付。这种变化背后是角色变化：原本更像“提需求的人”，现在已开始同时承担产品、测试和验收的一部分工作。AI Coding 降低的不只是开发门槛，也包括业务人员参与软件生产的门槛，可以更直接地参与原型搭建、问题复测和结果验收，把现场经验带进开发过程。门槛降低之后，复杂性并没有消失，只是更早地出现了。

规则立起来之后，AI 协作开始接近真实的软件工程流程。以前是看到问题再修改；现在，他会先要求 AI 阅读项目结构、理解已有逻辑，再开始改动。追问的范围也变了：这次修改影响了哪些状态？有没有破坏旧数据？构建版本和测试截图是不是同一个版本？

很多原本只属于开发、测试和产品协作的问题，就这样出现在一个没有开发背景的一线业务人员面前。而问题一旦摆上台面，最先被重新审视的，就是“测试通过”到底意味着什么。

03

验收：测试通过，不等于流程可用

规则立住之后，新的问题又往前推了一步：AI 说“测试通过”，并不等于用户真的能把一件事走完。这一点，在一次分享功能迁移中暴露得特别明显。

需求很明确：用户收到分享的验车清单后，可以先预览内容；确认使用时，再创建自己的新记录。MiMo 给出的结果是：文件解析正常、记录创建成功、测试通过。但复查发现，创建记录其实是直接调用内部方法完成的，并没有经过用户实际会操作的页面。也就是说，“数据能创建”，不等于“用户真的能完成创建”。模型验证的是接口和方法；用户操作的却是页面和流程。

▍AI 验证的是方法，用户走的是流程

真实用户路径应该是：接收分享、进入预览页、点击“使用清单”、创建新记录、跳转检查页面。而当时，预览页没有完整验证，页面跳转未覆盖，创建结果没有正确回传，重复点击甚至可能造成重复创建。文件能读、数据能建，只能说明部分底层能力成立，还不足以证明用户真能完成整项任务。

于是，他没有把“测试通过”直接视为功能完成，而是继续要求补充真实入口验证、页面跳转检查、创建结果传递、重复点击处理，以及完整用户路径复测。后续复查中他又发现：页面导航联动还没接好、创建结果没有正确传递、防重复点击仍有缺口。

▍将验收落到真实路径、数据和版本

这次复查也改变了他对“验收”的理解。过去，他更容易先看功能有没有出现、页面有没有做出来；现在，他会继续追问：

• 真实路径：用户能否从真实入口完成操作；测试覆盖的是内部方法，还是用户实际会走的完整路径；

• 数据连续性：输入或保存失败后，已有内容是否保留；旧照片是否仍可访问；用户返回上一页时，是继续检查还是回顾记录；

• 版本一致性：构建包、截图和测试材料是否来自同一版本；

除了功能链路，视觉和适配细节也被纳入验证范围。例如，暗色界面加大字体的设置下，“展开”按钮的文字与背景对比不足，几乎无法看清。他据此要求重新检查文字在对应背景上的可读性，并补充实际展开后的截图。页面上有这行字不等于功能可用，用户能不能看清、能不能点击、点击后状态是否正确，都要纳入验收。

对于涉及连续操作和数据流转的功能，验收不能只看局部测试，而要回到真实入口、真实路径和真实版本。目前，Android 版本已具备可运行的核心流程，仍处于内部验证和持续迭代阶段。

04

沉淀：两轮实践留下了什么

这次实践未必能够直接复制到所有项目中，但其中几种做法，可以为没有工程技术背景、又希望借助 AI 推进具体工作的小伙伴提供参考。

1.从熟悉的问题开始，让 AI 先做

没有开发经验，不意味着必须先掌握全部技术才能开始。他的起点不是“先学会开发”，而是熟悉的验车场景：先把现场动作和用户需求理清楚，再让 AI 把它转化为可操作的流程。AI 帮他跨过了软件安装、环境配置、页面搭建和代码实现等起步门槛，业务经验则帮助他判断工具应该怎样使用。先有一个可以操作的版本，许多原本抽象的问题才会变得具体。

2.用“现象、影响和预期”描述问题

面对悬浮导航与输入法冲突的问题，他并不知道技术原因，但能够持续描述：问题出现在哪一步，用户会受到什么影响，希望优先保障什么。当无法判断应该修改哪段代码时，不一定要先给出技术方案。把真实操作路径、实际结果和预期结果说清楚，仍然可以帮助 AI 缩小问题范围。

3.用真实用户路径验证交付结果

页面出现、日志通过、测试成功，都可以是过程中的证据，但不应自动等同于任务完成。验收时还要确认：验证的是局部能力，还是用户能实际完成的任务；相关截图、构建包和测试记录是否对应同一版本。

这次实践并不意味着，没有开发背景的人已经可以独立完成软件交付，但展示了业务人员参与开发的一种方式：用现场经验定义问题，借助 AI 推进实现，再用实际操作检验结果。小程序与 Android App 的开发、调试和部分验证，确实可以借助 AI 工具推进；但数据是否安全、流程是否合理、用户是否真的能够完成任务，仍然需要实际使用者持续判断和把控。

但它提供了一种新的可能：一线业务人员可以借助 AI，把真实场景里的问题，更早、更具体地带进软件生产流程，把现场遇到的问题更早做成可操作的原型，让需求讨论有具体的页面、动作和结果作为依据，而不是等到需求翻译、开发排期之后才被看见。

AI 帮他的远不止“写代码”。在与 AI 协作的过程中，他逐渐学会的，是另一种能力：如何描述真实问题，如何定义用户路径，如何建立规则和边界，以及如何验证一个功能是否真正可用。最开始，他给 AI 的反馈可能只是：“这里还是不对。”后来，反馈会逐渐变成：在哪个页面、先点了什么、实际发生了什么、预期应该是什么。他并没有因此变成专业开发者，但已经能够把业务里的判断，转化成机器可以执行、可以验证的要求。

AI 没有绕开软件开发里的复杂性，但它正在改变谁能够更早地参与软件生产。

END