sayu-app/docs/phase-planning-discussion.md

阶段划分研讨会议记录

项目：洒渔镇苹果产业供需对接平台

主题：需求阶段划分与各阶段详细设计

参与角色（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