AI产品工作流程的升级正成为企业效率提升的关键。本文揭秘基于Claude的智能工具如何将模糊需求转化为结构化Story清单，并通过智能排期实现精准开发规划。从需求拆解到异常场景预警，这套实战验证的流程正在重新定义产品经理与AI的协作边界。

最近一直在对公司的AI产品工作流程做升级。估计大家也体验过了：如果不做高度定制化，AI能给的就是“看起来很正确，但需要慢慢改”的东西。

所以我不断优化和重新选型。目前已经升级到基于Claude的版本——不得不折服，外国人的东西还是好用。为此我给每个产品经理批了200块钱预算，专门买了个国内方舟的coding-plan。好东西，还是贵。

改造的过程，本质上就是产品研发，只不过产品和研发都一个人干了：先出一版，然后边用边提需求，再优化。

今天我就把这段实践拆成两件具体的事：需求拆解和智能排期——也是我目前最依赖的两个“外挂大脑”。

一、我为什么非要搞这个东西？

很简单：需求模糊的成本，全让产品经理扛了。

客户成功说“我要一个团队权限管理”，你觉得“管理”是指增删改查，还是指角色分配？他说“你看着办”。等上线了，销售拿着原型去见客户，回来说“客户说不是他们要的”。

问题是，你问他“不是要的”是指什么，他也说不出来。

所以我们工作定了一条死规矩：任何需求，必须能回答类似5W2H的问题，否则我不开工。

后来我把这个表格越做越细，干脆写成了一个可执行的“需求拆解技能”。

二、这个技能到底在干什么？

一句话概括：把客户成功/销售的“人话”，翻译成开发能直接用的 Story + Gherkin 验收场景。

你给它一段自然语言需求，它做三件事：

1. 标准化输入：抽取出“用户角色、核心目标、关键场景、非功能需求、约束条件”。
2. 拆解成 Feature 和 Story：按SaaS模块（租户管理、用户与权限、订阅计费、产品配置、运营后台）归类，每个 Story 有独立ID。
3. 自动生成 Gherkin 验收场景：每个 Story 至少1个正向场景 + 1个异常场景。

举个例子。客户成功说：

“企业管理员可以邀请成员加入组织，被邀请的人会收到邮件，点击链接后设置密码即可加入，同时要给新成员分配一个默认角色。”

技能通过AI的辅助，按照自然语言描述->结构化FEATURE->结构化STORY的模式，将需求拆解成用户故事。

可以先看下feature:

feature经过技能拆解后会输出类似这样的 Story：

这个过程中，技能会不断地进行需求澄清和迭代，直到输出满意的story为止。

三、为了适配工作流程做的三个设计

1. 继承模式：迭代需求不破坏原有清单

按照敏捷的工作路径，需求是不断迭代的。以前用Coze很难处理，但现在稍加优化就可以支持。

技能支持 “基于已有 Story 迭代”。你只需要说：

“基于 STORY-008 升级，本次新需求是：邀请链接支持设置有效期，且过期后可重发。”

技能会读取原来的 STORY-008 内容，生成一个全新的 Story（比如 STORY-012），旧的那个原封不动。你既保留了历史，又有了新版本。

而且它还支持截图分析——你丢一张现有系统的截图过去，它能自动识别界面上有哪些按钮、哪些功能，然后基于这个布局来设计新功能的流程。

2. 异常场景库：那些你容易漏掉的“万一”

我踩过的坑，大部分不是正向流程，而是异常情况。

所以我借助AI将常见的异常场景整理成库，每次拆解时会自动扫描，看看有没有漏掉的。技能会生成一张“遗漏点清单”告诉你：

这个 Story 涉及角色权限变更，但你还没写并发修改时的处理逻辑。

3. 关键路径校验：确保核心链路没断

SaaS产品往往有自己的关键路径，比如：

• 租户开通流程：注册 → 创建组织 → 选择订阅 → 支付 → 激活
• 用户加入流程：管理员邀请 → 用户接受 → 分配角色 → 可访问资源
• 订阅变更流程：升级/降级 → 差额计算 → 生效时间 → 配额调整
• 计费与计量流程：用量采集 → 账单生成 → 扣费 → 欠费处理
• 跨租户数据隔离：租户A的用户不能看到租户B的数据

