企业官网建设流程全解析

这两年技术社区里关于“AI in GTM at Notion”这类岗位方向的讨论越来越多。很多人第一反应是疑惑：Notion 不是做笔记、文档和知识库的产品吗，为什么会专门招 AI Engineer 去支持 GTM？其实这背后是 SaaS 行业一个非常明显的变化——GTM（Go-To-Market）正在从“纯人力驱动”转向“AI 工程驱动”。

本文不打算猜测 Notion 内部的具体实现，而是以“AI in GTM at Notion”这个岗位方向为引子，从一名 AI Engineer 的视角，完整拆解在 GTM 场景中落地 AI 的工程路径。内容会覆盖 GTM 业务链路、系统架构设计、线索打分、个性化邮件生成、会议纪要结构化三个实战案例，以及评估体系、常见问题和工程最佳实践。无论是正在做 AI 应用开发的工程师，还是想了解 AI 如何改造商业化流程的产品和技术负责人，这篇文章都能给你一条可以照着落地的思路。

1. AI in GTM 是什么：从岗位 JD 说起

1.1 先理解 GTM 是什么

GTM 全称是 Go-To-Market，中文常翻译为“市场进入”或“上市策略”。它并不是某一个具体岗位，而是企业把产品推向市场并完成商业化闭环的一整套业务流程。对于 SaaS 和生产力工具类产品来说，GTM 通常包括市场（Marketing）、销售（Sales）、客户成功（Customer Success）三条主线，覆盖从品牌曝光、线索获取、线索培育、销售触达、转化签约，到客户交付、续费与增购的完整生命周期。

打个比方：研发团队负责“把车造出来”，GTM 团队负责“把车卖出去并且让用户愿意一直开”。后者需要解决的问题包括：目标客户是谁、用什么渠道触达、销售说什么话能打动对方、客户用完之后如何续费、哪些客户最有增购潜力。这些问题的共同特点是大量依赖非结构化信息：客户官网文案、会议录音、销售邮件、历史成交记录、产品使用行为。过去这些信息靠销售和运营人工整理，速度慢、标准不统一、容易遗漏；而现在，LLM 恰好擅长处理这类非结构化文本，这就是 AI 进入 GTM 的根本原因。

1.2 AI Engineer 在 GTM 团队里到底做什么

很多人会把 AI Engineer 理解成“用 AI 写文案的人”，这是极大的误解。GTM 场景下的 AI Engineer 核心任务是：把大模型能力嵌入到商业化业务流程中，并且保证它稳定、可控、可评估地运行。具体来说，日常工作通常包含四类：

第一是数据工程。GTM 相关的数据散落在 CRM、官网埋点、邮件系统、会议工具、客服工单等多个地方，AI Engineer 需要先把这些数据打通，形成统一的客户对象模型和事件流，才能让模型“有料可用”。第二是模型应用开发。包括设计 Prompt、构建 RAG 检索链路、开发 Agent 工具调用、封装模型 API 服务等。第三是评估与调优。线上效果怎么样、幻觉率多高、跟人工效果差多少，都需要建立评估集和指标体系。第四是工程化落地。把模型能力包装成销售、市场、客户成功团队日常能使用的产品功能，比如浏览器插件、CRM 侧边栏、自动化工坊、Slack/企微机器人。

换句话说，AI Engineer 是“业务问题翻译成技术问题，再把技术问题封装成业务工具”的桥梁岗位。这个岗位不要求你懂销售话术，但要求你能理解销售流程中的关键节点和痛点，并用系统工程的方式解决它们。

1.3 为什么 Notion 这类产品公司要设这样的岗位

Notion 本身是一款集文档、数据库、Wiki、项目管理于一体的工作平台，它的用户群体中有大量知识工作者和创业团队。把 GTM 和 AI 结合起来，对 Notion 这类公司来说有天然的业务基础：一方面，Notion AI 已经证明了大模型能力与产品场景结合的价值；另一方面，Notion 面向的是企业级客户，其商业化团队需要处理大量结构复杂、决策链条长的销售流程，这正好是 AI 可以发挥优势的地方。

