ChatGLM-6B实战案例：用Python调用API实现自动化报告生成流程

ChatGLM-6B实战案例：用Python调用API实现自动化报告生成流程

1. 为什么需要自动化报告生成？

你有没有遇到过这样的场景：每周五下午三点，准时打开Excel整理数据，复制粘贴十几张图表，再花一小时写一段千篇一律的“整体趋势向好，部分指标需关注”的总结？最后赶在下班前把PDF发给领导，心里却清楚——这份报告里真正有价值的洞察，可能只有一句话。

人工撰写周期长、格式易错、重复劳动多、响应速度慢。而业务部门的需求却越来越快：市场部要实时同步竞品动态，运营团队需要每小时更新用户行为摘要，管理层希望晨会前就看到带关键建议的一页纸简报。

这时候，一个能理解业务逻辑、熟悉行业术语、还能按固定模板输出专业文字的AI助手，就不是锦上添花，而是刚需。

ChatGLM-6B 就是这样一个靠谱的选择。它不是那种“什么都懂一点、但什么都说不深”的通用模型，而是专为中文场景打磨过的双语对话模型——对“环比增长”“GMV拆解”“DAU留存漏斗”这类业务词汇的理解准确度高，生成内容结构清晰、语气得体、极少胡编乱造。更重要的是，它已经封装成稳定服务，你不需要从零搭环境、下权重、调参数，只要几行Python代码，就能把它变成你团队里的“文字自动化引擎”。

下面我们就用一个真实可运行的案例，带你从零搭建一套每日销售日报自动生成系统：输入当天的销售数据摘要，自动输出含分析、归因和建议的完整报告段落，并支持导出为Markdown或直接插入企业微信/钉钉消息。

2. 环境准备与服务确认

在调用API前，先确认本地已成功连接并启动了ChatGLM-6B服务。根据镜像说明，该服务默认通过Gradio提供WebUI（端口7860），但我们要用Python程序调用，所以需要确认其后端API是否已启用。

好消息是：这个CSDN镜像不仅开箱即用，还默认启用了标准的FastAPI接口服务（监听在http://127.0.0.1:8000），无需额外配置。你可以用curl快速验证：

curl -X POST "http://127.0.0.1:8000/chat" \ -H "Content-Type: application/json" \ -d '{ "query": "你好", "history": [] }'

如果返回类似{"response":"你好！有什么我可以帮您的吗？","history":[["你好","你好！有什么我可以帮您的吗？"]],"status":200}的JSON，说明服务已就绪。

小提示：如果你是在远程GPU服务器上部署，记得用SSH隧道将8000端口也映射到本地：

ssh -L 8000:127.0.0.1:8000 -L 7860:127.0.0.1:7860 -p <端口号> root@gpu-xxxxx.ssh.gpu.csdn.net

我们不需要修改任何配置文件，也不用碰Supervisor命令——只要服务状态是RUNNING，API就随时待命。

3. 构建你的第一个自动化报告函数

现在，我们来写一个真正能干活的Python函数。它接收一个结构化的销售数据字典，调用ChatGLM-6B API，生成一段专业、简洁、带业务洞见的日报正文。

3.1 安装依赖与基础封装

新建一个report_generator.py，先安装最轻量的依赖：

pip install requests

然后定义核心调用函数。注意：我们不使用复杂框架，只用原生requests，确保最小依赖、最高兼容性：

import requests import json from typing import Dict, List, Optional def call_chatglm_api( query: str, history: List[List[str]] = None, temperature: float = 0.3, max_length: int = 512 ) -> Optional[str]: """ 调用ChatGLM-6B本地API生成文本 :param query: 当前提问内容（即报告需求描述） :param history: 对话历史，用于多轮上下文（本例中暂不使用） :param temperature: 创意控制（0.1~0.5适合报告类严谨输出） :param max_length: 最大生成长度 :return: 模型返回的文本内容，失败时返回None """ if history is None: history = [] url = "http://127.0.0.1:8000/chat" payload = { "query": query, "history": history, "temperature": temperature, "max_length": max_length } try: response = requests.post(url, json=payload, timeout=60) response.raise_for_status() result = response.json() return result.get("response", "").strip() except requests.exceptions.RequestException as e: print(f" API调用失败：{e}") return None except json.JSONDecodeError as e: print(f" 响应解析失败：{e}") return None

