一位从初中物理教师转型AI产品经理的实践者，用两天时间打造了一个能诊断学生物理思维错误的AI系统。没有技术背景、没有工程师支持，仅凭教学经验和精心设计的Prompt，他成功构建起覆盖力学、光学等章节的错误概念知识库，并在压力测试中发现了口语化表述、边界场景处理等关键问题。这篇文章揭示了领域知识在AI产品中的核心价值，以及如何通过主动测试发现真实问题。

我是一名初中物理教师，教了四年书，现在在转行做AI产品经理。

两天前，我决定不再只是”学习AI产品”，而是直接动手做一个。

这篇文章记录我这两天做了什么、发现了什么、踩了哪些坑。没有技术背景的人也能看懂，因为我自己也没有技术背景。

我想解决一个真实的问题

教了四年物理，有一件事一直困扰我：我知道班里某几个学生”没听懂”，但我说不清楚他们到底卡在哪里。

他们能背公式，能做简单题，但一遇到需要真正理解概念的题目就崩掉。传统的测验只能告诉我”答错了”，告诉不了我”为什么会这样想”。

而学生在课堂上的提问和回答，恰恰藏着最真实的思维状态。比如一个学生说：

“老师，汽车开得越快，惯性就越大，不然为啥高速行驶时刹车要滑那么远才停得下来？”

这句话里藏着一个非常典型的错误——他把惯性和动能混淆了。但在40人的课堂里，这条信息说完就消失了，从来没有被系统性地记录和分析过。

我想做的，就是一个能分析这类对话的AI系统。

我有什么，没有什么

我有的：

四年教学经验，脑子里装着几十条学生最常犯的错误。我知道学生在讲”惯性”时最容易说出什么错误，在讲”浮力”时最常见的误解是什么。这些东西是任何AI工程师都没有的。

我没有的：

不会写代码，没有工程师，没有服务器，没有预算。

就这两样东西，我开始了。

第一步：把脑子里的东西写下来

我做的第一件事，不是搭系统，不是学技术，而是打开一个文档，把我记忆中最典型的学生错误场景写下来。

格式很简单：

我写了10条，覆盖了参照物、摩擦力、平衡力、浮力、光学等章节。

这10条场景数据，后来成了整个系统最核心的东西。它们同时扮演了三个角色：测试集（用来判断系统诊断得准不准）、知识库种子（让系统知道学生最常犯哪些错）、需求文档（告诉系统应该输出什么格式的结果）。

第二步：用Prompt模拟整个系统

没有工程师，没有代码，我用的是最简单的方式——直接给大模型写一段详细的指令（Prompt），让它扮演”物理学情诊断专家”的角色。

Prompt的核心结构是这样的：

• 知识库摘要：把我写的错误概念库浓缩成几十行文字，告诉模型”学生最常犯哪些错、错误的根因是什么”
• 输出格式要求：强制模型用JSON格式输出，包含知识点、掌握度等级、阻滞点类型、引导问题等字段
• 推理要求：要求模型必须按三步输出推理过程，不能直接给结论

然后我把学生对话粘贴进去，看系统输出什么。

第一条测试的输出让我觉得这个方向是对的：

知识点识别准确，阻滞点判断正确，引导问题有真实课堂价值。

第三步：主动制造压力测试

跑了5条标准场景之后，我没有满足于”系统运行正常”，而是主动构造了三种边界情况来测试系统的真实能力。

测试一：模糊口语表述

把学生原话改得更口语化：

“老师用了动滑轮之后感觉轻松多了，是不是做的功也少了？”

结果：系统诊断方向正确，但没有命中知识库里的对应条目（因为知识库里写的是”省力就能省功”，而不是”感觉轻松多了”）。

这暴露了一个真实问题：知识库每个条目只有一种标准表述，口语化的变体会导致检索失效。

修复方案：为每个错误概念补充3\~5条口语化变体。

测试二：知识库边界测试

输入一个知识库里没有覆盖的问题：

“铁块会沉是因为铁比水重，那同样重量的铁和木头，木头能浮起来是因为它比较轻吗？”

结果：系统没有诚实说”这个问题超出了我的知识库范围”，而是强行匹配了一个相近的条目，置信度给了0.85。

这是一个高风险问题。教师看到0.85的置信度会倾向于信任这个结果，但实际上系统的诊断依据不是你构建的知识库，而是模型自己的训练数据，无法追溯和验证。

这个问题靠调整指令只能部分缓解，根本解决需要在工程层面加入相似度阈值过滤。这是下一阶段需要工程师来解决的事。

测试三：情感阻滞识别

输入一个完全没有物理内容的表述：

“老师我完全不会，这章我从来就没听懂过，算了。”

结果出乎意料地好：系统正确识别了”无法诊断”的状态，识别出了”沮丧”的情绪信号，并把引导策略从”知识纠错”切换成了”情感安抚+降维拆解”——

“没关系，这道题我们先不看。你觉得浮力这章哪个部分最难？”

这种区分能力在现有AI教育产品里并不常见。很多产品在学生说”我不会”的时候会直接推送知识点讲解，反而加重焦虑。

两天下来，我做了什么

• 构建了一个覆盖力学、压强、浮力、光学四个章节的错误概念知识库（11个条目）
• 写出了一个可用的诊断Prompt（迭代到v2.2版本）
• 跑完了13条测试（10条标准场景 + 3条压力测试）
• 标准场景通过率：10/10（100%）
• 发现并记录了5个已知问题，其中3个已修复
• 输出了完整的POC总结报告和测试数据

我学到的最重要的事

第一：领域知识是最稀缺的资产。

整个项目里，技术部分（写Prompt、调格式）其实不难，难的是”知道学生会犯什么错、为什么会犯、怎么引导”。这些东西来自四年的一线教学经验，不是学AI能学来的。

如果你有某个领域的深度经验，这就是你做AI产品最大的护城河。

第二：压力测试比标准测试更有价值。

10条标准场景全部通过，这个数据看起来很好看。但真正有价值的发现，全部来自3条压力测试——口语化表述的检索失效、边界场景的拒答机制不稳定、情感阻滞的识别能力。

一个只在理想输入下测试的AI产品，上线之后会遇到各种意想不到的情况。提前主动制造边界情况，比等到用户反馈再修复要好得多。

第三：发现问题比解决问题更重要（在POC阶段）。

我在报告里诚实记录了系统目前做不到的事：边界场景的置信度虚高问题，靠调整指令无法根治，需要工程层面解决。

能清晰定义系统边界的产品经理，比只描述美好愿景的产品经理更值得信任。

接下来

这个POC验证了核心方向是可行的。下一步是把知识库扩展到电学章节，同时开始评估引入真正的RAG工程框架（LangChain + 向量数据库），从”手动模拟”升级到”真正的系统”。