Arch Day 149
Arch Day 149: LLM产品设计方法论 — PM视角的AI应用设计
LLM产品设计的核心挑战不是技术实现，而是如何在不确定性中建立用户信任——LLM输出本质上是概率性的，用户期待的却是确定性的答案。PM必须在两者之间架桥。
2026-08-26
第六阶段 - LLM与AI架构AI产品产品设计用户体验AI原生PMFLLM应用
日期: 2026-08-26 (Day 149) 阶段: 第六阶段 - LLM与AI架构 标签: #AI产品 #产品设计 #用户体验 #AI原生 #PMF #LLM应用
核心概念
一句话定义
LLM产品设计的核心挑战不是技术实现，而是如何在不确定性中建立用户信任——LLM输出本质上是概率性的，用户期待的却是确定性的答案。PM必须在两者之间架桥。
知识点详解
1. LLM产品设计原则
| 原则 | 说明 | 反例 |
|---|---|---|
| 透明性 | 告诉用户"这是AI生成的" | 假装AI是人类 |
| 可控性 | 用户能编辑/纠正AI输出 | AI做最终决策 |
| 渐进信任 | 从辅助→建议→自动化逐步升级 | 一上来就全自动 |
| 优雅降级 | AI不确定时明确说"我不知道" | 编造答案 |
| 来源可溯 | 引用来源让用户验证 | 无法追溯的断言 |
2. LLM应用三大模式
| 模式 | 用户交互 | 典型产品 | PM关注点 |
|---|---|---|---|
| Copilot | 人主导,AI辅助 | GitHub Copilot/Cursor | 建议质量、接受率 |
| Agent | AI主导,人监督 | Devin/Claude Code | 任务完成率、可靠性 |
| Workflow | AI嵌入流程 | Notion AI/Zapier AI | 流程集成度、效率提升 |
3. AI产品的度量指标
| 传统SaaS指标 | AI产品等效指标 |
|---|---|
| DAU/MAU | AI功能使用率(用户是否真的用AI) |
| Conversion Rate | 建议接受率(AI建议被采纳的比例) |
| NPS | 信任度评分(用户对AI输出的信心) |
| Time on Task | 任务效率提升(有AI vs 无AI的时间对比) |
| Support Tickets | Revision Distance(AI输出需多少人工修改) |
4. 常见AI产品陷阱
| 陷阱 | 表现 | 解决 |
|---|---|---|
| Demo Trap | Demo惊艳,实际使用差 | 用真实数据做benchmark |
| Feature Creep | 给AI加太多能力 | 聚焦一个核心场景做到极致 |
| Hallucination Ignore | 不处理幻觉问题 | RAG+来源引用+Guardrails |
| Latency Neglect | 不关注响应速度 | Streaming+缓存+模型选型 |
5. AI产品的PMF验证
不同于传统SaaS——AI产品的PMF需要验证两层:
- 问题层: 用户是否真的需要AI来解决这个问题？
- 质量层: AI的输出质量是否足以替代/辅助人工？
验证方法: Wizard of Oz测试(人工模拟AI) → A/B测试(AI vs 无AI) → 质量指标跟踪。
面试题
问题：如何为一个金融知识库设计AI助手产品？
回答：1) 模式选择：Copilot模式(辅助而非替代分析师)；2) 核心功能：RAG检索+来源引用+结构化总结；3) 信任建立：每条回答附来源链接，用户可点击验证；4) 安全：金融数据敏感，Guardrails防止信息泄露，审计日志；5) 度量：建议接受率>60%为PMF信号。