企业官网建设流程全解析

季度末把销售明细整理成复盘报告，再顺手出一版能直接上会的汇报 PPT，这件事听起来像是两个独立任务，实际上是一条完整的数据加工链路。我过去几个季度都是用 WorkBuddy 配合 Python 和 LLM 来跑这套流程，从最初手工复制粘贴到后来全流程半自动化，中间踩过的坑足够写满一个笔记本。这篇内容就是把这套链路完整拆开，讲清楚每一步为什么这么做、参数怎么定、哪些地方最容易翻车。不管你是刚接触 WorkBuddy 的新手，还是已经用过一段时间但总觉得输出不够稳定的老用户，都能从里面找到可以直接抄作业的部分。核心关键词就三个：WorkBuddy 做任务编排、Python 做数据处理、LLM 做文本生成，三者串起来才能把一张季度销售表变成有观点、有结构、能汇报的成品。

1. 为什么季度销售表不能直接丢给 LLM 出报告

1.1 原始表格的数据噪声远比想象中多

很多人第一反应是：既然有 LLM，直接把 Excel 文件传进去让它写复盘报告不就行了。我最初也是这么干的，结果输出质量惨不忍睹。原因很简单，季度销售表里塞满了 LLM 不擅长处理的东西。比如合并单元格导致的空值、多级表头、隐藏列、批注、条件格式产生的颜色标记，还有各种手工填写的备注字段。这些东西在人眼里是"上下文"，在 LLM 眼里就是噪声。

我拿一份真实的季度销售表做过测试，原始文件 3800 行、27 列，直接喂给 LLM 后它把"华东大区"和"华东区域"当成两个不同的区域来统计，因为表格里这两种写法混用。还有一次，某列的数值被存成了文本格式，LLM 读出来是字符串，做同比计算时直接算错。这类问题不是 LLM 能力不够，而是输入数据本身没有经过清洗和结构化。

所以正确的做法是：先用 Python 把表格清洗成规整的二维结构，再交给 LLM 做语义层面的分析和写作。WorkBuddy 在这里的角色是编排整个流程，把清洗、统计、生成、导出这几个环节串起来，而不是让 LLM 直接面对原始表格。

1.2 复盘报告需要的是"观点"而不是"数据罗列"

另一个常见误区是把复盘报告写成数据汇总。我见过太多季度复盘，通篇都是"本季度销售额 X 万，同比增长 Y%"，读完不知道重点在哪。真正的复盘报告需要有判断、有归因、有建议。比如"华东大区虽然完成了目标，但增长主要来自一次性大客户订单，可持续性存疑"这种话，才是管理层想看的。

这就决定了流程设计：Python 负责算出客观数据（同比、环比、目标完成率、集中度等），LLM 负责基于这些数据生成有观点的叙述。两者分工明确，不能混。如果让 LLM 自己去算数，它大概率会算错；如果让 Python 去写观点，它写不出来。WorkBuddy 的价值就在于把这两类能力按正确的顺序编排起来。

1.3 WorkBuddy 在这条链路里的真实定位

WorkBuddy 不是数据处理工具，也不是写作工具，它是任务编排层。你可以把它理解成一个"流程调度员"：什么时候调用 Python 脚本、什么时候把中间结果传给 LLM、什么时候触发 PPT 生成、输出文件存到哪里，这些都由 WorkBuddy 来管。

我目前的配置是：WorkBuddy 里定义三个核心 skill，分别对应"数据清洗与统计""复盘文本生成""PPT 组装"。每个 skill 内部可以调用 Python 脚本或 LLM 接口。这样设计的好处是每个环节可以独立调试，出问题容易定位。如果全部塞进一个大流程里，一旦输出不对，你根本不知道是清洗错了、统计错了还是 LLM 写偏了。

提示：WorkBuddy 的 skill 划分粒度建议按"输入输出边界清晰"的原则来定。一个 skill 的输入应该是一份明确的数据或文本，输出也应该是明确的产物，中间不要有模糊的"处理一下"这种步骤。

2. 用 Python 把销售表洗成 LLM 能吃的格式

2.1 读取阶段就要处理的三个坑

用 pandas 读 Excel 看起来是一行代码的事，但实际项目里这一步就能卡住很多人。我总结下来有三个高频问题。

第一个是表头行数不固定。有些销售表的标题占了两三行，真正的列名在第四行。这时候pd.read_excel的header参数要设对，或者干脆用header=None读进来再手动指定列名。我一般会先读前 10 行看看结构，确认列名在第几行。

