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

丹阳公益婚恋服务平台

V1.0 WorkBuddy开发执行总指令、项目规则与任务拆解

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

---

第一章 文档定位

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

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

本文件不是普通PRD。

它同时承担：

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

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

项目最高执行规则。

---

第二章 总开发目标

开发一套：

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

核心服务路径：

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

---

第三章 产品核心定位

正式定位：

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

核心价值：

真实
公益
本地
安全
高效

---

第四章 V1最高产品原则

所有研发决策必须服从：

用户简单易用。

工作人员容易运营。

数据安全优先。

用户自主决定。

系统帮助而不是操控。

公益属性优先。

本地服务优先。

低开发复杂度。

易维护、易升级。

---

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

WorkBuddy不得将平台开发成：

商业婚恋VIP平台
陌生人社交平台
直播平台
短视频平台
社区平台
内容平台
游戏化交友平台
付费聊天平台
婚介CRM销售系统

---

第六章 V1用户收费规则

用户：

免费。

V1禁止：

VIP
会员
金币
礼物
付费曝光
超级喜欢
付费聊天
付费联系方式
付费活动

除非未来产品负责人明确重新立项。

---

第七章 用户准入

用户必须：

18周岁以上
+
微信登录
+
手机号
+
姓名/身份证实名认证
+
人工资料审核

未成年人：

禁止进入婚恋服务。

---

第八章 重要法律语义

必须区分：

成年人
≠
达到法定结婚登记年龄

产品不得将18岁描述为：

已具备法定结婚登记资格。

---

第九章 实名认证语义

“已实名认证”只代表：

用户身份通过实名认证。

不代表：

婚姻状态已经官方验证
职业已经验证
收入已经验证
所有资料100%真实

---

第十章 婚姻状态

当前V1：

未婚
离异
丧偶

属于：

用户自行申报 + 人工资料审核。

不得宣传：

官方婚姻状态认证。

---

第十一章 用户端技术形态

必须开发：

微信小程序。

底部导航固定：

首页
找对象
消息
活动
我的

不得擅自改成其他导航结构。

---

第十二章 后台技术形态

推荐并按V1执行：

一个统一Web后台。

通过：

Operator
+
Role
+
Permission
+
Data Scope

分别提供：

• 公益红娘工作台
• 运营后台
• 平台管理后台

不需要开发三套完全独立后台。

---

第十三章 用户核心资料

必须字段：

性别
出生年月
所在区域
身高
婚姻状况
是否有子女
学历
职业
头像

选填：

兴趣
性格/生活方式
吸烟
饮酒
婚姻态度
结婚计划
自我介绍

---

第十四章 用户资料输入原则

优先：

选择 / 标签 / Picker。

减少：

大段人工输入。

不要做超长复杂注册表。

---

第十五章 用户隐私字段

普通用户不得看到：

真实姓名
完整手机号
微信号
身份证
精确地址
精确单位
内部风险信息
举报记录

---

第十六章 择偶条件

基础：

年龄
身高
地区
婚姻状况
学历
是否接受有子女

扩展：

职业
吸烟
饮酒
婚姻计划
定居意愿
生活方式
兴趣

---

第十七章 条件语义不可改变

每一项条件支持：

必须符合
最好符合

Required：

不符合直接淘汰。

Preferred：

可参与评分。

WorkBuddy不得把Required自动降级。

---

第十八章 V1匹配算法

必须采用：

资格过滤
+
双向Required
+
双向规则评分
+
推荐排序
+
推荐理由

不采用：

• AI黑盒匹配
• 大模型判断婚姻幸福
• 向量数据库
• 深度学习推荐
• 颜值评分

---

第十九章 双向匹配

算法必须同时计算：

A → B
B → A

不是只满足A。

---

第二十章 MutualScore

建议公式实现为配置：

MutualScore
=
0.6 × min(scoreAB, scoreBA)
+
0.4 × average(scoreAB, scoreBA)

公式版本必须：

可版本化。

---

第二十一章 算法参数特别说明

此前文档中出现过：

6人每日推荐
60分阈值
100分权重
180天Pass冷却

这些属于：

示例/建议参数。

不得硬编码为不可修改业务常量。

必须通过：

Config / Match Rule Version

实现。

---

第二十二章 推荐前台展示

用户端不得显示：

92%
87.5分
AI匹配成功率

只显示：

很合适
比较合适
值得了解

以及：

为什么推荐。

---

第二十三章 推荐理由

必须来源真实资料。

例如：

年龄符合双方条件
都长期生活在丹阳
婚姻计划接近
双方都不吸烟
有共同兴趣

禁止AI虚构。

---

第二十四章 首页

首页必须：

推荐优先。

不要开发：

• 新闻
• Feed
• 广告
• 热门榜
• 用户排行榜
• 直播入口

---

第二十五章 用户关系

单向：

neutral
liked
passed
blocked

双向：

mutual_match

---

第二十六章 Mutual Match

只有双方Like：

才创建Match。

必须保证并发情况下：

同一对用户只有一个有效Match实例/有效关系阶段。

---

第二十七章 Chat准入

必须：

Mutual Match
+
双方账号允许
+
无Block
+
Conversation active

才允许聊天。

---

第二十八章 聊天V1支持

文字
图片
Emoji
系统消息
安全提示
未读
历史分页
失败重试

---

第二十九章 V1聊天禁止开发

语音消息
实时语音通话
视频
群聊
红包
转账
文件
阅后即焚
已读回执展示
正在输入
AI代聊

---

第三十章 聊天发送架构

V1采用：

REST发送
+
WebSocket接收

不要为了炫技改成全WebSocket协议。

---

第三十一章 消息持久化原则

必须：

