第2393篇：AI产品的需求分析方法——工程师视角的AI功能PRD

适读人群：有2年以上开发经验、正在或准备参与AI产品规划的Java工程师 | 阅读时长：约12分钟 | 核心价值：掌握从技术视角拆解AI功能需求的系统方法，写出真正可落地的AI功能PRD

上个月，我们团队接到一个需求：「给客服系统加个AI，让它更智能。」

就这一句话。

产品经理觉得自己说清楚了，研发负责人觉得需求太模糊，双方开了三次对齐会，还是没对齐。最后是我坐下来，用了半天时间把这个需求拆成了一份13页的AI功能PRD，才让项目真正启动起来。

这不是个例。「加个AI」这四个字，正在成为2026年最高频、最模糊、最容易翻车的产品需求。

今天我想系统讲一下，工程师视角的AI功能PRD应该怎么写。

---

为什么普通PRD不够用

传统软件的需求可以写成确定性的规则：「用户点击按钮，系统保存数据，返回成功提示。」输入确定，输出确定，测试用例也确定。

AI功能不一样。

AI的输出是概率性的，同样的输入可能产生不同的输出。AI有幻觉问题，有延迟问题，有成本问题，有边界case问题。如果用写普通功能的方式写AI需求，工程师拿到的PRD里永远有一堆「AI自动判断」「AI智能处理」这样的描述，根本无法落地。

工程师视角的AI功能PRD，需要把以下几个维度想清楚：

1. 这个AI功能解决什么具体问题——不是「让系统更智能」，而是「把客服平均处理时长从8分钟降到4分钟」
2. AI在哪个环节介入——是全流程替代还是辅助增强
3. AI的输入和输出的数据规格——输入什么格式，输出什么格式，精度要求是什么
4. 可接受的失败模式——AI答错了怎么办，超时了怎么办，置信度低了怎么办
5. 成功标准如何量化——上线后拿什么数字证明这个AI功能做对了

---

AI需求分析的五步框架

第一步：锁定业务问题，不要锁定技术方案

很多工程师拿到需求的第一反应是「用RAG还是Fine-tuning」「用哪个模型」。这是本末倒置。

正确的第一步是追问：这个功能要解决用户的什么痛点？

以客服AI为例，正确的问题序列是：

当前痛点：客服每天处理200+工单，重复问题占60%，工程师精力被大量消耗
用户期望：快速得到准确答案，不用等待人工
业务目标：把重复问题的自动化率提升到70%
技术约束：响应时间<3秒，准确率>85%，月成本预算<5000元

只有把业务目标和约束条件搞清楚，才能做出合理的技术选型。

第二步：绘制AI介入的流程图

AI不是万能的，它通常只能在流程的某个节点上发挥作用。把整个业务流程画出来，标注AI在哪里介入、介入程度是多少，这对工程师理解需求至关重要。

这张图告诉工程师三件事：

• AI有两个子功能：意图识别 + 答案生成
• 系统需要处理三种分支，不是非黑即白
• 人工兜底路径是必须的，不是可选的

第三步：定义数据规格

AI功能的输入输出规格是PRD中最容易被忽略、也最容易让项目翻车的部分。

一个完整的数据规格描述应该包括：

输入规格

• 数据类型：文本/图片/结构化数据
• 长度限制：单次输入最大Token数
• 语言范围：中文/英文/多语言
• 特殊字符处理：是否过滤HTML标签、是否处理emoji

输出规格

• 格式要求：纯文本/Markdown/JSON结构化
• 长度范围：最短XX字，最长XX字
• 必须包含的信息要素
• 禁止出现的内容（敏感词、竞品名称等）

质量指标

• 准确率目标：行业标准或业务要求的最低值
• 响应时间：P50/P95/P99的目标值
• 可用性：SLA要求

第四步：设计失败模式和降级策略

这是工程师视角PRD和产品经理PRD最大的差别所在。

AI会失败，这不是bug，这是特性。一个好的AI功能PRD必须把所有失败场景都列出来，并给出处理策略。

