danyang-match/WorkBuddy开发执行总指令、项目规则与任务拆解.md

# 丹阳公益婚恋服务平台
# V1.0 WorkBuddy开发执行总指令、项目规则与任务拆解

版本：V1.0  
文档级别：最高优先级开发执行文件  
适用对象：WorkBuddy、研发人员、测试人员、后续维护人员  
执行原则：严格继承既有设计，不擅自扩展，不擅自删减，不擅自重新定义产品

---

# 第一章 文档定位

本文件用于指导WorkBuddy完整开发：

> 丹阳公益婚恋服务平台 V1.0

本文件不是普通PRD。

它同时承担：

```text
产品总约束
+
技术总约束
+
开发顺序
+
项目长期记忆
+
不可变规则
+
验收标准
+
任务拆解
```

WorkBuddy在整个项目开发周期内，应将本文件视为：

> **项目最高执行规则。**

---

# 第二章 总开发目标

开发一套：

> 面向丹阳市成年单身人士，由公益组织参与运营的实名制公益婚恋服务平台。

核心服务路径：

```text
实名认证
↓
人工资料审核
↓
系统精准匹配
↓
用户双向喜欢
↓
平台内安全聊天
↓
公益红娘辅助
↓
公益线下相亲活动
↓
双方进一步了解
↓
成功牵手
```

---

# 第三章 产品核心定位

正式定位：

> 面向丹阳市成年单身人士，由公益组织参与运营的实名制公益婚恋服务平台，通过实名认证、人工审核、智能匹配、双向喜欢、在线沟通、公益红娘和线下相亲活动，帮助本地单身人士安全、高效、真实地寻找合适伴侣。

核心价值：

```text
真实
公益
本地
安全
高效
```

---

# 第四章 V1最高产品原则

所有研发决策必须服从：

> 用户简单易用。

> 工作人员容易运营。

> 数据安全优先。

> 用户自主决定。

> 系统帮助而不是操控。

> 公益属性优先。

> 本地服务优先。

> 低开发复杂度。

> 易维护、易升级。

---

# 第五章 明确禁止偏离产品方向

WorkBuddy不得将平台开发成：

```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：

> 可参与评分。

WorkBuddy不得把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
```

尚未锁死。

WorkBuddy如果当前仓库没有既有技术栈：

优先建议：

> 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

具体表结构由WorkBuddy合理实现。

---

# 第九十四章 Pass

需要预留：

```text
expires_at
```

但冷却周期：

> 配置。

---

# 第九十五章 AccountStatus

技术状态：

```text
normal
reviewing_risk
limited
suspended
banned
closed
```

属于建议技术模型。

如果WorkBuddy优化命名：

> 语义必须一致。

---

# 第九十六章 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细节
```

---

# 第一百二十章 WorkBuddy开发模式

WorkBuddy必须采用：

> 分阶段、可运行、可验证。

禁止：

> 一次生成全项目大量代码然后最后统一调试。

---

# 第一百二十一章 每阶段基本流程

每一个阶段执行：

```text
读取本阶段规则
↓
确认相关数据模型
↓
建立测试
↓
实现后端
↓
实现前端
↓
运行测试
↓
验证核心流程
↓
更新开发记录
↓
进入下一阶段
```

---

# 第一百二十二章 不允许静默改变需求

如果WorkBuddy发现：

- 规则冲突
- 前文未确认
- 技术实现存在多种方案

必须：

> 保持原需求。

对于未确认内容：

标记：

```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
```

---

# 第一百三十一章 WorkBuddy项目记忆文件

建议仓库根目录建立：

```text
AGENTS.md
```

用于放：

> WorkBuddy执行规则摘要。

---

# 第一百三十二章 AGENTS.md必须写入

至少：

```text
不得改变V1范围
Required不可放宽
Mutual后才能聊天
红娘不可替用户操作
隐私最小化
禁止VIP/付费
禁止陌生人私信
禁止管理员默认查看聊天
模块化单体
不引入微服务/K8s
```

---

# 第一百三十三章 STATUS.md

建议：

```text
docs/STATUS.md
```

记录：

```text
已完成
开发中
未开始
已知问题
待确认事项
```

WorkBuddy每阶段更新。

---

# 第一百三十四章 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明确不做列表

WorkBuddy遇到以下需求不得自行开发：

```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

