做 AI 产品，先别急着接模型

为什么不是先接模型

很多 AI 产品的第一步会被误解成“先把模型接起来”。这当然重要，但它更像技术验证，不是产品验证。

真正应该先回答的是三个问题：

1. 用户现在遇到的具体阻力是什么？
2. 这个阻力是否频繁、明确、值得解决？
3. AI 的介入是否能缩短路径，而不是制造新的理解成本？

如果这三个问题没有想清楚，模型能力越强，产品越容易变成一堆炫技功能。

我会先画一条任务路径

我通常会先把用户完成任务的路径写出来：

阶段	用户动作	最大阻力	AI 可以做什么
输入	描述需求	不知道怎么说清楚	追问和结构化
处理	组织信息	手动整理耗时	提炼、排序、生成草稿
输出	交付结果	不确定是否可用	给出检查清单和修改建议

这张表不用复杂，但它能避免一个常见问题：把 AI 放在“看起来很酷”的地方，而不是用户真正卡住的地方。

原型要验证反馈闭环

一个 AI 产品原型，不只是跑通一次生成。更关键的是看用户能不能判断结果、修改结果、继续推进。

type ProductLoop = {
  input: "用户表达目标";
  aiAction: "AI 生成或辅助判断";
  userReview: "用户确认、修改或拒绝";
  nextStep: "进入下一轮或完成交付";
};

如果用户每一步都要重新解释上下文，这个产品就还没有形成闭环。好的 AI 产品应该让用户感觉“它理解了我的工作”，而不是“我在管理一个不稳定的工具”。

先做小，但要做完整

我更倾向于先做一个小场景，但把它做完整。比如只解决“把零散想法整理成文章提纲”，也要包含输入引导、生成结果、用户调整、导出或保存。

这样才能看到真实摩擦：

• 用户愿不愿意把真实内容交给它？
• 生成结果是否足够接近可用？
• 用户修改时，系统能不能承接上下文？
• 这个流程是否比原来更省心？

我的判断标准

一个早期 AI 产品值得继续做，至少要满足两个条件。

第一，它确实减少了用户的认知负担。不是“多了一个 AI 按钮”，而是让用户更快进入结果。

第二，它能积累上下文。每一次使用之后，系统应该更懂用户、任务或领域，而不是永远从零开始。

这也是我后续做个人项目时想持续记录的重点：不只记录功能怎么实现，也记录每个产品判断为什么成立。