这段代码做了三件关键事：

• 用标准POST请求对接FastAPI接口；
• 设置了合理的超时（60秒）和错误捕获，避免程序卡死；
• 对返回结果做健壮性处理，即使API返回异常格式也能安全退出。

3.2 设计提示词：让AI写出“人话”报告

很多开发者卡在第一步：为什么我问“写个日报”，它回“好的，以下是日报”，然后就没了？问题不在模型，而在提示词（Prompt）设计。

ChatGLM-6B擅长遵循指令，但需要你明确告诉它：角色、任务、格式、禁忌。我们为销售日报专门设计了一段结构化提示词：

def generate_sales_daily_report(data: Dict) -> str: """ 根据销售数据字典，生成专业日报段落 :param data: 包含key: 'date', 'total_gmv', 'new_users', 'conversion_rate', 'top_product' """ prompt = f"""你是一位资深电商运营分析师，正在为管理层撰写每日销售简报。 请严格按以下要求输出： 1. 仅输出一段连贯文字，不加标题、不加编号、不加空行； 2. 开头用【{data['date']}销售简报】起始； 3. 必须包含三部分：①核心指标表现（GMV、新客、转化率）；②1个关键归因（结合top_product）；③1条可执行建议； 4. 语言精炼、客观、有数据支撑，避免“可能”“大概”等模糊表述； 5. 禁止虚构未提供的数据，禁止使用emoji和特殊符号。 今日数据： - 日期：{data['date']} - 总GMV：{data['total_gmv']}万元（较昨日+{data.get('gmv_change', 'N/A')}%） - 新增用户：{data['new_users']}人（较昨日+{data.get('user_change', 'N/A')}%） - 整体转化率：{data['conversion_rate']}% - 爆款商品：{data['top_product']}（销量占比{data.get('top_ratio', 'N/A')}%） """ result = call_chatglm_api(prompt, temperature=0.2) return result or " 报告生成失败，请检查服务状态或重试。" # 测试调用 if __name__ == "__main__": sample_data = { "date": "2024-06-15", "total_gmv": 286.5, "new_users": 1247, "conversion_rate": 3.2, "top_product": "无线降噪耳机Pro", "gmv_change": 12.3, "user_change": 8.7, "top_ratio": 24.1 } report = generate_sales_daily_report(sample_data) print(report)

运行后，你可能会看到类似这样的输出：

【2024-06-15销售简报】今日总GMV达286.5万元，环比提升12.3%，新增用户1247人，环比增长8.7%，整体转化率3.2%。爆款商品“无线降噪耳机Pro”贡献显著，销量占比24.1%，成为拉动GMV增长的核心驱动力。建议明日加大该单品在首页焦点图的曝光权重，并同步推送配套优惠券，进一步撬动转化。

看，这不是模板填空，而是基于数据逻辑的主动归纳——这正是ChatGLM-6B在中文业务语境下的真实能力。

4. 进阶：构建可复用的报告流水线

单次调用只是开始。真正的自动化，是把“数据输入→AI加工→结果分发”串成一条无人值守的流水线。我们来升级这个脚本，让它具备生产级能力。

4.1 支持多种报告类型

不同部门需要不同报告。我们把提示词逻辑抽离成配置，用字典管理不同模板：