更深一层的原因是行业共识：AI 在 to B 产品中的价值，已经从“让用户自己用 AI 提高效率”，演变为“让公司自己的 GTM 团队用 AI 提升商业化效率”。前者是产品功能，后者是内部提效和收入增长引擎。所以这类岗位的真实定位，往往不是做一个 Demo，而是通过机器学习、LLM、Agent 等工程技术，直接或间接影响获客成本、转化率、续费率和客单价等核心商业指标。理解了这一点，再看后面的技术方案，视角就会完全不同。

2. GTM 业务链路与 AI 介入点

2.1 一条完整的 GTM 主链路

不同的公司 GTM 流程会有差异，但抽象之后基本可以归结为一条主链路：线索获取 → 线索清洗与打分 → 销售触达 → 跟进与转化 → 客户成功 → 续费与增购。

线索获取阶段，市场和增长团队通过内容营销、广告投放、活动、官网注册等方式获取潜在客户；线索清洗与打分阶段，需要判断一条线索是否匹配目标客户画像（ICP），是否具备购买意向，决定销售要不要花时间跟进；销售触达阶段，销售代表需要写邮件、打电话、约会议；跟进与转化阶段，销售要理解客户需求、做产品演示、处理异议、推动报价和合同；客户成功阶段，客户成功经理要保证客户上线、使用、看到价值；最后是续费与增购，需要识别健康度高的客户、发现扩展机会。

这条链路每一个环节都产生大量文本数据，也存在大量需要人工判断和重复操作的步骤。过去这些工作依赖销售经验和个人执行力，效率上限很低。AI 的作用，不是替代人做最终决策，而是把“信息收集、分析、起草、分类、预测”这类高重复、高耗时的工作自动化，让人把精力集中在真正需要人的判断力和关系维护的环节。

2.2 每个环节的 AI 应用场景

从表格可以看出，AI 在 GTM 中的产出物不只是一个“回答”，而是能被下游系统消费的数据，比如字段、标签、分数、建议、草稿。这也意味着 AI Engineer 写的不只是 Prompt，更是“文本进，结构化数据出”的数据管道。

2.3 场景优先级怎么排

GTM 可做的 AI 场景很多，资源有限时建议按三个标准排序：数据成熟度、业务价值、容错空间。数据成熟度指的是该场景所需的数据（CRM 记录、邮件历史、行为事件）是否已经沉淀且可访问；业务价值指对应环节改进后对收入或成本的影响大小；容错空间指 AI 出错后能否被人及时发现和修正。

综合来看，会议纪要结构化和线索打分通常是优先级最高的两个场景：会议录音转写后做摘要，出错后销售能在现场立刻修正；线索打分本身就是给销售做参考，错误代价可控。而全自动邮件发送这类场景，因为直接影响客户关系，通常放在后面，即使要做也会采用“人工审核后发送”的兜底机制。这个排序思路，在后续的实战案例中会反复体现。

3. 整体工程架构设计

3.1 一个可落地的四层架构

在动手写代码之前，先明确整体架构。GTM 场景下的 AI 系统，我个人习惯拆成四层：数据层、模型层、应用层、评估与治理层。

┌──────────────────────────────────────────┐ │ 评估与治理层 │ │ 离线评测、线上指标、日志追踪、权限审计 │ ├──────────────────────────────────────────┤ │ 应用层 │ │ 线索打分 / 邮件生成 / 会议纪要 / Agent │ ├──────────────────────────────────────────┤ │ 模型层 │ │ 云端 LLM API / 开源模型 / 向量检索 / RAG │ ├──────────────────────────────────────────┤ │ 数据层 │ │ CRM / 行为事件 / 邮件 / 会议 / 内容库 │ └──────────────────────────────────────────┘

