# PropertyLab petaV3 — 全面战略报告(完整合并版)

**日期:** 2026-07-28 · **作者:** Claude(以 Chief AI Officer / Chief Product Officer 视角)· **语言:** 中文,技术词保留 English
**本文件合并并取代以下分报告的阅读需求:** Report 1(UX 检讨)、Report 2(AI Copilot 提案)、独立 Ideas 报告、上传文件评估与 6 个月计划。数据均为 **2026-07-27 实测**,非估算。

---

## 0. 执行摘要(先读这里)

1. **平台架构是强的,缺口几乎都不是「缺模块」,而是「模块之间的反馈回路断了」+「数据采集纪律」。** 出席过 webinar 的人不会进 pipeline;录音分析的洞察死在抽屉里;9,846 个 leads 只有 195 个曾被开过 engagement;182 张 bookings 没有一张填了 SPA price、bank 或 closer。
2. **AI 不是从零开始。** 平台已有生产级 AI substrate:`AiClient`(5 个 provider)、prompt registry、`ai_requests` 成本日志、统一的 ConversationAnalyzer、WhatsApp AI profiles/flows(实质上已是 RAG-lite + agent loop)。
3. **AI 路线的核心判断:先做「创造并采集数据」的 agent,后做「从数据学习」的 model。** 因为对话语料很富(1.9 万条 WhatsApp + ~1,900 份 transcript),但成交标签很薄(182 张 booking,状态几乎只有终态)。
4. **两份上传战略文件(Cloud GPU 计划 + PETA Global 飞轮架构)方向正确**,且与本报告独立得出的结论高度收敛 — 「outcome-labeled closed loop 才是护城河」。但:自建模型在当前用量下省不了钱(它的正确定位是 Phase 2 产品研发 + 中国合规);中国节点是市场进入而非 feature,应「为它设计、待伙伴落定再建」。
5. **算不算 deep tech?按当前范围:不算 — 而且没关系。** 真正可防守的是三样:专有的 outcome-labeled 数据集、在其上的区域 LoRA、跨境分区部署方法论。对外故事立在 closed loop,不立在标签。
6. **未来 6 个月一条合并时间线**(第八章):8 月起飞轮以手动 + API 模型立即转动,GPU POC 并行;9 月 Self-Filling CRM(LABEL);10 月 channel agents(GUIDE);11 月编排器 + playbook 挖掘(LEARN);12 月 uplift A/B(MEASURE);1 月外部 pilot + 两道数据闸门决策(on-prem GPU、中国节点)。

---

# 第一章 · 现状:系统架构与 AI 基础设施

## 1.1 技术栈与形态

- **Laravel 13 (PHP 8.4) + Inertia + Vue 3 + Tailwind v4**,MySQL,Redis + Horizon 队列(专用 lane:长时 ASR 走 `redis-transcription`,AI 调用走带韧性的 `ai` lane),Reverb websockets,GCS 文件存储(统一经 `MediaService`),scheduler,以及 Node 的 `baileys-wa-bridge` sidecar(WhatsApp QR 通道)。
- **严格架构约定**(GUIDELINES.md):写操作走 Repository + transaction,校验走 Form Request,列表过滤走 QueryRequest,model 只放常量与关系,所有 admin 列表共用一套 DataTable/filter 基础组件。
- **两个 portal,一条 identity 主线:** Manage portal(管理员)+ Main portal(客户)。**一个 lead 就是一个 portal user**,身份解析统一经 **`LeadLinker`**(phone-trust 策略、去重、merge 检测)。对 AI 最重要的架构事实:**所有信号都能用 `lead_id` join 起来。**

## 1.2 业务流

六条销售产品线,每条都跑 **Pipeline → Sales → Referral & Repeat**(UI 是 chevron stage rail)。Property Booking 已完整:买家 quiz → 按 (lead, project) 建 **engagement**(Caller → Closer → Follow-Up)→ **booking**(单位、价格、SPA 流程、commission = project rate × basis price)→ referral worklist(never-asked → 最近成交 → 消费额排序)。营销走 **funnels**(landing → sessions → Zoom webinars,含出席追踪与 session 级 Meta 广告归因)+ **Traffics**(campaign CPL)。沟通走**统一 inbox**(WhatsApp Cloud + QR bridge + Messenger)。

## 1.3 已在生产运行的 AI substrate(`Src\Ai`)