WorkBuddy必须在代码、测试中明确保护以下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
敏感访问
系统配置
匹配规则
```

---

# 第一百九十九章 测试优先要求

每完成模块：

WorkBuddy必须运行：

> 相关测试。

不得直到最后一次性运行。

---

# 第二百章 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。

---

# 第二百零九章 WorkBuddy每阶段输出要求

每完成一个阶段：

更新：

```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首发
```

---

# 第二百一十三章 WorkBuddy不得把待确认项硬编码

必须：

- 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

WorkBuddy新增开源库时：

必须确认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
```

并排除：

- 推荐
- 统计
- 用户搜索

---

# 第二百四十三章 数据统计必须排除测试账号

否则运营指标污染。

---

# 第二百四十四章 小程序发布前

WorkBuddy必须准备：

```text
微信合法域名清单
API域名
Upload域名
Download域名
WebSocket域名
隐私配置清单
```

---

# 第二百四十五章 小程序权限申请

只申请业务需要能力。

不要申请：

> GPS等当前不需要权限。

---

# 第二百四十六章 位置

V1：

> 不做持续GPS。

区域：

> 用户选择行政区。

---

# 第二百四十七章 用户协议页面

必须可访问：

```text
用户服务协议
隐私政策
个人信息收集清单
第三方共享清单
活动规则
```

---

# 第二百四十八章 Privacy版本

必须：

> 版本化。

用户同意：

> 可追溯。

---

# 第二百四十九章 Consent

建议表：

```text
consent_records
```

至少记录：

```text
user
type
version
agreed_at
```

---

# 第二百五十章 删除/注销

WorkBuddy必须设计：

> 正式后端流程。

不能只：

> 前端隐藏账号。

---

# 第二百五十一章 删除原则

需要：

```text
停止展示
停止服务
停止推荐
关闭Session
按保留规则处理数据
```

---

# 第二百五十二章 数据保留期限

精确法律/运营期限：

> 不在代码硬编码。

使用：

> Data Retention Config / Policy。

---

# 第二百五十三章 成功案例

默认：

> Private。

宣传必须：

> 单独授权。

---

# 第二百五十四章 活动现场宣传照片

如有：

> 单独授权/规则。

不能把报名视作永久宣传授权。

---

# 第二百五十五章 红娘工作台数据

禁止提供：

> 一键导出所有用户资料。

---

# 第二百五十六章 Admin数据导出

必须单独权限：

```text
data.export
```

并：

> 脱敏 + Audit。

---

# 第二百五十七章 后台临时账号

志愿者建议：

> expires_at。

活动结束后失效。

---

# 第二百五十八章 数据权限生命周期

服务结束后：

> 应减少无必要访问。

V1至少保证：

> assigned任务权限结束后不能继续编辑。

---

# 第二百五十九章 WorkBuddy不得擅自加入“内部用户价值评分”

禁止：

```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
一方发成功请求
↓
另一方确认
↓
成功牵手
↓
停止新推荐
```

---

# 第二百七十二章 WorkBuddy阶段验收机制

每完成Phase：

必须回答：

```text
完成了什么？
测试了什么？
有哪些已知问题？
有哪些待确认？
是否影响之前功能？
```

---

# 第二百七十三章 WorkBuddy禁止声明完成的情况

如果：

```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
```

---

# 第二百七十八章 WorkBuddy每次启动工作时

必须先阅读：

```text
AGENTS.md
docs/STATUS.md
docs/PENDING_DECISIONS.md
本阶段相关设计文档
```

然后再改代码。

---

# 第二百七十九章 WorkBuddy发现旧代码与文档冲突

