---
date: 2026-04-22 18:00
slug: commence-xiangqin
title: 立项 xiangqin
status: active
tags: [project-kickoff, business-model, autonomy-experiment]
---

# 立项 xiangqin

## 场景

matchmaker（现有交友平台）商业模式模糊、不产生营收；老板想重写 + 换商业模型。同时，生态里有多个"基础设施"项目，老板质疑这些独立 CLI 的必要性——业务团队是不是也能自治完成这些事？

归档候选列表**（2026-04-22 22:45 修订）**：membership / cashier / backup / host / oss / hitch / matchmaker **共 7 个**。原本还含 shipyard，后老板判定 shipyard 改 Python 栈保留（见 `decisions/2026-04-22-2245-keep-shipyard.md`）。

xiangqin 是**两个假设**的对照实验：
1. **商业假设**：相亲用户会为"付费置顶曝光"付钱
2. **工程假设**：业务团队自治（除 vault 外不依赖生态 CLI）更省事

## 选项

- **A) 重写 matchmaker + 商业化 + 自治单体**（采纳）
- B) 在 matchmaker 上改造，加付费置顶功能
- C) 重写 matchmaker 但保留生态依赖（host-cli 部署 / oss-cli 备份 / cashier 收钱）
- D) 不做，放弃交友赛道

## 选 A，因为

- **商业**：matchmaker 的"查询权全给用户 agent"红线很美但没变现路径；付费置顶是最直白的 ad-revenue 模式，和"不做推荐算法"不冲突——用户还是自己决定看谁，只是付费用户更可见
- **工程**：做对照组要彻底才有意义。留一半生态 CLI 的话无法判断"到底是整个生态贡献大，还是 vault 这一个就够"
- **心理**：老板明确说"重写"+"跑通就删 8 个项目"，方向是激进一刀切，不是渐进改良

## 对齐结论（老板确认 8 条）

1. 项目名：`xiangqin`，CLI 名 `xq`
2. 收费模型：**人人进池 + 付费置顶/高亮**（不付费也能被 query 到，付费获得排序权重 + 视觉高亮）
3. 架构哲学：**自治单体实验**
4. ECS：epsilon (`i-bp1iswr9bmkv3qh89965`, 112.124.27.213, 2C4G, 到期 2026-07-13)
5. 后端：Python + FastAPI + uvicorn + systemd
6. DB：sqlite + WAL + 定时 OSS 备份
7. 支付：0.1 mock（标志位 paid=true），0.2 再接真微信支付
8. vault 保留作唯一对外 CLI 依赖（凭证 + 资源台账）

## 代价 / 放弃了

- **生态复用**：不用 host / oss / cashier / backup 等成熟工具，得自己写部署 / 备份 / 支付脚本（预计 +3 人日）
- **matchmaker 历史工作**：TypeScript + Postgres + 5 agent 团队全弃（幸好没上线）
- **商业风险**：付费置顶如果没人买单，整个项目白做。M4（第一个付费意向用户）是 go/no-go 节点
- **自治实验失败可能**：30 天后若发现自己部署 / 备份痛苦得多，要承认回到生态

## 记录源

老板 2026-04-22 对话中连续拍下 4 个 AskUserQuestion 答案 + "你这个实现跑通完整的闭环我就准备把 [8 项目路径] 这些都删除"。

## 影响的其它项目

- **vault**：epsilon 分配给 xiangqin（current_use / tenant 已更新）；gamma 从 matchmaker 释放
- **matchmaker**：进入废弃倒计时，0.1 跑通后归档
- **上面 6 项目**（membership / cashier / backup / host / oss / hitch）：30 天自治实验观察期后决定归档与否
