AI 软件开发实战教程（三）：把讨论结果变成可执行的产品规划

“AI 软件开发实战教程”系列第 3 篇：把已经完成的产品讨论整理成正式规划，通过逐项审阅消除规则歧义，并为后续技术验证、架构设计和测试留下可以检查的依据。

上一篇完成产品讨论后，“邻行”已经不再只是一句模糊的想法。

我们知道它要解决的是：小区顺风车微信群里的供需信息出现时间不同，较早发布的消息很快被刷走，后来出现的车主和乘客很难持续发现彼此。

我们也已经确定，产品不会扩张成一个完整拼车平台。它不做支付、派单、导航和站内聊天，只负责让信息更容易发布、查找、更新和提醒，双方最终仍然回到微信沟通。

这些结论足够开始写产品规划，却还不够开始写代码。

因为“要做什么”只是第一层问题。开发前还必须回答：每个功能在什么条件下发生，失败后是什么状态，谁能看到哪些信息，以及怎样证明它真的完成了。

产品讨论和产品规划不是一回事

产品讨论主要解决方向问题：

• 谁遇到了问题；
• 他们现在怎样解决；
• 失败会付出什么代价；
• 最小切入口是什么；
• 哪些能力不应该进入产品。

正式产品规划则要继续向下，把方向变成可以执行和验收的规则：

产品讨论：为什么做、为谁做、边界在哪里
  ↓
产品规划：用户怎样完成任务、每一步遵守什么规则
  ↓
技术验证：外部条件能不能支撑这些规则
  ↓
工程架构：系统怎样实现并保护这些规则
  ↓
开发计划：按照什么顺序交付和验证

如果跳过产品规划，架构和代码就会被迫替产品做决定。

例如，“匹配到了就提醒”听起来已经很明确，但真正实现时仍然会遇到很多问题：

• 车主和乘客是不是都要提醒；
• 同一个候选发送两条提醒，算一个事件还是两个事件；
• 其中一方发送失败，候选是否仍然成立；
• 多个候选同时出现，是否会连续轰炸用户；
• 到了停止匹配的时间，旧候选还能不能联系。

这些不是数据库或框架应该决定的事情，而是产品规则。

先明确这份规划负责什么

AI 很容易在一份产品文档中顺手加入技术架构、数据库表、接口字段、开发排期和远期版本。

看起来很完整，实际会让不同阶段混在一起。

这次我先给正式产品规划划定职责。它负责定义：

• 产品服务谁、解决什么问题；
• 第一个受控试用版本做什么、不做什么；
• 用户必须能够走通哪些流程；
• 匹配、提醒、联系方式交换和状态更新遵守什么规则；
• 功能怎样验收；
• 哪些内容仍然只是未经验证的假设；
• 哪些技术条件必须在进入工程架构前关闭。

它不负责选择编程语言、数据库和部署平台，也不生成任务看板。

这样做不是增加文档数量，而是防止一个尚未确认的产品判断过早变成工程事实。

同一份文档中要分清三种结论

正式产品规划最重要的工作之一，是继续区分事实、决定和假设。

已有证据支持的事实

• 两个微信群属于同一个小区，只是因为人数较多拆成两个群；
• 群里存在重复发布和“刚才的车还有吗”一类追问；
• 有车主和乘客几乎每天沿固定方向通勤；
• 双方经常在不同时间发布消息；
• 匹配不到时，用户会改乘更贵或更慢的交通方式；
• 最终联系已经习惯在微信中完成。

产品负责人作出的决定

• 第一个版本只服务当前社区；
• 两个微信群共享一个站内社区和匹配池；
• 用户使用邀请码、账号和密码注册；
• 信息使用结构化字段，不提供自由文本说明；
• 联系方式默认不公开；
• 候选出现时同时提醒双方；
• 不把匹配成功率作为首轮试用的通过门槛。

仍然没有用户证据的假设

• 用户愿意点击群链接并注册；
• 用户愿意关注提醒服务并填写喵码；
• 用户能够理解时间窗口和匹配截止时间；
• 用户接受一方发起后双方同时交换微信号；
• 用户愿意在微信沟通后返回系统更新状态。

产品负责人可以在证据不足时作出试用决定，但不能把决定改写成“用户已经接受”。

这也是本项目在暂时无法完成用户访谈时采用的处理方式：允许规划继续推进，同时把证据缺口原样保留。