先落PostgreSQL
↓
再实时推送

推送失败：

消息仍然成功。

---

第三十二章 消息幂等

每条消息：

senderId + clientMessageId

唯一。

弱网重试：

不得重复消息。

---

第三十三章 Block

Block最高优先级。

发生后立即：

停止聊天
排除推荐
排除Search
排除红娘候选
停止互相可见

---

第三十四章 Unblock

解除Block后：

不得自动：

恢复Like
恢复Match
恢复Conversation

重新建立关系必须重新走业务流程。

---

第三十五章 Unmatch

解除匹配后：

Match失效
Conversation只读
停止新消息

Unmatch：

不等于Block。

---

第三十六章 RelationshipStatus

此前技术模型：

searching
getting_to_know
paused
matched_successfully
service_exited

属于：

技术建议状态模型。

具体代码可采用等义命名，但不得随意扩展产品含义。

---

第三十七章 Paused

暂停寻找：

不进入新推荐。

但：

已有聊天保留。

---

第三十八章 Getting To Know

“正在了解”是否自动暂停其他推荐：

不能硬编码。

应由：

• 用户选择
• 配置

决定。

---

第三十九章 Successful

成功牵手：

必须：

一方发起 + 对方确认。

不能：

• 红娘确认
• 管理员确认
• 系统自动确认

---

第四十章 公益活动

必须支持：

活动列表
活动详情
报名
资格检查
人工审核
报名结果
签到
反馈
活动互选

---

第四十一章 活动名额

必须支持：

总人数
可选性别名额

性别名额：

配置项。

不能写死每场都50:50。

---

第四十二章 Activity Pending

V1建议：

Pending不占正式名额。

Approved：

占正式名额。

审核通过必须事务检查剩余名额。

---

第四十三章 活动签到

采用：

短期签名二维码Token。

不能二维码直接放：

身份证
手机号
userId明文

---

第四十四章 活动互选

必须独立表：

activity_interests

不能在feedback中只放一个interestedUserId。

因为用户可能：

选择多个意向对象。

---

第四十五章 活动意向隐私

A选择B但B没选A：

B不知道。

双方选择：

才产生Match/通知。

---

第四十六章 活动互选不是成功牵手

只能表达：

双方愿意进一步了解。

---

第四十七章 公益红娘

用户可申请：

推荐合适对象
调整择偶条件
联系意向对象
参加活动
长期无匹配
聊天帮助
其他

---

第四十八章 红娘核心原则

红娘：

可以推荐。

不能：

替用户Like。

红娘：

可以辅助联系。

不能：

私自提供手机号。

红娘：

可以提供聊天建议。

不能：

看完整私人聊天。

---

第四十九章 红娘候选来源

必须调用：

Match Engine。

红娘不能绕过Required搜索全库强推。

---

第五十章 红娘推荐

推荐前服务端必须二次检查：

目标账号
审核
Block
Relationship
Required

---

第五十一章 红娘联系意向对象

V1采用保守实现：

A明确请求
↓
红娘触发平台中性邀请
↓
B自行查看/拒绝

不得：

自动给A或红娘释放B联系方式。

---

第五十二章 红娘服务记录

每次正式跟进：

时间
渠道
摘要
结果
下一步
下次跟进

必须结构化保存。

---

第五十三章 红娘不能看到

身份证
私人聊天
举报证据
无关风险调查
精确住址

---

第五十四章 后台Operator

所有工作人员统一：

operators

不要创建：

reviewer_accounts
matchmaker_accounts
volunteer_accounts

多套账号体系。

---

第五十五章 V1角色

建议：

super_admin
platform_admin
organization_admin
reviewer
matchmaker
activity_manager
risk_operator
volunteer
data_viewer

---

第五十六章 权限结构

必须采用：

RBAC
+
Data Scope
+
Sensitive Permission

---

第五十七章 Data Scope

至少支持：

platform
organization
assigned
self
activity_scope

---

第五十八章 用户不属于某个机构私有

禁止简单设计：

users.organization_id

作为用户唯一归属。

用户是：

平台用户。

组织通过：

• 活动
• 红娘服务
• 审核任务
• 授权

获得必要访问。

---

第五十九章 机构之间

机构合作：

不代表数据完全共享。

必须按业务关系限制。

---

第六十章 后台权限必须服务端执行

不能：

只隐藏菜单。

每个API：

必须检查：

Authentication
Permission
Data Scope
Sensitive Permission

---

第六十一章 聊天隐私

后台普通用户详情中：

禁止“聊天记录”Tab。

只有风控案件场景：

才允许有限访问。

---

第六十二章 敏感访问

查看：

完整身份证
风控证据
案件聊天

必须：

• 特殊权限
• 原因
• SensitiveAccessLog

---

第六十三章 用户数据安全

身份证：

id_number_enc
+
id_number_hash

手机：

phone_enc
+
phone_hash

禁止生产明文。

---

第六十四章 WeChat账号数据

不要仅：

users.openid

推荐：

user_wechat_accounts

唯一：

app_id + openid

unionid允许为空。

---

第六十五章 实名Provider数据

只保留：

业务必要结果。

不要默认存储：

第三方完整原始响应。

---

第六十六章 用户照片

必须：

Private Object Storage。

通过：

Signed URL。

---

第六十七章 图片处理

至少：

• MIME检查
• Magic Number
• 大小限制
• 图片解码
• EXIF清理

---

第六十八章 数据库

V1推荐：

PostgreSQL。

具体技术栈仍可根据最终后端语言确认。

但数据模型和约束不可改变业务含义。

---

第六十九章 Redis

只用于：

Cache
Session
Rate Limit
WebSocket
临时状态

不得成为：

