这次我们不看模型部署来看一个经常被低估的 AI 落地场景GTMGo-to-Market市场进入。标题来自 Notion 团队的一次分享方向在 Notion 的 GTM 流程中AI 到底怎么用AI Engineer 在里面做什么如果把这个问题拆开其实就是在讨论如何把大模型能力嵌入销售、市场、客户成功这些业务环节而不是单纯做一个聊天机器人。对做 AI 工程的人来说这个方向比想象中更值得关注。原因很简单GTM 环节每天产生大量文本、大量重复劳动、大量需要人工判断的内容这些恰恰是大模型最容易提效的地方。而且这类需求不依赖超大的显存或复杂的推理集群很多任务用 API 调用就能跑通少量任务甚至可以批量处理。更关键的是它有明确的业务收益不会因为“技术很炫但没有业务价值”而被砍掉。这篇文章会按工程落地的思路展开先梳理 GTM 里 AI 的典型应用场景再看 AI Engineer 在这些项目里的职责边界然后给出一个通用的架构设计最后用代码示例演示线索评分、会议纪要、批量任务和接口调用的实现方式。内容不绑定某个具体内部系统也不涉及 Notion 的私有数据只讲可复现的工程思路。如果你正在负责“AI 企业业务落地”的项目或者想把 LLM 接进销售和运营流程这篇文章可以直接收藏。下面进入正题。1. 核心能力速览先给一张速览表。它对应的是“GTM AI”这一类项目而不是某一个单一开源项目所以表中更多是能力域和技术选型建议。能力项说明项目方向在 GTM市场进入、销售、客户成功流程中应用大模型能力典型功能线索评分与分级、会议纪要、邮件自动起草、客户问题知识库、内容生成、预测分析技术栈Python、LLM API、向量数据库、工作流编排、低代码/内部平台硬件门槛低优先使用 API 服务不强制本地 GPU是否需要本地部署可选。数据敏感时可私有化部署开源模型支持平台Web 服务、内部工具、Slack/飞书/企微机器人、CRM 系统插件接口能力可封装为 REST API 供内部业务系统调用批量任务支持。需要队列、并发控制和失败重试关键难点数据质量、提示词效果、输出准确率、权限与合规适合团队有业务数据、有 AI 工程能力、想提升销售/运营效率的团队从工程角度说这个方向的入门门槛并不高。比如线索评分任务本质上就是把“公司信息 行为信息 历史转化结果”拼成 Prompt让模型输出一个评分和理由。但要把这个流程稳定跑在业务线上难点在数据清洗、Prompt 迭代、接口容错和人工审核机制。这就是 AI Engineer 的主要工作。2. GTM 中 AI 的典型落地场景很多团队对“GTM 里用 AI”的第一反应是做客服机器人但实际能落地的高价值场景比这多得多。我按业务链路拆成六个方向。2.1 线索评分与客户分级销售每天要处理大量线索。传统做法是人工看 CRM 记录、查公司信息、判断是否值得跟进。AI 可以自动汇总线索信息结合企业官网、融资新闻、招聘需求、目标客户画像生成一个线索评分并给出跟进理由和建议话术。这里的价值不是“用 AI 代替销售判断”而是把前期的信息收集和初步筛选自动化让销售把时间留给真正高意向的客户。2.2 会议纪要与行动项提取销售和客户成功团队每天都有大量线上会议。会议录音转写之后还需要人工整理纪要和下一步计划。AI 可以做三件事将语音自动转成高质量文字稿提取关键讨论点、客户痛点、竞品信息自动生成TODO行动项并关联到 CRM 任务。这个场景对 Prompt 工程的要求比较高因为“准确提取行动项”比“生成一段摘要”更难评估。2.3 邮件与内容自动起草售前方案、客户跟进邮件、营销文章、社交媒体内容都属于 GTM 内容。大模型可以基于客户资料库和已有内容模板自动生成初稿。重点在于生成结果必须有人工复核尤其是涉及报价、合同条款、合规信息时不能直接使用模型输出。2.4 客户支持与知识库问答把产品文档、历史工单、常见问题录入向量数据库构建一个内部知识库问答系统。客户支持团队可以直接输入用户问题系统返回知识库中相关的答案和文档段落。这里的难点是权限控制不同客户、不同角色能查到的内容可能完全不同。2.5 销售预测与风险预警基于 CRM 历史数据用 LLM 辅助分析销售漏斗状态。它可以自动生成周报哪些商机可能延期、哪些客户有流失风险、哪些渠道 ROI 下降。模型本身不直接做预测而是把数据指标和文本信息汇总成可读的洞察辅助业务负责人决策。2.6 内外部数据挖掘与竞争分析GTM 团队经常需要跟踪竞品动向、行业趋势、目标客户招聘信息。AI 可以定时抓取公开信息用 LLM 生成变化摘要再写入内部数据表。这样可以减少大量人工搜索和复制的重复劳动但要注意数据来源的合法性和版权边界。3. AI Engineer 在 GTM 项目中的职责既然标题里有“AI Engineer”这里需要单独说明这个角色的工程边界。很多团队以为招一个 AI Engineer 就是让他调大模型 API实际远不止。3.1 模型选型与调用层设计首先需要选择模型是用 GPT、Claude、Gemini 这类商业 API还是用开源模型私有化部署决策因素包括数据敏感度、成本预算、响应速度、语言质量、合规要求。选型完成后要设计统一的调用层避免业务代码直接依赖某一家模型 SDK。推荐封装一个llm_client统一管理超时、重试、token 数统计和日志。3.2 数据管道与特征工程LLM 不能直接吃原始数据库里的零散记录。AI Engineer 需要写数据管道把 CRM、行为日志、客服工单、邮件记录等数据清洗成 LLM 友好的结构。比如合并同一客户的多个联系人记录去除重复和过期数据保留最近 N 次互动记录按业务规则生成摘要字段。这一步做得好不好直接影响模型输出质量。3.3 提示词工程与用例评测“Prompt 调不好”几乎是大模型项目最常见的失败原因。AI Engineer 需要针对每个业务场景建立评测集比如准备 30 个真实线索样本让模型输出评分再和人工评分做对比不断迭代 Prompt。要注意的是评测不能只看一个例子感觉“还行”要用至少几十个样本做批量测试并记录每次修改前后的通过率。3.4 服务化与监控模型推理要封装成内部 API供 CRM、报表系统、机器人调用。同时要记录每次请求的延迟、Token 消耗、错误率、输出是否被人工修改。这样后续才能回答“这个 AI 功能到底省钱没有”。4. 从 0 到 1 搭建 GTM AI 工具的架构不依赖特定公司这里给一套通用架构。整体分为四层层级组件作用数据层CRM 数据、行为日志、文档库提供原始数据清洗层ETL 脚本、向量库、标签体系把数据变成 LLM 可用的上下文模型层LLM API、向量模型、转写模型负责推理和内容理解应用层内部 Web 工具、Slack/企微机器人、CRM 插件把 AI 能力提供给业务人员架构的核心约束是不要让业务系统直接访问原始 API也不要让模型直接读取原始数据库。中间必须有一层业务逻辑负责做 RAG 检索、提示词组装、权限过滤、结果审核。下面是一个典型的信息流用文字描述替代图用户在 CRM 里点击某个线索后端服务拿到线索 ID数据管道从数据库读取关联的公司信息、联系人、互动记录清洗后的数据被拼装成 PromptLLM 返回评分和理由结果写入数据库并显示在 CRM 页面。这个流程看起来简单但每一步都有大量细节字段映射、异常处理、多轮重试、日志记录、人工反馈回写。5. 典型功能实现示例线索评分 API这一节用代码演示如何实现一个线索评分服务。示例使用通用 LLM API需要替换成你自己的api_key、接口地址和模型名。5.1 环境准备建议环境Python 3.10一个可用的 LLM API 服务OpenAI、Claude、国内大模型或本地部署的 vLLMrequests 或 openai SDK如果本地跑开源模型需要按模型需求准备 GPU 显存具体显存以模型官方要求为准安装依赖pip install requests python-dotenvpython-dotenv用来读取环境变量避免把密钥硬编码在代码里。5.2 统一 LLM 客户端先封装一个最简的 LLM 客户端统一管理超时和重试。import os import time import requests from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(LLM_API_KEY) API_URL os.getenv(LLM_API_URL, https://api.openai.com/v1/chat/completions) MODEL_NAME os.getenv(LLM_MODEL, gpt-4o-mini) def chat(messages, temperature0.2, max_retries3): 通用 LLM 调用函数。 实际项目需要按供应商的接口格式调整。 headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: MODEL_NAME, messages: messages, temperature: temperature } for attempt in range(max_retries): try: resp requests.post(API_URL, headersheaders, jsonpayload, timeout60) resp.raise_for_status() data resp.json() return data[choices][0][message][content] except Exception as e: print(f[attempt {attempt 1}] error: {e}) time.sleep(2 * (attempt 1)) raise RuntimeError(LLM API call failed after retries)时间有限时这个客户端可以直接用于后续功能测试。生产环境建议使用官方 SDK并接入更完善的重试退避策略。5.3 线索数据清洗函数LLM 输入不能是原始数据库记录。假设从 CRM 拿到的是这样的字段company_name、industry、employee_count、recent_events、interactions。先把它清洗成一段结构化文本。def format_lead_context(lead: dict) - str: 将线索数据拼成结构化文本供后续 Prompt 使用 interactions \n.join( [f- {item[date]}: {item[summary]} for item in lead.get(interactions, [])] ) return f 公司名称{lead.get(company_name, Unknown)} 所属行业{lead.get(industry, Unknown)} 公司规模{lead.get(employee_count, Unknown)} 近期动态{lead.get(recent_events, 暂无)} 历史互动 {interactions if interactions else 暂无记录} .strip()这里的关键是把复杂数据提前整理成模型更容易理解的文本而不是把所有 JSON 都扔给模型。5.4 线索评分 Prompt接下来定义评分 Prompt。要求模型输出 JSON 格式方便下游程序解析。SYSTEM_PROMPT 你是一名资深的销售运营专家。请根据给定的客户信息输出该线索的跟进优先级评分。 评分标准 - 0-100 分分数越高代表越值得优先跟进。 - 输出 JSON包含三个字段 - score: 整数评分 - reason: 评分理由不超过 100 字 - suggestion: 建议的下一步行动不超过 50 字 注意只输出 JSON不要输出多余文字。 def score_lead(lead: dict): context format_lead_context(lead) messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f请评估以下线索\n{context}} ] raw_output chat(messages) return raw_output示例输入结构{ company_name: 示例科技有限公司, industry: 企业服务, employee_count: 150-500人, recent_events: 刚完成 B 轮融资正在搭建销售团队, interactions: [ { date: 2025-06-10, summary: 客户咨询了企业版落地方案重点关注数据安全。 }, { date: 2025-06-12, summary: 客户需求文档已发送等待对方反馈。 } ] }运行函数后模型会输出类似{ score: 92, reason: 客户近期融资且明确咨询企业版方案意愿和预算都较明确, suggestion: 建议今天内联系客户安排一次方案演示 }实际项目建议使用json.loads对输出做解析遇到解析失败时重试一次并加上fenced格式兼容处理。5.5 接口化把评分函数封装成 REST API 后销售系统就能直接调用。from flask import Flask, request, jsonify app Flask(__name__) app.route(/api/v1/score_lead, methods[POST]) def score_lead_endpoint(): data request.get_json() lead data.get(lead, {}) if not lead: return jsonify({error: lead is required}), 400 try: result_text score_lead(lead) # 实际项目需要更严谨的 JSON 解析 import json result json.loads(result_text) return jsonify(result) except Exception as e: return jsonify({error: str(e)}), 500 if __name__ __main__: app.run(host127.0.0.1, port8000, debugFalse)启动服务后用 curl 测试curl -X POST http://127.0.0.1:8000/api/v1/score_lead \ -H Content-Type: application/json \ -d { lead: { company_name: 示例科技有限公司, industry: 企业服务, employee_count: 150-500人, recent_events: 刚完成 B 轮融资正在搭建销售团队, interactions: [ {date: 2025-06-10, summary: 客户咨询了企业版落地方案}, {date: 2025-06-12, summary: 客户需求文档已发送} ] } }只要接口能返回结构化 JSON后面接 CRM、企业内部平台、Slack 机器人就比较容易。6. 会议纪要助手转写 摘要 行动项会议纪要是 GTM 场景里另一个高频刚需。实现思路分三步用 ASR 服务把录音转成文字用 LLM 对长文本做分段摘要用第二个 Prompt 提取行动项和负责人。6.1 转写与摘要的关键点转写服务可以使用各厂商的语音转写 API也可以本地部署 Whisper。如果本地部署需要注意显存要求Whisper 的 large 模型在 GPU 上运行显存占用较高CPU 也能跑但速度很慢具体以模型仓库说明为准。转写后文本可能超过模型上下文长度需要先分块。常见做法是def split_text(text: str, max_chars: int 3000) - list[str]: 按最大字符数切分较长的会议文本 return [text[i:i max_chars] for i in range(0, len(text), max_chars)]每块生成一个摘要再把所有摘要合并生成最终会议纪要。6.2 行动项提取示例假设已经有转写文本直接调用 LLM 提取行动项。def extract_action_items(transcript: str): prompt f 请从下面的会议转写内容中提取行动项。 输出 JSON 列表每个元素包含 - owner: 负责人姓名 - task: 具体任务 - due_date: 截止日期如果原文没有写 Unknown 转写内容 {transcript} messages [ {role: system, content: 你是会议纪要助手请只输出 JSON 数组。}, {role: user, content: prompt} ] return chat(messages, temperature0.1)建议在 Prompt 中强调“只输出 JSON”并配合代码容错如果返回结果被 Markdown 代码块包裹先去掉json和再解析。6.3 人工复核会议纪要直接发给客户是有风险的。行动项一旦提取错误可能漏掉关键承诺。当前更稳妥的做法是AI 先输出草稿由人工在内部系统里一键确认或修改再同步给客户。这一步不能省。7. 批量任务与并发控制GTM 场景经常需要一次性处理几百条线索、几百通电话记录、几百封邮件。这就要处理批量任务。7.1 简单顺序处理数据量小的场景直接顺序调用即可。但 QPS 太高时容易触发 API 限流所以需要加一个简单的速率控制。import time def batch_score_leads(leads: list[dict], sleep_seconds: float 0.5): results [] for idx, lead in enumerate(leads): result score_lead(lead) results.append(result) print(f[{idx 1}/{len(leads)}] {lead.get(company_name)} - {result}) time.sleep(sleep_seconds) return results批量测试时建议把中间结果实时落盘避免后期大任务失败后全部重跑。7.2 使用队列保存任务生产环境建议用 Redis 或数据库表做任务队列。表格结构可以是CREATE TABLE ai_batch_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_type VARCHAR(50) NOT NULL, input_data JSON NOT NULL, output_data JSON, status VARCHAR(20) DEFAULT pending, error_msg TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );流程相对简单插入任务记录状态为pending后台 Worker 扫描pending任务执行并更新结果失败时记录error_msg并重试。7.3 并发与重试策略并发数不要直接拉满。建议从 5 个并发开始观察 API 响应时间和限流情况。每次请求最好设置超时时间避免一个长时间阻塞的任务拖垮整个 Worker。from concurrent.futures import ThreadPoolExecutor, as_completed def batch_score_leads_concurrently(leads: list[dict], max_workers: int 5): results [None] * len(leads) with ThreadPoolExecutor(max_workersmax_workers) as executor: future_to_idx { executor.submit(score_lead, lead): idx for idx, lead in enumerate(leads) } for future in as_completed(future_to_idx): idx future_to_idx[future] try: results[idx] future.result() except Exception as e: results[idx] {error: str(e)} return results实际生产建议使用 Celery 或 Arq 这类任务框架而不是手写线程池。手写线程池适合小规模脚本不适合长期稳定运行。8. 性能、成本与质量评估8.1 性能观察在 GTM AI 工具里性能不只是“快不快”还包括接口响应时间小模型通常比大模型快但效果可能差批量任务吞吐量每秒能处理多少条线索排队等待时间任务多时是否积压错误率限流、超时、解析失败的比例。建议在日志里记录每一次请求的prompt_tokens、completion_tokens、latency_ms后续可以用这些数据分析成本和性能。8.2 成本控制LLM API 成本主要来自 Token。控制成本的方法有几类使用便宜的小模型处理简单任务减少 Prompt 中的冗余内容只保留必要字段对同类型任务做缓存比如同一客户短时间内的重复请求直接返回上次结果批量任务时设置单条超时避免无意义重试。8.3 质量评估AI 输出质量必须和业务指标挂钩。比如线索评分模型可以和销售最终是否成交做对比评分高的线索成交率是否真的更高会议纪要模型可以让客户成功经理每周抽样标注正确率。只有建立评估集和反馈回路Prompt 优化才有方向不然很容易变成凭感觉调参。9. 常见问题与排查方法这一节把 GTM AI 项目里容易踩的坑列成表格。问题现象可能原因排查方式解决方案接口响应特别慢模型上下文过长、网络延迟打印 token 数和请求耗时精简输入内容、切换小模型、增加超时时间输出 JSON 解析失败模型返回了多余文字或格式不对打印原始返回内容在 Prompt 中强调 JSON 格式或者用“修复 JSON”二次调用批量任务卡住API 限流、单条任务超时查看任务队列和日志降低并发数增加重试和超时机制评分结果和人工判断差距大线索数据不完整检查输入数据字段增加数据清洗逻辑补充更多上下文同一个客户重复生成结果不一致temperature 设置过高查看 temperature 参数把 temperature 降到 0.1 左右会议纪要遗漏关键行动项转写文本太长或内容分散检查分段摘要是否完整优化分段策略在 Prompt 中要求提炼所有行动项隐私问题敏感数据被发送给外部 API检查数据流向和脱敏逻辑必要时候选私有化部署或对敏感字段做脱敏无论遇到哪种问题第一步都是先看日志。日志里必须包含请求 ID、输入摘要、返回结果、耗时、错误信息。没有日志排查会很被动。10. 最佳实践与合规建议10.1 工程层面小场景先跑通再横向扩展。建议先做一个线索评分或会议纪要不要一开始就想做一个大而全的 AI 平台。所有模型调用都要有超时和重试避免单点故障。输入数据、Prompt 版本、模型输出都要留痕方便后期审计。批量任务必须支持断点续跑。最简单的方式是每跑完一条就写数据库而不是所有结果都留在内存里。10.2 数据和内容合规GTM 数据往往包含客户联系人、沟通记录、销售线索这些数据可能涉及个人信息和商业机密。使用时需要注意先确认数据来源是否合法是否经过授权如果使用外部 API要对敏感字段做脱敏或选择私有化部署模型生成的邮件、合同文案必须有人工复核不能直接发给客户涉及具体个人信息的处理要遵循当地数据保护法规必要时请法务审核。10.3 让业务人员参与评估AI Engineer 不能关起门来做模型调优。业务人员的反馈是质量评估的重要输入。建议搭建一个非常轻量的反馈入口在内部工具页面上加两个按钮“结果有用”和“结果不对”把结果和反馈一起存下来每周看一次分布。11. 总结与下一步这次围绕“在 Notion 的 GTM 中应用 AI”这个话题把 AI Engineer 在 GTM 项目里的工作拆成了几个可执行的工程任务场景识别、架构分层、数据清洗、Prompt 封装、接口服务、批量任务和质量评估。虽然没有暴露 Notion 内部系统的细节但其中的方法论在任何做 GTM AI 的团队里都通用。如果现在想开始尝试我的建议是先选一个最小的场景比如“线索评分”或者“会议纪要做行动项”然后用一个 CSV 或数据库表里的真实样本跑一遍观察模型输出是否符合业务直觉。不要一开始就追求完美系统先把一条完整链路打通数据读进来、Prompt 拼出来、模型返回结果、结果写入数据库、业务人员能看见。最容易踩的坑有三个一是数据没清洗就丢给大模型导致输出看起来合理但实际是错的二是用同一个 Prompt 处理所有情况导致输出不稳定三是没有人工复核机制导致模型错误直接进入业务动作。下一步可以考虑把评分结果接入 CRM 或者企业内部的客户管理系统让销售在打开一条线索时直接看到 AI 生成的参考结论。你会很快发现业务侧的反馈会比想象中更直接这个功能到底能不能省时间试一两周就有答案。建议收藏备用等真正要落地时再回来对照着做。