sayu-app/docs/requirements-discussion.md

需求研讨会议记录 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清除、操作日志
• 适老化：大字体、大按钮、高对比度、语音输入