失败场景	触发条件	处理策略	用户感知
模型超时	响应>5秒	返回兜底文案 + 转人工	「正在为您转接专员」
置信度过低	score<0.5	展示推荐问题列表	「您是否想问...」
内容安全拦截	触发安全规则	拒绝回答 + 记录日志	「暂时无法回答此类问题」
模型服务不可用	API返回5xx	全量转人工	「AI助手维护中，为您转接」
回答质量过低	用户标记「没帮助」>3次/天	触发人工审核	无感知

第五步：定义验收标准

AI功能的验收不能靠主观感受，必须数字说话。

一个标准的验收清单应该包括：

功能验收：
□ 意图识别准确率（测试集）≥ 87%
□ 答案相关性评分（人工评估）≥ 4.0/5.0
□ 响应时间P95 ≤ 3000ms
□ 失败降级路径全部可用

安全验收：
□ 通过100条红队测试用例（注入攻击、敏感话题等）
□ 个人信息不出现在AI回答中
□ 所有对话日志正确落库

上线验收：
□ 灰度5%流量，自动化率达到目标的80%
□ 用户负反馈率<5%
□ 日均API成本在预算内

---

实战：用Java代码辅助需求验证

工程师的一个优势是可以在需求阶段就写验证代码，快速判断某个AI功能是否技术可行。

下面是一个客服意图识别的可行性验证Demo：

@SpringBootTest
public class IntentRecognitionFeasibilityTest {

    @Autowired
    private ChatClient chatClient;

    /**
     * 需求可行性验证：测试意图识别在真实业务问题上的表现
     * 在写PRD之前先跑这个测试，用数据说话
     */
    @Test
    public void validateIntentRecognitionAccuracy() {
        // 准备测试数据集（真实客服工单样本）
        List<TestCase> testCases = buildTestCases();
        
        int correct = 0;
        List<String> failedCases = new ArrayList<>();
        
        for (TestCase testCase : testCases) {
            String detectedIntent = recognizeIntent(testCase.userInput());
            if (detectedIntent.equals(testCase.expectedIntent())) {
                correct++;
            } else {
                failedCases.add(String.format(
                    "输入：%s | 期望：%s | 实际：%s",
                    testCase.userInput(), testCase.expectedIntent(), detectedIntent
                ));
            }
        }
        
        double accuracy = (double) correct / testCases.size() * 100;
        System.out.printf("意图识别准确率：%.1f%% (%d/%d)%n", 
            accuracy, correct, testCases.size());
        System.out.println("失败案例：");
        failedCases.forEach(System.out::println);
        
        // PRD中的验收标准：≥87%
        // 如果这里达不到，需要调整方案或降低预期
        assertTrue(accuracy >= 87.0, 
            "准确率未达到PRD要求的87%，当前：" + accuracy + "%");
    }

    private String recognizeIntent(String userInput) {
        String prompt = """
            你是一个客服意图分类器。根据用户输入，从以下类别中选择最匹配的一个：
            - BILLING: 账单和费用相关
            - TECHNICAL: 技术问题和故障
            - ACCOUNT: 账号和权限相关
            - RETURN: 退换货相关
            - OTHER: 其他
            
            只返回类别名称，不需要解释。
            
            用户输入：%s
            """.formatted(userInput);
        
        return chatClient.prompt()
            .user(prompt)
            .call()
            .content()
            .trim()
            .toUpperCase();
    }

    private List<TestCase> buildTestCases() {
        return List.of(
            new TestCase("我的账单怎么比上个月多了200块？", "BILLING"),
            new TestCase("APP打不开了，一直转圈", "TECHNICAL"),
            new TestCase("我想换个手机号绑定账户", "ACCOUNT"),
            new TestCase("买的东西质量有问题想退货", "RETURN"),
            new TestCase("这个月扣了我两次钱", "BILLING"),
            new TestCase("密码忘了怎么找回", "ACCOUNT"),
            new TestCase("收到的商品和图片不一样", "RETURN"),
            new TestCase("网页一直报错500", "TECHNICAL"),
            new TestCase("发票怎么开", "BILLING"),
            new TestCase("账号被锁定了", "ACCOUNT")
        );
    }