第二个是数据类型自动推断错误。pandas 会把看起来像数字的列读成 int 或 float，但销售表里经常有"1,234"这种带千分位的写法，读进来就变成字符串了。解决办法是读的时候统一用dtype=str，后续再逐列转换。这样虽然多一步，但可控性强很多。

第三个是隐藏行和筛选状态。Excel 里被隐藏的行，pandas 默认还是会读进来。如果业务方在表里做了筛选，你读到的可能是全量数据而不是他看到的那些。这个必须在流程开始前跟业务方确认清楚：到底要处理全量还是筛选后的数据。

import pandas as pd # 先探查结构 raw = pd.read_excel("sales_q3.xlsx", header=None, nrows=10) print(raw.head(10)) # 确认列名在第 3 行后正式读取 df = pd.read_excel("sales_q3.xlsx", header=2, dtype=str) df.columns = df.columns.str.strip() # 去掉列名前后空格

2.2 清洗规则要写成可复用的配置

清洗规则不要硬编码在脚本里，我吃过这个亏。上季度写的清洗逻辑，这季度表格结构微调了一下，脚本直接报错，改了半天。后来我把清洗规则抽成一个 YAML 配置文件，包括：哪些列需要去空格、哪些列需要做同义词映射、哪些列需要转数值、空值怎么填充。这样换一份表格只需要改配置，不用动代码。

同义词映射是重点。销售表里区域名、产品名、渠道名的写法经常不统一。我一般会先跑一遍value_counts()，把出现频次低的写法挑出来，人工确认后加到映射表里。比如"华东""华东区""华东大区""East China"统一映射成"华东大区"。

# clean_config.yaml strip_columns: ["客户名称", "销售员", "备注"] synonym_map: 区域: "华东": "华东大区" "华东区": "华东大区" "East China": "华东大区" numeric_columns: ["销售额", "数量", "成本"] fillna: 备注: "" 销售员: "未知"

2.3 统计口径必须在代码里显式定义

这一步是最容易被忽略但最影响报告质量的。什么叫"同比增长"？是跟去年同期比，还是跟上季度比？"目标完成率"的分母是季度目标还是年度目标按比例拆分？这些口径如果不显式定义，不同人算出来的数不一样，报告就没法用。

我的做法是在 Python 脚本里把每个指标的计算逻辑写成独立函数，并且加上注释说明口径。比如：

def yoy_growth(current, last_year_same_period): """同比增长率 = (本期 - 去年同期) / 去年同期 注意：去年同期为 0 时返回 None，不返回 inf """ if last_year_same_period == 0: return None return (current - last_year_same_period) / last_year_same_period

这样即使后面换人维护，也能一眼看懂口径。而且 LLM 拿到这些带注释的统计结果后，写出来的报告口径也更准确。

2.4 输出给 LLM 的中间格式选择

清洗统计完之后，要把结果传给 LLM。这里有个关键选择：传什么格式。我试过三种：直接传 DataFrame 的字符串表示、传 JSON、传 Markdown 表格。

直接传 DataFrame 字符串最省事，但 LLM 解析时容易把列对齐搞错。JSON 结构最清晰，但 LLM 读大段 JSON 时容易丢失层级关系。最后我固定用Markdown 表格 + 关键指标 JSON的组合：明细数据用 Markdown 表格（LLM 对表格理解很好），汇总指标用 JSON（结构清晰，方便 LLM 引用具体数值）。

# 明细转 Markdown detail_md = df_summary.to_markdown(index=False) # 关键指标转 JSON metrics = { "total_sales": 12500000, "yoy_growth": 0.18, "target_completion": 1.05, "top_region": "华东大区", "top_region_share": 0.42 }

注意：传给 LLM 的数值一定要保留原始精度，不要在 Python 里提前四舍五入。让 LLM 决定在报告里显示几位小数，这样更灵活。

3. 让 LLM 写出有观点的复盘而不是流水账

3.1 Prompt 结构决定了输出质量的上限

我调了几十版 prompt 才找到比较稳定的结构。核心思路是：把 LLM 当成一个刚拿到数据、需要向老板汇报的分析师，而不是一个写作机器。Prompt 里要明确四件事：角色、数据、任务、输出格式。

