Cloudflare 如何用 AI 重构内部工作流

从一组 API 密钥请求开始

约六个月前，一名销售团队成员希望获得多个生产系统的 API 密钥，以及部署流水线的管理员权限，用 AI 构建一款服务市场团队的“超级应用”。这类需求很快不再是个例。

Cloudflare 此前对 AI 的内部推广相对谨慎，主要使用信息问答工具和代码模板辅助能力。但随着模型和智能体工具能力提升，越来越多技术与非技术岗位员工开始尝试用 AI 改变工作方式。

挑战也随之明确：既要让员工能够使用这些工具，又要保护内部系统、内部数据和客户数据。

为此，Cloudflare 在内部搭建了 Cloudflare OS。该平台结合了计算与零信任能力，并在实践中增加了面向新工作方式的定制服务。

AI 不应只是为了使用而使用。团队应先明确要解决的工作任务、痛点、瓶颈或错失的机会，再选择合适工具，以便把更多时间投入客户和产品问题。

AI 在编程领域表现突出，因此早期可执行任务的工具多围绕命令行、代码编辑器、终端和 Git 仓库设计。但并非所有员工都在开发工具中工作。

平台的目标是让员工带着自身领域知识，以更直观的方式改造工作流程，而不要求每个人都成为开发者。

AI 被定义为工具和工具制造者，而不是团队成员。人类需要对 AI 输出的质量、测试方式和相关流程负责。

这一原则同样适用于智能体：发布智能体的个人和团队应对其输出负责；当负责人离开时，其管理者需要继承相应责任。

工作流与智能体需要理解组织自身的业务、规范和知识。除了采用 AI 技术，企业还需要投入建设经过整理、可信且统一的上下文层。

员工通过角色、设备、区域等因素获得受限的数据访问范围。这些控制同样应适用于 AI 工具和智能体。

用户不应因为使用 AI 而获得更多数据权限；智能体仅应访问完成任务所必需的数据。共享智能体时，使用者获得的访问能力也应反映其自身权限，而非创建者权限。

AI 加快了代码产出，也让审查流程面临更大压力。Cloudflare 因此为工程团队建立了名为 Engineering Codex 的上下文层，用于沉淀工程原则与实践。

与只说明“不能做什么”的政策不同，Codex 更强调“应该怎样做”。代码库的每个部分都有对应领域负责人，对该领域的质量标准负责。

这一上下文被接入软件开发生命周期：

文中称，过去四个月中，这些智能体标记了近 25 万个潜在问题，阻止了 1.6 万次合并，并在代码编写前从近 600 份设计中发现架构问题。

Cloudflare 早期曾尝试向非工程人员提供与工程师相近、但界面更友好的工具。但代码导向的工作区并不适合大量知识工作场景，尤其是那些需要生成一次性成果、涉及多个业务系统的任务。

团队随后反向设计需求入口：员工可以把不愿亲自完成的工作发送到一个 AI 邮箱，由小团队借助 AI 工具处理。

在数百到数千次请求中，团队逐步识别出员工希望自动化的日常任务，并对需求进行人工分类，归纳出重复模式：

随着这些材料逐渐完善，部分邮件回复开始可以自动化。该阶段的核心目的，是积累足够多的常见工作任务，为后续自助式自动化平台提供基础。

Cloudflare OS 的首个版本是运行在其基础设施容器中的工作环境。用户通过浏览器访问，并在完成零信任认证后运行已沉淀的技能文件和工作流。

这种方式无需本地配置，用户打开浏览器即可开始工作。文中提到，一些新加入销售团队的员工在入职数天内，就能自动化此前可能需要数周完成的任务。

云端临时工作环境也被用于降低风险：环境只访问用户在本次会话中引入的数据，而不是默认接触用户电脑上的全部内容。安全团队可以获得审计可见性和网络控制能力，包括限制环境可访问的互联网目标。

用户可从跨部门提炼出的常见工作流开始，一键执行已有的技能与组织上下文；生成结果可在界面中展示，例如技术架构文档或演示文稿，并可与团队成员共享。

这一路径强调，企业部署 AI 的重点不只是选择模型或工具，而是同时建立四类能力：

对于希望推动 AI 自动化的团队而言，先用真实、重复且低价值的工作请求验证需求，再把成熟模式沉淀为技能和受控工作流，可能比直接鼓励所有人构建应用更容易形成可管理的实践。