三个 40 岁老程序员决定用 AI 重新出发（三）：Use Case 驱动的产品设计

你好，我是曹犟，欢迎关注我的公众号。

在上一篇文章中，我分享了我们如何用 AI 完成商业计划书：从市场调研到头脑风暴，再到结构化的人机协作写作。而有了 BP 之后，接下来就要思考：如何把商业目标转化成可执行的产品设计？

在这篇文章中，我会分享我们是如何用 Use Case 驱动的方式来完成产品设计的，以及在这个过程中如何用 Claude Opus 4.5 和 Gemini 3.0 Pro 来配合工作。

PART01

为什么是 Use Case 而不是 PRD

很多人一听到产品设计，第一反应就是写 PRD（产品需求文档）。但在这次实践中，我们选择了 Use Case 而不是传统的 PRD。

这个做法，是参考亚马逊的逆向工作法（关于逆向工作法，我在从程序员到 CTO 的十年创业血泪总结（三）：假设验证与逆向工作法中有详细介绍）。简单来说，就是从用户的使用场景出发，倒推需要什么功能，而不是从功能出发去找用户场景。过去十一年创业中得到的最深刻的认知之一，就是一定要从客户需求出发，不能拿着锤子到处找钉子。

传统 PRD 的问题

传统 PRD 有几个明显的痛点：

第一，功能导向，容易陷入细节。PRD 通常是按功能模块组织的——用户管理、权限管理、数据管理……写着写着，就会陷入对每个功能的细节描述，反而忘了用户到底要用这些功能做什么。

第二，缺乏用户视角。 PRD 描述的是“系统能做什么”，而不是“用户要完成什么任务”。但用户买单的从来不是功能列表，而是能不能解决他的问题。

第三，写完就过时。传统 PRD 往往是一次性的产物——写完、评审、然后束之高阁。但产品是不断演进的，PRD 很难跟上迭代的节奏。

Use Case 的优势

相比之下，Use Case 有几个天然的优势：

第一，用户故事导向，始终聚焦价值。 Use Case 描述的是“用户要完成什么任务、达成什么目标”，每一个 Use Case 都对应一个清晰的用户价值。这种思考方式更适合从商业模式顺延过来。这让我们在后续开发实现时，始终记得这个功能是为了帮用户解决什么问题。

第二，天然适合增量迭代。 Use Case 是相对独立的，可以先做最重要的几个，再逐步补充其他的。这和 MVP 的理念完美契合——先验证核心假设，再逐步完善。

第三，更容易和 AI 协作。 这一点是我们在实践中发现的。因为 Use Case 更具体、更有上下文，AI 更容易理解你到底要做什么。相比之下，抽象的功能描述往往会让 AI 产出一堆正确但没用的废话。而基于 Use Case 做增量开发的方式，也天然更加适合 Spec Coding。

我们的定义

在我们的实践中，一个 Use Case = 一个完整的用户故事 + 验收标准。

它需要回答几个核心问题：用户是谁？触发条件是什么？用户要完成什么任务？主流程是什么？异常情况怎么处理？怎么验证这个 Use Case 已经完成？

PART02

从 BP 到 MVP Use Case

有了 BP，下一步是确定 MVP 阶段要做哪些 Use Case。这个过程的核心是：找出最关键的假设，用最小的成本去验证它（关于 MVP 的详细讨论，可参考从程序员到 CTO 的十年创业血泪总结（四）：打造 MVP）。

BP 中有很多假设：客户是否真的有这个痛点？是否愿意付费？Agent 是否能解决这些痛点？用户能否接受 AI Agent 的交互方式？这其中有些是“不成立就彻底没戏”的关键假设，MVP 的目的就是用最快的速度验证这些关键假设。

Use Case 的优先级排序

基于这个思路，我们对 Use Case 进行了优先级排序：

P0（Must Have）：能验证核心假设的 Use Case。没有这些，就无法判断这个产品到底有没有价值。

P1（Should Have）：能提升用户体验的 Use Case。有了 P0，用户能用；有了 P1，用户用得舒服。

P2（Nice to Have）：锦上添花的 Use Case。可以放到后续版本再做。

我们的 MVP 包含哪些 Use Case

我们准备打造的产品的定位，是在某专业领域，提供一个比 80% 人类专业人员更专业、更勤奋、更便宜的 Agent。经过讨论，我们的 MVP 阶段确定了 3 个核心的 Use Case：

| 用例 ID | 用例名称 | 优先级 | 描述 |

|---------|----------|--------|------|

| UC-01 | 初始方案创建 | P0 | 分析需求，生成初始方案 |

| UC-02 | 智能调优 | P0 | 每日分析数据，识别问题和机会 |

