您的数据从何而来：我们如何做商业情报，如何测量购买意向
如果您在过去几周收到了我们的一封邮件，您很可能会问自己一个我们也会问自己的问题：他们是从哪里拿到我的名字的？
这就是那个完整的答案。没有营销式的委婉说辞，也没有那句让人省心的"我们专有的人工智能系统"。我们要展示的是完整的方法：我们用哪些来源、哪些工具，如何打分，剔除什么，记录什么，以及最终保存在哪里。公开这一切的理由很简单：如果我们要给您发冷邮件，您有权知道我们是如何找到您的。
还有第二个理由，没那么高尚，但同样坦诚：这套方法就是我们的服务本身。要解释我们用 Odoo 和受治理的 AI 智能代理做什么，最好的方式就是展示我们对自己商业运营做了什么。
1. 真正的问题：大多数"线索"根本不存在
2026 年的 B2B 潜客开发有一个算术层面的问题。生成名单的工具产出海量数据轻而易举。一万条记录只需点一下鼠标。而其中几乎没有一条有任何意义。
我们的起点是一次令人不适的自我剖析。我们通过商业自动化平台积累了数千个联系人。当我们去审计这些数据背后到底有什么时，发现 67% 不符合我们的理想客户画像，将近三分之一位于我们服务范围之外的地理区域，而平台称之为"意向"的信号，结果不过是话题匹配：只要有人在某条帖子里提到"ERP"这个词，系统就把他标记为有意购买 ERP。按照这个标准，我们自己的竞争对手都成了热门商机。
正是在这个节点，我们决定从零开始构建这套方法，并把一条令人不适的规则放在核心：
一条信号只有在我们能逐字引用它、并说清它从何而来时，才算数。
其余的一切——推断出来的、自我声称的、可能的——都算作零。不是"算得少"，而是算作零，而且在代码里就是这样写的。
查看 Mermaid 源码
flowchart LR
A["数量
10,000 条记录"] -->|"旧方法"| B["'合格线索'
凭话题匹配"]
B --> C["已发送邮件"]
C --> D["噪声"]
E["由 ICP 界定
的范围"] -->|"当前方法"| F["每条记录
都有可引用证据"]
F --> G["硬性排除
闸门"]
G --> H["带来源地
记录到 Odoo"]
style D fill:#7c2d12,color:#fff
style H fill:#166534,color:#fff
style B fill:#78350f,color:#fff
style F fill:#1e3a5f,color:#fff
2. 完整架构，一览全貌
在进入细节之前，先看整个系统的样子。五个层级，每一层的职责都是杀掉那些不该进入下一层的记录。
查看 Mermaid 源码
flowchart TD
subgraph L1["1 · 来源"]
F1["DENUE / INEGI"]
F2["公开网络
与技术足迹"]
F3["行业
目录"]
F4["职业
社交网络"]
end
subgraph L2["2 · 数据增强"]
E1["决策者
识别"]
E2["邮箱
验证"]
E3["基础设施
识别"]
end
subgraph L3["3 · 评估"]
R1["5 轴 / 100 分
评分表"]
R2["意向事件
目录"]
end
subgraph L4["4 · 闸门"]
G1["硬性
排除"]
G2["数据质量
闸门"]
end
subgraph L5["5 · 记录"]
O1["Odoo · res.partner
18 个自有字段"]
O2["标签
与屏蔽名单"]
O3["chatter 中的
台账"]
end
L1 --> L2 --> L3 --> L4 --> L5
style L1 fill:#0f172a,color:#fff
style L4 fill:#7c2d12,color:#fff
style L5 fill:#166534,color:#fff
3. 来源：先用免费的和官方的
顺序是固定的，不容商量。我们总是先从公开、官方且免费的东西入手，只有当一条记录已经挺过了这些廉价的过滤器之后，才向下动用付费 API。这不是出于美德：而是因为数据增强 API 按额度计费，而我们每月的配额是有限的——数量级是几十次查询，而不是几千次。
查看 Mermaid 源码
flowchart TD
S0["候选记录"] --> S1{"是否存在于
INEGI 的 DENUE 中？"}
S1 -->|"否"| X1["剔除或
手动核实"]
S1 -->|"是"| S2["SCIAN 行业、
人员规模区间、
地理位置"]
S2 --> S3{"按行业与规模
是否契合 ICP？"}
S3 -->|"否"| X2["剔除
成本：$0"]
S3 -->|"是"| S4["网站：
技术足迹"]
S4 --> S5{"是否有可验证的
技术信号？"}
S5 -->|"否"| S6["仍然存活，
但痛点未经证实"]
S5 -->|"是"| S7["基础设施
识别"]
S6 --> S8
S7 --> S8{"是否值得
动用 API 额度？"}
S8 -->|"是"| S9["决策者
数据增强"]
S8 -->|"否"| X3["冻结"]
style X1 fill:#7c2d12,color:#fff
style X2 fill:#7c2d12,color:#fff
style X3 fill:#78350f,color:#fff
style S9 fill:#166534,color:#fff
具体的来源：
| 层级 | 我们使用的 | 为什么 |
|---|---|---|
| 经济普查 | 通过自有连接器接入 DENUE（INEGI） | 官方的 SCIAN 行业、人员规模区间与地理定位。免费。 |
| 公开网络 | 企业官网、元数据、子域名、WHOIS 与 DNS 记录 | 一家企业对外暴露的基础设施是可由第三方验证的证据；而它在首页上对自己的描述则不是。 |
| 目录 | 公开的行业名录与出口商名录 | 用于界定范围，而非用于定性。 |
| 职业社交网络 | LinkedIn 公开个人资料 | 职位、任职年限，以及——非常有用的——对其已在使用的软件的原文提及。 |
| 产品足迹 | 对公开可访问的 Odoo 安装的探测 | 识别版本、暴露面以及开放的测试环境。 |
出于明确的决定，我们从不使用：泄露的数据库、安全漏洞、个人邮箱或私人电话。我们的技术识别工具被配置为一份包含 24 个允许模块与 23 个明确禁止模块的白名单，以默认拒绝模式运行。按邮箱和按电话的搜索种子在配置层面被封锁：该工具只接受一个域名或一个组织名称作为起点。这不是某人在一次潜客开发会话中出于方便就能改动的设置——这是容器的基础配置。
4. 我们在探测公开足迹时发现了什么
这大概是让我们付出最大代价、也为我们省下最多的一个发现。
七月底，我们在墨西哥、拉丁美洲和美国南部对公开可访问的 Odoo 安装做了一次大规模探测。原始结果：121 个经验证的唯一域名。这个数字在一份常规的销售报告里会被呈现为"121 个新线索"。
当我们把它们放进评分表后，真正存在的是这些：
查看 Mermaid 源码
pie showData
title 具有 Odoo 公开足迹的 121 个域名的真实构成
"合作伙伴与顾问（直接竞争对手）" : 73
"公共部门、教育机构、已迁移、测试环境" : 20
"真实候选对象" : 28
其中六成是我们自己的竞争对手。 这些企业之所以出现在一次"谁在用 Odoo"的探测里，恰恰是因为它们在为别人实施 Odoo。在随后一轮聚焦北美的行动中，24 个新域名里有 22 个是合作伙伴。百分之九十二。
如果那次行动最终变成一份发给销售团队的 CSV，我们就会写邮件，向那些靠提供 Odoo 支持为生的公司兜售 Odoo 支持。而我们还会把它报告为"已处理 121 个商机"。
同一类的第二个发现：我们有一份将近 200 条记录的名单，是围绕一个有保质期的商业触发点构建的——一个在 2026年7月19日 结束的国际活动。到八月的切分点，其中 199 条记录里有 176 条一下子全部失效，不是因为这些企业发生了变化，而是因为跟它们对话的理由已不复存在。一个不打招呼就过期的数据，比没有数据更糟。
5. 刻画一家企业：一次真实作业的全过程
当一个候选对象挺过了廉价过滤后，就进入完整的流程。下面是一次真实作业的样子，一步一步。
查看 Mermaid 源码
sequenceDiagram
autonumber
participant A as 分析员（智能代理 + 人）
participant M as 向量记忆
participant D as DENUE / INEGI
participant W as 网络与技术 OSINT
participant E as 数据增强 API
participant O as Odoo
A->>M: 我们是否已经了解这家企业？
M-->>A: 历史记录、既往裁决、排除项
A->>A: 在花费之前先检查可用额度
A->>D: 行业、规模区间、地址
D-->>A: 官方档案
A->>W: 站点、子域名、DNS、软件版本
W-->>A: 可验证的技术信号
A->>A: 用公开来源梳理相关方
A->>E: 仅当情况值得时：验证邮箱
E-->>A: 验证状态与置信度
A->>A: 应用评分表与闸门
alt 闸门关闭
A->>O: 记录档案、分数与被拦截的原因
else 闸门打开
A->>O: 记录档案、决策者、信号与台账
end
O-->>A: 以重新读取确认，而非以写入返回的 "true" 确认
最后那个细节比看起来更重要。一个报告"完成，已保存"却不加验证的自动化代理，就是一个会捏造的代理。我们 Odoo 中的每一次写入，都要通过重新读取该记录来确认。
6. 相关方梳理：五种角色，而非一份名字清单
一个联系人不等于一个决策者。我们要弄清的是谁做决定、谁承受问题、谁能否决这笔采购、以及如果项目推进谁会在内部受益。
查看 Mermaid 源码
mindmap root((相关方
地图)) 经济买家 签署预算 以金钱与风险来衡量 使用者 每天承受问题 真实痛点的来源 技术评估者 验证可行性 可从架构层面否决 内部拥护者 项目推进则受益 向内部翻译 阻拦者 维护现状 有时就是现任供应商
最低目标是两个具名的决策者，每人都有邮箱和电话，并明确标出哪些是已验证的、哪些是推断的。一个按规律推导出来的邮箱——猜测 [email protected]——是一个假设，并被如此标记。我们绝不向一个假设发送任何东西。
这里有必要坦白一个方法层面的问题。八月我们发现，我们自己有十一份档案写着"识别出零个人"。这是假的。这次搜索只按企业类型的记录做了筛选，没有下钻到子联系人。那里其实有 36 个人，包括三位总经理。修正之后，十一个分数上升了，其中一个整个类别都变了。错误在我们这边，在我们自己的查询里，而且整整两周都不可见，因为那个结果——"没有人"——恰好印证了我们本来的猜想。
这正是评分表被设计来捕捉的那种失误，而它恰恰在我们身上发生了。
7. 数据质量闸门：什么时候不产出任何东西
这是让本方法区别于一个文档生成器的部分。闸门在撰写任何商业材料之前就要评估。
查看 Mermaid 源码
flowchart TD
C0["情报档案
已完成"] --> C1{"是否有 2 个以上具名决策者
同时具备邮箱和电话？"}
C1 -->|"否"| N1["交付物 = 缺什么
的说明报告"]
C1 -->|"是"| C2{"是否有具体且可验证的
技术优先级信号？"}
C2 -->|"否"| C2b{"是否有明确理由
仍然继续推进？"}
C2b -->|"否"| N1
C2b -->|"是"| C3
C2 -->|"是"| C3{"是否有未解决的
红旗标记？"}
C3 -->|"是"| N2["拦截 + 永久
标签"]
C3 -->|"否"| Y1["闸门打开"]
N1 --> R["下一步
建议"]
N2 --> R
style N1 fill:#78350f,color:#fff
style N2 fill:#7c2d12,color:#fff
style Y1 fill:#166534,color:#fff
我们协议里的原文指令写着："不要仅仅为了凑齐作业就强行生成商业文档"。这听起来理所当然。但在实践中，一旦有了数字上的压力，这是最先被打破的一条。
8. 测量意向：事件目录
我们来到了问题的核心。什么才是购买意向？
行业里常规的回答是邮件打开、点击、网站访问与社交提及的某种组合。这四种我们全部拒绝。一封被打开的邮件可能只是邮件客户端在预加载图片。一次点击可能是企业安全过滤器所为。LinkedIn 上一次"ERP"的提及可能来自一个竞争对手。
我们的分类法区分十种信号类型，其中只有部分算作意向：
查看 Mermaid 源码
mindmap root((信号
分类法)) 算作意向 明确的需求 痛点信号 项目信号 对供应商的不满 预算或时间表 算作背景 转介机会 权威机会 联盟信号 不算数 噪声 因隐私被封锁
而这就是带权重的事件目录。在计算分数的代码里，它就是这样写的：
查看 Mermaid 源码
flowchart LR
subgraph P1["高权重 · 已证明的投入"]
A1["已付款发票 · 20"]
A2["已完成会议 · 12"]
A3["已发送报价 · 10"]
A4["已演示 · 10"]
end
subgraph P2["中权重 · 商机方主动索取"]
B1["索要会议 · 9"]
B2["索要报价 · 9"]
B3["尽职调查提问 · 8"]
B4["声明的痛点 · 8"]
B5["技术交流 · 8"]
end
subgraph P3["低权重 · 有对话"]
C1["回复了邮件 · 6"]
C2["邮件往来 · 6"]
C3["声明的兴趣 · 5"]
C4["已开通直接渠道 · 5"]
C5["己方发起的电话联系 · 4"]
C6["已确认的活动 · 3"]
end
subgraph P0["零权重 · 不是意向"]
D1["已投递触达 · 0"]
D2["已接收触达 · 0"]
D3["话题匹配 · 0"]
D4["打开但无回复 · 0"]
end
style P1 fill:#166534,color:#fff
style P2 fill:#1e3a5f,color:#fff
style P3 fill:#78350f,color:#fff
style P0 fill:#7c2d12,color:#fff
请注意零权重那一栏里有什么：已投递一封邮件、已接收一封邮件、话题匹配、以及打开但无回复。这正是大多数需求生成软件所依赖的四个指标。对我们来说它们都算作零，而这个决定让我们不得不重建整个看板。
五意向规则
在这份目录之上，架起了我们于 2026年7月17日 确立、如今已成为我们 CRM 中一个完整字段的操作性定义：
一个联系人不会因为回复就变成线索。一个候选对象只有在累计到五个或以上的可观测的购买意向——会议、已发送的报价、技术交流、演示——时，才成为合格线索(lead)。一次回复，仅凭它本身，算作零。
而它还带着后半句，被引用得少得多，但在经济上同样重要：
一旦达到五个意向，就停止对该候选对象继续开发。
这条规则从两端都切掉了浪费。它既阻止追逐那些从未给出信号的人，也阻止在那些已经给足信号的人身上继续耗费开发精力。这两种错误代价相同。
查看 Mermaid 源码
stateDiagram-v2
[*] --> 疑似对象: 进入范围
疑似对象 --> 候选对象: 识别出决策者
且具备有效渠道
疑似对象 --> 排除: 硬性闸门
候选对象 --> 商机: 第 1 个可观测
且带引用的意向
候选对象 --> 冷却: 一轮节奏后
0 个意向
商机 --> 商机: 第 2、3、4 个意向
商机 --> 线索: 第 5 个意向
商机 --> 冷却: 信号熄灭
冷却 --> 候选对象: 30 天后重新进入
线索 --> [*]: 停止开发
note right of 线索
本文
到此为止
end note
9. 完整评分表：100 分，5 轴
已验证的意向是五轴之一。这一百分是这样分配的：
查看 Mermaid 源码
flowchart TD
T["总分 · 100"] --> E1["ICP 契合度 · 30"]
T --> E2["可验证的痛点 · 20"]
T --> E3["决策者 · 25"]
T --> E4["已验证的意向 · 20"]
T --> E5["接触成本 · 5"]
E1 --> E1a["行业 · 12"]
E1 --> E1b["地理 · 6"]
E1 --> E1c["规模 · 6"]
E1 --> E1d["复杂度 · 6"]
E2 --> E2a["已确认的
旧版本 · 12"]
E2 --> E2b["脆弱的技术栈 · 5"]
E2 --> E2c["监管压力 · 3"]
E2 --> E2d["推断的痛点 · 0"]
E4 --> E4a["仅限带引用与来源
的可观测事件"]
style E2d fill:#7c2d12,color:#fff
style E4a fill:#166534,color:#fff
还有一个三轴的轻量版本——相关方、技术信号与规模契合，各 0 到 3 分——我们用它来批量筛选整段的细分。最终分级是：9 分中拿到 7 分或以上为高，4 到 6 分为中，3 分或以下为低。并配有一条覆盖分数的规则：如果这家企业不是我们要找的那类主体，红旗标记就会作废其优先级，无论它攒了多少分，并强制移除标签，而不仅仅是在评论里记下这个问题。
"记下它"与"移除标签"之间的这个区别，让我们付出了三次事故的代价。写在一个文本字段里的散文式裁决，并不能阻止那条记录在下一段细分里再次出现。只有标签能阻止它。在修正流程之前，我们记录到同一家被拦截的企业重新出现了三次。
当你改变评分表时会发生什么
值得展示一下真实的影响。当我们从七月的评分表切换到八月的——那个要求可引用证据的版本——时，一个我们原本打了 88 分（满分 100）的客户，跌到了 36 分。企业没变，变的是我们接受为证据的东西。
在同一个切分点，被评估的 351 条记录产生了 38 个硬性排除。三十八条记录，直到那一天为止都还被算作管道内的商机。
查看 Mermaid 源码
quadrantChart
title 投入的努力 对比 获得的信号
x-axis "少量努力" --> "大量努力"
y-axis "无信号" --> "有可引用信号"
quadrant-1 "深耕"
quadrant-2 "速赢"
quadrant-3 "搁置待命"
quadrant-4 "停止：无底洞"
"带 5 个意向的客户": [0.72, 0.93]
"带 3 个意向的客户": [0.55, 0.68]
"带决策者的候选对象": [0.30, 0.42]
"多次触达无回复": [0.75, 0.08]
"无联系人的 OSINT 域名": [0.16, 0.05]
10. 硬性闸门：我们永远不会写信给谁
无论分数如何，有些类别是凭决定、而非凭计算被排除出范围的。
查看 Mermaid 源码
flowchart TD
R["被评估的记录"] --> G1{"是否为 Odoo 的
合作伙伴或顾问？"}
G1 -->|"是"| X1["排除
直接竞争对手"]
G1 -->|"否"| G2{"是否为公共部门、
国有或教育机构？"}
G2 -->|"是"| X2["排除
永久闸门"]
G2 -->|"否"| G3{"是否存在法律
或声誉风险？"}
G3 -->|"是"| X3["排除
签署的决定，
而非因遗漏"]
G3 -->|"否"| G4{"是否为当前版本
且无已证实痛点？"}
G4 -->|"是"| X4["排除
无可提供"]
G4 -->|"否"| G5{"是否要求
不被联系？"}
G5 -->|"是"| X5["屏蔽名单
永久"]
G5 -->|"否"| P["继续进入评分"]
style X1 fill:#7c2d12,color:#fff
style X2 fill:#7c2d12,color:#fff
style X3 fill:#7c2d12,color:#fff
style X4 fill:#78350f,color:#fff
style X5 fill:#450a0a,color:#fff
style P fill:#166534,color:#fff
关于这一点有两点说明。第一：因法律或声誉风险而做的排除，被记录为签署的决定，而不是一次遗忘。如果一个客户因此被移出范围，会写清是谁做的决定以及为什么。第二：维护两份互不相通的屏蔽名单，是一种悄无声息地违背某个已明确要求不被联系者意愿的方式。这在我们身上发生过，我们发现了它，并把这些名单合并进了 Odoo 的原生记录中。
11. 让一段细分触达不到任何人的三个缺陷
在一段细分被判定为可用之前，会检查三个具体的故障。三者都是数据层面的、而非文案层面的，而且三者都是无声的。
查看 Mermaid 源码
flowchart TD
S["带广域名的
细分"] --> D1{"缺陷 1
父记录
是否有邮箱？"}
D1 -->|"否"| F1["邮箱存在于
子联系人上。
细分为空。"]
D1 -->|"是"| D2{"缺陷 2
名称是否为
企业名称？"}
D2 -->|"否"| F2["从站点抓取的标题。
动态称呼变成了
'Login | My Website'。"]
D2 -->|"是"| D3{"缺陷 3
可编辑正文与
已发送正文
是否一致？"}
D3 -->|"否"| F3["编辑器看起来正常
发出去的却是旧文本。
无声咬人的那一个。"]
D3 -->|"是"| OK["可接纳的细分"]
style F1 fill:#7c2d12,color:#fff
style F2 fill:#7c2d12,color:#fff
style F3 fill:#450a0a,color:#fff
style OK fill:#166534,color:#fff
第一个比人们预想的更常见。在我们自己的数据库里，64% 的企业记录在父记录上没有邮箱——邮箱都存在于子联系人上。一段建立在企业模型之上、却不下钻到人的细分，只会触达其真实受众极小的一部分，而报告却会说"发送成功"。
还有一条关于哪种邮箱可接纳的卫生规则。只有三种来源能通过：一位经直接验证的具名决策者、一个由企业本身逐字公开的决策者邮箱、或一个由企业公开的企业通用邮箱。任何未经验证、按规律推导的邮箱都不能通过。
12. 一切最终落在何处：着陆到 Odoo
情报作业到此结束。前面的一切之所以存在，都是为了在我们的 Odoo 中产出一条记录，让一个人可以不必向任何人索要解释就能审计它。
我们不用一份平行的电子表格，不用一个外部平台，也不用一个自由填写的备注字段。我们在联系人模型上创建了18 个自有字段，配有专属视图，分为四组。
查看 Mermaid 源码
erDiagram
RES_PARTNER ||--o{ CONTACTO_HIJO : "拥有决策者"
RES_PARTNER ||--o{ ETIQUETA : "被分类为"
RES_PARTNER ||--o{ MENSAJE_CHATTER : "的台账"
RES_PARTNER ||--o| OPORTUNIDAD_CRM : "生成"
LISTA_BLOQUEO ||--o{ RES_PARTNER : "屏蔽"
RES_PARTNER {
int x_tg_scoring_total "0-100"
int x_tg_eje_stakeholders "0-3"
int x_tg_eje_senal_tecnica "0-3"
int x_tg_eje_ajuste "0-3"
bool x_tg_bandera_roja "作废分级"
int x_tg_intenciones_n "五意向规则"
text x_tg_intenciones_detalle "带来源的台账"
char x_tg_decisor_nombre "人"
char x_tg_decisor_cargo "角色"
char x_tg_decisor_canal "有效渠道"
text x_tg_dolor_verificable "原文引用"
char x_tg_version_odoo "技术信号"
text x_tg_siguiente_accion "承诺"
char x_tg_fuente_dato "可追溯性"
date x_tg_fecha_scoring "有效期"
selection x_tg_tier "高 中 低"
selection x_tg_clasificacion "从线索到排除"
selection x_tg_icp "目标画像"
}
CONTACTO_HIJO {
char nombre
char cargo
char correo_verificado
char grado_confirmacion
}
ETIQUETA {
char tier_y_scoring
char banderas_rojas
char compuertas_permanentes
char origen_del_dato
}
真正承担繁重工作的四个字段：
x_tg_fuente_dato—— 这条记录从何而来。没有它，两个月后没有人记得起一家企业是通过官方普查、通过技术探测、还是因为有人手工录入才进来的。x_tg_intenciones_n与x_tg_intenciones_detalle—— 五意向规则的计数器，以及支撑它的台账。每一条已记录的意向都带着它的引用和日期。如果无法引用，就不记录。x_tg_fecha_scoring—— 打分的日期。没有日期的分数是一种意见。有了日期，它就是一个会过期的数据。x_tg_bandera_roja—— 那个无论分数如何都作废优先级的开关。
在这之上，是一套将各项决定具象化的标签系统——评分分级、按行业的永久闸门、不可用邮箱的标记、批次来源——以及每条记录的 chatter 中一份包含完整情报报告的台账。那份台账才是重点所在：结论和它的证据紧贴着记录而存在，而不是散落在某份需要有人去翻找的文档里。
查看 Mermaid 源码
timeline
title 方法的演进：从邮件打开到可引用的证据
section 2026年5月
首个 ICP 画像与 0 到 100 分评分 : 从设计上就拒绝追踪像素
信号的初始分类法 : 把观测到的与推断的分开的规则
section 2026年6月
带白名单的技术 OSINT 层 : 对真实漏斗的诊断
发现第一个空漏斗 : 大量触达，零信号被记录
section 2026年7月
确立五意向规则 : 一次回复，仅凭它本身，算作零
对继承数据库的审计 : 原始 OSINT 中六成是竞争对手
section 2026年8月
推断痛点归零的 100 分评分表 : 对整个范围的完整重新分类
迁移到 Odoo 原生字段 : 证据紧贴着记录而存在
13. 那些工具，指名道姓
既然我们在展示方法，那也一并展示这个作坊。所有这一切都通过标准化的连接器运作，由 AI 智能代理在明确的权限下调用。
查看 Mermaid 源码
flowchart LR
subgraph AG["智能代理 · 按工具授权"]
AG1["商业情报
协议"]
AG2["细分策展
协议"]
AG3["管道复盘
与竞争情报"]
end
subgraph CN["连接器"]
C1["DENUE · INEGI"]
C2["自有技术
识别"]
C3["邮箱
验证"]
C4["人员
数据增强"]
C5["受控
浏览器"]
C6["网络搜索
与读取"]
end
subgraph MEM["记忆与控制"]
M1["向量记忆"]
M2["追踪与
可观测性"]
M3["带日期的
审计台账"]
end
subgraph SR["记录系统"]
S1["Odoo"]
end
AG --> CN --> SR
AG <--> MEM
MEM --> S1
style SR fill:#166534,color:#fff
style MEM fill:#1e3a5f,color:#fff
| 功能 | 工具 | 治理说明 |
|---|---|---|
| 官方经济普查 | 自有连接器接入 DENUE（INEGI） | 免费。永远排第一。 |
| 技术识别 | Flowsint，自托管 | 24 个模块白名单，23 个禁止，默认拒绝。邮箱与电话种子被封锁。 |
| 邮箱验证 | Hunter.io | 每月 50 次查询的共享额度。到 95% 硬性停止。 |
| 人员数据增强 | Apollo.io、Clay、Snov.io | 敏感个人数据默认关闭。每位决策者做一次数据增强，而非出于好奇。 |
| 辅助浏览 | 受控的 Chrome | 用于那些不执行页面就无法读取的来源。 |
| 记录系统 | Odoo（自托管与云端） | 结论的唯一归宿。 |
| 智能代理记忆 | Mem0 与 Qdrant | 避免重做已完成的调研、避免把额度烧两遍。 |
| 可观测性 | Grafana、Langfuse、Prometheus | 每个代理做了什么、何时做的、成本几何。 |
| 自动化 | n8n | 对重复性任务的编排。 |
有两个值得明说的治理决定，因为它们是人们问我们最多的：
没有任何一个工具会独自向生产环境写入。 智能代理产出草稿。向 Odoo 的写入要经过复核，且每一次写入都通过重新读取该记录来验证。不因紧急而破例。
我们下线了一整个商业平台。 我们运营了数月一款基于 AI 的线索生成工具。在审计它对"热门线索"的定义时，我们发现那不过是社交帖子的话题匹配，其强度被任意声称，而且把我们自己的竞争对手也算了进去。我们把它下线了。它在技术上并没有失败：它做的恰恰是它承诺的事。问题在于它所承诺的东西本身。
14. 今天我们的记录里有什么
为了以真正的透明来收尾，这就是作为以上一切的成果、今天存在于我们 Odoo 中的东西：
- 一个由数百家被评估企业构成的范围，每一家都有分数、打分日期和数据来源。
- 一套将各项决定具象化的标签：优先级分级、按行业的永久闸门、不可用邮箱的标记、加载批次的来源。
- 一份合并后的、系统原生的屏蔽名单，能在任何发送工具更替中存活下来。
- 每条记录一份带完整商业情报报告的台账：我们发现了什么、在哪里发现的、以及我们得出了什么结论。
- 每个客户一个意向计数器，配有其带引用的台账，以及一个从排除到线索的分类——依据写下来的规则，而非当天的临时判断。
还有一个比任何其他数字都更说明问题的比例：在整个被评估的范围里，绝大多数被归类为疑似对象或候选对象。也就是说：我们明确承认，我们的大多数记录尚未对任何事表现出兴趣。把它们称作"线索"就是自欺欺人。
查看 Mermaid 源码
flowchart LR
subgraph ORI["来源"]
O1["出现在普查
或公开网络中"]
O2["通过行业与规模
的过滤"]
end
subgraph INV["调查"]
I1["查找相关人员
与技术信号"]
I2["可验证的予以验证，
推断的予以标注"]
end
subgraph JUI["评判"]
J1["通过评分表
与闸门"]
J2["记录理由，
即使被排除"]
end
subgraph REG["记录"]
R1["落入 Odoo，带
评分、来源与日期"]
R2["团队任何人
都可审计"]
end
ORI --> INV --> JUI --> REG
style ORI fill:#0f172a,color:#fff
style REG fill:#166534,color:#fff
如果您就在那些记录里
本文特意到此为止。我们不会去描述在拥有一条合格记录之后我们会做什么——那是我们与您之间那场对话的事，如果我们真的有那场对话的话。
我们确实想说清楚的是下面这一点。如果您收到了我们的一封邮件，那不是因为我们买了一个数据库。而是因为您的企业出现在一份官方经济普查里，或者因为您的公开基础设施发出了一个我们懂得解读的技术信号，又或者因为您团队里有人在一个公开的职业资料上发布了某些相关内容。全部来自可公开访问的来源。没有任何漏洞、没有任何泄露数据、没有任何个人邮箱。
而如果您希望我们不要保留：写信给我们，您会在当天、永久地从我们的记录中被移除，在系统里而不是在一张便签上。如果您希望看看我们掌握了关于您企业的哪些内容，提出请求，我们会完整地发给您。那是您的信息。
我们认为，一家将要向您提议治理您数据的企业，理应从展示它如何治理自己的数据开始。
Transgenia 用受治理的 AI 智能代理来实施与运营 Odoo。请写信给我们：[email protected] · 隐私声明