夜雨聆风我把一个月度流水归因报告系统，从“全塞进一个 SKILL.md”改成分层架构后，才真正把自动化做稳。
很多人做 AI 自动化，第一反应都是调 Prompt。
报告写得不对，就继续补规则；结论不稳定，就继续加限制；模型偶尔翻车，就再写几个“注意事项”。
我一开始也是这么做的。
我做的是一个会员业务月度流水归因机器人。每月放入数据，AI 自动产出一份完整报告，回答管理层最关心的三个问题：这个月流水涨了还是跌了，为什么，会怎么影响后续。
最开始，我把方法论、业务规则、口径定义、执行步骤、数据表结构、术语解释，全都塞进一个 SKILL.md。
短期看，确实能跑起来。
但项目一复杂，问题马上暴露：
• 改一个口径，要在整份文档里到处找 • 文档改了，代码不一定同步改 • 模板改了，校验规则可能还停留在旧版本 • AI虽然“看起来都懂”，但一到跨模块任务就开始漏条件、漏同步、漏校验
我后来才意识到：问题不是 Prompt 不够好，而是信息组织方式不对。
很多 AI 自动化项目做不稳，不是输在模型，而是输在架构。
为什么一个文件越写越大，系统反而越不稳？
因为当知识、规则、执行、模板、校验全混在一起时，系统表面上是“集中”，本质上却是“失控”。
你以为你在维护一个文件，实际上你在同时维护五类完全不同的信息：
• 什么时候触发 • 业务规则是什么 • 代码具体怎么算 • 报告最终长什么样 • 跑出来之后怎么验错
这五件事放在一起，最大的风险不是难读，而是非常容易不同步。
我踩过一个很典型的坑。
文档里明明写的是“渠道筛选用精确匹配”，代码里却残留着：
df[df['渠道'].str.contains('目标渠道')]这段代码本来想筛“目标渠道”，但如果数据里存在“非目标渠道”这样的值，也会被一起匹配进去。
最麻烦的是：这个 bug 不会报错，数字也能正常跑出来，只是结果 quietly 地错了。
这类问题，靠补 Prompt 很难解决。因为它根本不是“模型没听话”，而是规则、实现、校验分散在不同地方，没有形成闭环。
真正有用的解法，不是继续补Prompt，而是先分层
我后来把整个系统重构成了 5 层。不是为了好看，而是为了让每一层只负责一件事。
project/├── SKILL.md ← 入口层：触发条件 + 方法论 + 执行规则├── knowledge/ ← 知识层：业务定义、口径、术语、模型├── scripts/ ← 执行层：分析、生成、校验├── templates / examples ← 输出层：报告长什么样、成品长什么样└── SYNC_CHECKLIST.md ← 防错层：每次修改后检查哪些地方必须同步这个分法背后，其实对应的是 5 个问题：
• 入口层：什么时候触发，AI该遵守什么边界？ • 知识层：业务规则到底是什么，指标口径怎么定义？ • 执行层：代码具体怎么算，怎么生成结果？ • 输出层：最后报告长什么样，什么算合格产物？ • 防错层：改完之后，怎么确保没有漏同步、漏校验、漏口径？
一旦这样拆开，很多以前纠缠不清的问题，就突然变得能管理了。
这套分层，真正解决了什么问题？
1. 改口径时，终于知道该改哪里
以前改一个规则，比如“商品价格分档从3档改成4档”，要在整份 SKILL.md 里到处搜“商品”，很容易漏。
现在就很清楚：
• 业务定义改在 knowledge/rules/• 计算逻辑改在 scripts/analyze.py• 改完后按 SYNC_CHECKLIST.md逐项核对
从“靠记忆维护”变成“按结构维护”，这是稳定性的分水岭。
2. 业务规则和代码实现终于解耦了
知识库负责回答“是什么”和“怎么算”；代码负责回答“怎么跑出来”。
这件事的价值非常大。
因为业务同事其实不需要看 Python，他们只需要看业务规则有没有写对；而开发时也不需要靠脑子记所有口径，直接回到知识库看权威定义就行。
很多自动化系统之所以越做越乱，本质上就是：规则散在脑子里，代码写在文件里，最后谁都不是权威。
3. 质量保障从“顺手检查”变成了独立层
这是我后来觉得最关键的一步。
很多人会把“校验”当成最后顺手做一下的事，但只要你的系统开始自动生成结论、自动产出报告、甚至自动发布，校验就不能再是附属动作。
我后来单独做了一个 validate_report.py，把质量检查拆成 4 层：
• P0：数字可溯源 • P1：业务规则合规 • P2：格式规范一致 • P3：模块间结果一致
再配合一个同步检查清单，整个流程就从“改完感觉差不多了”变成“改完必须过检查”。
这一步对自动化系统的意义，和单元测试对工程代码很像：不是让你写得更优雅，而是防止你下次改挂。
4. 为后续 Agent 化预留了空间
现在很多项目还停留在 Skill 模式：AI 按你写好的指令执行。
但如果以后要走向更强的 Agent 模式，让模型自己决定“这次该下钻哪个维度”“这段结论该引用哪条规则”，那知识库就不能继续是一坨写给人看的长文了。
它需要逐步变成可检索、可引用、可注入上下文的结构化资产。
所以现在做分层，不只是为了今天好维护，也是为了未来还能继续进化，而不是推倒重来。
我踩过的3个坑，几乎都不是模型问题
坑1：字符串模糊匹配，结果看起来正常，其实已经错了
str.contains('目标渠道')这种写法，最危险的地方不是“容易报错”，而是“不报错也错”。
它会把“非目标渠道”也匹配进去，最后数字能算出来、图也能画出来、报告甚至都能生成，但整个分析结论已经偏了。
这类问题说明：自动化最怕的不是系统挂掉，而是系统悄悄给你一个看起来很合理的错误答案。
坑2：同一个指标，在不同模块里口径可能本来就不一样
比如“总流水”这个词，我的报告里会出现两次：
• 一次是全渠道口径，用来看整体盘子 • 一次是单渠道口径，用来看归因变化
这两个数字不一样，恰恰是合理的。
如果系统里没有明确写清楚“这个模块用哪种口径”，后面的人只会觉得“怎么同一个指标前后打架了”。
所以很多时候，问题不是数字错了，而是口径没有被结构化地写清楚。
坑3：把当月结论写死在代码里，下个月一定翻车
“某某活动带动年卡增长”这种话，如果是本月根据数据分析出来的结论，就不应该被硬编码在生成器里。
否则本月对，下个月错；这个月像自动化，下个月就变成事故现场。
我后来强制要求：
• 所有叙述都必须从数据动态生成 • 代码里不能出现特定月份、活动名、百分比数字 • 每次改动后都要检查有没有硬编码残留
自动化系统一旦涉及自然语言输出，最危险的不是写不出来，而是复用上个月的话。
到最后我发现，分层的价值不是“整洁”，而是“防错”
很多人以为架构分层是工程洁癖，项目小的时候没必要。
但我自己的体感正好相反：越是一个人维护、越是业务规则多、越是希望 AI 自动产出能直接用，越要早点分层。
因为你真正要防的，从来不是“代码不好看”，而是下面这些问题：
• 改了规则，忘了改实现 • 改了模板，忘了改校验 • 改了口径，忘了同步旧模块 • 本月特殊逻辑被默默带到下个月 • 报告能生成，但结论已经偏了
这些问题没有一个是靠“把 Prompt 写得更长”能根治的。
它们本质上都是架构问题。
给想做AI自动化报告的人，5个最实用的建议
1. 先分层，再写 Prompt不要把触发规则、业务知识、执行逻辑、输出模板、质量校验塞进一个文件。 2. 把知识库当成权威定义，而不是零散备注它不一定今天就被模型直接读取，但它决定了你和 AI 是否真的在同一个口径上工作。 3. 把校验单独做成一层不要相信“AI大概率不会错”，自动化系统必须有独立的验证机制。 4. 消灭硬编码的当月信息任何特定月份、活动名、结论句式，只要写死在代码里，迟早会在下个月出事。 5. 用清单代替记忆一旦系统开始跨知识库、脚本、模板、校验联动，维护清单几乎是必需品。
最后一句
我后来越来越确定一件事：
AI 自动化项目的上限，往往不取决于 Prompt 有多会写，而取决于你的系统是不是把知识、规则、执行和校验分开了。
Prompt 很重要，但它更像最后一层包装。
真正决定系统能不能长期稳定跑下去的，是架构。