| UC-03 | 优化建议与执行 | P0 | 发现机会后建议，确认后执行 |

这 3 个 Use Case 构成了一个完整的闭环：用户输入需求 → Agent 生成方案 → Agent 持续监控优化。通过这个闭环，我们可以验证核心假设：Agent 是否能够比大部分人类专业人员取得更好的效果。

PART03

用 Claude Opus 写 Use Case

确定了要做哪些 Use Case 之后，下一步就是把它们写清楚。在这个过程中，我们主要使用 Claude Code + Opus 模型。

为什么 Opus 是最好的文档撰写助手

在各种大模型中，我们发现 Opus 特别适合写这类结构化的业务文档：

第一，逻辑严密。 Use Case 需要清晰的主流程和异常处理，任何逻辑漏洞都会导致后续开发时遇到“这种情况怎么办”的问题。Opus 在这方面表现很好，它会主动考虑边界情况和异常场景。

第二，文字质量高。Opus 的输出更加精炼、专业，不会有太多废话。这对于要反复阅读和迭代的文档来说很重要。

第三，能够保持长文档的一致性。我们的 Use Case 文档最后有 2000 多行，包含大量的细节。Opus 能够在这样的长文档中保持术语一致、风格统一，这一点非常重要。

Use Case 的结构

我们的每个 Use Case 都遵循统一的结构，这里给出一个非常简略的例子：

```

用例 ID：UC-01

优先级：P0

触发方式：用户发起

参与者：操作者、Agent

前置条件：用户已提供基本信息

主要流程：

Step 1：Agent 分析信息，输出预判，请用户补充

Step 2：操作者确认或调整

Step 3：Agent 生成完整方案

Step 4：操作者审核确认

Step 5：Agent 执行创建

异常流程：

- 信息无法获取 → 提供手动输入

- 识别失败 → 提供选择菜单

后置条件：方案已创建，开始持续监控

```

实操技巧

在实践过程中，我们总结了几个实操技巧：

第一，管理好上下文。我们需要把商业模式、产品定位、目标客户等信息告诉 Opus，让它充分理解我们要做什么。上下文给得越充分，产出质量越高。这些都需要在项目中构建 AI 友好的文档体系来体现。

第二，增量构建。不要试图一次就写到完美。我们会先让 Opus 写一个框架版本，把主流程写清楚，然后再逐步补充异常处理、边界情况等细节。

第三，持续人机迭代。我们会阅读 Opus 的每一步产出，发现不合理的地方，或者在这个过程中有了新的认知就提出来让它改。这个过程中，Opus 像是一个能快速执行我们想法的“文档撰写员”，而我们则是不停提出新的想法并做最终判断。

PART04

Gemini 的独特作用

在 Use Case 设计过程中，我们也发现了 Gemini 的一个独特价值：它的超长上下文窗口和领域知识。

场景：需要消化大量资料

我们做的是一个特定行业的 Agent 产品，需要深入理解这个行业的业务逻辑。这意味着我们要阅读大量的行业资料：平台官方文档、最佳实践指南、API 文档、行业报告等。

这些资料加起来可能有几十万字，人读起来要好几天，而且很容易遗漏细节。

Gemini 的优势

Gemini 3.0 pro 在这个场景下有两个独特优势：

第一，超长的上下文窗口。1M token 的上下文，这意味着可以一口气把几百 K 的文档喂给它，然后和它讨论具体问题。不需要分批处理，不需要担心“忘记之前的内容”。竞品分析、技术选型调研、行业知识学习，都很适合用这种方式。

第二，特定领域的知识优势。在我们的产品涉及的专业领域上，Gemini 的理解和思考明显要比其他模型更加深入，我猜测这应该和它在这方面的训练数据更丰富有关关系。

因此，在我们的工作流中，Gemini主要用于“输入”：消化大量资料、建立认知、讨论方案；Opus主要用于"输出"：撰写结构化的 Use Case 文档、执行具体的写作任务。

当然，虽然 Gemini 有这种领域方面的优势，但是，人对于相关业务知识的学习依然是不可欠缺的，只不过，AI 让这个学习过程变得更加高效与便捷了。

PART05

写在最后

Use Case 驱动的产品设计，本质上就是遵循亚马逊逆向工作法，从用户价值出发，倒推需要什么功能。相比以 PRD 为中心的写法，这种方式避免了拿着锤子找钉子的自嗨，更聚焦于商业价值本身，适合 MVP 阶段的快速迭代，也更适合和 AI 协作。

在下篇文章中，我会继续分享从 Use Case 出发，如何用 Spec Coding 的方式进行后续的拆解与实现的经验，敬请期待。