Sheet To Report

数据分析&汇报小助手

把一张业务表，变成有依据、讲得清、能行动的经营简报。

面向运营、销售、产品及业务负责人。提供一张结构清晰的 Excel／CSV 和汇报目标，由 AI 检查口径、寻找重点、补查依据、组织结论和行动建议；先生成可离线阅读的 HTML，按需继续制作可编辑标准 PPT，并可选择使用 SlideViber 美化。

30 秒了解

• 适合谁： 需要做周报、月报、活动复盘或阶段经营汇报的运营、销售、产品及业务负责人。
• 准备什么： 一张结构清晰的 Excel／CSV、汇报对象，以及希望解决的问题。
• 能得到什么： 一份可离线阅读的 HTML 分析简报；按需生成可编辑标准 PPT；还可选择单独安装 SlideViber 继续制作美化版。
• 怎样配合： 你负责提供数据和业务目标、确认必要口径；AI 负责检查、分析、组织结论和生成报告。
• 实际效果： 在线查看完整合成案例，包括 HTML、标准 PPT 与 SlideViber 美化版的同源对照。

第一次试用？跟着示例做一次：下载完全合成的10万行练习表，选择“直接分析”或“先确认方案”，照着步骤得到 HTML；需要汇报时再继续制作 PPT。

为什么选择 sheet-to-report

帮你看懂业务变化，串起汇报主线，也把下一步讲清楚。

• 抓住值得关注的问题——找问题

  围绕你的汇报目标，从表中寻找重要变化、机会和风险。发现异常后，在数据支持的范围内继续按时间、渠道、人群或商品细分核查，并选择合适的图表说明。

• 结论有依据，判断有边界——核依据

  先核对指标含义和比较范围，再组织结论。关键数字可以追溯到计算依据；数据不足时说明哪些还无法判断，避免把猜测当成事实。

• 把零散发现串成清楚的汇报主线——串主线

  将整体表现、关键变化、细分证据和经营含义逐层展开，让读者顺着“发生了什么—哪些因素值得关注—依据是什么—下一步怎么做”理解整份报告。图表与文字前后呼应，汇报时更容易让听众跟上。

• 建议具体到行动和验证——落行动

  说明针对哪个业务环节、建议怎么做、观察什么指标，以及什么情况下需要调整，帮助你把分析结果转成下一步工作安排。

• 一份分析，衔接阅读与汇报——出报告

  按需生成离线 HTML、可编辑标准 PPT，并可另行安装 SlideViber 进一步美化。三类产物沿用同一套分析依据，并校验关键数字、口径与结论的一致性。

开始前准备

先准备三样东西：

1. 已安装本 Skill，并且能读取文件、运行本地代码的 AI 工具。
2. 一张结构清晰的 Excel 或 CSV；当前一次分析一张表。
3. 汇报对象和希望解决的问题。不确定时可以先说“请帮我判断这张表适合回答什么问题”。

HTML 需要 Python 3.10+ 和本 Skill 所列依赖；标准 PPT 还需要 Node.js 18+、python-pptx 及可用的预览工具；SlideViber 需单独安装。让 AI 先检查环境即可，无需自己编写脚本或 JSON。单纯把 Skill 上传到平台，不代表该平台已经具备运行模型、读取文件和生成产物的完整条件。

若文件含姓名、手机号、邮箱、证件号或详细地址等个人信息，先删除、脱敏或改用合成数据。脚本本身不调用外部 API；承载 AI 的平台仍可能读取你上传的文件，请同时遵循所在平台的隐私政策。

从 Excel 到报告

确认次数取决于数据口径、开始方式、已有偏好和运行环境。AI 不应为走流程重复询问已经确认的内容。

两种开始方式

首次推荐：先确认分析方案

适合第一次使用、希望先确认时间范围、汇报重点和关键口径的情况。明确说“先给方案，等我确认后再生成”，AI 会先用短句给出分析范围、重点问题、必要待确认项和预计交付；你确认或修改后才开始生成正式 HTML。

