# 阶段划分研讨会议记录

## 项目：洒渔镇苹果产业供需对接平台
## 主题：需求阶段划分与各阶段详细设计

## 参与角色（6人，每人1票）

| 角色 | 代号 | 核心关注 |
|------|------|---------|
| 产品经理 | PM | 业务价值、用户可用性、交付节奏 |
| 架构师 | ARCH | 技术依赖、基础设施、可扩展性 |
| 用户体验师 | UX | 用户旅程完整性、交互连贯性 |
| 后端开发 | BE | 开发工作量、并行度、技术风险 |
| 测试工程师 | QA | 可测试性、回归风险、验收标准 |
| 安全专家 | SEC | 安全基础设施、权限控制时机 |

## 投票规则
- 每人1票（支持/反对/弃权）
- **通过门槛：≥5票支持**（>n/2+1=4）

## 需求总览（来自 requirements-specification.md）

**P0功能（MVP核心，28个功能点）**：
- 公共：微信登录+身份路由+兜底绑定
- 果农：今日行情、找工人、发布招工（免审核+关键词标记）、找客商、我的名片（视频/照片）
- 工人：找活推荐、报名通知、状态管理（自动恢复+信用机制）
- 客商：货源筛选、联系授权（7天有效期）
- 后台：角色管理、数据导入（硬编码+预览）、名片审核、待复核列表、行情管理、数据大屏

**P1功能（12个功能点）**：
- 果农：招工记录、买农资
- 工人：工作记录、我的信息
- 客商：收购偏好
- 农资：店铺信息维护
- 后台：操作日志、短信配置、用户信息修正、招工巡查、流量指标、产业地图、报表导出

**P2功能（3个功能点）**：关于我们、举报处理

**数据表（15张）**：sys_user、user_identity、grower_profile、worker_profile、recruit_info、buyer_profile、phone_unlock_record、call_log、sms_daily_limit、market_price、supplier_shop、audit_log、operation_log、worker_apply、complaint

