我是如何利用 WorkBuddy 创建一个项目经营分析表解读 Skill 的-平芜编程栈

经营分析表摆在面前的那一刻，绝大多数项目经分人员的第一反应是"打开、滚动、看数字"——几十列、十几个维度，从哪里看起、按什么顺序看、看到什么算异常，全凭经验和直觉。

这就是我决定用 WorkBuddy 构建一个"项目经营分析表解读 Skill"的根本原因：把资深经分人员的解读思路固化成可复用能力。模板告诉你"报告长什么样"，回答不了"这份表到底该按什么顺序看"——这正是 Skill 要补上的那一环。

一、问题与背景

1.1 经营分析表为什么"读不懂"

每个项目都有一张经分表，看起来都差不多：项目、收入、成本、毛利率、净利率、回款、工时……但真读起来问题接踵而至：维度多，哪个先看？结构乱，有的"项目"放 A 列，有的放 B 列，“预算"与"实际"挨着或分两段都有；判断主观——毛利率 35% 是好是坏？同一份表两个项目经理能得出相反结论。复用更困难——老张的分析逻辑存在他脑子里，新人接手一切从零开始。网上模板能告诉你"报告长什么样”，回答不了"这份表到底有什么问题、应该按什么顺序看"——这才是最贵的部分。

1.2 资深项目经理的"读表八步"

拆开一位资深经分人员的解读过程，是一套相对稳定的八步：① 总量与同比；② 毛利率与净利率；③ 收入与回款；④ 工时与产能；⑤ 项目结构——头部项目占比；⑥ 预算完成度；⑦ 同比环比趋势；⑧ 风险信号——毛利率异常、产值塌方、回款拉长。这八步是内功，问题在于它不在文档、不在表格，而在几个具体的人身上。把内功留下来，是构建这个 Skill 的真正动机。

1.3 为什么选 WorkBuddy

WorkBuddy 是腾讯云 CodeBuddy 团队推出的桌面智能体，内置 MCP Server 与 Skill 机制——不是"问一句答一句"的聊天 AI，而是一台"能加载技能包"的工作台。用户把读表思路封装成 SKILL.md 与配套脚本，AI 按 Skill 定义逐步执行；要的是一份"能反复跑、换表不换逻辑"的解读资产——正是 WorkBuddy 的舒适区。

二、解决方案：把读表内功封装成 Skill

2.1 Skill 的四层文件结构

整个 Skill 由四份文件组成，各司其职：SKILL.md 是 8 项分析维度的"宪法"（流程层）；parse_excel.py 负责自适应识别 Excel（执行层）；report_template.md 规定报告骨架（输出层）；analysis-thresholds.md 沉淀阈值与角色清单（判断层）。四份文件分别承担"按什么步骤分析"、“表格怎么读”、“输出长什么样”、“什么算异常"四件事，组合起来就是一份完整的"读表内功”。

2.2 SKILL.md：8 项分析的流程骨架

SKILL.md 被写成八个阶段，每阶段都有"目标、输入、输出、判断口径、注意事项"五段式说明，覆盖总量与同比、毛利率与净利率、收入与回款、工时与产能、项目结构、预算完成度、同比环比、风险信号八个维度。五段式的作用是让 AI 在执行任何一步时都不"自由发挥"——资深分析师放心把流程交给 AI，正是因为每一步都"看得见"。

2.3 parse_excel.py：自适应识别不同格式的经分表

真实场景的经分表样式各不相同：有的把"项目"放 A 列但用"业务线"称呼，有的"预算/实际"横向并列，有的把日期拆成开始/结束两列。识别阶段做了三件事：

关键词优先级匹配：先按列名里的关键词（收入、成本、毛利……）锁定位置，再用行名与列名语义关系判断字段类型；
交替列处理：相邻两列常成对出现（预算-实际、同比-环比），成对处理而非独立解读；
未知列兜底：识别失败的列进入"待人工标注"清单，不让模型猜测。

最关键的一次修复是关键词优先级——之前会把"项目毛利"和"项目预算"误识别为同一类型，现在改为"先按列名整词匹配，再按行名属性升维判断"。

2.4 报告模板与阈值：业务记忆的载体

report_template.md 把 8 维度编排成固定结构的 Markdown：每节一个总览表 + 一段结论，结尾给红绿风险清单。模板的好处是"看起来稳"——无论数据来自哪个项目、哪个月份，输出都是熟悉框架，决策者能快速对照。

最有"知识"含量的反而是阈值。analysis-thresholds.md 沉淀了过去三年对各类项目的判断线：毛利率低于 25% 黄色，回款周期超 90 天红色，人均产值低于 30 万/月待复盘，头部项目集中度超 70% 触发结构化风险；并针对运营专员、项目经理、财务 BP 三类角色给出专项清单——Skill 不只是"看出问题"，还能"按角色给出不同视角的风险提示"。

