这两年技术社区里关于“AI in GTM at Notion”这类岗位方向的讨论越来越多。很多人第一反应是疑惑Notion 不是做笔记、文档和知识库的产品吗为什么会专门招 AI Engineer 去支持 GTM其实这背后是 SaaS 行业一个非常明显的变化——GTMGo-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 应用场景GTM 环节AI 能力典型输出核心工程难点线索获取受众画像分析、内容自动生成目标行业列表、广告文案、落地页草稿内容质量与品牌一致性线索打分线索信息解析、意向预测线索优先级分数、跟进建议打分标准可解释、可校准销售触达个性化邮件生成、多语言改写定制化首封邮件、跟进邮件语气控制、事实准确性跟进转化会议纪要、客户需求提炼、竞品分析结构化纪要与下一步行动项信息抽取准确性、CRM 回写客户成功健康度预测、知识库问答、工单分类风险预警、自助回答、工单标签实时性、权限隔离续费增购交叉销售/向上销售机会识别扩展销售推荐列表与业务规则的结合从表格可以看出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( modelgpt-4o-mini, messages[ {role: system, content: 你只输出合法 JSON。}, {role: user, content: PROFILE_PROMPT.format(lead_textlead_text)} ], temperature0.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( contextcontext, profilestr(profile), product_points\n.join(f- {p} for p in product_points), ) resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], temperature0.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(transcripttranscript[:12000]) # 截断超长文本 resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], temperature0.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( modelgpt-4o, messages[{role: user, content: JUDGE_PROMPT.format( emailemail, profileprofile, contextcontext )}], temperature0, ) 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 格式要求不严格或模型版本能力不足明确输出格式、增加 JSON 校验兜底、使用支持 JSON 输出的模型邮件生成出现编造内容事实上下文未注入或 Prompt 缺少禁止编造约束强制 RAG 检索、增加事实校验、设置人工审核生成结果不稳定同样的输入两次输出不同temperature 设置过高、Prompt 描述模糊降低 temperature明确判定标准增加示例few-shot调用成本快速上涨每次请求都塞入超长上下文、没有缓存控制上下文长度、结果缓存、按任务选择模型规格线下效果不错线上转化没提升业务环节存在瓶颈或销售没有真正使用工具先分析流程瓶颈跟踪工具使用率和采纳率CRM 回写字段混乱AI 输出字段与 CRM 字段没有对齐统一字段映射在后端做转换和校验部分客户数据被模型读取权限模型缺失或数据脱敏不足最小权限、按租户隔离、敏感字段脱敏项目中遇到问题不要第一时间怀疑模型能力不够先按“数据 → 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 的竞争点从来不只在模型本身而在于数据质量、工程稳定性和对业务流程的理解深度。把这些基础打牢你就能在这类岗位上真正站住脚。