第一个版本不是功能最少，而是闭环最小

正式规划把首版定义成一个受控试用版本。

它要完成的核心过程是：

社区成员发布结构化出行信息
  → 系统持续寻找可能同路的对象
  → 新候选出现时提醒双方
  → 一方发起双向微信号交换
  → 双方回到微信沟通
  → 用户更新信息和联系结果
  → 到匹配截止时间仍没有结果时收到提醒

为了让这个过程真的走通，首版需要包含账号、发布、查找、候选、提醒、联系方式交换、座位、状态和最小管理能力。

与此同时，仍然明确排除：

• 在线支付和车费结算；
• 报价、抢单和派单；
• 地图导航与实时位置；
• 站内聊天；
• 运输履约和担保；
• 自动周期发布；
• 复杂路线规划；
• 面向公开互联网的注册和搜索。

这里的“最小”不是页面最少，而是没有缺口的最小闭环。

真正困难的是把自然语言变成没有歧义的规则

初稿生成后，我没有直接接受，而是逐项审阅。

这轮审阅暴露的问题很有代表性。很多句子单独看都合理，放在一起却会互相冲突。

登录账号不能变成联系方式泄露通道

产品允许用户使用自定义用户名，也允许登录账号与微信号相同。

如果页面直接展示登录账号，用户即使没有发起联系方式交换，也可能看到对方微信号。这样会绕过最重要的隐私规则。

最终决定是：

• 登录账号永远不向其他社区成员展示；
• 交换联系方式前只显示“车主”或“乘客”和本条信息的短编号；
• 短编号不能跨多条信息稳定追踪同一个人；
• 合法交换后只显示微信号，仍然不显示登录账号。

“前端不显示微信号”还不够，接口响应、页面源码、分享预览和日志也不能包含它。

时间窗口和匹配截止时间必须分开

最初使用的名称是“最晚等待时间”。这个词很容易和“最晚什么时候可以出发”混在一起。

讨论中曾经出现过这样的例子：

可出发：08:05–08:35
最晚等到：08:20

它可以解释成“08:20 前必须找到同行对象，但实际可以到 08:35 再出发”，逻辑上并非完全错误，用户却很难自然理解。

因此，最后把这个字段改名为“匹配截止时间”：

到这个时间后不再产生新候选，并提醒用户考虑其他出行方式。

普通发布的默认规则是：

• 用户填写一个预计时间；
• 系统生成前后各 15 分钟的可出发时间窗口；
• 匹配截止时间默认是预计出发前 15 分钟；
• 用户可以在截止前修改。

针对群里真实存在的“现在随时”，又增加了一个单独的快捷规则：

选择“现在出发”
  → 可出发时间：当前至 15 分钟后
  → 匹配截止时间：当前时间后 15 分钟
  → 页面保存具体时刻，不保存会不断变化的“现在”

用户延长时间窗口时，截止时间默认一起延长，也可以单独提前。

地点只负责发现大致同路的人

群里的路线一般使用小区、园区和道路片区，例如万科、悦城、软件新城、环普和中软。

产品没有必要采集楼栋、门牌号和具体上下车点。

首版中的地点只表示社区约定的大范围区域。系统只判断两条路线是否值得联系，具体在哪里上车、在哪里下车，仍然由双方回到微信沟通。

这既符合原来的使用习惯，也减少了不必要的位置隐私。

信息交换以后不能悄悄改变路线

如果双方已经交换微信号，发布者又把时间和路线改成完全不同的内容，另一方看到的就不再是当初决定联系的信息。

最终规则是：

• 第一次交换联系方式前，可以修改日期、时间和起终点，修改后重新计算候选；
• 第一次交换后，类型、日期、时间窗口、起点和终点锁定；
• 尚未到达的匹配截止时间、合法座位数和状态仍然可以修改；
• 路线或时间发生重大变化时，必须取消原信息并重新发布；
• 已经披露的微信号无法撤回，原链接继续展示最新取消状态。

“已满员”也需要区分原因

车主可能因为站内双方确认同行而坐满，也可能已经在微信群或微信中找到其他乘客，然后手动标记满员。

如果系统不区分两种来源，一名站内乘客取消后，系统可能错误地把一个实际上仍然满员的车重新开放。

因此，规划区分：

• 系统满员：确认座位占满后自动发生，座位释放时可以自动恢复；
• 手动满员：车主因为站外情况主动设置，不能自动恢复；
• 手动满员只有车主重新填写可用座位并明确开放后才能恢复；
• 已关闭表示本次不再寻找，不能重新开放。