三、技术架构

3.1 阶段化执行模型

整个 Skill 的运行分四个阶段：阶段一由 parse_excel.py 识别 Excel；阶段二按 8 项维度依次分析；阶段三按 report_template.md 生成 Markdown；阶段四在用户确认后生成 DOCX 正式版。每阶段都有输入与输出契约，下一阶段只消费固定字段，不依赖"理解"上一阶段的全文——这是 Skill 可被复用、可被回归的根本保障。

3.2 自适应识别的代码骨架

parse_excel.py 不是"按列号硬读"，而是"按语义软读"：先按列名关键词精匹配（收入/营收/合同额/销售额归到"收入"桶），再把相邻列按"预算-实际""同比-环比"成对识别，最后对识别失败的列标记为 manual_review，绝不猜测。只要新表列名里仍有"收入、成本、毛利"这些关键词，脚本就能直接跑通。

3.3 "先 md 后 docx"的体验闭环

阶段四的输出流程被特别设计：Markdown 报告生成后用 present_files 展示给用户 → 用户提修正、AI 修改 → 用户确认无误后再生成 DOCX（蓝底表头、红绿标识、隔行底色）→ 再次展示成品。为什么要先 md 后 docx？因为 Markdown 改起来最快，几分钟内可反复迭代；DOCX 是"出街版本"，得等用户说"没问题"再生成。本质是把"草稿"和"成品"两个阶段分开——这是从资深经分人员身上学到的最重要的一招：报告永远要被人看过一遍再发出去。

3.4 WorkBuddy 作为执行容器

WorkBuddy 在这里承担三件工作：通过 MCP Server 协议加载 jingfenbiao-analyzer.zip，让 AI 进入"按 Skill 流程工作"的状态；内置的 present_files 工具负责文件展示与下载；分析阶段调度擅长中文阅读的模型，报告排版阶段切换到更适合长文输出的模型。这也是 WorkBuddy 相比"裸用 ChatGPT"的优势——它是一台"已经预装好水电煤"的工作台，而不是"什么都得自己接"的空白 API。

四、成果与收获

4.1 老张的方法论变成了团队资产

以前只有老张能看懂的经分表，现在团队里任何一位运营专员拿过同一份 Skill 都能产出一致结论——判断口径的统一，是团队资产化的第一步。

4.2 分析时间从"半天"压缩到"几分钟"

过去一份经分表的人工解读需要 2-3 小时（含数据整理、画图、写结论）；现在从"上传文件 + 触发 Skill"到产出 md 报告，全程不到 5 分钟；用户确认后再生成 docx，又 1 分钟。

4.3 自适应能力让 Skill 能"搬家"

经分表样式各不相同——有按"业务线 × 月份"的，有按"项目 × 季度"的，也有整张表就是一个长表。parse_excel.py 的自适应设计让 Skill 在跨项目、跨 BU 时都不需要重写，这是 Skill 区别于"硬编码脚本"的关键。

4.4 "先 md 后 docx"成为团队的报告范式

此前团队的报告范式是"写 docx → 发出去 → 被打回 → 重写"，现在改成"AI 跑 md → 人审一遍 → 转 docx"——md 阶段修改成本几乎为零，返工率明显下降。

4.5 阈值文件成为业务记忆

analysis-thresholds.md 不是代码，而是过去三年团队对各类项目的判断经验沉淀。后续新人或新 BU 想搭类似 Skill 时，可直接复用这套阈值，不必从头摸索——这是"组织级经验资产化"最具体的一步。

五、实践成果

Skill 交付清单：jingfenbiao-analyzer.zip 含 SKILL.md、parse_excel.py、report_template.md、analysis-thresholds.md 与 README.md。

实际产物：以"某跨境定制服务项目"为例，近期一份经分表输入后，AI 跑出两份文件：.md 在 WorkBuddy 内可直接预览，.docx 保留蓝底表头、红绿标识与隔行底色，可作为项目例会输入材料分发。

下一步可探索的方向：① 用另一份不同格式的经分表测试自适应识别；② 把分析 ②-⑧ 的逻辑逐项深化；③ 把计算逻辑直接写进 SKILL.md；④ 为 8 项分析各设计固定可视化模板；⑤ 把打包好的 Skill 装到全新会话里验证可加载性。无论选哪一条，Skill 已经能在真实项目上跑通——它证明了"读表内功"可以被沉淀、被继承、被不同人复用，这也是所有 Skill 工程的真正起点。