1. 拍照解题这件事为什么值得用 DeepSeek 加 Dify 重做一遍拍照解题不算新需求。学生拍一道题、上传、等答案这个动作在过去几年已经被各种 App 教育得很成熟了。但真正自己动手做过的人都知道市面上大多数方案要么是套壳搜题——图片走 OCR 拿到题干再去题库里做文本匹配遇到题库里没有的题就直接歇菜要么是纯大模型硬解——把图片丢给多模态模型让它看图说话结果公式识别错、几何图看不懂、步骤跳得比老师还快最后答案对了过程全错。我这次想聊的方案是把DeepSeek的推理能力和Dify的工作流编排能力拼在一起做一套自己能掌控、能改、能私有化部署的智能拍照解题系统。核心思路很直接Dify 负责流程调度和上下文管理DeepSeek 负责看懂题、想清楚、讲明白。图片进来先做预处理和识别识别结果进工作流工作流里做题型判断、知识检索、分步推理最后输出一份带解题步骤和知识点标注的答案。这套东西适合谁我梳理了三类人。第一类是独立开发者或小团队想做一个垂直的解题工具但不想从零训练模型、不想维护庞大的题库第二类是教育机构的教研或技术同学希望把机构自己的题库、讲义、错题本接进解题流程让答案更贴合自己的教学体系第三类是想学 Dify 工作流和大模型 API 调用的技术爱好者拍照解题是一个非常好的练手项目因为它同时涉及多模态输入、条件分支、知识库检索、变量聚合、长上下文处理这几个 Dify 的核心能力。先说清楚这套方案的边界。它不是一个拍什么都能解的万能工具数学、物理、化学这类有明确推理链条、答案可验证的题目效果最好语文阅读理解、开放性作文这类主观题它能给思路但给不了标准答案。另外拍照解题的准确率高度依赖图片质量手写体、复杂公式、带图的几何题识别环节就是第一道坎。这些坑我在后面会一个个拆开讲。我自己的判断是这套方案真正的价值不在于替代老师而在于把解题过程结构化。一道题从图片到答案中间经过了识别、分类、检索、推理、校验五个环节每个环节都可以单独优化、单独替换。这种可拆解性才是它比一个黑盒 App更值得动手做的原因。2. 整体架构怎么搭Dify 工作流与 DeepSeek 的分工逻辑2.1 为什么是 Dify 而不是自己写后端很多人第一反应是我直接写个 Python 服务调 DeepSeek 的 API 不就行了为什么要套一层 Dify这个问题我认真想过也两种都试过。自己写后端的优势是自由但劣势在拍照解题这个场景里被放大了。拍照解题的流程不是线性的。图片进来之后要先判断是不是题目图片、判断题型、决定要不要查知识库、决定用哪个提示词模板、处理超长上下文、最后还要做答案格式化和校验。这些判断如果用代码写就是一堆 if-else 和状态管理改一个环节要动整个服务。而 Dify 的工作流本质上是把 if-else 可视化成了节点和连线条件分支、变量聚合、知识库检索都是现成节点改流程不用改代码。更关键的是上下文管理。拍照解题经常遇到多轮追问——学生看完答案问第二步为什么这么变形这时候需要把上一轮的题目、答案、对话历史一起带进新的推理。Dify 的会话变量和上下文机制能比较自然地处理这个自己写的话得维护一套 session 存储。热词里出现的dify工作流 上下文超长就是这个场景的典型痛点后面我会专门讲怎么处理。当然Dify 不是没有代价。它的抽象层会带来一定的调试难度出问题的时候你看到的是节点报错而不是清晰的堆栈。所以我的建议是流程编排用 Dify核心的识别和推理逻辑尽量封装成独立的 API 或插件这样既能享受编排的便利又能在出问题时快速定位。2.2 DeepSeek 在这套系统里承担什么角色DeepSeek 在这套方案里不是一个模型而是两个不同职责的调用这一点很多人一开始会混淆。第一个职责是题目理解和推理。这是主力用的是 DeepSeek 的推理能力。它的强项在于数学推导和逻辑链条尤其是带步骤的解题它能把中间过程讲清楚而不是直接甩答案。这一点对教育场景特别重要因为学生要的是怎么想出来的不是答案是多少。第二个职责是辅助判断和格式化。比如判断这道题属于哪个知识点、把推理结果整理成固定格式、生成相似题推荐。这类任务对推理深度要求不高但对稳定性和格式遵循要求高可以用同一个模型配合不同的提示词来完成。这里有个选型上的细节值得说。DeepSeek 有不同规格的模型推理强的版本适合做核心解题响应快的版本适合做分类和格式化。如果你的部署环境资源有限可以只用一个版本但要在提示词上做区分。热词里vllm部署deepseek和本地部署deepseek说明很多人是走私有化路线的这种情况下模型规格的选择直接决定了硬件成本后面部署章节会展开。2.3 图片识别环节放在哪里这是架构设计里最容易踩坑的地方。有两种做法一是把图片直接丢给多模态模型让它一步到位输出题干和答案二是先用 OCR 或专门的公式识别把图片转成文本再进工作流。我强烈建议走第二条路原因有三个。第一多模态模型对复杂公式和几何图形的识别准确率不稳定尤其是手写体和印刷体混排的时候第二OCR 的结果是文本文本可以进知识库检索、可以做关键词匹配、可以人工校对而多模态模型的输出是个黑盒第三识别和解题分离之后识别错了可以单独换识别引擎不用动整个解题流程。具体来说识别环节可以拆成两步通用文字识别处理题干文字公式识别处理数学表达式。公式识别建议输出 LaTeX 格式因为 LaTeX 是结构化的后续无论是给模型推理还是渲染给用户看都比纯文本可靠。这一步的产物是一段干净的题干文本它才是进入 Dify 工作流的真正输入。提示识别环节一定要保留原始图片和识别结果的对应关系。学生反馈识别错了的时候你需要能快速定位是识别问题还是推理问题这个对应关系是排查的基础。3. 核心环节拆解从一张照片到一份解题报告3.1 图片预处理与识别别小看这一步拍照解题的准确率一半死在识别上。我见过太多方案模型能力很强但学生拍的照片是斜的、有阴影的、题目旁边还有上一题的残留识别出来一团糟后面再强也没用。预处理我一般做四件事。第一是纠偏和裁剪把倾斜的图片摆正把题目区域裁出来去掉无关的桌面、手指、其他题目。这一步可以用传统的图像处理做也可以用轻量的检测模型。第二是增强对比度尤其是铅笔手写或者光线不足的照片二值化或者自适应直方图均衡能明显提升识别率。第三是分辨率控制图片太大识别慢、太小识别不准一般把长边控制在 1500 到 2000 像素之间比较平衡。第四是格式统一统一转成模型和识别引擎都友好的格式。识别环节的选型上通用文字识别现在成熟度很高印刷体基本没问题手写体看具体引擎。公式识别是难点建议选专门做数学公式识别的方案输出 LaTeX。这里有个经验识别结果不要直接信要加一层校验。比如识别出来的 LaTeX 能不能正常渲染、括号是否配对、有没有明显的乱码字符。校验不通过的要么重新识别要么提示用户重拍而不是硬着头皮往下走。3.2 题型判断与路由让不同的题走不同的路题干文本拿到之后不要急着解题先做题型判断。这一步决定了后面走哪条分支是整个工作流的枢纽。我的分类维度一般是这样学科数学、物理、化学等、题型选择题、填空题、解答题、证明题、是否需要知识库纯计算题不需要概念题和需要引用定理的题需要、是否含图含几何图的题要特殊处理。这个判断用 DeepSeek 来做很合适给它一段题干让它输出结构化的分类结果比如 JSON 格式的学科、题型、难度、知识点标签。为什么要结构化因为 Dify 的条件分支节点需要明确的判断依据JSON 里的字段可以直接作为分支条件。路由的价值在于避免用一套提示词打天下。选择题需要的是快速给出选项判断解答题需要的是完整步骤证明题需要的是逻辑严密。如果所有题都用同一个提示词模型要么啰嗦要么简略体验很差。分路由之后每条分支用针对性的提示词效果提升非常明显。3.3 知识库检索让答案贴合你自己的教学体系这是 Dify 相比裸调 API 最大的优势之一。热词里dify知识库流水线和weknora dify都指向这个能力。知识库检索解决什么问题举个例子一道题用通用模型解它可能用了一种很高级的方法但学生所在的年级还没学或者机构的教学体系里强调另一种解法。这时候如果能把机构自己的讲义、例题、解题模板接进知识库检索出来的内容作为上下文喂给模型答案就会更贴合。具体做法是把讲义、例题、知识点总结做成文档切分后导入 Dify 的知识库。工作流里加一个知识库检索节点用题干或者题干的关键词去检索把检索到的相关内容作为上下文拼进提示词。这里的关键是切分策略切得太碎检索不到完整信息切得太大又引入噪声。我的经验是按一道例题一个块或者一个知识点一个块来切块之间保留一定的重叠。注意知识库检索不是越多越好。检索回来的内容太多会挤占上下文还可能引入不相关的信息干扰推理。一般控制在 3 到 5 个最相关的块比较合适并且要在提示词里明确告诉模型优先参考检索内容但不要被无关内容带偏。3.4 分步推理与答案生成提示词是灵魂到了核心解题环节提示词的设计直接决定输出质量。我踩过的坑是一开始提示词写得太简单就一句请解答这道题结果模型要么直接给答案要么步骤跳跃。后来改成结构化提示词效果稳定很多。我的提示词一般包含这几个部分角色设定你是一位有经验的学科老师、任务说明分步骤解答每步说明依据、输出格式用固定的结构比如题目分析—解题步骤—最终答案—知识点、约束条件不要跳步、公式用 LaTeX、如果信息不足要说明。这里有个技巧把输出格式用示例的方式给出来比单纯描述格式要有效得多模型会模仿示例的结构。分步推理还有一个价值是可校验。如果模型给出的步骤里某一步明显不合理或者最终答案代回原题不成立可以在工作流里加一个校验节点让模型自己检查一遍或者用规则做简单验证。热词里deepseek破甲这类词我不建议往这个方向想解题场景要的是准确和规范不是绕过限制。3.5 多轮追问与上下文承接学生看完答案经常有追问这时候就涉及上下文管理。热词里deepseek到达对话上限之后怎么让新对话承接上一个对话说的就是这个痛点。Dify 的会话机制能保存历史但上下文长度是有上限的。我的处理策略是分层压缩完整的题目和答案保留中间的推理过程如果太长就压缩成摘要。具体做法是在工作流里加一个节点当历史长度超过阈值时用模型把之前的对话总结成一段简短的背景替换掉原始的长历史。这样既保留了关键信息又控制了长度。另一个技巧是把题目本身作为锚点。无论对话进行到第几轮题干和标准答案始终保留在上下文里追问的内容围绕它们展开。这样即使中间过程被压缩了模型也不会忘记在解哪道题。4. 实操落地从环境准备到工作流跑通4.1 环境准备与部署方式选择部署这块有两条路云端 API 调用和本地私有化部署。热词里deepseek api如何调用和本地部署deepseek分别对应这两种需求。如果只是自己练手或者小规模使用直接调 API 最省事不用管硬件按量付费。如果涉及学生数据、机构内部资料或者对响应速度和成本有要求就得考虑本地部署。本地部署 DeepSeek 一般用 vLLM 做推理服务硬件上主要看模型规格推理强的版本对显存要求高具体配置要根据你选的模型版本来定。Dify 这边社区版可以本地部署也有在线版本。本地部署的好处是数据不出内网适合机构场景。热词里dify本地部署教程dify安装教程dify迁移dify 在线升级 windows说明这块的部署和运维是很多人的关注点。我的建议是先用在线版把工作流跑通验证效果再考虑迁移到本地。因为工作流的设计和调试才是核心工作量部署只是载体不要一上来就卡在环境上。4.2 工作流节点配置详解我把工作流拆成几个关键节点逐个说配置要点。开始节点接收图片和可选的追问文本。图片先经过预处理和识别这里可以做成一个独立的 API 服务Dify 通过 HTTP 请求节点调用它拿到题干文本。条件分支节点做题型判断。前面用 DeepSeek 输出结构化的分类结果这里根据学科和题型字段分流。分支不要太多三到四条主分支就够太多会难以维护。知识库检索节点配置检索的知识库和返回条数。检索的 query 用题干文本返回条数控制在 3 到 5。如果知识库内容多可以加一个重排序节点提升相关性。LLM 节点是核心配置 DeepSeek 的模型和提示词。提示词里把检索到的上下文、题干、输出格式要求都拼进去。温度参数建议调低解题场景要的是稳定和准确不是创意。变量聚合节点把不同分支的输出汇总。热词里dify变量聚合器使用步骤详解说的就是这个它的作用是把多条分支的结果统一成一个变量方便后续处理。结束节点输出最终结果可以是结构化的 JSON也可以是渲染好的 Markdown。4.3 关键参数与提示词模板这里给一个我实际在用的提示词模板结构你可以直接改。角色你是一位经验丰富的{学科}老师擅长把复杂问题拆解成学生能理解的步骤。 题目{题干} 参考资料{知识库检索结果} 要求 1. 先分析题目考查的知识点和解题思路 2. 分步骤解答每一步说明依据 3. 公式使用 LaTeX 格式 4. 最后给出最终答案和易错点提醒 5. 如果题目信息不完整明确指出缺少什么 输出格式 【题目分析】 【解题步骤】 【最终答案】 【知识点】 【易错提醒】参数上温度建议 0.2 到 0.4太低会死板太高会发散。最大输出长度要留够解答题步骤多太短会被截断。如果用的是推理模型注意它的输出可能包含思考过程要在提示词里明确要求只输出最终结果或者在工作流里做后处理把思考过程剥离。4.4 联调与效果验证工作流搭好之后别急着上线先做小批量验证。我一般准备 20 到 30 道覆盖不同学科、不同题型的测试题人工核对识别准确率和解题准确率把失败的案例分类是识别错了、分类错了、检索没命中、还是推理错了。这个分类过程能帮你快速定位瓶颈在哪。验证的时候要特别注意边界情况图片模糊的、题目不完整的、超纲的、有多个小问的。这些情况在真实使用中占比不低工作流里要有兜底逻辑比如识别置信度低就提示重拍题目不完整就说明缺什么而不是硬答。5. 常见问题与排查技巧实录5.1 识别与推理类问题问题一公式识别出来是乱码LaTeX 渲染失败。这是最常见的。排查思路是先看原始图片质量再看识别引擎对这类公式的支持度。解决方法是加一层 LaTeX 校验渲染失败的走重新识别或者提示用户。另外识别引擎的选择很关键通用 OCR 对复杂公式支持有限建议用专门的公式识别方案。问题二模型答案对但步骤跳跃。这是提示词问题。检查提示词里有没有明确要求分步骤和每步说明依据。如果还是跳步可以在提示词里加一个示例展示你期望的详细程度。另一个办法是让模型先输出解题计划再按计划展开这样步骤会更完整。问题三几何题带图模型看不懂图。纯文本模型确实处理不了图形。解决方案是把图形信息用文字描述出来比如三角形 ABCAB 垂直于 BCAB 长 3BC 长 4作为题干的一部分。如果图形复杂可以考虑用多模态模型先做图形理解把理解结果转成文字再进主流程。5.2 工作流与部署类问题问题四Dify 工作流报 SSL 错误。热词里dify ssl错误是个高频问题。这类问题一般出在调用外部 API 或者访问知识库服务时的证书验证上。排查方向是检查网络配置、证书是否过期、域名解析是否正确。如果是内网环境要注意内网服务的证书配置。问题五上下文超长导致工作流失败。热词里dify工作流 上下文超长说的就是这个。解决思路前面提过核心是压缩历史。具体可以在工作流里加一个判断节点当 token 数超过阈值时触发摘要节点把长历史压缩。另外知识库检索返回的条数也要控制别一次塞太多。问题六插件离线安装失败。热词里dify如何离线安装插件说明内网部署场景不少。离线安装的关键是提前把插件包和依赖准备好注意版本匹配。安装失败一般是依赖缺失或者版本不兼容看日志能定位到具体是哪个依赖的问题。问题七迁移后工作流跑不起来。热词里dify迁移也是常见需求。迁移要注意的不只是工作流本身还有知识库数据、模型配置、环境变量。建议迁移前先导出完整配置迁移后逐项核对尤其是 API 密钥和模型端点这类容易遗漏的配置。5.3 常见问题速查表问题现象可能原因排查方向解决思路公式识别乱码图片质量差或引擎不支持检查原图、测试识别引擎加 LaTeX 校验、换识别方案步骤跳跃提示词不够具体检查提示词结构加示例、先出计划再展开几何题答错图形信息缺失确认题干是否含图形描述图形转文字描述SSL 错误证书或网络配置检查证书、域名、网络修正证书配置上下文超长历史或检索内容过多统计 token 数压缩历史、控制检索条数插件安装失败依赖缺失或版本不匹配看安装日志补齐依赖、对齐版本迁移后异常配置遗漏逐项核对配置导出导入完整配置5.4 几个我踩过的坑第一个坑是过度依赖知识库。一开始我把所有讲义都塞进知识库结果检索回来的内容又杂又多模型反而被带偏了。后来精简了知识库内容只保留高质量的例题和知识点总结效果反而更好。知识库的质量比数量重要得多。第二个坑是忽略识别环节的耗时。识别是整条链路里最慢的一环如果同步等待用户体感很差。后来改成识别和后续流程异步处理先返回正在识别识别完成后再推送结果体验好很多。第三个坑是没有做答案校验。有次模型给出的答案代回原题不成立但流程直接输出了。后来加了一个简单的校验节点比如数学题把答案代回验证不通过就重新推理或者标注答案存疑。这个兜底机制能显著降低错误答案的流出率。第四个坑是提示词里没控制输出长度。解答题步骤多有时候模型会写得很长超出输出限制被截断答案不完整。后来在提示词里明确了步骤简洁每步不超过三句话输出就稳定了。6. 后续可以怎么扩展这套方案跑通之后扩展空间其实挺大的。我列几个我自己在做的方向。错题本和学情分析。每次解题的记录都存下来按知识点、题型、错误类型做统计能生成学生的薄弱点报告。这个用 Dify 的工作流加一个数据存储节点就能做数据积累起来之后价值很高。相似题推荐。解完一道题用知识点标签去题库里检索相似题推给学生练习。这个和知识库检索是同一套逻辑换个数据源就行。多解法对比。同一道题让模型用不同方法解对比哪种更简洁、哪种更通用这对培养思维很有帮助。实现上就是同一个题干走多条提示词分支最后聚合展示。接入更多学科。目前数学物理效果最好化学的方程式配平、生物的遗传题也可以尝试但每个学科的知识库和提示词都要单独调优不能一套打天下。最后分享一个我在实际使用中的体会这套系统的瓶颈往往不在模型而在数据和流程。模型能力已经足够强了真正决定体验的是识别准不准、知识库内容好不好、提示词设计得合不合理、异常情况有没有兜底。把精力花在这些地方比反复换模型、调参数要有效得多。