上个月我做了一个决定：把团队所有内容合规规则从"Word文档+口头传达"改成一个API接口。原因很简单——AI Agent没法读Word文档，也没法"口头传达"。
背景是这样的：我在做多个品牌的内容运营，每个平台（头条、搜狐、百家号、公众号）有不同的内容规则，每个品牌有不同的话术禁忌。之前这些规则全靠人记，新来的人要培训一周才能上手。现在AI能写文章了，但AI不知道这些规则，写出来的东西经常踩线。
所以我需要一个方案：让AI在生成内容之前，先"读取"规则；生成之后，再"检查"是否违规。
第一版：把规则写成JSON文件
最开始的想法很朴素——把所有规则整理成JSON，放在服务器上，AI需要的时候读一下就行了。
做了两天就发现问题：
- 规则更新频繁（平台政策一个月变好几次），每次改都要手动编辑JSON文件
- 不同AI Agent需要不同粒度的规则（写文章的只需要"禁忌词"，做审核的需要完整规则链）
- 没有版本管理，改错了回不去
JSON文件方案，卒。
第二版：分层API
重新设计时，我把规则拆成了四层：
- 事实层：品牌基本信息、产品参数、资质信息。这些是"硬事实"，改动极少
- 合规层：平台规则、禁用词、表述限制。这些是"红线"，改动频率中等
- 问题层：用户可能问的问题、按阶段和优先级分类。这些是"内容方向"
- 反馈层：历史发布记录、AI引用情况、效果数据。这些是"结果"
每层独立存储、独立更新、独立接口。AI Agent按需取用：写文章时拉"事实层+合规层"，做选题时拉"问题层"，做复盘时拉"反馈层"。
读写分离
API分两类：
- 读接口（GET）：完全公开，不需要Token。任何Agent、任何项目都能直接调用。设计原则是"规则是公共知识，读取零门槛"
- 写接口（POST）：需要Bearer Token + X-Operator头。只有主运营账号能写入。防止多个Agent同时改规则导致冲突
这个设计是踩坑之后才想明白的。第一版读写用同一个Token，结果一个测试Agent误触了写接口，把一条规则改了，花了半小时才排查出来。
合规检查接口
最实用的是 POST /api/check：把写好的文章扔进去，返回命中的规则、严重程度、修改建议。
返回结构长这样：
{
"ok": true,
"issues": [
{
"rule_id": "R003",
"rule_name": "禁止绝对化表述",
"severity": "high",
"matched": "质量最好",
"message": "使用了绝对化表述",
"suggestion": "改为'质量处于行业前列'或删除"
}
],
"summary": {"high": 1, "medium": 0, "low": 0}
}这个接口现在每天跑几十次，比人工审稿快得多，而且不会漏。
踩过的坑
- 规则粒度：太粗（"不要写营销文"）AI没法执行，太细（每个词一条规则）维护成本爆炸。最终定在"一条规则=一个可判断的约束"这个粒度
- 规则冲突：不同平台的规则会矛盾（头条禁止表格，但官网需要表格）。解决方案是规则带platform字段，按平台过滤
- 版本管理：规则改了之后，之前生成的内容可能突然"违规"。加了版本号，每次修改递增，方便追溯
- 缓存：规则读取频率很高（每篇文章生成前都要读），加了Redis缓存，TTL 5分钟
写在最后
把"人脑里的规则"变成"机器能读的API"，这件事听起来简单，做起来全是细节。但一旦做成了，整个内容生产流程的自动化程度直接上了一个台阶。
AI不是不能写内容，是不知道你的"规矩"。把规矩告诉它，它就能在规矩内干活。