数据层解决“数据从哪来、怎么统一建模”的问题；模型层屏蔽具体模型差异，统一提供 Prompt 调用、检索增强、模型路由能力；应用层面向具体业务场景，把模型能力封装成销售、市场、客户成功团队能直接使用的功能；评估与治理层贯穿始终，负责效果度量、成本控制、安全合规和问题追溯。很多 AI 项目失败，不是因为模型不够强，而是因为数据层没有打通、评估层没有建立，导致模型表现不稳定又无处排查。

3.2 数据层：统一对象模型与事件流

GTM 数据建模的核心是围绕几个业务对象展开：Account（客户公司）、Contact（联系人）、Opportunity（商机）、Activity（互动记录）。一条线索进入系统后，会不断产生行为事件，比如访问官网、打开邮件、参加会议、试用产品。AI Engineer 需要把这些散落的数据汇聚到统一的数据仓库或数据湖中，并且给每个对象建立完整的时间线。

在具体实现上，常见做法是用消息队列接收 CRM 和各类 SaaS 工具的事件，经过清洗和标准化后写入数据仓库。例如 CRM 中的字段、邮件系统中的发送记录、会议工具中的录音转写，最终都映射到统一的事件模型。这个环节不需要多么高深的模型技术，但决定了下游所有 AI 能力的上限。如果数据质量差、字段缺失、ID 对不齐，无论 Prompt 写得多好，最终效果都会大打折扣。

3.3 模型层：API 模型与开源模型怎么选

模型选型没有标准答案，主要看数据敏感性、成本预算和团队能力。常见的选择是云端大模型 API，适合快速迭代、对数据脱敏要求不高的场景；如果客户数据高度敏感，或者希望降低长线调用成本，可以部署本地开源模型。以我接触过的团队为例，很多公司会把任务分级：核心的意图理解、信息抽取用较强的云端模型；简单的分类、摘要用轻量模型甚至规则；需要低延迟和隐私保护的任务用本地部署模型。

还有一个容易被忽略的点是向量检索。GTM 场景中大量需求是“基于已有内容生成新内容”，比如基于客户官网生成个性化邮件、基于知识库回答客户问题。这类需求几乎都要用到 RAG，因此向量数据库（如 pgvector、Milvus 等）也是模型层的重要组成部分。向量库不只存文档，还存客户资料、历史邮件、产品文档，方便模型在生成时“带着证据回答”。

4. 实战一：客户线索智能打分与优先级排序

4.1 业务目标与打分逻辑

第一个实战案例是线索打分。业务目标是：当一条新线索进入系统时，自动给出一个 0 到 100 的分数，并附带简短理由，帮助销售决定优先跟进谁。传统做法是规则打分，比如根据公司规模、行业、职位设定分值；问题在于规则难以处理非结构化信息，比如客户官网上的产品描述、招聘信息，这些文本恰恰能反映客户当前的需求和紧迫程度。

我的设计思路是“LLM 解析 + 规则打分 + 分数融合”。LLM 负责从文本中抽取结构化信号，比如客户主营方向、公司规模、关键需求关键词、技术栈等；规则打分负责处理结构化字段，比如客户是否来自目标行业、联系人职位是否符合 ICP；最后按权重融合，并对低置信度的结果打上“需要人工确认”的标记。这样既发挥了 LLM 的理解能力，又保留了规则的可解释性。

4.2 用 LLM 做线索画像解析

下面给出一个核心片段，假设使用 OpenAI 兼容接口，把线索的公开资料和官网信息作为输入，输出结构化的线索画像。生产环境中，这一步通常由一个定时任务触发，新线索进入 CRM 后自动调用。

