# 需求研讨会议记录 V2

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

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

| 角色 | 代号 | 核心关注 |
|------|------|---------|
| 产品经理 | PM | 需求完整性、业务合理性、用户价值、优先级 |
| 架构师 | ARCH | 技术可行性、系统架构、可扩展性、技术选型 |
| 用户体验师 | UX | 适老化、交互流程、用户痛点、操作效率 |
| 后端开发 | BE | 实现复杂度、性能风险、开发成本、可维护性 |
| 测试工程师 | QA | 可测试性、边界场景、数据一致性、回归风险 |
| 安全专家 | SEC | 数据安全、隐私合规、权限控制、攻击面 |

## 投票规则
- 每人1票（支持/反对/弃权）
- **通过门槛：≥5票支持**（6人中至少5人同意，>n/2+1=4）
- 弃权不计入有效票，但弃权者须说明顾虑
- 未通过的议题需修改方案后重新投票

## 功能清单原文摘要（共45个功能点）

**小程序端**：公共基础（登录/身份路由）、果农端（行情/找工人/招工/找客商/农资/名片）、工人端（找活/报名/状态）、客商端（找货/联系授权）、农资端（店铺）
**后台管理端**：系统管理、数据导入、审核中心、数据大屏
**非功能性**：适老化、性能、安全、兼容性

---

## 议题一：用户身份与登录体系

### 问题
1. 微信登录+手机号唯一标识是否可靠？
2. 多身份数据模型设计？
3. 身份路由匹配逻辑？

### 第一轮发言

**PM**：微信登录+手机号是最佳方案。洒渔镇果农多为中老年人，微信是他们唯一会用的APP。手机号作为唯一标识，后台Excel导入也用手机号做主键，保持一致性。支持。

**ARCH**：同意PM。数据模型建议`sys_user`存基础信息（openid/phone/nickname/avatar），`user_identity`存身份关联（user_id/identity_type/status）。关联表比单表多角色字段灵活得多——一人多职在农村很常见，关联表可以无限扩展身份类型。

**UX**：支持。微信一键登录对中老年用户最友好，无需记密码。身份选择页用大卡片+大字体展示，每个身份一张卡片，点击进入对应工作台。建议卡片尺寸≥120px高度，方便手指点击。

**BE**：方案本身没问题，但我有一个必须解决的问题：微信手机号获取需要用户主动授权。如果用户拒绝授权怎么办？需要兜底方案。我建议：拒绝后弹窗提示"需要手机号才能使用"，同时提供"联系村委会"入口，管理员后台手动绑定。

**QA**：同意BE的顾虑。补充测试角度：多身份场景下的数据隔离必须验证——果农发布的招工信息，切换到工人身份后不应可见。另外，手机号格式校验需要覆盖：正常号、虚拟号、国际号（虽然概率低）。

**SEC**：支持方案，但有硬性要求：手机号必须AES加密存储，数据库不能存明文。查询时用phone_hash（SHA256）做精确匹配，接口返回时脱敏（138****1234）。这是合规要求，不能妥协。

### 第二轮交锋

**PM**：SEC说的加密存储会影响查询性能吗？

**ARCH**：不会。phone_hash建唯一索引，查询走索引，性能和明文查询一样。加密存储只是增加了一层安全，不影响功能。

**BE**：那我改为支持。但补充一点：手机号变更（换号）场景，管理员后台可修改，不需要用户自助——低频操作，管理员处理即可。

**QA**：数据隔离的问题，ARCH能确认技术方案吗？

**ARCH**：确认。所有业务表都带`user_identity_id`字段，查询时强制加`WHERE user_identity_id = ?`条件，由拦截器统一处理。果农身份查不到工人数据，反之亦然。

**QA**：明确了，改为支持。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 业务合理，降低门槛 |
| ARCH | ✅ 支持 | 关联表模型可扩展，phone_hash索引性能无损 |
| UX | ✅ 支持 | 用户体验最优，大卡片交互友好 |
| BE | ✅ 支持 | 兜底方案（管理员绑定）可接受 |
| QA | ✅ 支持 | 数据隔离方案明确，边界case可控 |
| SEC | ✅ 支持 | AES加密+phone_hash查询已确认 |

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

