Retaintive

    系统世界观

    这是给「写代码的 AI / 人」读的世界观锚点。 动手写 task / contact / pipeline / agent 相关代码前,先读这份。

    它不讲实现细节(细节见 index.md 的分层准则、north-star.md 的产品本质、Task V3 Product / Domain Contract 的 selected Target，以及 Task V3 Rollout 状态快照 的实施与环境边界)。Task V2+ 工程审计与实施基线 只保留为历史审计背景。本文只锁一件事:这台系统信什么、谁说了算。

    为什么需要它: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/reviewContact 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 状态快照，并以目标环境的 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. 静默丢弃 —— 任务凭空消失,不报错、没人知道。

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

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

    四、演进方向

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

    这块现在以后人话
    进来的信息电话 / 短信 / lead任何来源(Salesforce / Slack / …)所有信息用同一套机制进系统(进门平等),但不平等地被信任(按来源可信度 / 新鲜度分级)。底层不为某个来源写特殊逻辑,接新渠道不用重写。
    翻出来的东西Task snapshot + suggestion/time + Activity ledgerTask / Next Action / Activity / OutcomeTask = 要解决什么；Next Action = 当前采用的计划；Activity = 实际做了什么；Outcome = 最后怎么样及其 evidence。
    谁干活员工AI 自己干、人来批AI 自己打电话、发短信、出 coaching 方案,经理在旁边批准 / 驳回。
    判断几次一次性 structured inferencebounded 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 绝不能偷偷消失。

    相关文档