核心结论
经营月报 Agent 的第一版不是万能 BI，也不是财务自动结论机。它要先跑通一条可复核链路：经营问题 -> 数据来源 -> 指标计算 -> 证据包 -> 月报判断 -> 人审 -> 下月行动。
角色分工
Agent编排流程、检查输入、调用脚本、判断是否停止。
Skill固化目录、口径、步骤、停止条件和复核清单。
Python / SQL负责清洗、关联、计算、同比环比、异常和图表。
大模型 + 人模型写判断和表达；人确认财务、客户承诺和资源决策。
月报要回答什么
| 管理问题 | 月报判断 | 证据不足时 |
|---|---|---|
| 经营规模有没有增长 | 收入、回款、订单、项目交付、上线餐厅是否变化 | 标为待补证，不用形容词替代数字 |
| 增长或回落来自哪里 | 项目、客户、产品包、区域、业务线或渠道贡献 | 只写可追溯来源，不做营销归因猜测 |
| 增长质量怎么样 | 毛利、回款、复用率、验收、返工、缺陷、满意度 | 缺口径时只写过程风险 |
| 最大风险是什么 | 履约延期、验收卡点、客户承诺、产品缺口、数据异常 | 拆到 owner 和下月动作 |
| 下月先做什么 | 3-5 个可验收行动 | 不写“持续优化”这类空话 |
第一版 MVP
| 阶段 | 目标 | 输出 |
|---|---|---|
| Day 0 | 锁定报告月份、读者、用途和 reviewer | monthly-report-contract.md |
| Day 1 | 收集核心数据源并登记证据等级 | source-index.csv |
| Day 2 | 定义收入、回款、项目、产品、AI 提效等口径 | metric-dictionary.csv |
| Day 3 | 程序化生成指标、异常、图表和质量报告 | evidence-pack.json / quality-report.md |
| Day 4 | 大模型只读证据包，写经营诊断草稿 | business-monthly-report-draft.md |
| Day 5 | 人工复核关键口径和行动项 | business-monthly-report.html / action-backlog.csv |
证据包形态
证据包要小而硬，像审计底稿，而不是原始明细堆叠。
{
"report_month": "YYYY-MM",
"data_quality": {
"status": "review_ready",
"warnings": ["财务毛利缺少最终确认"]
},
"core_metrics": [],
"growth_drivers": [],
"risk_signals": [],
"action_candidates": []
}
输出结构
- 一句话经营结论
- 本月经营结果
- 增长与回落拆解
- 增长质量与履约风险
- 产品策略推进
- 问题复盘
- 下月行动清单
- 需要人工拍板的问题
停止条件
报告月份不明确、关键财务数据无来源、同比环比不可比、异常数据未处理、模型写无证据归因、涉及客户承诺或合同金额未经确认时，只能输出待补证草案，不能输出正式月报。
数科业务第一版建议
第一个试点建议选“数字技术中心 / 数科业务经营月报 MVP”，先跟踪六条线：
| 追踪线 | 第一版关注点 |
|---|---|
| 经营结果 | 收入、回款、合同、应收，只写已确认口径 |
| 项目闭环 | 上线、验收、延期、阻塞、客户反馈 |
| 产品标准化 | 标准包、演示包、手册、测试用例、控标证据 |
| 智慧食堂业务 | 订单、消费、设备、食安、营养、经营报表 |
| 售前转化 | 重点商机、招投标、样板客户、下一步动作 |
| AI Native 提效 | 可复用文档、Skill、自动化、一次通过率和返工率样本 |