### 决议
1. 微信登录+手机号唯一标识，拒绝授权时引导联系村委会后台绑定
2. `sys_user`（基础信息）+ `user_identity`（身份关联），支持一人多职
3. 手机号AES加密存储，phone_hash(SHA256)建唯一索引用于查询
4. 身份路由：手机号精确匹配→0个提示联系村委会，1个直接进入，N个展示选择页
5. 数据隔离：所有业务表带`user_identity_id`，拦截器强制加条件

---

## 议题二：果农端核心功能方案

### 问题
1. "今日行情"数据来源和更新频率？
2. "找工人"距离计算方案？
3. "我的名片"视频上传技术方案？
4. 招工信息是否需要审核？

### 第一轮发言

**PM**：今日行情由政府后台手动配置，权威可控，每日更新。招工信息建议免审核直接发布——果农发布招工是高频操作，审核会增加等待时间，降低使用意愿。通过举报机制事后管控。

**BE**：反对免审核。完全免审核会导致虚假招工泛滥——发布虚假高薪信息吸引工人电话骚扰，或者发布不当内容。至少做关键词自动过滤，敏感词拦截，非敏感词放行。开发成本不高，一个正则匹配就行。

**PM**：关键词过滤误杀率怎么控制？比如"高价急招"可能被误判为敏感词？

**BE**：敏感词库只包含明确违规词（色情/赌博/政治等），不包含业务词汇。"高价急招"不会被拦截。拦截后不直接拒绝，而是标记为"待复核"，人工审核。这样既不误杀，又能拦截明确违规内容。

**UX**：BE的方案比完全免审核更好。果农发布后立即可见（不等待审核），但违规内容会被标记后人工复核。体验上和免审核一样流畅，但安全性更好。支持折中方案。

**ARCH**：距离计算我建议用地址而非GPS。农村地区GPS信号不稳定，果农也不习惯开定位。方案：果农填写果园地址（精确到村），后台首次录入时地理编码获取经纬度存储，查询时用Haversine公式计算距离。简单可靠。

**BE**：同意ARCH。经纬度只需计算一次，存储后查询性能好。GPS方案需要持续获取位置，复杂度高且不稳定。

**SEC**：视频上传有安全风险。建议：后端中转（不直传OSS，便于统一管控），限制≤50MB/MP4/MOV，后端压缩至720p/2Mbps，清除EXIF元数据（防止位置泄露）。照片限制：单次≤9张，单张≤5MB。

**QA**：SEC说的EXIF清除很重要。补充测试边界：超大文件上传（正好50MB/超过50MB）、格式异常（伪装扩展名）、网络中断。建议上传前前端预校验格式和大小。

### 第二轮交锋

**PM**：BE的关键词标记+人工复核方案可以接受。那审核员的工作量怎么控制？

**ARCH**：标记的内容不阻塞发布，审核员每天定时处理待复核列表即可。如果量大可以按优先级排序——包含多个敏感词的优先审核。

**BE**：同意。另外建议招工信息支持下架和重新编辑，果农用工结束后可以关闭招工，避免信息过期。

**PM**：这个功能清单里有（P1），纳入。大家对今日行情的更新频率有异议吗？

**UX**：建议行情页面用醒目色块——红色涨价、绿色降价，中老年用户一看就懂。另外建议展示"更新时间"，让用户知道信息的新鲜度。

**PM**：好建议，采纳。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 折中方案平衡效率和安全 |
| ARCH | ✅ 支持 | 地址+经纬度方案简单可靠 |
| UX | ✅ 支持 | 用户体验友好，色块标识直观 |
| BE | ✅ 支持 | 关键词标记方案可接受，开发成本可控 |
| QA | ✅ 支持 | 边界case明确，EXIF清除已确认 |
| SEC | ✅ 支持 | 视频安全措施已确认 |

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

