产品与业务定义：先决定做什么

Last updated: 2026-07-05

团队级 AI 开发的第一步不是让智能体写代码，而是先把业务意图写清楚。

AI 很擅长根据提示补全细节。问题是，如果业务目标不清楚，它补全出来的不是答案，而是团队还没做过的产品决策。个人项目里，这只是一次返工；团队项目里，它会变成多人理解不一致、接口设计不一致、验收标准不一致。

所以产品与业务定义不是“产品经理的前置文档”，而是团队级 AI 开发的第一道工程边界。

---

为什么产品定义更重要了

过去写代码慢，很多模糊需求会在开发过程中自然暴露。AI 让实现速度变快以后，模糊不会消失，只会更快地固化成代码、接口、表结构和页面。

这会带来三个变化：

• 范围漂移更快：智能体会主动补功能，看起来贴心，实际上绕过了团队决策。
• 错误更像正确答案：生成的代码结构完整、命名合理、页面能跑，反而更难一眼看出它偏离了真实目标。
• 返工成本后移：需求没想清楚时，后面要改的不只是代码，还有数据、接口、测试、文档和用户预期。

产品定义的价值，是把“我们到底要解决什么问题”变成团队和智能体都能执行的边界。

---

产品定义要产出什么

一个足够好的产品定义，不需要很长，但必须能回答五个问题：

问题	产出物	为什么重要
谁会用	用户角色、使用场景	防止功能按开发者想象设计，而不是按真实使用路径设计
解决什么	问题陈述、目标行为	让智能体围绕结果实现，而不是围绕功能名发散
本期做什么	用户故事、核心流程	明确可交付范围，方便拆任务和验收
本期不做什么	非目标、延期项	防止智能体顺手扩展，防止 review 时反复争论范围
怎么算完成	验收标准、边界场景	把“看起来可以”变成可验证行为

这五个问题回答清楚以后，后续的技术设计、任务拆解、测试和 review 才有共同依据。

---

第一步：定义问题，而不是定义功能

功能名很容易误导智能体。例如“做一个审批模块”太宽泛，它可以生成表单、流程引擎、通知、权限、日志、后台配置。每个方向都合理，但不一定是你要的。

更好的起点是问题陈述：

目标用户：团队管理员。
当前问题：管理员需要手动收集团队成员提交的信息，过程分散在聊天、表格和邮件里，容易遗漏。
本期目标：提供一个可配置的信息收集流程，让管理员能创建收集任务、查看提交状态、导出结果。

为什么这样设计：问题陈述限定了智能体的推理空间。它知道这是“信息收集”，不是完整 BPM，也不是通用审批流。

---

第二步：写清用户故事和主路径

用户故事不要只写“作为用户，我想要某功能”。团队级开发需要把主路径写到能拆任务的程度。

一个可执行的用户故事可以这样写：

用户故事：管理员创建信息收集任务。

主路径：
1. 管理员输入任务标题、说明、截止时间。
2. 管理员选择需要填写的字段。
3. 系统生成任务并展示提交链接。
4. 成员打开链接并提交信息。
5. 管理员在列表中查看提交状态。

验收标准：
- 未到截止时间前，成员可以提交或修改。
- 截止后，成员不能继续提交。
- 管理员能看到已提交、未提交、逾期三类状态。

为什么这样设计：智能体最容易在“流程缺口”里自由发挥。主路径越清楚，生成的接口、状态、页面和测试越一致。

---

第三步：明确非目标

非目标不是可有可无的补充，而是团队级 AI 开发的护栏。

例如：

本期不做：
- 不支持多级审批。
- 不支持字段之间的复杂联动。
- 不做移动端独立适配。
- 不做组织架构同步，只支持手动选择成员。

为什么这样设计：智能体很容易把“常见产品能力”当成“应该实现的能力”。非目标能阻止它把行业常见完整方案塞进本期交付。

非目标还有一个作用：保护 review。评审者看到额外实现时，不需要重新判断“这个能力是不是也挺有用”，只要对照非目标即可。

---

第四步：做 MVP 切分

MVP 切分不是把功能砍少，而是找出“没有它产品就不成立”的最小闭环。

可以用三个问题判断：

1. 没有这个能力，核心流程还能不能跑通？
2. 这个能力做到什么程度，刚好能支撑本期目标？
3. 这个能力如果延后，会不会导致后续架构推倒重来？

把能力分成三类：

类型	判断标准	处理方式
核心能力	没有它，产品目标不成立	本期必须做，但只做到刚好够用
价值增强	没有它能用，但体验或效率下降	降级实现或二期补充
边缘能力	没有它不影响主流程	明确写入非目标

为什么这样设计：AI 会倾向生成“完整方案”。MVP 切分让团队用业务价值控制实现规模，而不是让实现便利性反过来定义产品。

---

第五步：把产品定义转成智能体上下文

产品定义写完后，不应该停在文档里。它要进入智能体实际工作的上下文。

常见做法：

• 把稳定的项目定位、核心边界写入 CLAUDE.md。
• 把本期需求、用户故事、验收标准写入任务说明或规格文档。
• 把非目标放在任务开头，优先级高于实现建议。
• 把主路径和边界场景转成测试用例或验收 checklist。

示例任务上下文：

请实现“管理员创建信息收集任务”的后端接口。

必须遵守：
- 只实现创建任务、查询任务、提交信息、查看提交状态。
- 不实现多级审批、字段联动、组织架构同步。
- Controller 不写业务逻辑，业务逻辑放 Service。
- 完成后补充主路径测试和截止时间边界测试。

为什么这样设计：产品定义只有进入执行上下文，才能真正约束 AI。否则它只是人读过的文档，不是智能体会遵守的规则。

---

常见失败模式

团队在产品定义阶段最常见的问题，不是想得不够多，而是没有把关键决策写成可执行边界。

失败模式	结果	修正方式
只写功能名	AI 自行补全产品形态	改成问题陈述、用户故事和主路径
不写非目标	范围持续膨胀	每个需求都明确本期不做什么
验收标准模糊	review 变成主观争论	写出具体行为和边界场景
MVP 切分过大	AI 生成复杂实现，后续难维护	区分核心能力、价值增强、边缘能力
产品定义不进入上下文	智能体执行时仍然不知道边界	写入任务说明、规格文档或 CLAUDE.md

---

最小模板

每个团队都可以从这个模板开始：

# 业务定义

## 问题
- 目标用户：
- 当前问题：
- 本期目标：

## 主路径
1.
2.
3.

## 本期范围
- 必须做：
- 降级做：
- 不做：

## 验收标准
- 正常流程：
- 异常流程：
- 边界场景：

## 需要沉淀到上下文的规则
-

模板的目的不是形式统一，而是让团队每次都先回答最容易被忽略、但最容易影响后续实现的问题。