给 AI 立规矩：这一年的 Prompt 工程实践

太长不读：这一年我一直在做 AI 测试平台相关的项目，回头盘点，攒下最多的不是模型调参技巧，而是几百条写给 AI 看的「规矩」。这篇把这些规矩背后的经验整理了一遍。整理下来，有几处体会和我原来想的不太一样：一是 prompt 不是咒语，是规章制度，要当工程产物来养；二是规则管不管用不取决于措辞，取决于每条后面有没有贴着实测反例；三是确定性的操作一行都不该让模型做，把它请出循环，很多噪音会自己消失。读完这篇，大伙对「给 AI 写 prompt」这件事应该能有些更清晰的感知。

为什么 AI 产品需要规章制度

先说一个这一年最核心的认知：跑通一个 demo 和做出一个能用的产品，是两回事。

demo 阶段，模型答错一次，重新问一遍就好。产品阶段不行。用户点一下「生成用例」，背后是十几个 agent、几十轮调用，任何一环抽风，整条链路就废了。你没法跟用户说「再点一次试试」。

大模型最大的问题是什么？它什么都知道一点，但对你的业务一无所知。你不知道它什么时候自作主张，什么时候过度脑补，什么时候把你的禁令当成建议。

所以我很早就放弃了「信任模型」这条路。信任不是工程手段。可行的做法是：把模型当成一个能力很强、但没有丝毫公司常识的新员工，给它写规章制度。什么能做、什么不能做、遇到某种情况走哪个流程、不确定时怎么办，一条条写清楚。

这就是 prompt-as-code。prompt 不再是聊天框里随手敲的咒语，而是和代码一样，要评审、要版本管理、要迭代维护的工程产物。

铁律表：每条规则都要带实测反例

我维护的一个 CLI 工具里，给 AI agent 写了十来份 SKILL.md 操作手册。每份手册开头钉着一张编号铁律表，T0 到 T25、P1 到 P13，一条条排下来。

为什么要编号？为了出问题能精确引用。「你违反了 T7」比「你怎么又这样了」管用得多，和 code review 贴行号一个道理。

但光写规则没用。每条铁律后面必须附「实测踩坑」的反例。没有反例的条款只是许愿，有反例的条款才是规则。分享三个代价最大的。

第一条，思考不外露。 我写过一条「思考过程不许输出」，结果某次 agent 直接把这么一段吐了出来：

<thinking>现在进入入口门，弹窗前不许输出</thinking>

它把「不许输出」这条规则本身输出了，等于用违规的方式复述禁令。后来条款改成：思考内容、以及提到「不许输出思考」这句话本身，都不允许出现在输出里。反例贴在条款下方，之后再没人犯过。

第二条，路由规则锚在宾语上，别锚在动词上。 我一度把 skill 路由写成动词白名单：用户说「创建、新建、发起流程」时走某条链路。结果用户来一句「生成一个流程」，动词不在名单里，路由直接漏了。换个说法规则就失效，这种规则是纸糊的。改成锚定宾语之后：只要句子的宾语是「流程、编排、流水线」，无论用什么动词都路由过去，问题消失。

第三条，写正向要求，不写黑名单。 我要求输出必须是中文，最初写成「不要输出英文」。结果它输出了日语。黑名单永远列不完，世界上几千种语言，禁不过来。改成正向要求「所有输出一律使用中文」，一句话堵死所有可能。

这三条背后是同一个道理：写规则时，要假设执行者会字面理解你，并且总能在你没想到的地方翻车。带团队定流程，其实也是这个道理。

prompt 和代码的职责分层

第二个心得：判断和交互交给 prompt，确定性操作交给脚本，一行都不许模型手工做。

举个真实的例子。有一个环节叫物料替换：用例 JSON 里有一批占位符，要替换成实际物料值。这事看起来简单，但如果让模型逐条手工替换，它会漏两条、改错一条，顺手把 JSON 格式弄坏，然后输出一句「已全部替换完毕」。

后来我在铁律表里写死：不许模型逐条手工替换物料占位，替换必须走脚本。脚本就是个查表替换，几十行代码，百分之百可靠。模型只负责调用它。

分层的判断依据，可以总结成一张表：

活儿	交给谁	为什么
意图路由、对话、用例生成	模型（SKILL.md 里的 prompt）	没有标准答案，需要权衡判断
占位替换、轮询、渲染、格式校验	脚本	有标准答案，错不错一眼能看出来