### 决议
1. **今日行情**：政府后台手动配置，按品种设置价格区间，每日更新，涨价红/降价绿色块，展示更新时间
2. **距离计算**：果园地址→地理编码→经纬度存储→Haversine公式计算
3. **视频上传**：后端中转，≤50MB/MP4/MOV，压缩720p/2Mbps，清除EXIF；照片≤9张/张≤5MB
4. **招工发布**：免审核直接发布，敏感关键词自动标记+待复核列表，后台保留强制下架
5. **招工管理**：支持下架、重新编辑、查看历史记录

---

## 议题三：工人端核心功能方案

### 问题
1. "智能推荐"算法方案？
2. 报名通知方案？
3. 工人状态审核机制？
4. 防骚扰限制合理性？

### 第一轮发言

**PM**：智能推荐用技能+距离简单匹配，先跑起来再迭代。报名用短信通知，最直接。工人状态需要审核，防止虚假空闲状态。每天1条防骚扰限制合理。

**BE**：反对状态审核。工人状态变更是高频操作（每天上下工），审核会严重增加操作门槛和后台工作量。建议：工人手动切换状态，3天无操作自动恢复"空闲"。报名后自动变为"忙碌"。这样既保证信息时效性，又不需要人工审核。

**PM**：不审核的话，工人故意标"空闲"来获取更多推荐怎么办？

**BE**：这种行为收益很低——工人标空闲但实际忙碌，接到果农电话后无法响应，果农会投诉，多次投诉后工人信用降低，推荐权重下降。不需要审核，用信用机制约束。

**ARCH**：同意BE。信用机制比审核更有效且更简单。建议：工人被投诉3次以上，状态自动变为"忙碌"且不可手动切换，需联系管理员解除。

**QA**：防骚扰限制的计数逻辑需要明确：按自然日（00:00-23:59）还是24小时？跨天怎么算？同一工人多身份（既是工人又是果农）场景？

**PM**：按自然日计，实现简单。多身份场景下，工人身份和果农身份独立计数——工人身份报名时消耗工人身份的配额。

**SEC**：短信内容需要合规。建议模板："【洒渔用工】[工人姓名]([工种])对您的招工感兴趣，联系电话：[电话]"。电话不能脱敏——果农需要看到工人才能联系，这是核心功能。短信签名需提前报备。

**UX**：关于智能推荐，建议MVP用技能+距离，后续迭代加入"确认率"权重——果农确认用工的工人优先推荐。另外工人首页卡片设计要大字大按钮，工种标签用醒目颜色。

### 第二轮交锋

**PM**：BE的信用机制方案比审核好，我改为支持。但信用机制的细节需要定义。

**ARCH**：建议：被投诉1次→警告，2次→限制报名24小时，3次→状态锁定需管理员解除。投诉由果农发起，审核员判定。

**BE**：同意ARCH。开发成本低——一个`complaint_count`字段+定时任务检查即可。

**QA**：3天自动恢复"空闲"的定义需要明确：是3天没打开小程序，还是3天没切换状态？

**BE**：建议定义为3天没有任何操作（包括打开、报名、切换状态），通过`last_active_time`字段判断。用户每次操作更新该字段，定时任务每天检查一次。

**PM**：方案成熟了，投票。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 信用机制比审核更合理 |
| ARCH | ✅ 支持 | 技术简单，信用机制可扩展 |
| UX | ✅ 支持 | 减少操作摩擦，用户体验好 |
| BE | ✅ 支持 | 自动机制替代审核，开发成本低 |
| QA | ✅ 支持 | 边界case已明确 |
| SEC | ✅ 支持 | 短信合规已确认 |

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

### 决议
1. **智能推荐**：MVP工种匹配+距离排序，后续迭代加入确认率权重
2. **报名通知**：阿里云短信API，模板"【洒渔用工】[工人姓名]([工种])对您的招工感兴趣，联系电话：[电话]"
3. **状态管理**：手动切换+3天无操作自动恢复"空闲"（last_active_time判断），报名后自动"忙碌"
4. **信用机制**：投诉1次警告，2次限制24小时，3次锁定需管理员解除
5. **防骚扰**：同一工人每天对同一果农最多1条短信，自然日计，短信日志全量记录
6. **短信预算**：月均500元/约12500条

