怎么把一篇 AI 应用文档写得真正有用
这一页不再只是“我以后想写什么”的说明，而是我给自己定的一套写法。
目标很简单：以后在这里写一篇 AI 应用文档，至少要让人看完之后知道这东西为什么值得做、为什么好用、为什么难做，而不是只看见一串功能名词。
先别从“功能列表”开始
很多 AI 应用文档一上来就写：
- 支持多轮对话
- 支持工具调用
- 支持知识库
- 支持工作流
这种写法最大的问题不是不对，而是没用。
因为它没有回答更关键的问题：
- 它到底解决了谁的什么问题
- 哪个体验是真正的核心杠杆
- 这些体验背后靠什么系统机制撑住
- 它什么时候还只是 demo，什么时候已经开始长出系统复杂度
我会强迫自己用三个层面去拆
1. 产品层
先回答它为什么值得存在。
- 它服务的是谁
- 目标任务到底是什么
- 不用 AI 时，这件事原来怎么被做
- 它真正省掉的是什么成本，或者提升的是什么体验
如果这一层说不清，后面的技术拆解大概率也会飘。
2. 体验层
再去拆它为什么“看起来顺手”。
- 哪个体验只是表层功能
- 哪个体验其实来自上下文组织、反馈节奏或任务拆分
- 哪个点是用户愿意继续用下去的关键杠杆
这一层如果只会写“交互很流畅”“体验很好”，那基本等于没写。
3. 系统层
最后才看它为什么“撑得住”。
- 状态存在哪里
- 权限怎么收口
- 预算怎么限制
- 长任务怎么异步化
- 失败怎么回退
- 观测性从哪里拿
很多东西在 demo 里可以假装不存在，但只要你想长期跑，它们迟早都会回来。
每篇文档至少要回答这 5 个问题
- 这个应用最核心的问题定义是什么
- 它最值钱的体验不是哪一个功能，而是哪一个机制
- 如果把模型能力当黑盒，真正决定效果的工程组织点是什么
- 它现在还只是 demo，还是已经开始出现系统复杂度
- 它最容易被高估的地方在哪里
如果这 5 个问题里有 3 个都答不上来，我宁可先不写正文。
我会优先采用的最小结构
1. 这是什么应用，解决谁的问题
一句话说清对象和目标，不绕。
2. 它最关键的体验杠杆是什么
不要写“功能很多”，要写“哪个体验点让它成立”。
3. 这个体验背后的系统机制是什么
把它拆回上下文、工具、状态、权限、异步任务、预算或观测性。
4. 它的边界和代价是什么
别只写优点。要写哪里容易翻车，哪里最烧钱，哪里一扩展就会复杂。
5. 我的判断是什么
最后必须给结论：
- 值不值得做
- 值不值得学
- 值不值得继续投入
哪些写法我会主动避开
- 把原项目文档换个说法再写一遍
- 用“大而全”的综述掩盖自己其实没判断
- 只讲产品想象，不碰系统约束
- 通篇都在夸，没有任何保留意见
一句自查
如果把应用名字抹掉，这篇文档还能成立，那说明我大概率还没抓住它真正的特征。