每周五下午写周报要两小时？我把SQL结果直接喂给AI，现在只花八分钟
一、那个让我头疼的周五下午
独立开发者和小团队应该都懂这种感觉：产品跑起来了，数据也积累起来了，但每周给合作方、给投资人、给自己看的运营周报，永远是最后才被想起来的一件事。
我之前的工作流是这样的：
- 打开数据库，手动跑五六条SQL——本周新增用户、活跃用户、订单量、GMV、留存率、Top 10商品；
- 把结果一条条复制到Excel里，算环比、算同比；
- 对着数字发呆十分钟，回忆“这周到底发生了什么”；
- 憋出几百字的周报文字，措辞还要反复调整——"下降"要不要写成“回落”？"暴涨"是不是太夸张了？
一套流程下来，平均耗时110到130分钟。最要命的不是时间，而是第3步：数字就在眼前，但我大脑已经疲劳了，写出来的东西经常是“本周数据如下”然后罗列一串数字——这不是周报，这是数字搬运。
我还试过让实习生帮忙写，结果培训成本比我自己写还高，而且她理解的业务口径和我总对不上。
二、AI在这里能替你做什么
转变的起点很简单：写周报这件事，本质上不是“创作”，而是“翻译”——把SQL查询结果翻译成人类能读懂、有重点、有上下文的文字。这恰恰是大模型最擅长的。
我把整个流程拆成了三段，AI承担了其中最重的两段：
第一段：解释数字。 我把SQL结果原样粘贴（或用脚本自动拉取）给AI，附上业务背景说明。AI会自动算环比、找异常值、指出“订单量涨了但客单价降了”这种我经常漏看的交叉信号。
第二段：起草周报文字。 AI根据我指定的格式和语气生成初稿——给投资人看的版本偏正式，给内部群的版本口语化一些，一键切换。
第三段：我来审核。 这一步不能省。AI偶尔会“过度解读”，比如把正常的周期性波动说成“显著增长趋势”，需要人工把关。但改初稿比从零写快十倍。
整套流程现在稳定在8到15分钟，其中大部分时间花在核对数字上——而这个核对动作本来就该做，以前自己写的时候反而经常省略。
三、具体怎么搭：三步走
第一步：固定你的SQL清单
不要每周临时想查什么。我建了一个固定的查询清单文件，每周跑一遍脚本，所有结果自动汇总成一个文本块。如果你用Python，sqlite3或者pymysql十几行代码就能搞定。
第二步：喂给AI，用提示词模板
这是整个方案的核心。提示词不精致，AI的输出就会飘。下面是我打磨过几轮的模板，可以直接复制修改：
你是一位数据分析顾问，请根据我提供的SQL查询结果，撰写一份数据周报。
## 业务背景
- 产品：{一句话描述你的产品，例如"一款面向大学生的二手书交易小程序"}
- 当前阶段：{例如"上线3个月，处于增长期"}
- 本周已知事件：{例如"周三开展了拉新活动"、"周五服务器故障2小时"，没有则写"无"}
## 数据口径说明
- 活跃用户定义：{例如"7日内有打开行为的不重复用户"}
- 时间范围：{本周起止日期}，对比上周同期
- 金额单位：元
## SQL查询结果（上周 / 本周）
新增用户：{数字} / {数字}
活跃用户：{数字} / {数字}
订单量：{数字} / {数字}
GMV：{数字} / {数字}
{其他指标照此格式追加}
## 输出要求
1. 结构：整体概览（2-3句）→ 亮点 → 需关注的问题 → 下周建议关注点
2. 所有百分比和环比数据请基于我提供的数字计算，禁止编造任何未提供的数据
3. 如果某指标波动超过±15%，必须单独解释可能原因；如果无法解释，明确写"原因待查"而不是猜测
4. 语气：{客观、克制，给内部团队看的周报}
5. 篇幅：400-600字
6. 数字保留与原始数据相同的精度，不要四舍五入到失真
先输出周报正文，再单独列出"本次数据中你无法解释的异常点"清单，方便我人工核查。模板里有两处是踩坑后加上的：一是“禁止编造数据”——早期AI偶尔会自己补一个“转化率约X%”，很吓人；二是最后的异常点清单，等于让AI自查一遍，每次都能帮我聚焦核对重点。
第三步：固化成半自动流程
我现在的做法是一个脚本：拉数据 → 拼提示词 → 调用大模型API → 输出到文档。API调用按token计费，一个月下来成本很低（具体价格以官网价格页为准），跟省下的时间比基本可以忽略。
四、前后对比：这笔账很清楚
| 项目 | 用AI之前 | 用AI之后 |
|---|---|---|
| 单次周报耗时 | 110-130分钟 | 8-15分钟 |
| 每月时间成本（按4周） | 约8小时 | 约1小时 |
| 漏看交叉异常的频率 | 每月至少2次 | 基本为0（AI主动标记） |
| 周报格式稳定性 | 看当天状态 | 高度一致 |
| 我的实际角色 | 搬运数字+写文字 | 只做审核和补充判断 |
按一个月算，省下大约7小时——差不多一整个工作日。对独立开发者来说，这7小时可以多写一个功能；对小团队来说，这意味着周报这件事不再需要“专人负责”。
还有一个意外收获：因为写周报的边际成本降到几乎为零，我从“周报”升级成了“日报”。每天早上花3分钟看一眼AI生成的数据摘要，很多问题发现得比以前早了三四天。
五、几个提醒
- 不要跳过审核环节。 AI生成的文字太流畅了，流畅到你容易忘了核对数字。我的习惯是抽查两三个关键数字和原文比对。
- 业务背景要写清楚。 同样是“订单量下降12%”，旺季和淡季的含义完全不同。背景信息给得越足，AI的解读越靠谱。
- 注意数据脱敏。 如果周报涉及用户个人信息，先在SQL层面做好聚合和脱敏，只喂聚合后的指标。
- 指标口径写进提示词。 “活跃用户”的定义歧义是数据周报最常见的翻车点，模板里专门留了这一节。
写在最后
数据周报这件事的痛点从来不是“不会写”，而是“不值得花那么多时间写”。把SQL结果到成稿之间的翻译工作交给AI，人只保留判断和审核，这个分工我认为是对的。
如果你想自己搭一套这样的流程，需要一个稳定的大模型API来支撑定时任务，可以试试这个平台的注册入口：https://api.thistoken.ai/register ——配好key之后，上面那个脚本模板改造一下就能跑起来，下周五下午的时间就能还给你自己了。
---
想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。