| 组件 | 作用 |
|---|---|
| `AiClient` | Provider-agnostic 调用层,横跨 **Anthropic / OpenAI / Gemini / DeepSeek / Moonshot**;统一响应、fail-soft、支持 streaming。所有 AI 调用唯一入口。 |
| `AiKeyService` / `AiCredential` | 加密 key 存储,两种 scope:公司全局 key 与会员自带 key(BYO-key);入库前先向 provider 验证。 |
| Prompt registry | `AiPrompt` / `AiPromptVersion` + markdown prompt 文件 — prompt 是有版本的数据,不是硬编码。 |
| `ai_requests` 日志 | 每次调用记录 provider、model、tokens、成本、耗时 + 多态 `subject`(关于哪条记录)。至今 764 条。 |
| Credits | `lead_ai_credits`:会员先用免费额度、用完切自己的 key。 |
| 队列 lane | 带 rate-limit + circuit-breaker 的 `ai` lane。 |

## 1.4 已上线的 AI 功能

1. **ConversationAnalyzer** — 电话 / 门店 badge / Zoom 三种录音共用一个 analyzer、一个 schema:summary、对话类型、sentiment、客户画像(interest level、buying stage、budget、needs、concerns)、销售表现(0–10 score、strengths、improvements)、meeting report(next steps + follow-up date),中英双语。输出经 `normalize()` 钳制 — **防幻觉 guardrail 已制度化。**
2. **Transcription** — Gemini 主 → Deepgram 兜底,专用队列 lane,三条录音 pipeline 共用。
3. **WhatsApp AI** — 按 channel 分配 **AI Profiles**:分层知识文档 + instruction、draft-suggest / auto-reply 双模式(超时段自动降级为草稿)、debounce、objective 完成标记。**实质是生产级 RAG-lite + agent loop。**
4. **WhatsApp Flows** — 20 条:定时 drip 与规则型 menu bot、并行 run slot、多种触发、四道 template 校验、human handoff 即终止自动化。
5. **AI Conversations**(会员 portal)— 流式聊天,可注入会员自己的 wealth plans + analyses 做 grounding。
6. **Lead enrichment** — GeoIP、设备指纹、电话有效性/运营商、WhatsApp 在网检测、Gravatar、Google Places(已 enrich 1,213 个)。
7. **AI Video**(feature-flagged)与 **AI Debate** 实验。

## 1.5 集成轨道(agent 可以通过什么行动)

WhatsApp Cloud + Bridge(发送、templates、flows)、Messenger、Zoom S2S(会议/webinar、录音 + transcript)、Meta Ads API、Stripe、SMS360、Telegram 告警(`Notifier`)、magic-link email、dowayai 通话录音轮询、yhy 智能工牌 webhook。

---

# 第二章 · 数据盘点(实测 2026-07-27)

| 领域 | 表 | 行数 | 对 AI 的意义 |
|---|---|---|---|
| **人** | `leads` / `users` + profiles | **9,846 / 10,063** | 主轴,其余全部 join 到它。 |
| 归因 | `lead_funnels` | 9,841 | 每次注册的 first-touch 来源/UTM/广告。 |
| Enrichment | `lead_enrichments` | 1,213 | 身份/假号特征。 |
| **对话** | `whatsapp_messages`(1,048 threads) | **19,070** | 最丰富的行为语料,尚未开采。 |
| | `messenger_messages` | 18 | 边缘。 |
| **录音** | `zoom_recordings` | **1,694** | 最大 transcript 语料。 |
| | `call_recordings` | 214 | 已带结构化分析。 |
| | `f2f_recordings` | 4 | Pipeline 已验证,硬件佩戴率低。 |
| **销售** | `engagements` / `bookings` / `projects` | 195 / 182 / 39 | 成交结果 = 监督标签。⚠️ SPA/bank/closer 全空。 |
| 会员 | `member_subscriptions` | 452 | 第二收入流。 |
| **活动** | `event_registrations`(9 场) | **1,004** | 高意向信号,目前是死胡同。 |
| **Portal 行为** | 5 类 | 1 / 2 / 1 / 3 / 8 | 量极小,但出现即极高意向。 |
| **楼盘知识** | `catalog_projects` | **15,528** | 现成的地产 RAG 知识库。 |
| 获客表单 | property match / rental estimate | 0 / 0 | 已上线,无流量。 |
| AI 运维 | `ai_requests` | 764 | 成本遥测已积累。 |

**诚实判断:** 语料富、标签薄 → **先做创造数据的 agent,后做学习数据的 model。**

---

# 第三章 · 产品功能与 UX 检讨(12 个导航区域)

## 3.1 十大优先修复