请用 sheet-to-report 分析这份 Excel，面向业务负责人做月度复盘。先检查数据，用简短的方案告诉我：建议分析哪个时间范围、重点回答哪些业务问题、有哪些需要我确认的口径。等我确认后再生成 HTML 分析简报。完成后，请告诉我如何继续制作可编辑 PPT。

周报、活动复盘等场景可替换“月度复盘”和汇报对象。你可以这样回答方案：

按这个方案分析。重点看渠道效率；收入使用退款后的净收入。先只生成 HTML。

这只是回答形式示例，不是所有数据的默认口径。

已熟悉时：直接分析

适合目标和口径已经清楚、希望尽快得到结果的情况。明确说“直接分析，只确认影响结论的问题”，AI 不再额外等待整份方案批准；日期、指标分母、业务对象粒度等真实歧义仍会询问，不能猜测。

请用 sheet-to-report 直接分析这份 Excel，面向业务负责人做月度复盘。先检查字段和时间范围；遇到影响结论的口径不清时再向我确认。先生成 HTML，完成后告诉我如何继续制作可编辑 PPT。

Agent 执行时先运行与目标对应的环境预检；失败时保留已经通过的产物，并按快速帮助与故障定位用普通用户能理解的语言说明“卡在哪一步、影响什么、下一步做什么”。

使用前需要了解的内容到这里结束。 你可以上传文件，复制上面的指令开始。下面是供 AI 执行的详细规则，无需提前学习；AI 仍须完整遵守。

供 AI 执行的详细规则

开始前确认

先明确分析意图，避免把工程测试包装成业务结论：

• business_review：回答经营变化、结构驱动、风险与行动；正式 HTML 按有证据的业务问题组织章节，不预设页数。
• exploration：在已确认语义范围内探索可验证线索；证据不足的内容降级为带限制的假设。
• engineering_regression：只输出计算合同、数据质量与回归核验 dossier，不生成经营洞察或行动建议。

仅向用户呈现两种选择。用户未表明方式、也没有本次任务已确认的分析计划时，默认先给简短方案确认；明确要求直接分析或已有已确认方案时，不增加重复审批：

• 直接分析：自动扫描字段与少量预览；只采用高置信语义，存在歧义时返回结构化待确认问题。
• 确认分析计划：确认语义合同、分析问题、指标契约、受众、目标、维度、比较方式和主题后再执行。中置信字段只有在确认后才可使用，低置信字段始终需要确认。

确认分析计划时，面向用户只显示“分析范围、重点问题、必要待确认项、预计交付”四项短句；没有待确认项就明确写“无”。不要让用户填写 analysis_intent、JSON、脚本参数或其他内部合同。实验性分析画像等既有规则要求先确认时，即使用户说“直接分析”，也要说明原因后确认。

无论哪种模式，不能可靠判断时都要询问用户，不猜口径：

• 汇报目标、受众和 analysis_intent
• 周报或月报、日期字段、未完成周期策略
• 1–6 个核心指标及其单位、聚合方式、分子分母
• 0–4 个拆解维度
• 只要数据简报，还是同时需要可编辑 PPTX

先查看字段名和少量预览。可运行 python scripts/sheet_to_report.py --inspect path/to/data.xlsx 获取机器可读的候选字段与待确认问题。若发现姓名、手机号、邮箱、证件号、详细地址等个人信息，提示用户先删除、脱敏或改用合成数据。脚本本身不调用外部 API；运行它的 AI 平台仍可能读取用户提供的文件，应遵循所在平台的隐私政策。

受控混合分析链路

执行顺序固定为：

分析意图 → 语义能力与质量决定 → 分析简报 → 候选问题图 → 确定性计算与受控补查 → 决策章节 → 行动合同 → 内容 QA → HTML/PPT

