大模型很擅长制造一个令人兴奋的开始。给它一个目标，它可以写出代码、生成页面、整理资料，甚至调用工具完成一连串操作。
但真实产品面对的问题通常不是“它能不能做一次”，而是“它能不能在明确边界内稳定地做，并且在失败时不伤害数据”。
这也是我做 AI 应用时最关心的部分。
把能力和权限分开
模型能够提出修改建议，不等于它应该直接修改生产数据。工具能够访问一个系统，也不等于每次任务都需要全部权限。
我更愿意把任务拆成几个边界清楚的阶段：
- 先读取必要信息，不扩大数据范围。
- 生成可以检查的中间结果。
- 在关键动作前设置人工确认。
- 执行后保存测试、日志或浏览器证据。
- 失败时回到一个已知状态，而不是继续猜。
这些步骤看起来会让第一次演示慢一点，但会让系统更容易长期运行。
失败不是异常情况
外部接口会超时，网页结构会变化，模型输出会偏离格式，权限也可能在运行中失效。如果工作流只设计成功路径，那么一次小问题就可能变成数据错误或无法恢复的半成品。
所以，失败降级不是上线前补上的异常处理。它应该和主流程一起设计。
例如，AI 元数据生成失败时，核心书签数据仍然应该能够保存；浏览器 QA 被环境阻塞时，任务状态应该明确保持为未通过；自动审查没有证据时，也不应该被写成已经完成。
证据让协作继续
AI 加快了构建速度，也增加了复查的重要性。比“已经做完”更有价值的是一组别人可以继续使用的证据：
- 哪些文件发生了变化；
- 哪些测试真正执行过；
- 浏览器里看到了什么；
- 当前还剩什么风险；
- 如果下一次接着做，应该从哪里开始。
当这些信息被保存下来，AI 就不只是一次性生成器，而能成为工程流程中可管理的一部分。
我想做的 AI 应用
我不训练基础模型。我更关心如何让模型进入一个真实产品，并在权限、数据、失败和责任都清楚的情况下工作。
这类工作没有演示视频那么显眼，却决定了 AI 能力究竟停留在样品，还是成为可以被用户依赖的产品。