角色部分要具体，不要写"你是一个数据分析师"，而是写"你是一个负责华东区销售的资深分析师，需要向销售总监汇报本季度情况"。越具体，LLM 的输出越有针对性。

数据部分就是我前面说的 Markdown 表格加 JSON。任务部分要拆成几个明确的小任务：先总结整体表现，再分析各区域差异，然后指出异常点，最后给建议。输出格式要规定好章节结构，但不要规定得太死，留一点发挥空间。

prompt = """ 你是一位负责季度销售复盘的高级分析师，需要向销售总监提交一份复盘报告。 以下是本季度销售数据： {detail_md} 关键指标： {metrics_json} 请按以下结构撰写复盘报告： 1. 整体表现概述（200字以内，给出核心结论） 2. 区域表现分析（重点分析 Top3 和 Bottom3 区域，说明差异原因） 3. 异常点识别（找出数据中值得警惕的信号） 4. 下季度建议（3条以内，要具体可执行） 要求： - 所有结论必须基于给定数据，不要编造 - 涉及具体数值时保留原始精度 - 语言简洁，避免套话 """

3.2 用 few-shot 示例锚定输出风格

光靠指令，LLM 的输出风格还是不稳定。有时候写得很官方，有时候又太口语。我的解决办法是在 prompt 里塞一两个 few-shot 示例，展示我想要的风格。示例不用长，一段话就够。

比如我会给一个这样的示例："华东大区本季度完成销售额 520 万，目标完成率 112%，但增长主要来自 3 月的一笔大客户订单，剔除后实际增长仅 4%，可持续性需要关注。"这段话的特点是：先给数据，再给判断，最后给风险提示。LLM 看到这个模式后，输出会明显更接近。

3.3 数值校验环节不能省

LLM 有个毛病：它会"顺手"改数字。比如你给它 12500000，它可能写成 1250 万，这没问题；但它也可能写成 1200 万，这就出错了。所以 LLM 输出后必须做数值校验。

我的做法是写一个校验函数，把 LLM 输出里所有数字提取出来，跟原始数据比对。如果发现对不上的，标记出来人工确认。这个环节用 Python 做很快，但能避免很多尴尬。

import re def extract_numbers(text): return re.findall(r'\d+\.?\d*', text) def validate_numbers(llm_output, source_metrics): output_nums = set(extract_numbers(llm_output)) source_nums = set(str(v) for v in source_metrics.values()) # 找出输出里有但源数据里没有的数字 suspicious = output_nums - source_nums return suspicious

3.4 处理 LLM 的"过度自信"问题

LLM 写报告时经常给出过于肯定的判断，比如"该区域业绩下滑是因为销售团队能力不足"。这种归因没有数据支撑，写进报告里很危险。我在 prompt 里加了一条约束："对于无法从数据直接得出的结论，使用'可能''需要进一步确认'等措辞，不要做确定性归因。"

另外，我会在报告末尾加一个"数据局限性说明"章节，让 LLM 自己列出本次分析的数据盲区。比如"本次分析未包含退货数据，实际净销售额可能低于报告数值"。这个章节看起来是减分项，实际上大大提升了报告的可信度。

4. 从复盘文本到汇报 PPT 的转换逻辑

4.1 PPT 不是报告的搬运，而是重新组织

很多人做汇报 PPT 就是把报告内容复制粘贴到幻灯片里，结果每页都是大段文字，没人看。正确的做法是：PPT 是报告的"提纯版"，只保留最核心的结论和支撑数据，细节留在报告里备查。

我一般会把复盘报告拆成 8 到 12 页 PPT，结构大致是：封面、核心结论（1页）、整体数据（1页）、区域分析（2到3页）、异常点（1页）、建议（1页）、附录数据（1到2页）。每页只讲一件事，标题就是结论本身，比如"华东大区完成目标但增长质量存疑"，而不是"华东大区分析"。

4.2 用 WorkBuddy 编排 PPT 生成流程

PPT 生成我用的是 python-pptx 库，配合一个预定义的模板文件。WorkBuddy 在这里负责把 LLM 生成的文本按页拆分，然后调用 python-pptx 填充到模板里。

关键点是模板要提前设计好版式。我做了三种版式：标题加正文、标题加图表、标题加表格。LLM 输出时会给每页标注用哪种版式，WorkBuddy 根据标注选择对应的填充逻辑。这样既保证了风格统一，又不用每次重新排版。