---

## 议题四：客商端与农资端方案

### 问题
1. "联系授权"（勾选批次才解锁电话）是否合理？
2. 客商和果农信息匹配方向？
3. 农资端是否需要在线下单？

### 第一轮发言

**PM**：联系授权是核心差异化功能。客商必须勾选具体苹果批次才能看到果农电话，保护果农隐私，同时记录客商偏好。信息匹配单向（客商找果农），农资端暂不做在线下单，MVP先跑通信息展示。

**SEC**：强烈支持联系授权。但解锁状态必须设有效期——建议7天。永久解锁会导致信息泄露后长期有效，果农无法控制自己的联系方式被谁长期持有。7天后需重新勾选，也给果农"被关注"的感觉。

**BE**：同意SEC。解锁记录需要存储：客商ID、果农ID、批次ID、解锁时间、过期时间。查询时判断是否在有效期内。另外建议：同一客商对同一果农的解锁次数需要记录，防止反复骚扰。

**UX**：农资端功能确实太简单。但同意PM，MVP先做信息展示。不过建议预留商品数据模型，后续扩展在线下单时不用重构数据库。

**ARCH**：同意UX。`supplier_shop`表预留`goods`相关字段，如`has_online_order`标记位。数据模型兼容性比功能扩展更重要。

**QA**：联系授权的测试重点：勾选后解锁状态是否持久、过期后是否自动锁定、同一客商多次勾选同一果农是否重复计数、解锁记录的查询准确性。

### 第二轮交锋

**PM**：大家对单向匹配有异议吗？是否需要双向（果农也能找客商）？

**ARCH**：单向匹配实现简单，双向增加复杂度且需求不明确。果农端已经有"找客商"入口，展示客商列表即可，不需要算法匹配。MVP单向，后续根据用户反馈决定。

**UX**：同意单向。果农"找客商"是浏览客商列表，客商"找货"是筛选果农货源，两者交互模式不同，不需要统一匹配算法。

**BE**：农资端不做下单，但建议店铺信息支持"一键拨号"——农资商的核心诉求是被联系，电话是最直接的方式。

**PM**：功能清单里已有联系电话展示，一键拨号是小程序标准能力，纳入。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 业务合理，保护隐私 |
| ARCH | ✅ 支持 | 技术简单，数据模型预留扩展 |
| UX | ✅ 支持 | 流程清晰，一键拨号已纳入 |
| BE | ✅ 支持 | 解锁记录存储方案明确 |
| QA | ✅ 支持 | 测试重点已明确 |
| SEC | ✅ 支持 | 7天有效期方案已确认 |

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

### 决议
1. **联系授权**：客商勾选苹果批次→解锁果农电话，有效期7天，过期需重新勾选
2. **解锁记录**：客商ID、果农ID、批次ID、解锁时间、过期时间，全量存储
3. **信息匹配**：单向（客商→果农），MVP不做双向
4. **农资端**：MVP仅做店铺信息展示+一键拨号，`supplier_shop`表预留`goods`字段
5. **客商偏好**：支持维护收购品种/价格区间/总量/标准

---

## 议题五：后台管理与数据导入方案

### 问题
1. Excel字段映射方案？
2. 大批量导入处理方式？
3. 审核流程设计？
4. 数据大屏技术方案？

### 第一轮发言

**PM**：字段映射建议可配置方案，不同村委提供的Excel格式可能不同。审核单级即可。数据大屏定时刷新。

**BE**：反对MVP做可配置映射。开发成本高，且当前需求明确——就4种模板（果农/工人/客商/农资），字段固定。建议MVP硬编码映射（手机号/电话→phone，姓名→name等），后续迭代为可配置。硬编码半天就能做完，可配置至少需要3天。