| # | 优先事项 | 区域 | 原因 |
|---|---|---|---|
| 1 | **攻 9,651 个未跟进 lead 的缺口** | Leads → Sales | 9,846 个 lead 只有 195 个开过 engagement,98% 的池子没人碰。其他一切都是次要的。 |
| 2 | **修 booking 数据采集** | Sales | 0/182 有 SPA price、bank、SPA/LO 日期;0/195 有 closer。字段、filter、sort 都在,全渲染成「—」。 |
| 3 | **Speed-to-lead SLA 队列** | Leads | 没有「新 lead 待首触」视图 + 计时器。行业常识:5 分钟内触达,转化率翻倍。 |
| 4 | **打通:出席 → pipeline** | Funnels → Sales | 1,004 个报名,出席从不生成/更新 engagement。刚听完 webinar 的人是全场最热的 lead。 |
| 5 | **让录音洞察流到工作现场** | 录音 → Leads/Messages | analyzer 已提取 interest、stage、objections、next steps — 但只在每条录音的 drawer 里。应喂给 lead 页、inbox、coaching。 |
| 6 | **Portal 激活** | Portal | 10,063 账号:1 个 wealth plan、2 个 analysis、3 个 AI 对话。功能没问题,是没人被带进来。 |
| 7 | **Traffics → 营收归因** | Traffics | 有 CPL,没有 cost-per-booking。join 链路(spend → lead → engagement → booking)数据全在。 |
| 8 | **Agent coaching dashboard** | Dashboard | 每条已分析录音都有 0–10 的 `sales_performance.score`,没人按 agent 聚合。 |
| 9 | **Pipeline 状态卫生** | Sales | 98 Converted + 79 Lost,工作态状态(New→With Closer)全为零。要么 UI 强制走阶段,要么承认是历史导入并打标。 |
| 10 | **修 deploy DB backup** | Ops | 每次 deploy 写出 20-byte 空备份。下次带 migration 的 deploy 前必须修 `mysqldump` host 参数。 |

## 3.2 分区域检讨

**Dashboard(Insights · Sales · Pipeline · Calendar)** — 建议:顶部加一条 funnel strip(Leads → 注册 → 出席 → Engagements → Booked → Converted,每级带周环比);agent leaderboard(bookings、营收、通话量、平均 score、响应时间 — 全部现有数据可推导);「今日 appointments」做成 Dashboard 卡片。

**Leads** — 最强的列表页(搜索、filter、export、enrichment、distribution)。建议:**默认「next-action worklist」段**(无 engagement、无外呼、7 天内的新 lead + SLA 计时列)— 全套件杠杆最大的一处 UX;可保存的 segments;enrichment 信号变成 filter(「号码不在 WhatsApp」= 假 lead 过滤);批量操作(bulk assign / add-to-pipeline / tag);`activity_logs` 只有 31 条 — `ActivityLogger` 应埋进状态变更、assign、booking 等写路径。

**AI Copilot** — 占位页(有意为之),建设方案见第四章。UX 要点:v1 必须能从上下文进入(lead 页、inbox thread),不能只是一个独立页面。