# 文件路径：services/lead_profile.py import json from openai import OpenAI client = OpenAI() PROFILE_PROMPT = """ 你是一名资深 B2B 销售分析师。请根据下面的线索信息，提取客户画像字段。 要求： 1. 只输出 JSON，不要输出任何解释。 2. 字段必须包含： - industry: 客户所属行业 - company_size: 估计的公司规模 - tech_stack: 客户使用的技术栈关键词列表 - pain_points: 客户可能存在的痛点列表 - buying_signals: 客户表现出的购买信号列表 3. 如果某个字段无法判断，填 null。 线索信息： {lead_text} """ def extract_lead_profile(lead_text: str) -> dict: resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你只输出合法 JSON。"}, {"role": "user", "content": PROFILE_PROMPT.format(lead_text=lead_text)} ], temperature=0.2, response_format={"type": "json_object"}, ) content = resp.choices[0].message.content # 有些模型或接口不支持 response_format，这里做一次安全解析兜底 try: profile = json.loads(content) except json.JSONDecodeError: start = content.find("{") end = content.rfind("}") + 1 profile = json.loads(content[start:end]) return profile

这段代码的关键点有三个。第一，Prompt 明确指定了输出字段和格式，这是保证后续程序能稳定消费输出的基础。第二，temperature调低到 0.2，让输出更确定，因为线索画像抽取不是创意任务。第三，代码做了 JSON 解析兜底，防止模型输出多余文字导致解析失败。在实际项目中，我会建议把这种“抽取类 Prompt”统一维护在一个目录中，并且为每种输出格式写一个 Pydantic 或 dataclass 定义，方便后续校验和版本管理。

4.3 规则分数与模型分数融合

拿到 LLM 抽取的画像后，还需要和规则分数融合，才能得到最终可用于排序的分数。下面的代码实现一个简单的融合函数，核心思路是：规则分基于结构化字段计算，模型分基于画像完整度和购买信号计算，再加一个置信度判断。

# 文件路径：services/lead_scoring.py def rule_score(lead: dict) -> float: """基于结构化字段的规则打分，范围 0~50 分。""" score = 0 if lead.get("industry") in ("互联网", "企业服务", "人工智能"): score += 20 if lead.get("company_size", 0) > 200: score += 15 if lead.get("contact_title", "").lower() in ("cto", "vp", "director", "head"): score += 15 return min(score, 50) def model_signal_score(profile: dict) -> float: """基于 LLM 画像的模型打分，范围 0~50 分。""" score = 0 if profile.get("buying_signals"): score += min(len(profile["buying_signals"]) * 10, 30) if profile.get("pain_points"): score += min(len(profile["pain_points"]) * 5, 20) return min(score, 50) def final_score(lead: dict, profile: dict) -> dict: r = rule_score(lead) m = model_signal_score(profile) total = round(0.5 * r + 0.5 * m, 1) has_signal = bool(profile.get("buying_signals")) or bool(profile.get("pain_points")) profile_complete = all(profile.get(k) for k in ("industry", "company_size")) return { "total_score": total, "rule_score": r, "model_score": m, "needs_review": not (has_signal and profile_complete), "reasons": { "rule": "目标行业/规模/职位匹配", "model": profile.get("pain_points", []), }, }

这段代码不是完整的生产实现，但表达了核心思想：用规则分数兜底结构化信息，用模型分数捕捉非结构化信息中的购买信号，最后通过needs_review标记低置信度样本，让销售人工判断。线上运行时，建议把所有打分结果和中间特征都记录到日志中，方便后续复盘为什么某条线索被打低分或高分，这也是可解释性要求的一部分。

5. 实战二：个性化销售邮件生成与人工审核

5.1 为什么不能直接“生成即发送”

第二个实战案例是个性化销售邮件生成。很多团队一开始都会兴奋地把 LLM 接入邮件系统，希望全自动生成并发信，结果往往很快踩坑。原因是销售邮件直接代表公司形象，一旦出现事实错误、语气不当、过度承诺，损失的不仅是这一封邮件的转化机会，还有客户的信任。所以在本案例中，我采用“生成草稿 + 人工审核 + 确认发送”的机制，这个机制不是效率的妥协，而是负责任 AI 落地的必要手段。

真实业务中，邮件的个性化来源包括客户官网信息、客户近期动态、历史往来记录、产品功能匹配度。为了不让模型凭空发挥，需要把这些信息通过 RAG 检索出来，作为 Prompt 中的“事实上下文”。模型只负责基于给定事实起草文案，不能自行编造客户信息。

