> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# 系统世界观

> **这是给「写代码的 AI / 人」读的世界观锚点。** 动手写 task / contact / pipeline / agent 相关代码前,先读这份。
>
> 它不讲实现细节(细节见 [`index.md`](/product-design/index.md) 的分层准则、[`north-star.md`](/product-design/north-star.md) 的产品本质、[Task V3 Product / Domain Contract](/product-design/v3/tasks-feature/task-domain-lifecycle.md) 的 selected Target，以及 [Task V3 Rollout 状态快照](/product-design/v3/tasks-feature/task-v3-rollout-status.md) 的实施与环境边界)。[Task V2+ 工程审计与实施基线](/product-design/v2/tasks-feature/task-v2-plus-engineering-audit.md) 只保留为历史审计背景。本文只锁一件事:**这台系统信什么、谁说了算。**
>
> 为什么需要它:AI 写代码时最常见的错,不是语法错,是**世界观认知错**——把过时的数据库标签当真相、让 AI 直接写库、把任务静默丢掉。这份文档就是防这个。
>
> Updated: 2026-08-04（Task 导航对齐 V3 selected Target）

***

## 一、它是台什么机器

retaintive 是一台 **「把客户那边发生的任何事,翻译成该达成的目标、该做的事」的机器**。

- **发生的事** = 一通电话、一条短信、一个 lead 表单(以后还有 Salesforce、Slack…什么都可能)。
- **翻出来的** = 一件有完成标准的客户任务（Task）、当前采用的下一步（Next Action）、实际处理记录（Activity）和最终结果（Outcome）。
- 中间那层翻译,是 AI 做的。

**整个系统的所有设计争议,本质都是同一个问题:这台翻译机该信什么、谁说了算。** 下面就是答案。

***

## 二、不变的内核

无论系统怎么演进(从电话扩到全渠道、从派活给人扩到 AI 自己干),下面这套**规则**永远成立——注意是规则不变,**底下的执行层有些还在建**(哪条已落地、哪条是前瞻设计,逐条会标)。这是 bug 的高发区,逐条讲。

### 1. 判断的时候信什么 —— 不是「谁最新谁赢」,是「谁证据更强谁赢」

AI 判断「该做什么」,核心是权衡手上的多条证据。每条证据看**三个维度**,不是只看「新不新」:

- **类型** —— 是意向 / 行为(想不想升级),还是硬事实(到底是不是会员)?
- **强度** —— 这条有多硬?「我上周刚续了卡」(具体、可核)远强于「我应该算会员吧」(含糊)。
- **新鲜度** —— 多久前得到的、现在还成立吗?今天电话里说的,比 contact 表里三个月前攒的旧判断新鲜。

为什么不能简单「先查档案再判断」:我们**当前没有接入外部 CRM**,数据库里那个身份标签(`lifecycleStage` = lead / member / churned / unknown)不是权威事实,而是**我们基于历次对话攒出来的判断,不一定准**。拿这个不完全准的旧判断去否决刚发生的第一手事实 = **用过去否定现在**。

把三个维度合起来,**分类型看谁赢**(不能笼统说「电话赢」):

| 字段类型                                  | 谁赢                                        | 例子                                                                          |
| ------------------------------------- | ----------------------------------------- | --------------------------------------------------------------------------- |
| **意向 / 行为类**(想不想买、要不要取消、何时方便联系、有什么顾虑) | **永远信刚发生的事(电话)** —— 意向天然以最新为准             | 电话里说「我想升级」→ 以此为准                                                            |
| **硬事实类**(是不是会员、账单、合同、号码归哪家店、法律身份)     | **信证据更强的源；没有权威来源时允许 unknown/review**      | Contact Profile 是 AI-derived snapshot，不能因为旧 label 或一句模糊电话就假装 membership 已确认 |
| **合规类**(DNC)                          | 明确沟通和有权限员工输入触发 dedicated hard guard       | 客户明确要求停止联系 → 记录 restriction，相关 outreach 不再继续                                |
| **真冲突 / 都不够硬**                        | **谁都不许静默改**,记一笔冲突、标 `needs_review`、触发人工复核 | 上面那个会员冲突 → 记 `conflict`,走 review,不直接覆盖                                      |