    record TestCase(String userInput, String expectedIntent) {}
}

@Service
public class AIPRDValidator {
    
    private final ChatClient chatClient;
    
    public AIPRDValidator(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }
    
    /**
     * 验证AI回答的长度是否符合PRD规格
     * PRD要求：回答在50-500字之间
     */
    public ValidationResult validateResponseLength(String question) {
        String response = chatClient.prompt()
            .user(question)
            .call()
            .content();
        
        int length = response.length();
        boolean isValid = length >= 50 && length <= 500;
        
        return new ValidationResult(
            isValid,
            String.format("回答长度：%d字 (要求：50-500字)", length),
            response
        );
    }
    
    /**
     * 验证响应时间是否符合PRD规格
     * PRD要求：P95 ≤ 3000ms
     */
    public LatencyStats measureResponseLatency(List<String> questions, int iterations) {
        List<Long> latencies = new ArrayList<>();
        
        for (int i = 0; i < iterations; i++) {
            String question = questions.get(i % questions.size());
            long start = System.currentTimeMillis();
            chatClient.prompt().user(question).call().content();
            latencies.add(System.currentTimeMillis() - start);
        }
        
        Collections.sort(latencies);
        long p50 = latencies.get((int)(latencies.size() * 0.50));
        long p95 = latencies.get((int)(latencies.size() * 0.95));
        long p99 = latencies.get((int)(latencies.size() * 0.99));
        
        return new LatencyStats(p50, p95, p99);
    }
    
    record ValidationResult(boolean valid, String message, String content) {}
    record LatencyStats(long p50, long p95, long p99) {}
}

这段代码的意义不是为了上线，而是在需求分析阶段就验证技术假设。跑完测试，你就有数据告诉产品经理：「这个方案当前准确率是81%，达不到87%的要求，我们需要调整策略——要么接受更低的准确率，要么加人工审核环节，要么增加Fine-tuning预算。」

---

PRD模板：AI功能需求文档结构

基于上面的框架，我整理了一个AI功能PRD的标准结构：

1. 需求背景
   1.1 业务痛点描述
   1.2 当前解决方案的不足
   1.3 引入AI的核心价值

2. 目标与范围
   2.1 业务目标（量化）
   2.2 功能范围（做什么/不做什么）
   2.3 上线时间要求

3. 功能设计
   3.1 AI介入的业务流程图
   3.2 输入规格
   3.3 输出规格
   3.4 交互设计说明

4. 技术要求
   4.1 性能指标（延迟/吞吐/可用性）
   4.2 成本约束
   4.3 数据安全要求
   4.4 依赖的基础设施

5. 失败处理
   5.1 降级策略
   5.2 异常场景处理
   5.3 人工兜底方案

6. 验收标准
   6.1 功能验收指标
   6.2 性能验收指标
   6.3 安全验收要求
   6.4 上线验收检查清单

7. 风险与假设
   7.1 技术假设
   7.2 已知风险
   7.3 未解决问题

---

一个容易踩的坑：AI需求的"范围蔓延"

AI需求有一个特别容易出现的问题：范围蔓延（Scope Creep）。

「既然能识别意图，能不能顺便分析情绪？」 「识别出来以后，能不能直接给用户推荐产品？」 「推荐了以后，能不能接着完成下单？」

每一步扩展听起来都合理，但工程复杂度是指数级增长的。意图识别是一个独立的AI任务，情感分析是另一个，推荐系统是第三个，这三个组合在一起的调试成本、维护成本、出错概率都会急剧上升。

工程师视角的PRD必须明确写出「不做什么」，这和「做什么」同等重要。

---

总结

AI功能PRD不是产品经理的工作，也不是工程师的工作，它是需要双方用同一种语言沟通的产物。工程师的价值在于：

1. 把模糊的「AI很智能」翻译成具体的技术规格
2. 在纸面阶段就识别出技术风险
3. 用代码验证需求可行性，而不是开发完了才发现做不到
4. 为验收标准提供可测量的数字依据

下一篇我们会深入讲如何定义AI功能的成功指标——这是PRD写完之后，让AI功能持续改进的核心能力。