很多人做AI自动写月报，最后卡住的不是Prompt，而是架构

我把一个月度流水归因报告系统，从“全塞进一个 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 很重要，但它更像最后一层包装。

真正决定系统能不能长期稳定跑下去的，是架构。