> **外部 CRM/booking/membership/billing 在这套逻辑里是什么** —— 它们只是未来可能新增的 evidence source，不是当前判断前提。即使以后接入，也必须按具体 source 的 authority、freshness 和 conflict policy 判断，不能笼统定义“永不过期、永远赢”。
>
> **Current reality**：主要来源是 RingCentral communication、Email Lead 和员工输入。Contact Profile 是可纠正的 AI snapshot；员工线下确认是一等输入。未来只有在真实接入并验证后，才能产生 `external_verified` evidence。

### 2. 谁能真正动手 —— AI 只能在「授权范围」内行动,代码才是权威

老规矩说「AI 只能出主意,代码才能动手」。在「AI 建 task、人去执行」的阶段这够用——AI 的输出只是个提案(proposal),真正写库由代码把关。

但当 **AI agent 自己打电话**时,这条不够了:**agent 嘴里说出的每句话,已经是对客户的真实影响,不是「建议」**。代码的数据库把关拦不住一句已经说出口的话。

所以内核升级为:**AI 只能在代码事先发的「能力许可证」范围内行动**(capability envelope)。许可证规定:能调哪个工具、对哪个客户、什么能说什么不能说、什么时候必须停、什么必须先经人批准。真正去打电话 / 发短信的,**永远是一个受控的执行服务(execution service),不是 AI 直接调外部 API**。每个动作——成功的、被拒的、尝试过的——都记进审计账本(audit ledger)。

> 一句话:**AI 可以「自主」,但只能在代码圈好的笼子里自主。代码永远是那个发许可证、关笼子门、记账的人。**

> **落地状态(别误读成已实现)** —— 本文只定义稳定规则，不维护会漂移的 merge、deployment、TEST 或 PROD 快照。当前状态见 [Task V3 Rollout 状态快照](/product-design/v3/tasks-feature/task-v3-rollout-status.md)，并以目标环境的 live code、schema、config、migration state 与 runtime evidence 为准。

### 3. 最终事实在数据库,外部结果要回流成新证据

数据库存的,是**经过把关后被接受的状态**(system of record)。AI 在外面打完电话、客户回了话,这些**外部世界的真实结果,要作为新证据再回流进系统**,让系统重新判断、修正。判断不是一锤子买卖。

### 4. 三条死规矩(踩了就是 bug)

- **硬红线碰不得** —— 号码归哪家店(`store_id`)、DNC、谁有权批准。再确凿的电话也不能让 AI 绕过。
- **先处理身份冲突,再派活(但必须可回滚)** —— 新 communication 与 AI-derived Contact snapshot 冲突时，不能用旧 label 静默丢 Task，也不能把 AI inference 冒充硬事实。能安全处理就建立 Task；影响合规、跨店或高风险 business truth 时进入 review。后续员工确认或更强 evidence 可以纠正。
- **绝不静默丢弃** —— 任务 / 动作被拒,**必须留痕**(为什么拒、基于什么证据、谁拒的);拿不准就标「需要人看一下」(`needs_review`)。**静默地丢任务,是这台机器最大的敌人**——它不报错、没人知道、任务凭空消失。

***

## 三、那个 bug —— 永远的反面教材

> **现象**:一个 lead 在电话里说想升级会籍(`primarySubcategory = member_upgrade`、`primaryOutcomeResult = no_resolution`)。AI 判断出来了,但系统因为他档案里还是 lead,**把 upgrade 任务默默丢掉了**——`upgrade` 是 member 才能建的类型。

这一个 bug 同时踩了两条死规矩:

1. **没先理顺身份** —— 拿旧身份(lead)直接卡死,而没先根据电话证据把他更新成 member,再在新身份下派任务。
2. **静默丢弃** —— 任务凭空消失,不报错、没人知道。

它是整套世界观最好的教学案例。正解的顺序是:

```text
1. 读档案 snapshot + 最近的事件
2. AI 输出「身份提案」+「任务提案」
3. 代码裁决身份迁移:电话证据够硬够新,就乐观更新成 member(标「AI 推断、未经权威确认」,可被后续更硬证据回滚)
4. 用「裁决后的有效身份」算「能建哪类任务」(allowed set)—— 不是用档案里的旧身份
5. 再裁决任务提案
6. 任何被拒的提案,都带 reason + audit 留痕,绝不静默丢弃
```

