requirements-discussion.md 27 KB
需求研讨会议记录 V2
项目：洒渔镇苹果产业供需对接平台
参与角色（6人，每人1票）
| 角色 | 代号 | 核心关注 |
|---|---|---|
| 产品经理 | PM | 需求完整性、业务合理性、用户价值、优先级 |
| 架构师 | ARCH | 技术可行性、系统架构、可扩展性、技术选型 |
| 用户体验师 | UX | 适老化、交互流程、用户痛点、操作效率 |
| 后端开发 | BE | 实现复杂度、性能风险、开发成本、可维护性 |
| 测试工程师 | QA | 可测试性、边界场景、数据一致性、回归风险 |
| 安全专家 | SEC | 数据安全、隐私合规、权限控制、攻击面 |
投票规则
- 每人1票（支持/反对/弃权）
- 通过门槛：≥5票支持（6人中至少5人同意，>n/2+1=4）
- 弃权不计入有效票，但弃权者须说明顾虑
- 未通过的议题需修改方案后重新投票
功能清单原文摘要（共45个功能点）
小程序端：公共基础（登录/身份路由）、果农端（行情/找工人/招工/找客商/农资/名片）、工人端（找活/报名/状态）、客商端（找货/联系授权）、农资端（店铺） 后台管理端：系统管理、数据导入、审核中心、数据大屏 非功能性：适老化、性能、安全、兼容性
议题一：用户身份与登录体系
问题
- 微信登录+手机号唯一标识是否可靠？
- 多身份数据模型设计？
- 身份路由匹配逻辑？
第一轮发言
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，通过 ✅
决议
- 微信登录+手机号唯一标识，拒绝授权时引导联系村委会后台绑定
sys_user（基础信息）+user_identity（身份关联），支持一人多职- 手机号AES加密存储，phone_hash(SHA256)建唯一索引用于查询
- 身份路由：手机号精确匹配→0个提示联系村委会，1个直接进入，N个展示选择页
- 数据隔离：所有业务表带
user_identity_id，拦截器强制加条件
议题二：果农端核心功能方案
问题
- "今日行情"数据来源和更新频率？
- "找工人"距离计算方案？
- "我的名片"视频上传技术方案？
- 招工信息是否需要审核？
第一轮发言
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，通过 ✅
决议
- 今日行情：政府后台手动配置，按品种设置价格区间，每日更新，涨价红/降价绿色块，展示更新时间
- 距离计算：果园地址→地理编码→经纬度存储→Haversine公式计算
- 视频上传：后端中转，≤50MB/MP4/MOV，压缩720p/2Mbps，清除EXIF；照片≤9张/张≤5MB
- 招工发布：免审核直接发布，敏感关键词自动标记+待复核列表，后台保留强制下架
- 招工管理：支持下架、重新编辑、查看历史记录
议题三：工人端核心功能方案
问题
- "智能推荐"算法方案？
- 报名通知方案？
- 工人状态审核机制？
- 防骚扰限制合理性？
第一轮发言
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，通过 ✅
决议
- 智能推荐：MVP工种匹配+距离排序，后续迭代加入确认率权重
- 报名通知：阿里云短信API，模板"【洒渔用工】工人姓名对您的招工感兴趣，联系电话：[电话]"
- 状态管理：手动切换+3天无操作自动恢复"空闲"（last_active_time判断），报名后自动"忙碌"
- 信用机制：投诉1次警告，2次限制24小时，3次锁定需管理员解除
- 防骚扰：同一工人每天对同一果农最多1条短信，自然日计，短信日志全量记录
- 短信预算：月均500元/约12500条
议题四：客商端与农资端方案
问题
- "联系授权"（勾选批次才解锁电话）是否合理？
- 客商和果农信息匹配方向？
- 农资端是否需要在线下单？
第一轮发言
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，通过 ✅
决议
- 联系授权：客商勾选苹果批次→解锁果农电话，有效期7天，过期需重新勾选
- 解锁记录：客商ID、果农ID、批次ID、解锁时间、过期时间，全量存储
- 信息匹配：单向（客商→果农），MVP不做双向
- 农资端：MVP仅做店铺信息展示+一键拨号，
supplier_shop表预留goods字段 - 客商偏好：支持维护收购品种/价格区间/总量/标准
议题五：后台管理与数据导入方案
问题
- Excel字段映射方案？
- 大批量导入处理方式？
- 审核流程设计？
- 数据大屏技术方案？
第一轮发言
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，通过 ✅
决议
- 字段映射：MVP硬编码（4种模板），后续迭代可配置
- 导入流程：上传→预览（总行数/有效/错误/重复，错误行红色高亮）→确认入库
- 批量处理：≤100行同步，>100行异步+完成通知
- 去重规则：手机号+身份类型唯一，重复数据标记，用户可选跳过或覆盖
- 审核流程：单级审核，SLA≤24小时（超时提醒），48小时升级给超级管理员
- 数据大屏：定时任务每5分钟刷新，Redis缓存，核心指标：用户总数/活跃/供需比/撮合指标
议题六：非功能性需求确认
问题
- 适老化设计标准？
- 性能基准？
- 视频压缩标准？
- 手机号脱敏规则？
第一轮发言
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，通过 ✅
决议
- 适老化：正文≥18px(rem)、标题≥24px、媒体查询320-428px、按钮≥88×88px、高对比度、语音输入、去动画
- 性能：首屏<3秒、分页20条/页、手机号唯一索引+身份类型索引+经纬度复合索引
- 视频：前端直传OSS（后端申请凭证），≤50MB、720p/2Mbps、≤5分钟，前端清除EXIF
- 脱敏：手机号138**1234，姓名张，小程序端脱敏，后台管理员可看完整数据（需权限）
- 安全：敏感操作（导出/批量删除）二次确认+操作日志
议题七：数据模型与接口边界
问题
- 核心数据表设计？
- 小程序端和后台是否共用API？
- 短信服务方案？
第一轮发言
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，通过 ✅
决议
- API架构：共用RESTful API，
/api/wx/*小程序端、/api/admin/*后台管理端 - 认证机制：小程序微信code→JWT token，后台账号密码→JWT token，独立拦截器
- 权限模型：RBAC，角色分为果农/工人/客商/农资商/管理员(超级/录入/审核/运维)，MVP粗粒度控制
- 数据过滤：接口返回过滤敏感字段，手机号通过单独拨号接口获取，记录拨号日志
- 短信服务：阿里云短信API，签名"洒渔用工"，密钥环境变量存储
- 配置管理：敏感配置（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清除、操作日志
- 适老化：大字体、大按钮、高对比度、语音输入