夜雨聆风
“AI 软件开发实战教程”系列第 7 篇：把产品规划、工程架构和页面设计整理成纵向开发任务、状态看板与验收覆盖矩阵，让 TDD 不会变成一堆彼此失联的测试。
到上一篇为止，邻行已经有了三份重要事实源：
产品规划说明首版做什么、为什么做和怎样验收； 工程架构说明事务、并发、权限、后台任务和测试边界； 页面体验说明用户看到什么、怎样操作以及各种状态如何表达。
现在可以开始写代码了吗？
还差一个容易被低估的步骤：把这些横跨几十页的规则拆成可以独立完成、独立验证和独立提交的任务。
如果直接让 AI“按照文档把整个项目实现出来”，常见结果是：
先一次性创建所有数据库模型； 再一次性创建所有页面； 最后补一些测试； 看板显示功能很多，实际没有一条完整流程能运行； 产品规划中的边界散落在代码里，没人知道有没有遗漏。
这次使用 dev-harness-planning 生成计划，但没有把模板填满就算完成。计划必须证明两件事：每个任务能产生一个可运行结果，所有产品验收场景都有唯一负责人。
1. 看板和任务详情为什么要分开
一个计划文档同时写状态、背景、文件、步骤、测试和风险，很快就会变得难以扫描。
邻行把计划分成三层：
Dashboard.md 当前阶段、任务状态、优先级和跳转TaskDetails.md 每个任务的目标、文件、TDD 步骤、验证和提交边界AcceptanceMatrix.md AC-01 到 AC-56 的负责人、证据类型和真实状态看板只回答“现在做到哪里、下一项是什么”。
任务详情回答“这项工作怎样做完”。
验收矩阵回答“哪一条产品规则由谁证明”。
三份文档职责不同，可以避免在多个地方复制同一大段实现说明。任务状态变化时更新看板；测试证据变化时更新验收矩阵；实现步骤只在任务详情维护。
2. 不按技术层拆，而按用户闭环拆
一种常见拆法是：
任务一：设计全部数据表任务二：实现全部后端接口任务三：实现全部前端页面任务四：补自动测试这种拆法对分工看起来整齐，对验证却很不友好。
完成第一项以后，用户还不能做任何事；完成第二项以后，仍然没有可用页面；到了最后才发现表结构或接口不适合真实流程，前面的“完成”需要大面积返工。
邻行改用纵向切片：
社区邀请、登录与私密资料 → 从规则、数据库、服务到真实注册页面一起完成结构化发布、信息大厅与详情 → 从时间规则、发布幂等到移动页面一起完成候选计算、解释与站内事件 → 从匹配纯函数到双方页面一起完成联系方式双向交换 → 从权限、事务、加密快照到复制降级一起完成每项完成后都多出一条可以实际运行的用户能力，也能立即用浏览器检查架构和页面设计是否真的成立。
技术层仍然存在，但它们服务于同一个切片，而不是各自成为“已经完成”的孤岛。
3. 第一个任务不是业务功能
在纵向开发以前，计划保留一个前置任务 V0：工程骨架与验证契约。
它要建立：
Python、Django 和 PostgreSQL 的锁定环境； Web、Worker 和数据库的本地运行方式； 自定义用户模型的第一条迁移； 格式、静态检查、单元、集成和浏览器测试； 可注入时钟； 不会调用真实第三方的假提醒渠道； setup、quick、test、e2e、check 等统一命令。
V0 不是先搭一套宏大平台。它只负责让后面的每个任务都能以相同方式启动、测试和验收。
例如产品大量依赖截止时刻，如果没有可注入时钟，测试就会靠真实等待或修改系统时间，既慢又不稳定。
又例如最后一个座位依赖 PostgreSQL 行锁，如果测试环境默认偷偷使用 SQLite，测试通过也不能说明并发正确。
验证环境本身是产品正确性的一部分。
4. 每个任务都先写“怎样失败”
任务详情没有只列“实现账号、实现发布、实现匹配”，而是为每项写了 RED、GREEN、REFACTOR。
以联系方式交换为例：
RED 非候选、跨社区、受限账户、失效候选必须拒绝 重复点击和并发点击不能产生两次交换 非参与者和页面源码不能看到微信号GREEN 实现短事务、重新校验、一对一交换和加密快照 双方同时得到对方微信号REFACTOR 模板上下文只装入当前用户有权看到的一方资料 权限判断集中在服务，不散落在页面“先写失败测试”不是追求红色输出本身。
测试必须因为目标能力尚未实现而失败，而不是因为导入路径写错、数据库没启动或测试代码本身报错。确认红灯原因正确以后，才写最小实现让它变绿。
5. 一个任务要同时拥有多个证据层次
不是所有规则都适合用同一种测试。
匹配时间窗口可以用纯函数测试；社区权限需要 HTTP 集成测试；最后一个座位需要 PostgreSQL 双连接并发；复制降级需要浏览器；微信分享和会话保持最终需要真机。
因此任务详情为每项规定证据层次：
纯规则 → 时间、地点、状态、提醒分类服务和数据库 → 幂等、授权、事务、事件一致性HTTP → 登录、跨社区、CSRF、表单和源码Playwright → 两个用户的完整移动页面流程真实设备和外部人员 → 微信 Gate、群管理员、隐私与法律审查越接近用户环境的测试覆盖面越大，但它不能代替更底层的精确规则测试。反过来，单元测试再多也不能证明微信内置浏览器真的可用。
6. 56 个验收场景为什么需要单独矩阵
产品规划已经写了 56 个验收场景。
如果只在任务描述中随手标几个编号，很难发现：
某一条没人负责； 同一条被多个任务都认为由对方负责； 人工 Gate 被写成自动化已通过； 任务完成后没有真实测试路径。
验收矩阵为 AC-01 到 AC-56 每条记录：
场景摘要； 唯一负责人； 计划证据； 当前真实状态。
生成以后做了机器检查：
编号范围：AC-01–AC-56总数：56顺序完整：是重复：0遗漏：0当前自动通过：0最后一行很重要。
计划覆盖了 56 条，不代表实现通过了 56 条。当前状态全部是“未实现”或“等待成品”，这才符合项目事实。
7. “协作任务”和“最终负责人”要分开
一条验收往往跨多个模块。
例如 AC-24 要求第三方提醒失败不能回滚发布、候选或交换，而且一方失败不影响另一方。
候选任务会创建业务事件，交换任务会保存交换事实，提醒任务会处理发送失败。三项都参与，但验收矩阵仍把 K7 提醒任务设为最终负责人。
这样关闭任务时不会出现：
K3：我已经创建事件，剩下不是我的问题K4：交换已经保存，提醒由别人测试K7：上游应该已经保证事务，我只测 HTTP协作关系可以有多个，最终关闭责任只能有一个。
8. 把最危险的测试单独标出来
验收矩阵没有把所有场景都写成“自动测试”。几类证据被明确加粗：
AC-27 最后一个座位：必须在 PostgreSQL 做真实并发； AC-23、AC-39、AC-40：必须主动扫描“不包含”敏感资料； AC-31 到 AC-35：只能由 iOS 和 Android 微信真机最终通过； AC-39：除了代码和备份检查，还需要隐私与法律审查共同关闭。
这能防止自动化系统为了提高通过率，用容易执行但证据不足的测试替换真实要求。
9. 外部 Gate 也要进看板，但不能自动完成
Gate B 和 Gate C 被当作正式任务保留：
G1：微信成品真机验收 状态：等待可运行成品G2：受控试用准备 状态：等待外部人员与合规证据它们有明确输入、步骤和通过条件，却不会在 AI 完成代码后自动变绿。
G1 需要真实 iOS、Android、微信版本和测试群；G2 需要群管理员同意、地点确认、七天基线、试用名单以及隐私和法律意见。
计划可以替这些工作准备记录模板，不能替责任人签字。
10. 看板的状态必须反映事实
邻行统一使用几种状态：
📋 规划中：任务定义完成，代码尚未开始； 🚧 开发中：当前正在执行，而且同时只能有一个； ✅ 已完成：退出条件和证据全部满足； ⏸️ 等待成品/外部：任务定义清楚，但缺少真实输入； 📋 远期：没有真实数据支持现在进入首版。
创建了文件不等于任务完成，测试通过一部分也不等于任务完成，AI 暂时停止更不等于任务受阻。
每个任务完成时必须同时更新：
看板状态； 任务详情中的验证记录； 验收矩阵中的真实证据路径； 节点检查点； 本地 Git 提交。
这让第二天查看项目的人不必从聊天记录猜测实际进度。
11. 计划也要接受自动检查
文档不是代码，但仍然可以做一些确定性验证。
本次计划检查了：
Dashboard 中有 14 个任务； TaskDetails 中有对应的 14 个任务标题； 验收矩阵恰好有 56 行； 编号严格等于 1 到 56； 没有重复； 没有 TBD、TODO、FIXME等模板残留；Markdown 没有明显空白错误。
这不能证明任务拆分一定完美，却能消除链接缺失、编号漏掉和模板没填完这类低级错误。
12. 本节点形成的实际开发顺序
邻行首版最终按这个顺序推进：
V0 工程骨架 → K1 社区访问与私密资料 → K2 发布、大厅和详情 → K3 候选与站内事件 → K4 联系方式交换 → K5 双方反馈与座位 → K6 编辑、截止和状态生命周期 → K7 外部提醒 Worker → K8 删除、审计和社区管理 → K9 完整移动浏览器验收 → K10 部署、恢复和试用数据 → G1 微信真机 → G2 受控试用准备K4 完成以后，登录—详情—交换—复制的首条成品闭环已经存在，可以开始准备微信真机测试；但完整 Gate B 仍等到 K9 页面和浏览器质量收束。
13. 写在最后
一个好计划不是把所有工作都提前写得很详细。
它应该让下一步足够明确，让每条产品规则都有负责人，让不同证据不会互相冒充，也让远期想法不会偷偷混进首版。
现在邻行的下一步已经非常具体：执行 V0，先写配置和健康检查的失败测试，建立 PostgreSQL 与统一验证命令。
从这一刻开始，后续教程会进入真正的 TDD 开发。
文章不会只展示最后的绿色测试，还会记录：第一条测试为什么失败、最小实现怎样让它通过、重构改变了什么、浏览器看到了什么，以及还有哪些真实 Gate 不能由 AI 关闭。
14. 本篇验证摘要
计划按用户可完成的纵向流程拆分，而不是按模型、页面和接口横向切块； 每项任务都记录产品规则、第一条失败测试、实现范围和完成门禁； 56 条验收场景分别标注负责人、自动证据、浏览器证据或人工验证要求； PostgreSQL 并发、微信真机和真实用户接受度不会被普通单元测试代替； 看板允许“部分通过”和“环境待验”，避免任务完成被误写成产品已上线。
15. 附录：相关工具与仓库
15.1 gstack
仓库：garrytan/gstack 地址：https://github.com/garrytan/gstack
15.2 dev-harness
仓库：Dev-Wiki/dev-harness 地址：https://github.com/Dev-Wiki/dev-harness
15.3 UI UX Pro Max Skill
仓库：nextlevelbuilder/ui-ux-pro-max-skill 地址：https://github.com/nextlevelbuilder/ui-ux-pro-max-skill