1. 销售运营的报告地狱为什么 CRM 数据躺在那里周报还是要写两小时如果你在销售运营岗待过一定熟悉这个画面周五下午四点CRM 里躺着本周的线索、商机、成交记录飞书群里散落着跟进纪要脑子里有一堆判断但周报模板还是一片空白。然后你开始复制粘贴、翻聊天记录、回忆上周数字一两个小时就这么没了。这件事的本质不是写作能力问题而是一个典型的信息汇聚 结构化输出任务把分散在 CRM、聊天记录、邮件里的数据按固定模板组织成一份有洞察的文档。它完全应该被自动化。我这次要交付的是一个可落地的销售周报/月报生成 Skill技术栈是 CRM 数据 RAG 历史召回 模板生成底层统一走 TaoToken 的 API 通道。适合谁销售运营、销售主管、以及想给团队做内部 Agent 工具的同学。读完你能拿到可复制的config.toml与settings.json骨架、TaoToken 统一 Key 接入步骤、以及用样例 CRM 数据跑通周报生成并校验 RAG 召回结果的完整验证动作。先说清楚为什么 RAG 在这个场景里不是锦上添花。没有 RAG你生成的报告只是一次性填空——本周新增 12 家客户这句话模型不知道上周是 9 家还是 15 家写不出环比Q3 跟进的大客户终于进入采购流程这种语境继承更是无从谈起。RAG 让报告有记忆这才是它和套模板填空的分水岭。2. TaoToken 前置统一 Key 与 API 通道把模型调用从业务里剥出来在动手写 Skill 之前先把模型调用这一层处理干净。销售报告生成会用到 LLM 做结构化输出可能还会用到 embedding 做 RAG 向量化如果每个环节各自管一套 Key、各自处理不同厂商的接口差异代码会很快变成一团乱麻。TaoToken 在这里的角色是统一 API 通道一个 Key、一套 OpenAI 兼容接口覆盖对话模型和 embedding 模型。你不需要在业务代码里区分这个请求走哪家只需要在配置里声明模型名。接入入口如下按需取用官网与账号https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基地址代码里填这个https://taotoken.net/api模型对话调试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注意API 基地址统一用https://taotoken.net/api不要带 UTM 参数否则部分 SDK 会把它当成路径的一部分导致 404。拿到 Key 之后先别急着写 Skill用一条最小请求确认通道是通的。这一步能帮你排除掉后面 80% 的到底是模型问题还是网络问题的扯皮。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 回复 OK 两个字母即可}], max_tokens: 10 }返回里能看到choices[0].message.content就说明通道没问题。接下来所有配置都围绕这个基地址展开。3. 可复制配置config.toml 与 settings.json 骨架Skill 的配置分两层config.toml管运行时的模型、RAG、CRM 连接参数settings.json管 Skill 的输入输出契约和模板选择。分开的原因是前者随环境变测试/生产不同 Key后者随业务变模板迭代混在一起每次改模板都要动环境配置很容易出事。先看config.toml# config.toml - 运行时配置 [llm] # 统一走 TaoToken 通道 base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} # 从环境变量读取不要硬编码 model gpt-4o embedding_model text-embedding-3-small max_tokens 4096 temperature 0.3 # 报告生成要稳定温度压低 [rag] enabled true vector_store chroma collection sales_reports persist_dir ./data/chroma recent_weeks 4 # 优先召回最近 4 周 top_k 5 time_weight 0.6 # 时间权重 vs 语义相关度 [crm] provider custom # salesforce / hubspot / wecom_crm / custom api_endpoint ${CRM_API_ENDPOINT} auth_token ${CRM_AUTH_TOKEN} timeout_seconds 15 retry 2 [report] default_template standard output_format markdown再看settings.json它定义 Skill 的输入契约和模板结构{ skill_id: sales-report-generator, version: 2.1.0, inputs: { report_type: { type: string, enum: [weekly, monthly] }, report_period: { type: object, required: [start_date, end_date] }, author: { type: object, required: [name, team] }, raw_data: { type: object, description: 离线模式预处理好的业务数据提供时跳过 CRM 拉取 }, crm_connection: { type: object, description: 在线模式提供时走 CRM API 拉数据 }, template_id: { type: string, enum: [standard, executive_summary, deep_dive, kpi_focused], default: standard } }, templates: { standard: { sections: [ 本周核心数据, 重点客户进展, 主要活动回顾, 下周计划, 需要支持的事项 ] }, kpi_focused: { sections: [ KPI 达成情况, 差距分析, 关键动作与结果, 风险预警 ] } } }这里有个设计取舍值得说raw_data和crm_connection二选一。在线模式自动化程度高但耦合了 CRM 的可用性离线模式更灵活能处理那些没有 API 的数据源比如导出的 Excel。两种都支持同一个 Skill 既能进定时任务也能被销售手动触发。4. 跑通验证用样例 CRM 数据生成周报并校验 RAG 召回配置就绪后用一份样例数据把整条链路跑通。这一步的目标不是生成一份漂亮报告而是验证三件事数据是否正确注入、模板字段是否齐全、RAG 是否真的召回了历史上下文。先准备样例输入{ report_type: weekly, report_period: { start_date: 2026-01-13, end_date: 2026-01-17 }, author: { name: 张伟, team: 华北销售一组 }, template_id: standard, raw_data: { new_leads: [ { name: 李总, company: ABC科技, source: 展会, potential_value: 200000 } ], deals_updated: [ { deal_name: XYZ集团ERP采购, stage_from: 需求确认, stage_to: 方案评审, amount: 500000, note: 客户对价格敏感需准备阶梯报价 } ], deals_closed_won: [ { deal_name: DEF工厂MES系统, amount: 180000, customer: DEF制造 } ], activities_summary: { calls: 23, meetings: 6, demos: 2, emails_sent: 41 } } }调用 Skill 的核心逻辑Python 伪代码重点看数据流import os, json, requests BASE https://taotoken.net/api HEADERS { Authorization: fBearer {os.environ[TAOTOKEN_API_KEY]}, Content-Type: application/json } def build_prompt(payload, rag_context): return f你是销售运营报告助手。基于以下数据生成周报。 数据{json.dumps(payload[raw_data], ensure_asciiFalse)} 历史上下文用于环比和语境继承{rag_context} 要求按模板 sections 输出缺失数据在末尾列出 warnings。 def generate_report(payload, rag_context): body { model: gpt-4o, messages: [{role: user, content: build_prompt(payload, rag_context)}], temperature: 0.3 } r requests.post(f{BASE}/v1/chat/completions, headersHEADERS, jsonbody, timeout60) r.raise_for_status() return r.json()[choices][0][message][content] report generate_report(payload) print(report)跑通后重点做两个校验动作。校验一模板字段完整性。把生成的报告按settings.json里的 sections 逐项对照看本周核心数据重点客户进展主要活动回顾下周计划需要支持的事项是否都在。缺项通常意味着 Prompt 里模板描述不够明确或者数据里对应字段为空但没进 warnings。校验二RAG 召回结果。这一步最容易被跳过但恰恰是报告质量的关键。在生成前先单独调一次检索把召回的片段打印出来def debug_rag(query_text, top_k5): # 用 TaoToken 的 embedding 接口向量化查询 emb requests.post(f{BASE}/v1/embeddings, headersHEADERS, json{ model: text-embedding-3-small, input: query_text }).json()[data][0][embedding] # 从 chroma 检索此处省略客户端初始化 results collection.query(query_embeddings[emb], n_resultstop_k) for doc, dist in zip(results[documents][0], results[distances][0]): print(f[dist{dist:.3f}] {doc[:120]}) debug_rag(XYZ集团ERP采购 方案评审 价格敏感)如果召回的全是无关片段先检查collection里是否真的写入了历史报告——RAG 冷启动阶段前几周召回质量差是正常的随着报告积累会明显改善。建议在 metadata 里记录每次生成是否成功召回有效上下文用这个指标追踪冷启动进度。5. 本篇常见错排查从 401 到召回为空逐个击破报错 401 Unauthorized。九成是 Key 没读到。检查TAOTOKEN_API_KEY环境变量是否在当前 shell 生效echo $TAOTOKEN_API_KEY确认非空。如果是 Docker 或定时任务里跑注意环境变量不会自动继承要在启动脚本里显式传入。报错 404 Not Found。大概率是 base_url 写错了。正确写法是https://taotoken.net/api然后请求路径拼/v1/chat/completions。如果你把 base_url 写成带/v1的再拼/v1/...就会变成/v1/v1/...。另外确认 base_url 没带 UTM 参数。报告生成成功但字段缺失。先看raw_data里对应字段是不是空数组。空数组不会报错但模型会跳过该 section。解决办法是在 Prompt 里明确要求数据为空的 section 也要保留标题并标注本周无记录。RAG 召回为空或全是无关内容。三个检查点一是collection名称是否和写入时一致二是 embedding 模型是否和写入时用的是同一个换模型会导致向量空间不匹配检索全乱三是top_k和time_weight是否合理time_weight太高会让近期但无关的报告挤掉真正相关的历史片段。生成内容里出现上周数据但明显不对。这是 RAG 召回了错误的历史片段。在 Prompt 里加一句约束环比数据必须来自提供的 rag_context不得自行推断能显著降低这类幻觉。CRM 在线模式超时。timeout_seconds默认 15 秒部分 CRM 的报表接口很慢。建议把拉数据和生成报告拆成两步先拉数据落盘再从落盘数据生成这样超时不会导致整条链路重跑。6. 把 Skill 接进你的工作流从手动触发到定时任务跑通之后落地方式取决于你的团队习惯。销售个人用可以做成一个手动触发的脚本周五下午跑一次输出 Markdown 直接贴进周报系统。团队用可以挂到定时任务上每周五 17:00 自动拉 CRM 数据、生成报告、推送到飞书群。如果你打算长期维护这套东西甚至让它参与更复杂的编码和 Agent 流程可以了解一下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content模型选型上报告生成建议用gpt-4o或claude-3-5-sonnet这类长上下文模型因为要同时塞进 CRM 数据、RAG 上下文和模板描述上下文长度不够会截断。embedding 用text-embedding-3-small就够性价比高。想对比不同模型在这个场景下的输出质量可以直接在模型对话页调试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content最后说一个我踩过的坑模板设计是报告质量的核心变量但别指望在配置里写一堆描述性规则就能让模型写出好报告。更有效的做法是拿几份团队里公认写得好的历史周报作为 few-shot 示例注入 Prompt——模型学样本比学规则快得多。这件事值得在 Skill 上线第一周就做能省掉后面大量的调 Prompt 时间。 销售运营必备：自动写周报_月报Skill（CRM+RAG+模板）配 TaoToken 实战
1. 销售运营的报告地狱为什么 CRM 数据躺在那里周报还是要写两小时如果你在销售运营岗待过一定熟悉这个画面周五下午四点CRM 里躺着本周的线索、商机、成交记录飞书群里散落着跟进纪要脑子里有一堆判断但周报模板还是一片空白。然后你开始复制粘贴、翻聊天记录、回忆上周数字一两个小时就这么没了。这件事的本质不是写作能力问题而是一个典型的信息汇聚 结构化输出任务把分散在 CRM、聊天记录、邮件里的数据按固定模板组织成一份有洞察的文档。它完全应该被自动化。我这次要交付的是一个可落地的销售周报/月报生成 Skill技术栈是 CRM 数据 RAG 历史召回 模板生成底层统一走 TaoToken 的 API 通道。适合谁销售运营、销售主管、以及想给团队做内部 Agent 工具的同学。读完你能拿到可复制的config.toml与settings.json骨架、TaoToken 统一 Key 接入步骤、以及用样例 CRM 数据跑通周报生成并校验 RAG 召回结果的完整验证动作。先说清楚为什么 RAG 在这个场景里不是锦上添花。没有 RAG你生成的报告只是一次性填空——本周新增 12 家客户这句话模型不知道上周是 9 家还是 15 家写不出环比Q3 跟进的大客户终于进入采购流程这种语境继承更是无从谈起。RAG 让报告有记忆这才是它和套模板填空的分水岭。2. TaoToken 前置统一 Key 与 API 通道把模型调用从业务里剥出来在动手写 Skill 之前先把模型调用这一层处理干净。销售报告生成会用到 LLM 做结构化输出可能还会用到 embedding 做 RAG 向量化如果每个环节各自管一套 Key、各自处理不同厂商的接口差异代码会很快变成一团乱麻。TaoToken 在这里的角色是统一 API 通道一个 Key、一套 OpenAI 兼容接口覆盖对话模型和 embedding 模型。你不需要在业务代码里区分这个请求走哪家只需要在配置里声明模型名。接入入口如下按需取用官网与账号https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基地址代码里填这个https://taotoken.net/api模型对话调试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注意API 基地址统一用https://taotoken.net/api不要带 UTM 参数否则部分 SDK 会把它当成路径的一部分导致 404。拿到 Key 之后先别急着写 Skill用一条最小请求确认通道是通的。这一步能帮你排除掉后面 80% 的到底是模型问题还是网络问题的扯皮。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 回复 OK 两个字母即可}], max_tokens: 10 }返回里能看到choices[0].message.content就说明通道没问题。接下来所有配置都围绕这个基地址展开。3. 可复制配置config.toml 与 settings.json 骨架Skill 的配置分两层config.toml管运行时的模型、RAG、CRM 连接参数settings.json管 Skill 的输入输出契约和模板选择。分开的原因是前者随环境变测试/生产不同 Key后者随业务变模板迭代混在一起每次改模板都要动环境配置很容易出事。先看config.toml# config.toml - 运行时配置 [llm] # 统一走 TaoToken 通道 base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} # 从环境变量读取不要硬编码 model gpt-4o embedding_model text-embedding-3-small max_tokens 4096 temperature 0.3 # 报告生成要稳定温度压低 [rag] enabled true vector_store chroma collection sales_reports persist_dir ./data/chroma recent_weeks 4 # 优先召回最近 4 周 top_k 5 time_weight 0.6 # 时间权重 vs 语义相关度 [crm] provider custom # salesforce / hubspot / wecom_crm / custom api_endpoint ${CRM_API_ENDPOINT} auth_token ${CRM_AUTH_TOKEN} timeout_seconds 15 retry 2 [report] default_template standard output_format markdown再看settings.json它定义 Skill 的输入契约和模板结构{ skill_id: sales-report-generator, version: 2.1.0, inputs: { report_type: { type: string, enum: [weekly, monthly] }, report_period: { type: object, required: [start_date, end_date] }, author: { type: object, required: [name, team] }, raw_data: { type: object, description: 离线模式预处理好的业务数据提供时跳过 CRM 拉取 }, crm_connection: { type: object, description: 在线模式提供时走 CRM API 拉数据 }, template_id: { type: string, enum: [standard, executive_summary, deep_dive, kpi_focused], default: standard } }, templates: { standard: { sections: [ 本周核心数据, 重点客户进展, 主要活动回顾, 下周计划, 需要支持的事项 ] }, kpi_focused: { sections: [ KPI 达成情况, 差距分析, 关键动作与结果, 风险预警 ] } } }这里有个设计取舍值得说raw_data和crm_connection二选一。在线模式自动化程度高但耦合了 CRM 的可用性离线模式更灵活能处理那些没有 API 的数据源比如导出的 Excel。两种都支持同一个 Skill 既能进定时任务也能被销售手动触发。4. 跑通验证用样例 CRM 数据生成周报并校验 RAG 召回配置就绪后用一份样例数据把整条链路跑通。这一步的目标不是生成一份漂亮报告而是验证三件事数据是否正确注入、模板字段是否齐全、RAG 是否真的召回了历史上下文。先准备样例输入{ report_type: weekly, report_period: { start_date: 2026-01-13, end_date: 2026-01-17 }, author: { name: 张伟, team: 华北销售一组 }, template_id: standard, raw_data: { new_leads: [ { name: 李总, company: ABC科技, source: 展会, potential_value: 200000 } ], deals_updated: [ { deal_name: XYZ集团ERP采购, stage_from: 需求确认, stage_to: 方案评审, amount: 500000, note: 客户对价格敏感需准备阶梯报价 } ], deals_closed_won: [ { deal_name: DEF工厂MES系统, amount: 180000, customer: DEF制造 } ], activities_summary: { calls: 23, meetings: 6, demos: 2, emails_sent: 41 } } }调用 Skill 的核心逻辑Python 伪代码重点看数据流import os, json, requests BASE https://taotoken.net/api HEADERS { Authorization: fBearer {os.environ[TAOTOKEN_API_KEY]}, Content-Type: application/json } def build_prompt(payload, rag_context): return f你是销售运营报告助手。基于以下数据生成周报。 数据{json.dumps(payload[raw_data], ensure_asciiFalse)} 历史上下文用于环比和语境继承{rag_context} 要求按模板 sections 输出缺失数据在末尾列出 warnings。 def generate_report(payload, rag_context): body { model: gpt-4o, messages: [{role: user, content: build_prompt(payload, rag_context)}], temperature: 0.3 } r requests.post(f{BASE}/v1/chat/completions, headersHEADERS, jsonbody, timeout60) r.raise_for_status() return r.json()[choices][0][message][content] report generate_report(payload) print(report)跑通后重点做两个校验动作。校验一模板字段完整性。把生成的报告按settings.json里的 sections 逐项对照看本周核心数据重点客户进展主要活动回顾下周计划需要支持的事项是否都在。缺项通常意味着 Prompt 里模板描述不够明确或者数据里对应字段为空但没进 warnings。校验二RAG 召回结果。这一步最容易被跳过但恰恰是报告质量的关键。在生成前先单独调一次检索把召回的片段打印出来def debug_rag(query_text, top_k5): # 用 TaoToken 的 embedding 接口向量化查询 emb requests.post(f{BASE}/v1/embeddings, headersHEADERS, json{ model: text-embedding-3-small, input: query_text }).json()[data][0][embedding] # 从 chroma 检索此处省略客户端初始化 results collection.query(query_embeddings[emb], n_resultstop_k) for doc, dist in zip(results[documents][0], results[distances][0]): print(f[dist{dist:.3f}] {doc[:120]}) debug_rag(XYZ集团ERP采购 方案评审 价格敏感)如果召回的全是无关片段先检查collection里是否真的写入了历史报告——RAG 冷启动阶段前几周召回质量差是正常的随着报告积累会明显改善。建议在 metadata 里记录每次生成是否成功召回有效上下文用这个指标追踪冷启动进度。5. 本篇常见错排查从 401 到召回为空逐个击破报错 401 Unauthorized。九成是 Key 没读到。检查TAOTOKEN_API_KEY环境变量是否在当前 shell 生效echo $TAOTOKEN_API_KEY确认非空。如果是 Docker 或定时任务里跑注意环境变量不会自动继承要在启动脚本里显式传入。报错 404 Not Found。大概率是 base_url 写错了。正确写法是https://taotoken.net/api然后请求路径拼/v1/chat/completions。如果你把 base_url 写成带/v1的再拼/v1/...就会变成/v1/v1/...。另外确认 base_url 没带 UTM 参数。报告生成成功但字段缺失。先看raw_data里对应字段是不是空数组。空数组不会报错但模型会跳过该 section。解决办法是在 Prompt 里明确要求数据为空的 section 也要保留标题并标注本周无记录。RAG 召回为空或全是无关内容。三个检查点一是collection名称是否和写入时一致二是 embedding 模型是否和写入时用的是同一个换模型会导致向量空间不匹配检索全乱三是top_k和time_weight是否合理time_weight太高会让近期但无关的报告挤掉真正相关的历史片段。生成内容里出现上周数据但明显不对。这是 RAG 召回了错误的历史片段。在 Prompt 里加一句约束环比数据必须来自提供的 rag_context不得自行推断能显著降低这类幻觉。CRM 在线模式超时。timeout_seconds默认 15 秒部分 CRM 的报表接口很慢。建议把拉数据和生成报告拆成两步先拉数据落盘再从落盘数据生成这样超时不会导致整条链路重跑。6. 把 Skill 接进你的工作流从手动触发到定时任务跑通之后落地方式取决于你的团队习惯。销售个人用可以做成一个手动触发的脚本周五下午跑一次输出 Markdown 直接贴进周报系统。团队用可以挂到定时任务上每周五 17:00 自动拉 CRM 数据、生成报告、推送到飞书群。如果你打算长期维护这套东西甚至让它参与更复杂的编码和 Agent 流程可以了解一下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content模型选型上报告生成建议用gpt-4o或claude-3-5-sonnet这类长上下文模型因为要同时塞进 CRM 数据、RAG 上下文和模板描述上下文长度不够会截断。embedding 用text-embedding-3-small就够性价比高。想对比不同模型在这个场景下的输出质量可以直接在模型对话页调试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content最后说一个我踩过的坑模板设计是报告质量的核心变量但别指望在配置里写一堆描述性规则就能让模型写出好报告。更有效的做法是拿几份团队里公认写得好的历史周报作为 few-shot 示例注入 Prompt——模型学样本比学规则快得多。这件事值得在 Skill 上线第一周就做能省掉后面大量的调 Prompt 时间。