教 AI 写工作月报：从一次性投喂到节点化工作流，再到 Skills 模块化改造
我是舸扬。记录 AI 探索与生活思考。在速成时代，坚持每篇文章都是一次深潜。行者开路，不随前尘。
每月最后要写月报的那几天，你是怎么过的？对着空白文档发呆？在网上搜索"月报模板"？还是对着散落在各处的会议纪要叹气？
作为一个"能用脚本绝不手动"的程序员，我决定给自己设计一套 AI 工作流来解决这个问题。从最初简单的"一次性投喂"，到后来设计出复杂的"节点化工作流"，再到最近紧跟技术潮流做的 Skills 模块化改造。折腾这一圈下来，我不仅解放了写月报的双手，也对 AI 自动化助手的设计有了些新的体感。
TL;DR（全文速览）
- 场景：月报素材散乱（会议纪要、聊天记录、邮件），一次性投喂导致 AI "消化不良"。
- 痛点：材料太长，AI 会"看了后面忘了前面"；而且每次都要重新教它格式，很麻烦。
- 解决方案：把大任务拆成小步骤，让 AI 一步步来，每一步的结果都存下来。后来又升级成了更模块化的 Skills 技能包。
- 核心洞见：AI 是很强的"执行者"，但需要人来指方向；用一个"进度表"文件来管理整个流程，效果拔群。
- 可以带走：文末附录给了两样东西，一套复制粘贴就能用的五步提示词（零安装，适合所有人），以及封装成 Skills 的进阶版（一句话触发、自动接力，晚点开源）。不想读原理，直接跳到附录也能上手。
一、月报之痛：你也有过这种感觉吗？
每月最后几天，我都有一种熟悉的生理性抗拒。
打开文档准备写月报，才发现这个月做过的事情散落在各处：会议纪要在一个文件夹，项目进度在另一个表格，和客户的沟通记录在微信聊天里，还有几封重要邮件埋在收件箱深处……
光是把这些材料"物理搬运"到一起，就要花掉半天时间。等真正开始写的时候，大脑已经因为过载而罢工了。
写到一半，突然想起来：上周那个紧急问题的处理过程好像没记录？于是又开始翻找，群聊记录、文档备注、邮件……
最后往往是在临近提交前草草收尾，交上去一份自己都不太满意的流水账。
有一天我盯着屏幕想：这事儿不就是典型的"信息提取+结构化重组"吗？如果 AI 能帮我自动生成月报就好了。
把一个月的工作材料丢给它，让它帮我整理、归纳、撰写，这个想法看起来很美好。于是说干就干。
二、第一版：把所有材料一股脑丢给 AI
最简单的思路当然是：收集所有材料 → 复制粘贴给 AI → 让它生成月报。
第一次尝试的效果居然还不错。我把整理好的会议纪要、项目进度表、几封关键邮件的内容复制粘贴给 AI，它确实能理解这些内容，并且整理出一份结构清晰的月报。
但随着我试图让它处理更多细节，问题很快就暴露了。
材料越来越多，AI 开始"消化不良"。
有一次我把整个月的详细材料（大概 3 万多字）一股脑丢进去，AI 的表现让我很失望：
- Context Window（上下文窗口）告急：如果你不理解这个词，可以把它想象成 AI 的"短期记忆容量"。虽然现在的模型记忆力已经很强，但一次性塞入过长且杂乱的文本，注意力机制很容易"失焦"。这是一个被称为 "Lost in the Middle"↗ 的经典问题：斯坦福大学的研究发现，大模型在处理长文本时，往往只记得开头和结尾，而对中间部分"遗忘"严重，呈现一个 U 形曲线的性能表现。
- "遗忘"现象：它在写后半部分的项目规划时，完全不记得前面提过的项目背景，导致前后逻辑脱节。
- 输出质量不稳定：有时候它能抓准重点，有时候却漏掉关键的里程碑，完全不可控。
- 无法复用：每次都要从头开始写 Prompt（提示词，就是你给 AI 说的那句话），上个月调好的格式，这个月又要重新教一遍。
我意识到，这种"一次性投喂"的方法有根本性的缺陷。
我需要一个更系统的、工程化的方案。
三、突破：节点化工作流，让 AI 分步处理
既然一次处理太多信息会有问题，那就把大任务拆成小步骤。
但什么是"节点化"？这个概念可能有点抽象，让我用一个更直观的比喻来解释。
先搞清楚：什么是节点化工作流？
想象一下餐厅的后厨。
一次性投喂的做法，就像把所有食材一股脑倒进一口大锅里，然后期望它自己变成一桌满汉全席。结果可想而知：土豆还没熟，青菜已经烂了；调料的量全凭感觉，咸淡完全不可控。
节点化工作流则完全不同。它就像一个真正的厨房：有专门洗菜的水槽、切菜的案板、不同功能的灶台。每个岗位只负责一件事：
- 备菜区：清洗、切丁、腌制，只负责把原材料处理成"半成品"
- 炒锅区：只接收处理好的食材，专注于翻炒调味
- 摆盘区：只负责让菜品好看
每个环节（节点）的输入是明确的，输出也是明确的。炒锅不需要知道菜是怎么洗的，摆盘不需要知道火候是怎么控制的。它们只需要接收上一个环节递过来的"半成品"，做好自己的事情，再把成果传给下一个环节。
这就是节点化的核心思想：专业分工加接力传递。
为什么这能解决 AI 过载的问题？
回到月报生成的场景。如果我把 3 万字材料一次性丢给 AI，就相当于让它同时处理：
- 理解每份材料的内容（信息提取）
- 识别哪些是重点、哪些是细节（判断筛选）
- 规划文章结构（内容规划）
- 撰写正文（内容生成）
- 统一语言风格（润色修订）
五件事情同时做，而且都要记住前面的所有信息，这就是为什么 AI 会"消化不良"。它的注意力被分散了，很难在每一件事上都做好。
但如果我们把这些任务拆成独立的节点呢？
[扫描材料] → [生成摘要] → [提取主题] → [规划大纲] → [撰写正文] → [润色修订]现在每个节点都只需要：
- 读取有限的输入：比如"生成摘要"节点只需要看原始材料，不需要管后面怎么写文章
- 完成单一任务：专注做好一件事
- 输出结构化的中间产物：比如输出一份摘要文档，供下一个节点使用
当 AI 执行到"撰写正文"这个节点时，它不需要再去翻那 3 万字的原始材料。它只需要读取前面节点产出的摘要和大纲，可能只有 3000 字，就能写出一篇逻辑清晰的月报。
这就是节点化的魔力：通过中间产物的"信息压缩"，让每个节点都在自己能力范围内工作。
我的核心设计思想
想通了这些，我提出了这套工作流的核心设计原则：
每个节点只处理有限的、相关的材料。节点之间通过中间产物传递信息。用户可以在关键节点控制流程。
这个想法其实是我在和 AI 讨论方案时碰撞出来的。最初 AI 还是建议我优化提示词，尝试一次性搞定。我坚决反对，要求它帮我设计成一个"节点化的流水线"。
程序员朋友可能更熟悉它的学名，状态机（State Machine）。但这不重要，你只需要把它想象成一条精密的工厂流水线：每个环节（节点）只做一件事，做完贴个标签，再传给下一站。
Document-as-Orchestrator（文档即指挥官）设计模式
接下来的问题是：谁来管理这些节点？谁来记住现在执行到哪一步了？
我和 AI 想出了一个有趣的设计：不是用代码来硬编码流程，而是用一个配置文件（YAML 格式，你可以理解为"AI 能读懂的清单"）作为"调度中心"。
这个文件叫 orchestration.yaml，它就像是厨房里的"出餐进度表"，记录了：
- 当前执行到哪个节点（"你现在在这里"）
- 每个节点的状态（等待、运行中、完成、阻塞）
- 节点之间的依赖关系（"完成 A 才能做 B"）
- 用户确认的检查点（"这里需要你看一眼"）
AI 每次启动时读取这个文件，就知道自己该做什么。执行完一个节点后，更新状态，写入文件。
这意味着，工作流是"有状态"且"持久化"的。我今天处理完素材整理，关机睡觉；明天早上起来，读取这个 YAML，AI 知道下一步该写大纲了，完全无缝衔接。
💡 想直接上手？ 文末附录里放了一套可以直接复制粘贴的 Prompt，跟着五步走就能让 AI 帮你写月报，不用懂任何配置文件。
5 个阶段，14 个节点
为了搞定一份完美的月报，我们把工作流拆得非常细，分成了 5 个阶段：
INIT (初始化) → INGEST (素材摄入) → PLAN (规划) → EXECUTE (执行) → FINALIZE (定稿)具体包含 14 个节点：
| 阶段 | 节点 | 职责 |
|---|---|---|
| INIT | init_project | 初始化项目结构 |
| INGEST | scan_materials | 扫描原始素材 |
| split_chunks | 将大文件分块（解决 Context Window 问题的关键） | |
| summarize_chunks | 为每个块生成结构化摘要 | |
| extract_topics | 提取本月关键主题 | |
| confirm_ingest | [检查点] 确认素材整理 | |
| PLAN | plan_series | 规划内容结构 |
| outline_article | 生成详细大纲 | |
| confirm_plan | [检查点] 确认计划 | |
| EXECUTE | draft_article | 撰写初稿 |
| polish_article | 润色打磨 | |
| confirm_review | [检查点] 用户审阅 | |
| generate_images | 生成配图 | |
| FINALIZE | cleanup | 收尾统计 |
检查点的价值
注意上面标注为 [检查点] 的节点。
这不是一个完全自动化的"黑盒"，而是一个人机协作的"白盒"。在关键节点，工作流会暂停，等待我的确认：
- confirm_ingest：AI 识别出的主题对吗？有没有把我和客户的闲聊当成正事了？
- confirm_plan：这个大纲结构合理吗？是不是漏了那个最重要的项目？
- confirm_review：这篇文章语气对吗？是不是太像机器人了？
这样设计的好处是：既利用了 AI 的处理能力，又保留了人类的判断权。我不需要盯着它写的每一个字，只需要在关键路口把把关。
四、实战：工作月报生成全流程
这一套听起来挺复杂，但实际用起来非常丝滑。让我演示一下我现在的月报是怎么生成的。
1. 启动工作流
操作非常简单。我不需要去记复杂的命令行参数，也不用打开什么专门的后台。
只要在 IDE（比如 Cursor 或 VS Code）里打开对话框，输入：
@orchestration.yaml启动本月的月报生成工作流
AI 就会自动读取这个编排文件，发现当前状态是初始状态，然后告诉我：
"收到，已初始化工作流。请把这个月的所有工作材料放入
materials/raw目录，然后告诉我'继续'。"
这就是 Document-as-Orchestrator 的魅力。一切交互都基于自然语言和文件状态。
2. INGEST 阶段：素材整理
我把散落在各处的文件（会议纪要.md、项目进度.xlsx、邮件汇总.txt）一股脑拖进目录，然后说"继续"。
后台发生的事情是这样的：
→ scan_materials
扫描发现 5 个文件，约 1.5 万字
→ split_chunks
发现"项目进度"文件超长了，自动切分成 3 个小块。
最终得到 8 个小块（chunk）。
→ summarize_chunks
为每个小块生成结构化摘要：
- chunk_01: 项目 A 本月完成需求评审，进入开发阶段...
- chunk_02: 拜访了 3 家客户，其中 2 家有明确意向...
→ extract_topics
提取本月关键主题：
- 项目 A 上线
- 客户拜访（深圳 + 广州）
- 团队建设活动
- Q1 规划讨论
→ [检查点] confirm_ingest
AI 问我："这些主题覆盖了本月的主要工作吗？"
我看了一眼，补了一句："还有，要把上周处理的那个线上故障也加上。"
AI："收到，已补充'线上故障处理复盘'主题。"3. PLAN 阶段：内容规划
材料整理清楚了，接下来是规划怎么写。
→ plan_series
AI 根据主题规划月报结构：
- 本月重点工作（3 项）
- 项目进度更新
- 问题与风险
- 下月计划
→ outline_article
生成详细大纲：
(这里会生成具体的二级标题，比如"1.1 项目 A 上线：提前 2 天完成交付")
→ [检查点] confirm_plan
AI："这个结构合理吗？"
我："OKR 部分要前置，放到最前面。"
AI："好的，已调整顺序。"4. EXECUTE 阶段：内容生成
→ draft_article
按大纲撰写初稿。这一步 AI 会根据大纲，去之前的 chunks 里找对应的细节，填充进去。
→ polish_article
润色处理。我会要求它："语气专业一点，多用数据说话，少用形容词。"
→ [检查点] confirm_review
这是最后的把关。我读了一遍，确实比我平时写的流水账强多了，逻辑清晰，数据详实。
"通过。"
→ generate_images
AI 甚至帮我生成了两张图表：一张项目进度的甘特图，一张工作时间分布的饼图。输出
一份结构清晰、重点突出、甚至还带图表的工作月报就这么诞生了。整个过程，我只做了三件事：扔材料、确认大纲、审阅成稿。
最关键的是，每个节点只需要读取相关的材料。生成摘要时只看原始素材片段，撰写时只看之前的大纲和相关摘要。不需要一次性加载所有内容，AI 从未过载。
五、新事物出现：Claude 推出了 Skills
这套工作流在我的本地跑了几个月，极其稳定，我也挺满足。
直到近期，Claude 推出了一个名为 Skills↗ 的新功能。简单来说，Skills 是一种模块化的能力扩展框架，你可以把它理解为给 AI 装上"技能包"，让它在特定领域变得更专业。Anthropic 随后将其作为开放标准发布（译注：即 Agent Skills），Antigravity 和 Trae 等 IDE 也迅速跟进并提供了支持。
什么是 Skills？
简单说，它是一种更现代的 AI 助手能力扩展方式：
- 自动发现：用户只需描述意图（"帮我写月报"），AI 会根据你说的话，自动判断该用哪个技能包↗，不需要你手动指定。就像你走进餐厅说"我想吃辣的"，服务员自动推荐川菜一样。
- 模块化：每个 Skill 独立封装，职责单一，就像一个个乐高积木。
- 独立调用：可以单独使用某个能力（比如只用润色能力），而不需要跑整个流程。
Workflows vs Skills
我当时有点懵。我手里的这套东西（我都叫它 Workflows），和新的 Skills 有啥区别？
| 维度 | Workflows (我的老方案) | Skills (新潮流) |
|---|---|---|
| 触发方式 | 我需要主动输入命令（/start 或 @文件） | AI 根据对话意图自动识别 |
| 目录结构 | 一个巨大的 .md 或 .yaml | 多目录结构，支持脚本和资源分离 |
| 自动执行 | 支持 // turbo 注解（部分步骤自动跑） | ❌ 暂时不支持，每一步都要确认 |
我的困惑
Skills 看起来确实更优雅、更符合"原生 AI 助手"的感觉。用户都不用知道什么配置文件，直接说话就行。
但我的工作流已经很稳定了，值得改吗？
六、让 AI 帮我分析：值得改造吗？
作为一个理性派，我决定让 AI 帮我做个决策。我把 Skills 的文档丢给它，让它对比我现有的方案，出一份分析报告。
AI 的分析非常犀利：
收益分析
- 自动发现 ⭐⭐⭐⭐：这是最大价值。对于不熟悉脚本的人来说，自动识别意图能极大地降低使用门槛。
- 结构契合 ⭐⭐⭐：我现有的节点化设计，天然就适合拆分成一个个 Skill。
- 职责分离 ⭐⭐⭐：每个 Skill 独立维护，这就很工程化。
风险分析
- 丢失
// turbo自动执行（🔴 高风险）：这是最大的倒退。Workflows 可以配置某些步骤自动执行（简单说就是"自动连招"，不需要我一步步点确认），但 Skills 目前为了安全，每个工具调用通常都需要用户点击确认（当然不同的调用环境和不同大模型可能会有差异）。这意味着我的交互次数会翻倍。 - 误触发（🟡 中风险）：有时候我只是想问个问题，AI 可能会误判我要写月报，加载一堆东西。
AI 的结论
建议暂不改造。
现有的"Document-as-Orchestrator"设计已经成熟稳定。Skills 主要解决"发现"问题，而你已经有成熟的触发机制。改造会丢失
// turbo的便利性，对于这种长流程任务，交互成本的增加不可忽视。
看，AI 有时候比人更理智。
七、但我还是决定试试看
理智告诉我听 AI 的，但直觉告诉我，新东西总得去踩踩坑才知道深浅。
虽然"暂不改造"的建议很合理，但我还是决定动手。
为什么？
- 代码洁癖犯了：原来的 14 个指令文件散落在文件夹里，Skills 的模块化结构确实看着更舒服，更像是一个正经的软件工程项目。
- 想亲身体验"自动发现"：道听途说不如亲自试试。我想看看现在的模型对于意图识别的准确率到底有多高。
- 拥抱变化：Skills 明显是未来的趋势。早点适应新的范式，总比守着旧代码强。
- 反正有 Git：大不了回滚嘛。
决定：Do it！
八、实践：9 个 Skills 的拆分与实施
说干就干。我把原来的 14 个节点逻辑，重新梳理整合成 9 个独立的 Skills：
| Skill | 职责 | 亮点 |
|---|---|---|
| blog_orchestrator | 总调度 | 相当于以前的 orchestration.yaml 管理者 |
| material_scan | 扫描 + 分块 | 专门解决 AI 记忆容量问题，可独立调用 |
| material_summarize | 摘要 + 主题 | 负责信息压缩，可独立调用 |
| series_planning | 内容规划 | 负责结构设计 |
| article_outlining | 大纲设计 | 细化到二级标题 |
| article_drafting | 撰写初稿 | 也就是"填空" |
| article_polishing | 润色审阅 | 负责风格统一，可独立调用 |
| image_prompting | 配图设计 | 新增：专门思考"这里该配什么图" |
| image_generation | 生成配图 | 负责画图 |
想先跑一个只做月报的精简版？我把这套链路压成了 4 个 Skill（编排、素材摄入、规划、撰写），思想和上面这张"博客向"拆分表一致，但场景更聚焦。我整理好后会传到 GitHub，见文末附录。
实施过程
整个迁移过程大约花了 1 个多小时。
- 创建
.agent/skills/目录结构。 - 把原来的指令文件搬运进去，按照 Skills 的格式（SKILL.md）重写。
- 然后就是漫长的测试，一个节点一个节点地跑。
一个插曲：让 AI 生成 AI Skills
实施过程中，我试着让 Claude Sonnet 4.5 直接帮我把现有工作流转换成 Skills。
我把所有文档丢给它，只说了一句："请根据我这个工作流，帮我转换成 SKILLS。" AI 倒是明白我想干什么，结果第一次跑起来直接翻车了。
我回去查了 Antigravity 的文档才发现两个问题：
- 路径错误：Antigravity 要求项目级 Skills 必须在
.agent/skills下，结果 AI 给我写到了.gemini/skills。 - 设计失误：它把我的整个工作流逻辑"揉"进了一个巨大的 Skill 里，完全违背了模块化的初衷。
我提示它："生成位置不对，应该在 .agent/skills 下，且 Skills 需要拆分成多个。" AI 马上反应过来，迅速处理成了我想要的版本。虽然没有一步到位，但也没走太多弯路。
九、复盘：改造后的真实体验
改造完到现在，我又用新版流程生成了两份月报。真实体验如何？
✅ 确实更好了
1. 自动发现真的方便
以前我得记得具体的命令。现在我只要在对话框里敲："帮我生成这个月的月报"，AI 就能自动弹出来："监测到你需要写月报，加载 Orchestrator Skill 中……"
这种体验确实很丝滑。
2. 意外之喜：独立调用
有一天我只想让 AI 帮我润色一段写给老板的汇报，我直接说："帮我润色这段话"。AI 自动调用了 article_polishing Skill。而在以前，我这个流程会稍麻烦，需要增加总调度文件或者单独写一个润色指令才行。这种模块化的复用能力，是 Skills 最大的优势。
写在最后：关于人与 AI 协作的几点思考
折腾这一圈下来，我收获的不只是一套能用的工作流，更是对"人机协作"这件事有了更深的体感。
一、AI 需要人的方向性指导
回顾整个过程，有一个现象让我印象深刻：AI 很难主动想到"节点化工作流"这种设计模式。
当我最初向 AI 描述月报生成的问题时，它给出的建议都是在"优化提示词"层面打转，换个更好的说法、多给几个示例对话、调整一下随机性……这些当然有用，但都是在"让 AI 一次性搞定"的框架里做优化。
是我坚持说："不，我要把它设计成一个状态机，每个节点只做一件事。"
AI 一开始甚至有点"不理解"为什么要这么复杂。但一旦我把这个设计思路传达清楚，它立刻就能理解，并且迅速帮我细化每个节点的职责、设计中间产物的格式、规划节点之间的依赖关系，落地执行的速度和质量都远超我自己动手。
这让我意识到：现阶段的 AI 更像是一个顶级的执行者，而不是架构师。它擅长在给定框架内把事情做好，但跳出框架、提出全新设计思路的能力还比较弱。人类的价值，恰恰在于提供这个方向性指导。
二、Workflows 和 Skills，并没有质的不同
从实际体验来看，改造成 Skills 之后，我的月报生成效率并没有显著提升。
核心任务还是那些任务，核心逻辑还是那套逻辑。变化的只是"怎么触发"和"怎么组织代码"。自动发现确实更优雅，但对于一个我每月只用一次、而且已经形成肌肉记忆的流程来说，这点便利性提升真的很有限。
反而是丢失了 // turbo 自动执行，让我每次都要多点十几次确认，净效率可能还下降了。
回头看，AI 当初给我的建议（"暂不改造"）其实是相当中肯的。它比我更理性，没有被新技术的光环冲昏头脑。
但话说回来，我肯定还是忍不住要去尝试的。因为探索本身的乐趣，以及在得到结论之前那段亲手验证的过程，往往才是最有价值的部分。结论可以听别人说，但体感只能自己攒。
三、Skills 不需要被神化，但官方设计确有高明之处
说实话，当 Skills 刚发布、社区一片热议的时候，我内心是有点不以为然的。
"这不就是我几个月前就在做的事情吗？把能力模块化、每个模块一个指令文件、通过文档来编排……" 核心思想上，我的 Workflows 和官方的 Skills 确实殊途同归。
但深入研究之后，我发现官方的 Skills 设计里，有一些我没有考虑到的东西：
- 标准化：统一的目录结构（
.agent/skills/）、统一的入口文件（SKILL.md）、统一的配置信息格式。这让不同人写的 Skills 可以互相兼容、互相组合。 - 可分发性：因为结构标准化了，Skills 就可以像手机 App 一样被分享和安装。今天我写了一个"润色"Skill，明天你可以直接拿去用。
- 生态思维：官方显然在下一盘更大的棋，不只是让你自己用得爽，而是要构建一个 Skills 生态。
我的方案是"目标导向"的，关注效率、关注功能本身，能跑就行。官方的方案是"平台导向"的，向上抽离了一层标准化和分发的逻辑，为生态扩展留出了空间。
从这个角度看，Skills 确实有成为"事实标准"的苗头。就像 Docker 统一了容器格式、npm 统一了 JS 包管理一样，谁能定义标准，谁就能主导生态。
所以我的结论是：Skills 不需要被神化，它的核心思想并不神秘；但官方的设计确实比我想得更远，这种"平台思维"值得学习。
我的工作流还会继续迭代。下一步，我打算研究一下怎么给 Skills 加上自动执行的脚本，把失去的效率找回来。
如果你也在用 AI 帮你处理复杂工作，或者对这套工作流感兴趣，欢迎在评论区交流。
附录：拿走即用
正文讲的是"为什么"，这里给你"怎么开始"。分两档：简单版直接复制下面的提示词就能用；进阶版是我把整套流程封装成的 Skills，晚点开源出来附地址。
简单版：五条提示词，接力生成
不用装任何东西，也不用建什么目录。打开你常用的 AI（ChatGPT、Claude、豆包都行），最好开一个新对话（保证上下文干净），把这个月的材料准备好，然后按顺序发下面五条提示词。
关键在于"接力"二字：每一条都吃上一条的输出。你要做的只有三件事，把材料喂进第 1 步、在标了【停下来确认】的地方看一眼、最后拿走成稿。
先花一分钟理解这条流水线在干什么，照着用才不会跑偏：
材料 → ①摘要压缩 → ②提炼主题 →【看一眼】→ ③搭大纲 →【看一眼】→ ④写初稿 → ⑤润色 →【看一眼】→ 成稿
（把长文变短） （抓住重点） （定结构） （填内容） （改语气）每一步都把上一步的产物"浓缩"一次，AI 每次只面对一小段信息，自然不会"消化不良"。
💡 用之前，把这两句话替换成你自己的情况：下面提示词里我预设了"汇报对象是直属领导、语气专业克制、篇幅 2000 字左右"。如果你写的是给同级同步的周报、或者更口语的团队汇报，直接在第 1 步开头加一句交代清楚，比如"这是给项目组同步用的，语气可以轻松点"，后面几步 AI 会自动跟着走。
第 1 步 · 摘要压缩
把散乱的材料先"压缩"成结构化摘要。这一步是整条流水线的地基，材料越多越要先做这一步。
我要写这个月的工作月报，汇报对象是直属领导，语气专业克制。下面是我这个月的原始材料（会议纪要、聊天记录、邮件、进度记录等，可能有点乱）。
请逐份帮我做结构化摘要，每份用这个格式输出：
- 来源：（这份材料是什么，如"10 月项目周会纪要"）
- 摘要：200 字以内，只保留有信息量的内容
- 关键事实：把涉及的项目名、人名、日期、数字、金额单独列出来
- 主题标签：这份材料属于哪些工作主题（如 #项目A #客户拜访）
三条硬要求：① 不要遗漏任何一份材料；② 绝对不要编造材料里没有的数字或结论，拿不准的标注"原文未明确"；③ 闲聊、无关内容可以跳过，但要在最后说明跳过了哪些。
材料如下：
【把这个月的材料全部粘贴到这里】
材料特别多（超过一两万字）发不进去？分几次发，每次开头都写一句"这是材料的第 X 部分，先摘要，等我发完再汇总"，全部发完再进第 2 步。
第 2 步 · 提炼主题（【停下来确认】）
从一堆摘要里抓出"这个月到底干了哪几件大事"。
基于上面所有摘要，帮我归纳出本月的 4 到 8 个核心工作主题。每个主题按这个格式：
- 主题名：一句话概括
- 重要程度：高 / 中 / 低（能进月报重点的才算高）
- 涉及的材料：这个主题是从哪几份摘要来的
列完后停下来，等我确认或补充，先别急着往下写大纲。
这是第一个把关点，花三十秒看一眼很值：
- 漏了？ 补一句："还有上周处理的那个线上故障，要单独算一个高优主题。"
- 把闲聊当正事了？ 直接说："客户那条只是日常寒暄，不用算主题。"
- 轻重不对？ "客户拜访应该是高，不是中。"
改完让它重新列一遍，满意了再进下一步。
第 3 步 · 搭大纲（【停下来确认】）
主题定了，先定"文章骨架"，别急着让它写正文。结构错了，写得再好也白搭。
主题确认了。请先给我一份月报大纲（先别写正文）：
- 先给整体结构，默认用这四块：本月概览 / 重点工作进展 / 问题与风险 / 下月计划（你可以根据实际情况增删）。
- 每个板块下列出二级标题，并在每个二级标题后面标注打算引用哪条关键事实（用第 1 步摘要里的数字、日期）。
- 高优主题多给篇幅，低优的可以合并成一句带过。
给完大纲停下来等我确认结构，我 OK 了你再动笔。
看结构、看顺序，觉得不对直接说：
- "OKR / 重点成果放最前面，领导先看这个。"
- "问题与风险那节太散，合并成一段。"
- "下月计划要具体到能落地，别写空话。"
第 4 步 · 写初稿
结构敲定，现在才让它填内容。
大纲 OK，按这个大纲写初稿。要求：
- 严格跟着大纲的结构和顺序，不要自己加戏；
- 用数据和结果说话，少用"有序推进""显著提升"这类空泛的词，能写具体数字就写数字；
- 每件事写清状态：已完成 / 进行中 / 受阻；
- 大纲里标了但材料没有的数据，留一个显眼的"（待补充：xxx）"占位，绝对不要自己编；
- 篇幅控制在 2000 字左右。
第 5 步 · 润色定稿（【停下来确认】）
最后一步，把初稿改成能直接交上去的样子。
帮我把这份初稿润色成可以直接提交的版本：
- 语气专业克制，删掉重复和空话；
- 开头加一段 3 到 5 句的概述，让领导 30 秒就能抓住本月重点；
- 检查每个数字、日期是否和前面的摘要一致，不一致的标出来问我；
- 改完之后，单独告诉我两件事：① 你主要动了哪些地方；② 还有哪些"（待补充）"需要我自己填。
拿到定稿，把"（待补充）"补齐、再通读一遍确认没有事实错误，就可以交了。
这套提示词建议存进备忘录或记事本，每个月直接套用，改改第 1 步开头的材料就行。想改成周报、季报，只要把第 3 步的默认结构换一下（比如周报改成"本周完成 / 遇到的问题 / 下周计划"）。
⚠️ 最容易踩的坑：图省事把五条一次性发出去。那就直接退回到正文开头说的"一次性投喂"老问题了，AI 一次要干五件事，反而哪件都做不好。一步一条，让中间产物先落地，才是它不"消化不良"的关键。
进阶版：封装成 Skills
如果你在用 Claude Code、Cursor、Antigravity 这类支持 Agent Skills 的工具，我把上面这套流程封装成了几个可以"一句话触发、自动接力"的 Skills。直接说"帮我写这个月的月报"，它就会自己走完摘要、主题、大纲、撰写、润色，并在关键节点停下来等你确认。
这部分已开源到 GitHub，附带安装说明。