自由文本不是首版必须能力

初稿原本保留了可选说明，后来审阅发现它会产生一个新的隐私缺口。

用户可能在说明中填写微信号、手机号、门牌号或具体上下车位置，然后这些内容又被复制到微信群文案和分享页面。

自由文本不参与匹配，核心价值有限，因此首版直接取消。

如果真实使用证明需要表达“携带儿童”“只到某个园区门口”等情况，可以以后增加受限制的结构化选项，而不是提前开放一个无法控制的输入框。

一个候选不等于只有一次发送

新候选产生时，车主和乘客都应该收到提醒。

但系统不能因为向两个人发送了两条消息，就记录成两个候选。

最后确定：

• 一个候选只创建一个业务事件；
• 车主和乘客分别记录自己的发送结果；
• 一方发送失败不影响另一方；
• 没有微信提醒渠道的一方仍能看到站内提醒；
• 即时提醒上限按“用户 + 出行信息”分别计算，更多候选合并成摘要。

这些规则以后会影响数据结构和后台任务，但此时只定义产品事实，还没有提前决定怎样实现。

为什么没有把匹配成功率当成首轮门槛

产品规划一度把“双方确认同行”当作最重要的指标，并准备进一步设置匹配成功率目标。

继续讨论后发现，这个判断过度关注最终结果。

邻行只负责信息沟通，并不控制当天有多少车主、路线是否一致、双方最后是否改变计划。用户也可能已经在微信中约好，却忘记回系统确认。

因此，首轮试用更应该验证：

• 用户能否顺利发布和查找；
• 信息是否不再随着群消息消失；
• 候选和匹配截止提醒能否及时送达；
• 联系方式交换是否可用；
• 失效信息能否保持最新；
• 重复发布和重复追问是否减少。

匹配率、联系方式交换率和双方确认率仍然记录，但不设置成通过门槛。

这不是放弃数据，而是避免用产品无法控制的结果过早否定产品。

把产品规则变成可以测试的场景

如果正式规划只写“支持注册”“支持匹配”“保护隐私”，后续开发仍然可以用很多不同方式解释。

因此，这次规划最终整理出 56 个产品验收场景。

例如：

• 无效或停用的邀请码不能注册；
• 一个微信群来源的邀请码加入后，可以看到另一个群成员发布的信息；
• 同日期、地点兼容且时间重合的信息可以形成一个候选；
• 已经匹配截止的信息不能产生新候选；
• 新候选同时提醒车主和乘客，但只创建一个候选业务事件；
• 非候选、跨社区或受限账户不能交换微信号；
• 最后一个座位不能被两个配对同时确认；
• 登录账号不能出现在列表、详情、分享文案和交换结果中；
• 取消信息不会撤回已经发生的联系方式披露；
• “现在出发”必须保存具体时刻，而不是保存“现在”两个字。

这些场景还不是自动测试代码，但它们会成为以后架构设计、测试驱动开发和浏览器验收共同引用的含义。

如果产品文档、自动测试和页面验收分别使用不同规则，测试再多也无法证明同一个产品已经完成。

审阅不是检查错别字，而是寻找不同解释

这次产品规划初稿有七百多行。篇幅长并不等于质量高。

真正有效的审阅不是问“文档是否完整”，而是尝试从不同角色和状态寻找冲突：

• 如果登录账号就是微信号，普通页面会不会泄露它；
• 如果已经交换联系方式，发布者还能不能改变路线；
• 如果车主手动满员，座位释放后是否应该自动开放；
• “现在随时”怎样变成不会变化的时间数据；
• 自由文本会不会绕过隐私边界；
• 双方提醒怎样避免产生重复候选；
• 方向筛选是否和起终点筛选重复。

每发现一个问题，都先讨论产品含义，再更新核心流程、状态规则、验收场景和决策记录。

只修改其中一处，会让同一份文档内部继续保留两个答案。

内容审阅完成，为什么仍然只是有条件通过

产品内容审阅完成后，我按照节点收尾模板再次检查：

• 这个节点的目标是否完成；
• 正式产品规划阶段是否完成；
• 哪些证据已经存在；
• 下一节点可以做什么；
• 哪些事情仍然不能宣布完成。

最后得到的结论是 CONDITIONAL GO，意思是“有条件继续”。

