# 丹阳公益婚恋服务平台 # V1.0 Codex开发执行总指令、项目规则与任务拆解 版本：V1.0 文档级别：最高优先级开发执行文件 适用对象：Codex、研发人员、测试人员、后续维护人员 执行原则：严格继承既有设计，不擅自扩展，不擅自删减，不擅自重新定义产品 --- # 第一章 文档定位 本文件用于指导Codex完整开发： > 丹阳公益婚恋服务平台 V1.0 本文件不是普通PRD。 它同时承担： ```text 产品总约束 + 技术总约束 + 开发顺序 + 项目长期记忆 + 不可变规则 + 验收标准 + 任务拆解 ``` Codex在整个项目开发周期内，应将本文件视为： > **项目最高执行规则。** --- # 第二章 总开发目标 开发一套： > 面向丹阳市成年单身人士，由公益组织参与运营的实名制公益婚恋服务平台。 核心服务路径： ```text 实名认证 ↓ 人工资料审核 ↓ 系统精准匹配 ↓ 用户双向喜欢 ↓ 平台内安全聊天 ↓ 公益红娘辅助 ↓ 公益线下相亲活动 ↓ 双方进一步了解 ↓ 成功牵手 ``` --- # 第三章 产品核心定位 正式定位： > 面向丹阳市成年单身人士，由公益组织参与运营的实名制公益婚恋服务平台，通过实名认证、人工审核、智能匹配、双向喜欢、在线沟通、公益红娘和线下相亲活动，帮助本地单身人士安全、高效、真实地寻找合适伴侣。 核心价值： ```text 真实 公益 本地 安全 高效 ``` --- # 第四章 V1最高产品原则 所有研发决策必须服从： > 用户简单易用。 > 工作人员容易运营。 > 数据安全优先。 > 用户自主决定。 > 系统帮助而不是操控。 > 公益属性优先。 > 本地服务优先。 > 低开发复杂度。 > 易维护、易升级。 --- # 第五章 明确禁止偏离产品方向 Codex不得将平台开发成： ```text 商业婚恋VIP平台 陌生人社交平台 直播平台 短视频平台 社区平台 内容平台 游戏化交友平台 付费聊天平台 婚介CRM销售系统 ``` --- # 第六章 V1用户收费规则 用户： > 免费。 V1禁止： ```text VIP 会员 金币 礼物 付费曝光 超级喜欢 付费聊天 付费联系方式 付费活动 ``` 除非未来产品负责人明确重新立项。 --- # 第七章 用户准入 用户必须： ```text 18周岁以上 + 微信登录 + 手机号 + 姓名/身份证实名认证 + 人工资料审核 ``` 未成年人： > 禁止进入婚恋服务。 --- # 第八章 重要法律语义 必须区分： ```text 成年人 ≠ 达到法定结婚登记年龄 ``` 产品不得将18岁描述为： > 已具备法定结婚登记资格。 --- # 第九章 实名认证语义 “已实名认证”只代表： > 用户身份通过实名认证。 不代表： ```text 婚姻状态已经官方验证 职业已经验证 收入已经验证 所有资料100%真实 ``` --- # 第十章 婚姻状态 当前V1： ```text 未婚 离异 丧偶 ``` 属于： > 用户自行申报 + 人工资料审核。 不得宣传： > 官方婚姻状态认证。 --- # 第十一章 用户端技术形态 必须开发： > 微信小程序。 底部导航固定： ```text 首页 找对象 消息 活动 我的 ``` 不得擅自改成其他导航结构。 --- # 第十二章 后台技术形态 推荐并按V1执行： > 一个统一Web后台。 通过： ```text Operator + Role + Permission + Data Scope ``` 分别提供： - 公益红娘工作台 - 运营后台 - 平台管理后台 不需要开发三套完全独立后台。 --- # 第十三章 用户核心资料 必须字段： ```text 性别 出生年月 所在区域 身高 婚姻状况 是否有子女 学历 职业 头像 ``` 选填： ```text 兴趣 性格/生活方式 吸烟 饮酒 婚姻态度 结婚计划 自我介绍 ``` --- # 第十四章 用户资料输入原则 优先： > 选择 / 标签 / Picker。 减少： > 大段人工输入。 不要做超长复杂注册表。 --- # 第十五章 用户隐私字段 普通用户不得看到： ```text 真实姓名 完整手机号 微信号 身份证 精确地址 精确单位 内部风险信息 举报记录 ``` --- # 第十六章 择偶条件 基础： ```text 年龄 身高 地区 婚姻状况 学历 是否接受有子女 ``` 扩展： ```text 职业 吸烟 饮酒 婚姻计划 定居意愿 生活方式 兴趣 ``` --- # 第十七章 条件语义不可改变 每一项条件支持： ```text 必须符合 最好符合 ``` Required： > 不符合直接淘汰。 Preferred： > 可参与评分。 Codex不得把Required自动降级。 --- # 第十八章 V1匹配算法 必须采用： ```text 资格过滤 + 双向Required + 双向规则评分 + 推荐排序 + 推荐理由 ``` 不采用： - AI黑盒匹配 - 大模型判断婚姻幸福 - 向量数据库 - 深度学习推荐 - 颜值评分 --- # 第十九章 双向匹配 算法必须同时计算： ```text A → B B → A ``` 不是只满足A。 --- # 第二十章 MutualScore 建议公式实现为配置： ```text MutualScore = 0.6 × min(scoreAB, scoreBA) + 0.4 × average(scoreAB, scoreBA) ``` 公式版本必须： > 可版本化。 --- # 第二十一章 算法参数特别说明 此前文档中出现过： ```text 6人每日推荐 60分阈值 100分权重 180天Pass冷却 ``` 这些属于： > 示例/建议参数。 不得硬编码为不可修改业务常量。 必须通过： > Config / Match Rule Version 实现。 --- # 第二十二章 推荐前台展示 用户端不得显示： ```text 92% 87.5分 AI匹配成功率 ``` 只显示： ```text 很合适 比较合适 值得了解 ``` 以及： > 为什么推荐。 --- # 第二十三章 推荐理由 必须来源真实资料。 例如： ```text 年龄符合双方条件 都长期生活在丹阳 婚姻计划接近 双方都不吸烟 有共同兴趣 ``` 禁止AI虚构。 --- # 第二十四章 首页 首页必须： > 推荐优先。 不要开发： - 新闻 - Feed - 广告 - 热门榜 - 用户排行榜 - 直播入口 --- # 第二十五章 用户关系 单向： ```text neutral liked passed blocked ``` 双向： ```text mutual_match ``` --- # 第二十六章 Mutual Match 只有双方Like： > 才创建Match。 必须保证并发情况下： > 同一对用户只有一个有效Match实例/有效关系阶段。 --- # 第二十七章 Chat准入 必须： ```text Mutual Match + 双方账号允许 + 无Block + Conversation active ``` 才允许聊天。 --- # 第二十八章 聊天V1支持 ```text 文字 图片 Emoji 系统消息 安全提示 未读 历史分页 失败重试 ``` --- # 第二十九章 V1聊天禁止开发 ```text 语音消息 实时语音通话 视频 群聊 红包 转账 文件 阅后即焚 已读回执展示 正在输入 AI代聊 ``` --- # 第三十章 聊天发送架构 V1采用： ```text REST发送 + WebSocket接收 ``` 不要为了炫技改成全WebSocket协议。 --- # 第三十一章 消息持久化原则 必须： ```text 先落PostgreSQL ↓ 再实时推送 ``` 推送失败： > 消息仍然成功。 --- # 第三十二章 消息幂等 每条消息： ```text senderId + clientMessageId ``` 唯一。 弱网重试： > 不得重复消息。 --- # 第三十三章 Block Block最高优先级。 发生后立即： ```text 停止聊天 排除推荐 排除Search 排除红娘候选 停止互相可见 ``` --- # 第三十四章 Unblock 解除Block后： 不得自动： ```text 恢复Like 恢复Match 恢复Conversation ``` 重新建立关系必须重新走业务流程。 --- # 第三十五章 Unmatch 解除匹配后： ```text Match失效 Conversation只读 停止新消息 ``` Unmatch： > 不等于Block。 --- # 第三十六章 RelationshipStatus 此前技术模型： ```text searching getting_to_know paused matched_successfully service_exited ``` 属于： > 技术建议状态模型。 具体代码可采用等义命名，但不得随意扩展产品含义。 --- # 第三十七章 Paused 暂停寻找： > 不进入新推荐。 但： > 已有聊天保留。 --- # 第三十八章 Getting To Know “正在了解”是否自动暂停其他推荐： > 不能硬编码。 应由： - 用户选择 - 配置 决定。 --- # 第三十九章 Successful 成功牵手： 必须： > 一方发起 + 对方确认。 不能： - 红娘确认 - 管理员确认 - 系统自动确认 --- # 第四十章 公益活动 必须支持： ```text 活动列表 活动详情 报名 资格检查 人工审核 报名结果 签到 反馈 活动互选 ``` --- # 第四十一章 活动名额 必须支持： ```text 总人数 可选性别名额 ``` 性别名额： > 配置项。 不能写死每场都50:50。 --- # 第四十二章 Activity Pending V1建议： > Pending不占正式名额。 Approved： > 占正式名额。 审核通过必须事务检查剩余名额。 --- # 第四十三章 活动签到 采用： > 短期签名二维码Token。 不能二维码直接放： ```text 身份证 手机号 userId明文 ``` --- # 第四十四章 活动互选 必须独立表： ```text activity_interests ``` 不能在feedback中只放一个interestedUserId。 因为用户可能： > 选择多个意向对象。 --- # 第四十五章 活动意向隐私 A选择B但B没选A： > B不知道。 双方选择： > 才产生Match/通知。 --- # 第四十六章 活动互选不是成功牵手 只能表达： > 双方愿意进一步了解。 --- # 第四十七章 公益红娘 用户可申请： ```text 推荐合适对象 调整择偶条件 联系意向对象 参加活动 长期无匹配 聊天帮助 其他 ``` --- # 第四十八章 红娘核心原则 红娘： > 可以推荐。 不能： > 替用户Like。 红娘： > 可以辅助联系。 不能： > 私自提供手机号。 红娘： > 可以提供聊天建议。 不能： > 看完整私人聊天。 --- # 第四十九章 红娘候选来源 必须调用： > Match Engine。 红娘不能绕过Required搜索全库强推。 --- # 第五十章 红娘推荐 推荐前服务端必须二次检查： ```text 目标账号 审核 Block Relationship Required ``` --- # 第五十一章 红娘联系意向对象 V1采用保守实现： ```text A明确请求 ↓ 红娘触发平台中性邀请 ↓ B自行查看/拒绝 ``` 不得： > 自动给A或红娘释放B联系方式。 --- # 第五十二章 红娘服务记录 每次正式跟进： ```text 时间 渠道 摘要 结果 下一步 下次跟进 ``` 必须结构化保存。 --- # 第五十三章 红娘不能看到 ```text 身份证 私人聊天 举报证据 无关风险调查 精确住址 ``` --- # 第五十四章 后台Operator 所有工作人员统一： ```text operators ``` 不要创建： ```text reviewer_accounts matchmaker_accounts volunteer_accounts ``` 多套账号体系。 --- # 第五十五章 V1角色 建议： ```text super_admin platform_admin organization_admin reviewer matchmaker activity_manager risk_operator volunteer data_viewer ``` --- # 第五十六章 权限结构 必须采用： ```text RBAC + Data Scope + Sensitive Permission ``` --- # 第五十七章 Data Scope 至少支持： ```text platform organization assigned self activity_scope ``` --- # 第五十八章 用户不属于某个机构私有 禁止简单设计： ```text users.organization_id ``` 作为用户唯一归属。 用户是： > 平台用户。 组织通过： - 活动 - 红娘服务 - 审核任务 - 授权 获得必要访问。 --- # 第五十九章 机构之间 机构合作： > 不代表数据完全共享。 必须按业务关系限制。 --- # 第六十章 后台权限必须服务端执行 不能： > 只隐藏菜单。 每个API： 必须检查： ```text Authentication Permission Data Scope Sensitive Permission ``` --- # 第六十一章 聊天隐私 后台普通用户详情中： > 禁止“聊天记录”Tab。 只有风控案件场景： > 才允许有限访问。 --- # 第六十二章 敏感访问 查看： ```text 完整身份证 风控证据 案件聊天 ``` 必须： - 特殊权限 - 原因 - SensitiveAccessLog --- # 第六十三章 用户数据安全 身份证： ```text id_number_enc + id_number_hash ``` 手机： ```text phone_enc + phone_hash ``` 禁止生产明文。 --- # 第六十四章 WeChat账号数据 不要仅： ```text users.openid ``` 推荐： ```text user_wechat_accounts ``` 唯一： ```text app_id + openid ``` unionid允许为空。 --- # 第六十五章 实名Provider数据 只保留： > 业务必要结果。 不要默认存储： > 第三方完整原始响应。 --- # 第六十六章 用户照片 必须： > Private Object Storage。 通过： > Signed URL。 --- # 第六十七章 图片处理 至少： - MIME检查 - Magic Number - 大小限制 - 图片解码 - EXIF清理 --- # 第六十八章 数据库 V1推荐： > PostgreSQL。 具体技术栈仍可根据最终后端语言确认。 但数据模型和约束不可改变业务含义。 --- # 第六十九章 Redis 只用于： ```text Cache Session Rate Limit WebSocket 临时状态 ``` 不得成为： > Match等业务事实唯一数据源。 --- # 第七十章 Backend架构 V1采用： > Modular Monolith。 不要擅自拆微服务。 --- # 第七十一章 模块 至少： ```text Auth User Verification Profile Review Match Relationship Messaging Activity Matchmaker Risk Notification Organization Permission Analytics Audit Config ``` --- # 第七十二章 模块之间规则 禁止： > Module A直接跨模块修改Module B表。 通过： > Service / Domain接口。 --- # 第七十三章 后端语言 此前推荐： ```text Java 21 + Spring Boot 3.x ``` 或者： ```text Node.js + NestJS ``` 尚未锁死。 Codex如果当前仓库没有既有技术栈： 优先建议： > Java 21 + Spring Boot 3.x + PostgreSQL + Redis。 原因： - 权限 - 事务 - 状态机 - 长期维护 - 国内团队适配 但若用户后续明确指定技术栈： 以用户指令为准。 --- # 第七十四章 前端技术 微信小程序： 优先： > 原生微信小程序或成熟稳定框架。 不要为了技术炫技引入过重跨端体系。 后台： > Vue 3 或 React均可。 如果无既有代码： 建议： ```text Vue 3 TypeScript Vite Pinia ``` --- # 第七十五章 组件库 后台可采用： > Element Plus 或等价成熟组件库。 用户小程序： > 自建统一轻量组件。 --- # 第七十六章 Design Token 必须继承此前Design Token规范。 页面不能： > 每个开发者自己写一套颜色、间距、圆角。 --- # 第七十七章 UI原则 用户端： ```text 简单 温和 可信 公益 非商业化 ``` 避免： ```text 大量粉红 皇冠 钻石 金币 火焰 排行榜 夜店风 ``` --- # 第七十八章 页面架构 小程序核心路由必须继承既有U01-U48设计。 不得随意合并导致业务缺失。 --- # 第七十九章 用户启动路由优先级 服务端状态判断： ```text 1 登录 2 手机 3 实名 4 资料完整 5 审核 6 账号风险 7 婚恋服务状态 8 正常业务 ``` 页面自己不能猜。 --- # 第八十章 State Store 前端建议： ```text AuthStore UserStore MatchStore MessageStore ActivityStore MatchmakerStore AppStore ``` --- # 第八十一章 Server Truth 所有关键状态： > 后端数据库为最终事实。 前端Store： > 只是显示缓存。 --- # 第八十二章 API Base 统一： ```text /api/v1 ``` --- # 第八十三章 API响应 统一： ```json { "success": true, "code": "OK", "message": "success", "data": {} } ``` 建议同时包含： > requestId / timestamp 并在全项目保持一致。 --- # 第八十四章 HTTP Status 必须合理使用： ```text 400 参数错误 401 未认证 403 权限/禁止 404 不存在/不可见 409 状态冲突 422 业务校验（如选用） 429 限流 500 服务端异常 ``` --- # 第八十五章 API DTO 禁止： > 数据库Entity直接作为API Response。 必须： ```text PublicUserDTO SelfUserDTO MatchmakerUserDTO AdminUserDTO SensitiveIdentityDTO ``` 等隔离。 --- # 第八十六章 OpenAPI 必须： > 维护Swagger/OpenAPI。 并建议： > 生成TypeScript Client。 减少前后端接口不一致。 --- # 第八十七章 Production Swagger 不得无保护公开管理API文档。 可： - 内网 - 鉴权 - Production关闭 --- # 第八十八章 数据库主键 建议： > 应用生成UUID。 不要依赖可枚举自增ID作为对外资源ID。 --- # 第八十九章 数据库时间 统一： > TIMESTAMPTZ。 展示： > Asia/Shanghai。 --- # 第九十章 状态字段 推荐： > VARCHAR + CHECK / 字典。 不建议PG Native ENUM。 便于状态演进。 --- # 第九十一章 JSONB原则 只用于： - 配置 - Snapshot - 小型扩展字段 不能把核心实体全部塞JSON。 --- # 第九十二章 关键数据库唯一约束 必须有： ```text 微信 app_id + openid 身份证hash 手机号hash（按业务需要） user relation activity registration clientMessageId Match active pair ``` --- # 第九十三章 Match历史 不要设计成： > 一对用户永远只有一条不可变Match且无法未来重新建立。 必须支持： > 历史关系和新的有效关系阶段。 可采用： - Match Episode - 历史记录 - Active Pair Unique 具体表结构由Codex合理实现。 --- # 第九十四章 Pass 需要预留： ```text expires_at ``` 但冷却周期： > 配置。 --- # 第九十五章 AccountStatus 技术状态： ```text normal reviewing_risk limited suspended banned closed ``` 属于建议技术模型。 如果Codex优化命名： > 语义必须一致。 --- # 第九十六章 RiskLevel 建议： ```text normal watch high critical ``` RiskLevel： > 不等于AccountStatus。 --- # 第九十七章 RiskAction 建议： ```text warning feature_limit temporary_suspend ban manual_investigation ``` --- # 第九十八章 Report Report是否成立： 与： > 风控如何处置 必须分开。 --- # 第九十九章 风控原则 不得： > 单个关键词直接永久封禁。 默认： ```text 规则发现 ↓ 风险事件 ↓ 人工判断 ↓ 处置 ``` 明显技术攻击除外。 --- # 第一百章 申诉 Appeal此前属于： > 推荐V1功能。 如果开发资源充足： 应实现。 若必须缩减： > 可作为V1.0.x补充，但数据结构建议预留。 --- # 第一百零一章 数据统计 正式指标必须唯一口径。 尤其： ```text 注册 实名 审核通过 推荐曝光 Like Mutual Match Chat Started Activity Mutual Successful Match ``` 不得混淆。 --- # 第一百零二章 Success统计 只有： > 双方成功牵手确认 才算： ```text successful ``` 活动互选： > 不是成功牵手。 --- # 第一百零三章 Chat Started 必须是真实用户消息。 SystemMessage： > 不算。 --- # 第一百零四章 数据统计架构 V1： ```text PostgreSQL业务表 + Daily Summary + Redis缓存 ``` 足够。 禁止提前建设： - Kafka - Flink - ClickHouse - Data Lake --- # 第一百零五章 部署 必须： ```text Docker Docker Compose Nginx PostgreSQL Redis Private Object Storage ``` --- # 第一百零六章 V1禁止基础设施过度设计 不得擅自引入： ```text Kubernetes Service Mesh Kafka Elasticsearch Neo4j Milvus 分布式数据库 ``` 除非出现明确、经过验证的必要性。 --- # 第一百零七章 配置 区分： ```text 业务Config 部署Config Secret ``` Secret： > 不进Git。 --- # 第一百零八章 CI/CD 至少： ```text Lint Unit Test Integration Test Migration Validation Build ``` 通过后： > 构建固定版本镜像。 --- # 第一百零九章 生产发布 禁止： ```text SSH生产 git pull 现场npm install 现场mvn package ``` 生产只拉： > 已构建Artifact/Image。 --- # 第一百一十章 Migration 所有数据库变化： > Migration管理。 生产禁止： > 手工无记录ALTER TABLE。 --- # 第一百一十一章 Health 必须： ```text /health/live /health/ready /version ``` --- # 第一百一十二章 监控 至少： ```text CPU Memory Disk API 5xx P95 PostgreSQL Redis Backup 证书 ``` --- # 第一百一十三章 日志 必须： > Structured Log。 统一： ```text requestId ``` --- # 第一百一十四章 日志禁区 禁止记录： ```text 完整身份证 完整Token 密码 聊天正文 举报完整正文 敏感图片URL ``` --- # 第一百一十五章 Backup 必须： ```text 数据库自动备份 + 独立位置 + 加密 + 恢复验证 ``` --- # 第一百一十六章 Restore 必须真正演练。 只有“有backup文件”： > 不算合格。 --- # 第一百一十七章 Rollback 每个生产Release： 必须知道： > 上一个稳定版本。 --- # 第一百一十八章 Feature Flag 至少支持： ```text activityEnabled matchmakerEnabled imageChatEnabled ``` 以及必要核心模块Kill Switch。 --- # 第一百一十九章 测试最高优先级 开发过程中测试顺序： ```text 权限 数据一致性 Match Block Chat 实名认证 审核 活动并发 红娘 统计 UI细节 ``` --- # 第一百二十章 Codex开发模式 Codex必须采用： > 分阶段、可运行、可验证。 禁止： > 一次生成全项目大量代码然后最后统一调试。 --- # 第一百二十一章 每阶段基本流程 每一个阶段执行： ```text 读取本阶段规则 ↓ 确认相关数据模型 ↓ 建立测试 ↓ 实现后端 ↓ 实现前端 ↓ 运行测试 ↓ 验证核心流程 ↓ 更新开发记录 ↓ 进入下一阶段 ``` --- # 第一百二十二章 不允许静默改变需求 如果Codex发现： - 规则冲突 - 前文未确认 - 技术实现存在多种方案 必须： > 保持原需求。 对于未确认内容： 标记： ```text TODO_PRODUCT_CONFIRMATION ``` 或者： > 使用可配置实现。 不得擅自拍板改变产品。 --- # 第一百二十三章 不允许“为了方便”简化核心规则 禁止： > 为了开发简单取消双向匹配。 禁止： > 为了查询方便给管理员全部权限。 禁止： > 为了快速推荐自动放宽Required。 禁止： > 为了聊天方便允许陌生私信。 --- # 第一百二十四章 技术债原则 允许： > 简化技术架构。 不允许： > 简化产品安全规则。 --- # 第一百二十五章 项目目录建议 如果从零开发，建议： ```text project/ ├── backend/ ├── miniapp/ ├── admin-web/ ├── infrastructure/ ├── docs/ ├── scripts/ └── tests/ ``` --- # 第一百二十六章 Backend目录建议 以模块化单体为原则： ```text backend/src/ ├── auth/ ├── user/ ├── verification/ ├── profile/ ├── review/ ├── match/ ├── relationship/ ├── messaging/ ├── activity/ ├── matchmaker/ ├── risk/ ├── notification/ ├── organization/ ├── permission/ ├── analytics/ ├── audit/ ├── config/ └── shared/ ``` 具体语言框架结构可调整。 --- # 第一百二十七章 Miniapp目录建议 ```text miniapp/ ├── pages/ ├── components/ ├── stores/ ├── services/ ├── utils/ ├── theme/ ├── constants/ └── types/ ``` --- # 第一百二十八章 Admin目录建议 ```text admin-web/src/ ├── pages/ ├── layouts/ ├── components/ ├── modules/ ├── stores/ ├── api/ ├── permissions/ ├── router/ ├── theme/ └── types/ ``` --- # 第一百二十九章 Docs必须进入Git 至少： ```text docs/ ├── product/ ├── architecture/ ├── api/ ├── database/ ├── security/ ├── testing/ ├── ops/ └── decisions/ ``` --- # 第一百三十章 ADR 重要技术决策建议记录： ```text docs/decisions/ ADR-001-backend-stack.md ADR-002-auth-strategy.md ADR-003-object-storage.md ``` --- # 第一百三十一章 Codex项目记忆文件 建议仓库根目录建立： ```text AGENTS.md ``` 用于放： > Codex执行规则摘要。 --- # 第一百三十二章 AGENTS.md必须写入 至少： ```text 不得改变V1范围 Required不可放宽 Mutual后才能聊天 红娘不可替用户操作 隐私最小化 禁止VIP/付费 禁止陌生人私信 禁止管理员默认查看聊天 模块化单体 不引入微服务/K8s ``` --- # 第一百三十三章 STATUS.md 建议： ```text docs/STATUS.md ``` 记录： ```text 已完成 开发中 未开始 已知问题 待确认事项 ``` Codex每阶段更新。 --- # 第一百三十四章 CHANGELOG 每次版本更新： > CHANGELOG.md。 --- # 第一百三十五章 第一阶段：项目基础骨架 目标： > 项目可以启动。 任务： ```text 初始化Backend 初始化Mini Program 初始化Admin Web Docker环境 PostgreSQL Redis 基础配置 统一Response Error Handling Logging RequestId Migration ``` --- # 第一百三十六章 第一阶段验收 必须： ```text Backend可启动 数据库Migration成功 Redis正常 Admin可打开 Miniapp可打开 Health正常 CI通过 ``` --- # 第一百三十七章 第二阶段：认证与Operator基础 用户： ```text 微信登录 手机号 Session /me/status ``` 后台： ```text Operator login Role Permission Organization ``` --- # 第一百三十八章 第二阶段重点 必须先做好： > 权限框架。 不要等整个后台开发完才补权限。 --- # 第一百三十九章 第二阶段测试 重点： ```text Token Refresh Logout Operator Disable RBAC Data Scope基础 ``` --- # 第一百四十章 第三阶段：实名认证 开发： ```text IdentityProvider接口 实名请求 实名认证状态 年龄检查 身份证加密/hash 去重 日志脱敏 ``` --- # 第一百四十一章 第三阶段验收 必须： - 未成年拦截 - 重复身份证处理 - Provider失败可恢复 - 数据库无明文身份证 - 日志无身份证 --- # 第一百四十二章 第四阶段：用户Profile 开发： ```text Basic Profile Lifestyle Photos Interests Self Intro Relationship Intent Privacy Preference ``` --- # 第一百四十三章 第四阶段重点 必须同时完成： > Draft / Completion / Validation。 --- # 第一百四十四章 第五阶段：人工审核 开发： ```text ReviewTask ReviewItem Claim Approve Need Edit Reject Review History ``` --- # 第一百四十五章 第五阶段后台 完成： > Reviewer工作台最小可用版本。 --- # 第一百四十六章 第五阶段并发 必须测试： > 多审核员同时Claim。 --- # 第一百四十七章 第六阶段：推荐Match Engine 优先只做后端。 开发： ```text Eligibility RequiredCondition DirectionalScore MutualScore Reasons Ranking RecommendationRecord ``` --- # 第一百四十八章 第六阶段测试 必须覆盖： > 每个维度 + 双向Required。 算法测试必须自动化。 --- # 第一百四十九章 第七阶段：首页与找对象 开发： ```text 推荐卡 推荐理由 详情 Find Filter 临时筛选 ``` --- # 第一百五十章 第七阶段重点 确保： > Search和Recommendation使用同一Eligibility基础规则。 --- # 第一百五十一章 第八阶段：Like与Match 开发： ```text Like Cancel Like Pass Block Unblock Mutual Match Match History ``` --- # 第一百五十二章 第八阶段最高风险 重点验证： ```text 并发Like 重复Like Match唯一性 Block优先级 ``` --- # 第一百五十三章 第九阶段：Conversation与Text Chat 先只做： ```text Conversation Text Message REST Send WebSocket Receive Unread History ``` 暂不先做图片。 --- # 第一百五十四章 第九阶段完成条件 A/B双方： ```text Like ↓ Match ↓ 打开Chat ↓ 发送文字 ↓ 另一方实时收到 ``` 必须完整。 --- # 第一百五十五章 第十阶段：Chat安全与图片 增加： ```text 图片 上传 Signed URL Risk Notice Rate Limit Block实时 Ban实时 ``` --- # 第一百五十六章 第十一阶段：系统通知 统一NotificationService。 接： ```text 审核 Match 活动 红娘 风险 ``` --- # 第一百五十七章 第十二阶段：Relationship状态 开发： ```text Paused Getting To Know Successful Request Confirm Decline ``` Success必须双确认。 --- # 第一百五十八章 第十三阶段：公益红娘 开发： ```text MatchmakerService 分配 Claim 候选 推荐 Followup Waiting User Complete Risk Referral ``` --- # 第一百五十九章 第十三阶段用户端 完成： ```text 公益红娘首页 申请 进度 红娘推荐 ``` --- # 第一百六十章 第十四阶段：活动基础 开发： ```text Activity CRUD Publish Cancel Browse Apply Review My Activities ``` --- # 第一百六十一章 第十四阶段并发 必须完成： > Activity capacity事务。 --- # 第一百六十二章 第十五阶段：签到 开发： ```text Signed Checkin Token Staff Scan Manual Checkin Duplicate Check ``` --- # 第一百六十三章 第十六阶段：活动反馈与互选 开发： ```text Feedback ActivityInterest Mutual Interest Activity Source Match ``` --- # 第一百六十四章 第十六阶段隐私重点 单向Activity Interest： > 不得向对方暴露。 --- # 第一百六十五章 第十七阶段：举报与风控 开发： ```text Report Evidence RiskEvent RiskProfile RiskAction Account Capability Risk Admin ``` --- # 第一百六十六章 第十七阶段实时联动 封禁/限制： 必须立即影响： ```text Recommendation Like Chat Activity Matchmaker ``` --- # 第一百六十七章 第十八阶段：申诉 如果列入V1正式范围： ```text Appeal Process Approve Reject Recalculate Account Status ``` --- # 第一百六十八章 第十九阶段：后台完善 完成： ```text User Management Organization Operator Role Permission Audit SensitiveAccess ``` --- # 第一百六十九章 第二十阶段：Analytics 实现： ```text Dashboard User Funnel Match Funnel Matchmaker Stats Activity Stats Risk Stats Daily Summary ``` --- # 第一百七十章 第二十一阶段：注销与数据生命周期 完成： ```text Account Deletion Service Exit Visibility Removal Activity Cleanup Matchmaker Cleanup Retention Hooks ``` --- # 第一百七十一章 第二十二阶段：部署体系 完成： ```text Dockerfile Docker Compose Nginx Health CI/CD Staging Backup Restore Rollback Monitoring ``` --- # 第一百七十二章 第二十三阶段：完整系统测试 必须执行： ```text 核心E2E 权限矩阵 IDOR 并发 聊天弱网 活动并发 风控 统计 恢复 ``` --- # 第一百七十三章 第二十四阶段：UAT 邀请： ```text 普通用户 审核员 红娘 活动管理员 风控员 志愿者 ``` 进行真实操作。 --- # 第一百七十四章 第二十五阶段：RC 生成： ```text v1.0.0-rc.1 ``` 进入Staging最终回归。 --- # 第一百七十五章 第二十六阶段：生产上线 上线前： ```text Backup Migration Deploy Smoke Monitor ``` --- # 第一百七十六章 开发任务优先级 定义： ```text P0 P1 P2 ``` --- # 第一百七十七章 P0 所有上线必须功能： ```text 认证 实名 Profile 审核 Preference 推荐 Like Mutual Chat Block Report Matchmaker基础 Activity基础 权限 风控 ``` --- # 第一百七十八章 P1 V1必须完成但可以后置开发： ```text 图片聊天 活动互选 高级红娘协同 Analytics 申诉 动态水印 ``` 其中： > 活动互选属于V1最终上线必需闭环，不得拖到V2。 --- # 第一百七十九章 P2 可V1.0.x： ```text 更高级统计 异常登录提醒 MFA强化 更多运营辅助 高级风控规则 ``` --- # 第一百八十章 V1明确不做列表 Codex遇到以下需求不得自行开发： ```text 直播 短视频 动态Feed 朋友圈 群聊 语音房 视频相亲 礼物 金币 积分商城 排行榜 VIP 支付 超级喜欢 Boost 付费解锁联系方式 AI数字人 AI代聊 AI婚恋预测 颜值评分 财富评分 复杂智能排桌 ``` --- # 第一百八十一章 Git规则 建议： ```text main develop feature/* fix/* hotfix/* ``` 小团队也可以简化。 但Production发布必须： > 有Tag。 --- # 第一百八十二章 Commit原则 每个Commit： > 一个明确任务。 不要： ```text update fix stuff final ``` 建议： ```text feat(match): implement mutual eligibility fix(chat): prevent send after block ``` --- # 第一百八十三章 Branch完成规则 合并前： ```text Tests pass Lint pass Build pass Migration pass ``` --- # 第一百八十四章 数据Migration与代码同PR 新增字段： > Migration必须随代码提交。 不能： > 口头告诉运维自己建表。 --- # 第一百八十五章 环境变量 `.env.example`必须持续同步。 新增环境变量： > 同时更新文档。 --- # 第一百八十六章 API变更 每次： > 更新OpenAPI。 不得代码改了API但文档不变。 --- # 第一百八十七章 前后端共享类型 如果可能： > 自动生成。 避免手写两套Enum。 --- # 第一百八十八章 状态枚举 所有状态： > 单一来源。 尤其： ```text AccountStatus ReviewStatus RelationshipStatus MatchStatus ActivityStatus RegistrationStatus MatchmakerStatus ReportStatus ``` --- # 第一百八十九章 业务配置 所有未确认数量型规则： 必须： > Configurable。 例如： ```text 推荐数量 照片数量 兴趣数量 Pass冷却 活动互选人数 消息长度 限流阈值 ``` --- # 第一百九十章 不要过度配置 只有： > 业务可能变化的值 才配置。 不要把所有按钮颜色都放数据库。 UI走： > Design Token。 --- # 第一百九十一章 代码注释原则 复杂业务： > 解释为什么。 例如： ```text // Required preferences must never be relaxed. // This is a product invariant. ``` 而不是： ```text // if ``` --- # 第一百九十二章 核心Invariant Codex必须在代码、测试中明确保护以下Invariant： ```text 未Mutual不可聊天 Required不可自动放宽 Block即时禁止互动 工作人员不能替用户Like 成功牵手必须双确认 单向活动意向不泄露 敏感身份默认脱敏 跨组织默认拒绝 ``` --- # 第一百九十三章 事务边界 以下必须事务： ```text Mutual Match创建 Activity名额批准 Review Claim Successful Confirm RiskAction + AccountStatus ``` --- # 第一百九十四章 事务外副作用 例如： ```text Notification WebSocket Analytics ``` 事务提交后执行。 失败： > 补偿/重试。 不能回滚已成功核心业务。 --- # 第一百九十五章 Outbox V1如果通知可靠性实现复杂： 建议： > Lightweight Outbox Pattern。 无需Kafka。 --- # 第一百九十六章 Scheduler 允许： > Backend内置Scheduler。 多实例时加锁。 --- # 第一百九十七章 后台删除原则 重要实体： > 不物理删除。 采用： ```text disabled cancelled closed soft_delete ``` --- # 第一百九十八章 Audit 后台关键操作： > 必须Audit。 包括： ```text 审核 风险 活动取消 角色权限 Operator 敏感访问 系统配置 匹配规则 ``` --- # 第一百九十九章 测试优先要求 每完成模块： Codex必须运行： > 相关测试。 不得直到最后一次性运行。 --- # 第二百章 Match模块完成定义 必须同时满足： ```text 算法单测通过 Required测试通过 Mutual并发测试通过 Block测试通过 Recommendation API通过 ``` 才算完成。 --- # 第二百零一章 Chat模块完成定义 必须： ```text 无Match不可发送 Match可发送 重复clientMessage不重复 Block即时失效 Unmatch即时失效 WS恢复 ``` --- # 第二百零二章 Activity完成定义 必须： ```text 资格正确 名额并发正确 重复报名安全 签到安全 单向意向私密 Mutual创建一次 ``` --- # 第二百零三章 Permission完成定义 必须使用： > 非超级管理员测试。 至少测试： ```text reviewer matchmaker activity_manager risk_operator volunteer organization_admin ``` --- # 第二百零四章 敏感数据完成定义 必须确认： ```text DB无身份证明文 日志无身份证 Public DTO无手机号 Bucket非公开 SensitiveAccess有审计 ``` --- # 第二百零五章 不接受“先做功能以后补安全” 本项目安全不是后置模块。 权限、敏感数据、Block： > 必须和功能一起实现。 --- # 第二百零六章 用户体验完成定义 页面不只要： > 功能存在。 必须： - Loading - Empty - Error - Success feedback - Disabled state - Retry 完整。 --- # 第二百零七章 普通用户错误提示 不得展示： ```text NullPointerException SQLSTATE 403 Forbidden ``` 使用业务文案。 --- # 第二百零八章 后台技术错误 可以显示： > RequestId 帮助技术排查。 但仍不得展示敏感Stack。 --- # 第二百零九章 Codex每阶段输出要求 每完成一个阶段： 更新： ```text docs/STATUS.md CHANGELOG.md OpenAPI Migration Tests ``` --- # 第二百一十章 STATUS示例 ```text ## Phase 8 Like & Match Status: Completed Implemented: - Like - Pass - Block - Mutual Match Tests: - simultaneous like - duplicate like - block override Known: - pass cooldown configurable, default not finalized ``` --- # 第二百一十一章 待确认内容管理 建立： ```text docs/PENDING_DECISIONS.md ``` --- # 第二百一十二章 当前需要标记为可配置/待确认的项目 包括但不限于： ```text 每日推荐数量 推荐最低阈值 最终权重 Pass冷却 照片上限 兴趣标签上限 Self Intro长度 Privacy默认值 Getting To Know是否自动暂停推荐 活动是否默认审核 活动男女名额 活动互选人数 活动互选截止时间 Matchmaker联系目标的电话授权规则 RelationshipStatus最终业务命名 Appeal是否V1首发 ``` --- # 第二百一十三章 Codex不得把待确认项硬编码 必须： - Config - Feature Flag - 合理默认技术值 - 文档标记 并明确： > 默认值只是当前技术默认，不代表产品最终确认。 --- # 第二百一十四章 不得修改已确认内容 例如： ```text 用户免费 必须实名认证 人工资料审核 双向喜欢后聊天 公益活动顶级Tab 红娘不代操作 Required不可放宽 ``` 这些不是待确认。 --- # 第二百一十五章 代码质量原则 优先： ```text 可读 明确 少魔法 少抽象 可测试 ``` 不要为了： > “架构高级” 创建大量无意义层。 --- # 第二百一十六章 不提前设计十年后的架构 当前只需： > 支持V1 + 平滑扩容。 不要构建： - Plugin Platform - Workflow Engine - Rule DSL - Distributed Saga 除非实际需要。 --- # 第二百一十七章 Domain Service原则 业务规则集中。 Controller： > 不写核心业务逻辑。 --- # 第二百一十八章 Repository原则 数据访问统一。 不要： > Service里到处拼SQL。 --- # 第二百一十九章 Validation 分： ```text DTO validation + Business validation ``` 两者不要混淆。 --- # 第二百二十章 异常体系 例如： ```text AuthenticationException PermissionDeniedException BusinessConflictException ResourceUnavailableException ValidationException ``` 统一映射API错误。 --- # 第二百二十一章 Security默认拒绝 任何： > 权限不确定 应： > 拒绝。 --- # 第二百二十二章 Recommendation降级 推荐Reason失败： > 可返回候选。 Eligibility失败： > 不可绕过。 --- # 第二百二十三章 Privacy优先 Privacy设置： > 高于推荐便利。 --- # 第二百二十四章 Risk优先 Risk状态： > 高于普通业务状态。 --- # 第二百二十五章 Block优先 Block： > 高于Match。 --- # 第二百二十六章 数据库Source of Truth Redis/前端与DB不一致： > DB为准。 --- # 第二百二十七章 前端Optimistic Update 可以用于： ```text Like Pass Privacy ``` 但失败必须回滚。 以下不要盲目Optimistic： ```text 实名 审核 成功牵手 活动通过 封禁 ``` --- # 第二百二十八章 WebSocket只是通知通道 不能： > 依赖WebSocket事件作为唯一业务状态。 断线后： > REST可重建。 --- # 第二百二十九章 外部Provider 必须Adapter封装。 后续： > 可更换供应商。 --- # 第二百三十章 中国大陆环境适配 优先： ```text 国内网络稳定 国内云服务 微信生态 中国大陆对象存储 国内实名认证Provider ``` 避免核心依赖境外不可控服务。 --- # 第二百三十一章 第三方依赖最小化 V1不需要大量SDK。 只接： > 真正必要能力。 --- # 第二百三十二章 开源依赖选型原则 选择： - 活跃维护 - 社区成熟 - License清晰 - 国内可用 - 不过度绑定云厂商 --- # 第二百三十三章 License Codex新增开源库时： 必须确认License。 避免引入： > 与商业/公益部署冲突的许可证风险。 --- # 第二百三十四章 Dependency清单 维护： ```text docs/DEPENDENCIES.md ``` 列： ```text 名称 版本 用途 License ``` --- # 第二百三十五章 Security Dependency 定期扫描： - npm audit - Maven/Gradle依赖扫描 - Container CVE 但不要盲目自动升级破坏生产。 --- # 第二百三十六章 可观测性 每个模块关键操作应有： ```text Metrics Logs Audit（需要时） ``` --- # 第二百三十七章 Match Observability 至少记录： ```text candidate_count required_reject_count recommendation_count match_created ``` 不记录敏感推断。 --- # 第二百三十八章 Message Observability 至少： ```text send_success send_failure ws_push_failure reconnect ``` --- # 第二百三十九章 Activity Observability 至少： ```text apply approve checkin capacity_conflict ``` --- # 第二百四十章 Risk Observability 至少： ```text report_created risk_action appeal ``` --- # 第二百四十一章 生产数据禁止Seed测试用户 正式环境： > 禁止默认插入测试用户。 --- # 第二百四十二章 Test Account 如果生产必须保留运营测试账号： 必须明确标记： ```text is_test_account ``` 并排除： - 推荐 - 统计 - 用户搜索 --- # 第二百四十三章 数据统计必须排除测试账号 否则运营指标污染。 --- # 第二百四十四章 小程序发布前 Codex必须准备： ```text 微信合法域名清单 API域名 Upload域名 Download域名 WebSocket域名 隐私配置清单 ``` --- # 第二百四十五章 小程序权限申请 只申请业务需要能力。 不要申请： > GPS等当前不需要权限。 --- # 第二百四十六章 位置 V1： > 不做持续GPS。 区域： > 用户选择行政区。 --- # 第二百四十七章 用户协议页面 必须可访问： ```text 用户服务协议 隐私政策 个人信息收集清单 第三方共享清单 活动规则 ``` --- # 第二百四十八章 Privacy版本 必须： > 版本化。 用户同意： > 可追溯。 --- # 第二百四十九章 Consent 建议表： ```text consent_records ``` 至少记录： ```text user type version agreed_at ``` --- # 第二百五十章 删除/注销 Codex必须设计： > 正式后端流程。 不能只： > 前端隐藏账号。 --- # 第二百五十一章 删除原则 需要： ```text 停止展示 停止服务 停止推荐 关闭Session 按保留规则处理数据 ``` --- # 第二百五十二章 数据保留期限 精确法律/运营期限： > 不在代码硬编码。 使用： > Data Retention Config / Policy。 --- # 第二百五十三章 成功案例 默认： > Private。 宣传必须： > 单独授权。 --- # 第二百五十四章 活动现场宣传照片 如有： > 单独授权/规则。 不能把报名视作永久宣传授权。 --- # 第二百五十五章 红娘工作台数据 禁止提供： > 一键导出所有用户资料。 --- # 第二百五十六章 Admin数据导出 必须单独权限： ```text data.export ``` 并： > 脱敏 + Audit。 --- # 第二百五十七章 后台临时账号 志愿者建议： > expires_at。 活动结束后失效。 --- # 第二百五十八章 数据权限生命周期 服务结束后： > 应减少无必要访问。 V1至少保证： > assigned任务权限结束后不能继续编辑。 --- # 第二百五十九章 Codex不得擅自加入“内部用户价值评分” 禁止： ```text A级用户 高价值用户 低质量用户 颜值分 财富分 ``` --- # 第二百六十章 算法不使用 禁止推断： ```text 宗教 政治 健康 性生活 财富等级 ``` 作为匹配分。 --- # 第二百六十一章 成功标准 本项目不是： > 页面全部完成。 而是以下闭环真正运行： ```text 注册 ↓ 实名 ↓ 审核 ↓ 推荐 ↓ Mutual ↓ Chat ↓ 红娘/活动 ↓ 进一步了解 ↓ 成功 ``` --- # 第二百六十二章 V1核心验收用户故事一 新用户进入。 应能： ```text 微信登录 ↓ 绑定手机 ↓ 实名 ↓ 填写资料 ↓ 设置择偶 ↓ 提交审核 ↓ 等待 ``` --- # 第二百六十三章 用户故事二 审核员： ```text 登录 ↓ 待审核 ↓ 领取 ↓ 查看 ↓ 通过/退回 ``` --- # 第二百六十四章 用户故事三 用户审核通过： ```text 首页看到推荐 ↓ 看详情 ↓ Like ``` --- # 第二百六十五章 用户故事四 双方Like： ```text Mutual Match ↓ Conversation ↓ 聊天 ``` --- # 第二百六十六章 用户故事五 用户觉得不合适： ```text Unmatch ``` 随后： > 不能继续聊天。 --- # 第二百六十七章 用户故事六 用户遭骚扰： ```text Block + Report ``` 立即停止联系。 --- # 第二百六十八章 用户故事七 长期没结果： ```text 申请红娘 ↓ 红娘接手 ↓ 系统候选 ↓ 人工推荐 ``` --- # 第二百六十九章 用户故事八 用户参加活动： ```text 报名 ↓ 审核 ↓ 签到 ↓ 互选 ↓ Mutual ``` --- # 第二百七十章 用户故事九 风控员： ```text 处理举报 ↓ 采取Action ↓ 用户立即受限 ``` --- # 第二百七十一章 用户故事十 双方关系稳定： ```text 一方发成功请求 ↓ 另一方确认 ↓ 成功牵手 ↓ 停止新推荐 ``` --- # 第二百七十二章 Codex阶段验收机制 每完成Phase： 必须回答： ```text 完成了什么？ 测试了什么？ 有哪些已知问题？ 有哪些待确认？ 是否影响之前功能？ ``` --- # 第二百七十三章 Codex禁止声明完成的情况 如果： ```text 代码写完 测试没跑 Migration没验证 权限没测 核心E2E没跑 ``` 不得说： > 完成。 --- # 第二百七十四章 Regression 每个新模块： 必须确保： > 不破坏之前通过的核心流程。 --- # 第二百七十五章 优先自动化场景 一定自动化： ```text Required Mutual Block Chat permission Activity capacity RBAC Data Scope ``` --- # 第二百七十六章 Go-Live阻断 上线前以下必须为0： ```text P0 未接受P1 严重权限漏洞 敏感数据明文 Match并发错误 Activity超卖 ``` --- # 第二百七十七章 V1开发路线总览 ```text Phase 01 基础架构 Phase 02 Auth + Operator Phase 03 Verification Phase 04 Profile Phase 05 Review Phase 06 Match Engine Phase 07 Home/Discover Phase 08 Like/Relationship Phase 09 Text Chat Phase 10 Image/Safety Chat Phase 11 Notification Phase 12 Relationship Progress Phase 13 Matchmaker Phase 14 Activity Phase 15 Check-in Phase 16 Activity Mutual Interest Phase 17 Risk Phase 18 Appeal Phase 19 Admin Complete Phase 20 Analytics Phase 21 Account Lifecycle Phase 22 Ops/Deployment Phase 23 Full Testing Phase 24 UAT Phase 25 RC Phase 26 Production ``` --- # 第二百七十八章 Codex每次启动工作时 必须先阅读： ```text AGENTS.md docs/STATUS.md docs/PENDING_DECISIONS.md 本阶段相关设计文档 ``` 然后再改代码。 --- # 第二百七十九章 Codex发现旧代码与文档冲突 优先级： ```text 用户最新明确指令 > 本总指令 > 已确认专项设计 > 旧代码实现 ``` 不得因为： > “现在代码已经这样写了” 就倒逼修改产品规则。 --- # 第二百八十章 文档冲突处理 如果两个旧文档存在不一致： 优先： > 后续明确修正文档。 例如已明确： - Privacy默认值未确认 - Recommendation数量未确认 - Pass冷却未确认 不得引用旧示例当最终规则。 --- # 第二百八十一章 已知需要纠正的旧示例 Codex特别注意： 以下不是固定产品要求： ```text 每天6人 60分 照片最多6张 兴趣最多8个 180天Pass 所有Privacy默认true 活动男50女50 活动必须审核 活动互选只能1人 ``` 都必须配置/待确认。 --- # 第二百八十二章 不重复造轮子原则 使用成熟组件： - JWT/session库 - PostgreSQL driver - Redis library - Validation - Migration - WebSocket - Object Storage SDK 但核心业务规则： > 自己明确实现。 --- # 第二百八十三章 不引入完整婚恋开源项目替代业务 可以参考开源代码。 但不能为了快： > 把商业社交项目直接改皮肤。 因为产品逻辑差异很大。 --- # 第二百八十四章 核心开发哲学 本项目真正复杂的地方不是： > UI页面数量。 而是： ```text 状态 权限 双向关系 隐私 并发 线下闭环 ``` Codex投入重点必须放在这些地方。 --- # 第二百八十五章 研发优先级原则 如果时间不够： 先保证： ```text 正确 安全 完整 ``` 再做： ```text 动画 视觉细节 非必要运营功能 ``` --- # 第二百八十六章 后端优先于高级视觉 推荐流程、权限、活动容量等后端正确前： > 不要优先花时间做复杂UI动画。 --- # 第二百八十七章 V1不追求“智能感” 匹配系统只需要： > 准、稳定、解释清楚。 不需要到处写： > AI智能。 --- # 第二百八十八章 AI使用边界 V1可以未来使用AI： > 润色自我介绍等辅助。 但不得： - 自动虚构用户资料 - 自动代聊 - 自动决定Match - 自动判断婚姻幸福 --- # 第二百八十九章 对用户尊重 产品文案、标签不得： ```text 没人喜欢 低匹配用户 难匹配 条件太高 高价值 低质量 ``` --- # 第二百九十章 空候选文案 使用： > 暂时没有完全符合你条件的人。 然后提供： ```text 查看择偶条件 申请公益红娘 参加活动 ``` --- # 第二百九十一章 数据和用户不是商品 开发界面中不要使用： ```text 库存用户 优质资源 资源池等级 ``` 可以使用： ```text 候选用户 可匹配用户 用户池 ``` --- # 第二百九十二章 用户自主权最终红线 系统和工作人员不得替用户执行： ```text Like 确认成功牵手 主动发送私人聊天 ``` --- # 第二百九十三章 上线前产品验收 必须最终检查： > 页面是否仍符合公益定位。 如果最终UI变成： > Tinder/直播/商业婚介风格 即使功能全： > 也不合格。 --- # 第二百九十四章 上线前技术验收 必须： ```text Core E2E Pass Permission Pass Security Pass Concurrency Pass Backup Restore Pass Rollback Pass ``` --- # 第二百九十五章 上线前运营验收 必须： ```text 审核员会用 红娘会用 活动管理员会用 志愿者能签到 风控能处理举报 ``` --- # 第二百九十六章 项目最终交付物 Codex必须至少交付： ```text 完整源码 数据库Migration OpenAPI文档 Docker部署 CI配置 环境变量示例 测试代码 运营后台 微信小程序 数据库说明 部署说明 备份恢复说明 权限矩阵 测试报告 Release Notes ``` --- # 第二百九十七章 README 必须写清： ```text 项目是什么 技术栈 如何本地启动 环境变量 如何Migration 如何运行测试 如何Build 如何Deploy ``` --- # 第二百九十八章 一键本地启动 目标： ```text docker compose up ``` 可以启动必要基础设施。 应用本身根据技术栈一条标准命令运行。 --- # 第二百九十九章 新开发人员接手标准 一个新的研发人员： > 不依赖原作者口头解释。 通过： ```text README AGENTS Docs Migration Tests ``` 应能够理解并启动项目。 --- # 第三百章 最终完成标准 只有同时满足： ```text 用户端完整 后台完整 核心业务完整 权限正确 安全正确 测试通过 部署可用 备份恢复可用 文档完整 运营可以执行 ``` 才允许定义： > V1.0开发完成。 --- # 第三百零一章 Codex最终执行宣言 在整个开发过程中必须始终遵守： > **不要重新设计已经确认的产品。** > **不要擅自增加商业化功能。** > **不要为了开发方便降低安全要求。** > **不要把技术示例当成已经确认的业务规则。** > **所有未确认数量参数配置化。** > **用户Required绝不自动放宽。** > **没有双向意愿绝不创建聊天。** > **拉黑必须立即有效。** > **红娘只能辅助，不能替用户决定。** > **活动单向意愿必须保密。** > **后台人员只能看到完成工作必要的数据。** > **敏感数据默认拒绝访问。** > **数据库是业务事实源。** > **关键动作必须幂等、事务安全、可审计。** > **系统必须可以部署、升级、备份、恢复和回滚。** --- # 第三百零二章 Codex项目最终原则 整个项目只围绕一件事情设计： > **让丹阳本地真实单身用户，用最低的学习成本，在一个可信、安全、有公益组织参与的平台中，获得线上精准匹配、人工红娘辅助和线下公益活动服务。** 技术存在的目的不是增加复杂度。 算法存在的目的不是替用户选择。 红娘存在的目的不是替用户决定。 后台存在的目的不是让工作人员无限查看数据。 数据存在的目的不是建立用户价值等级。 因此V1.0最终开发原则可以浓缩为： > **真实身份是基础。** > **双向意愿是边界。** > **隐私安全是底线。** > **规则匹配是效率工具。** > **公益红娘是人工补位。** > **线下活动是服务延伸。** > **用户本人永远拥有最终决定权。** --- # 第三百零三章 Codex收到本文档后的第一条执行指令 Codex不得立即开始无序编码。 首先执行： ```text 1. 创建项目文档目录 2. 创建AGENTS.md 3. 创建STATUS.md 4. 创建PENDING_DECISIONS.md 5. 确认当前仓库是否已有代码 6. 输出当前代码基线审计 7. 确认最终技术栈 8. 建立Phase 01任务清单 9. 建立测试基础设施 10. 再开始Phase 01开发 ``` 如果仓库已经存在： > 不得直接推翻重写。 先进行： ```text 现状分析 ↓ 与V1规范Gap Analysis ↓ 保留可复用代码 ↓ 渐进重构 ``` --- # 第三百零四章 Codex首次仓库审计必须输出 ```text 当前技术栈 目录结构 已有模块 已有数据库 已有API 已有测试 已有部署 和V1需求一致的部分 存在冲突的部分 可复用部分 必须重构部分 风险 Phase 01建议 ``` --- # 第三百零五章 若仓库为空 则严格按照： > Phase 01 → Phase 26 顺序推进。 禁止： > Phase 01时顺手把后面所有功能都做一点。 --- # 第三百零六章 长期连续开发规则 每次任务结束必须留下： ```text Current Phase Completed Next Task Known Issues Pending Decisions Test Result ``` 保证下一次Codex恢复上下文时： > 可以从项目状态继续，而不是重新理解整个项目。 --- # 第三百零七章 最终交付原则 整个V1.0项目最终应呈现为： > **代码能运行。** > **文档能接手。** > **测试能证明。** > **部署能复现。** > **数据能恢复。** > **权限能控制。** > **业务能闭环。** > **运营能执行。** 这才是本项目真正意义上的“完成”。