技能会检查你的 Story 清单有没有覆盖这些路径。如果缺了，它会直接警告。

四、它不是万能的——我的使用建议

这套技能目前只做一件事：从原始需求到结构化 Story 清单的转换。

它不会帮你排优先级（这个得你和客户成功、销售一起撕），不会帮你做变更管理，也不会帮你设计技术方案——这些都是后续技能做的工作。

它的定位就是一个 “外挂大脑”——把你脑子里那些“这个需求应该问清楚什么”的 checklist 自动化了。

五、拆完以后，怎么给Story算分、排期？

上一部分讲的是需求拆解——把业务方的“随便来一版”变成结构化的 Story + Gherkin。下面接着讲：拆完以后，怎么给 Story 算分、排期。

这是第二个技能，工作就是给上一期产出的那一版 Story 算优先级和做排期。

1. 它怎么干活？

第一步：读你的 Story 清单

它直接读取上一期生成的 stories.md 文件，找出所有“已确认”但“优先级”一栏还是空的 Story，然后列给你看。

第二步：算分

它用一个公式给每个 Story 打分。权重和评分可以人工设置，这里我用了个默认的得分算法：

得分 = 业务价值 × 0.4

+ (1 – 实现成本/10) × 0.2

+ (10 – 风险等级) × 0.1

+ 用户影响范围 × 0.3

四个维度：

默认情况下，它会用“业务价值=5、实现成本=5、风险等级=5、影响范围=部门”来算。你也可以针对某些 Story 手动改参数。

算完以后，按得分从高到低排序。

第三步：考虑依赖，智能排期

得分高不代表可以直接做。比如某个 Story 依赖于另一个 Story 的结果，你必须先做被依赖的那个。

工具会解析每个 Story 的“依赖关系”列（比如 STORY-001, STORY-002），自动构建依赖图，然后按规则排：

• 被依赖的 Story 必须排在依赖它的 Story 之前
• 同层按得分从高到低
• 如果依赖的 Story 还没确认（状态不是“ 已确认”），就跳过并提示

然后你告诉它“本迭代打算做几个 Story”，它就把排好序的前 N 个展示出来。

第四步：你确认，它写回文件

你一看，“嗯，这个顺序靠谱”，说一声“确认”。

工具就直接把 stories.md 里的“优先级”列填上得分，并把进入本迭代的那几个 Story 的状态从“ 已确认”改为“ 已排期”。全程不碰其他列，不用担心把之前写好的描述、验收场景弄乱了。

2. 三个个性化的设计

① 循环依赖检测

依赖关系图里如果出现一个圈：A 依赖 B，B 依赖 C，C 又依赖 A，人工怎么都排不出来。工具直接警告：

检测到循环依赖：STORY-001 → STORY-003 → STORY-001

建议人工检查，将继续进行排期

拿到这个警告，我去改依赖关系，排期才变顺。

② 支持手动调整参数和得分

算法再聪明，也比不上你对业务的直觉。比如某个 Story 得分很低，但老板拍桌子说“这个必须下个月上”，你可以直接修改它的业务价值或手动设定优先级得分，然后重新排。工具会尊重你的覆盖。

③ 只排“已确认”的 Story

那些“ 待确认”的 Story 不会进入排期，避免你排了半天，业务方说“这个我们还没想好”。只有你确认过的需求才有资格占坑。

3. 它不做什么？

跟需求拆解工具一样，这个排期工具也只做一件事：从 Story 清单到优先级得分 + 排期建议。

它不会帮你：

• 自动写代码
• 分配具体开发人员
• 管理需求的变更
• 跨项目资源协调

它的定位同样是“外挂大脑”——把繁琐的算分、依赖解析、迭代容量计算自动化，让你从“拍脑袋”变成“有理有据”。

写在最后

这套工作流目前已经在我和团队的产品日常中跑通。它不完美，但确实帮我省下了大量“反复澄清-遗漏异常-排期拍脑袋”的时间。

工具永远只是外挂，真正的大脑还是你自己。