“AI 软件开发实战教程”系列第 2 篇：不急着列功能，先用一次真实产品讨论弄清楚谁遇到了什么问题，还有哪些关键假设没有证据。
AI 很擅长快速生成页面、功能清单和版本规划。但如果问题还没有想清楚，生成得越快，返工也可能来得越早。
我想做一个叫“邻行”的小工具。
它来自一个很普通的生活场景：我们小区有两个顺风车微信群。有车的人发布“车找人”，准备坐车的人发布“人找车”。大家最终还是在微信里联系，群里也已经聚集了不少真实用户。
问题是，群消息很快就会被刷走。
一开始，我很容易把这个想法概括成一句话：
做一个更方便发布和查找顺风车信息的平台。
这句话听起来已经足够让 AI 开始工作了。它可以马上列出注册、登录、发布、搜索、订单、支付、地图、聊天、评价等功能，甚至直接生成数据库和页面。
但这样做有一个危险：代码可能很快出现，我们却还不知道真正要解决的是什么。
所以，这次我没有继续往下写功能，而是先让 AI 和我进行了一次完整的产品讨论。
最初看到的是“消息被刷走”
微信群里的消息通常是这样的：
【车找人】
【时间】17:50
【路线】软件新城，中软、环普 → 悦城
【人找车】
【时间】现在随时
【路线】华为 → 悦城
【车找人】🚗
【时间】明早 8:05
【路线】万科 → 环普 / 中软 / 阿里 / 华为
格式并不是完全统一的，但人通常能看懂。
如果对方恰好在线，也恰好看到了这条消息，双方很快就能联系上。真正麻烦的是，他们经常不会在同一时间出现。
群里能看到这样的重复询问：
- “刚才去某地的车还有吗？”
- “明早有八点左右去锦业路的吗？”
- “人找车，明早有到国际医学的吗？”
过一段时间，可能才有人简单回复一句：“有。”
这说明问题不只是“搜索群消息不方便”。更准确地说，是车主和乘客的需求在不同时间出现，而微信群只能按照发送时间排列消息。
较早发布的人不知道后来出现了合适的人，后来进入群里的人也不一定会继续向上翻。
先找证据，而不是先想功能
这次产品讨论使用了 gstack 中的产品讨论技能，工具名称是 office-hours。名字并不重要，它做的事情可以用一句普通话解释：
不急着给方案，先不断追问谁真的需要、现在怎样解决、失败以后会付出什么代价。
我提供了几个真实情况：
- 目前有两个小区顺风车群，一个群有 398 人，另一个群有 295 人，成员可能重复；
- 活跃时期每天大约有 20 到 30 条顺风车供需消息；
- 有乘客周一到周六几乎每天都需要早上八点左右去同一个工作区域；
- 有车主除限行日外每天都会开车，每次都会寻找顺路的人；
- 匹配不到时，用户通常改乘网约车或公共交通；
- 群内顺风车不管远近一般是 10 元，网约车贵得多，公共交通耗时通常接近顺风车的两倍。
这些信息还不能证明产品一定会成功，但至少说明这不是开发者凭空想象出来的问题。
这里已经出现了几种不同性质的内容：
已经观察到的事实
- 群里存在重复发布和重复询问；
- 有高频、固定路线的车主和乘客；
- 车主和乘客经常在不同时间出现；
- 匹配失败确实会增加费用或通勤时间。
根据事实作出的产品判断
- 产品不应该取代微信群；
- 最终联系仍然回到微信；
- 产品应当帮助不同时间出现的人发现彼此；
- 第一批用户应该是固定路线的高频通勤者，而不是所有居民。
仍然没有验证的假设
- 用户是否愿意从微信群点击一个网页；
- 用户是否愿意注册账号；
- 用户是否愿意关注第三方提醒服务并填写提醒码；
- 用户是否接受在符合条件时交换微信号；
- 结构化发布和主动提醒究竟能提高多少联系成功率。
把这三类内容分开非常重要。否则，AI 很容易把“我们觉得用户会接受”写成“用户需要”，再把它变成必须开发的功能。
真正的核心不是保存消息，而是跨时间找到对方
讨论中曾经出现过一个相对简单的方案：做一个适合在微信中打开的信息板。
用户可以发布“车找人”或“人找车”，填写时间和路线；其他人可以按日期、方向和地点筛选。旧消息不再随着群聊滚动而消失，取消和过期状态也可以及时更新。
这个方案比微信群更整齐，但它仍然有一个明显问题：用户必须主动、反复打开网页。
如果乘客早上八点发布需求，车主九点才发布信息，乘客可能早已放弃等待。即使系统里已经存在两条合适的信息，双方仍然可能错过。
因此，我提出了一个更强的要求：
匹配到同路信息时要提醒；到了用户最晚愿意等待的时间仍没有结果，也要提醒。
这个变化重新定义了第一个试用版本。
产品不只是把群消息存起来，而是要完成下面这个过程：
车主或乘客发布结构化信息
→ 系统按照日期、方向、地点和时间寻找可能同路的人
→ 有合适信息时提醒双方
→ 一方决定联系后，双方获得对方微信号
→ 双方回到微信沟通
→ 到最晚等待时间仍没有结果时，提醒用户准备其他出行方式
这里使用“可能同路”，而不是“匹配成功”。系统只能判断两条信息值得互相看看，不能替双方确认路线，也不能承诺一定同行。
第一个版本应该做什么，又坚决不做什么
讨论最终选择的是“信息板加最小匹配提醒”。
第一个受控试用版本准备包含：
- 邀请注册和账号密码登录；
- 车找人、人找车的结构化发布；
- 日期、时间范围、常用地点和方向；
- 用户可以修改的最晚等待时间；
- 只服务当前小区的规则匹配；
- 找到可能同路对象后的提醒；
- 到等待截止时间后的结果提醒；
- 符合条件时双向交换微信号；
- 关闭、满员、取消和过期状态；
- 可以复制到微信群的标准文字。
与此同时，一些看起来很像“拼车平台应该有”的功能被明确排除：
- 不做在线支付；
- 不计算或结算车费；
- 不抽成；
- 不抢单、不派单；
- 不提供地图导航和实时位置；
- 不建设站内聊天；
- 不承担运输、担保或保险责任。
这些边界不是为了让功能列表显得简单，而是为了让产品始终回答最初的问题：怎样提高社区同路信息的沟通效率。
为什么不能直接公开所有人的微信号
只要产品需要“回到微信联系”，就会遇到一个隐私问题：谁能看到谁的微信号？
最方便的做法，是登录后直接展示发布者微信号。但这样会让任何社区成员都能批量翻看其他人的联系方式，也会让分享链接、页面源代码和日志存在泄露风险。
最后确定的规则是：
- 微信号不显示在信息列表和普通详情中；
- 系统先判断两条信息是否属于有效的可能同路对象；
- 其中一方点击“想和对方联系”时，明确告诉他自己的微信号也会提供给对方；
- 发起后，双方同时获得对方微信号；
- 每次联系方式交换都留下必要的审计记录；
- 管理员不能通过普通后台查看成员微信号和提醒码。
这不是微信授权登录。用户仍然使用自己设置的账号和密码登录，微信号只是私密联系方式。
首版计划借助“喵提醒”向微信发送提醒。用户关注相应服务后，把自己的喵码填入系统。但这目前只是候选方案，还没有经过真实接口验证，因此不能写成“已经确定可用”。
一次讨论结束，不等于整个产品验证结束
产品讨论完成后，AI 生成了一份五百多行的设计文档。它包含问题证据、目标用户、候选方案、匹配规则、状态变化、隐私边界、提醒去重、失败处理和下一步任务。
这份文档经过了多轮独立检查，也得到了我的确认。
但这里很容易出现另一个错误：把“这次讨论完成了”写成“产品验证完成了”。
实际上，当前状态应该是：
- 产品讨论节点已经完成；
- 产品验证阶段仍在进行；
- 正式产品规划还没有生成；
- 工程架构和开发计划还没有开始；
- 用户访谈和两个技术验证仍未完成。
为了避免后续 AI 会话跳过这些缺口，我增加了一个“节点收尾”步骤。
每个重要节点结束后，都要记录：
- 这个节点原本要完成什么；
- 实际产出了什么；
- 哪些结论已经确认；
- 哪些仍然只是假设；
- 哪些旧文档与新结论冲突；
- 当前是否允许进入下一步；
- 下一步必须读取哪些材料；
- 哪些事情不能提前宣称完成。
对这次产品讨论，最初的收尾结论是“有条件继续”：优先准备访谈和技术验证，不能直接进入编码。后来确认当前无法安排访谈后，检查点进一步更新为：允许形成带有未验证假设的正式产品规划草案，但仍然不能把用户接受度写成已验证事实，也不能直接进入编码。
为什么把已经写好的旧规划删掉
在进行这次讨论之前，我已经让 AI 生成过一份完整产品规划和一份从第一个版本到正式版本的开发路线。
它们看起来很完整，却包含一个根本问题：这些规划形成得太早。
例如，旧规划把匹配和提醒放到了较晚版本，但真实讨论表明，提醒才是解决不同时间出现的车主和乘客互相错过的关键能力。旧规划还曾允许社区成员直接查看联系方式，这与后来确认的双向交换规则冲突。
如果这些文档继续放在项目根目录，后续 AI 很可能先读到它们，然后根据过时的任务列表直接设计架构、生成看板甚至开始编码。
我的处理方式是：
- 先把旧文档、调整说明和节点检查点一起提交到版本历史；
- 确认它们以后可以恢复；
- 再从当前工作区删除四份旧规划；
- 在项目首页明确写出当前唯一入口和下一步门禁。
删除不是否认以前的思考，而是避免历史材料继续冒充当前事实。
这也是版本管理真正有价值的地方：项目目录保持清晰，历史过程仍然可以追溯。
理想的下一步是访谈，但这次不能虚构
产品讨论留下的用户验证作业很具体：
- 访谈一名几乎每天寻找顺路人的车主；
- 访谈一名周一到周六经常在相近时间通勤的乘客。
如果能够安排访谈，不能先介绍产品有多好，也不能教对方怎样操作。需要观察和询问的是：
- 他们现在怎样判断一条旧消息是否还有效；
- 是否愿意点击群里的链接并注册；
- 是否愿意关注提醒服务并填写喵码；
- 怎样理解“最晚等待时间”；
- 是否接受符合条件后一方发起、双方同时交换微信号；
- 哪一步会让他们直接放弃。
访谈结果需要区分用户原话、观察到的行为和开发者自己的解释。
但这个教程当前没有条件完成这两次访谈。为了让文章看起来完整而模拟用户回答，会比直接跳过更糟，因为伪造的反馈很可能在后续文档中变成“已经验证的需求”。
因此，这次采用证据受限的处理方式：
- 明确记录用户访谈没有执行；
- 不声称用户已经接受注册、喵提醒和联系方式交换；
- 基于现有群聊行为、个人使用经历和产品讨论形成产品规划草案；
- 把所有依赖用户接受度的结论继续标记为待验证；
- 如果以后具备条件，再补充真实访谈或试用反馈。
读者在开发自己的真实产品时，如果能够接触目标用户，仍然应该完成这一步。这里跳过的原因是现实条件不足，不是因为用户访谈没有价值。
喵提醒接口和微信内置浏览器仍需要分别验证，之后才能批准产品规划并进入工程架构与开发计划。
后续调整：这段话记录的是当时的门禁安排。执行到 Gate A 以后，产品负责人补充了另一个现有项目在微信内置浏览器正常使用的经验。项目据此取消一次性的前置 Gate B 页面，把邻行成品的双平台微信真机验收移到首条可运行闭环完成后、正式试用前执行。
一套普通开发者也能复用的方法
如果你也准备让 AI 帮助完成一个产品，可以先不用记工具名称，只执行下面这条简单流程：
保存真实问题和原始材料
→ 追问谁在使用、现在怎样解决、失败成本是什么
→ 区分事实、判断和假设
→ 比较几个不同大小的解决方案
→ 明确第一个试用版本和永久边界
→ 给本次讨论做节点收尾
→ 能接触用户时完成真实验证；不能时明确记录证据限制
→ 形成带有未验证假设的正式产品规划草案
→ 最后才进入架构、任务拆分和编码
AI 的速度很快，但我们不必把这种速度全部用在生成更多功能上。
更有价值的用法，是让它帮助我们暴露证据不足、发现前后冲突，并在每一步结束时留下可以检查的结果。
最后
这个项目到现在还没有一行业务代码。
但相比一开始那句“做一个更容易发布和查找同路信息的工具”，我们已经更清楚地知道：
- 谁最可能需要它；
- 他们为什么会反复使用；
- 现有微信群究竟缺少什么；
- 为什么提醒比单纯保存消息更重要；
- 联系方式应该怎样保护；
- 哪些功能不应该进入产品；
- 哪些关键假设仍然没有证据。
这不是开发进度停滞，而是在减少以后用代码返工的概率。
下一篇将基于 Office Hours 结果和现有证据形成正式产品规划草案，并明确区分已确认边界、待技术验证条件和尚未获得用户确认的假设。
附录：相关工具与仓库
gstack
仓库：garrytan/gstack
地址：https://github.com/garrytan/gstack
本文实际使用了其中的 office-hours 产品讨论技能，用来追问需求证据、目标用户、现有替代方式、最窄切入口和产品边界。
dev-harness
仓库：Dev-Wiki/dev-harness
地址：https://github.com/Dev-Wiki/dev-harness
本文阶段只使用了它的版本管理工作流来保存检查点和历史文档。后续将在产品规划、架构和验收条件确定后，再使用计划与看板能力。
UI UX Pro Max
仓库：nextlevelbuilder/ui-ux-pro-max-skill
地址：https://github.com/nextlevelbuilder/ui-ux-pro-max-skill
本文阶段尚未进入正式页面设计。该工具将在产品规划和关键用户流程稳定后，用于移动端页面、表单、状态提示和无障碍设计。