5.2 基于知识库的 RAG 邮件生成

下面用简化代码演示 RAG 邮件生成的思路。完整项目需要向量库，这里用列表模拟检索结果，但 Prompt 结构和流程是真实可用的。

# 文件路径：services/email_generator.py from openai import OpenAI client = OpenAI() EMAIL_PROMPT = """ 你是一名资深的 B2B 销售顾问，负责撰写首封陌生拜访邮件。 请严格遵循以下约束： 1. 只能使用【事实上下文】中提供的信息，禁止编造客户公司、产品、数据。 2. 如果事实上下文中没有的信息，直接不写，不要猜测。 3. 语气专业、简洁、自然，不要使用夸张营销词汇。 4. 邮件长度控制在 150 词以内。 5. 输出格式：主题行 + 正文。 【事实上下文】 {context} 【客户画像】 {profile} 【本次推广的产品能力】 {product_points} """ def retrieve_context(company_id: str, top_k: int = 3) -> str: # 生产环境这里会调用向量库：根据 company_id 检索相关文档片段 # 例如客户官网文本、近期新闻、历史邮件等 mock_docs = [ "该公司官网显示正在搭建数据中台，团队约 300 人，技术栈以 Java 和 Python 为主。", "该公司近期发布了数据治理方向的新职位，说明数据团队在扩张。", "历史记录显示该客户曾参加我们线上研讨会，但未注册产品试用。", ] return "\n".join(mock_docs[:top_k]) def generate_email(company_id: str, profile: dict, product_points: list[str]) -> str: context = retrieve_context(company_id) prompt = EMAIL_PROMPT.format( context=context, profile=str(profile), product_points="\n".join(f"- {p}" for p in product_points), ) resp = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], temperature=0.7, ) return resp.choices[0].message.content

这个示例中最重要的是 Prompt 里的约束部分：只允许使用事实上下文、禁止编造、没有信息就不写。RAG 的核心价值不是让模型“记得更多”，而是让模型在生成时有一个可追溯的证据来源。每封邮件的生成记录都应该包含“引用了哪些上下文片段”，这样人工审核时能快速判断事实是否准确。

5.3 人工审核与回退机制

邮件生成之后，需要进入一个审核列表，而不是直接发送。审核界面可以很简单：左侧显示 AI 生成的邮件草稿，右侧显示模型引用的上下文片段，审核人点击“通过并发送”或“编辑后再发”。这个流程在工程上需要注意权限设计，建议记录每个草稿的生成人、生成时间、模型版本、Prompt 版本、引用上下文 ID 和审核人操作，方便出问题时回溯。

另一个容易被忽略的点是发送频率和退订合规。即使有人工审核，也应当在邮件系统中接入退订链接、发送频率限制和域名信誉监控。实际操作中，这类项目的“AI 工程”部分可能只占 40%，剩下 60% 是流程设计、权限控制、审计日志和合规校验。把这些做好，AI 才能安全地在客户沟通场景中发挥作用。

6. 实战三：客户会议纪要结构化与知识沉淀

6.1 从通话录音到 CRM 字段

第三个实战案例是会议纪要结构化。销售和客户成功团队每周都要开大量客户会议，会议里包含关键信息：客户需求、预算、决策链、竞品、风险、下一步行动项。过去这些内容由销售手动整理进 CRM，不仅耗时，而且每个人记录格式不一，导致后续分析困难。AI 的目标是把“录音转写文本”自动加工成“结构化会议纪要和 CRM 字段”。

这个数据链路是：会议录音 → 语音转写（ASR）→ 文本分段 → LLM 摘要与字段抽取 → 人工确认 → 回写 CRM。其中语音转写通常由会议工具自带能力完成，AI Engineer 的重点在后面的文本处理和系统集成环节。这里同样遵循“AI 先起草、人后确认”的原则，避免错误信息直接污染 CRM 数据。

6.2 摘要与字段抽取

看一下核心的摘要和字段抽取函数。输出结构建议分为三块：会议摘要、结构化字段、风险与行动项。