具体来说：

• 正式产品规划内容审阅节点已经完成；
• 产品规划阶段仍在进行；
• 可以进入喵提醒接口验证；
• 还不能进入工程架构和编码；
• 不能声称喵提醒已经可用；
• 不能声称微信内置浏览器流程已经通过；
• 不能声称用户已经接受注册、提醒和联系方式交换。

节点完成不等于阶段完成。把两者分开，才能既保存已经完成的成果，又不掩盖剩余风险。

用过某个接口，也不等于当前 Gate 自动通过

我以前在其他项目中使用过喵提醒，确认它确实能够正常发送消息。

这是一条有价值的历史证据，说明方案不是完全未知，也可以缩小这次验证的范围。

但邻行需要验证的不只是“能不能发送一条消息”，还包括：

• 当前接口和认证方式是否仍然有效；
• 两个不同喵码是否都能收到提醒；
• 无效喵码、频率限制、超时和服务错误怎样返回；
• 网络结果不确定时怎样处理重试和重复送达；
• 当前额度、使用条款和隐私条款；
• 失败时怎样明确降级到站内提醒。

因此，已有经验可以让 Gate A 更有针对性，但不能替代当前项目的验证记录。

一套可以复用的产品规划方法

如果你也准备把一次产品讨论整理成正式规划，可以使用下面的顺序：

读取已经确认的需求发现事实源
  → 明确产品规划负责和不负责的内容
  → 分开事实、产品决定和未验证假设
  → 定义首版核心闭环与永久边界
  → 把自然语言拆成时间、权限、状态和失败规则
  → 为每条关键规则编写验收场景
  → 从隐私、修改、并发和异常路径审阅冲突
  → 同步所有受影响章节
  → 生成节点检查点
  → 保存当前状态，再进入外部技术验证

AI 在这里最有价值的作用，不是一次生成更多内容，而是不断用反例追问规则是否真的完整。

开发者仍然需要决定哪些复杂度值得进入首版，哪些指标真的代表价值，以及什么证据才允许项目继续。

当前真实进度

到第三篇结束时，仓库中的真实状态是：

• Office Hours 产品讨论已经完成；
• 正式产品规划内容审阅已经完成；
• 21 项重要产品决定已经记录；
• 56 个产品验收场景已经形成；
• 节点检查点和 README 已经同步并提交；
• 产品规划状态是 REVIEWED / CONDITIONAL GO；
• 用户访谈仍未完成；
• 喵提醒接口和微信内置浏览器仍未验证；
• 工程架构、页面设计、开发计划和业务代码都还没有开始。

下一步是 Gate A：喵提醒接口验证。它完成后还要验证微信内置浏览器，两个技术条件都关闭以后，才能最终批准产品规划并进入工程架构。

后续调整：这段话保留了第三篇完成时的真实计划。Gate A 通过后，产品负责人提供了另一个现有项目在微信内置浏览器正常使用的经验，因此取消一次性的前置 Gate B 页面。邻行自身的微信真机验收没有取消，而是移到首条可运行闭环完成后、正式试用前执行。

最后

从一个想法走到正式产品规划，最容易产生的错觉是：文档已经很长，所以需求一定已经清楚。

实际上，真正决定规划质量的不是行数，而是这些问题有没有明确答案：

• 谁能做什么；
• 什么时间发生什么；
• 哪些状态可以恢复；
• 信息改变后谁会受到影响；
• 隐私数据会出现在哪里；
• 失败时产品怎样降级；
• 什么证据才允许进入下一步。

AI 可以很快生成第一稿。

把第一稿变成可以指导架构、开发和测试的事实源，仍然需要逐项审阅、真实决定和明确门禁。

下一篇将记录怎样在写业务代码之前验证喵提醒和微信内置浏览器，避免把无法控制的外部条件留到开发后期才发现。

附录：相关工具与仓库

gstack

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

前一阶段使用了其中的 office-hours 产品讨论技能。后续还会使用浏览器和质量检查能力完成真实环境验证。

dev-harness

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

本阶段使用节点检查点和 Git 工作流保存产品规划、README 状态与下一节点交接。正式开发计划和任务看板仍要等产品规划最终批准和架构完成后生成。

UI UX Pro Max

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

本阶段尚未进入正式页面设计。产品流程和技术 Gate 稳定后，再用它设计移动端页面、表单、状态提示和无障碍体验。