让运营写一篇 Markdown 就给 AI 加能力：一个双轨技能层的设计

事实说明

经验来源: 本文来自我在一个生产级 AI 助手里设计「可维护技能层」的实践，已剥离具体业务背景，保留可迁移的架构与权限设计。
判断边界: "哪些能力可以下放给运营、哪些必须锁死"这条线，取决于你的业务里"改错了会造成什么后果"。本文给的是分轨方法，不是一份现成的权限清单。

问题：领域知识卡在研发节奏里

把一个 AI 助手做上线只是开始。上线后你会发现，最高频的迭代需求不是技术性的"换个更强的模型"，而是业务性的"这个常见异议换种说法更好""刚出的活动话术要补进去""这个政策解释得再清楚点"。这些都是运营的领域知识，本该由最懂业务的人随时调整，却因为"改 AI 的行为=改代码=排研发=等发版"而被卡在工程节奏里。

但你又不能把所有能力都开放给运营改。涉及精确数字、金额计算的输出，一旦被自由文本带偏就是事故。于是问题变成：怎么既让运营能自助迭代话术，又不让他们能碰到"改错了会算错钱"的那部分？

能力扩展的关键不是"全部开放"或"全部锁死"，而是按风险分轨。

核心机制一：两轨分工，一个入口

我把技能层分成两条轨道，用同一个命中入口统一调度：

确定性 Skill（不动）

涉及数字 / 结构化输出的能力，继续走"固定步骤取数 + 代码组装"，输出稳定、可单测、可追责——金额绝不交给模型自由发挥。

可维护 Skill（新增）

话术、政策解读、指引这类表达类能力，做成一个标准技能包——一篇带元信息的 Markdown 指令为主体，可附参考资料和辅助脚本。运营在后台编辑 Markdown 即可调整 AI 行为。

统一命中

两轨共用一个路由入口：确定性 Skill 按意图精确命中；可维护 Skill 靠"技能描述"让模型自己判断该不该用。它是一个全局能力池，任何场景都能调到合适的技能。

这套设计的产品含义是：同一个技能层，两种治理强度。把"改了会算错钱"的和"改了只是话术变好"的分开管理，前者留给代码，后者下放给运营。

核心机制二：三个正交开关，把权限切到刚刚好

"可维护"不等于"全可改"。我用三个相互独立的标志治理可维护技能，组合出"能不能用 / 能不能改 / 能不能跑脚本"的精确权限：

开关	控制什么	设计意图
enabled	能不能用	上线/下线开关，运营随时切。
editable	能不能改	平台预置的内置技能只读（运营能看、能启停，但不能改内容，防止误改官方话术）；运营自建的才可编辑。
trusted	能不能跑脚本	只有平台预置的可信技能允许运行附带脚本（在沙箱里），运营自建的技能永远不能执行脚本——把"运营上传一段代码到服务器跑"这条攻击面从机制上封死。

为什么是三个正交开关，而不是一个管理员权限

一个粗粒度的"管理员权限"大开关，要么给太多、要么给太少。把权限拆成三个正交维度，既给了运营自助的自由度，又为每一类风险（误改官方内容、任意代码执行）留了独立的闸——这比一个大开关安全得多。

核心机制三：脚本沙箱，给"能跑代码的技能"上铐

部分内置技能需要跑脚本算出确定的数据，再让模型基于这些数据组织话术。脚本执行是最大的安全面，所以沙箱做了多层约束：只允许白名单内的运行时、超时强杀、工作目录锁定防止越权读文件、剥离数据库密码等敏感环境变量、输出大小封顶、脚本出错就降级跳过而不是让整个回答失败。

还有一条铁律：数字一律由脚本算好原样透传，模型的正文只负责包装话术、不重算——把"模型乱算数字"的风险也关在门外。脚本算账，模型说话，两者职责严格分开。

核心机制四：命中即自动「喂事实」，杜绝编造

这是踩坑之后才补上的关键一环，也是我最想分享的一个教训。早期让 AI 写一段招募/介绍类文案，它编造了不存在的等级名称——凭空造出几个真实体系里根本没有的级别。根因是话术技能只有"怎么说"的指令，没有"事实是什么"的依据。

修法不是把规则写死进提示词（会过时、会与知识库打架），而是让技能在元信息里声明它需要什么上下文，命中时系统自动补齐：

知识库依据（强制喂）

命中即自动检索知识库相关制度，把真实的级别/规则直接塞进模型输入，并附硬约束"涉及级别、数字必须以下方依据为准，绝不编造"。这一步刻意绕过了营销场景默认跳过检索的设置——因为话术最需要事实兜底。

个体数据（按需取）

只有当用户明确要个性化时，模型才去拉真实的个体数据；普通通用文案不触发多余取数。

让 AI"不编造"的可靠办法，不是把规则写死进提示词，而是命中时把权威事实喂进去 + 明确禁止编造。

实测换更强的模型并不能根治编造——这是个"内容/数据问题"，不是"模型能力问题"。把事实喂到位，比堆更贵的模型有效得多。

一个顺带还清的工程债

上线这个技能层时要加一张数据库表，却发现项目的数据库迁移工具一直处于"不可用、想重置"的状态——根因是另一个框架把它自己的状态表建在了和业务表同一个命名空间里，两个"数据库管理者"互相打架，迁移工具每次都把对方的表当成"漂移"要求清库。

我没有绕过去，而是把对方的表连同数据迁移到独立命名空间，让两个管理者各管各的，顺手补齐了历史遗留的几处迁移缺口，让迁移工具恢复到"干净、可正常加新表"的状态。这次的债是"两个系统共用一个命名空间"——典型的边界没划清，绕过去会让后面每个加表的人都重新踩一遍。划清边界一次，所有人受益。

分期与衡量

这套技能层的推进顺序是先证明可控、再放开：一期用"文件 + 内置示例"验证双轨架构本身 → 二期开放后台 Markdown 编辑/启停 + 三标志分权 + 热生效 + 操作审计 → 三期才考虑对接外部技能生态。尤其"让运营改 AI 行为"这种高杠杆能力，必须先把分权和沙箱做扎实。

衡量上我盯几类信号：可维护技能的"编辑→生效"时长（从依赖发版的天级降到分钟级，是核心价值证明）；命中率与误命中率（technique 描述写得好不好的直接反馈）；以及一批"应该很少发生"的安全信号——沙箱脚本拒绝/超时次数、只读内容被尝试修改的拦截次数。这些信号不为零，恰恰说明分权机制在正确运转。最后还有一条质量红线：金额类回答仍由确定性轨产出的占比应为 100%，可维护轨绝不染指数字输出。

总结：能力开放不是非黑即白，而是按风险分级授权

这套设计留下三个我愿意反复讲的判断。第一，按风险分轨的治理：算钱的锁死在代码、话术的下放给运营，用一个命中入口统一调度——能力开放不是非黑即白。第二，三个正交开关的权限建模：把"能用/能改/能跑脚本"拆成独立标志，既给自助自由度，又把"任意代码执行"从机制上封死。第三，命中即喂事实：让 AI 不编造靠的是注入权威事实 + 禁止编造，而不是堆更强的模型。

把"给 AI 加能力"从一次研发排期变成一次 Markdown 编辑，提速的是迭代；而真正决定这件事能不能放心做的，是你在提速的同时把红线划得有多清楚。

欢迎通过邮件和我交流：shaoyanyan91@163.com