• analysis_profile=auto 是默认入口。general、retail_growth 与 transactional_commerce 为 verified；content_operations 与 project_operations 为 experimental，必须经“确认分析计划”后在 general 执行层运行；unavailable 必须明确失败，不能伪装为通用分析成功。
• 交易表必须声明表粒度与订单、数量、单价等字段映射。销售域与客户域分开：缺客户 ID 的交易仍可保留在销售口径，但不得伪造匿名客户。
• 负数量、取消、退货、零价和异常价格分别记录数量、影响金额、规则与范围；任何排除都必须来自已确认的白名单规则，不能静默清洗。
• 新比率请求明确单行分母为零的处理。全量投入除以全量产出等总量比率使用 zero_denominator_policy=include_in_totals，保留零产出行的投入；仅汇总分母为零时不可计算。旧请求未指定时保留 exclude_row 兼容口径，不能把其数值当作全量成本效率。
• 分析问题只能从已确认的业务对象、字段、指标和时间覆盖中选择。确定性计算负责数字与公式，叙事层只能选择、排序和压缩证据，不得自创数字、公式、因果或行业基准。
• 高优先问题按“事实—驱动—细分—经营含义”记录 required_depth / achieved_depth。深度不足且仍有合法表内路径时必须继续受控补查；没有真实信息增量时降级，不能用非空文本冒充回答。
• 正文选择单位是业务章节，不是孤立指标或单条洞察。核心诊断应说明问题、判断、证据与经营含义；行动可由多个章节共同支持，背景章节无需制造行动。
• report_model.json 是一次生成的内容真相源，洞察、行动、图表均引用可解析的 evidence ID。新版 html-chapters/1 通过独立 chapter-presentation/1 接续标准PPT或SlideViber，不交给旧PPT消费者；旧模型只保留原兼容路径。

执行流程

1. 要求 Python 3.10 或更高版本。先运行环境预检：

   python scripts/environment_check.py --target html

   PPT阶段另运行 python scripts/environment_check.py --target standard；美化版改为 --target slideviber --slideviber-dir <已单独安装的SlideViber目录>。Node不在PATH时传 --node <Node可执行文件>。检查按目标区分：HTML不要求PPT/Node；标准完整稿及主题小样使用公开python-pptx与Node，不需要Codex私有工具。预检通过不代表字体、浏览器或实际视觉已验。

2. 预检提示缺少依赖时，再运行 python -m pip install -r requirements.txt；不要把依赖或生成文件打包进 Skill。普通安装不要求Git；版本追溯保留文件指纹，Git信息只在本Skill自身仓库可读取时补充，缺失不冒充已知版本或干净工作区。

3. 读取 请求与报告模型，确定意图、分析画像与语义合同。选择“直接分析”时可先执行：

   python scripts/sheet_to_report.py --inspect path/to/data.xlsx

4. 正式 HTML 默认由宿主 AI 驱动。先读 宿主 HTML 分析合同，显式使用本 Skill 绝对目录。初扫 → 阅读证据并逐问题判断充分性 → 必要时受控补查 → 绑定最终快照提交故事 → compose → finalize。无需用户手写问题或提案；脚本只做确定性计算，不会独立调用模型。不允许手修最终模型或 HTML。html-chapters/1 与旧 PPT 页型解耦；背景无需制造行动，数字仍必须绑定证据。以下一键入口保留为旧分析/兼容用途，不代表完成新版宿主 AI 分析：

   python scripts/sheet_to_report.py --request path/to/request.json --output path/to/output

5. 以下为旧模型兼容入口，不接续上面的新版 HTML 流程。 经确认的旧分析流程可分两阶段运行。--analyse-only 只生成确定性 analysis_evidence.json；--finalize 只接受与来源哈希、请求指纹和 evidence 严格绑定的 story plan：

   python scripts/sheet_to_report.py --request path/to/request.json --output path/to/output --analyse-only
   python scripts/sheet_to_report.py --output path/to/output --finalize path/to/story_plan.json

   默认 story plan 只能重排已有内容。若表内已有结构证据却缺经营判断，先由当前 AI 阅读冻结证据，按 证据后判断提案 提交结构化 proposals，再用 --compose-decisions 编译故事计划。数字、范围、深度和章节归属仍由脚本生成与校验；不得直接改 seed 或内容锁。来源不匹配、引用越权、缺少必需页面角色或内容证据不足时必须失败，不能静默生成。

