规则固化-脚本-模板三层封装法

方法定义

把一个重复性交付任务拆成"规则说明 + 确定性脚本 + 版式模板"三层，分别交给最合适的载体处理，最后保留人工审核作为闭环。在本案例中，这三层被统一封装进一个 Claude Skill（engineering-monthly-report-generator）。

三层各自的职责

• 规则层（SKILL.md / 提示说明）：用稳定语言描述任务目标、字段约束、步骤顺序、输出要求。承担"模型必须遵守的规则"。
• 脚本层（Python 等）：处理读表、筛选、字段映射、文件生成等可形式化操作。承担"确定性、不可让模型自由发挥的部分"。
• 模板层（.docx 等模板 + 样式参考）：把表格样式、段落格式、版式要求交给模板资源，而不是要求模型每次凭语言重建。

三阶段演进逻辑（来自本案例）

1. 直接提示词：规则只写在对话里。问题：格式不稳定（月份、编号、表格样式漂移）。
2. Markdown 提示文件：规则保存为文件希望复用。问题：跨会话不持久、上下文长度受限、缺少明确可执行步骤。
3. Skill 封装：规则 + 脚本 + 模板一起打包。问题：源表字段、规则、模板变化时需同步维护。

适合的使用场景

• 每月/每季/每周需要重复生成的同结构报告。
• 输入字段稳定（列名、单位、含义固定）。
• 输出格式固定（同一份 Word/Excel/PDF 模板）。
• 团队或个人对该任务的流程已经熟练。

不适合的场景

• 输入字段或筛选逻辑频繁变化。
• 任务只发生一两次（封装成本高于收益）。
• 输出样式需要每次重新设计。
• 对错误零容忍、不允许人工复核的高风险交付。

关键经验

• 直接聊天适合"探索和试错"，难以稳定承担每月相同的正式文件生产。
• 把可形式化的步骤交给脚本，把版式交给模板资源，把主观判断留给人工。
• 封装不等于零维护。源数据、规则、模板任一变化都要同步修改对应文件。

与其他方法的关系

• 与 文件夹触发式 PDF 翻译工作流 同属"封装 AI 任务为可重复工作流"思路，但具体技术路径不同：文件夹触发式 PDF 翻译依赖 GitHub Actions，本方法依赖 Claude Skills + 本地脚本。
• 不构成直接重复或替代关系，可视为同一思路在不同交付场景下的两种实现。

来源边界

• 该方法的具体三层结构来自 SRC-WORK-002 单一案例的归纳，未在其他作者作品中得到独立验证。
• 不应将本方法描述为"Claude Skill 的通用做法"或"任何报告自动化的标准流程"。