**PM**：BE说得有道理。4种模板的字段是固定的，硬编码够用。改为支持硬编码。

**ARCH**：大批量导入（>1000行）需要异步处理，否则前端会超时。建议：≤100行同步导入，>100行异步队列处理，完成后通知。异步用Spring的`@Async`或简单线程池即可，不需要引入MQ。

**QA**：导入的边界case必须覆盖：空行跳过、手机号格式校验、重复数据去重（按手机号+身份类型）、错误行高亮提示。建议导入前先预览，展示：总行数、有效行数、错误行数、重复行数，用户确认后再入库。

**UX**：同意QA的预览方案。预览页面用表格展示，错误行红色高亮，鼠标悬停显示错误原因。用户一目了然。

**SEC**：审核操作必须记录日志——谁审核、审核什么、什么时间、通过/驳回。日志不可篡改（只追加不修改）。另外建议审核SLA≤24小时，超时自动提醒审核员。

**ARCH**：数据大屏用定时任务每5分钟刷新，统计数据缓存到Redis。不需要实时计算，5分钟延迟对政府管理场景完全可接受。核心指标：注册用户总数、今日活跃、供需比、电话拨打次数、短信条数、有效撮合率。

### 第二轮交锋

**BE**：导入的去重逻辑需要明确——"重复"的定义是什么？

**QA**：建议：同一手机号+同一身份类型=重复。同一手机号不同身份不算重复（一人多职）。重复数据预览时标记为"重复"，用户可选择跳过或覆盖。

**PM**：同意QA的定义。另外，审核时效24小时对政府场景合理吗？

**SEC**：政府工作人员可能不在电脑前，24小时SLA是合理的。超过24小时自动发送提醒通知（站内消息或短信）。超过48小时升级提醒给超级管理员。

**PM**：好，采纳。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 硬编码+预览方案实用 |
| ARCH | ✅ 支持 | 异步+定时刷新技术可行 |
| UX | ✅ 支持 | 预览体验好，错误高亮直观 |
| BE | ✅ 支持 | 硬编码开发成本低 |
| QA | ✅ 支持 | 边界case和去重规则已明确 |
| SEC | ✅ 支持 | 日志和SLA已确认 |

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

### 决议
1. **字段映射**：MVP硬编码（4种模板），后续迭代可配置
2. **导入流程**：上传→预览（总行数/有效/错误/重复，错误行红色高亮）→确认入库
3. **批量处理**：≤100行同步，>100行异步+完成通知
4. **去重规则**：手机号+身份类型唯一，重复数据标记，用户可选跳过或覆盖
5. **审核流程**：单级审核，SLA≤24小时（超时提醒），48小时升级给超级管理员
6. **数据大屏**：定时任务每5分钟刷新，Redis缓存，核心指标：用户总数/活跃/供需比/撮合指标

---

## 议题六：非功能性需求确认

### 问题
1. 适老化设计标准？
2. 性能基准？
3. 视频压缩标准？
4. 手机号脱敏规则？

### 第一轮发言

**UX**：适老化是本项目的核心竞争力。建议：正文≥18px(rem)、标题≥24px，媒体查询覆盖320-428px宽度，关键按钮≥88×88px，高对比度配色（白底黑字，关键按钮用大色块），输入处放置麦克风图标支持语音输入，去除复杂动画。

**BE**：18px在小屏机型（如iPhone SE）上可能溢出布局。建议用rem+媒体查询做响应式，而不是固定px。另外10万级数据查询必须建索引——手机号唯一索引、身份类型索引、经纬度复合索引。分页20条/页。

**QA**：适老化测试需覆盖：最小字号在不同机型的显示、大按钮的点击区域、高对比度在强光下的可读性、语音输入的识别率。视频压缩边界：超长视频、低质量源视频、格式异常。

**SEC**：手机号脱敏规则统一为中间4位（138****1234），姓名保留姓氏（张**）。敏感操作（数据导出、批量删除）需管理员二次确认+操作日志。接口返回数据中，小程序端只能看到脱敏数据，后台管理员可看完整数据（需权限）。