from pptx import Presentation from pptx.util import Inches def add_content_slide(prs, title, bullets): slide = prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text = title body = slide.placeholders[1].text_frame for i, bullet in enumerate(bullets): if i == 0: body.text = bullet else: p = body.add_paragraph() p.text = bullet return slide

4.3 图表生成要跟 PPT 同步做

复盘 PPT 里少不了图表。我的做法是在 Python 阶段就把图表生成好，存成 PNG，然后插入 PPT。图表类型根据数据特点选：趋势用折线图，区域对比用条形图，占比用饼图或环形图。

这里有个细节：图表的配色要跟 PPT 模板一致。我一开始没注意，生成的图表是 matplotlib 默认配色，插到 PPT 里跟模板的蓝色系完全不搭。后来我把模板的主色提取出来，在 matplotlib 里设置成全局配色，看起来就协调多了。

import matplotlib.pyplot as plt plt.rcParams['axes.prop_cycle'] = plt.cycler( color=['#1F4E79', '#2E75B6', '#9DC3E6', '#BDD7EE'] ) plt.rcParams['font.sans-serif'] = ['SimHei'] # 中文显示

4.4 导出环节的格式兼容问题

PPT 导出看起来简单，但实际会遇到字体丢失、图片模糊、动画错乱等问题。我的经验是：字体用系统自带的中文字体（比如微软雅黑、黑体），不要用特殊字体，否则换台电脑打开就变形。图片导出时设置 DPI 为 150 以上，保证投影清晰。

还有一个坑是 python-pptx 对某些模板的兼容性。如果模板里有复杂的 SmartArt 或组合图形，python-pptx 可能无法正确填充。解决办法是模板尽量用简单的占位符结构，复杂图形提前在模板里做好，代码只负责填文字。

5. 整条链路串起来之后的实测效果与调优

5.1 一次完整运行的耗时分布

我把整条链路跑通后，记录了几次运行的耗时。清洗统计阶段大概 15 到 30 秒（取决于数据量），LLM 生成报告 20 到 40 秒，PPT 组装 10 到 20 秒，整体下来 1 到 2 分钟。相比手工做，效率提升是数量级的。

但这里有个隐藏成本：首次配置的时间。清洗规则、prompt、PPT 模板这些都需要根据具体业务调整，第一次做可能要花半天到一天。不过一旦配好，后续每个季度只需要微调，边际成本很低。

5.2 输出质量不稳定的三个常见原因

跑多了之后会发现，有时候输出很好，有时候又不行。我总结下来主要是三个原因。

第一是输入数据波动。如果某季度数据里出现了之前没见过的值（比如新区域、新产品线），清洗规则没覆盖到，就会出问题。解决办法是每次运行前先跑一遍数据探查，看看有没有异常值。

第二是LLM 的随机性。同样的 prompt，不同次运行输出会有差异。如果对稳定性要求高，可以把 temperature 调低（比如 0.3），牺牲一点创造性换稳定性。

第三是模板与内容的匹配度。如果 LLM 生成的某页内容特别长，模板的文本框装不下，就会溢出。我的做法是在代码里加一个长度检查，超过阈值就自动拆分或精简。

5.3 给 WorkBuddy 定几条长期生效的规则

用 WorkBuddy 一段时间后，我发现有些规则是每次都要遵守的，与其每次重复交代，不如直接写进 WorkBuddy 的全局规则里。我目前定了这么几条：

• 所有涉及数值的输出，必须经过 Python 校验后才能进入下一步
• 所有 LLM 生成的文本，必须保留原始版本和校验后版本，方便回溯
• 所有输出文件按"日期_项目名_版本号"命名，避免覆盖
• 任何环节报错，先输出中间结果再终止，不要静默失败

这几条规则写进去之后，整个流程的稳定性明显提升。特别是最后一条，以前出错了什么线索都没有，现在至少能看到卡在哪一步。

5.4 后续可以扩展的方向

这套链路目前跑得比较顺，但我还在想几个扩展点。一个是多季度对比，把过去四个季度的数据都跑一遍，生成趋势分析。另一个是自动生成汇报讲稿，在 PPT 基础上再生成一份逐页讲稿，汇报时直接照着念。还有一个是异常自动预警，如果某区域数据偏离历史均值超过阈值，自动在报告里高亮。

这些扩展都不难，核心链路已经通了，剩下的就是加环节。我的建议是先把基础链路跑稳，再考虑扩展，不要一上来就追求大而全。