# 文件路径：services/meeting_notes.py import json from openai import OpenAI client = OpenAI() MEETING_PROMPT = """ 你是一名客户成功分析师。请根据会议转写文本，输出结构化会议纪要。 输出 JSON 格式，必须包含： - summary: 一段 80 字以内的会议摘要 - pain_points: 客户明确表达的痛点列表 - product_interest: 客户对哪些功能/产品表现出兴趣 - competitors: 客户提到的竞品列表 - decision_chain: 提到的决策相关人物和角色 - next_steps: 明确的下一步行动项列表，每一项包含 owner 和 deadline - risk_level: 整体风险等级，取值 high / medium / low 约束：所有内容必须基于转写文本，禁止推测。 转写文本： {transcript} """ def process_meeting(transcript: str) -> dict: prompt = MEETING_PROMPT.format(transcript=transcript[:12000]) # 截断超长文本 resp = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], temperature=0.1, response_format={"type": "json_object"}, ) content = resp.choices[0].message.content try: result = json.loads(content) except json.JSONDecodeError: result = {"summary": content, "error": "JSON parse failed"} return result

这个函数的核心是明确的字段定义。为了下游 CRM 系统能直接消费，字段名应该在设计阶段就与 CRM 的字段映射对齐，比如next_steps对应 CRM 中的任务对象，risk_level对应商机风险字段。同时要注意转写文本长度限制，超过模型上下文长度时要做分段处理，先分段抽取、再汇总合并。

6.3 错误兜底与人工修正

由于会议信息直接进入 CRM，错误的代价比邮件生成场景更高，因此必须设计人工确认环节。一个简单的实现是：AI 生成结果先落到一个“待确认”表，销售在浏览器插件或 CRM 侧边栏中审核，确认后按钮回写 CRM。回写操作应该由后端服务完成，而不是前端直接写 CRM，这样可以在服务端做权限校验、字段校验和操作审计。

另外，我建议对这类结构化抽取任务定期做质量抽检。比如每周随机抽取 50 条会议记录，让运营人员标注“AI 输出的字段是否与原文一致”，统计字段级准确率。这个准确率数据反过来可以驱动 Prompt 优化和异常处理策略调整。很多团队把精力放在调 Prompt 上，但没有建立持续的质量反馈闭环，这是非常可惜的。

7. 没有评估的 AI GTM 项目都是摆设

7.1 离线评估：先让机器给机器打分

AI 类项目最怕“感觉好用但说不清哪里好”。在 GTM 场景中，我强烈建议每个 AI 能力上线前都建立离线评估集。评估集是一批带人工标注的样本，例如 200 条线索画像、100 封参考邮件、50 份标准会议纪要。每次修改 Prompt、切换模型，都先在评估集上跑一遍，用指标判断改动是变好还是变差。

以邮件生成为例，可以先用规则和 LLM-as-a-Judge 做初筛。规则检查包括：长度是否超限、是否包含禁用词、是否包含编造的客户数据；LLM-as-a-Judge 则让一个更强的模型对生成的邮件从相关性、语气、事实一致性三个维度打分。

# 文件路径：evaluation/judge_email.py from openai import OpenAI client = OpenAI() JUDGE_PROMPT = """ 你是一名严格的邮件质量评审员。请对下面的销售邮件打分，每项 1~5 分。 评分项： - relevance: 邮件内容与客户画像的相关程度 - tone: 语气是否专业、自然 - factual_consistency: 是否基于提供的上下文，是否存在编造 只输出 JSON：{"relevance": 5, "tone": 4, "factual_consistency": 3, "comment": "..."} 【客户画像】 {profile} 【事实上下文】 {context} 【邮件内容】 {email} """ def judge_email(email: str, profile: str, context: str) -> dict: resp = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": JUDGE_PROMPT.format( email=email, profile=profile, context=context )}], temperature=0, ) return resp.choices[0].message.content