Match等业务事实唯一数据源。

---

第七十章 Backend架构

V1采用：

Modular Monolith。

不要擅自拆微服务。

---

第七十一章 模块

至少：

Auth
User
Verification
Profile
Review
Match
Relationship
Messaging
Activity
Matchmaker
Risk
Notification
Organization
Permission
Analytics
Audit
Config

---

第七十二章 模块之间规则

禁止：

Module A直接跨模块修改Module B表。

通过：

Service / Domain接口。

---

第七十三章 后端语言

此前推荐：

Java 21 + Spring Boot 3.x

或者：

Node.js + NestJS

尚未锁死。

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

优先建议：

Java 21 + Spring Boot 3.x + PostgreSQL + Redis。

原因：

• 权限
• 事务
• 状态机
• 长期维护
• 国内团队适配

但若用户后续明确指定技术栈：

以用户指令为准。

---

第七十四章 前端技术

微信小程序：

优先：

原生微信小程序或成熟稳定框架。

不要为了技术炫技引入过重跨端体系。

后台：

Vue 3 或 React均可。

如果无既有代码：

建议：

Vue 3
TypeScript
Vite
Pinia

---

第七十五章 组件库

后台可采用：

Element Plus

或等价成熟组件库。

用户小程序：

自建统一轻量组件。

---

第七十六章 Design Token

必须继承此前Design Token规范。

页面不能：

每个开发者自己写一套颜色、间距、圆角。

---

第七十七章 UI原则

用户端：

简单
温和
可信
公益
非商业化

避免：

大量粉红
皇冠
钻石
金币
火焰
排行榜
夜店风

---

第七十八章 页面架构

小程序核心路由必须继承既有U01-U48设计。

不得随意合并导致业务缺失。

---

第七十九章 用户启动路由优先级

服务端状态判断：

1 登录
2 手机
3 实名
4 资料完整
5 审核
6 账号风险
7 婚恋服务状态
8 正常业务

页面自己不能猜。

---

第八十章 State Store

前端建议：

AuthStore
UserStore
MatchStore
MessageStore
ActivityStore
MatchmakerStore
AppStore

---

第八十一章 Server Truth

所有关键状态：

后端数据库为最终事实。

前端Store：

只是显示缓存。

---

第八十二章 API Base

统一：

/api/v1

---

第八十三章 API响应

统一：

{
  "success": true,
  "code": "OK",
  "message": "success",
  "data": {}
}

建议同时包含：

requestId / timestamp

并在全项目保持一致。

---

第八十四章 HTTP Status

必须合理使用：

400 参数错误
401 未认证
403 权限/禁止
404 不存在/不可见
409 状态冲突
422 业务校验（如选用）
429 限流
500 服务端异常

---

第八十五章 API DTO

禁止：

数据库Entity直接作为API Response。

必须：

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。

---

第九十二章 关键数据库唯一约束

必须有：

微信 app_id + openid
身份证hash
手机号hash（按业务需要）
user relation
activity registration
clientMessageId
Match active pair

---

第九十三章 Match历史

不要设计成：

一对用户永远只有一条不可变Match且无法未来重新建立。

必须支持：

历史关系和新的有效关系阶段。

可采用：

• Match Episode
• 历史记录
• Active Pair Unique

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

---

第九十四章 Pass

需要预留：

expires_at

但冷却周期：

配置。

---

第九十五章 AccountStatus

技术状态：

normal
reviewing_risk
limited
suspended
banned
closed

属于建议技术模型。

如果WorkBuddy优化命名：

语义必须一致。

---

第九十六章 RiskLevel

建议：

normal
watch
high
critical

RiskLevel：

不等于AccountStatus。

---

第九十七章 RiskAction

建议：

warning
feature_limit
temporary_suspend
ban
manual_investigation

---

第九十八章 Report

Report是否成立：

与：

风控如何处置

必须分开。

---

第九十九章 风控原则

不得：

单个关键词直接永久封禁。

默认：

规则发现
↓
风险事件
↓
人工判断
↓
处置

明显技术攻击除外。

---

第一百章 申诉

Appeal此前属于：

推荐V1功能。

如果开发资源充足：

应实现。

若必须缩减：

可作为V1.0.x补充，但数据结构建议预留。

---

第一百零一章 数据统计

正式指标必须唯一口径。

尤其：

注册
实名
审核通过
推荐曝光
Like
Mutual Match
Chat Started
Activity Mutual
Successful Match

不得混淆。

---

第一百零二章 Success统计

只有：

双方成功牵手确认

才算：

successful

活动互选：

不是成功牵手。

---

第一百零三章 Chat Started

必须是真实用户消息。

SystemMessage：

不算。

---

第一百零四章 数据统计架构

V1：

PostgreSQL业务表
+
Daily Summary
+
Redis缓存

足够。

禁止提前建设：

• Kafka
• Flink
• ClickHouse
• Data Lake

---

第一百零五章 部署

必须：

Docker
Docker Compose
Nginx
PostgreSQL
Redis
Private Object Storage

---

第一百零六章 V1禁止基础设施过度设计

不得擅自引入：

Kubernetes
Service Mesh
Kafka
Elasticsearch
Neo4j
Milvus
分布式数据库

除非出现明确、经过验证的必要性。

---

第一百零七章 配置

区分：

业务Config
部署Config
Secret

Secret：

不进Git。

---

第一百零八章 CI/CD

至少：

Lint
Unit Test
Integration Test
Migration Validation
Build

通过后：

构建固定版本镜像。

---

第一百零九章 生产发布

禁止：

SSH生产
git pull
现场npm install
现场mvn package

生产只拉：

已构建Artifact/Image。

---

第一百一十章 Migration

