模型只是零件：从一次调用到一个真正可用的 AI 产品

第一次把大模型接进一个应用时，很容易产生一种完成感：输入能得到漂亮输出，Demo 也能录了。

但真正的产品问题通常从第二次运行开始。用户换了一份文件怎么办？模型少返回一个字段怎么办？任务执行一半失败怎么办？换了模型以后，原来有效的流程还成立吗？

当这些问题出现，我才意识到：会调用模型和能构建 AI 产品之间，隔着的不是另一个提示词，而是一整套系统。

模型调用与产品工程，解决的是两类问题

模型调用解决的是：能不能产生一个候选答案。

产品工程解决的是：用户的任务能不能安全、稳定、可重复地完成。

两者之间隔着上下文、数据、状态、工具、权限、验证、失败恢复和反馈。模型往往是最显眼的零件，却不是产品本身。

一个视频模型可以判断哪些片段可能精彩，但它不会天然知道素材是否有授权、时间轴能否闭合、渲染失败应该从哪里重来。一个模型可以总结项目，却不会天然知道哪份文件是当前事实，哪一段只是历史计划。一个编程助手可以给学生答案，却不会天然照顾教师怎样观察、判断和介入。

这些“模型之外”的部分，才决定 AI 能力能否成为产品。

我用四个问题判断一个项目是否越过 Demo

我现在会用四个问题检查一个 AI 项目：

1. 拆得开吗？

一个目标能否被拆成边界清楚的步骤？哪些步骤适合确定性代码，哪些步骤需要模型判断，哪些动作必须由人确认？

如果所有事情都压进一次长提示词，系统只剩“成功”和“失败”两种状态。结果不理想时，既不知道哪里错了，也无法只重做受影响的部分。

2. 验得过吗？

系统怎样知道输出是对的？格式校验只能说明 JSON 合法，不能说明内容有用。真正的验证往往还包括来源、权限、业务规则、人工标准和真实样本。

Hamel Husain 与 Shreya Shankar 的 LLM Evals FAQ 把错误分析放在评测工作的起点：先从真实失败中建立问题分类，再决定哪些判断值得自动化。这个顺序比先挑一个通用分数更符合我的实践。

3. 接得住吗？

任务超时、模型限流、工具离线或中间结果损坏以后，系统能否恢复？恢复是从头再来，还是只重跑一个节点？已有成果是否会被覆盖？

“接得住”不仅是后台可靠性，也直接影响体验。用户真正关心的是工作是否还在、已经完成了多少、接下来需要做什么。

4. 改得动吗？

用户修改结果以后，系统是否留下了下一轮改进的依据？能否知道是模型、上下文、规则、工具还是界面造成了问题？

如果没有版本、运行记录和反馈，所谓迭代只是在凭感觉换模型、改提示词。

拆得开、验得过、接得住、改得动。只要其中一项没有答案，系统可能依然令人惊艳，但还很难被长期使用。

三个项目改变了我对 AI 产品的理解

媒体生产：把语义判断和确定性执行分开

在 Project-to-Short-Video 里，我最初关心的是模型能不能找到更好的演示故事。流程真正展开以后，工作重点却变成了证据边界、镜头状态、人工确认、渲染和失败恢复。

模型负责理解内容并提出候选方案；结构化规则检查时间和参数；媒体引擎负责执行；人负责最后的质量判断。某个镜头失败时，只重做受影响的镜头，而不是让整条生产线重新开始。

这让我第一次清楚看到：AI 产品的价值不只来自智能判断，也来自系统怎样承接这个判断。

知识系统：会回答，不等于能交接

在另一个知识系统项目中，模型可以把项目总结得很漂亮，但下一位执行者仍可能不知道哪份文件是当前事实、哪些内容已经验证、还有什么没有完成。

于是我把来源、状态、证据、失败和限制放进系统。一次图谱任务阻塞时，我没有为了“全部成功”重新生成已经完成的 68 份文档，而是先保护成果，再用只读轻量图谱完成可追踪的 v0.1。

知识只有在能支持下一次行动时，才不只是存储。

教育产品：能力不是越多越好

当 AI 编程工具进入课堂，产品需要同时支持学生探索和教师判断。教师不需要看到全部日志，但必须看得见关键状态、判断得了何时需要介入，并能阻止系统越过教学与隐私边界。

这类场景提醒我：功能数量不是能力。真正的能力，是系统能否让不同角色在正确时机理解并采取行动。

为什么我先设计 Workflow，再决定哪里需要 Agent

Anthropic 在 Building Effective Agents 中区分了两类系统：预先定义路径的 workflow，以及由模型动态决定过程和工具的 agent。它给我的关键提醒不是“应该用哪一种”，而是复杂度必须有收益证据。

如果任务路径稳定、步骤可枚举、失败成本高，我会优先使用显式 workflow。它更容易观察、审批、回放和局部恢复。

只有当目标开放、步骤无法预先写死，并且模型能够从环境取得真实反馈时，我才会逐步增加 Agent 自治。即使如此，工具权限、停止条件、费用和不可逆动作仍然需要产品层约束。

Human-in-the-loop 不是临时补丁

Human-in-the-loop 常被解释成“AI 还不够强，所以先让人兜底”。我更愿意把它看成责任结构。

当目标本身有歧义，或者动作会影响账号、费用、隐私和外部世界时，人的判断本来就是系统的一部分。好的设计不是把人从流程里删除，而是让人只在真正需要承担判断和责任的位置出现。

这也解释了为什么权限不能跟着模型信心一起增长。OpenAI 关于 Prompt Injection 的说明强调了分层防御、限制访问范围和重要动作前确认；这些都不是提示词能单独承担的责任。

上线前，我会再问七个问题

用户真正要完成的任务是什么，而不是模型能表演什么？
哪些步骤应该由普通代码完成？
模型输出怎样被验证，失败样本从哪里来？
中断以后从哪里恢复，会不会覆盖已有成果？
什么信息是不可信输入，模型能访问哪些工具和数据？
哪些动作必须让人明确确认？
用户修改结果后，我们能学到什么？

这七个问题不依赖某个框架或模型版本。工具会持续变化，但任务、责任、证据和恢复不会消失。

AI Product Design Engineer 真正设计的是什么

不是一个聊天框，也不是一条模型调用链。

我想设计的是人、模型、数据、工具、状态和证据共同完成任务的方式：模型变化时，产品不随之坍塌；输出错误时，我们知道问题发生在哪里；人修改结果时，系统得到下一轮改进的依据。

对我而言，这才是从“调用模型”走向“设计 AI 产品”的分界线。

参考与延伸

资料核验日期：2026-08-29。本文的“十项能力”与“四项检查”是 Eric 用于组织实践的个人框架，不代表行业统一标准。