5个AI功能各自正常 产品却支离破碎

一位开发者花了大量时间打磨五个AI功能——纹身生成、图片转纹身、文字设计、精修和试戴。每个功能单独测试都表现正常：生成器能产出有用的概念，图片转纹身能完成转换，文字设计能保留精确文本，精修能局部调整而不必推倒重来，试戴能把设计放到身体照片上。

但他最终发现：产品整体体验是断裂的。

问题的根源不在任何一个功能内部，而在功能与功能之间。用户生成一个喜欢的图案后，下一步该做什么并不明确；想修改局部、换个位置、调整尺寸、从文字设计过渡到完整构图、重新打开之前的作品、把结果放到身体照片上——这些动作都需要用户自己在脑子里把五个工具拼成一条工作流。

用他的话说：“That was the real bug.”

功能没问题，缺的是“过渡”

作者在构建AIMakeTattoo时逐渐意识到，自己一直在问“下一个该加什么AI功能”，但真正应该问的是：每个功能产出什么？这个产出下一步该流向哪里？

他梳理出的有效路径是：想法 → 生成 → 修改 → 试戴 → 对比 → 交给纹身师。写下来显得理所当然，但在产品里一点都不显然。

关键的转变不是再加一次模型调用，而是让一个结果能被下一步直接使用。每个功能单独可用，但用户仍然要手工缝合整个产品——这就是断裂感的来源。

把输出当作共享对象

最有用的心智模型是：不再把生成器、文字设计、图片转纹身、精修和试戴当成五个独立工具，而是把生成的结果视为一个在产品中流动的共享对象。

生成的结果可以成为精修的输入；精修后的结果可以进入试戴；文字设计的结果可以在身体上预览；保存的结果可以重新打开而不是重新创建。这样产品才从“一堆demo的集合”变成一个连续的工作流。

这个视角的转换也重新定义了功能边界：一次生成只是流程中的一步，而不是终点。

共享对象（Shared Object） 是软件设计中一个常用概念，指在多个模块或步骤之间传递、被多方读取或修改的数据实体。与每个工具各自维护私有状态不同，共享对象拥有统一的标识和结构，任何下游功能都可以直接引用它，而不需要用户或系统重新构造。

在本案例中，一个纹身设计从上一步传到下一步时，如果能携带图案、文本、位置、尺寸、精修历史等元数据，那么精修、试戴等环节就能直接消费同一个对象，无需重复上传或重新描述。这要求设计时明确对象的 schema（例如设计 ID、版本、图层信息），并建立稳定的读写约定。共享对象的成熟度往往决定了多步骤 AI 产品能否从演示走向可用。

模型调用很少是最难的部分

作者坦承模型工作重要，但大多数令人沮丧的产品问题都发生在模型之外：在工具之间保持状态、决定哪些信息该传递下去、把精确文本和视觉指令分开处理、让同一个结果可供下一步动作使用、让下一步显而易见、避免迫使用户从头再来。

这些是普通的产品和软件工程问题。AI只是暂时把它们藏了起来，因为每个孤立的功能单独看都很惊艳。一个成功的API响应不等于用户成功完成了任务——功能可以通过所有技术测试，却因为产出无处可去而制造摩擦。

状态保持（State Management） 指应用在多个步骤或页面之间维持用户数据一致性的能力。在单功能演示中，状态通常只存在于一次请求内；一旦进入多步骤工作流，就必须回答：哪些字段需要跨步骤持久化？后端如何存储中间结果？前端刷新或重新打开后如何恢复？

常见的实现手段包括统一的设计 ID 与后端存储、会话级或持久化的草稿机制，以及为每个步骤定义清晰的输入/输出契约。状态设计不当会直接导致用户被迫重新输入信息、丢失精修结果或无法回退，这正是文中所述“模型之外”摩擦的主要来源之一。把状态当作产品架构的一等公民，往往比更换更强的模型更能改善体验。

用五个问题替代“再加一个功能”

在添加新功能之前，作者现在会先问：

1. 这个功能输出什么？
2. 最可能的下一步动作是什么？
3. 用户能直接复用这个输出吗？
4. 我们是否在迫使他们重新输入信息？
5. 新功能是接入现有工作流，还是只是增加一个分支？

这份清单比“另一个AI能力在演示里是否好看”更有用。

过渡本身就是功能的一部分

作者过去把工具之间的交接视为实现细节，现在他认为这就是产品本身。从生成到修改、从修改到试戴的过渡，可以和任何一个功能单独存在时同样重要。构建AI产品的难点往往不是让又一个模型跑通，而是确保它产出的东西能在一个有用的地方继续下去。

这个案例对多AI功能产品的开发者有普遍参考价值：当功能清单越来越长，用户体验的瓶颈会从“能不能做”转移到“做完之后往哪走”。把输出设计成可流转的共享对象，把过渡当作一等公民来设计，可能是比堆叠模型调用更有效的产品策略。