在 Notion 的 GTM 流程中应用 AIAI Engineer 视角的落地实践最近不少团队开始尝试把 AI 能力嵌进市场进入Go-to-MarketGTM流程里。我梳理了一套以 Notion 作为业务操作层、以大模型能力作为智能化引擎的落地思路从 GTM 的核心目标、AI 在哪些环节真正有用、工程上怎么搭到一套可以照跑的线索评分与客户意图识别实战代码一次性讲清楚。本文适合负责市场增长、销售运营、客户成功的同学也适合想了解 AI Engineer 在商业化团队里到底做什么的技术同学。1. GTM 到底是什么为什么需要 AI1.1 GTM 不是“市场推广”这么简单GTM 全称是 Go-to-Market中文常翻译成“进入市场”或“市场进入策略”。它不是一个单一动作而是从产品准备推向市场开始到客户成功交付为止的一整套策略和执行动作。GTM 包含目标客户定义、价值主张设计、定价策略、渠道选择、销售流程、内容营销、线索孵化、客户成功等多个环节。在 Notion 这类工具型 SaaS 公司里GTM 团队通常非常依赖数据库、文档、项目管理看板来协同。Notion 本身作为“一体化工作台”承担了需求池、客户档案、内容排期、销售漏斗、复盘会议纪要等大量信息沉淀工作。但这恰恰产生了一个新的问题信息都在但人看不过来。比如一条新线索进来销售是否应该马上跟进这个客户属于哪个行业规模多大是否有明确的预算信号客户在 Notion 里留下的行为数据、沟通记录、需求描述谁能快速提炼成下一步行动传统做法是靠人工判断效率低且不同人的判断标准不一致。这就给 AI 提供了天然的用武之地。1.2 GTM 流程里的 AI 能解决什么AI 在 GTM 里的价值不是取代销售或者市场人员而是把“信息到判断”的距离缩短。用一句话概括GTM 本质上是围绕客户信息做决策和执行而 AI 最擅长的就是从非结构化信息中提取结构化判断。典型的问题包括线索很多但人力有限哪些线索最值得优先跟进客户沟通记录里有大量隐含需求谁能第一时间总结出痛点、预算、时间线内容团队要做一批针对某一行业客户的提案如何快速生成初稿客户成功团队收到大量反馈能否自动归类为功能需求、Bug 投诉、使用障碍、续约风险跨部门会议里的行动项如何自动提取并同步到任务看板这些问题在 Notion 的生态环境里非常常见因为 Notion 本身就承载了 GTM 团队几乎全部的业务信息。AI 的作用是成为这些信息的“阅读器”和“提炼器”把 Notion 数据库里的原始记录变成决策依据。1.3 AI Engineer 在这个场景里的角色AI Engineer 在 GTM 项目里承担的职责和传统后端开发、算法工程师都不太一样。核心工作是四件事第一打通数据管道。把 Notion 数据库、API 请求、第三方数据源整合成模型可用的数据流。第二设计 AI 能力。选模型、写提示词、做 Agent 流程编排让大模型完成某件具体业务任务比如线索评分、需求提取、内容生成。第三建立反馈闭环。AI 的输出要能回到业务系统里比如写回 Notion并允许用户反馈“这条判断准不准”。第四做好评估与治理。模型输出不稳定怎么办如何防止 AI 幻觉如何控制成本如何做权限隔离这些都是 AI Engineer 必须考虑的工程问题。所以本文的路线是先讲概念和场景再给出一套可执行的工程方案最后用一个 Notion LLM 的端到端案例演示从线索读取、意图分析到结果回写的完整过程。2. AI 在 GTM 中的典型应用场景拆解在动手写代码之前有必要把 GTM 里的 AI 应用场景梳理清楚。不同场景的复杂度和落地方式差别很大不要混为一谈。2.1 线索优先级评分销售团队每天会收到大量新线索但并不是每条都值得立刻跟进。线索评分Lead Scoring是一个经典问题。传统做法是设定规则比如“公司人数大于 50 且行业为 SaaS 的线索加 20 分”但规则很难覆盖所有情况更无法理解线索描述中的语义信息。有了大模型之后评分不再只是规则运算而是阅读理解。把客户的简介、来源渠道、互动记录、沟通摘要一起交给模型让模型判断这条线索的购买意向强弱并给出理由。评分结果写回 Notion销售按分数排序跟进效率会高很多。2.2 客户意图标签提取客户在沟通中留下的信息往往是非结构化的。例如一段销售跟进笔记“客户目前使用 Excel 管理渠道数据每周要花两天手工汇总他们希望能有一个更自动化的方案预算大概 5 到 8 万计划在下季度启动。”这段文字里其实包含多个高价值字段客户痛点手工汇总耗时、预算范围5 到 8 万、时间线下季度、潜在产品需求自动化方案。让 AI 从类似文本中提取结构化标签并写入 Notion 的客户数据库可以显著减少销售的手工录入。这就是典型的“信息抽取 结构化”任务大模型的稳定性和准确率在良好提示词下已经可以达到可用的水平。2.3 内容生成与提案初稿GTM 团队的另一个高频任务是内容创作包括邮件营销文案、行业案例、竞品对比表、售前方案初稿。Notion 常常被用作内容素材库沉淀了大量产品文档、客户案例、历史方案。AI 在内容生成环节的价值是“基于内部素材生成第一稿再由人润色定稿”。比如可以设计一个 RAG检索增强生成流程先从 Notion 知识库里检索相关段落再让模型基于检索结果生成针对某行业客户的方案初稿。这样做既可以避免模型完全凭空发挥也可以确保内容符合公司的事实口径。2.4 客户沟通摘要与行动项提取每次客户会议之后团队需要写会议纪要、提炼行动项、更新客户阶段。这些工作通常要占用 15 到 30 分钟。用 AI 把会议记录或转录文本自动处理成结构化摘要并提取行动项、负责人、截止时间再写入 Notion 数据库是效率提升最明显的场景之一。2.5 风险预警与客户健康度分析对于客户成功团队最怕的是客户悄悄流失。AI 可以从客户的历史工单、使用反馈、沟通语气、续约时间中识别出风险信号。比如一段客户消息里频繁出现“太贵了”“考虑换”“还没感受到价值”等表达AI 可以自动标记为“续约风险高”并建议客户成功经理尽早介入。这五项场景中最容易起步的是线索评分和意图标签提取因为它们本质上都是“读文本、出结构化结果”的任务不需要复杂的工作流编排。而内容生成和风险预警则需要更完善的上下文管理。接下来我给出的案例就是基于线索评分 意图标签提取这条主线。3. 技术方案与工程架构设计3.1 整体架构Notion 是操作层LLM 是智能层在这套方案里Notion 承担两个角色。第一个角色是数据源。客户信息、线索信息、沟通纪要、产品需求都存在于 Notion 数据库中。第二个角色是业务操作台。模型分析完的结果需要写回 Notion让销售、市场、客户成功人员在每天习惯使用的工具里直接看到结果而不是打开另一个 AI 平台。因此整体的架构可以分成三层。第一层是数据接入层。通过 Notion API 读取目标数据库中的记录筛选出需要处理的字段比如公司名称、行业、简介、最近互动记录。第二层是 AI 处理层。把读取到的一批记录组织成 Prompt调用大模型接口进行分析要求模型返回 JSON 格式的结构化结果。为了效率和稳定性可以给每条记录单独构造 Prompt也可以把多条记录合并成一次批量请求。第三层是回写展示层。将模型返回的评分、标签、理由等字段通过 Notion API 更新到对应数据库的记录里。这套架构的好处是业务人员不需要改变工作习惯所有输入输出都在 Notion 内完成而 AI 只是后台的一个“增强组件”。3.2 模型选型通用模型 兼顾成本模型选型需要结合任务类型、数据敏感度、成本和响应速度来定。对于“文本分类 信息抽取 生成判断理由”这类任务目前主流的商用大模型都能达到较好的效果。如果团队希望数据不出内网也可以考虑部署开源模型比如通过 Ollama 在本地 GPU 机器上运行 Llama 系列或 Qwen 系列模型。但需要注意本地部署的模型在中文语义理解、指令遵循能力上往往不如同期的顶级商用 API 模型。这里给出一个务实的选择原则如果团队处于快速验证阶段优先使用商用 API 模型开发成本最低。如果团队所在行业有严格的数据合规要求再考虑本地部署开源模型。如果任务对成本非常敏感可以先用小模型试跑评估再决定是否升级到大模型。无论选哪种线上环境都要有模型版本固定机制不能允许模型在无人知晓的情况下悄悄升级。我在案例中将以 OpenAI 兼容的 API 接口为例代码里也保留了本地模型如 Ollama的切换方式。这样无论是用云 API 还是本地模型都可以套用同一套代码框架。3.3 Prompt 设计结构化输出是重中之重在 GTM 场景里Prompt 设计的核心目标不是“让模型说出正确答案”而是“让模型以可解析的格式输出结构化结果”。如果模型返回的是自由文本后面的自动化处理根本跑不起来。因此在 Prompt 中要明确给出输出格式要求最好让模型输出 JSON并指定字段名和枚举值范围。同时要要求模型在拿不准的情况下使用“unknown”或“null”而不是强行猜测一个结果。另一个关键技巧是提供 Few-shot 示例。给模型一两个参考输入和对应输出能显著提高 JSON 格式的稳定性和字段取值的规范性。哪怕只是简短的示例也能让模型少犯很多低级错误。3.4 处理链路批量、限流、重试、回写实际环境中一次要处理的线索可能有几十条甚至上百条。工程上要考虑批处理效率但同时也要注意 API 的速率限制Rate Limit和成本。比较稳妥的做法是设置一个合理的批大小比如每批 20 条记录。为每条记录构造独立的 Prompt但复用同一个系统提示词。调用接口时增加超时和重试机制。对模型返回结果做 JSON 解析校验解析失败时降级处理不阻断整批任务。回写 Notion 时可以逐条更新也可以使用 Notion API 的批量更新能力具体以官方文档为准。4. 完整实战用 Notion LLM 做客户线索评分与意图识别在这一节我会带你完成一个可运行的最小闭环。项目目标是从 Notion 数据库读取线索记录调用大模型对每条线索进行购买意向评分和痛点标签提取然后把结果写回 Notion。4.1 创建 Notion 数据库结构在动手写代码前先在 Notion 里创建一个数据库用于存放待分析的线索。数据库字段建议至少包含以下几列字段名类型说明公司名称标题线索对应的公司行业富文本或单选客户所处行业公司简介富文本客户业务描述可以是粘贴的信息最近互动富文本最近销售沟通记录或客户留言意向评分数字AI 输出后回写评分理由富文本AI 输出后回写痛点标签富文本AI 输出后回写可存逗号分隔文本准备好数据库后记下数据库的 ID。在 Notion 中打开数据库URL 形如https://www.notion.so/workspace/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxURL 中最后一段 32 位字符串通常就是数据库 ID。另一种方式是点击数据库右上角菜单选择“Copy link”再从中提取 ID。4.2 创建 Notion API Integration要让 Python 脚本读取和写入 Notion 数据库需要创建一个 Integration并获得访问令牌。登录 Notion 的集成管理页面创建一个新的 Internal Integration名称可以随便取比如GTM AI Assistant。创建成功后你会得到一串以ntn_开头的内部集成令牌。接着回到刚才创建的数据库页面点击右上角菜单选择Connections在弹窗中添加刚刚创建的 Integration。这一步非常关键很多新手在这里卡住集成创建了但没有连接到数据库导致 API 返回 404。连接完成后数据库就授权给这个 Integration 了。需要注意Integration 的权限需要设置为读写Read Update权限否则无法回写数据。这些操作都应该在你自己拥有管理权限的 Notion 工作区内完成生产环境应遵循最小权限原则。4.3 配置 OpenAI API Key 或本地模型地址本案例以 OpenAI 兼容接口为例。如果你使用 OpenAI 官方 API直接配置OPENAI_API_KEY。如果你通过 Ollama 等工具运行本地模型可以借助其兼容接口地址通常是http://localhost:11434/v1模型名按实际拉取的模型填写。为了安全不要在源码中硬编码密钥。建议使用环境变量或者在项目根目录创建一个.env文件并通过python-dotenv加载。4.4 安装依赖创建一个项目目录并写入如下依赖pip install requests python-dotenv openai这里requests用于调用 Notion APIopenai用于调用大模型接口python-dotenv用于加载环境变量。4.5 项目结构为了便于理解和扩展项目按如下结构组织gtm-ai-demo/ ├── .env ├── config.py ├── notion_client.py ├── ai_analysis.py ├── main.py └── requirements.txt下面逐个文件展开。4.6 环境变量配置文件路径.envNOTION_API_KEYntn_你的_integration_token NOTION_DATABASE_ID你的数据库ID OPENAI_API_KEYsk-你的_openai_key OPENAI_BASE_URLhttps://api.openai.com/v1 MODEL_NAMEgpt-4o-mini如果你使用本地模型可以把OPENAI_BASE_URL和模型名替换为本地配置。比如OPENAI_BASE_URLhttp://localhost:11434/v1 MODEL_NAMEqwen2.5:7b4.7 配置文件文件路径config.pyimport os from dotenv import load_dotenv load_dotenv() NOTION_API_KEY os.getenv(NOTION_API_KEY) NOTION_DATABASE_ID os.getenv(NOTION_DATABASE_ID) OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini)这个文件的作用是统一读取环境变量避免在多个文件里重复加载。4.8 编写 Notion 数据访问模块文件路径notion_client.pyimport requests import config class NotionDBClient: def __init__(self): self.headers { Authorization: fBearer {config.NOTION_API_KEY}, Notion-Version: 2022-06-28, Content-Type: application/json, } self.base_url https://api.notion.com/v1 def query_database(self, page_size100): url f{self.base_url}/databases/{config.NOTION_DATABASE_ID}/query payload {page_size: page_size} resp requests.post(url, headersself.headers, jsonpayload) resp.raise_for_status() return resp.json() def update_page(self, page_id, properties): url f{self.base_url}/pages/{page_id} payload {properties: properties} resp requests.patch(url, headersself.headers, jsonpayload) resp.raise_for_status() return resp.json() def extract_lead_info(page): props page.get(properties, {}) lead { page_id: page[id], company_name: _get_rich_text(props.get(公司名称, {})), industry: _get_rich_text(props.get(行业, {})), description: _get_rich_text(props.get(公司简介, {})), recent_interaction: _get_rich_text(props.get(最近互动, {})), } return lead def _get_rich_text(property_value): if property_value is None: return prop_type property_value.get(type) if prop_type rich_text: parts property_value.get(rich_text, []) elif prop_type title: parts property_value.get(title, []) else: return return .join(part.get(plain_text, ) for part in parts)这段代码最核心的地方是extract_lead_info它把 Notion API 返回的复杂 JSON 结构简化成我们需要的四个文本字段。这样后面的 AI 分析模块就不用关心 Notion 的数据结构了。4.9 编写 AI 分析模块接下来是核心的 AI 分析模块。设计上我们给每条线索单独构造一个 Prompt请模型输出一个 JSON里面包含三个字段score购买意向评分0 到 100reason评分理由中文简述pain_points痛点标签列表。为了保证输出格式稳定我们既要明确指定 JSON 格式也要给出一个 Few-shot 示例。文件路径ai_analysis.pyimport json from openai import OpenAI import config SYSTEM_PROMPT 你是一名资深的 B2B 销售策略助手负责对销售线索进行购买意向评分。 请根据给定的公司信息、行业和最近互动记录输出 JSON 格式评估结果。 字段说明 - score: 0 到 100 的整数分数越高表示购买意向越强。 - reason: 一句话说明评分理由控制在 50 字以内。 - pain_points: 数组列出客户的主要痛点或需求最多 3 个。 注意 - 如果信息不足不要强行猜测score 可以给一个保守值pain_points 返回空数组。 - 只输出 JSON不要输出任何解释文字。 USER_PROMPT_TEMPLATE 请分析以下销售线索 公司名称{company_name} 行业{industry} 公司简介{description} 最近互动记录{recent_interaction} 请参考示例输出格式 {{ score: 78, reason: 客户有明确预算和部署时间痛点匹配度高, pain_points: [数据汇总耗时, 缺乏自动化方案, 预算已确认] }} class LeadAnalyzer: def __init__(self): self.client OpenAI( api_keyconfig.OPENAI_API_KEY, base_urlconfig.OPENAI_BASE_URL, ) self.model config.MODEL_NAME def analyze_lead(self, lead): user_prompt USER_PROMPT_TEMPLATE.format( company_namelead.get(company_name, ), industrylead.get(industry, ), descriptionlead.get(description, ), recent_interactionlead.get(recent_interaction, ), ) try: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], temperature0.2, response_format{type: json_object}, ) content response.choices[0].message.content return self._parse_result(content) except Exception as e: return { score: 0, reason: f分析失败: {str(e)}, pain_points: [], } def _parse_result(self, content): try: data json.loads(content) score int(data.get(score, 0)) reason data.get(reason, ) pain_points data.get(pain_points, []) if not isinstance(pain_points, list): pain_points [] return { score: max(0, min(100, score)), reason: reason, pain_points: pain_points, } except json.JSONDecodeError: return { score: 0, reason: 模型输出无法解析为 JSON, pain_points: [], }这里有几个细节值得说明。response_format{type: json_object}是让模型尽量按 JSON 结构输出但即使如此我们仍然要在代码里做解析兜底防止偶发的非 JSON 输出导致整批任务失败。模型返回字段的取值也会做一次范围校验确保 score 落在 0 到 100 之间。temperature0.2设置为低温度是为了让模型输出更稳定减少随机发挥。4.10 编写主流程文件路径main.pyfrom notion_client import NotionDBClient, extract_lead_info from ai_analysis import LeadAnalyzer def build_update_properties(company_name, result, display_name): # 回写 Notion 的字段结构 pain_points_text , .join(result[pain_points]) return { 意向评分: { number: result[score] }, 评分理由: { rich_text: [{text: {content: result[reason]}}] }, 痛点标签: { rich_text: [{text: {content: pain_points_text}}] } } def main(): db_client NotionDBClient() analyzer LeadAnalyzer() print(开始读取 Notion 数据库...) data db_client.query_database(page_size50) pages data.get(results, []) if not pages: print(数据库中没有待处理的记录。) return print(f共读取到 {len(pages)} 条线索。) for page in pages: lead extract_lead_info(page) company_name lead.get(company_name) or 未命名客户 print(f正在分析: {company_name}) result analyzer.analyze_lead(lead) print(f 评分: {result[score]}理由: {result[reason]}) properties { 意向评分: {number: result[score]}, 评分理由: {rich_text: [{text: {content: result[reason]}}]}, 痛点标签: { rich_text: [{text: {content: , .join(result[pain_points])}}] }, } db_client.update_page(lead[page_id], properties) print(f 已回写结果到 Notion。) print(全部线索处理完成。) if __name__ __main__: main()这段主流程的逻辑非常直白读取数据库、逐条分析、回写结果。实际项目中你可以把逐条分析改成并发调用但并发会带来限流问题所以先用单线程跑通是最稳妥的方式。4.11 运行与验证在终端执行python main.py正常执行时你会看到类似输出开始读取 Notion 数据库... 共读取到 10 条线索。 正在分析: 某某云科技 评分: 82理由: 客户有明确的数据自动化需求预算和采购时间已确认 已回写结果到 Notion。 正在分析: 某某零售集团 评分: 45理由: 客户有潜在需求但缺乏明确预算需要进一步培育 已回写结果到 Notion。 全部线索处理完成。然后打开 Notion 数据库你会发现“意向评分”“评分理由”“痛点标签”三列已经被自动填充。整个流程就跑通了。4.12 使用本地模型时的调整方式如果你使用的是 Ollama 等本地模型ai_analysis.py中的 OpenAI 客户端接口保持不变只需要在.env里修改OPENAI_BASE_URL和MODEL_NAME。例如OPENAI_BASE_URLhttp://localhost:11434/v1 MODEL_NAMEqwen2.5:7b本地模型的好处是数据不出内网适合对数据合规要求较高的团队。但也要注意本地模型对复杂指令的遵循能力可能弱于商用 API 模型因此你可能需要根据模型表现调整SYSTEM_PROMPT甚至增加更多 Few-shot 示例。如果你的机器有 NVIDIA GPU且希望模型跑在 GPU 上可以提前确认 Ollama 是否识别到 GPU。不同系统下查看方式略有不同一般在运行模型时观察日志或者使用ollama ps查看模型是否加载在 GPU 上。如果 GPU 未生效需要检查驱动、CUDA 环境和 Ollama 的启动日志。5. 常见问题与排查思路在实际运行这套流程时有几个问题出现频率非常高。5.1 Notion API 返回 404这个问题的绝大多数原因不是代码写错了而是 Notion Integration 没有连接到目标数据库。排查步骤确认数据库页面右上角菜单里的Connections是否包含你创建的 Integration。检查.env中的NOTION_DATABASE_ID是否准确复制了数据库 ID。检查 Integration Token 是否填错是否包含多余的空格。解决方法是打开数据库页面在Connections中添加你的 Integration然后重新运行脚本。5.2 模型返回内容解析失败即便指定了response_format模型在极少数情况下仍然可能返回非 JSON 内容特别是某些本地模型。排查步骤打印出模型的原始返回内容确认到底输出了什么。如果模型经常返回 Markdown 代码块可以在解析前先清理多余字符。在 Prompt 中增加 Few-shot 示例通常能显著提升格式稳定性。常见的简单修复方式是在解析前做一次清理去掉可能的json 和标记。5.3 回写 Notion 时提示 400回写时报 400 通常是属性结构不正确比如字段名不存在或者字段类型不匹配。排查步骤检查 Notion 数据库里是否真的有“意向评分”“评分理由”“痛点标签”这三个字段。检查字段类型是否是数字和富文本。如果是单选类型字段需要传select而不是rich_text。5.4 API 限流导致部分记录失败调用商用 API 时如果一次批量处理太多记录可能触发限流。排查步骤检查报错信息中是否包含rate limit等字样。在循环中加入一个短暂的time.sleep(1)给请求之间留出间隔。把批处理数量从 50 条降到 20 条试试。5.5 模型出现“AI 幻觉”编造客户信息这是一个值得重视的问题。模型在信息不足时可能会根据训练数据中的模式联想给出看似合理但实际不存在的客户痛点。应对方法在 Prompt 中明确要求信息不足时输出unknown或空数组不要猜测。对模型的输出增加字段校验比如pain_points必须来自给定文本的语义提炼不能凭空增加关键词。在业务上把 AI 结果定位为“辅助建议”而不是“决策结论”最终跟进动作由人工确认。问题现象常见原因解决思路Notion API 返回 404Integration 未连接到数据库在数据库页面 Connection 中授权模型输出无法解析Prompt 缺少格式约束增加 Few-shot 和 JSON 解析兜底回写字段提示 400字段名或类型不匹配核对数据库字段名与属性结构API 限流请求频率过高增加间隔时间降低批次大小幻觉内容信息不足时模型强行猜测提示词限制增加人工确认环节6. 最佳实践与工程建议6.1 始终保留人工确认环节在 GTM 场景中AI 的输出会直接影响销售跟进策略。因此我建议任何 AI 生成的评分、标签、摘要都必须保留“人工可修改”的入口。不要让 AI 的结果变成不可变的唯一标准。工具上是这样操作流程上也要定义清楚AI 是助理不是决策者。6.2 数据权限与最小权限原则Notion 数据库里可能包含客户敏感信息。在创建 Integration 和 API Key 时要坚持最小权限原则只授予读取必要数据库的权限。生产环境不要使用个人账号的集成令牌应该使用团队级隔离的密钥。API Key 不要提交到代码仓库要通过环境变量或密钥管理服务注入。不要将 Notion 数据未经脱敏就发送给第三方模型除非你已确认数据合规边界。6.3 建立评估集量化模型质量很多人做 AI 功能只关注“能不能跑通”但真正的难点是“能不能稳定跑”。建议建一个 20 到 50 条标准样本的评估集每条样本包含“输入文本 期望输出”。每次修改提示词、更换模型后都先在评估集上跑一遍再决定是否上线。评估指标可以关注JSON 格式解析成功率。评分与实际销售结果的相关系数。痛点标签的准确率。有了评估集你才敢逐步优化而不是靠感觉调提示词。6.4 成本控制与模型分级对 GTM 流程来说不同的任务可以调用不同档次的模型。比如简单的文本分类用轻量模型即可复杂的语义分析才需要大模型。你可以在代码中抽象出模型路由层按任务类型选择模型。同时记录每次调用的输入输出长度和费用避免月末账单爆掉。6.5 日志与可追踪性线上跑 AI 任务一定要记录完整的输入输出日志。建议至少包含处理时间。线索 ID。模型名称。Prompt 版本。模型返回结果。是否成功回写。这样即使出现问题也能回溯是哪一批数据、哪个 Prompt、哪个模型版本造成的而不是靠感觉猜。6.6 从 Notion 出发但不局限于 Notion本文以 Notion 为例因为它是 GTM 团队高频使用的协作工具。但背后的方法论完全适用于飞书多维表格、Excel、CRM 等任何数据载体。你只需要把“数据读取”和“数据回写”替换成对应平台的 API 即可。这也是为什么我在代码里把 Notion 读取逻辑单独封装成一个类目的就是方便替换。7. 总结与下一步实践建议本文从一个 AI Engineer 的视角把“在 Notion 的 GTM 流程中应用 AI”这件事拆成了三段一是想清楚 AI 在 GTM 里到底能做什么二是搭一套数据读取、AI 分析、结果回写的工程管道三是用尽可能小的成本验证可行性。完整跑通这套最小闭环之后你其实已经摸到了 AI Agent 在业务系统里落地的主干数据接入、模型调用、结构化解析、业务回写、人工确认。后续往更深处走还会有几个方向值得继续研究。如果你希望继续深化可以优先做三件事。第一补充检索增强生成能力让模型在生成内容时能引用 Notion 知识库里的真实产品文档减少幻觉。第二把单条线索的分析升级为批量并发处理并引入任务队列让整个流程可以定时自动跑。第三搭建一个简单的评估脚本把每次人工修正的结果沉淀下来逐步优化提示词和模型选择。这套方案的价值不在于代码多复杂而在于你真正理解了AI 不是悬在业务之上的魔法而是嵌在业务系统里的一个可靠组件。希望这篇文章能帮你迈出实战的第一步。如果你在自己的环境里跑通了也遇到了其他问题欢迎在评论里一起讨论。
Notion GTM流程中如何应用AI：从线索评分到意图识别的实战
在 Notion 的 GTM 流程中应用 AIAI Engineer 视角的落地实践最近不少团队开始尝试把 AI 能力嵌进市场进入Go-to-MarketGTM流程里。我梳理了一套以 Notion 作为业务操作层、以大模型能力作为智能化引擎的落地思路从 GTM 的核心目标、AI 在哪些环节真正有用、工程上怎么搭到一套可以照跑的线索评分与客户意图识别实战代码一次性讲清楚。本文适合负责市场增长、销售运营、客户成功的同学也适合想了解 AI Engineer 在商业化团队里到底做什么的技术同学。1. GTM 到底是什么为什么需要 AI1.1 GTM 不是“市场推广”这么简单GTM 全称是 Go-to-Market中文常翻译成“进入市场”或“市场进入策略”。它不是一个单一动作而是从产品准备推向市场开始到客户成功交付为止的一整套策略和执行动作。GTM 包含目标客户定义、价值主张设计、定价策略、渠道选择、销售流程、内容营销、线索孵化、客户成功等多个环节。在 Notion 这类工具型 SaaS 公司里GTM 团队通常非常依赖数据库、文档、项目管理看板来协同。Notion 本身作为“一体化工作台”承担了需求池、客户档案、内容排期、销售漏斗、复盘会议纪要等大量信息沉淀工作。但这恰恰产生了一个新的问题信息都在但人看不过来。比如一条新线索进来销售是否应该马上跟进这个客户属于哪个行业规模多大是否有明确的预算信号客户在 Notion 里留下的行为数据、沟通记录、需求描述谁能快速提炼成下一步行动传统做法是靠人工判断效率低且不同人的判断标准不一致。这就给 AI 提供了天然的用武之地。1.2 GTM 流程里的 AI 能解决什么AI 在 GTM 里的价值不是取代销售或者市场人员而是把“信息到判断”的距离缩短。用一句话概括GTM 本质上是围绕客户信息做决策和执行而 AI 最擅长的就是从非结构化信息中提取结构化判断。典型的问题包括线索很多但人力有限哪些线索最值得优先跟进客户沟通记录里有大量隐含需求谁能第一时间总结出痛点、预算、时间线内容团队要做一批针对某一行业客户的提案如何快速生成初稿客户成功团队收到大量反馈能否自动归类为功能需求、Bug 投诉、使用障碍、续约风险跨部门会议里的行动项如何自动提取并同步到任务看板这些问题在 Notion 的生态环境里非常常见因为 Notion 本身就承载了 GTM 团队几乎全部的业务信息。AI 的作用是成为这些信息的“阅读器”和“提炼器”把 Notion 数据库里的原始记录变成决策依据。1.3 AI Engineer 在这个场景里的角色AI Engineer 在 GTM 项目里承担的职责和传统后端开发、算法工程师都不太一样。核心工作是四件事第一打通数据管道。把 Notion 数据库、API 请求、第三方数据源整合成模型可用的数据流。第二设计 AI 能力。选模型、写提示词、做 Agent 流程编排让大模型完成某件具体业务任务比如线索评分、需求提取、内容生成。第三建立反馈闭环。AI 的输出要能回到业务系统里比如写回 Notion并允许用户反馈“这条判断准不准”。第四做好评估与治理。模型输出不稳定怎么办如何防止 AI 幻觉如何控制成本如何做权限隔离这些都是 AI Engineer 必须考虑的工程问题。所以本文的路线是先讲概念和场景再给出一套可执行的工程方案最后用一个 Notion LLM 的端到端案例演示从线索读取、意图分析到结果回写的完整过程。2. AI 在 GTM 中的典型应用场景拆解在动手写代码之前有必要把 GTM 里的 AI 应用场景梳理清楚。不同场景的复杂度和落地方式差别很大不要混为一谈。2.1 线索优先级评分销售团队每天会收到大量新线索但并不是每条都值得立刻跟进。线索评分Lead Scoring是一个经典问题。传统做法是设定规则比如“公司人数大于 50 且行业为 SaaS 的线索加 20 分”但规则很难覆盖所有情况更无法理解线索描述中的语义信息。有了大模型之后评分不再只是规则运算而是阅读理解。把客户的简介、来源渠道、互动记录、沟通摘要一起交给模型让模型判断这条线索的购买意向强弱并给出理由。评分结果写回 Notion销售按分数排序跟进效率会高很多。2.2 客户意图标签提取客户在沟通中留下的信息往往是非结构化的。例如一段销售跟进笔记“客户目前使用 Excel 管理渠道数据每周要花两天手工汇总他们希望能有一个更自动化的方案预算大概 5 到 8 万计划在下季度启动。”这段文字里其实包含多个高价值字段客户痛点手工汇总耗时、预算范围5 到 8 万、时间线下季度、潜在产品需求自动化方案。让 AI 从类似文本中提取结构化标签并写入 Notion 的客户数据库可以显著减少销售的手工录入。这就是典型的“信息抽取 结构化”任务大模型的稳定性和准确率在良好提示词下已经可以达到可用的水平。2.3 内容生成与提案初稿GTM 团队的另一个高频任务是内容创作包括邮件营销文案、行业案例、竞品对比表、售前方案初稿。Notion 常常被用作内容素材库沉淀了大量产品文档、客户案例、历史方案。AI 在内容生成环节的价值是“基于内部素材生成第一稿再由人润色定稿”。比如可以设计一个 RAG检索增强生成流程先从 Notion 知识库里检索相关段落再让模型基于检索结果生成针对某行业客户的方案初稿。这样做既可以避免模型完全凭空发挥也可以确保内容符合公司的事实口径。2.4 客户沟通摘要与行动项提取每次客户会议之后团队需要写会议纪要、提炼行动项、更新客户阶段。这些工作通常要占用 15 到 30 分钟。用 AI 把会议记录或转录文本自动处理成结构化摘要并提取行动项、负责人、截止时间再写入 Notion 数据库是效率提升最明显的场景之一。2.5 风险预警与客户健康度分析对于客户成功团队最怕的是客户悄悄流失。AI 可以从客户的历史工单、使用反馈、沟通语气、续约时间中识别出风险信号。比如一段客户消息里频繁出现“太贵了”“考虑换”“还没感受到价值”等表达AI 可以自动标记为“续约风险高”并建议客户成功经理尽早介入。这五项场景中最容易起步的是线索评分和意图标签提取因为它们本质上都是“读文本、出结构化结果”的任务不需要复杂的工作流编排。而内容生成和风险预警则需要更完善的上下文管理。接下来我给出的案例就是基于线索评分 意图标签提取这条主线。3. 技术方案与工程架构设计3.1 整体架构Notion 是操作层LLM 是智能层在这套方案里Notion 承担两个角色。第一个角色是数据源。客户信息、线索信息、沟通纪要、产品需求都存在于 Notion 数据库中。第二个角色是业务操作台。模型分析完的结果需要写回 Notion让销售、市场、客户成功人员在每天习惯使用的工具里直接看到结果而不是打开另一个 AI 平台。因此整体的架构可以分成三层。第一层是数据接入层。通过 Notion API 读取目标数据库中的记录筛选出需要处理的字段比如公司名称、行业、简介、最近互动记录。第二层是 AI 处理层。把读取到的一批记录组织成 Prompt调用大模型接口进行分析要求模型返回 JSON 格式的结构化结果。为了效率和稳定性可以给每条记录单独构造 Prompt也可以把多条记录合并成一次批量请求。第三层是回写展示层。将模型返回的评分、标签、理由等字段通过 Notion API 更新到对应数据库的记录里。这套架构的好处是业务人员不需要改变工作习惯所有输入输出都在 Notion 内完成而 AI 只是后台的一个“增强组件”。3.2 模型选型通用模型 兼顾成本模型选型需要结合任务类型、数据敏感度、成本和响应速度来定。对于“文本分类 信息抽取 生成判断理由”这类任务目前主流的商用大模型都能达到较好的效果。如果团队希望数据不出内网也可以考虑部署开源模型比如通过 Ollama 在本地 GPU 机器上运行 Llama 系列或 Qwen 系列模型。但需要注意本地部署的模型在中文语义理解、指令遵循能力上往往不如同期的顶级商用 API 模型。这里给出一个务实的选择原则如果团队处于快速验证阶段优先使用商用 API 模型开发成本最低。如果团队所在行业有严格的数据合规要求再考虑本地部署开源模型。如果任务对成本非常敏感可以先用小模型试跑评估再决定是否升级到大模型。无论选哪种线上环境都要有模型版本固定机制不能允许模型在无人知晓的情况下悄悄升级。我在案例中将以 OpenAI 兼容的 API 接口为例代码里也保留了本地模型如 Ollama的切换方式。这样无论是用云 API 还是本地模型都可以套用同一套代码框架。3.3 Prompt 设计结构化输出是重中之重在 GTM 场景里Prompt 设计的核心目标不是“让模型说出正确答案”而是“让模型以可解析的格式输出结构化结果”。如果模型返回的是自由文本后面的自动化处理根本跑不起来。因此在 Prompt 中要明确给出输出格式要求最好让模型输出 JSON并指定字段名和枚举值范围。同时要要求模型在拿不准的情况下使用“unknown”或“null”而不是强行猜测一个结果。另一个关键技巧是提供 Few-shot 示例。给模型一两个参考输入和对应输出能显著提高 JSON 格式的稳定性和字段取值的规范性。哪怕只是简短的示例也能让模型少犯很多低级错误。3.4 处理链路批量、限流、重试、回写实际环境中一次要处理的线索可能有几十条甚至上百条。工程上要考虑批处理效率但同时也要注意 API 的速率限制Rate Limit和成本。比较稳妥的做法是设置一个合理的批大小比如每批 20 条记录。为每条记录构造独立的 Prompt但复用同一个系统提示词。调用接口时增加超时和重试机制。对模型返回结果做 JSON 解析校验解析失败时降级处理不阻断整批任务。回写 Notion 时可以逐条更新也可以使用 Notion API 的批量更新能力具体以官方文档为准。4. 完整实战用 Notion LLM 做客户线索评分与意图识别在这一节我会带你完成一个可运行的最小闭环。项目目标是从 Notion 数据库读取线索记录调用大模型对每条线索进行购买意向评分和痛点标签提取然后把结果写回 Notion。4.1 创建 Notion 数据库结构在动手写代码前先在 Notion 里创建一个数据库用于存放待分析的线索。数据库字段建议至少包含以下几列字段名类型说明公司名称标题线索对应的公司行业富文本或单选客户所处行业公司简介富文本客户业务描述可以是粘贴的信息最近互动富文本最近销售沟通记录或客户留言意向评分数字AI 输出后回写评分理由富文本AI 输出后回写痛点标签富文本AI 输出后回写可存逗号分隔文本准备好数据库后记下数据库的 ID。在 Notion 中打开数据库URL 形如https://www.notion.so/workspace/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxURL 中最后一段 32 位字符串通常就是数据库 ID。另一种方式是点击数据库右上角菜单选择“Copy link”再从中提取 ID。4.2 创建 Notion API Integration要让 Python 脚本读取和写入 Notion 数据库需要创建一个 Integration并获得访问令牌。登录 Notion 的集成管理页面创建一个新的 Internal Integration名称可以随便取比如GTM AI Assistant。创建成功后你会得到一串以ntn_开头的内部集成令牌。接着回到刚才创建的数据库页面点击右上角菜单选择Connections在弹窗中添加刚刚创建的 Integration。这一步非常关键很多新手在这里卡住集成创建了但没有连接到数据库导致 API 返回 404。连接完成后数据库就授权给这个 Integration 了。需要注意Integration 的权限需要设置为读写Read Update权限否则无法回写数据。这些操作都应该在你自己拥有管理权限的 Notion 工作区内完成生产环境应遵循最小权限原则。4.3 配置 OpenAI API Key 或本地模型地址本案例以 OpenAI 兼容接口为例。如果你使用 OpenAI 官方 API直接配置OPENAI_API_KEY。如果你通过 Ollama 等工具运行本地模型可以借助其兼容接口地址通常是http://localhost:11434/v1模型名按实际拉取的模型填写。为了安全不要在源码中硬编码密钥。建议使用环境变量或者在项目根目录创建一个.env文件并通过python-dotenv加载。4.4 安装依赖创建一个项目目录并写入如下依赖pip install requests python-dotenv openai这里requests用于调用 Notion APIopenai用于调用大模型接口python-dotenv用于加载环境变量。4.5 项目结构为了便于理解和扩展项目按如下结构组织gtm-ai-demo/ ├── .env ├── config.py ├── notion_client.py ├── ai_analysis.py ├── main.py └── requirements.txt下面逐个文件展开。4.6 环境变量配置文件路径.envNOTION_API_KEYntn_你的_integration_token NOTION_DATABASE_ID你的数据库ID OPENAI_API_KEYsk-你的_openai_key OPENAI_BASE_URLhttps://api.openai.com/v1 MODEL_NAMEgpt-4o-mini如果你使用本地模型可以把OPENAI_BASE_URL和模型名替换为本地配置。比如OPENAI_BASE_URLhttp://localhost:11434/v1 MODEL_NAMEqwen2.5:7b4.7 配置文件文件路径config.pyimport os from dotenv import load_dotenv load_dotenv() NOTION_API_KEY os.getenv(NOTION_API_KEY) NOTION_DATABASE_ID os.getenv(NOTION_DATABASE_ID) OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini)这个文件的作用是统一读取环境变量避免在多个文件里重复加载。4.8 编写 Notion 数据访问模块文件路径notion_client.pyimport requests import config class NotionDBClient: def __init__(self): self.headers { Authorization: fBearer {config.NOTION_API_KEY}, Notion-Version: 2022-06-28, Content-Type: application/json, } self.base_url https://api.notion.com/v1 def query_database(self, page_size100): url f{self.base_url}/databases/{config.NOTION_DATABASE_ID}/query payload {page_size: page_size} resp requests.post(url, headersself.headers, jsonpayload) resp.raise_for_status() return resp.json() def update_page(self, page_id, properties): url f{self.base_url}/pages/{page_id} payload {properties: properties} resp requests.patch(url, headersself.headers, jsonpayload) resp.raise_for_status() return resp.json() def extract_lead_info(page): props page.get(properties, {}) lead { page_id: page[id], company_name: _get_rich_text(props.get(公司名称, {})), industry: _get_rich_text(props.get(行业, {})), description: _get_rich_text(props.get(公司简介, {})), recent_interaction: _get_rich_text(props.get(最近互动, {})), } return lead def _get_rich_text(property_value): if property_value is None: return prop_type property_value.get(type) if prop_type rich_text: parts property_value.get(rich_text, []) elif prop_type title: parts property_value.get(title, []) else: return return .join(part.get(plain_text, ) for part in parts)这段代码最核心的地方是extract_lead_info它把 Notion API 返回的复杂 JSON 结构简化成我们需要的四个文本字段。这样后面的 AI 分析模块就不用关心 Notion 的数据结构了。4.9 编写 AI 分析模块接下来是核心的 AI 分析模块。设计上我们给每条线索单独构造一个 Prompt请模型输出一个 JSON里面包含三个字段score购买意向评分0 到 100reason评分理由中文简述pain_points痛点标签列表。为了保证输出格式稳定我们既要明确指定 JSON 格式也要给出一个 Few-shot 示例。文件路径ai_analysis.pyimport json from openai import OpenAI import config SYSTEM_PROMPT 你是一名资深的 B2B 销售策略助手负责对销售线索进行购买意向评分。 请根据给定的公司信息、行业和最近互动记录输出 JSON 格式评估结果。 字段说明 - score: 0 到 100 的整数分数越高表示购买意向越强。 - reason: 一句话说明评分理由控制在 50 字以内。 - pain_points: 数组列出客户的主要痛点或需求最多 3 个。 注意 - 如果信息不足不要强行猜测score 可以给一个保守值pain_points 返回空数组。 - 只输出 JSON不要输出任何解释文字。 USER_PROMPT_TEMPLATE 请分析以下销售线索 公司名称{company_name} 行业{industry} 公司简介{description} 最近互动记录{recent_interaction} 请参考示例输出格式 {{ score: 78, reason: 客户有明确预算和部署时间痛点匹配度高, pain_points: [数据汇总耗时, 缺乏自动化方案, 预算已确认] }} class LeadAnalyzer: def __init__(self): self.client OpenAI( api_keyconfig.OPENAI_API_KEY, base_urlconfig.OPENAI_BASE_URL, ) self.model config.MODEL_NAME def analyze_lead(self, lead): user_prompt USER_PROMPT_TEMPLATE.format( company_namelead.get(company_name, ), industrylead.get(industry, ), descriptionlead.get(description, ), recent_interactionlead.get(recent_interaction, ), ) try: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], temperature0.2, response_format{type: json_object}, ) content response.choices[0].message.content return self._parse_result(content) except Exception as e: return { score: 0, reason: f分析失败: {str(e)}, pain_points: [], } def _parse_result(self, content): try: data json.loads(content) score int(data.get(score, 0)) reason data.get(reason, ) pain_points data.get(pain_points, []) if not isinstance(pain_points, list): pain_points [] return { score: max(0, min(100, score)), reason: reason, pain_points: pain_points, } except json.JSONDecodeError: return { score: 0, reason: 模型输出无法解析为 JSON, pain_points: [], }这里有几个细节值得说明。response_format{type: json_object}是让模型尽量按 JSON 结构输出但即使如此我们仍然要在代码里做解析兜底防止偶发的非 JSON 输出导致整批任务失败。模型返回字段的取值也会做一次范围校验确保 score 落在 0 到 100 之间。temperature0.2设置为低温度是为了让模型输出更稳定减少随机发挥。4.10 编写主流程文件路径main.pyfrom notion_client import NotionDBClient, extract_lead_info from ai_analysis import LeadAnalyzer def build_update_properties(company_name, result, display_name): # 回写 Notion 的字段结构 pain_points_text , .join(result[pain_points]) return { 意向评分: { number: result[score] }, 评分理由: { rich_text: [{text: {content: result[reason]}}] }, 痛点标签: { rich_text: [{text: {content: pain_points_text}}] } } def main(): db_client NotionDBClient() analyzer LeadAnalyzer() print(开始读取 Notion 数据库...) data db_client.query_database(page_size50) pages data.get(results, []) if not pages: print(数据库中没有待处理的记录。) return print(f共读取到 {len(pages)} 条线索。) for page in pages: lead extract_lead_info(page) company_name lead.get(company_name) or 未命名客户 print(f正在分析: {company_name}) result analyzer.analyze_lead(lead) print(f 评分: {result[score]}理由: {result[reason]}) properties { 意向评分: {number: result[score]}, 评分理由: {rich_text: [{text: {content: result[reason]}}]}, 痛点标签: { rich_text: [{text: {content: , .join(result[pain_points])}}] }, } db_client.update_page(lead[page_id], properties) print(f 已回写结果到 Notion。) print(全部线索处理完成。) if __name__ __main__: main()这段主流程的逻辑非常直白读取数据库、逐条分析、回写结果。实际项目中你可以把逐条分析改成并发调用但并发会带来限流问题所以先用单线程跑通是最稳妥的方式。4.11 运行与验证在终端执行python main.py正常执行时你会看到类似输出开始读取 Notion 数据库... 共读取到 10 条线索。 正在分析: 某某云科技 评分: 82理由: 客户有明确的数据自动化需求预算和采购时间已确认 已回写结果到 Notion。 正在分析: 某某零售集团 评分: 45理由: 客户有潜在需求但缺乏明确预算需要进一步培育 已回写结果到 Notion。 全部线索处理完成。然后打开 Notion 数据库你会发现“意向评分”“评分理由”“痛点标签”三列已经被自动填充。整个流程就跑通了。4.12 使用本地模型时的调整方式如果你使用的是 Ollama 等本地模型ai_analysis.py中的 OpenAI 客户端接口保持不变只需要在.env里修改OPENAI_BASE_URL和MODEL_NAME。例如OPENAI_BASE_URLhttp://localhost:11434/v1 MODEL_NAMEqwen2.5:7b本地模型的好处是数据不出内网适合对数据合规要求较高的团队。但也要注意本地模型对复杂指令的遵循能力可能弱于商用 API 模型因此你可能需要根据模型表现调整SYSTEM_PROMPT甚至增加更多 Few-shot 示例。如果你的机器有 NVIDIA GPU且希望模型跑在 GPU 上可以提前确认 Ollama 是否识别到 GPU。不同系统下查看方式略有不同一般在运行模型时观察日志或者使用ollama ps查看模型是否加载在 GPU 上。如果 GPU 未生效需要检查驱动、CUDA 环境和 Ollama 的启动日志。5. 常见问题与排查思路在实际运行这套流程时有几个问题出现频率非常高。5.1 Notion API 返回 404这个问题的绝大多数原因不是代码写错了而是 Notion Integration 没有连接到目标数据库。排查步骤确认数据库页面右上角菜单里的Connections是否包含你创建的 Integration。检查.env中的NOTION_DATABASE_ID是否准确复制了数据库 ID。检查 Integration Token 是否填错是否包含多余的空格。解决方法是打开数据库页面在Connections中添加你的 Integration然后重新运行脚本。5.2 模型返回内容解析失败即便指定了response_format模型在极少数情况下仍然可能返回非 JSON 内容特别是某些本地模型。排查步骤打印出模型的原始返回内容确认到底输出了什么。如果模型经常返回 Markdown 代码块可以在解析前先清理多余字符。在 Prompt 中增加 Few-shot 示例通常能显著提升格式稳定性。常见的简单修复方式是在解析前做一次清理去掉可能的json 和标记。5.3 回写 Notion 时提示 400回写时报 400 通常是属性结构不正确比如字段名不存在或者字段类型不匹配。排查步骤检查 Notion 数据库里是否真的有“意向评分”“评分理由”“痛点标签”这三个字段。检查字段类型是否是数字和富文本。如果是单选类型字段需要传select而不是rich_text。5.4 API 限流导致部分记录失败调用商用 API 时如果一次批量处理太多记录可能触发限流。排查步骤检查报错信息中是否包含rate limit等字样。在循环中加入一个短暂的time.sleep(1)给请求之间留出间隔。把批处理数量从 50 条降到 20 条试试。5.5 模型出现“AI 幻觉”编造客户信息这是一个值得重视的问题。模型在信息不足时可能会根据训练数据中的模式联想给出看似合理但实际不存在的客户痛点。应对方法在 Prompt 中明确要求信息不足时输出unknown或空数组不要猜测。对模型的输出增加字段校验比如pain_points必须来自给定文本的语义提炼不能凭空增加关键词。在业务上把 AI 结果定位为“辅助建议”而不是“决策结论”最终跟进动作由人工确认。问题现象常见原因解决思路Notion API 返回 404Integration 未连接到数据库在数据库页面 Connection 中授权模型输出无法解析Prompt 缺少格式约束增加 Few-shot 和 JSON 解析兜底回写字段提示 400字段名或类型不匹配核对数据库字段名与属性结构API 限流请求频率过高增加间隔时间降低批次大小幻觉内容信息不足时模型强行猜测提示词限制增加人工确认环节6. 最佳实践与工程建议6.1 始终保留人工确认环节在 GTM 场景中AI 的输出会直接影响销售跟进策略。因此我建议任何 AI 生成的评分、标签、摘要都必须保留“人工可修改”的入口。不要让 AI 的结果变成不可变的唯一标准。工具上是这样操作流程上也要定义清楚AI 是助理不是决策者。6.2 数据权限与最小权限原则Notion 数据库里可能包含客户敏感信息。在创建 Integration 和 API Key 时要坚持最小权限原则只授予读取必要数据库的权限。生产环境不要使用个人账号的集成令牌应该使用团队级隔离的密钥。API Key 不要提交到代码仓库要通过环境变量或密钥管理服务注入。不要将 Notion 数据未经脱敏就发送给第三方模型除非你已确认数据合规边界。6.3 建立评估集量化模型质量很多人做 AI 功能只关注“能不能跑通”但真正的难点是“能不能稳定跑”。建议建一个 20 到 50 条标准样本的评估集每条样本包含“输入文本 期望输出”。每次修改提示词、更换模型后都先在评估集上跑一遍再决定是否上线。评估指标可以关注JSON 格式解析成功率。评分与实际销售结果的相关系数。痛点标签的准确率。有了评估集你才敢逐步优化而不是靠感觉调提示词。6.4 成本控制与模型分级对 GTM 流程来说不同的任务可以调用不同档次的模型。比如简单的文本分类用轻量模型即可复杂的语义分析才需要大模型。你可以在代码中抽象出模型路由层按任务类型选择模型。同时记录每次调用的输入输出长度和费用避免月末账单爆掉。6.5 日志与可追踪性线上跑 AI 任务一定要记录完整的输入输出日志。建议至少包含处理时间。线索 ID。模型名称。Prompt 版本。模型返回结果。是否成功回写。这样即使出现问题也能回溯是哪一批数据、哪个 Prompt、哪个模型版本造成的而不是靠感觉猜。6.6 从 Notion 出发但不局限于 Notion本文以 Notion 为例因为它是 GTM 团队高频使用的协作工具。但背后的方法论完全适用于飞书多维表格、Excel、CRM 等任何数据载体。你只需要把“数据读取”和“数据回写”替换成对应平台的 API 即可。这也是为什么我在代码里把 Notion 读取逻辑单独封装成一个类目的就是方便替换。7. 总结与下一步实践建议本文从一个 AI Engineer 的视角把“在 Notion 的 GTM 流程中应用 AI”这件事拆成了三段一是想清楚 AI 在 GTM 里到底能做什么二是搭一套数据读取、AI 分析、结果回写的工程管道三是用尽可能小的成本验证可行性。完整跑通这套最小闭环之后你其实已经摸到了 AI Agent 在业务系统里落地的主干数据接入、模型调用、结构化解析、业务回写、人工确认。后续往更深处走还会有几个方向值得继续研究。如果你希望继续深化可以优先做三件事。第一补充检索增强生成能力让模型在生成内容时能引用 Notion 知识库里的真实产品文档减少幻觉。第二把单条线索的分析升级为批量并发处理并引入任务队列让整个流程可以定时自动跑。第三搭建一个简单的评估脚本把每次人工修正的结果沉淀下来逐步优化提示词和模型选择。这套方案的价值不在于代码多复杂而在于你真正理解了AI 不是悬在业务之上的魔法而是嵌在业务系统里的一个可靠组件。希望这篇文章能帮你迈出实战的第一步。如果你在自己的环境里跑通了也遇到了其他问题欢迎在评论里一起讨论。