教 AI 写工作月报：从一次性投喂到节点化工作流，再到 Skills 模块化改造
我是舸扬。记录 AI 探索与生活思考。在速成时代，坚持每篇文章都是一次深潜。行者开路，不随前尘。
每月最后要写月报的那几天，你是怎么过的？对着空白文档发呆？在网上搜索"月报模板"？还是对着散落在各处的会议纪要叹气？
作为一个"能用脚本绝不手动"的程序员，我决定给自己设计一套 AI 工作流来解决这个问题。从最初简单的"一次性投喂"，到后来设计出复杂的"节点化工作流"，再到最近紧跟技术潮流进行的 Skills 模块化改造——折腾这一圈下来，我不仅解放了写月报的双手，更对 AI 自动化助手的设计有了些新的体感。
TL;DR（太长不看版）
- 场景：月报素材散乱（会议纪要、聊天记录、邮件），一次性投喂导致 AI "消化不良"。
- 痛点：材料太长，AI 会"看了后面忘了前面"；而且每次都要重新教它格式，很麻烦。
- 解决方案：把大任务拆成小步骤，让 AI 一步步来，每一步的结果都存下来。后来又升级成了更模块化的 Skills 技能包。
- 核心洞见：AI 是很强的"执行者"，但需要人来指方向；用一个"进度表"文件来管理整个流程，效果拔群。
一、月报之痛：你也有过这种感觉吗？
每月最后几天，我都有一种熟悉的生理性抗拒。
打开文档准备写月报，才发现这个月做过的事情散落在各处：会议纪要在一个文件夹，项目进度在另一个表格，和客户的沟通记录在微信聊天里，还有几封重要邮件埋在收件箱深处……
光是把这些材料"物理搬运"到一起，就要花掉半天时间。等真正开始写的时候，大脑已经因为过载而罢工了。
写到一半，突然想起来：上周那个紧急问题的处理过程好像没记录？于是又开始翻找——群聊记录、文档备注、邮件……
最后往往是在临近提交前草草收尾，交上去一份自己都不太满意的流水账。
有一天我盯着屏幕想：这事儿不就是典型的"信息提取+结构化重组"吗？如果 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 知道下一步该写大纲了，完全无缝衔接。
💡 想看具体代码？ 如果你对
orchestration.yaml的结构和节点指令文件的写法感兴趣，我在文末的附录里放了完整的代码示例。
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 | 生成配图 | 负责画图 |
实施过程
整个迁移过程大约花了 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 帮你处理复杂工作，或者对这套工作流感兴趣，欢迎在评论区交流。
附录：技术细节
以下是给硬核玩家准备的代码示例。如果你只是想了解思路，上面的内容已经足够；如果你想动手实践，这些代码可以作为参考。
A. orchestration.yaml 完整示例
这是工作流的「大脑」，记录了整个流程的状态：
# orchestration.yaml - 工作流编排文件
version: "1.0"
project: "2024年1月工作月报"
current_phase: "INGEST" # 当前阶段
current_node: "summarize_chunks" # 当前执行到的节点
# 节点定义
nodes:
scan_materials:
status: "completed" # 已完成
output: "intermediate/scan_result.yaml"
completed_at: "2024-01-28T10:30:00"
split_chunks:
status: "completed"
output: "intermediate/chunks/"
completed_at: "2024-01-28T10:35:00"
summarize_chunks:
status: "running" # 正在执行
depends_on: ["split_chunks"]
prompt: "prompts/03_summarize.md"
output: "intermediate/summaries.yaml"
confirm_ingest:
status: "pending" # 等待中
type: "checkpoint" # 这是一个检查点，需要用户确认
depends_on: ["summarize_chunks"]
outline_article:
status: "blocked" # 被阻塞（因为前置节点未完成）
depends_on: ["confirm_ingest"]
prompt: "prompts/05_outline.md"
# 中间产物路径
intermediate_dir: "./intermediate"
output_dir: "./output"关键设计要点：
| 字段 | 说明 |
|---|---|
status | 节点状态：pending → running → completed，或 blocked 表示被依赖阻塞 |
depends_on | 依赖关系，AI 会自动判断哪些节点可以执行 |
type: checkpoint | 标记需要人工确认的节点，工作流会在这里暂停 |
output | 该节点产出的中间文件路径，供下游节点读取 |
B. 节点 Prompt 文件示例
每个节点都有一个对应的 Prompt 文件。以 03_summarize.md 为例：
# 节点：生成结构化摘要
## 你的任务
为每个 chunk 生成一份结构化摘要，方便后续节点快速理解内容。
## 输入
- 读取 `intermediate/chunks/` 目录下的所有分块文件
## 输出格式
为每个 chunk 生成如下结构的摘要，保存到 `intermediate/summaries.yaml`：
chunk_id: "chunk_01"
source_file: "会议纪要.md"
token_count: 1200
summary: |
本次会议讨论了项目 A 的上线时间表...
key_entities:
- type: "project"
name: "项目 A"
- type: "person"
name: "张三"
tags: ["项目进度", "上线计划"]
## 注意事项
1. 摘要控制在 200 字以内
2. 必须提取所有出现的人名、项目名、日期
3. tags 用于后续的主题聚类，尽量使用统一的词汇
## 完成后
更新 orchestration.yaml，将本节点状态改为 completed，
并将下一个节点 extract_topics 的状态改为 pending。Prompt 文件的标准结构：
- 任务描述：这一步要做什么
- 输入来源：从哪里读取数据
- 输出格式：产出物的具体结构
- 注意事项：质量要求和边界条件
- 完成动作：执行完后如何更新状态
这样的设计让每个节点都是自包含的——AI 只需要读取这个 Prompt 和对应的输入文件，就能独立完成任务，不需要知道整个工作流的全貌。