提示：扩展功能时，每加一个环节都要单独测试，确认它不会影响已有环节的输出。我吃过这个亏，加了个自动预警功能，结果把原来的统计逻辑搞乱了，排查了半天。

6. 几个容易翻车的细节和我的处理方式

6.1 中文编码问题贯穿始终

从 Excel 读取到 LLM 输出到 PPT 写入，中文编码问题几乎每个环节都会遇到。最常见的是乱码，根源通常是某个环节用了默认编码而不是 UTF-8。我的做法是在所有文件读写操作里显式指定encoding='utf-8'，包括读 Excel、写 JSON、写文本文件。

还有一个隐蔽的坑是全角和半角字符。销售表里经常混用，比如"（华东）"和"(华东)"。这会导致同义词映射失效。我在清洗阶段加了一步字符规范化，把所有全角括号、逗号、空格统一转成半角。

def normalize_chars(text): if not isinstance(text, str): return text # 全角转半角 text = text.replace('（', '(').replace('）', ')') text = text.replace('，', ',').replace(' ', ' ') return text.strip()

6.2 LLM 输出格式不稳定的应对

即使 prompt 里规定了输出格式，LLM 有时候还是会跑偏。比如要求用 Markdown 标题，它可能用加粗代替；要求分四点，它可能写成三段。我的应对方式是在 prompt 里给一个严格的输出模板，并且要求"严格按照以下格式输出，不要添加额外说明"。

如果还是不稳定，就在 Python 侧加一个格式修正层。比如检测到 LLM 用了加粗而不是标题，自动转换成标题格式。这个修正层不用太复杂，覆盖最常见的几种偏差就行。

6.3 PPT 文字溢出的预防

PPT 文字溢出是最影响观感的问题。我的预防措施有三层：第一层是在 prompt 里限制每页 bullet 数量和每条字数；第二层是在代码里检查文本长度，超过阈值自动截断或拆分；第三层是在模板设计时留足空间，宁可页面空一点也不要挤。

具体阈值我设的是：每页最多 5 条 bullet，每条不超过 40 个字。超过的话，要么拆成两页，要么精简表述。这个标准是根据实际投影效果定的，40 个字在 16:9 的幻灯片上大约占两行，看起来比较舒服。

6.4 版本管理和回溯

这套流程涉及多个环节，一旦最终输出有问题，需要能快速定位是哪一步出的错。我的做法是每个环节的输出都单独存文件，按运行时间戳建文件夹。比如2024Q3_20241015_143022/下面存01_cleaned_data.csv、02_metrics.json、03_report.md、04_report_checked.md、05_slides.pptx。这样出问题可以逐环节比对。

这个习惯看起来麻烦，但实际省了很多时间。有一次报告里某个数字不对，我直接对比02_metrics.json和03_report.md，发现是 LLM 引用错了，五分钟就定位了。如果没有中间文件，可能要重新跑一遍才能发现。

6.5 跟业务方确认口径的时机

技术上的坑好解决，业务上的坑才麻烦。我遇到过一次，报告都生成好了，业务方说"我们这个季度的目标口径变了，你用的还是老口径"。结果整个报告重做。

后来我定了个规矩：每次运行前，先跟业务方确认三个问题——数据范围是什么、统计口径有没有变化、报告重点想看什么。这三个问题确认清楚，后面基本不会返工。确认方式可以很简单，发个消息问一下就行，但一定要问。

7. 写在最后的一点个人体会

这套流程我跑了四个季度，从最初的手忙脚乱到现在基本可以"一键出报告"，中间最大的体会是：工具的价值不在于替代人，而在于把人从重复劳动里解放出来，去做真正需要判断的事。Python 负责算得准，LLM 负责写得快，WorkBuddy 负责串得稳，但最终报告里的观点、建议、风险提示，还是需要人来把关。

我现在的工作模式是：流程自动跑出初稿，我花 20 分钟审一遍，重点看结论是否合理、数值是否准确、建议是否可执行。这 20 分钟的投入，换来的是以前半天的工作量。省下来的时间，可以用来做更深入的业务分析，而不是耗在复制粘贴和排版上。

如果你也想搭这套流程，我的建议是从最小可用版本开始：先跑通"Excel 到 Markdown 表格"这一步，再加 LLM 生成，最后加 PPT。每步都跑稳了再往下走，不要一上来就追求全自动。踩坑是必然的，但只要每个环节都有中间产物可以检查，排查起来就不会太痛苦。