# “善缘丹阳”公益婚恋服务平台 # V1.1 Codex 最终主启动提示词（整合版） 版本：V1.1 文档级别：最高优先级执行文件 适用对象：Codex 使用方式：首次正式启动开发时完整提供；后续每次继续开发前，先要求 Codex 读取仓库内的 `AGENTS.md`、`docs/STATUS.md`、`docs/PENDING_DECISIONS.md`、`docs/JIRA_BACKLOG.md` 和本阶段相关设计文档。 核心原则：**以 V1.1 为当前唯一最新产品基线，V1.0 中未被 V1.1 修订的核心规则继续有效。** --- # 第一部分：你的任务 你现在负责完整开发正式项目： > **善缘丹阳——丹阳公益婚恋服务平台 V1.1** 这不是 Demo、原型或单纯页面项目。 你需要持续完成一套： ```text 微信小程序用户端 + 统一 Web 运营后台 + 公益红娘工作台 + 公益咨询工作台 + 活动与服务站工作台 + 平台管理后台 + 后端服务 + PostgreSQL + Redis + 私有对象存储 + WebSocket + 测试体系 + 部署、备份、恢复、监控体系 ``` 最终必须达到： > 可运行、可测试、可部署、可运营、可维护、可升级、可恢复。 --- # 第二部分：产品最新正式定位 “善缘丹阳”不是单纯的相亲小程序。 正式定位为： > **面向丹阳本地适龄单身人群，由公益组织参与运营，集实名认证、本地资格核验、人工资料审核、双向婚恋匹配、安全沟通、公益红娘、线下公益活动、固定服务阵地、婚恋咨询、婚前辅导、婚恋课堂、婚恋反诈和婚俗新风于一体的本地公益婚恋综合服务平台。** 项目最新计划明确要求形成“婚前交友—婚恋辅导—婚俗新风”全链条服务，并依托万善公园婚姻登记处等固定阵地开展常态化服务。 --- # 第三部分：项目核心价值 所有实现必须服务于： ```text 真实 公益 本地 安全 高效 尊重用户自主决定 ``` --- # 第四部分：最重要的产品红线 以下规则不可擅自修改。 ## 1. 用户基础婚恋服务永久免费 禁止： ```text VIP 会员 金币 积分商城 礼物 付费曝光 付费聊天 付费联系方式 超级喜欢收费 Boost 支付系统 ``` --- ## 2. 必须实名 用户进入婚恋匹配服务前需要： ```text 微信登录 + 手机号 + 实名认证 + 本地资格 + 婚恋资料 + 人工审核 ``` --- ## 3. 实名不等于婚姻状态官方核验 “已实名”仅代表： > 身份已核验。 不得宣传： ```text 100%真实 100%单身 官方单身认证 婚姻状态官方已核验 ``` --- ## 4. 本地资格和实名认证必须分开 本地资格用于确认： ```text 丹阳户籍 丹阳工作 丹阳长期居住 其他符合本项目服务条件 ``` 不得把它简单塞进实名认证字段。 --- ## 5. Required 绝不自动放宽 用户择偶规则： ```text 必须符合 最好符合 ``` 其中： > `必须符合 = Hard Constraint` 系统、算法、红娘、后台都不能静默放宽。 --- ## 6. 双向 Like 才能建立普通婚恋 Match ```text A Like B + B Like A = Mutual Match ``` 单向 Like： > 不能聊天。 --- ## 7. Block 优先级最高 任意一方 Block 后： ```text 停止聊天 停止推荐 停止搜索展示 停止红娘候选 停止进一步关系互动 ``` Unblock： > 不自动恢复旧 Match、Like 或 Conversation。 --- ## 8. 红娘只能辅助 红娘可以： ```text 查看必要资料 查看系统候选 人工推荐 提出择偶条件建议 推荐活动 转介咨询 跟进服务 ``` 红娘不能： ```text 替用户Like 替用户Pass 替用户确认成功牵手 查看私人聊天 查看完整身份证 私自泄露手机号/微信 绕过Required强推 ``` --- ## 9. 普通后台人员不能默认读取私人聊天 私人聊天只有在： > 风控案件 + 明确业务目的 + 对应权限 + 审计 下才能有限访问。 --- ## 10. 咨询和红娘是两个不同业务域 不得把婚恋咨询塞进红娘 Notes。 咨询人员和红娘： > 权限、数据范围、服务记录必须分离。 --- ## 11. 活动单向意向必须保密 A 在活动后选择 B： > 如果 B 没有选择 A，B 不得知道。 --- ## 12. 活动 Mutual Interest 不能直接创建 Chat V1.1 最新正式规则： ```text A选择B + B选择A = Mutual Activity Interest ↓ 双方分别确认“愿意开启线上沟通” ↓ 双方均确认 ↓ 创建新的 Match Episode ↓ 创建 Conversation ``` 这一规则替代所有旧版： ```text activity mutual → match → chat ``` 逻辑。 --- ## 13. 成功牵手必须双向确认 一方发起： > 另一方确认。 管理员、红娘、系统都不能替用户确认。 --- ## 14. 敏感信息默认拒绝 以下默认不可见： ```text 完整身份证 完整手机号 私人聊天 咨询敏感记录 举报证据 本地资格原始证明 精确住址 ``` --- # 第五部分：V1.1 首页最新唯一结构 旧首页实现废弃。 正式首页必须按以下顺序： ```text 顶部品牌 ↓ 用户状态 ↓ Banner ↓ 8个核心入口 ↓ 今日推荐 ↓ 善缘公益服务 ↓ 近期公益活动 ↓ 善缘服务站 ↓ 婚恋课堂 ↓ 安全提醒 ``` --- # 第六部分：首页 8 个核心入口 第一排固定： ```text 找对象 公益红娘 公益活动 婚恋咨询 ``` 第二排固定： ```text 婚恋课堂 婚前辅导 婚恋反诈 善缘服务站 ``` 不要允许运营人员随意删除或重排。 --- # 第七部分：首页 Banner Banner 属于正式 V1.1 核心能力。 支持： ```text 品牌 重点活动 公益红娘 婚恋咨询 婚前辅导 服务站 婚恋反诈 婚俗新风 重要公告 ``` 必须支持： ```text 图片 标题 副标题 按钮 内部目标 开始时间 结束时间 排序 受众状态 上下架 ``` 禁止任意外部 URL。 --- # 第八部分：用户端固定底部导航 严格固定： ```text 首页 找对象 消息 活动 我的 ``` 不新增第六个 Tab。 --- # 第九部分：善缘服务站 V1.1 正式增加： > **善缘丹阳公益服务站** 当前核心线下阵地： > 万善公园婚姻登记处。 计划书明确把该阵地作为常态化驻点服务空间。 用户端至少支持： ```text 服务站详情 地址 开放时间 联系电话 地图导航 服务项目 预约 ``` --- # 第十部分：婚恋咨询 V1.1 正式新增。 支持： ```text 择偶困惑 沟通相处 情感困惑 婚恋焦虑 关系冲突 其他公益婚恋指导 ``` 但： > 不建设医疗诊疗系统。 V1.1 不建设咨询即时 IM。 采用： ```text 服务介绍 ↓ 申请 ↓ 分配 ↓ 预约 ↓ 线下/电话/约定方式服务 ↓ 必要摘要 ↓ 完成 ``` --- # 第十一部分：婚前辅导 婚前辅导作为： > CounselingService 的一个正式服务类型。 不要再单独创建一整套重复系统。 可以包括： ```text 关系沟通 家庭责任 家庭边界 财务与生活规划 冲突处理 文明婚嫁 ``` --- # 第十二部分：婚恋课堂、婚恋反诈、婚俗新风 统一使用轻量 Content 模块。 用户端： ```text 内容列表 内容详情 ``` 后台： ```text 创建 编辑 发布 下架 ``` 明确不做： ```text 评论 点赞 粉丝 Feed 用户投稿 热搜 排行榜 ``` --- # 第十三部分：多类型公益活动 Activity 正式支持： ```text matchmaking interest_social relationship_education premarital_guidance marriage_custom_culture anti_fraud ``` 前台中文： ```text 公益联谊 兴趣交友 婚恋课堂 婚前辅导 婚俗新风 反诈科普 ``` --- # 第十四部分：活动报名规则必须按类型配置 相亲联谊可以要求： ```text 实名认证 本地资格 资料审核 当前婚恋服务能力 ``` 反诈课堂等可使用更宽松规则。 不得写死所有活动同一资格。 --- # 第十五部分：活动容量 不默认使用： ```text male_limit female_limit ``` 正式设计： ```text total_capacity + 可选 capacity groups ``` 只有具体活动确实需要分组容量时才配置。 --- # 第十六部分：专项公益服务 新增 ServiceProgram。 用于： ```text 职工关爱 青年公益婚恋 异地务工青年服务 残障人士公益支持 其他专项公益项目 ``` 不得把 Program 变成： ```text 高价值用户 低价值用户 困难匹配用户 ``` --- # 第十七部分：多组织协同 支持： ```text 主办 联合主办 运营 合作 场地合作 ``` 但： > 组织关系不自动授予用户数据权限。 权限仍由： ```text Operator + Role + Permission + DataScope ``` 控制。 --- # 第十八部分：技术总体架构 如果仓库为空，推荐： ## Backend ```text Java 21 Spring Boot 3.x Spring Security PostgreSQL Redis WebSocket Flyway S3-Compatible Private Object Storage ``` ## Admin Web ```text Vue 3 TypeScript Vite Pinia Element Plus ``` ## Mini Program ```text 微信原生小程序 + TypeScript ``` ## Deployment ```text Docker Docker Compose Nginx PostgreSQL Redis Private Object Storage ``` --- # 第十九部分：禁止过度架构 V1.1 不主动引入： ```text Kubernetes Kafka RabbitMQ（除非后续明确需要） Elasticsearch ClickHouse Neo4j Milvus Service Mesh 微服务拆分 复杂工作流引擎 ``` --- # 第二十部分：后端继续使用模块化单体 至少领域模块： ```text Auth User Verification LocalEligibility Profile Review Match Relationship Messaging Activity Matchmaker Counseling ServiceLocation ServiceAppointment Content ServiceProgram Risk Notification Organization Permission Analytics Audit Config Banner ``` --- # 第二十一部分：模块边界 禁止： > 一个模块直接跨模块写另一模块数据库表。 使用： ```text Application Service Domain Service 明确接口 ``` --- # 第二十二部分：数据库 Source of Truth 所有正式业务事实： > PostgreSQL。 Redis 只允许： ```text Cache Session Rate Limit WebSocket辅助 短期状态 ``` --- # 第二十三部分：V1.1 新增核心表 在 V1.0 基础上正式新增： ```text home_banners service_locations service_appointments counseling_services counseling_followups content_categories content_articles user_local_eligibilities local_eligibility_evidences service_programs service_program_members organization_relationships activity_organizations activity_mutual_connection_consents ``` --- # 第二十四部分：不得重复建模 已有： ```text users organizations activities risk notifications files audit ``` 必须复用。 不要为了新需求重新创建： ```text new_users partner_org_users special_activity_users ``` 之类重复体系。 --- # 第二十五部分：本地资格 正式数据模型： ```text user_local_eligibilities local_eligibility_evidences ``` 先允许用户声明： ```text 丹阳户籍 丹阳工作 丹阳居住 其他 ``` 只有在需要时补充佐证。 --- # 第二十六部分：人脸核验 项目计划书提出加强身份真实性核验。 当前开发规则： > 只预留接口/状态。 不得自行实现： ```text Face Embedding 人脸模板数据库 自研人脸识别 ``` 如未来启用： > 使用合规第三方 Provider。 --- # 第二十七部分：匹配算法 继续使用： ```text Eligibility ↓ A Required ↓ B Required ↓ Directional Score ↓ Mutual Score ↓ Ranking ↓ Reasons ``` 不得换成黑盒 AI。 --- # 第二十八部分：推荐算法禁止使用 ```text 财富 房产 车辆 颜值 公司级别 职位高低 人气 ``` 作为价值排序。 --- # 第二十九部分：前台推荐不显示数字匹配率 只显示： ```text 很合适 比较合适 值得了解 ``` 以及真实理由。 --- # 第三十部分：聊天 继续： ```text REST Send + WebSocket Receive ``` 支持： ```text 文字 图片 Emoji 系统消息 未读 历史 失败重试 ``` 不做： ```text 语音通话 视频 群聊 红包 转账 位置 文件 AI代聊 正在输入 公开已读回执 ``` --- # 第三十一部分：消息幂等 必须： ```text senderId + clientMessageId ``` 唯一。 --- # 第三十二部分：Match 历史 必须支持： > Match Episode。 一对用户不能设计成 lifetime 只能有一个 Match。 例如： ```text 曾经Unmatch ↓ 未来合法重新形成关系 ↓ 创建新Episode ``` --- # 第三十三部分：活动 Match Activity Mutual 后： > 双方确认沟通。 如果双方已有 active Match： > 复用现有聊天。 如果以前已 Unmatch： > 创建新 Episode。 --- # 第三十四部分：统一权限 所有后台人员都使用： ```text operators ``` 不要建多套账号表。 --- # 第三十五部分：角色建议 ```text super_admin platform_admin organization_admin reviewer matchmaker activity_manager risk_operator volunteer data_viewer service_station_operator counselor counseling_manager content_editor ``` 实际一个 Operator 可以拥有多个 Role。 --- # 第三十六部分：权限三层 必须： ```text RBAC + Data Scope + Sensitive Permission ``` 菜单隐藏不等于权限完成。 所有 API 服务端检查。 --- # 第三十七部分：新增角色的最小权限 ## Counselor 只看： > assigned counseling services。 ## Content Editor 默认： > 零用户婚恋数据权限。 ## Service Station Operator 只能： > 处理服务预约/指定现场任务。 不能全库搜索用户。 --- # 第三十八部分：敏感访问 完整身份证、本地资格原始证明、案件聊天、咨询敏感备注等： 必须： ```text 特殊权限 + 业务理由 + SensitiveAccessLog ``` --- # 第三十九部分：日志禁止内容 禁止： ```text 完整身份证 完整手机号 AccessToken RefreshToken 密码 私人聊天正文 咨询逐字内容 举报完整证据 本地资格证明内容 ``` --- # 第四十部分：首页聚合接口 推荐： ```text GET /api/v1/home ``` 由： > HomeApplicationService 聚合。 返回： ```text userState banners quickEntries recommendations serviceRecommendations activities serviceLocation articles safetyNotice ``` 但 Home 不能复制业务规则。 --- # 第四十一部分：Quick Entry 8 个入口： > 不需要数据库动态配置。 可以由： ```text 前端固定结构 + Feature Flag + Capability ``` 控制可用状态。 --- # 第四十二部分：用户状态由服务端 Capability 决定 建议统一： ```text CapabilityService ``` 返回： ```text canReceiveRecommendations canSearchUsers canLike canChat canApplyMatchmakingActivity canApplyCounseling canApplyMatchmaker ``` 前端不自行拼状态判断。 --- # 第四十三部分：V1.1 页面新增 在原 U01～U48 基础上： ```text U49 公益服务中心 U50 善缘服务站 U51 服务预约 U52 我的预约 U53 婚恋课堂 U54 内容详情 U55 婚恋咨询 U56 申请婚恋咨询 U57 我的婚恋咨询 U58 婚前辅导 U59 婚前辅导申请 U60 婚恋反诈 U61 专项公益服务 U62 本地资格说明 U63 本地资格补充 U64 公益服务记录 ``` --- # 第四十四部分：我的页面 正式结构： ```text 身份状态 ↓ 我的资料 择偶条件 我的缘分 ↓ 我的红娘 我的咨询 我的活动 我的预约 公益服务记录 ↓ 隐私设置 黑名单 举报与安全 账号设置 ↓ 婚恋课堂 婚恋反诈 善缘服务站 关于善缘丹阳 ``` --- # 第四十五部分：前端 UI 核心风格 必须： ```text 温暖 可信 公益 清爽 现代 本地 克制浪漫 ``` 避免： ```text 夜店风 网红粉 大爱心 金币 皇冠 火焰 商业婚介豪华感 老式政务门户感 ``` --- # 第四十六部分：首页高保真必须按定稿 第一屏： > 品牌 + Banner + 核心入口。 不能让 Banner 太高导致用户看不到入口。 --- # 第四十七部分：Design Token 统一使用 Token。 禁止： > 每页面硬编码颜色、圆角、间距。 --- # 第四十八部分：前端必须具备 ```text Loading Skeleton Empty Error Retry Disabled Reason Success Feedback ``` --- # 第四十九部分：服务站、咨询等不允许“伪完成” 例如： 如果只做： > 服务站介绍页 却没有预约/后台处理： > 不算服务站功能完成。 如果只做： > 婚恋咨询介绍 没有申请、分配、完成： > 不算咨询功能完成。 --- # 第五十部分：V1.1 正式 Phase 顺序 严格按： ```text Phase 01 项目基础架构 Phase 02 Auth + Operator + RBAC Phase 03 实名认证 Phase 04 Profile + Preference + 本地资格 Phase 05 审核 Phase 06 Match Engine Phase 07 V1.1首页 + 找对象 Phase 08 Like / Match / Block Phase 09 Text Chat Phase 10 Image & Chat Safety Phase 11 Notification Phase 12 Relationship Progress Phase 13 公益红娘 Phase 13A 公益咨询与婚前辅导 Phase 14 多类型公益活动 Phase 15 活动签到 Phase 16 活动互选 + 双向沟通确认 Phase 17 举报与风控 Phase 18 申诉 Phase 19 统一运营后台 + Banner + 内容 + 服务站 + 专项项目 Phase 20 Analytics Phase 21 Account Lifecycle Phase 22 Deployment / Ops Phase 23 System Testing Phase 24 UAT Phase 25 RC Phase 26 Production ``` --- # 第五十一部分：每个 Phase 完成后必须停 Codex 不允许： > 完成 Phase 01 后自动开始 Phase 02。 必须输出： ```text Phase XX Completion Report ``` 然后等待下一条开发指令。 --- # 第五十二部分：Completion Report 格式 ```markdown # Phase XX Completion Report ## Status Completed / Partial / Blocked ## Implemented ## Database Changes ## API Changes ## Frontend Changes ## Automated Tests ## Manual Verification ## Permission & Security Verification ## Known Issues ## Pending Decisions ## Regression Results ## Documentation Updated ## Next Phase ``` --- # 第五十三部分：Definition of Done 一个 Story/Task 只有同时满足： ```text 代码完成 测试完成 Lint通过 Build通过 Migration通过 相关权限验证通过 OpenAPI更新 文档更新 Regression通过 ``` 才算 Done。 --- # 第五十四部分：禁止“代码写完=完成” 如果未跑测试： > 不得宣称完成。 如果未做权限测试： > 涉及后台功能不得宣称完成。 如果有 Migration 未验证： > 不得宣称完成。 --- # 第五十五部分：永久核心 Invariants CI 必须保护： ```text INV-001 Required不可自动放宽 INV-002 未Mutual不可聊天 INV-003 Block后双方不可互动 INV-004 并发Like只生成一个Match INV-005 Activity容量不可超卖 INV-006 单向Activity Interest不可泄露 INV-007 红娘不能替用户Like INV-008 未授权Operator不能读取身份证 INV-009 非案件上下文不能读取私人聊天 INV-010 跨组织不能越权 INV-011 未授权不能查看本地资格证明 INV-012 Counselor只能读取Assigned Service INV-013 Matchmaker不能读取Counseling正文 INV-014 Activity Mutual不能直接创建Match INV-015 双方确认后才创建Activity Match INV-016 Banner不能任意外链 INV-017 首页8核心入口顺序固定 INV-018 ServiceStationOperator不能浏览全用户库 INV-019 ContentEditor不能访问用户婚恋档案 INV-020 Sponsor组织关系不自动赋予用户访问权限 ``` --- # 第五十六部分：关键事务 以下必须事务安全： ```text Mutual Match创建 活动最后名额批准 Review Claim Successful双确认 RiskAction Activity双方沟通确认→Match ``` --- # 第五十七部分：通知和推送必须在事务后 例如： ```text 创建Match ↓ 事务Commit ↓ Notification ↓ WebSocket ``` 通知失败： > 不回滚核心Match。 --- # 第五十八部分：V1.1 测试优先级 最高优先： ```text 权限 隐私 数据一致性 Match Block Chat 本地资格 活动容量 活动互选同意 咨询权限 ``` 之后： ```text Banner 内容 统计 UI细节 ``` --- # 第五十九部分：上线阻断项 存在以下任一项： > NO-GO。 ```text 未Mutual可聊天 Block无效 重复Match 活动超卖 单向活动意向泄露 Activity Mutual直接Chat 咨询人员可看非Assigned服务 红娘可看咨询正文 服务站人员可看身份证 本地资格佐证公网可访问 Banner可跳任意外链 跨组织敏感数据越权 数据库无备份 恢复未验证 无法Rollback ``` --- # 第六十部分：Analytics 最新要求 除了原婚恋核心指标，新增： ```text 服务站访问 服务预约 咨询申请 咨询完成 婚前辅导 公益课堂 反诈内容 专项服务 用户来源 ``` 必须区分： ```text 服务用户数 服务人次 ``` --- # 第六十一部分：活动互选不等于成功 必须区分： ```text Activity Interest Mutual Activity Interest Bilateral Connection Consent Match Two-Way Chat Successful ``` 统计不得混淆。 --- # 第六十二部分：有效交友匹配 计划书提出“有效交友匹配”目标。 当前建议技术指标： ```text Mutual Match + Two-Way Chat Started ``` 但正式项目报送口径仍需运营确认。 因此： > 口径版本化，不擅自永久固化。 --- # 第六十三部分：服务数据留痕 必须记录： ```text 谁被服务 什么服务 什么时候 哪个工作人员 结果摘要 下一步 ``` 不得默认记录： > 所有私人交谈全文。 --- # 第六十四部分：线下服务和线上系统必须打通 核心路径： ```text 群众到万善公园 ↓ 扫码进入善缘丹阳 ↓ 注册/登录 ↓ 预约/报名 ↓ 工作人员后台处理 ↓ 到场 ↓ 服务完成 ↓ 系统留痕 ``` 不能再建立独立 Excel 作为正式事实源。 --- # 第六十五部分：微信群只属于运营渠道 可以运营官方微信群。 但： > 小程序/后台才是正式档案和业务事实系统。 V1.1 不开发微信群机器人、群聊同步或开放社区。 --- # 第六十六部分：新增第三方依赖规则 任何依赖必须： ```text 活跃维护 License清晰 国内可用 安全 非必要不引入 ``` 新增依赖必须登记： ```text docs/DEPENDENCIES.md ``` --- # 第六十七部分：Secret 严格禁止进入 Git： ```text 数据库密码 JWT Secret 微信Secret 实名Provider Secret Object Storage Secret ``` --- # 第六十八部分：生产禁止 Debug Production： ```text 无Mock实名 无测试API 无默认密码 无公开Swagger管理接口 无Debug模式 ``` --- # 第六十九部分：部署 正式继续采用： ```text Nginx + Backend Container + Admin Static Build + PostgreSQL + Redis + Private Object Storage ``` --- # 第七十部分：必须实现 ```text /health/live /health/ready /version ``` --- # 第七十一部分：备份 必须： ```text 自动备份 独立存储 加密 实际Restore验证 ``` 只有备份文件存在： > 不算完成。 --- # 第七十二部分：Rollback 每次生产发布： > 必须明确上一个稳定版本。 数据库优先采用： > 向前兼容 Migration。 --- # 第七十三部分：Feature Flags 至少： ```text counselingEnabled premaritalEnabled serviceLocationEnabled contentEnabled localEligibilityEnabled imageChatEnabled matchmakerEnabled activityEnabled ``` Feature Flag： > 用于灰度和故障关闭。 不是把已确认功能永久推迟的借口。 --- # 第七十四部分：PENDING_DECISIONS 最新列表 至少包含： ```text 人脸核验是否首发强制 人脸Provider 本地资格佐证触发策略 本地资格文件保留期限 咨询服务人员实际资质要求 服务站正式开放时间 服务预约时段规则 Banner最大活跃数量 推荐每日数量 推荐阈值/最终权重 Pass冷却 照片上限 有效交友匹配正式报送口径 申诉是否V1.1首发 ``` --- # 第七十五部分：Confirmed 列表 以下不得再放 Pending： ```text 善缘丹阳品牌 首页Banner 首页8核心入口 善缘服务站 婚恋咨询 婚前辅导 婚恋课堂 婚恋反诈 多类型活动 活动双向沟通确认 Required不可放宽 Mutual后才能普通Chat Block优先 ``` --- # 第七十六部分：文档冲突处理顺序 以后如发现冲突： ```text 用户最新明确指令 > 本V1.1最终主启动提示词 > V1.1专项修订文件 > V1.0未被修改的核心设计 > 旧代码 > 技术示例 ``` --- # 第七十七部分：旧代码和新规范冲突 不能因为： > “旧代码已经这样写” 就继续旧逻辑。 必须： ```text Gap Analysis ↓ KEEP / EXTEND / REFACTOR / REPLACE / ADD ↓ 渐进迁移 ``` --- # 第七十八部分：已知必须替换的旧逻辑 如果发现： ```text 旧Home = Recommendation only ``` 标记： > REPLACE。 如果发现： ```text Activity mutual → Match ``` 标记： > REFACTOR。 如果发现： ```text users.organization_id = 用户唯一组织归属 ``` 不得继续作为产品数据边界。 --- # 第七十九部分：Codex 首轮执行流程 当你第一次拿到仓库时，只执行： ```text 1. 仓库审计 2. V1.0→V1.1 Gap Analysis 3. 技术栈确认 4. 更新AGENTS.md 5. 更新STATUS.md 6. 更新PENDING_DECISIONS.md 7. Merge最新JIRA_BACKLOG 8. 建立测试骨架 9. 拆解Phase 01 10. 完成Phase 01 11. 运行全部Phase 01测试 12. 输出Phase 01 Completion Report ``` 然后停止。 --- # 第八十部分：仓库审计输出 必须包括： ```text 技术栈 目录结构 已有模块 数据库 API 前端 测试 CI/CD 部署 安全 依赖 ``` 以及： ```text KEEP EXTEND REFACTOR REPLACE ADD ``` --- # 第八十一部分：Gap Analysis 特别检查 必须重点检查： ```text Home Banner Local Eligibility Counseling Service Station Content Activity Type Activity Mutual Consent Organization Scope Analytics ``` --- # 第八十二部分：Phase 01 不允许跨阶段开发 Phase 01 完成后： > 不自动开发 Phase 02。 即使你“顺手可以做”。 --- # 第八十三部分：每次继续开发前 读取： ```text AGENTS.md docs/STATUS.md docs/PENDING_DECISIONS.md docs/JIRA_BACKLOG.md 相关ADR 本Phase专项设计 ``` --- # 第八十四部分：每次结束留下长期记忆 更新： ```text Current Phase Completed Next Task Known Issues Pending Decisions Test Results Migration Version Release State ``` --- # 第八十五部分：开发哲学 本项目真正复杂之处： ```text 权限 隐私 双向关系 状态 并发 线上线下服务 多角色协同 ``` 不是： > 页面数量。 --- # 第八十六部分：不要为了“智能”增加AI V1.1 不需要： ```text AI推荐婚姻幸福 AI自动配对象 AI代聊 AI判断用户价值 ``` 匹配： > 用透明规则。 AI若未来用于润色： > 不得虚构资料。 --- # 第八十七部分：不要为了运营做复杂超级后台 后台第一目标： > 工作人员今天知道自己要做什么。 不是： > 展示几十个漂亮图表。 --- # 第八十八部分：后台工作台原则 Reviewer： > 待审核。 Matchmaker： > 待服务、待跟进。 Counselor： > 今日预约、待服务。 Service Station： > 今日预约、待确认。 Activity Manager： > 报名、签到。 Risk： > 高风险、待处理。 --- # 第八十九部分：用户体验原则 普通用户应该： > 不培训就能使用。 表单： > 尽量选择，不长输入。 重要页面： > 一步一个任务。 --- # 第九十部分：首页体验原则 用户打开后 5 秒内应该知道： ```text 这是丹阳本地公益婚恋平台 可以找对象 有公益红娘 有活动 有咨询 有真实线下服务站 有反诈保障 ``` --- # 第九十一部分：禁止商业化文案 禁止： ```text 优质男神 高价值女性 热门异性 桃花爆棚 脱单率92% VIP推荐 ``` --- # 第九十二部分：禁止绝对安全承诺 禁止： ```text 100%安全 绝无骗子 100%真实 ``` 使用： ```text 实名认证 人工审核 持续风控 公益服务 ``` --- # 第九十三部分：安全提示 用户首次查看详情/Chat时可轻量提示： > 实名认证和人工审核能够提升信息真实性，交往过程中仍请谨慎涉及借款、投资及个人隐私。 --- # 第九十四部分：用户自主权 系统和工作人员不得替用户执行： ```text Like 确认成功 活动开启沟通确认 私人聊天 ``` --- # 第九十五部分：最终 V1.1 产品闭环 ```text 公益品牌触达 ↓ 微信注册 ↓ 实名认证 ↓ 本地资格 ↓ 资料与择偶条件 ↓ 人工审核 ↓ 首页Banner/主要入口 ↓ 线上推荐/找对象 ↓ Like ↓ Mutual ↓ Chat ↓ ├ 公益红娘 ├ 公益活动 ├ 婚恋咨询 └ 善缘服务站 ↓ 进一步了解 ↓ 婚前辅导 ↓ 双方确认关系进展 ↓ 婚俗新风服务 ``` --- # 第九十六部分：最终 V1.1 运营闭环 ```text 妇联/工会/民政/团委/公益组织/企业等渠道 ↓ 活动/二维码/服务站 ↓ 用户进入善缘丹阳 ↓ 系统准入 ↓ 匹配与人工服务 ↓ 活动/咨询/服务站 ↓ 服务留痕 ↓ 风险处理 ↓ 公益数据统计 ↓ 项目成果报送 ``` --- # 第九十七部分：V1.1 最终验收标准 只有同时满足： ```text 婚恋核心闭环可运行 + V1.1首页完成 + 本地资格完成 + 善缘服务站完成 + 服务预约完成 + 婚恋咨询完成 + 婚前辅导完成 + 婚恋课堂完成 + 婚恋反诈完成 + 多类型公益活动完成 + 活动双方沟通确认完成 + 后台权限正确 + 统计正确 + 测试通过 + 部署可复现 + 备份可恢复 ``` 才允许定义： > **善缘丹阳 V1.1 完成。** --- # 第九十八部分：给 Codex 的第一条最终指令 现在开始执行“善缘丹阳 V1.1”。 本轮严格执行： ```text 1. 读取当前仓库 2. 完整审计 3. 输出 V1.0→V1.1 Gap Analysis 4. 将本文件规则写入 AGENTS.md 5. 更新 STATUS.md 6. 更新 PENDING_DECISIONS.md 7. 合并 V1.1 Jira Backlog 8. 建立/校验测试骨架 9. 输出最终技术栈基线 10. 拆解 Phase 01 11. 完成 Phase 01 12. 运行 Phase 01 全部测试 13. 更新 OpenAPI / Migration / CHANGELOG 14. 输出 Phase 01 Completion Report ``` 完成后： > **立即停止。** 不要自动开始 Phase 02。 --- # 第九十九部分：Codex 完成报告必须回答 ```text 本次具体完成了什么？ 实际运行了哪些测试？ 测试输出是什么？ 有哪些代码/数据库变化？ 有哪些安全影响？ 有哪些待确认项？ 是否破坏已有功能？ 下一Phase是什么？ ``` 不能只回复： > “已完成。” --- # 第一百部分：最终执行宣言 整个项目开发过程中始终坚持： > **V1.1 是当前唯一最新产品基线。** > **V1.0 未被修订的核心安全和婚恋规则继续有效。** > **不要重新设计已确认产品。** > **不要为了实现方便弱化权限、隐私和双向意愿。** > **不要把示例参数硬编码成产品规则。** > **不要引入不必要的基础设施和AI复杂度。** > **不要把公益平台做成商业Dating App。** > **不要把综合公益服务做成复杂政务门户。** > **所有新增服务必须真正形成用户端、后台端、数据、权限、测试的完整闭环。** 最终目标是交付： > **一套真实、安全、本地、公益、易用，并能够支持线上匹配、人工红娘、线下活动、固定阵地、婚恋咨询、婚前辅导、反诈和婚俗新风持续运营的“善缘丹阳”公益婚恋服务平台。**