这种“用模型评估模型”的方式并不完美，但作为初筛手段效率很高。需要注意一点：Judge 模型本身也可能有偏好偏差，所以离线评估结果不能完全替代人工抽检，两者要结合使用。同时，评估集需要持续扩充，把线上发现的 badcase 不断补充进去，形成回归测试集。

7.2 在线评估：从技术指标到业务指标

离线指标只能说明模型本身的质量，业务价值最终还是要看在线指标。我把在线评估分成两层：第一层是行为指标，比如 AI 生成的邮件发送后，打开率和回复率是否高于人工写的基线；AI 标注的会议纪要被销售的采纳率是多少；线索打分结果被销售接受的比例有多高。第二层是商业指标，比如线索到商机转化率、销售人均产出、客户续费率。商业指标受很多因素影响，短期内难以归因于某个 AI 功能，所以通常采用 A/B 测试的方式评估，比如一组销售使用 AI 辅助工具，另一组维持原有流程，比较一段时间内的转化数据。

在线评估最容易被忽略的是“人在回路”的数据采集。销售审核邮件时是否做了修改、改了什么、为什么改，这些数据如果能记录，就是最好的训练信号和分析素材。建议在系统设计时就考虑“每一次人工修正都是一条标注数据”这一原则，把审核页面变成数据采集页面。

7.3 幻觉、合规与安全边界

GTM 场景中，AI 幻觉的代价比一般场景更高。如果模型在销售邮件里编造了一个产品功能，销售没发现就发出去了，后续客户要求兑现，就会变成一次真实的信誉事故。因此幻觉治理是 GTM AI 项目的必修课。

治理手段可以分为三层：第一层是 Prompt 层，在指令中明确禁止编造、明确限定只能使用给定上下文；第二层是事实校验层，对模型输出中提到的公司名、产品名、数据、日期做实体校验，与知识库比对，不一致就拦截；第三层是流程层，涉及对外发送或写入 CRM 的内容必须有人工确认。这三层叠加，可以把幻觉带来的风险降到可控范围。

安全与合规方面还需要注意数据权限。GTM 系统涉及大量客户敏感信息，AI 服务在访问这些数据时必须遵循最小权限原则，不能因为一个模型服务能读到所有 CRM 记录就真的让它这么做。建议按场景划分数据访问范围，控制业务用户和 AI 服务的数据可见性，同时落实操作审计，确保谁在什么时间经 AI 系统访问或生成了什么数据都有记录。

8. 常见问题与排查思路

8.1 高频问题清单

这里整理一份 GTM AI 项目中最常见的问题清单，按出现频率排序。

项目中遇到问题，不要第一时间怀疑模型能力不够，先按“数据 → Prompt → 模型 → 流程”的顺序排查。数据是否干净、上下文是否注入、Prompt 是否足够明确、模型选型是否匹配、流程是否有兜底，大部分问题都出在前两层。

8.2 一个排查实例：邮件生成频繁出现空字段

举一个真实高频问题：邮件生成流程中，业务团队反馈“生成结果偶尔会缺失主体内容，直接返回空字符串或只有主题行”。排查时先从日志看模型请求参数，发现上下文长度超长时触发了截断，而截断后的文本夹杂在 Prompt 中间，导致模型理解混乱，输出为空。修复方式有两个层面：一是在 Prompt 模板中对上下文长度显式限制，并在截断处加“以下上下文不完整，请基于现有信息回答”；二是在代码中增加重试机制，对空输出自动重试一次，并降低 temperature。修复后还把这个 case 加入了回归测试集，防止后续改动再次引入同类问题。

这个例子说明，AI 应用的很多问题并不神秘，关键是有一套可观测的日志体系和规范的排查流程。模型调用日志里应当记录完整的请求参数、响应内容、Token 消耗、耗时和错误码，这是所有排错工作的基础。

9. 最佳实践与工程建议

9.1 数据安全与最小权限