**Sales(六条产品线 + stage rail)** — 建议:**数据卫生提示**(缺 SPA price 的行给一个可点的 amber「缺 3 个字段」chip + 「missing SPA price」filter);stage rail 上加**阶段转化率**(match → booking %、customer → referral %)— 只有 counts 没有转化率的 funnel 是 vanity 阅读;pipeline 工作态无人使用(见 3.1 #9);Property Match / Rental Estimate 提交为 0 是营销问题不是代码问题 — stage-1 页已加 Landing Page 按钮,可再加线下活动 QR code;referral 的「Mark asked」若无人用,把 ask 动作整合进 WhatsApp inbox(一键发 referral ask 模板)。

**Funnels(Funnel · Meta Ads · AI Video)** — 成熟:slots/sessions/webinar、出席与 walk-in 捕获、session 级广告快照、WhatsApp welcome/reminder 自动化、QR 票。建议:**出席 → pipeline**(最低限度:Leads 上「出席但不在任何 pipeline」的 segment;更好:会后提示「18 人出席 · 12 人不在 pipeline → 加入 [project]」);no-show 一键转入下期 + 邀请 flow(campaign 触发机制已支持);funnel 列表页应显示每条 funnel 的活数据(下一场、本周注册、CPL 趋势)。

**Traffics** — 建议:**cost per booking**(不只 per lead);趋势线而非快照(spend/CPL 时间序列 + campaign 起停标注);点 campaign 直接钻取到按该归因过滤的 Leads。

**Portal(Activity · 五个 pivot)** — 数字本身就是结论(见 3.1 #6):要靠外部杠杆修 — WhatsApp flow 里加「你的账号已开通,分析你的第一套房:{{login_link}}」、webinar 跟进链接到 portal 工具、LMS 完课提示。**让 Activity 可行动**:每行加「message on WhatsApp」(inbox 深链已存在);高意向信号(如「lead X 建了 wealth plan」)注册成 `Notifier` 事件推送 Telegram。

**Messages(Inbox · Broadcasts · AI Automation · Settings)** — 最成熟的模块。建议:**打开 thread 即显示 AI 摘要** + 提取的状态(「看周二、预算 ~600k、顾虑贷款 margin」);**未回复队列视图**(「客户最后发言、超过 N 小时」— 主管每天最该看的 SLA 视图);**thread 级 sentiment/intent 分类**(analyzer 目前只跑录音)→ inbox 可按「热对话」过滤,并成为 lead scoring 的输入;Messenger(18 条)不值得继续投入。

**Zoom(Recordings · Polls · Settings)** — 1,694 条录音是**最大对话语料**(超过电话 + 门店总和)。建议:Recordings 页加「未分析」计数保持诚实;webinar 录音刻意不做逐条分析是对的,但**每场一条 summary**(话题 + chat 提问 — chat 采集已存在)只需一次 AI 调用,直接喂 follow-up flow。

**Phone Call & Showroom F2F** — 工程上已完备(双设备摄入管线、统一录音界面、tombstone 删除语义)。缺口在**产出被低估消费**(见 3.1 #5):分析结果应传播到 lead 页(「上次对话:高意向、decision 阶段」)、follow-up 建议(「analyzer 说周五跟进 — 建 appointment?」)、coaching。`agent_call_events` 为 0 — click-to-call 埋点没生效,会饿死 suggested-match;F2F 只有 4 条 — 硬件佩戴问题,不是软件。

**Setting(七个 tab)** — 重构后结构正确。建议:**AI Requests 页提前加按功能/按天的成本聚合**(第四章上线后此页会重要得多);`Notifier` 是上面一半建议的投递轨道 — 边建边注册事件。

## 3.3 跨领域主题

1. **列表都很好,「接下来该做什么」全缺。** 下一个成熟度是有观点的队列(SLA、未回复、缺数据),把 list 变成 work。
2. **到处是 counts,几乎没有转化率。** 改变行为的是级间比率。
3. **信号不流动。** enrichment 困在 Identity tab、分析困在录音 drawer、出席困在 Events — 决策发生在 lead 页和 inbox,把信号接过去。
4. **空状态要教学。** 每个空页应说明「什么会填满我」并链接到杠杆(landing page、设备注册、flow builder)。
5. **运维债:** deploy 备份写空文件(修 `mysqldump` host 参数);`routes/web.php` 里 `rental-estimates` 组声明了两次(删一份);Diver `QueryRequest` 在 PHP 8.4 下每请求抛 deprecation(一行 nullable 修复)。

---

# 第四章 · AI Copilot 建设提案

## 4.0 定位(一段话)

不要做「摆在 CRM 旁边的 chatbot」。要做:**以 tool-use 驾驭 CRM 的 copilot** + **与所有现有 AI 界面共享的知识层** + **延伸既有自动化的 channel agents**(WhatsApp profiles/flows 已是 SDR agent 的 80%)。编排上**先 deterministic workflow,AI 放在边缘** — 行业共识与 Anthropic 工程指南一致:可靠的生产系统由 workflow 编排、LLM 做步骤,只有任务真正需要开放式规划才升级 multi-agent。

## 4.1 地基 — Lead Timeline API(前置,~1 周)

一个能回答「关于 lead X 我们知道的一切」+「自 T 以来发生了什么」的 service(`Src\Lead\Services\LeadTimeline`),泛化自 Portal Activity 的 UNION 模式。合并:注册、双渠道消息、录音分析、出席、portal 行为、engagement/booking 变迁、enrichment。两个 day-one 消费者:Copilot context builder + 事件流(`lead.registered` / `lead.attended` / `lead.high_intent_signal` / `lead.went_quiet`)。顺带解决「信号不流动」。

## 4.2 Copilot v1 — 管理员的 tool-using chat

**对内部 read API 做 agentic tool-use,不是 embeddings 优先。** 暴露 ~10–15 个 read tool(leads.search、lead.timeline、engagements.list、bookings.stats、campaigns.cpl、events.attendance、recordings.analysis…),每个都是现有代码薄封装,**强制执行调用者的 `LeadVisibility`/权限**。Model 调用走 `AiClient`(需补 tool-use 透传 — v1 唯一的 substrate 升级),照旧记 `ai_requests`。**两个挂载点:** Copilot 页 + lead/inbox 的 context drawer。v1 写操作**只做提议**(复用 WhatsApp draft-suggest 的 UX)。将来要暴露给外部 runner 时再包 **MCP server** — 那是打包,不是架构。

## 4.3 知识层 — closing playbook RAG

泛化 WhatsApp AI Profiles 已有的分层知识文档:**一个 `KnowledgeBase` service**(scope:全局/产品线/渠道/阶段),供四个界面消费(copilot、WhatsApp 草稿、coaching、portal chat)。**先 prompt-stuffing,后 embeddings**(playbook 规模下直接塞 context 优于向量库;超出预算再上,并用先宽后窄的 agentic 检索)。**15,528 楼盘 catalog 是第二知识库** —「X 附近 600k 以下可比项目」是 tool,不是文档 RAG。

## 4.4 Channel 与阶段 agents(按序)

1. **Speed-to-lead SDR(WhatsApp)** — 新 lead → 短暂人工认领窗口 → 无人认领则 AI-profile 开启对话,objective = qualify + 约时段。直接攻 3.1 #1。
2. **Pre-call/pre-meeting brief** — 任何 appointment 前从 timeline 生成一页:上次 objections、portal 信号、来源、playbook 话术。
3. **Post-conversation actions** — analyzer 的 `next_steps` + `follow_up_date` → 提议的 appointment + 草稿消息,一键批准。
4. **Attendance follow-up agent** — 出席未入 pipeline → 个性化跟进;no-show → 重邀 flow。
5. **Referral 与 renewal agents** — stage 3 worklist 在正确时机起草 ask;452 个 subscription 同法。

## 4.5 「Master Brain」编排层(纪律警告)

**事件驱动的 next-best-action 引擎,不是放养的 multi-agent 社会。** timeline 事件 → 规则优先的 policy 表(Manage 可编辑)→ channel agents 执行,每类动作三档自主权:*suggest → draft → auto*(guardrail:营业时间、消息上限),全程审计。**LLM 在边缘,代码在中间。** Lead scoring 内置:先启发式,day-one 记录 score-vs-outcome,标签够了再学习型。

## 4.6 Coaching agent(被低估的赢面)

按 agent 聚合 `sales_performance` 分数 + strengths/improvements,对照 playbook,每周 Telegram 投递 2–3 个训练点 + 本周最佳/最差通话。数据今天就齐。

## 4.7 风险与 guardrails

WhatsApp 号码信誉(限速 + 每 lead 上限 + kill-switch);**PDPA**(录音/transcript 属个人数据,agent 引用前过法务);幻觉(`normalize()` 钳制推广到所有 structured output;draft 档以上必须 template 锚定或 KB grounded);成本(按功能日预算 + 熔断,Setting → AI Requests 可视化);评估(真实语料建 eval set,suggest→draft→auto 晋级靠测量)。

---

# 第五章 · 11 个独立 World-Class AI Ideas

> 这些是 brief 之外、我自己的押注 — world-class 的标准不是概念新颖,而是「**别人抄不走**」。每条注明数据依据。

### 第一层:Data Flywheel(数据自动化 — 地基)

**Idea 1 — Self-Writing Playbook(自己写自己的 playbook)。** 您的原构想是上传销售知识库;我建议反过来:从 ~1,900 份带 objections/stage/score 的 transcripts + 98 Converted / 79 Lost 标签里,定期追问「**同一个 objection 面前,赢单做了什么、输单没做什么**」,产出持续自更新的 objection → rebuttal playbook。上传的书本是 seed,自己的语料才是 moat。落地:scheduled batch(现有 `AiClient` + prompt registry)→ 入 KnowledgeBase → 喂 copilot / 草稿 / coaching。风险:赢单样本少 → 初期人工审核每条 pattern。

**Idea 2 — Self-Filling CRM(自己填自己的 CRM)。** 0/182 booking 有 SPA price/bank/closer — 靠 UI 提醒改不了纪律,那就不要求人:事实*已经在对话里*(「SPA 上礼拜二签了」「Maybank 批了 90%」)。extraction agent 读新 transcript / WhatsApp,**提议**字段更新(suggest 档、一键接受 — 同 Phone Call suggested-match 的 UX)。**所有其他 idea 的营养来源,排第一优先。** 风险:错误提取 → 永远只到 suggest 档。

### 第二层:Growth Engine

**Idea 3 — AI-as-the-Funnel(AI 就是 funnel)。** 现在获客是 webinar 形状(定时、批量、费力),两个表单型 magnet 提交为 **0** — 表单已失效。把**公开的 conversational property advisor** 放上 WhatsApp:15,528 楼盘任问、答案有据、聊着完成 qualify + 预约 — 一条 24/7 的新 funnel。bridge、AI profiles、objective、catalog 全部现成。品牌风险最高 → 单盘试点,严格 grounding,超范围 handoff。

**Idea 4 — Creative Loop(Traffics 创意闭环)。** campaign/adset/ad 级归因 + feature-flagged AI Video 已在:某条 ad CPL 衰减 → 自动生成有据变体(catalog 事实 + Idea 1 的 winning hooks)→ Meta API 推送 → 度量。先 copy 变体(suggest 档),video 后置。

**Idea 5 — Campaign Factory(一句话开出整条 funnel)。** 从一句 brief(「八月 KLCC 新盘,主打首购族」)生成整套草稿:landing 文案、flow 步骤、ad creative、受众建议 — 人审后一键上线。把*自己家的*五个模块串成流水线。范围大 → Phase 3 之后。

**Idea 6 — Market Intelligence Radar(市场情报雷达)。** 每周双语市场简报,**挂钩我们 catalog 在售的具体楼盘**(「本周 X 区新增供应,影响在售的 Y、Z」),经 Telegram `Notifier` 推送。半天级工程量。

### 第三层:People & Operations

**Idea 7 — Buyer Simulator(买家模拟器)。** Coaching 只能事后复盘;把时态反过来:用 Idea 1 的真实 objection corpus 构建 AI「买家」(多疑的 Sri Petaling upgrader、DSR 吃紧的首购族),新人反复演练 closing,由*同一个* analyzer 打分。训练从「听坏电话」变成「把 rebuttal 练成肌肉记忆」。市场上没人做。

**Idea 8 — AI Loan Companion(贷款陪跑员)。** 马来西亚成交最大瓶颈是 loan。Wealth 模块已有 WhoPay CCRIS 解析 + bank-rules simulator:长成 WhatsApp 上的贷款陪跑 agent(DSR pre-check、材料清单、银行比较、LO/SPA 里程碑提醒)。三重回报:减少因贷款流失的 Lost;里程碑自动喂 Idea 2;交楼后标记 referral ask 时机。合规敏感 → 只做资讯陪跑不做建议。

**Idea 9 — Membership Success Agent(会员成功代理)。** 452 个 subscription + 只有 8 条 lesson progress(这本身就是 churn 信号):课程停滞 → nudge;完课 → 引流 portal;续费窗口 → 个性化沟通。教育与交易之间的 cross-sell 桥。

### 第四层:Demand Recycling(最被低估)

**Idea 10 — Lost-Deal Marketplace(输单不丢)。** 79 个 Lost 是**带预算带偏好的活跃需求**;Concierge 同时躺着业主卖/租委托。AI matchmaker 把两边接起来:楼盘 A 输掉的买家 → 匹配 subsale/rental 的 B。「没有一个 lead 被浪费」变成系统属性。

**Idea 11 — Project-Launch War Room(新盘作战室)。** 新盘上架瞬间,AI 反向扫描 9,846 个 lead 的历史信号(budget、区域、quiz、portal 行为)→ **按匹配度排序的 call list**,每人附「为什么是他」+ 开场白。Copilot v1 之后近乎免费。

### 押注顺序

**#2 → #1 → #11 → #8 → #3(试点)→ #7 → #10 → 增长层(#4/#5/#6/#9)。**
一句话:brief 造的是「AI 帮团队干活」;这 11 个造的是「AI 让公司拥有别人抄不走的资产」— 自我更新的 playbook、自我维护的 CRM、不休息的 funnel、不浪费的需求池。两条线共享 Phase 0–1 地基。

---

# 第六章 · 两份上传战略文件:解读

## 6.1《petaV3 Cloud GPU Internal AI Deployment and Private AI Rollout Plan》(v1.0,2026-07-07)

工程级的**自建 AI 基础设施**三阶段计划:

- **Test / Phase 0(2–4 周):** 租 cloud GPU(RunPod L40S 48GB / GCP L4 SG / AWS G6),**vLLM** 以 OpenAI-compatible API 部署 **Qwen 14B**(必要时 32B quantized),前置 gateway;petaV3 新增 **`internal_ai` provider**;试点 1–3 个文本功能(AI Conversations、20–50 份 transcript 对比 ConversationAnalyzer、WhatsApp draft);Go/No-Go 标准明确(成功率 ≥95%、3–10s、JSON 失败 <5–10%、质量 ≥3.5/5)。
- **Phase 1(1–3 月):「Internal AI Brain」** — **Qdrant** RAG(按源 chunking、PII 脱敏、**服务端权限过滤**)、五个内部功能(Lead Summary / Next Action / WhatsApp Draft / Marketing Brief / Management Chat)、50–100 题 eval、成本报告、on-prem GPU 决策。
- **Phase 2:产品化「Private AI」** 卖给外部房地产公司 — 按客户隔离部署、pilot SOP、打包、**NVIDIA certification** 增信。

难得的纪律性 non-goals:验证前不买硬件、不预训练、WhatsApp 不经人审不自动发、内部未证实不做外部。

## 6.2《PETA Global Architecture — 一套代码 · 两个外壳 · 一个大脑 · 一个飞轮》

**PETA = 房地产经纪的 AI coaching layer**,横跨两市场:

- **两个节点:** 中国(**WeCom** 外壳、会话存档采集、备案境内模型、**PIPL** 数据不出境)与国际(自有 CRM、Claude/GPT 新加坡节点)。同 repo 同 schema;跨境的只有**方法论与匿名基准**。
- **五触点**(chat / 电话 / 视频 / 智能工牌 / 官网-App)经**适配层**归一。
- **飞轮(产品论点):** CAPTURE(覆盖率 ≥80%)→ **LABEL(结果回填 join —「所有人都跳过的接触点」,即护城河)** → LEARN(月度规则 + 区域 **LoRA**)→ GUIDE(`pushed → read → executed` 状态机,一键 Send 即采纳率传感器)→ **MEASURE(uplift A/B,North Star,也是 performance-based billing 的基础)**。建设序 **v0 手动 → v1 自动 → v2 训练** —「别先造训练管线,那是没接油路的引擎」。
- 文件自己诚实划界:目前真实上线的只有 portal 事件分析(30,156 events / 7 identified users),双节点飞轮是 roadmap。

**重要观察:** F2 的实际页面(`ih_user_events`、`InvestHink\AnalyticsController`、Blade)属于**另一个 codebase**(propertylabglobal.com)—「一套代码」目前是*两套代码*,谁并入谁,两份文件都未决定、未排期。

---

# 第七章 · 评估:可行性、方向、deep tech

## 7.1 方向对吗?对 — 三份计划的共识比它们自己知道的还多

本报告在读到两份文件*之前*就独立得出相同结论:F2 的 **LABEL** *就是* Idea #2 Self-Filling CRM;「no labels → no flywheel」*就是*第二章的诚实判断与「先造数据后学数据」;GUIDE 状态机*就是* 4.5 的 suggest→draft→auto;MEASURE *就是* 4.7 的 eval guardrail 升格 North Star。三份独立文件收敛到「outcome-labeled closed loop 是护城河」— 是信号,不是巧合。

## 7.2 可行性,说实话

- **飞轮(F2):可行且正确,一个警告。** v0 手动先行完全正确。风险是*组织性*的:覆盖真实但偏科(1.9 万 WhatsApp、1,694 Zoom;但工牌 4 条、click-event 0、booking 字段全空)。飞轮从 LABEL 被填上那天才转 — 所以 6 个月计划把 Self-Filling CRM 排第一。
- **自建模型(F1):技术成立,但想清楚为什么做。** 当前用量(764 条)自建**省不了钱** — 一台 24/7 L40S 比现在全部 AI 账单还贵;Qwen 在中英夹杂销售分析上大概率落后 Claude/Gemini。*正确*理由:(a) **Phase 2 本身是产品**(数据主权就是卖点);(b) **中国**备案硬要求;(c) 议价与可迁移性。把 Phase 0 当低成本产品研发跑(约一个工程师·月 + GPU 租金),永久保留 fallback 链。
- **中国节点(F2):战略自洽,操作过早。** WeCom Finance SDK、境内 GPU、模型备案、本地主体、PIPL — 是市场进入不是 feature。现在*为它设计*(适配层 schema 就是 4.1 的 LeadTimeline;`AiClient` 本就 provider-agnostic),拿到承诺的中国锚定客户/伙伴才*动手建*。
- **Performance-based billing:有差异化但难。** uplift 归因招争议 → 混合定价(基础订阅 + 双方认可度量的成功费),先内部跑满 ≥2 个季度 MEASURE。

## 7.3 算不算 deep tech?直接回答

**按当前范围:不算,而且没关系。** vLLM + 开源模型 + Qdrant + RAG + LoRA 是世界级*系统集成* — vertical applied AI,不是原创研究;对投资人讲 deep tech 招来错误审视。真正可防守、比多数 deep-tech 故事更稀有的:(1) **专有 outcome-labeled 数据集**及其 uplift 闭环(复利、买不到);(2) 在其上的**区域 LoRA**(随语料增长向 deep tech 靠拢);(3) **跨境分区部署方法论**(少有对手愿复刻的合规工程)。马来西亚生态(Cradle / MDEC / MRANTI)申报 deep-tech 相邻类别站得住;对外*故事*立在 closed loop,不立标签。

---

# 第八章 · 未来 6 个月优先计划(2026-08 → 2027-01)

把第四章的 roadmap、F1 的阶段、F2 的飞轮合并成一条时间线。**总原则:飞轮现在就用手动 + API 模型转起来;自建模型是并行研发线,靠 eval 成绩挣上场资格。**

| 月份 | 飞轮阶段 | 交付物 | 出处 |
|---|---|---|---|
| **1 · 8月** | CAPTURE + v0 手动闭环 | LeadTimeline + 事件流;`AiClient` tool-use;booking 采集修复 + speed-to-lead SLA 队列;**每周手动复盘仪式**立即开始(不需要 GPU)。并行:**GPU POC**(vLLM、`internal_ai`、20–50 份 transcript 评测)。 | 4.1 / 3.1#1–3 / F1 |
| **2 · 9月** | LABEL | **Self-Filling CRM**(suggest 档)— *结果回填率成为 KPI*;Copilot v1(tool-use + drawer、只提议不写);KnowledgeBase + playbook 上传;POC **Go/No-Go**。 | Idea#2 / 4.2–4.3 / F1 |
| **3 · 10月** | GUIDE | Channel agents 第一波:SDR、pre-call briefs、post-conversation 动作;coaching 周报;每条 AI 建议接上**采纳状态机**(`pushed → read → executed`)。**另:petav3 ⇄ propertylabglobal 归并做出决定(哪个 repo 是主干)。** | 4.4 / 4.6 / F2 |
| **4 · 11月** | LEARN(规则) | 编排器 v1(policy 表 + 三档自主权 + 审计);启发式 scoring + score-vs-outcome 记录;**Self-Writing Playbook v1**(月度挖掘赢/输模式回灌 KB);POC 通过则 draft 档功能按 eval 迁移 `internal_ai`;内部 case study 起草。 | 4.5 / Idea#1 / F1 |
| **5 · 12月** | MEASURE | **Uplift A/B 上线**(North Star 报表);attendance + referral agents;多租户隔离设计;1–2 名工程师 NVIDIA certification;PDPA 法务审查。 | F2 / 4.4 / F1 |
| **6 · 1月** | 产品化 | 选定一家外部 **pilot 中介** + SOP;混合定价草案;内部 case study + 实测 uplift 搭 demo。**两道数据闸门:** on-prem GPU(POC + 用量撑得起才买)· 中国节点(有承诺伙伴才建)。 | F1 / F2 |

**明确的 6 个月 non-goals:** 不建中国节点、不买 on-prem GPU、不做本地视频生成、不整体替换 provider、draft 档以上不自动发客户(除非草稿质量已测满 2 个月)、不做 codebase 迁移(第 3 个月要的是*决定*,不是迁移)。

---

# 附录 A · 给评审 AI model 的话

你在评审一个 Laravel/Inertia 房地产销售平台的战略报告。可索取的 ground truth:`GUIDELINES.md`、`docs/modules_handbook/`(尤其 `shared/ai`、`shared/conversation-analysis`、`manage/messages/whatsapp/*`、`manage/engagement`、`manage/leads`)、`src/Ai/Services/AiClient.php`、第二章的实测数据。值得挑战的主张:(1) Copilot v1 用 tool-use-over-APIs 而非 embeddings 优先;(2) workflows-first 编排 vs 自主 multi-agent;(3) 标签稀薄下「先造数据后学数据」的顺序之赌;(4) WhatsApp 中心化是否把风险过度集中在一个号码;(5) 第五章 11 个 idea 的排序、以及是否应顶替第八章时间线中的项目;(6) 第七章对自建模型经济性与中国节点时机的判断。

**Sources:** [Salesmate — AI agent trends 2026](https://www.salesmate.io/blog/future-of-ai-agents/) · [Cflow — AI workflow automation trends 2026](https://www.cflowapps.com/ai-workflow-automation-trends/) · [SS&C Blue Prism — AI agent trends](https://www.blueprism.com/resources/blog/future-ai-agents-trends/) · [On-Demand — agentic AI automation](https://blog.on-demand.io/the-future-of-ai-agents-2/) · [Portkey — MCP vs RAG in production](https://portkey.ai/blog/mcp-vs-rag/) · [ProjectPro — MCP + RAG implementation](https://www.projectpro.io/article/mcp-with-rag/1144) · [Anthropic — multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)