我自己的土办法是问一句：这个操作写错了能立刻发现吗，能写单测吗？能，就该是代码。只有没有标准答案、需要权衡判断的事，才配交给模型。换句话说，模型只负责调脚本，不负责扮演脚本。

另外一个实践：共享规约按变更频率拆成独立文件。稳定的全局规则，比如输出语言、安全红线，放一份，几乎不动；易变的业务规则，比如路由表、场景清单，单独放，改起来不影响全局。思路和代码里拆配置文件一致。

把 AI 移出轮询循环

这一条是今年回报最高的一个设计。

场景：触发一个云端生成任务后，要轮询任务进度，把进度流实时渲染给用户。最自然的写法是让 agent 自己循环：查一次状态，说一句「还在生成中」，再查一次。

跑起来就知道，这是灾难。每轮 poll，模型都要冒一句旁白：「让我看看进度」「嗯还在跑」「快了快了」。几十轮下来，整个对话全是噪音，token 烧得心疼，它还时不时加戏，自己脑补进度。

解法：写一个脚本接管整个轮询加渲染循环，AI 只负责启动它，然后什么都不说，等它退出。

// 设计思想就一句话：
// 脚本接管轮询循环，AI 启动后保持沉默，退出码回来才开口

AI 在循环里，每一轮都是一次自由发挥的机会；AI 在循环外，它一次发挥的机会都没有。把 AI 移出循环，等于从根上消除了逐轮 poll 的旁白噪音。这个道理可以推广：凡是模型不需要做决策的循环，都不应该有模型。

领域知识要硬编码进 prompt

做测试平台的 prompt 工程，有个绕不开的问题：模型不懂你的领域。

你让它「设计测试用例」，它认识等价类、边界值这些词，但不知道什么场景该用决策表，什么场景该上状态迁移。所以我在生成用例的 prompt 里，把 14 种测试设计方法全硬编码了进去：等价类划分、边界值分析、决策表、因果图、场景法、状态迁移、正交实验……每种方法配上适用场景和判断条件。

这么多内容塞进 prompt，不怕长吗？怕。但比起生成一堆没法用的用例，我宁愿多花 token。领域知识不进 prompt，模型只会给你「看起来对」的东西，而「看起来对」是最可怕的，因为审查成本极高。

还有一个技巧：CoT 模板里放反面示例。我们的模板里专门有一大段反面示例，纠正模型过度推断意图的毛病。最典型的一条是「分析不等于生成用例」。用户说「帮我分析一下这个需求」，模型经常顺手把用例也生成了，它太想表现自己。反面示例里写得明明白白：这是分析阶段，只产出分析，不要多做。

带实习生也是这样。不但要告诉他该做什么，还得告诉他别多做。

规约的版本化治理

最后聊规模化的坑。

单个项目写十条铁律很轻松。当规约膨胀到一百五十多份 SKILL.md、整个团队都在改的时候，新问题出现了：有人随手改了一条路由规则，半个系统的行为都变了；有人把稳定规约和易变规约写在一个文件里，每次改动都牵一发动全身。

解法说实话都是软件工程里的老办法：

• 写保护守门：用 hooks 在文件写入前做校验，关键规约不许随便动，动了要留评审记录。和 CI 里的 lint 门禁一个意思。
• semver 版本管理：场景规约独立版本号，破坏性变更升 major，新增能力升 minor。引用方锁版本，和锁依赖版本一个道理。
• 按变更频率拆文件：稳定的一份，易变的一份，不搅在一起。

可以看到，prompt 工程做到后面，拼的不是「会不会跟 AI 聊天」，而是软件工程的老本行：模块化、版本管理、变更控制、评审流程。

写在最后

一年下来，最大的感受是：给 AI 立规矩和给人定流程，本质是一件事。区别只在于，AI 没有人情世故，没有默契，没有「你懂的」，你写下的每一个字都是它理解你意图的唯一线索。规则写糊了，它一定翻车给你看，而且翻得毫不留情。

规则系统本身有维护成本，铁律会过期、会打架、会被新的翻车现场推翻。所以别追求一次写完美，当代码养：踩一次坑，补一条反例，版本号慢慢往上滚。我那些编号到 T25 的铁律，也是一条一条翻车翻出来的。