**ARCH**：10万级数据MySQL单表可支撑，但需要合理建索引。建议核心索引：手机号唯一索引、身份类型索引、经纬度复合索引（用于距离查询）。分页查询每页20条，支持按创建时间倒序。

**PM**：视频压缩标准：720p、码率2Mbps、时长≤5分钟。超长视频前端截断提示"请压缩至5分钟以内"。

### 第二轮交锋

**BE**：720p压缩后大约多大？

**ARCH**：720p/2Mbps，5分钟视频约75MB压缩后约15-20MB。存储成本可控。建议视频存储在对象存储（如阿里云OSS），数据库只存URL。

**BE**：OSS方案好，减轻服务器压力。但上传流程需要调整——先向后端申请上传凭证，前端直传OSS，上传完成后回调后端记录URL。这样后端不中转视频流，带宽压力为零。

**ARCH**：同意BE的直传OSS方案。比后端中转更优。但EXIF清除需要在前端完成（上传前），或者后端下载OSS文件清除后重新上传。

**SEC**：建议前端清除EXIF——上传前用JS库清除，减少后端处理。后端作为兜底，下载后检查并清除。

**UX**：前端清除EXIF对用户透明，不影响体验。同意。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 标准合理 |
| ARCH | ✅ 支持 | 直传OSS+索引方案可行 |
| UX | ✅ 支持 | 适老化设计全面 |
| BE | ✅ 支持 | 直传OSS减轻服务器压力 |
| QA | ✅ 支持 | 测试场景明确 |
| SEC | ✅ 支持 | 脱敏和二次确认已确认 |

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

### 决议
1. **适老化**：正文≥18px(rem)、标题≥24px、媒体查询320-428px、按钮≥88×88px、高对比度、语音输入、去动画
2. **性能**：首屏<3秒、分页20条/页、手机号唯一索引+身份类型索引+经纬度复合索引
3. **视频**：前端直传OSS（后端申请凭证），≤50MB、720p/2Mbps、≤5分钟，前端清除EXIF
4. **脱敏**：手机号138****1234，姓名张**，小程序端脱敏，后台管理员可看完整数据（需权限）
5. **安全**：敏感操作（导出/批量删除）二次确认+操作日志

---

## 议题七：数据模型与接口边界

### 问题
1. 核心数据表设计？
2. 小程序端和后台是否共用API？
3. 短信服务方案？

### 第一轮发言

**ARCH**：建议小程序和后台共用RESTful API，通过RBAC权限控制访问范围。小程序端用微信token认证，后台用JWT。这样减少代码重复，便于维护。

**BE**：同意共用API。但需要严格区分中间件——小程序请求走微信鉴权拦截器，后台请求走JWT拦截器。两个拦截器不能混淆。建议用不同的URL前缀区分：`/api/wx/*`给小程序，`/api/admin/*`给后台。

**QA**：同意，但需要测试验证：小程序token不能访问`/api/admin/*`，后台JWT不能访问`/api/wx/*`。权限隔离是测试重点。

**SEC**：共用API的安全风险在于权限泄露。建议：所有接口默认拒绝，显式授权。管理员接口加IP白名单限制（可选）。短信API密钥存储在环境变量，不能硬编码。

**PM**：短信用阿里云短信API，成本低、稳定性好。短信签名"洒渔用工"需要提前报备。

**ARCH**：短信API密钥存储在环境变量或配置中心。建议所有敏感配置统一管理：数据库密码、OSS密钥、短信密钥等。

### 第二轮交锋

**BE**：URL前缀区分`/api/wx/*`和`/api/admin/*`是否足够？还是需要更细粒度的权限控制？

**ARCH**：建议角色-权限表配置。角色：果农/工人/客商/农资商/管理员(超级/录入/审核/运维)。每个角色绑定一组权限，权限控制到接口级别。但MVP阶段可以先用角色+URL前缀做粗粒度控制，后续迭代为细粒度。

