许多团队都有一些需求，还不足以专门做一个应用：一个用来审阅方案的比较工具、一份决策记录，或是一份只在迁移期间才用得上的清单。它们通常靠手头现成的工具解决。自己动手构建，就得决定放在哪里托管、数据如何保存、谁能进入。有时候，这些外围工作比工具本身还要繁重。
在《当软件与问题存在得一样久》中，我们讨论过为某项具体任务而生成的应用。但写代码只是其中一部分：这些应用还需要一个地方来运行、保存我们所做的工作，并且可以分享出去。Cloudflare OS 提出的正是这样一个地方。我们在 Codin 部署了它，想探索一下能用它做些什么。
一个你也可以修改的工作环境
Cloudflare OS 是 Cloudflare 的一个开源项目，它把 AI 智能体、小型应用和对外部服务的受控访问整合在一起。它在浏览器中使用，也可以部署在自己的环境中。
Cloudflare 给出的类比有助于理解它：想象一套办公软件，其中每个文件都可以是一个量身定制的应用。你不必总在文档、电子表格和演示文稿之间做选择，而是可以创建一个工具，带有你需要的字段、视图和操作。OS 把这些应用称为 gadgets，你可以调整并分享它们。
用一个简单的例子就能看出区别。假设我们要比较几家供应商的方案。表格可以收集数据，但我们可能还需要标出疑问、保留每项评估的理由，并且只显示关键的差异。一个属于我们自己的应用，可以把整个流程集中到同一个界面上。OS 的价值在于提供一个共同的环境来构建这类工具，而不必为每个工具单独准备一套基础设施。
示意示例从想法到工具
对话
我想比较三家供应商的方案：工期、范围和支持。
我来准备一个比较工具，每个方案一列，每项标准一行。
加上每个方案的条件，并支持按是否包含支持来筛选。
描述：请求从一项具体任务出发。只需说明要比较什么、按哪些标准比较。
构建：助手给出 gadget 的第一个版本。这里是一个框架，包含三家虚构供应商、工期和范围。
调整：审阅过程中出现了新需求。工具增加了一行条件，以及一个筛选器，把不包含支持的方案放到次要位置。
从请求一个工具，到用它来工作
内置助手可以让你描述一个 gadget，并对它提出修改。第一个版本做好之后，对话还可以继续：添加一个视图、改变某个结果的呈现方式，或者加入一个操作。工具的代码始终可用，方便继续修改。
这改变了我们与小型应用的关系。回到比较工具的例子：如果在审阅中途发现还需要记录供应商的某项条件，就可以据此修改工具。我们不必再把整个任务硬塞进第一个界面所能支持的范围。当然，还需要确认这次修改保留了数据，并且按我们的预期运行。
在 OS 中，对话和应用共处于同一个空间。左侧是需求及其历史记录；右侧可以使用 gadget、打开它的文件，或查看它所连接的服务。下面是我们实例中的三个视图：
真实截图一个 gadget，三种工作方式
1 · 需求始终可见。在这个例子中：一个包含销售管道、跟进和来自 Radar 的商机的 CRM。下方记录了修改已被接受。
2 · 应用就在旁边使用。App 标签页会打开 gadget：可以查看看板并处理其中的数据，无需离开这个空间。
1 · 文件随时可访问。Code 汇集了 gadget 的界面和逻辑。切换一个标签页，就能从应用转到它的实现。
2 · 规则可以审查。这里可以看到 CRM 的各个阶段及其使用的上下文。在我们检查代码时，对话仍在旁边。
1 · gadget 的资源有独立的面板。Connections 显示可用的模型，以及代码调用它时使用的名称：LUNA。借助这个连接，可以在 CRM 中请求分析。
我们用这个 CRM 来试验这一流程，数据是从 Codin Radar 导入的公开信息。它还只是第一个版本，需要手动导入，但已经集合了一个能保存数据的应用、一份我们可以修改的代码，以及一个用于分析商机的 AI 连接。
这个例子还区分了 AI 的两种用途：一种帮助编写工具，另一种在工具内部完成任务。保存一条备注或更改一个阶段，依然是传统软件的工作。应用并不需要每次有人使用时都由模型重新想象一遍。
用你已经在用的工具来构建
在我们的试验中，我们在自己惯用的环境里用 Codex 编写了 gadget，再通过 OS 的 API 进行安装。这个 API 使用了 Cap’n Web，这是 Cloudflare 的一个库，用于从 JavaScript 调用远程函数。整个流程就是修改代码、审查代码，然后提交新版本。
我们认为这一点对技术团队尤其有用。我们可以继续使用已经习惯的编辑器、模型和代码审查方式。即使构建工作是在 OS 自带助手之外完成的，OS 依然是应用运行和保存数据的地方。
这也便于分工。一个人可以提出需求并审查界面；另一个人可以负责那些需要更加谨慎处理的部分。对话帮助把工具的需求具体化，而当需要理解或修正其行为时，代码依然就在那里。
分享一个工具，或复用它的设计
OS 区分了使用权限和构建权限。获得前者的人可以使用应用及其功能；获得后者的人还可以修改代码。使用并不只是查看：一个 gadget 可以允许他人录入信息或请求分析，而不授予其开发权限。
还有一种同样有意思的分享方式：blueprints（蓝图）。它们是完整应用的模板，可以让其他人创建属于自己的 gadget 副本，拥有独立的存储和连接，而不会带走原实例的历史记录、已保存的数据或凭据。
这种区别很实际。一个团队可以在同一份迁移清单上协作；另一个团队则可以复用它的设计，用于另一次迁移，配上自己的系统和负责人。前一种情况下，他们共享的是工作；后一种情况下，共享的是一个让他们不必从零开始的工具。
示意示例共享工作，还是共享设计
Lucía同一实例原始实例
北区迁移
- 邮件服务器 Lucía：检查 DNS
- 客户数据库 Andrés：已导出
- 办公室 VPN Lucía：待处理
Andrés同一实例新副本
北区迁移
- 邮件服务器 Lucía：检查 DNS
- 客户数据库 Andrés：已导出
- 办公室 VPN Lucía：待处理
南区迁移
- 供应商门户 Andrés：申请访问
- 文件存储
- 楼层打印机 Andrés：盘点
一起工作：两个人打开同一个工具，看到相同的数据，因此一人记下的内容会显示给另一人。拥有使用权限就可以录入信息；修改代码则需要构建权限。
创建副本：blueprint 描述了完整的应用，可以用它创建另一个拥有独立存储和连接的实例。复用的是设计；原实例的历史记录、数据和凭据不会进入副本。
外部连接在这一设想中也有其位置。OS 使用 Gatekeepers，这类组件负责居间管理智能体和 gadget 对特定资源的访问。这需要配置相应的集成：部署 OS 并不会自动连接公司的所有系统。
什么值得拥有一个专属工具
Cloudflare 将 OS 定位为一个仍在开发中的项目。我们的经验也还很初步：我们试用了一个应用，并没有衡量团队生产力的变化。而且，自建工具仍然需要维护；如果一个流程依赖大量集成或需要持续支持，成熟的产品可能是更好的选择。
即便如此，那些通用工具只能覆盖一半的小任务，依然值得关注。一个方案审阅工具可以伴随一项反复进行的流程；一份迁移清单也许只在几周内有意义。两者都需要界面、规则和能够保存下来的数据，尽管它们的存续时间不同。
我们希望在 Cloudflare OS 上继续探索的，正是这种可能性：让这些工具可以安身的地方提前准备好。如果每个工具都需要启动一个完整项目，很多工具根本不会被考虑。如果一部分工作已经解决，问题就可以更贴近任务本身：我们需要做什么，以及什么样的应用能帮我们做到。
