danyang-match/docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词（整合版）.md

# “善缘丹阳”公益婚恋服务平台
# V1.1 WorkBuddy 最终主启动提示词（整合版）

版本：V1.1  
文档级别：最高优先级执行文件  
适用对象：WorkBuddy  
使用方式：首次正式启动开发时完整提供；后续每次继续开发前，先要求 WorkBuddy 读取仓库内的 `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 完成后必须停

WorkBuddy 不允许：

> 完成 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 = 用户唯一组织归属
```

不得继续作为产品数据边界。

---

# 第七十九部分：WorkBuddy 首轮执行流程

当你第一次拿到仓库时，只执行：

```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 完成。**

---

# 第九十八部分：给 WorkBuddy 的第一条最终指令

现在开始执行“善缘丹阳 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。

---

# 第九十九部分：WorkBuddy 完成报告必须回答

```text
本次具体完成了什么？
实际运行了哪些测试？
测试输出是什么？
有哪些代码/数据库变化？
有哪些安全影响？
有哪些待确认项？
是否破坏已有功能？
下一Phase是什么？
```

不能只回复：

> “已完成。”

---

# 第一百部分：最终执行宣言

整个项目开发过程中始终坚持：

> **V1.1 是当前唯一最新产品基线。**

> **V1.0 未被修订的核心安全和婚恋规则继续有效。**

> **不要重新设计已确认产品。**

> **不要为了实现方便弱化权限、隐私和双向意愿。**

> **不要把示例参数硬编码成产品规则。**

> **不要引入不必要的基础设施和AI复杂度。**

> **不要把公益平台做成商业Dating App。**

> **不要把综合公益服务做成复杂政务门户。**

> **所有新增服务必须真正形成用户端、后台端、数据、权限、测试的完整闭环。**

最终目标是交付：

> **一套真实、安全、本地、公益、易用，并能够支持线上匹配、人工红娘、线下活动、固定阵地、婚恋咨询、婚前辅导、反诈和婚俗新风持续运营的“善缘丹阳”公益婚恋服务平台。**