**SEC**：同意ARCH。MVP粗粒度够用。但有一个硬性要求：接口返回数据必须过滤敏感字段。比如小程序端查询工人列表，返回姓名+工种+报价，不返回手机号（需要拨号时单独申请）。

**PM**：这个设计好——工人手机号不在列表中展示，点击"拨号"时才通过单独接口获取，获取时记录拨号日志。同样适用于客商找果农场景。

**ARCH**：同意。拨号接口记录：谁拨了谁、什么时间。用于数据大屏的"电话拨打次数"统计。

### 投票

| 角色 | 投票 | 理由 |
|------|------|------|
| PM | ✅ 支持 | 效率最高，拨号日志支撑数据统计 |
| ARCH | ✅ 支持 | 架构合理，粗粒度权限MVP够用 |
| UX | ⚪ 弃权 | 无直接关联，但认可列表不展示手机号的设计 |
| BE | ✅ 支持 | URL前缀区分开发成本低 |
| QA | ✅ 支持 | 权限隔离已明确，测试重点清晰 |
| SEC | ✅ 支持 | 敏感字段过滤已确认 |

**结果：5/6支持（UX弃权）≥ 5，通过 ✅**

### 决议
1. **API架构**：共用RESTful API，`/api/wx/*`小程序端、`/api/admin/*`后台管理端
2. **认证机制**：小程序微信code→JWT token，后台账号密码→JWT token，独立拦截器
3. **权限模型**：RBAC，角色分为果农/工人/客商/农资商/管理员(超级/录入/审核/运维)，MVP粗粒度控制
4. **数据过滤**：接口返回过滤敏感字段，手机号通过单独拨号接口获取，记录拨号日志
5. **短信服务**：阿里云短信API，签名"洒渔用工"，密钥环境变量存储
6. **配置管理**：敏感配置（DB/OSS/短信）统一环境变量或配置中心管理

---

## 讨论总结

### 投票汇总

| 议题 | 结果 | 支持/总 | 关键争议 |
|------|------|---------|----------|
| 一：用户身份与登录 | ✅ 通过 | 6/6 | 无争议 |
| 二：果农端功能方案 | ✅ 通过 | 6/6 | 招工审核：免审核 vs 审核→折中：标记+复核 |
| 三：工人端功能方案 | ✅ 通过 | 6/6 | 状态审核：人工审核 vs 自动→折中：信用机制 |
| 四：客商端与农资端 | ✅ 通过 | 6/6 | 联系授权有效期：永久 vs 7天→7天 |
| 五：后台管理与导入 | ✅ 通过 | 6/6 | 字段映射：可配置 vs 硬编码→MVP硬编码 |
| 六：非功能性需求 | ✅ 通过 | 6/6 | 视频上传：后端中转 vs 直传OSS→直传OSS |
| 七：数据模型与接口 | ✅ 通过 | 5/6 | UX弃权（无直接关联） |

### 关键争议与最终折中

| 争议点 | 正方 | 反方 | 最终方案 |
|--------|------|------|----------|
| 招工审核 | PM:免审核 | BE:关键词过滤 | 免审核+敏感词标记+人工复核 |
| 状态审核 | PM:人工审核 | BE:自动机制 | 手动切换+3天自动恢复+信用机制 |
| 字段映射 | PM:可配置 | BE:硬编码 | MVP硬编码+后续可配置 |
| 视频上传 | SEC:后端中转 | BE:直传OSS | 前端直传OSS+后端申请凭证 |
| 距离计算 | PM:地址 | - | 地址→经纬度→Haversine |
| 解锁有效期 | SEC:7天 | PM:永久 | 7天有效期 |

### 方案特点
- **简单实用**：所有方案优先选择实现成本低、可靠性高的方案
- **MVP优先**：复杂功能（可配置映射、在线下单、双向匹配）延后迭代
- **安全合规**：手机号加密存储、脱敏显示、EXIF清除、操作日志
- **适老化**：大字体、大按钮、高对比度、语音输入