***

## 四、演进方向

内核不变,但机器在长大,往这几个方向走：

| 这块         | 现在                                                | 以后                                        | 人话                                                                                                                |
| ---------- | ------------------------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **进来的信息**  | 电话 / 短信 / lead                                    | 任何来源(Salesforce / Slack / …)              | 所有信息**用同一套机制进系统**(进门平等),但**不平等地被信任**(按来源可信度 / 新鲜度分级)。底层不为某个来源写特殊逻辑,接新渠道不用重写。                                      |
| **翻出来的东西** | Task snapshot + suggestion/time + Activity ledger | `Task / Next Action / Activity / Outcome` | Task = 要解决什么；Next Action = 当前采用的计划；Activity = 实际做了什么；Outcome = 最后怎么样及其 evidence。                                  |
| **谁干活**    | 员工                                                | AI 自己干、人来批                                | AI 自己打电话、发短信、出 coaching 方案,经理在旁边批准 / 驳回。                                                                          |
| **判断几次**   | 一次性 structured inference                          | bounded reasoning loop                    | 先给 compact context；缺 material evidence 时调用受限 read tool；有冲突就 review，不是每次把全量历史重喂。                                   |
| **怎么搭**    | 一条健身房流程                                           | 厚底座 + 薄壳子                                 | 核心那套(看懂→出主意→把关→执行→学习)做厚做扎实,各行各业、各种功能只是上面**薄薄一层壳**。健身房的 `member` / `class` 这些词只是表皮,不是架构。                           |
| **怎么隔离**   | 门店级(`store_id`)                                   | 租户级能力逐步演进                                 | 当前 Task/Contact/Evidence 的硬隔离键是 `store_id`。`tenant_id` rollout 以 live schema 和多租户文档为准；任何 AI tool 都不能只按 phone 跨店读。 |
| **怎么赚钱**   | —                                                 | **多条路,不锁死**                               | 卖账号(员工 / 经理 / 老板分级)、卖「AI 打电话形成任务」的底座、按行业卖、按用量和模型档位收费……变现方式多样。                                                     |

**一个 nuance**：同一客户可以同时有多个独立 Task；一通电话 Activity 可以为多个 Tasks 提供 evidence。Task lifecycle 仍分开，但前台应把兼容的 Next Actions 合成合理的一次 customer session，避免重复联系客户；interaction count 和 staff credit 只记一次。

***

## 五、一句话总括

> retaintive 把可获得的客户 communication 和员工 context 翻译成「要解决的 Task、当前 Next Action、可审计 Activity 和有 evidence 的 Outcome」。判断时按 evidence strength 权衡；AI 只能在代码授权范围内行动；Funnel projection、工作执行和最终 Outcome 分开。这台机器可以从员工执行演进到 AI 执行，但三条死规矩不变：**硬红线碰不得、冲突不能假装确定、proposal 和 Task 绝不能偷偷消失。**

***

## 相关文档

- [`index.md`](/product-design/index.md) — 这套世界观的**工程落地准则**(Schema-first / API-first / State-machine-first / Prompt-last 的分层设计方法)
- [`north-star.md`](/product-design/north-star.md) — **产品本质 / 北极星**（为什么做、Task 如何服务客户运营）
- [`v3/tasks-feature/task-domain-lifecycle.md`](/product-design/v3/tasks-feature/task-domain-lifecycle.md) — **Task V3 Product / Domain Contract**（selected Target 的术语、产品与工程边界）
- [`v3/tasks-feature/task-v3-rollout-status.md`](/product-design/v3/tasks-feature/task-v3-rollout-status.md) — **Task V3 Rollout 状态快照**（source、deployment、TEST、UAT 与 PROD readiness 分栏）
- [`v2/tasks-feature/task-v2-plus-engineering-audit.md`](/product-design/v2/tasks-feature/task-v2-plus-engineering-audit.md) — **Historical Task V2+ audit**（保留当时的审计、假设和演进背景）