REPORT_TEMPLATES = { "sales_daily": { "role": "电商运营分析师", "sections": ["核心指标", "归因分析", "执行建议"], "prompt": """你是一位资深电商运营分析师...（同上，略）""" }, "customer_service": { "role": "客服主管", "sections": ["问题分类统计", "TOP3投诉原因", "流程优化建议"], "prompt": """你是一位客服主管，正在汇总今日用户反馈... - 今日共受理咨询{total_tickets}例，其中{complaint_ratio}%为投诉类； - 投诉集中于：{top_issue1}（{ratio1}%）、{top_issue2}（{ratio2}%）、{top_issue3}（{ratio3}%）； 请据此生成一段简明日报，聚焦可落地的改进点。""" } } def generate_report(report_type: str, data: Dict) -> str: template = REPORT_TEMPLATES.get(report_type) if not template: return f" 不支持的报告类型：{report_type}" # 动态填充prompt中的占位符 filled_prompt = template["prompt"].format(**data) return call_chatglm_api(filled_prompt, temperature=0.25)

这样，只需传入report_type="customer_service"和对应字段，就能生成客服日报，无需重写逻辑。

4.2 自动化调度与错误重试

用Python内置的schedule库，轻松实现每日定时执行（无需部署cron）：

import schedule import time import logging # 配置日志 logging.basicConfig( level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s', handlers=[logging.FileHandler('report.log'), logging.StreamHandler()] ) def run_daily_report(): try: data = fetch_today_sales_data() # 你的数据获取函数 report = generate_sales_daily_report(data) # 保存为Markdown文件 with open(f"daily_report_{data['date']}.md", "w", encoding="utf-8") as f: f.write(f"# {data['date']} 销售日报\n\n{report}\n") # 同时推送到企业微信（示例，需替换webhook） send_to_workwx(report, data['date']) logging.info(f" {data['date']}日报生成并推送成功") except Exception as e: logging.error(f" 日报生成失败：{e}") # 每天上午8:30执行 schedule.every().day.at("08:30").do(run_daily_report) if __name__ == "__main__": logging.info("日报服务已启动，等待执行...") while True: schedule.run_pending() time.sleep(60) # 每分钟检查一次

关键细节：我们加入了日志记录、文件保存、多通道分发（文件+消息），且所有异常都被捕获，不会导致整个进程退出。

5. 实战效果与避坑指南

我们已在某中型电商团队实际运行这套方案2周，以下是真实反馈和关键经验：

5.1 效果对比（真实数据）

最意外的收获是：运营同事开始把AI生成的初稿当作“思考起点”，在基础上补充自己的判断，反而提升了报告深度。

5.2 你一定会遇到的3个典型问题及解法

问题1：生成内容偶尔重复或跑题
→解法：降低temperature至0.1–0.25，并在提示词末尾加一句硬约束：“请严格控制在180字以内，且必须覆盖全部三个指定部分。”

问题2：对数字敏感度不足（如把‘23.5%’写成‘约24%’）
→解法：在数据传入前做预处理，用字符串而非浮点数传递关键数值：“'conversion_rate': '23.5%'”，并在提示词中强调“原文照搬所有数字，禁止四舍五入或改写”。

问题3：多轮对话时历史记录膨胀，影响性能
→解法：不依赖API的history参数，改为在Python层维护精简的上下文。例如只保留最近2轮问答，且用[Q]xxx [A]yyy格式压缩，长度超200字符则截断。

这些都不是模型缺陷，而是工程化过程中的必经调试。每一次调整，都在让AI更贴合你的业务节奏。

6. 总结：让AI成为你工作流里的“静默协作者”

回顾整个流程，我们没有训练新模型，没有部署Kubernetes集群，甚至没写一行CUDA代码。只是用120行Python，把一个开箱即用的本地大模型，变成了每天准时交作业的“数字员工”。

它的价值不在于替代人，而在于释放人：把运营从机械的文字搬运中解放出来，去盯盘、做实验、跟用户聊天；让管理者不再花时间读报告，而是直接讨论“下一步怎么干”。

更重要的是，这套方法论完全可迁移——换成财务日报、产品周会纪要、技术故障复盘，只需更换提示词模板和数据源，几分钟就能上线。

AI落地最难的从来不是技术，而是找到那个“足够痛、足够高频、足够标准化”的切口。销售日报，就是这样一个完美的起点。

现在，你的自动化报告流水线已经就绪。接下来，只需要决定：明天早上8:30，第一份由ChatGLM-6B生成的日报，要发给谁？

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。