所有数据库变化：

Migration管理。

生产禁止：

手工无记录ALTER TABLE。

---

第一百一十一章 Health

必须：

/health/live
/health/ready
/version

---

第一百一十二章 监控

至少：

CPU
Memory
Disk
API 5xx
P95
PostgreSQL
Redis
Backup
证书

---

第一百一十三章 日志

必须：

Structured Log。

统一：

requestId

---

第一百一十四章 日志禁区

禁止记录：

完整身份证
完整Token
密码
聊天正文
举报完整正文
敏感图片URL

---

第一百一十五章 Backup

必须：

数据库自动备份
+
独立位置
+
加密
+
恢复验证

---

第一百一十六章 Restore

必须真正演练。

只有“有backup文件”：

不算合格。

---

第一百一十七章 Rollback

每个生产Release：

必须知道：

上一个稳定版本。

---

第一百一十八章 Feature Flag

至少支持：

activityEnabled
matchmakerEnabled
imageChatEnabled

以及必要核心模块Kill Switch。

---

第一百一十九章 测试最高优先级

开发过程中测试顺序：

权限
数据一致性
Match
Block
Chat
实名认证
审核
活动并发
红娘
统计
UI细节

---

第一百二十章 WorkBuddy开发模式

WorkBuddy必须采用：

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

禁止：

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

---

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

每一个阶段执行：

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

---

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

如果WorkBuddy发现：

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

必须：

保持原需求。

对于未确认内容：

标记：

TODO_PRODUCT_CONFIRMATION

或者：

使用可配置实现。

不得擅自拍板改变产品。

---

第一百二十三章 不允许“为了方便”简化核心规则

禁止：

为了开发简单取消双向匹配。

禁止：

为了查询方便给管理员全部权限。

禁止：

为了快速推荐自动放宽Required。

禁止：

为了聊天方便允许陌生私信。

---

第一百二十四章 技术债原则

允许：

简化技术架构。

不允许：

简化产品安全规则。

---

第一百二十五章 项目目录建议

如果从零开发，建议：

project/
├── backend/
├── miniapp/
├── admin-web/
├── infrastructure/
├── docs/
├── scripts/
└── tests/

---

第一百二十六章 Backend目录建议

以模块化单体为原则：

backend/src/
├── auth/
├── user/
├── verification/
├── profile/
├── review/
├── match/
├── relationship/
├── messaging/
├── activity/
├── matchmaker/
├── risk/
├── notification/
├── organization/
├── permission/
├── analytics/
├── audit/
├── config/
└── shared/

具体语言框架结构可调整。

---

第一百二十七章 Miniapp目录建议

miniapp/
├── pages/
├── components/
├── stores/
├── services/
├── utils/
├── theme/
├── constants/
└── types/

---

第一百二十八章 Admin目录建议

admin-web/src/
├── pages/
├── layouts/
├── components/
├── modules/
├── stores/
├── api/
├── permissions/
├── router/
├── theme/
└── types/

---

第一百二十九章 Docs必须进入Git

至少：

docs/
├── product/
├── architecture/
├── api/
├── database/
├── security/
├── testing/
├── ops/
└── decisions/

---

第一百三十章 ADR

重要技术决策建议记录：

docs/decisions/
ADR-001-backend-stack.md
ADR-002-auth-strategy.md
ADR-003-object-storage.md

---

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

建议仓库根目录建立：

AGENTS.md

用于放：

WorkBuddy执行规则摘要。

---

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

至少：

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

---

第一百三十三章 STATUS.md

建议：

docs/STATUS.md

记录：

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

WorkBuddy每阶段更新。

---

第一百三十四章 CHANGELOG

每次版本更新：

CHANGELOG.md。

---

第一百三十五章 第一阶段：项目基础骨架

目标：

项目可以启动。

任务：

初始化Backend
初始化Mini Program
初始化Admin Web
Docker环境
PostgreSQL
Redis
基础配置
统一Response
Error Handling
Logging
RequestId
Migration

---

第一百三十六章 第一阶段验收

必须：

Backend可启动
数据库Migration成功
Redis正常
Admin可打开
Miniapp可打开
Health正常
CI通过

---

第一百三十七章 第二阶段：认证与Operator基础

用户：

微信登录
手机号
Session
/me/status

后台：

Operator login
Role
Permission
Organization

---

第一百三十八章 第二阶段重点

必须先做好：

权限框架。

不要等整个后台开发完才补权限。

---

第一百三十九章 第二阶段测试

重点：

Token
Refresh
Logout
Operator Disable
RBAC
Data Scope基础

---

第一百四十章 第三阶段：实名认证

开发：

IdentityProvider接口
实名请求
实名认证状态
年龄检查
身份证加密/hash
去重
日志脱敏

---

第一百四十一章 第三阶段验收

必须：

• 未成年拦截
• 重复身份证处理
• Provider失败可恢复
• 数据库无明文身份证
• 日志无身份证

---

第一百四十二章 第四阶段：用户Profile

开发：

Basic Profile
Lifestyle
Photos
Interests
Self Intro
Relationship Intent
Privacy
Preference

---

第一百四十三章 第四阶段重点

必须同时完成：

Draft / Completion / Validation。

---

第一百四十四章 第五阶段：人工审核

开发：

ReviewTask
ReviewItem
Claim
Approve
Need Edit
Reject
Review History

---

第一百四十五章 第五阶段后台

完成：

Reviewer工作台最小可用版本。

---

第一百四十六章 第五阶段并发

必须测试：

多审核员同时Claim。

---

第一百四十七章 第六阶段：推荐Match Engine

优先只做后端。

开发：

Eligibility
RequiredCondition
DirectionalScore
MutualScore
Reasons
Ranking
RecommendationRecord

