做 AI 产品时如何选切入点、管理非确定性输出并建立长期壁垒

当团队要决定 AI 用在哪里、如何在概率性输出下设计产品、以及如何避免被基础模型进步碾平时，用这套策略流程。

适用场景

解决思路

1. 定义切入点（Define the wedge）：找出用户产品中摩擦最大的高摩擦琐事（high-friction chore），优先选择 AI 能带来不成比例回报的场景。
2. 选择架构（Select the architecture）：按需求在 retrieval-augmented generation (RAG) 与 fine-tuning 之间二选一——需要实时/内部数据用 RAG，需要特定且一致的行为风格用 fine-tuning。
3. 安全地扩大自主性（Scale agency safely）：设计分级的自主度方案，在走向全自动化之前始终保留 human-in-the-loop。
4. 面向曲线构建（Build for the curve）：把产品路线图对齐未来的模型能力，而不是为今天的模型局限搭建复杂脚手架。
5. 为“软输出”做设计（Account for squishy outputs）：在 UI 设计上假设 AI 是非确定性、不完美的，不要试图把 100% 准确率硬塞进产品体验里。
6. 把产品当作活的有机体（Treat products as living organisms）：用团队摄入数据、改进学习回路的“代谢速度”衡量成功，而不是用静态的功能发布衡量。
7. 在垂直化中找防御性（Find defensibility in verticalization）：不要正面竞争基础模型，转而瞄准特定行业细分，让领域专长和专有数据形成结构性优势。
8. 孵化特定超能力（Incubate specific superpowers）：不做通用 AI 功能；先向客户询问“如果 Slack 拥有这些新超能力，你希望它能做什么”，再给专门的团队独立空间去做原型、试点，最后推出让人惊艳的功能。
9. 为模型的未来构建（Build for the model's future）：按 12–18 个月后预期具备的能力来设计，避免自建脚手架最终被模型原生能力“当早餐吃掉”。
10. 采用渐进式自主（Adopt a graduated approach to autonomy）：从影响最小、人类控制最多的场景开始部署，摸清当前能力边界后再逐步增加 agency、减少控制。
11. 用诊断问题引导用户：问“你的产品里哪个高摩擦琐事用自动化回报最大？”
12. 用诊断问题引导用户：问“你的用例需要访问实时、内部数据，还是需要一种特定且一致的行为风格？”
13. 用诊断问题引导用户：问“你打算如何设计界面来处理非确定性或错误的 AI 输出？”
14. 用诊断问题引导用户：问“你正在构建的功能，会不会在一年内被基础模型的一次更新淘汰？”
15. 用诊断问题引导用户：问“你有哪些竞争对手不易获取或复制的专有数据？”
16. 用诊断问题引导用户：问“你将如何长期衡量产品学习回路的代谢速度？”
17. 查阅现成模板与框架作为决策辅助：AI Glossary、AI Product Builder's 12 Principles、CC/CD（Continuous Calibration/Continuous Development）框架、AI Integration Decision Framework、The Bitter Lesson Applied to AI Product Building、AI Startup Defensibility Framework、Prototype-First vs. Design-First、Data > Interface > Model 差异化栈、Stickiness Over Moats。
18. 完整案例与出处见 references/guest-insights.md 与 references/artifacts.md，需要细节时按图索骥。

适用边界 · 注意事项

• 不要为当前模型的局限搭建复杂脚手架，基础模型很快就会吸收这些功能，这是必输策略。
• 不要为了“加 AI 而加 AI”，没有经过验证、有数据支撑的用户问题的通用 AI 功能无法带来价值和防御性。
• 不要把 prompt engineering 置于数据质量之上，AI 功能的效果往往更多受限于底层数据的质量与时效，而不是提示词本身。