**接口（约25个）**：/api/wx/* + /api/admin/*

---

## 议题一：阶段数量与划分策略

### 问题
1. 划分为几个阶段？每个阶段多长？
2. 划分依据：按功能模块 vs 按技术层次 vs 按用户旅程？

### 第一轮发言

**PM**：建议按用户价值交付节奏划分。用户最关心的是"能不能用起来"，而不是"后端架构完不完整"。我建议3个阶段：
- 阶段一：能登录、能看到数据（基础可用）
- 阶段二：能发布、能对接（核心交易）
- 阶段三：能统计、能管理（运营闭环）

**ARCH**：反对按纯功能模块划分，因为有技术依赖。比如：没有用户系统就没有身份路由，没有身份路由就没有果农/工人功能。建议按技术层次+功能模块结合：
- 阶段一：基础设施+用户体系+后台数据导入（没有用户数据，小程序端无人可用）
- 阶段二：四端核心功能（果农/工人/客商/农资的基础功能）
- 阶段三：运营功能+数据大屏+P1功能

**UX**：同意ARCH。从用户旅程角度，用户的第一步是"登录→看到自己的身份→看到有用的信息"。如果阶段一只有登录没有数据，用户登录后看到空页面会流失。所以阶段一必须包含数据导入+今日行情+基础浏览功能。

**BE**：同意ARCH的3阶段划分。补充工作量评估：
- 阶段一：约40%工作量（基础设施+用户体系+数据导入+行情）
- 阶段二：约40%工作量（四端核心功能）
- 阶段三：约20%工作量（运营+统计+P1）

**QA**：同意3阶段。每个阶段都需要有可测试的交付物。阶段一的验收标准：管理员能导入数据、用户能登录并看到身份。阶段二的验收标准：四端核心流程跑通。阶段三的验收标准：数据大屏可用、报表可导出。

**SEC**：同意3阶段。安全基础设施必须在阶段一完成——手机号加密、权限框架、操作日志。不能等到阶段二再补安全，否则代码需要大量重构。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 3阶段按用户价值交付，节奏合理 |
| ARCH | ✅ 支持 | 技术依赖+功能模块结合划分 |
| UX | ✅ 支持 | 用户旅程完整，阶段一即可用 |
| BE | ✅ 支持 | 工作量分布合理（40/40/20） |
| QA | ✅ 支持 | 每阶段有可测试交付物 |
| SEC | ✅ 支持 | 安全基础设施前置到阶段一 |

**结果：6/6 ≥ 5，通过 ✅**

### 决议
- **3个阶段**，按技术层次+功能模块+用户价值结合划分
- 阶段一：基础设施+用户体系+数据导入+基础浏览（40%工作量）
- 阶段二：四端核心功能（40%工作量）
- 阶段三：运营功能+统计+P1补充（20%工作量）

---

## 议题二：阶段一详细设计

### 问题
阶段一应包含哪些具体功能？依赖关系如何？验收标准？

### 第一轮发言

**PM**：阶段一的目标是"平台可用"——管理员能录入数据，用户能登录并看到有用信息。建议包含：
1. 微信登录+身份路由
2. 后台：系统管理（角色/账号/字典）+ 数据导入
3. 后台：行情管理（配置今日行情）
4. 小程序：首页展示（今日行情+金刚区框架）
5. 后台：名片审核（果农视频/照片审核）

**ARCH**：同意PM。补充技术依赖链：
```
数据库建表 → 用户体系(sys_user+user_identity) → 微信登录 → 身份路由
           → 后台管理框架(角色/权限) → 数据导入 → 行情配置
           → 小程序首页(行情展示)
```
阶段一必须完成数据库建表（全部15张表），即使部分表暂时没有数据。

**BE**：全部15张表在阶段一建？会不会过度设计？

**ARCH**：不是过度设计，是避免后续阶段改表结构。表结构在需求规格中已经定义清楚了，一次性建好，后续阶段只做INSERT/UPDATE，不做ALTER TABLE。改表结构的成本远高于提前建表。

**UX**：阶段一的用户体验重点：
1. 登录流程顺畅（微信一键→身份选择→首页）
2. 首页信息有价值（今日行情让用户觉得"这个平台有用"）
3. 金刚区展示4个入口，但部分入口可以显示"即将开放"灰态

**QA**：阶段一验收标准：
1. 管理员能登录后台
2. 管理员能通过Excel导入果农/工人/客商/农资数据
3. 管理员能配置今日行情
4. 用户能微信登录
5. 用户能选择身份进入对应首页
6. 首页展示今日行情
7. 名片审核流程可用

**SEC**：阶段一安全清单：
1. 手机号AES加密存储+phone_hash索引
2. 权限框架（RBAC角色+URL拦截）
3. 操作日志（登录/导入/审核记录）
4. 接口数据脱敏

### 第二轮交锋

**PM**：名片审核放在阶段一还是阶段二？果农上传视频/照片是阶段二的功能，审核放在阶段一是否太早？

**BE**：建议阶段一只做审核框架（审核列表+通过/驳回操作），不包含视频上传。果农的视频上传功能放在阶段二。阶段一的审核对象可以是Excel导入时的"待审核"数据。

**ARCH**：同意BE。阶段一的审核有两个用途：
1. Excel导入的数据可能需要审核确认
2. 为阶段二的名片审核/招工审核预建框架

**QA**：那阶段一的审核对象是什么？

**PM**：建议阶段一审核对象是"导入的用户数据"——录入员导入Excel后，审核员确认数据无误再入库。这样阶段一就有完整的审核流程可测试。

**BE**：这个方案好。导入→预览→审核→入库，流程完整。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 目标明确，用户可用 |
| ARCH | ✅ 支持 | 技术依赖链清晰，全量建表合理 |
| UX | ✅ 支持 | 登录+首页体验完整 |
| BE | ✅ 支持 | 工作量可控，审核框架复用 |
| QA | ✅ 支持 | 验收标准明确可测 |
| SEC | ✅ 支持 | 安全基础设施前置 |

**结果：6/6 ≥ 5，通过 ✅**

### 阶段一决议

**阶段名称**：基础设施与用户体系
**目标**：平台可用——管理员能录入数据，用户能登录并看到有价值的信息

**功能清单**：

| 模块 | 功能 | 优先级 | 说明 |
|------|------|--------|------|
| 数据库 | 全量建表（15张） | P0 | 一次性建好，避免后续ALTER |
| 后台-系统管理 | 角色管理 | P0 | 超级管理员/录入员/审核员/运维 |
| 后台-系统管理 | 账号管理 | P0 | 管理员CRUD+权限分配 |
| 后台-系统管理 | 字典管理 | P0 | 品种/工种/农资种类/行政区划 |
| 后台-系统管理 | 操作日志 | P0 | 登录/导入/审核记录 |
| 后台-数据导入 | Excel模板下载 | P0 | 4类模板 |
| 后台-数据导入 | Excel上传+预览 | P0 | 预览（总行数/有效/错误/重复） |
| 后台-数据导入 | 数据校验+去重 | P0 | 手机号校验、手机号+身份去重 |
| 后台-数据导入 | 确认入库 | P0 | ≤100行同步，>100行异步 |
| 后台-审核中心 | 审核框架 | P0 | 审核列表+通过/驳回+SLA提醒 |
| 后台-审核中心 | 导入数据审核 | P0 | 导入数据需审核确认后生效 |
| 后台-行情管理 | 行情配置 | P0 | 按品种设置价格区间+趋势 |
| 小程序-登录 | 微信登录 | P0 | wx.login→JWT |
| 小程序-登录 | 身份路由 | P0 | 0/1/N个身份路由逻辑 |
| 小程序-登录 | 身份选择页 | P0 | 大卡片列表（≥120px） |
| 小程序-首页 | 今日行情 | P0 | 涨价红/降价绿色块+更新时间 |
| 小程序-首页 | 金刚区 | P0 | 4入口（部分可灰态"即将开放"） |
| 安全 | 手机号加密 | P0 | AES加密+phone_hash索引 |
| 安全 | 权限框架 | P0 | RBAC+URL拦截器 |
| 安全 | 接口脱敏 | P0 | 手机号138****1234 |

**技术依赖链**：
```
数据库建表 → sys_user+user_identity → 权限框架 → 后台管理API
                                              → 微信登录+JWT
          → 全量表结构 → 数据导入(Excel上传/预览/校验/入库)
                      → 审核框架(审核列表/操作)
                      → 行情管理(配置)
                      → 小程序首页(行情展示/金刚区)
```

**验收标准**：
- [ ] 管理员能登录后台管理系统
- [ ] 管理员能通过Excel导入4类用户数据
- [ ] 导入数据预览正确显示有效/错误/重复行
- [ ] 导入数据经审核后生效
- [ ] 管理员能配置今日行情（品种+价格区间+趋势）
- [ ] 用户能微信登录，0/1/N个身份路由正确
- [ ] 小程序首页展示今日行情（涨价红/降价绿色块）
- [ ] 金刚区展示4个入口
- [ ] 手机号数据库存储为密文
- [ ] 接口返回手机号脱敏
- [ ] 操作日志记录登录/导入/审核操作

---

## 议题三：阶段二详细设计

### 问题
阶段二应包含哪些具体功能？四端功能的开发顺序？依赖关系？

### 第一轮发言

**PM**：阶段二的目标是"供需对接"——四端用户能完成核心交易流程。建议按用户旅程顺序开发：
1. 果农端（发布方，先有供给才有需求）
2. 工人端（劳动方，果农招工→工人找活）
3. 客商端（收购方，果农有货→客商找货）
4. 农资端（供应方，最简单，最后做）

**ARCH**：同意PM的顺序。技术依赖链：
```
果农档案(grower_profile) → 招工发布(recruit_info) → 工人报名(worker_apply) → 短信通知
果农名片(视频/照片) → OSS上传 → 审核流程
果农货源 → 客商浏览 → 联系授权(phone_unlock_record) → 拨号(call_log)
```

**BE**：果农端工作量最大（名片含视频上传、招工发布、找工人、找客商），建议拆为两个子阶段：
- 2a：果农核心（名片+招工+找工人）
- 2b：对接功能（工人报名+客商找货+联系授权）

**UX**：同意BE的拆分。用户体验上，果农先完善自己的名片和招工信息，然后工人才能来找活，客商才能来找货。顺序不能反。

**QA**：每个子阶段的验收标准：
- 2a：果农能上传视频/照片到名片、能发布招工、能找到并拨号联系工人
- 2b：工人能报名并短信通知果农、客商能筛选货源并解锁电话

**SEC**：阶段二安全重点：
1. 视频上传安全（EXIF清除、格式校验、大小限制）
2. 拨号日志记录（call_log表）
3. 联系授权有效期控制（7天过期）
4. 短信防骚扰限流（sms_daily_limit表）

### 第二轮交锋

**PM**：BE建议拆为2a和2b，我同意。但2a和2b是串行还是并行？

**ARCH**：建议串行。2a的果农数据是2b的前提——没有果农的招工信息，工人就没东西可报名；没有果农的货源信息，客商就没东西可看。

**BE**：同意串行。但2a和2b内部可以并行——比如2a阶段，果农名片和招工发布可以同时开发，找工人列表也可以同时开发。

**UX**：2a的用户旅程：果农登录→完善名片→发布招工→找工人拨号。2b的用户旅程：工人登录→找活报名→客商登录→找货解锁→拨号。

**QA**：建议2a和2b各有一个独立的验收节点，不要等2b全部做完才验收。2a验收通过后进入2b。

**PM**：同意。那农资端放在哪里？

**ARCH**：农资端功能最简单（店铺信息CRUD），放在2b末尾即可，不需要单独子阶段。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 按用户旅程顺序，逻辑清晰 |
| ARCH | ✅ 支持 | 技术依赖链明确，串行合理 |
| UX | ✅ 支持 | 用户旅程完整连贯 |
| BE | ✅ 支持 | 2a/2b拆分降低单阶段复杂度 |
| QA | ✅ 支持 | 每个子阶段独立可验收 |
| SEC | ✅ 支持 | 安全重点明确 |

**结果：6/6 ≥ 5，通过 ✅**

### 阶段二决议

**阶段名称**：四端核心功能（供需对接）
**目标**：四端用户能完成核心交易流程

#### 阶段2a：果农核心功能

| 模块 | 功能 | 说明 |
|------|------|------|
| 小程序-果农 | 我的名片-信息维护 | 品种/产量/价格/地址 |
| 小程序-果农 | 我的名片-视频上传 | 前端直传OSS，清除EXIF，≤50MB/720p |
| 小程序-果农 | 我的名片-照片上传 | ≤9张/张≤5MB，清除EXIF |
| 小程序-果农 | 我的名片-审核状态 | 待审/已通过/被驳回 |
| 小程序-果农 | 发布招工 | 工种/价格/人数/天数/地点/备注（语音输入） |
| 小程序-果农 | 招工管理 | 下架/重新编辑/历史记录 |
| 小程序-果农 | 找工人-列表 | 工种筛选+距离排序 |
| 小程序-果农 | 找工人-拨号 | 调用拨号接口（记录call_log） |
| 小程序-果农 | 找客商-列表 | 客商信息展示 |
| 小程序-果农 | 找客商-拨号 | 调用拨号接口（记录call_log） |
| 后台-审核 | 名片审核 | 审核果农视频/照片，通过/驳回 |
| 后台-审核 | 待复核列表 | 敏感关键词标记的招工 |
| 安全 | 视频安全 | EXIF清除、格式校验、大小限制 |
| 安全 | 拨号日志 | call_log表记录所有拨号 |

**2a验收标准**：
- [ ] 果农能编辑名片信息（品种/产量/价格/地址）
- [ ] 果农能上传视频到OSS，视频压缩至720p
- [ ] 果农能上传照片（≤9张）
- [ ] 名片提交后进入待审核状态
- [ ] 审核员能审核名片（通过/驳回+原因）
- [ ] 果农能发布招工信息（免审核直接发布）
- [ ] 敏感关键词自动标记，进入待复核列表
- [ ] 果农能下架/编辑招工
- [ ] 果农能按工种筛选工人列表
- [ ] 果农能一键拨号联系工人（记录call_log）
- [ ] 果农能查看客商列表并拨号

#### 阶段2b：工人+客商+农资功能

| 模块 | 功能 | 说明 |
|------|------|------|
| 小程序-工人 | 找活推荐 | 工种匹配+距离排序 |
| 小程序-工人 | 报名 | 点击→短信通知果农→自动忙碌 |
| 小程序-工人 | 防骚扰 | 每天1条限制（sms_daily_limit） |
| 小程序-工人 | 状态管理 | 手动切换+3天自动恢复 |
| 小程序-工人 | 信用机制 | 投诉1警告→2限24h→3锁定 |
| 小程序-客商 | 货源筛选 | 品种/价格/距离 |
| 小程序-客商 | 货源详情 | 种植面积/规格/视频/照片 |
| 小程序-客商 | 联系授权 | 勾选批次→解锁电话（7天有效） |
| 小程序-客商 | 拨号 | 解锁后一键拨号（记录call_log） |
| 小程序-农资 | 店铺信息 | CRUD+一键拨号 |
| 后台-短信 | 短信配置 | 签名+模板管理 |
| 安全 | 联系授权 | phone_unlock_record表+过期控制 |
| 安全 | 短信限流 | sms_daily_limit表+自然日计 |

**2b验收标准**：
- [ ] 工人能看到推荐的招工列表（工种匹配+距离排序）
- [ ] 工人能报名，果农收到短信通知
- [ ] 同一工人每天对同一果农最多1条短信
- [ ] 工人能切换状态（空闲/工作中）
- [ ] 3天无操作自动恢复空闲
- [ ] 工人被投诉3次后状态锁定
- [ ] 客商能按品种/价格/距离筛选货源
- [ ] 客商能查看货源详情（含视频/照片）
- [ ] 客商勾选批次后解锁果农电话（7天有效）
- [ ] 客商能一键拨号（记录call_log）
- [ ] 农资商能维护店铺信息
- [ ] 解锁记录完整存储
- [ ] 短信日志全量记录

---

## 议题四：阶段三详细设计

### 问题
阶段三应包含哪些功能？P1功能的优先级排序？

### 第一轮发言

**PM**：阶段三的目标是"运营闭环"——政府管理部门能监控平台运营、统计数据、导出报表。包含：
1. 数据大屏（宏观概览+撮合指标）
2. 流量指标+产业地图
3. 报表导出
4. P1功能补充（招工巡查、用户信息修正、短信配置等）

**ARCH**：数据大屏需要统计拨号次数、短信条数、供需比等，数据来源是阶段二产生的call_log、sms_daily_limit、worker_apply等表。所以阶段三依赖阶段二的数据积累。

**BE**：数据大屏的技术方案：定时任务每5分钟刷新→Redis缓存。建议先做核心指标（用户总数/活跃/供需比/拨号次数），再做扩展指标（PV/UV/产业地图）。

**UX**：数据大屏的UI设计要政府领导能看懂——大字大图、关键指标醒目、支持按时间筛选。产业地图用热力图展示果农分布。

**QA**：阶段三验收标准：
1. 数据大屏展示核心指标
2. 报表能导出为Excel
3. P1功能全部可用

**SEC**：报表导出是敏感操作，需要二次确认+操作日志。导出的数据必须脱敏。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 运营闭环，政府可用 |
| ARCH | ✅ 支持 | 数据依赖链明确 |
| UX | ✅ 支持 | 大屏UI方向清晰 |
| BE | ✅ 支持 | 技术方案简单可靠 |
| QA | ✅ 支持 | 验收标准明确 |
| SEC | ✅ 支持 | 导出安全已确认 |

**结果：6/6 ≥ 5，通过 ✅**

### 阶段三决议

**阶段名称**：运营功能与数据统计
**目标**：政府管理部门能监控运营、统计数据、管理平台

| 模块 | 功能 | 优先级 | 说明 |
|------|------|--------|------|
| 后台-大屏 | 宏观概览 | P0 | 注册用户总数、今日活跃、供需比 |
| 后台-大屏 | 撮合指标 | P0 | 电话拨打次数、短信条数、有效撮合率 |
| 后台-大屏 | 流量指标 | P1 | PV/UV、名片浏览量 |
| 后台-大屏 | 产业地图 | P1 | 果农分布热力图、客商来源TOP10 |
| 后台-报表 | 数据导出 | P1 | 用户列表/撮合记录/操作日志→Excel |
| 后台-管理 | 招工巡查 | P1 | 查看所有招工，强制下架 |
| 后台-管理 | 用户信息修正 | P1 | 管理员修改用户基础信息 |
| 后台-管理 | 短信配置 | P1 | 签名+模板管理 |
| 后台-管理 | 举报处理 | P2 | 处理用户投诉 |
| 小程序-公共 | 关于我们 | P2 | 平台介绍、联系方式、免责声明 |
| 小程序-果农 | 买农资 | P1 | 分类筛选+店铺列表+一键拨号 |
| 小程序-工人 | 工作记录 | P1 | 报名历史+联系果农 |
| 小程序-工人 | 我的信息 | P1 | 展示姓名/技能/电话 |
| 小程序-客商 | 我的需求 | P1 | 收购偏好维护 |

**验收标准**：
- [ ] 数据大屏展示注册用户总数、今日活跃、供需比
- [ ] 数据大屏展示电话拨打次数、短信发送条数
- [ ] 数据大屏每5分钟自动刷新
- [ ] 管理员能导出用户列表/撮合记录为Excel（脱敏）
- [ ] 管理员能查看所有招工并强制下架
- [ ] 管理员能修改用户基础信息
- [ ] 短信签名和模板可配置
- [ ] 举报处理流程可用
- [ ] 果农能按分类筛选农资店铺
- [ ] 工人能查看报名历史
- [ ] 客商能维护收购偏好

---

## 议题五：各阶段工期估算

### 问题
每个阶段的预估工期？关键路径？

### 第一轮发言

**BE**：基于CRRC项目的开发经验，估算如下：
- 阶段一：约2-3周（数据库+用户体系+后台框架+数据导入+行情+小程序首页）
- 阶段2a：约2-3周（果农名片+视频上传+招工+找工人+找客商+审核）
- 阶段2b：约2周（工人报名+客商找货+联系授权+农资店铺）
- 阶段三：约1-2周（数据大屏+报表+P1功能）

**ARCH**：阶段一是关键路径——所有后续阶段都依赖阶段一的基础设施。建议阶段一投入最多资源，确保质量。

**PM**：总工期约7-10周。建议每个阶段结束时有一个验收节点，业务领导确认后再进入下一阶段。

**QA**：每个阶段的测试时间需要预留——建议每个阶段最后2-3天用于测试和修复。

**UX**：阶段一和阶段二a的UI设计需要提前启动，不能等后端做完再设计。

**SEC**：阶段一的安全review必须在进入阶段二前完成。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 工期合理，验收节点明确 |
| ARCH | ✅ 支持 | 关键路径识别正确 |
| UX | ✅ 支持 | UI设计前置建议合理 |
| BE | ✅ 支持 | 工作量估算可接受 |
| QA | ✅ 支持 | 测试时间已预留 |
| SEC | ✅ 支持 | 安全review节点明确 |

**结果：6/6 ≥ 5，通过 ✅**

### 工期决议

| 阶段 | 工期 | 关键里程碑 | 验收节点 |
|------|------|-----------|----------|
| 阶段一 | 2-3周 | 数据库+用户体系+后台+首页 | 管理员能导入数据，用户能登录看行情 |
| 阶段2a | 2-3周 | 果农核心功能 | 果农能发招工、上传名片、找工人 |
| 阶段2b | 2周 | 工人+客商+农资 | 四端核心流程跑通 |
| 阶段三 | 1-2周 | 运营+统计+P1 | 数据大屏可用，报表可导出 |
| **总计** | **7-10周** | | |

**关键路径**：阶段一 → 阶段2a → 阶段2b → 阶段三（串行依赖）

**并行策略**：
- 阶段一：UI设计与后端开发并行
- 阶段2a：果农名片UI与招工发布后端并行
- 阶段2b：工人端与客商端可并行开发（无强依赖）

---

## 讨论总结

### 阶段划分总览

```
阶段一（2-3周）          阶段2a（2-3周）         阶段2b（2周）          阶段三（1-2周）
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│ 基础设施         │  │ 果农核心         │  │ 工人+客商+农资   │  │ 运营+统计        │
│                 │  │                 │  │                 │  │                 │
│ • 数据库建表     │  │ • 果农名片       │  │ • 工人找活报名   │  │ • 数据大屏       │
│ • 用户体系       │  │ • 视频/照片上传  │  │ • 状态+信用     │  │ • 报表导出       │
│ • 后台管理框架   │  │ • 招工发布       │  │ • 客商找货       │  │ • 招工巡查       │
│ • 数据导入       │  │ • 找工人/客商    │  │ • 联系授权       │  │ • P1功能补充     │
│ • 审核框架       │  │ • 名片审核       │  │ • 农资店铺       │  │ • 举报处理       │
│ • 行情管理       │  │ • 待复核列表     │  │ • 短信配置       │  │                 │
│ • 微信登录       │  │                 │  │                 │  │                 │
│ • 小程序首页     │  │                 │  │                 │  │                 │
│ • 安全基础设施   │  │                 │  │                 │  │                 │
└─────────────────┘  └─────────────────┘  └─────────────────┘  └─────────────────┘
     验收：                验收：                验收：                验收：
     能登录+看行情         能发招工+找工人       四端流程跑通          大屏+报表可用
```

### 投票汇总

| 议题 | 结果 | 票数 |
|------|------|------|
| 阶段数量与划分策略 | ✅ 通过 | 6/6 |
| 阶段一详细设计 | ✅ 通过 | 6/6 |
| 阶段二详细设计 | ✅ 通过 | 6/6 |
| 阶段三详细设计 | ✅ 通过 | 6/6 |
| 工期估算 | ✅ 通过 | 6/6 |