优先级：

```text
用户最新明确指令
>
本总指令
>
已确认专项设计
>
旧代码实现
```

不得因为：

> “现在代码已经这样写了”

就倒逼修改产品规则。

---

# 第二百八十章 文档冲突处理

如果两个旧文档存在不一致：

优先：

> 后续明确修正文档。

例如已明确：

- Privacy默认值未确认
- Recommendation数量未确认
- Pass冷却未确认

不得引用旧示例当最终规则。

---

# 第二百八十一章 已知需要纠正的旧示例

WorkBuddy特别注意：

以下不是固定产品要求：

```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
状态
权限
双向关系
隐私
并发
线下闭环
```

WorkBuddy投入重点必须放在这些地方。

---

# 第二百八十五章 研发优先级原则

如果时间不够：

先保证：

```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
审核员会用
红娘会用
活动管理员会用
志愿者能签到
风控能处理举报
```

---

# 第二百九十六章 项目最终交付物

WorkBuddy必须至少交付：

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

---

# 第三百零一章 WorkBuddy最终执行宣言

在整个开发过程中必须始终遵守：

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

> **不要擅自增加商业化功能。**

> **不要为了开发方便降低安全要求。**

> **不要把技术示例当成已经确认的业务规则。**

> **所有未确认数量参数配置化。**

> **用户Required绝不自动放宽。**

> **没有双向意愿绝不创建聊天。**

> **拉黑必须立即有效。**

> **红娘只能辅助，不能替用户决定。**

> **活动单向意愿必须保密。**

> **后台人员只能看到完成工作必要的数据。**

> **敏感数据默认拒绝访问。**

> **数据库是业务事实源。**

> **关键动作必须幂等、事务安全、可审计。**

> **系统必须可以部署、升级、备份、恢复和回滚。**

---

# 第三百零二章 WorkBuddy项目最终原则

整个项目只围绕一件事情设计：

> **让丹阳本地真实单身用户，用最低的学习成本，在一个可信、安全、有公益组织参与的平台中，获得线上精准匹配、人工红娘辅助和线下公益活动服务。**

技术存在的目的不是增加复杂度。

算法存在的目的不是替用户选择。

红娘存在的目的不是替用户决定。

后台存在的目的不是让工作人员无限查看数据。

数据存在的目的不是建立用户价值等级。

因此V1.0最终开发原则可以浓缩为：

> **真实身份是基础。**

> **双向意愿是边界。**

> **隐私安全是底线。**

> **规则匹配是效率工具。**

> **公益红娘是人工补位。**

> **线下活动是服务延伸。**

> **用户本人永远拥有最终决定权。**

---

# 第三百零三章 WorkBuddy收到本文档后的第一条执行指令

WorkBuddy不得立即开始无序编码。

首先执行：

```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
↓
保留可复用代码
↓
渐进重构
```

---

# 第三百零四章 WorkBuddy首次仓库审计必须输出

```text
当前技术栈
目录结构
已有模块
已有数据库
已有API
已有测试
已有部署
和V1需求一致的部分
存在冲突的部分
可复用部分
必须重构部分
风险
Phase 01建议
```

---

# 第三百零五章 若仓库为空

则严格按照：

> Phase 01 → Phase 26

顺序推进。

禁止：

> Phase 01时顺手把后面所有功能都做一点。

---

# 第三百零六章 长期连续开发规则

每次任务结束必须留下：

```text
Current Phase
Completed
Next Task
Known Issues
Pending Decisions
Test Result
```

保证下一次WorkBuddy恢复上下文时：

> 可以从项目状态继续，而不是重新理解整个项目。

---

# 第三百零七章 最终交付原则

整个V1.0项目最终应呈现为：

> **代码能运行。**

> **文档能接手。**

> **测试能证明。**

> **部署能复现。**

> **数据能恢复。**

> **权限能控制。**

> **业务能闭环。**

> **运营能执行。**

这才是本项目真正意义上的“完成”。