---

第一百四十八章 第六阶段测试

必须覆盖：

每个维度 + 双向Required。

算法测试必须自动化。

---

第一百四十九章 第七阶段：首页与找对象

开发：

推荐卡
推荐理由
详情
Find
Filter
临时筛选

---

第一百五十章 第七阶段重点

确保：

Search和Recommendation使用同一Eligibility基础规则。

---

第一百五十一章 第八阶段：Like与Match

开发：

Like
Cancel Like
Pass
Block
Unblock
Mutual Match
Match History

---

第一百五十二章 第八阶段最高风险

重点验证：

并发Like
重复Like
Match唯一性
Block优先级

---

第一百五十三章 第九阶段：Conversation与Text Chat

先只做：

Conversation
Text Message
REST Send
WebSocket Receive
Unread
History

暂不先做图片。

---

第一百五十四章 第九阶段完成条件

A/B双方：

Like
↓
Match
↓
打开Chat
↓
发送文字
↓
另一方实时收到

必须完整。

---

第一百五十五章 第十阶段：Chat安全与图片

增加：

图片
上传
Signed URL
Risk Notice
Rate Limit
Block实时
Ban实时

---

第一百五十六章 第十一阶段：系统通知

统一NotificationService。

接：

审核
Match
活动
红娘
风险

---

第一百五十七章 第十二阶段：Relationship状态

开发：

Paused
Getting To Know
Successful Request
Confirm
Decline

Success必须双确认。

---

第一百五十八章 第十三阶段：公益红娘

开发：

MatchmakerService
分配
Claim
候选
推荐
Followup
Waiting User
Complete
Risk Referral

---

第一百五十九章 第十三阶段用户端

完成：

公益红娘首页
申请
进度
红娘推荐

---

第一百六十章 第十四阶段：活动基础

开发：

Activity CRUD
Publish
Cancel
Browse
Apply
Review
My Activities

---

第一百六十一章 第十四阶段并发

必须完成：

Activity capacity事务。

---

第一百六十二章 第十五阶段：签到

开发：

Signed Checkin Token
Staff Scan
Manual Checkin
Duplicate Check

---

第一百六十三章 第十六阶段：活动反馈与互选

开发：

Feedback
ActivityInterest
Mutual Interest
Activity Source Match

---

第一百六十四章 第十六阶段隐私重点

单向Activity Interest：

不得向对方暴露。

---

第一百六十五章 第十七阶段：举报与风控

开发：

Report
Evidence
RiskEvent
RiskProfile
RiskAction
Account Capability
Risk Admin

---

第一百六十六章 第十七阶段实时联动

封禁/限制：

必须立即影响：

Recommendation
Like
Chat
Activity
Matchmaker

---

第一百六十七章 第十八阶段：申诉

如果列入V1正式范围：

Appeal
Process
Approve
Reject
Recalculate Account Status

---

第一百六十八章 第十九阶段：后台完善

完成：

User Management
Organization
Operator
Role
Permission
Audit
SensitiveAccess

---

第一百六十九章 第二十阶段：Analytics

实现：

Dashboard
User Funnel
Match Funnel
Matchmaker Stats
Activity Stats
Risk Stats
Daily Summary

---

第一百七十章 第二十一阶段：注销与数据生命周期

完成：

Account Deletion
Service Exit
Visibility Removal
Activity Cleanup
Matchmaker Cleanup
Retention Hooks

---

第一百七十一章 第二十二阶段：部署体系

完成：

Dockerfile
Docker Compose
Nginx
Health
CI/CD
Staging
Backup
Restore
Rollback
Monitoring

---

第一百七十二章 第二十三阶段：完整系统测试

必须执行：

核心E2E
权限矩阵
IDOR
并发
聊天弱网
活动并发
风控
统计
恢复

---

第一百七十三章 第二十四阶段：UAT

邀请：

普通用户
审核员
红娘
活动管理员
风控员
志愿者

进行真实操作。

---

第一百七十四章 第二十五阶段：RC

生成：

v1.0.0-rc.1

进入Staging最终回归。

---

第一百七十五章 第二十六阶段：生产上线

上线前：

Backup
Migration
Deploy
Smoke
Monitor

---

第一百七十六章 开发任务优先级

定义：

P0
P1
P2

---

第一百七十七章 P0

所有上线必须功能：

认证
实名
Profile
审核
Preference
推荐
Like
Mutual
Chat
Block
Report
Matchmaker基础
Activity基础
权限
风控

---

第一百七十八章 P1

V1必须完成但可以后置开发：

图片聊天
活动互选
高级红娘协同
Analytics
申诉
动态水印

其中：

活动互选属于V1最终上线必需闭环，不得拖到V2。

---

第一百七十九章 P2

可V1.0.x：

更高级统计
异常登录提醒
MFA强化
更多运营辅助
高级风控规则

---

第一百八十章 V1明确不做列表

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

直播
短视频
动态Feed
朋友圈
群聊
语音房
视频相亲
礼物
金币
积分商城
排行榜
VIP
支付
超级喜欢
Boost
付费解锁联系方式
AI数字人
AI代聊
AI婚恋预测
颜值评分
财富评分
复杂智能排桌

---

第一百八十一章 Git规则

建议：

