AI 是一种强大的工具，但它不是灵丹妙药。它的成功在很大程度上取决于具体的应用场景。了解其优势和劣势是妥善使用 AI 的关键。
在决定是否对某项任务使用 AI 时，请遵循以下原则作为您的指南：
- 反馈闭环至关重要： 决定成功与否的最重要因素是反馈闭环。您测试输出并纠正幻觉的速度有多快、多容易？代码和脚本的正确性远比主观内容的正确性更容易进行测试。
- 优先考虑增量任务： AI 通常更适合增量（additive）任务（例如您以前无法或不会做的全新事情），而不是维持业务运行所需的运营任务。
在寻求通过 AI 解决问题或简化流程之前，我们会问自己几个问题：
- 这是一项手动、重复性的杂务吗？
- 手动完成此任务需要耗费数小时、数天还是数周？
- 我们是否需要一遍又一遍地执行完全相同的操作？
- 是否有明确的逻辑可以让我们成功地识别或执行该操作？
- 这是否具备可扩展性，或者是否也对其他人有用？
如果我们可以对这些问题回答 yes，那么它就是基于 AI 的解决方案的强有力候选者。如果我们在任何一个问题上回答 no 或 I do not know，我们会先继续执行当前的流程，并寻找 AI 仍可能有所帮助的较小、具体的领域。
在这些领域，我们发现 AI 具有明确的积极作用和效果。
这是 AI 最积极、最值得推荐的用例。
- 为什么行之有效： 当您可以轻松“测试”幻觉时，AI 处于最佳状态，而代码具有高度的可测试性。
- 可以用它来做些什么：
- 编写本地脚本（如 Vibecoding 脚本）以自动更新我们的文档。
- 生成简单的文档组件。
- 创建 GitHub Actions。
- 辅助进行文档竞争分析。
- 关键优势： 您拥有生成的代码。它是稳定的且不会改变，无论未来 AI 模型或定价如何变化。
对于使用文档即代码（docs-as-code）方法的团队，集成到 IDE（如 Windsurf、Cursor 等）中的 AI 聊天非常适合进行多次、精简的修改。
- 为什么行之有效：
- AI 可以理解来自您的代码库（在此场景下为文档）的大量上下文。
- 发现和修复幻觉的反馈闭环非常短。
- Git 集成使查找、评审和清除幻觉变得容易。
- 关键优势： 这可以节省数天甚至数周的工作时间。对于需要重复完成相同任务的大大规模文档更新，支持 AI 的 IDE 可以显著简化该过程。
- 警告： 始终优先考虑更简单的解决方案（例如 regex），因为它们通常更好、更快且更便宜。当您需要对大型任务进行强力攻关或应对极高复杂度时，再使用 AI。
这些是展示出前景但需要谨慎实施的领域。
我们乐观地期望利益相关者在将文档移交给技术写作团队之前，使用 AI 来创建文档的初稿。
- 核心价值： AI 生成的草稿本身的质量往往参差不齐。其主要价值在于，它充当了一种强制机制，促使利益相关者将文档视为其产品的一部分——而不是与其产品分离——同时也能为我们忙碌的利益相关者提供一种尽快向技术写作团队共享关键信息的方式。
- 为什么？ 为了创建草稿，请求者必须首先收集所有必要的背景信息。提前收到这些信息对技术写作团队来说是一个重大的胜利。
- 行动： 有关构建此类请求的更多信息，请参阅我们的提示词模板。
我们在面向客户的聊天机器人方面的体验喜忧参半。
- 优点： 偶尔，它能提供非常出色的回答。
- 缺点： 为了防止幻觉，机器人通常会被设置得更加“自信”。这导致它们会拒绝回答（例如，“我不知道”），而用户并不喜欢这样。另一方面，用户也不喜欢幻觉。因此，请留意实际的用户体验，并想出一种方法来跟踪用户与您的文档聊天机器人的互动和成功率。根据结果，您可能会发现值得填补的文档空白，从而防止未来出现幻觉。
- 替代方案： 目前，我们对 AI 驱动的搜索和相似度评分的前景要乐观得多。这些感觉更在我们的控制之中。然而，我们仍在测试和跟踪我们的文档如何积极地影响 Cloudflare 内部以及通过第三方应用程序的聊天机器人体验。
根据我们的经验，我们目前不推荐以下使用场景。
在通过拉取请求（pull request）自动建议内容修改（例如语法、格式）的机器人方面，我们尚未取得成功。
- 为什么失败了：
- 反馈闭环缓慢： GitHub PR 的上下文使纠正幻觉的反馈闭环变得非常缓慢且困难。
- 参与度低： 我们发现，即使是我们自己的团队也经常关闭或忽略这些 PR，因为验证它们的代价太大了。
- 贡献者困惑： 一个类似的用于标记传入 PR 问题的机器人让贡献者感到沮丧和困惑，而且其建议往往是幻觉。