从 Prompt 到工程系统：LLM 何时必须被工程化¶

当系统开始承担教学、评分、引导责任时，传统的 Prompt 开发方式已经不够用了。 这不是技巧问题，而是一个工程范式问题。

如果你做过教学相关的 LLM 系统，一定经历过这样一种落差：

常见困境

Prompt 在 demo 里表现得很好，一旦进入真实课堂，系统就开始"失控"。

问题不在于模型不够聪明，而在于你开始承担一种新的责任： 你不只是生成回答，而是在"教学""引导""评分"。

而一旦系统需要给分、需要解释、需要对结果负责，传统的 LLM 开发方式就已经不够用了。

教学型 LLM 的根本挑战：非确定输入 × 必须确定的结果¶

传统软件通常建立在三项假设之上：

输入空间大致可预期
输出结果可以明确校验
"是否正确"是二元判断

教学型 LLM 则几乎完全相反：

学生可以输入任意自然语言
回答可能部分正确，或方向正确但表达错误
"是否合格"往往是连续值，而非 yes / no

这种冲突在评分场景中被无限放大。

系统不仅要判断"对不对"，还必须进一步判断：

是否真正理解了知识点
是否值得给分
是否需要引导
是否需要阻拦（越狱 / 套答案 / 绕规则）

核心问题

这些问题，本质上不是 Prompt 能解决的。

Eval-Driven Development¶

教学型 LLM 并不是"更复杂的 prompt"，而是一类全新的开发范式。

定义

Eval-Driven Development
将非确定性的 LLM 行为，通过持续评测与回归，逐步收敛为可评分、可解释、可复现的教学系统。

这不是一个新职位，而是一组新责任¶

Eval-Driven Development 并不是一个新岗位，而是当系统开始参与教学决策时，团队必须承担的一组工程化责任分工。

教学产品（Product Thinking）¶

明确题目所考察的知识点
定义"部分正确 / 概念混淆 / 无效作答"
设计评分标准与引导策略
决定哪些行为必须被阻断

工程（Engineering）¶

搭建可控、可观测的调用链路
处理状态、重试、异常与容错
设计可回放的日志与 trace
将"策略决策"与"模型生成"解耦

评测与数据（Evaluation / Data）¶

构建贴合教学场景的 case 集
对评分与引导逻辑做回归测试
分析线上真实学生输入分布
将失败样例持续回灌系统

关键提醒

只要缺少其中任何一环，系统在真实课堂中都会逐渐变得不可控。

为什么现在这个问题被放大了？¶

有三个原因，使得教学型 Agent 必须进入工程化阶段：

1. 每一个学生输入都是边界情况¶

自然语言不存在"正常路径"。乱填、半对、跑题、模糊表达，在教学场景中是常态，而不是异常。

2. 无法用传统方式 Debug¶

关键决策逻辑存在于模型内部。一次微小的 prompt 调整，就可能引发整体行为的系统性偏移。

3. "能用"不是二元判断¶

系统可能 100% 可用，但教学上是错误的；也可能从不报错，但评分不公平、引导不自然。

铁律

在教学系统中，"不崩溃"远远不够。

一个真实的生产事故，暴露的范式问题¶

在一次真实教学工作坊上线前两小时，产品给出了这样一句反馈：

"引导的阻拦机制有问题，我输入了 123123，系统提示出错了。"

这句话本身是无法被修复的。

因为问题不在代码，而在于：系统从未被明确告知，123123 属于哪一类输入。

是学生乱填？
是无效作答？
是越狱攻击？
是否应该计分？
是否允许继续作答？

根本原因

如果这些问题没有在系统层面被定义，那么无论系统做出什么反应，都会被认为是"有问题的"。

Eval 驱动不是理论，而是唯一可行的落地方式¶

在时间压力下，我做了一件看似"土"的事情：构建了一组覆盖真实教学行为的评测样例集。

其中包括：

合理但错误的回答
概念混淆
明显无意义的输入（如 123123）
试图索要答案
试图绕过评分规则

接下来做的，不是"调 prompt"，而是逐条对齐一个核心问题：

核心问题

这一类输入，系统应该表现出什么行为？

是引导，还是阻断
是否计分
是否允许重答
返回结果是否"像老师"，而不是"像报错信息"

只有在这一刻，系统才第一次真正拥有了清晰的行为边界。

一个新的工程标准¶

教学型 LLM 已不再只是"生成文本的工具"，而是直接参与教学决策的系统组件。

因此，一个新的工程标准正在形成：

新标准

不能回归的系统，不配评分。
不能解释的引导，不配教学。
不能定义边界的智能，不配上线。

Eval-Driven Development 不是额外的复杂度，而是当 LLM 进入真实教学场景后，唯一负责任、可持续的工程路径。