main
develop
feature/*
fix/*
hotfix/*

小团队也可以简化。

但Production发布必须：

有Tag。

---

第一百八十二章 Commit原则

每个Commit：

一个明确任务。

不要：

update
fix stuff
final

建议：

feat(match): implement mutual eligibility
fix(chat): prevent send after block

---

第一百八十三章 Branch完成规则

合并前：

Tests pass
Lint pass
Build pass
Migration pass

---

第一百八十四章 数据Migration与代码同PR

新增字段：

Migration必须随代码提交。

不能：

口头告诉运维自己建表。

---

第一百八十五章 环境变量

.env.example必须持续同步。

新增环境变量：

同时更新文档。

---

第一百八十六章 API变更

每次：

更新OpenAPI。

不得代码改了API但文档不变。

---

第一百八十七章 前后端共享类型

如果可能：

自动生成。

避免手写两套Enum。

---

第一百八十八章 状态枚举

所有状态：

单一来源。

尤其：

AccountStatus
ReviewStatus
RelationshipStatus
MatchStatus
ActivityStatus
RegistrationStatus
MatchmakerStatus
ReportStatus

---

第一百八十九章 业务配置

所有未确认数量型规则：

必须：

Configurable。

例如：

推荐数量
照片数量
兴趣数量
Pass冷却
活动互选人数
消息长度
限流阈值

---

第一百九十章 不要过度配置

只有：

业务可能变化的值

才配置。

不要把所有按钮颜色都放数据库。

UI走：

Design Token。

---

第一百九十一章 代码注释原则

复杂业务：

解释为什么。

例如：

// Required preferences must never be relaxed.
// This is a product invariant.

而不是：

// if

---

第一百九十二章 核心Invariant

WorkBuddy必须在代码、测试中明确保护以下Invariant：

未Mutual不可聊天
Required不可自动放宽
Block即时禁止互动
工作人员不能替用户Like
成功牵手必须双确认
单向活动意向不泄露
敏感身份默认脱敏
跨组织默认拒绝

---

第一百九十三章 事务边界

以下必须事务：

Mutual Match创建
Activity名额批准
Review Claim
Successful Confirm
RiskAction + AccountStatus

---

第一百九十四章 事务外副作用

例如：

Notification
WebSocket
Analytics

事务提交后执行。

失败：

补偿/重试。

不能回滚已成功核心业务。

---

第一百九十五章 Outbox

V1如果通知可靠性实现复杂：

建议：

Lightweight Outbox Pattern。

无需Kafka。

---

第一百九十六章 Scheduler

允许：

Backend内置Scheduler。

多实例时加锁。

---

第一百九十七章 后台删除原则

重要实体：

不物理删除。

采用：

disabled
cancelled
closed
soft_delete

---

第一百九十八章 Audit

后台关键操作：

必须Audit。

包括：

审核
风险
活动取消
角色权限
Operator
敏感访问
系统配置
匹配规则

---

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

每完成模块：

WorkBuddy必须运行：

相关测试。

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

---

第二百章 Match模块完成定义

必须同时满足：

算法单测通过
Required测试通过
Mutual并发测试通过
Block测试通过
Recommendation API通过

才算完成。

---

第二百零一章 Chat模块完成定义

必须：

无Match不可发送
Match可发送
重复clientMessage不重复
Block即时失效
Unmatch即时失效
WS恢复

---

第二百零二章 Activity完成定义

必须：

资格正确
名额并发正确
重复报名安全
签到安全
单向意向私密
Mutual创建一次

---

第二百零三章 Permission完成定义

必须使用：

非超级管理员测试。

至少测试：

reviewer
matchmaker
activity_manager
risk_operator
volunteer
organization_admin

---

第二百零四章 敏感数据完成定义

必须确认：

DB无身份证明文
日志无身份证
Public DTO无手机号
Bucket非公开
SensitiveAccess有审计

---

第二百零五章 不接受“先做功能以后补安全”

本项目安全不是后置模块。

权限、敏感数据、Block：

必须和功能一起实现。

---

第二百零六章 用户体验完成定义

页面不只要：

功能存在。

必须：

• Loading
• Empty
• Error
• Success feedback
• Disabled state
• Retry

完整。

---

第二百零七章 普通用户错误提示

不得展示：

NullPointerException
SQLSTATE
403 Forbidden

使用业务文案。

---

第二百零八章 后台技术错误

可以显示：

RequestId

帮助技术排查。

但仍不得展示敏感Stack。

---

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

每完成一个阶段：

更新：

docs/STATUS.md
CHANGELOG.md
OpenAPI
Migration
Tests

---

第二百一十章 STATUS示例

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

---

第二百一十一章 待确认内容管理

建立：

docs/PENDING_DECISIONS.md

---

第二百一十二章 当前需要标记为可配置/待确认的项目

包括但不限于：

每日推荐数量
推荐最低阈值
最终权重
Pass冷却
照片上限
兴趣标签上限
Self Intro长度
Privacy默认值
Getting To Know是否自动暂停推荐
活动是否默认审核
活动男女名额
活动互选人数
活动互选截止时间
Matchmaker联系目标的电话授权规则
RelationshipStatus最终业务命名
Appeal是否V1首发

---

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

必须：

• Config
• Feature Flag
• 合理默认技术值
• 文档标记

并明确：

默认值只是当前技术默认，不代表产品最终确认。

---

第二百一十四章 不得修改已确认内容

例如：

用户免费
必须实名认证
人工资料审核
双向喜欢后聊天
公益活动顶级Tab
红娘不代操作
Required不可放宽

这些不是待确认。

---

第二百一十五章 代码质量原则

优先：

可读
明确
少魔法
少抽象
可测试

不要为了：

“架构高级”

创建大量无意义层。

---

第二百一十六章 不提前设计十年后的架构

当前只需：

支持V1 + 平滑扩容。

不要构建：

• Plugin Platform
• Workflow Engine
• Rule DSL
• Distributed Saga

除非实际需要。

---

第二百一十七章 Domain Service原则

业务规则集中。

Controller：

不写核心业务逻辑。

---

第二百一十八章 Repository原则

数据访问统一。

不要：

Service里到处拼SQL。

---

第二百一十九章 Validation

分：

DTO validation
+
Business validation

两者不要混淆。

---

第二百二十章 异常体系

例如：

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

可以用于：

Like
Pass
Privacy

但失败必须回滚。

以下不要盲目Optimistic：

实名
审核
成功牵手
活动通过
封禁

---

第二百二十八章 WebSocket只是通知通道

不能：

依赖WebSocket事件作为唯一业务状态。

断线后：

REST可重建。

---

第二百二十九章 外部Provider

必须Adapter封装。

后续：

可更换供应商。

---

第二百三十章 中国大陆环境适配

优先：

国内网络稳定
国内云服务
微信生态
中国大陆对象存储
国内实名认证Provider

避免核心依赖境外不可控服务。

---

第二百三十一章 第三方依赖最小化

V1不需要大量SDK。

只接：

真正必要能力。

---

第二百三十二章 开源依赖选型原则

选择：

• 活跃维护
• 社区成熟
• License清晰
• 国内可用
• 不过度绑定云厂商

---

第二百三十三章 License

WorkBuddy新增开源库时：

必须确认License。

避免引入：

与商业/公益部署冲突的许可证风险。

---

第二百三十四章 Dependency清单

维护：

docs/DEPENDENCIES.md

列：

名称
版本
用途
License

---

第二百三十五章 Security Dependency

定期扫描：

• npm audit
• Maven/Gradle依赖扫描
• Container CVE

但不要盲目自动升级破坏生产。

---

第二百三十六章 可观测性

每个模块关键操作应有：

Metrics
Logs
Audit（需要时）

---

第二百三十七章 Match Observability

至少记录：

candidate_count
required_reject_count
recommendation_count
match_created

不记录敏感推断。

---

第二百三十八章 Message Observability

至少：

send_success
send_failure
ws_push_failure
reconnect

---

第二百三十九章 Activity Observability

至少：

apply
approve
checkin
capacity_conflict

---

第二百四十章 Risk Observability

至少：

report_created
risk_action
appeal

---

第二百四十一章 生产数据禁止Seed测试用户

正式环境：

禁止默认插入测试用户。

---

第二百四十二章 Test Account

如果生产必须保留运营测试账号：

必须明确标记：

is_test_account

并排除：

• 推荐
• 统计
• 用户搜索

---

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

否则运营指标污染。

---

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

WorkBuddy必须准备：

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

---

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

只申请业务需要能力。

不要申请：

GPS等当前不需要权限。

---

第二百四十六章 位置

V1：

不做持续GPS。

区域：

用户选择行政区。

---

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

必须可访问：

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

---

第二百四十八章 Privacy版本

必须：

版本化。

用户同意：

可追溯。

---

第二百四十九章 Consent

建议表：

consent_records

至少记录：

user
type
version
agreed_at

---

第二百五十章 删除/注销

WorkBuddy必须设计：

正式后端流程。

不能只：

前端隐藏账号。

---

第二百五十一章 删除原则

需要：

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

---

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

精确法律/运营期限：

不在代码硬编码。

使用：

Data Retention Config / Policy。

---

第二百五十三章 成功案例

默认：

Private。

宣传必须：

单独授权。

---

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

如有：

单独授权/规则。

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

---

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

禁止提供：

一键导出所有用户资料。

---

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

必须单独权限：

data.export

并：

脱敏 + Audit。

---

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

志愿者建议：

expires_at。

活动结束后失效。

---

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

服务结束后：

应减少无必要访问。

V1至少保证：

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

---

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

禁止：

A级用户
高价值用户
低质量用户
颜值分
财富分

---

第二百六十章 算法不使用

禁止推断：

宗教
政治
健康
性生活
财富等级

作为匹配分。

---

第二百六十一章 成功标准

本项目不是：

页面全部完成。

而是以下闭环真正运行：

注册
↓
实名
↓
审核
↓
推荐
↓
Mutual
↓
Chat
↓
红娘/活动
↓
进一步了解
↓
成功

---

第二百六十二章 V1核心验收用户故事一

新用户进入。

应能：

微信登录
↓
绑定手机
↓
实名
↓
填写资料
↓
设置择偶
↓
提交审核
↓
等待

---

第二百六十三章 用户故事二

审核员：

登录
↓
待审核
↓
领取
↓
查看
↓
通过/退回

---

第二百六十四章 用户故事三

用户审核通过：

首页看到推荐
↓
看详情
↓
Like

---

第二百六十五章 用户故事四

双方Like：

Mutual Match
↓
Conversation
↓
聊天

---

第二百六十六章 用户故事五

用户觉得不合适：

Unmatch

随后：

不能继续聊天。

---

第二百六十七章 用户故事六

用户遭骚扰：

Block
+
Report

立即停止联系。

---

第二百六十八章 用户故事七

长期没结果：

申请红娘
↓
红娘接手
↓
系统候选
↓
人工推荐

---

第二百六十九章 用户故事八

用户参加活动：

报名
↓
审核
↓
签到
↓
互选
↓
Mutual

---

第二百七十章 用户故事九

风控员：

处理举报
↓
采取Action
↓
用户立即受限

---

第二百七十一章 用户故事十

双方关系稳定：

一方发成功请求
↓
另一方确认
↓
成功牵手
↓
停止新推荐

---

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

每完成Phase：

必须回答：

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

---

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

如果：

代码写完
测试没跑
Migration没验证
权限没测
核心E2E没跑

不得说：

完成。

---

第二百七十四章 Regression

每个新模块：

必须确保：

不破坏之前通过的核心流程。

---

第二百七十五章 优先自动化场景

一定自动化：

Required
Mutual
Block
Chat permission
Activity capacity
RBAC
Data Scope

---

第二百七十六章 Go-Live阻断

上线前以下必须为0：

P0
未接受P1
严重权限漏洞
敏感数据明文
Match并发错误
Activity超卖

---

第二百七十七章 V1开发路线总览

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每次启动工作时

必须先阅读：

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

然后再改代码。

---

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

优先级：

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

不得因为：

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

就倒逼修改产品规则。

---

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

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

优先：

后续明确修正文档。

例如已明确：

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

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

---

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

WorkBuddy特别注意：

以下不是固定产品要求：

每天6人
60分
照片最多6张
兴趣最多8个
180天Pass
所有Privacy默认true
活动男50女50
活动必须审核
活动互选只能1人

都必须配置/待确认。

---

第二百八十二章 不重复造轮子原则

使用成熟组件：

• JWT/session库
• PostgreSQL driver
• Redis library
• Validation
• Migration
• WebSocket
• Object Storage SDK

但核心业务规则：

自己明确实现。

---

第二百八十三章 不引入完整婚恋开源项目替代业务

可以参考开源代码。

但不能为了快：

把商业社交项目直接改皮肤。

因为产品逻辑差异很大。

---

第二百八十四章 核心开发哲学

本项目真正复杂的地方不是：

UI页面数量。

而是：

状态
权限
双向关系
隐私
并发
线下闭环

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

---

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

如果时间不够：

先保证：

正确
安全
完整

再做：

动画
视觉细节
非必要运营功能

---

第二百八十六章 后端优先于高级视觉

推荐流程、权限、活动容量等后端正确前：

不要优先花时间做复杂UI动画。

---

第二百八十七章 V1不追求“智能感”

匹配系统只需要：

准、稳定、解释清楚。

不需要到处写：

AI智能。

---

第二百八十八章 AI使用边界

V1可以未来使用AI：

润色自我介绍等辅助。

但不得：

• 自动虚构用户资料
• 自动代聊
• 自动决定Match
• 自动判断婚姻幸福

---

第二百八十九章 对用户尊重

产品文案、标签不得：

没人喜欢
低匹配用户
难匹配
条件太高
高价值
低质量

---

第二百九十章 空候选文案

使用：

暂时没有完全符合你条件的人。

然后提供：

查看择偶条件
申请公益红娘
参加活动

---

第二百九十一章 数据和用户不是商品

开发界面中不要使用：

库存用户
优质资源
资源池等级

可以使用：

候选用户
可匹配用户
用户池

---

第二百九十二章 用户自主权最终红线

系统和工作人员不得替用户执行：

Like
确认成功牵手
主动发送私人聊天

---

第二百九十三章 上线前产品验收

必须最终检查：

页面是否仍符合公益定位。

如果最终UI变成：

Tinder/直播/商业婚介风格

即使功能全：

也不合格。

---

第二百九十四章 上线前技术验收

必须：

Core E2E Pass
Permission Pass
Security Pass
Concurrency Pass
Backup Restore Pass
Rollback Pass

---

第二百九十五章 上线前运营验收

必须：

审核员会用
红娘会用
活动管理员会用
志愿者能签到
风控能处理举报

---

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

WorkBuddy必须至少交付：

完整源码
数据库Migration
OpenAPI文档
Docker部署
CI配置
环境变量示例
测试代码
运营后台
微信小程序
数据库说明
部署说明
备份恢复说明
权限矩阵
测试报告
Release Notes

---

第二百九十七章 README

必须写清：

项目是什么
技术栈
如何本地启动
环境变量
如何Migration
如何运行测试
如何Build
如何Deploy

---

第二百九十八章 一键本地启动

目标：

docker compose up

可以启动必要基础设施。

应用本身根据技术栈一条标准命令运行。

---

第二百九十九章 新开发人员接手标准

一个新的研发人员：

不依赖原作者口头解释。

通过：

README
AGENTS
Docs
Migration
Tests

应能够理解并启动项目。

---

第三百章 最终完成标准

只有同时满足：

用户端完整
后台完整
核心业务完整
权限正确
安全正确
测试通过
部署可用
备份恢复可用
文档完整
运营可以执行

才允许定义：

V1.0开发完成。

---

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

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

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

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

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

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

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

用户Required绝不自动放宽。

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

拉黑必须立即有效。

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

活动单向意愿必须保密。

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

敏感数据默认拒绝访问。

数据库是业务事实源。

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

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

---

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

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

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

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

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

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

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

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

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

真实身份是基础。

双向意愿是边界。

隐私安全是底线。

规则匹配是效率工具。

公益红娘是人工补位。

线下活动是服务延伸。

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

---

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

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

首先执行：

1. 创建项目文档目录
2. 创建AGENTS.md
3. 创建STATUS.md
4. 创建PENDING_DECISIONS.md
5. 确认当前仓库是否已有代码
6. 输出当前代码基线审计
7. 确认最终技术栈
8. 建立Phase 01任务清单
9. 建立测试基础设施
10. 再开始Phase 01开发

如果仓库已经存在：

不得直接推翻重写。

先进行：

现状分析
↓
与V1规范Gap Analysis
↓
保留可复用代码
↓
渐进重构

---

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

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

---

第三百零五章 若仓库为空

则严格按照：

Phase 01 → Phase 26

顺序推进。

禁止：

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

---

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

每次任务结束必须留下：

Current Phase
Completed
Next Task
Known Issues
Pending Decisions
Test Result

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

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

---

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

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

代码能运行。

文档能接手。

测试能证明。

部署能复现。

数据能恢复。

权限能控制。

业务能闭环。

运营能执行。

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