GTM AI 系统处理的都是企业商业数据，安全设计必须前置。实践经验是：AI 服务访问 CRM 数据时，按“场景 + 角色 + 数据范围”三个维度控制权限。场景决定能调用哪些能力，角色决定谁能使用，数据范围决定能看哪些客户的数据。例如普通销售只能对自己负责的客户执行邮件生成，销售管理者可以批量查看本团队的线索打分报告。所有 AI 生成和人工改写的操作都要记录审计日志，尤其是写回 CRM、对外发送这类高风险动作。

9.2 成本控制：从 Token 到 Credits

大模型调用成本是 GTM AI 项目绕不开的问题。实践中通常从四个方面控制：第一，任务分级，简单任务用便宜的小模型，复杂任务才用大模型；第二，减少重复调用，对同样的输入结果做缓存，比如同一客户一周内的画像抽取结果可以直接复用；第三，控制上下文长度，只注入必要字段，避免把整个 CRM 记录都塞进 Prompt；第四，设置预算告警，根据每日 Token 消耗和费用设置阈值。很多 AI 平台用 Credits 表示额度消耗，工程上建议在请求层做速率限制和用量统计，避免某个异常任务耗尽整个团队当天的预算。

9.3 人机协同与变更流程

GTM AI 项目的核心原则是“AI 提效、人工兜底”。对外发送的内容和写入核心系统的数据必须有人工确认环节，这既是风险控制，也是数据质量保障。另一个容易被忽略的点是变更管理：Prompt 修改、模型切换、评估集更新都应走版本控制，线上效果出现波动时能快速回滚到上一个稳定版本。我的习惯是使用配置中心或版本库管理 Prompt 模板，每次修改都关联测试评估结果，做到可追溯、可回滚。

9.4 可观测性与评测平台化

最后一条建议是把评估和观测做成平台能力，而不是单一脚本。随着 AI 能力在 GTM 中铺开，你会遇到一个现实问题：评估没有统一工具，每个场景各搞一套，无法横向比较。更好的做法是搭建一个简单的评测平台，支持上传数据集、运行评测、查看指标、对比模型和 Prompt 版本。这个平台不需要多复杂，一个后台页面加几张表就够了，但它能把团队从“人工试 Prompt”的低效循环中解放出来，让每次优化都有数据支撑。

10. 总结与学习路线

10.1 读完应该掌握什么

回到最初的问题：AI in GTM at Notion 这类岗位和项目，技术本质到底是什么？通过本文的拆解，你应该已经看到一条清晰的路径：理解 GTM 业务链路，找到 AI 的高价值介入点；搭建“数据层—模型层—应用层—评估治理层”的分层架构；用线索打分、邮件生成、会议纪要三个典型场景作为起步；把评估体系和人工兜底机制作为项目成功的生命线。这些内容组合在一起，就是 AI Engineer 在 GTM 场景下的核心能力框架。

10.2 下一步学习路径

如果你想把这条路线走深，建议按下面的顺序学习。先掌握 RAG 技术栈，理解向量检索、上下文注入和引用溯源，这是 GTM 文本类任务的基础；再学习评估方法论，包括评估集构建、LLM-as-a-Judge、线上 A/B 测试，这是区分“Demo 工程师”和“AI 工程师”的关键；然后学习 Agent 相关工程实践，覆盖工具调用、状态管理和容错设计，因为更复杂的 GTM 场景最终会走向 Agent 化；最后深入业务，理解销售流程、CRM 数据模型和商业化指标，技术只有和业务指标绑定，才能真正创造价值。

10.3 给想动手的工程师一个起点

建议你从最轻量的场景开始：选一个你熟悉或感兴趣的业务流程，比如把客户访谈录音整理成结构化纪要，或者把一批线索信息做自动画像分析，用本文的代码骨架快速搭一个最小系统。不要一开始就追求大而全的 Agent 平台，先把“一条业务链路、一个模型能力、一套评估机制、一个人工兜底流程”跑通，再逐步扩大范围。AI in GTM 的竞争点从来不只在模型本身，而在于数据质量、工程稳定性和对业务流程的理解深度。把这些基础打牢，你就能在这类岗位上真正站住脚。