先理解你是谁、对方是谁、你们是什么关系，再帮你决定这句话怎么回。
Yance 是一个由多个 MCP 连接器驱动的、本地优先的个人关系与沟通智能大脑。
它把散落在微信、小红书、闲鱼、钉钉、飞书等平台上的聊天放回真实的人、账号、身份、关系和场景中，帮助用户理解上下文、维护长期记忆，并生成目标和代价不同的回复策略。系统早期只提供建议并由人确认；经过持续反馈和专项验证后，用户可以对明确身份、账号、对象和场景开启受限、可审计、可随时暂停的自动回复。
A local-first relationship and communication intelligence brain that connects identities, context, memory, and controlled replies across messaging platforms.
Important
Yance 当前处于 planning-only 阶段。本仓库已经包含产品、架构、安全边界、契约草案和验证计划，但还没有可安装发行版、受支持运行时或冻结的公开 API。下文描述的是已经确认的产品方向，不代表功能已经实现。详见项目状态。
人真正难处理的通常不是“帮我润色一句话”，而是：
- 消息分散在多个平台、多个账号和不同时间阶段；
- 同一句话面对领导、客户、伴侣、朋友、长辈或晚辈，含义和合适回应完全不同；
- 很难长期记住每个人的偏好、边界、历史承诺和关系变化；
- 模型可以生成一段流畅文字，却不知道此刻应该以哪种身份说话，也不知道会新增什么承诺；
- 自动回复工具往往直接把“模型能生成”误当成“模型有权发送”。
Yance 的目标不是代替用户社交，而是让用户在重要沟通前，看见更多上下文、可能解释、回复选择和相应代价。
现实中的一个人可能同时出现在多个平台，一个账号也可能由多人共用或暂时无法确认主体：
真实人物 Person
├── 微信：私人号 / 工作号
├── 小红书：创作者号 / 商业号
├── 闲鱼：买家号 / 商家号
├── 钉钉：组织身份 A
└── 飞书：组织身份 B
Yance 区分真实人物、平台账号、平台身份、关系和场景 Persona。跨平台身份关联由系统提出、用户确认；不能只因为昵称相同就自动合并，也必须允许撤销错误关联。
系统从长期互动中整理事实、观察、关系变化和沟通特征，但每个结论都有时间和关系范围。同一个人面对客户、领导、伴侣和朋友时可以呈现不同风格；一次生气、沉默或热情不能覆盖长期判断。
人物与关系分析应保留：
- 可观察到的原始信号；
- 支持证据与反证；
- 其他可能解释和未知项；
- 用户的明确纠正；
- 结论适用的人物、关系和时间范围。
Yance 默认提供三种目标和代价不同的策略，例如：
- 推进结果：直接确认目标和下一步，但可能显得强势；
- 维护关系：先回应情绪与立场，但解决问题的速度较慢；
- 设置边界 / 降低风险：控制承诺和暴露面，但需要注意语气。
用户选择策略后再生成可编辑草稿。系统会指出润色是否改变了事实、金额、日期、责任或关系姿态，而不是只提供“正式一点”“温柔一点”的同义改写。
早期流程是：
收到消息
→ 识别人物、平台账号、当前身份和目标
→ 区分字面事实、可能暗示、证据、反证和未知项
→ 给出三种回复策略
→ 用户选择、修改和确认
→ 连接器填入或发送
→ 记录用户反馈与平台结果
只有当某一身份、账号、对象范围和场景积累了足够反馈并通过验证后，用户才能主动建立自动回复授权。授权默认到期、可随时撤销；身份冲突、低置信判断、敏感关系、金额或重要承诺变化、平台风控、连接器变化和发送状态未知都会暂停自动回复并交还用户。
长期方向包括：
- 操控性沟通信号，包括通常所说的 PUA 模式；
- 话里有话、试探、回避和隐含要求；
- 合作、销售、资源或关系中的机会信号；
- 类似“三国式”的多方关系、立场和利益变化分析。
这些能力只能输出带证据的假设、各方案的代价和验证方式，不能把推测写成对人的定罪，也不能提供利用个人弱点进行操控的建议。
| 场景 | Yance 需要理解什么 | 可能提供什么 |
|---|---|---|
| 微信上下级沟通 | 对方是直属领导、协作方还是提携者；此前是否承诺过时间 | 区分普通询问、进度压力与潜在风险，给出澄清、承诺或说明阻塞的不同策略 |
| 亲友与家庭 | 当前是伴侣、朋友、长辈还是晚辈关系；近期是否存在冲突或重要事件 | 在共情、直接问清和温和设界限之间展示真实取舍 |
| 闲鱼交易 | 使用者是个人买家、个人卖家还是持续经营的商家；商品、报价和售后边界是什么 | 结合历史报价与商品事实回复，识别异常信号，避免凭空承诺和失控议价 |
| 小红书运营 | 当前账号面向什么人群，以创作者、品牌方、销售还是客服身份互动 | 结合笔记和互动上下文生成评论或私信草稿，写操作先确认 |
| 钉钉 / 飞书 | 当前组织、账号、群、话题和执行身份是什么 | 避免跨组织或跨账号串话，在正确会话中提供建议并保留审批记录 |
| 多平台同一联系人 | 多个账号是否属于同一个人，不同平台关系是否相同 | 合并长期事实但保留来源和场景，不把某个平台的表达方式错误套到所有关系 |
Yance 不打算重复维护每个平台的解密、逆向、自动化或开放 API 适配。微信、小红书、闲鱼、钉钉、飞书及业务系统由独立 MCP 或受控 computer-use 能力接入。
平台与业务 MCP
├─ 读取聊天、联系人、群和平台身份
├─ 搜索商品、库存、房源或客户资料
└─ 可选：填入草稿、发送并核验结果
│
▼
Yance 本地大脑（macOS）
├─ 跨平台人物与身份图谱
├─ 时序记忆、关系状态与证据
├─ 情境、目标和风险识别
├─ 回复策略、草稿与反馈学习
└─ 权限、确认、审计和自动化暂停
│
▼
Android 决策界面
└─ 待回复收件箱 / 身份纠正 / 策略选择 / 最终确认
连接器最低需要在授权范围内读取消息，并说明“使用者是谁、对方是谁”；写入和发送是可选能力。每个连接器都是独立信任域，读取、草稿、发送和高影响操作分级授权。模型不能接触平台凭据，也不能自行生成用户授权。
Yance 不试图取代聊天导出器、平台 MCP、AI 客服或数字分身项目，而是希望连接它们已经解决的能力：
- 不止保存聊天记录，还要把记录关联到人物、身份、关系、时间和证据；
- 不只模仿“我的说话风格”，还要知道我在当前场景应该以什么身份说话；
- 不只生成自动回复，还要控制目标身份、承诺变化、批准范围和发送结果；
- 不把所有平台做成一个大爬虫，而是通过开放能力契约复用社区连接器；
- 不把 AI 分析当作事实，所有高阶判断都必须允许核验、纠正、过期和删除。
我们正在邀请微信聊天记录、微信 / 小红书 / 闲鱼 / 钉钉 / 飞书 MCP、AI 分析、数字分身、Agent 记忆和自动回复项目共同讨论底层结构。规范不应由 Yance 单方面宣布，合作可以从 schema 评审、匿名 fixture、兼容适配器或联合原型开始。
| 内容 | 状态 |
|---|---|
| 产品定义、用户体验与系统架构 | PLANNING |
| 身份、记忆、证据和连接器契约 | PROPOSED |
| 匿名合成 fixture 与验证计划 | PROPOSED |
| 真实连接器兼容性 | UNTESTED |
| 可安装应用、受支持运行时、正式 API | NOT IMPLEMENTED |
首个可验收闭环不会直接碰真实微信或闲鱼账号，而是使用受控测试 MCP 验证：读取一个待回复会话、识别身份、分层分析、生成三种策略、精确确认、测试发送和结果核验。之后再逐个验收真实平台连接器、关系记忆和受限自动回复。
完整路线见路线图与验证。
- 第一次了解项目：产品定义
- 查看完整文档导航：文档首页
- 理解系统分层：系统架构
- 了解身份、记忆和证据模型：记忆与数据
- 了解 MCP 接入边界：MCP 耦合层
- 了解隐私和自动回复限制：隐私、安全与合规边界
- 查看当前决定和未决问题：决策与未决问题
- 参与规划、契约或匿名测试材料：贡献指南
当前仓库只接受规划文档、契约草案、匿名测试材料和文档治理改进。old/ 保存停止维护的历史快照，不代表当前实现，也不是安装入口。
owner、License、最低系统版本、正式 API、首个真实 connector、数据库、模型、发布政策和安全响应 SLA 仍为 UNSPECIFIED，仓库不会用推测填补这些决定。
安全问题请不要提交公开 Issue，请按安全政策私密报告。