从旧项目到上线：Calicat × WorkBuddy 如何构建 AI 驱动的产品迭代工作流

前言

随着 AI 开始进入产品设计流程，产品经理的工作正在发生一个很明显的变化。

过去，一个功能迭代往往意味着：重新梳理业务逻辑、整理需求文档、绘制原型、补充交互、同步设计与研发，再反复确认需求是否一致。

而现在，AI 正在把这些分散的工作串联起来。

本文以一个「费用报销审批功能迭代」为例，看看如何通过 Calicat + WorkBuddy，把从理解旧项目到最终开发的整个过程连接起来，让 AI 真正参与产品迭代。

接手一个老项目，第一步不是画原型

假设现在需要迭代一个已经运行了一段时间的费用报销审批系统。

原有的审批逻辑由其他同事设计，随着项目迭代，新的需求又不断加入。对于产品经理来说，真正麻烦的往往不是「怎么画新页面」，而是：现在这个系统到底是怎么工作的？ 审批流程是什么？有哪些字段？不同状态分别代表什么？哪些接口参与了审批？驳回之后又会发生什么？

尤其当原负责人已经离职，过去沉淀在代码、文档和设计中的信息往往更加分散。

所以在开始新的设计之前，首先要做的是：把现有系统的逻辑搞清楚。

让 WorkBuddy 先理解现有代码

传统方式下，产品经理通常需要在文档、设计稿和代码之间反复寻找信息，再和研发确认细节。

而在这套工作流里，可以直接让 WorkBuddy 参与进来。

首先，将 Calicat 的 MCP 接入 WorkBuddy。操作流程参考 Calicat MCP Server 使用方法。

MCP 可以理解为连接 AI Agent 与外部工具和数据的一座桥梁。通过 MCP，WorkBuddy 不仅可以获取 Calicat 中的需求和设计信息，也可以进一步向 Calicat 写入内容。

接入之后，让 WorkBuddy 直接分析现有代码库。AI 会从代码中提取和整理与审批功能相关的信息，包括：

• 审批流程
• 字段
• 状态
• 接口

原本需要人工阅读和反复确认的信息，被整理成一份更结构化的系统逻辑。

这一步的意义并不是让 AI「替产品经理做判断」，而是先帮助产品经理快速建立对现有系统的完整认知。

从旧逻辑出发，直接生成需求文档

理解现有逻辑之后，下一步就是进入这次迭代。

这次的需求很明确：在现有费用报销审批流程中增加主管预审。

新的审批流程变成：员工提交 → 主管审批 → 财务审批。如果主管驳回，员工可以修改后重新提交。

过去，这一步通常意味着重新整理需求、单独维护文档，再把相关内容同步给设计和研发。

现在，WorkBuddy 可以结合对代码库的理解，以及本次迭代需求，通过 MCP 直接在 Calicat 中创建需求文档。

这样，旧系统的逻辑和新的迭代需求就可以在同一个地方被沉淀下来。

需求确定之后，让 AI 直接生成原型

有了需求文档之后，不需要再从空白画布开始。在 Calicat 中，可以直接让 AI 基于需求生成新版本原型。

针对这次主管预审的需求，AI 不只是生成一个孤立的页面，而是围绕完整业务流程生成对应的设计，包括：

• 报销申请
• 报销列表
• 审批详情
• 主管审批
• 财务审批

同时，新的审批逻辑也会体现在页面和流程中。例如：员工提交 → 主管审批 → 财务审批。当主管选择驳回时：主管驳回 → 员工收到通知 → 修改报销 → 重新提交。

这样，从「文字需求」到「可讨论的完整原型」，中间原本大量依赖人工完成的工作，就有了一个 AI 生成的第一版结果。

原型生成之后，再让 AI 补齐交互

一个完整的产品设计，不只是页面长什么样，还包括：哪里可以点击？点击之后发生什么？不同状态下页面应该如何变化？

这些细节过去也需要产品经理逐项补充。现在可以继续让 AI 基于已有原型完善交互设计。

例如在主管审批页面中：主管点击「驳回」→ 填写驳回原因 → 报销单退回员工 → 员工修改后重新提交。

这些交互说明可以继续沉淀到需求中，并生成对应的需求卡片，关联到具体设计。

于是，需求、原型和交互说明不再是彼此独立的几份材料，而是在同一张画布中建立关联。

从「来回同步」变成「同一张画布协作」

传统工作流中，需求文档、原型和交互说明往往分散在不同工具里。需求改了，要同步原型；原型改了，又要更新文档。评审时，产品、设计、研发还需要在多个工具之间切换。

这也是产品迭代中一个非常常见的问题：信息没有消失，但信息被分散了。

Calicat 的做法，是将需求和原型放在同一张画布中进行设计和管理。到了评审阶段，团队成员可以直接进入同一张画布：

• 在对应位置发表评论
• 直接讨论具体设计
• 将需求卡片分配给负责人
• 持续跟踪问题处理状态

比如研发发现「员工端的新建报销单页」这一节点需要优化，可以直接在对应节点下留言，而不是再回到聊天工具里单独描述。讨论也因此和上下文绑定在了一起。

评审完成之后，直接进入开发

当需求和设计完成评审之后，下一步就是开发。研发可以继续在 WorkBuddy 中，通过 MCP 获取 Calicat 中的需求和设计数据。

这样，AI 获取到的就不再只是零散的一段需求描述，而是完整的产品上下文：需求 + 原型 + 交互说明。AI 理解这些信息之后，就可以进一步辅助开发。

于是，整个链路变成：代码 → 需求 → 原型 → 交互 → 评审 → 开发。中间的信息不再需要依靠人工一次次复制、整理和转述。

这不是让 AI 替代产品经理，而是重新分配工作

这个工作流带来的变化，并不是「产品经理以后什么都不用做」。恰恰相反。

AI 接手的是大量机械、重复、需要反复搬运的信息工作：梳理代码、整理信息、生成文档、生成原型、补充交互、同步上下文。

而产品经理需要投入更多精力的，是那些真正需要判断的事情：业务理解是否足够深入？用户真正的问题是什么？需求到底该不该做？方案是否真正解决了问题？这个产品最终能不能创造价值？

过去，原型和文档本身就是产品工作的重要组成部分。但在 AI 工作流下，原型和文档越来越像是一种执行载体，而不是最终价值。

真正重要的是：定义问题，以及判断应该怎么解决问题。

结语

AI 正在改变的，不只是产品经理使用工具的方式，而是整个产品迭代的工作方式。从理解旧系统开始，到生成需求、设计原型、完善交互、协作评审，再到辅助开发，AI 正逐渐进入产品生命周期的每一个环节。

Calicat 和 WorkBuddy 的结合，让这些环节之间的上下文能够被持续传递。

AI 负责把信息整理好、把执行做得更快，而产品经理可以把更多时间留给判断、决策和创造价值。

这或许才是 AI 时代产品经理更值得期待的变化：不是被 AI 替代，而是从重复执行中真正解放出来。