6. 新版 HTML 在组织提案前读取 共享图表规格。按判断任务与数据条件选图，用 chart-spec/1 记录选择理由、限制、尺度和重点；新运行不能退回旧细横条合同。柱图、分布、构成、关系和贡献图各有数据约束，不按行业名或固定图型配额选择。图中分箱、比例和累计坐标只消费已计算证据；能力不足须说明原因，不能交给渲染器临时计算。检查 report_model.json、report.html、html_qa.json 和数据质量提示。html-chapters/1 必须走 html_analysis.py finalize 对应的检查，不能再交给只支持旧 analysis_chapters 的 html_qa.py；结构／证据通过不等于视觉通过。实际审核关键图能否支持判断，优先桌面；手机只查基础可用性。机器 QA 通过不等于实际阅读验收完成。

   HTML 完成后先给可打开的报告入口，再用普通文字报告已经完成和仍未验证的检查；用户未排除 PPT 时，说明可以回复“生成 PPT”继续。用户明确只要 HTML 时不再推荐后续产物。优先补充一条与本次汇报目标相关、已绑定证据的发现，避免只交付文件。

7. 若用户选择 PPTX，新版 HTML 先读取 章节到演示投影，使用独立 chapter-presentation/1 及对应新消费者，不把模型直接送入旧 build_pptx.py。按当前已验证能力执行，显式拒绝尚未支持的布局或图形条件。交付 report.pptx 与 ppt_qa.json；标准版必须先独立通过字号、边界、重叠、占位符、标题—图表证据一致性、内容锁定与中文排版门禁。

8. 生成任何 PPT 前读取 主题选择。已明确指定或已确认沿用的风格优先；用户明确说“你决定、直接生成”且无已确认偏好时，使用默认清晰商务。无偏好且未授权代选时，先推荐清晰商务，备选最多两种当前完整稿已验证的方向；每种实际导出同内容的封面＋真实图表两页 PPT 小样，并优先把真实渲染图片直接展示在聊天中。不能渲染时须在让用户选主题前说明，并让用户选择“按文字方向选择”或“明确授权使用推荐主题”；不得用网页示意图冒充真实 PPT、让用户自己寻找本地文件夹，或因超时和沉默自动代选。

   一个待选择节点只发一次清楚问题，然后停止并等待新用户输入。没有新输入时，不重复催选、重做小样或自行生成完整稿；自动续跑不构成用户确认。只列当前完整稿已经验证的主题，editorial 两页小样可做不代表完整稿可用。

   标准版通过后，交付完整稿阅读入口和独立可编辑 PPTX；只有入口实际可用时才写“预览完整稿”或“下载可编辑 PPT”。随后若用户尚未表态，简短说明可回复“制作美化版”通过 SlideViber 继续；同时说明它需单独安装、标准稿会保留，图表编辑方式可能不同。用户已拒绝时不重复询问。美化版继承同一已确认选择，保留标准稿、完整内容和来源校验；新版章节模型使用 章节到演示投影 的独立构图消费者，旧模型使用 slideviber_handoff.md。预览及实际 PPT 核验后另存 report-polished.pptx，不重复审批。

9. 美化稿在同一显示尺寸下对照标准稿，检查视觉焦点、图文对应、图表可读性及整稿节奏；只换颜色、分辨率或导出器不算美化完成。精修版导出后运行对应合同的一致性检查；缺少日期、关键数值、判断标题或 evidence 对应关系时不得交付。新版章节投影使用 chapter_presentation_qa.py 并传入绑定的 --scene；以下命令仅用于旧模型：

   python scripts/slideviber_consistency.py --model report_model.json --pptx report-polished.pptx --output slideviber_qa.json