同样的模型，为什么效果差这么多
做AI应用的人，迟早会遇到这样一个困惑：
明明用的是同一个API，调用的是同一个模型，A项目的输出质量稳定、体验流畅；B项目的输出时好时坏，一旦输入稍微复杂就开始乱来。
直觉上，很多人会把问题归结到模型上——”是不是模型不够强？要不要换个更贵的？要不要微调？”
但如果仔细拆解那些效果好的项目，你会发现：模型本身的差异，往往不是主要原因。 真正的差距，在于工程设计——在于开发者在调用模型之前做了什么，以及怎么做的。
通常的误解：把工程问题当模型问题
AI应用开发中有一个常见的误区：当效果不好时，第一反应是”升级模型”或者”优化Prompt”，而不是审视整个系统的设计。
这个误区的代价很高。换模型解决不了设计问题，优化单条Prompt也解决不了系统性的结构问题。
真正的问题往往是：我们让AI去解决了一个没有被设计过的问题。
AI在处理清晰、有约束的问题时表现很好；在处理模糊、开放的问题时，表现则不稳定。工程设计的核心工作，就是把业务需求转化成AI能够稳定处理的问题——通过架构、流程、约束、规范，主动缩小AI的决策空间。
核心论点：AI工程化设计的本质
如果用一句话概括：
AI工程化设计的本质，是把人类的知识和判断，编码进AI的决策链路。
不是让AI更聪明，而是让AI面对一个被设计过的问题：更小、更清晰、约束更明确。
这件事有几种常见的形式：
- 流程拆解：把一个复杂任务分成多个阶段，AI每次只解决一个子问题
- 结构化输出：不让AI自由发挥，而是要求它在规定的格式和范围内输出
- 规范文件/模板：把领域知识外置成AI可以读取和遵循的约束
- 角色与边界：明确每个AI角色能做什么、不能做什么
- 确定性兜底：不该AI做决定的，用代码逻辑接管
每一种形式背后，都是同一个动作：人先想清楚，再告诉AI怎么想。
下面是两个案例：
案例一：OpenMAIC的设计拆解
OpenMAIC是一个开源的多智能体互动课堂平台。你告诉它”教我Python”，它能自动生成一堂完整的课——有幻灯片、有测验、有AI老师和AI同学实时互动。
这个项目是观察AI工程化设计的好样本，因为它的复杂度足够高，工程决策足够多，每一个关键设计都有明确的动机。
1.两阶段生成：把”发明”和”执行”分开
OpenMAIC生成课堂内容的方式，和一个真实的老师备课非常像：先列大纲，再逐个填充内容。
这个设计看起来简单，但它解决了一个重要问题：如果让AI一次性生成完整课堂，它需要同时处理”这堂课讲什么”和”每个知识点怎么呈现”两件事，认知负担大，输出质量不稳定。
拆成两阶段后，第一个AI只做课程规划，第二个AI只做内容生成。每一步的问题都更清晰，输出质量也更可控。
这里编码进去的人类知识是：好的教学内容需要先有结构，再有细节。 这是教育学的基本常识，工程师把它显式地设计进了生成流程。
2.Prompt模板化：把提示词当软件工程对象管理
OpenMAIC里有9套Prompt模板，分别用于生成大纲、幻灯片内容、测验题目、交互实验等不同场景。
如果把这9套模板全部硬编码在代码里，维护会非常痛苦——想调整教学风格要改代码，想支持多语言要改代码，想复用一段公共描述要复制粘贴。
项目的做法是把Prompt当配置文件来管理：
prompts/
├── templates/
│ ├── requirements-to-outlines/ # 用户需求 → 课堂大纲
│ ├── slide-content/ # 大纲 → 幻灯片内容
│ ├── quiz-content/ # 大纲 → 测验题目
│ └── ...
├── snippets/ # 公共片段，多个模板复用
│ ├── action-types.md
│ └── element-types.md
└── loader.ts # 加载、替换变量、组装通过{{snippet:action-types}}引用公共片段，通过{{language}}注入运行时变量。调整教学风格只需要改Markdown文件，不用动代码。
这不只是一个工程技巧，背后的思路是：Prompt本身是系统设计的一部分，应该用软件工程的方式管理——模块化、复用、和业务逻辑解耦。 当一个系统里的Prompt数量增长到一定程度，这种管理方式带来的收益会显著高于它的成本。
3.Director模式：用规则约束多Agent的协调
OpenMAIC最有设计感的部分是多Agent的协调方式。
课堂里有多个AI角色：老师、助教、学生。谁来控制”下一个该谁说话”？项目引入了一个专门的”导演”AI，它的唯一职责就是做这个调度决策：
导演的输出非常简单，只有三种：让某个角色说话、让用户说话、结束对话。
但关键在于：导演的Prompt里，编码了一套课堂互动的规则——
- 角色多样性：老师说完应该让学生或助教接，而不是连续让两个老师发言
- 内容去重：如果某个知识点已经解释清楚了，不要再让其他角色重复
- 讨论节奏：好的节奏是”解释→提问→深入→不同视角→总结”，不是”解释→重复→换个说法再解释”
这些规则，是有经验的教师对课堂节奏的判断——工程师把它写进了Prompt，变成了导演AI的决策依据。
与此同时，项目还做了一个优化：不是所有情况都需要调用AI来决策。如果只有一个Agent，直接用代码逻辑派发，不调用AI。把确定性的判断还给代码，只在真正需要灵活决策的地方才用AI——这本身也是工程化设计的一部分。
4.角色约束：在Prompt里定义边界
多Agent系统有一个典型问题：AI角色会”越界”。如果不加约束，学生角色的AI会讲出老师级别的长篇大论，破坏课堂的角色感。
OpenMAIC的做法是在角色Prompt里反复强调边界：
“你是学生，不是老师。你的回复应该比老师短得多。用简短、自然的反应：一个问题、一个笑话、一个简短的见解。不要主动使用白板，除非老师明确邀请你。”
同时，系统还通过”同伴上下文”机制，让每个Agent看到前面已经说了什么，避免内容重复。以及”白板操作日志”，让每个Agent知道白板上已经有什么，避免重复绘制或位置冲突。
这些机制解决的问题本质上是”社会性”的——如何让多个独立的AI在同一个空间里协作而不产生冲突。纯靠Prompt很难完美解决，需要代码层面的状态管理配合。
5.输出设计：文字和动作交错
在真实课堂里，老师不是先讲完所有话再操作PPT，而是边讲边操作。OpenMAIC要求Agent的输出也是这样的结构：
这个设计里有一个主动放弃的选择：没有用Function Calling，也没有用ReAct循环，而是”单次生成、文字动作交错”。
原因是：Function Calling和ReAct适合”探索式推理”——AI需要根据中间结果调整后续行为。但课堂教学是”连续输出”——老师讲课不会每画一笔就停下来看效果再决定下一步。选最简单的、最匹配场景交互模式的方案，不是偷懒，是判断。
案例二：图文生成的模板决策
在做AI生成图文内容的项目时，有两种典型的实现路径：
方案A：给AI开放问题
只提供画布大小，让AI自己决定内容、位置、样式和排版。实现简单，理论上最灵活。
但实践中问题很多：内容质量不稳定，元素位置可能冲突，视觉效果依赖AI的”审美”——而AI的审美是不可预测的，也是很难通过Prompt稳定控制的。
方案B：给AI约束问题
提供一套模板库，每个模板对应一个规范文件。规范文件包含两类信息：
- 视觉风格约束：色调、背景色、边框样式、间距规则——定义这个模板”长什么样”
- 布局数据结构：用结构化的方式描述内容的排布方式——定义这个模板”怎么放内容”
AI拿到用户主题后，先分析主题的性质和调性，判断它适合什么样的视觉风格和呈现方式，然后从模板库中匹配最合适的模板，最后按照规范文件的布局结构生成填充数据。
方案B在质量、稳定性和可扩展性上都明显更好——但代价是灵活性受限，以及需要投入设计模板和规范文件的工作量。
这个取舍是值得的。更重要的是，理解为什么值得：
方案A里，AI需要同时解决”内容创作”、”视觉设计”和”排版布局”三类问题。这三类问题的知识来源不同，评估标准也不同，混在一起让AI一次性处理，每一个都做不好。
方案B把视觉设计和排版布局这两类问题，从AI的决策空间里拿出来，交给模板设计师提前解决。AI只剩”内容创作”和”模板匹配”——这是AI真正擅长的部分。
模板规范文件不只是”给AI参考的文档”，它是设计师经验的编码产物。 一个设计师在设计模板时，已经做好了大量判断：这个主题适合冷色调还是暖色调，内容应该用列表还是卡片，标题和正文的间距应该是多少。这些判断被固化进规范文件，AI在使用时直接继承，不需要从头发明。
这和OpenMAIC把Prompt当配置文件管理是同一个思路的不同体现：把人类的专业判断，结构化地注入AI的决策链路。
系统的可扩展性也由此而来：增加新模板，等于把新的设计判断注入进系统，AI的能力边界随之扩展。这是一种可预测的、线性的增长方式——比试图让AI自己学会更多风格要可靠得多。
设计AI决策空间的几个方法
综合两个案例，可以提炼出几个通用的设计手法：
1. 分阶段拆解任务
把一个复杂任务拆成多个阶段，每个阶段只解决一类问题。OpenMAIC的两阶段生成、先选模板再填内容，都是这个思路。好处是每一步的问题更清晰，输出更可控，也更容易单独优化和调试。
2. 结构化输出
明确规定AI输出的格式，而不是让AI自由输出文本。代价是需要处理格式错误和容错，但换来的是输出可以被可靠地解析和执行。OpenMAIC的三层JSON修复机制，是为结构化输出付出的工程成本的体现——但这个成本是值得的。
3. 领域知识外置
把需要领域专业性的判断，从AI的决策中剥离出来，以配置文件、模板、规范文档的形式外置。AI调用这些外置的知识，而不是从头发明。Prompt模板库、模板规范文件，都是这种形式。
4. 明确角色与边界
在多Agent场景中，每个角色能做什么、不能做什么，要通过Prompt明确告知，必要时用代码层面的状态管理配合强化。角色边界模糊，是多Agent系统最常见的质量问题来源之一。
5. 确定性逻辑兜底
不是所有决策都需要AI来做。当判断条件明确、结果确定时，用代码逻辑处理，不调用AI。OpenMAIC的导演在只有一个Agent时直接用代码派发，就是这个原则。过度使用AI处理本可以确定性处理的问题，是一种常见的工程浪费。
结语：工程能力是AI应用真正的护城河
AI模型正在快速商品化。各家大模型的能力差距在收窄，价格越来越低，切换成本越来越小。
在这个趋势下，AI应用的竞争重心，正在从”用什么模型”转向”怎么设计系统”。
工程化设计能力——识别哪些判断应该由人来做，然后把它结构化地编码进系统——这种能力不随模型更新而贬值，也无法通过调用更贵的API来复制。
它是人对问题域的深度理解，是对AI能力边界的准确判断，是把业务知识转化为系统约束的工程实践。
对一个AI应用来说，工程设计决定的不只是”好不好用”，而是整个应用能否成立。一个设计粗糙的系统，即使今天用最新的模型勉强跑通，换个输入场景就会暴露问题；而一个设计扎实的系统，随着模型能力的提升，效果会自然跟着提升——因为它的结构本身是健康的。
在AI能力快速演进、模型选择越来越多的今天，工程设计能力是少数几件真正值得长期投入的事之一。
这才是AI应用真正的护城河。
