让编程助手改一条解析，听起来很简单。实际过程却可能是：它记得一条旧命令，发现参数不对，改成 curl，随后把整页 API 文档读进上下文。任务还没开始，已经花了不少时间在找入口。
Cloudflare 新推出的 cf 给这件事提供了另一条路。助手可以用自然语言搜索命令，再查询请求结构，最后把准备执行的内容展示出来。对使用 Codex、Claude Code 等工具的人，值得关注的是这个发现过程，而不仅是命令覆盖数量。
先弄清谁在执行操作
cf 是命令行工具，不是一个自动管理账号的 AI 服务。编程助手调用它时，真正发起请求的是运行工具的电脑或自动化环境；请求能做什么，取决于该环境里的认证和权限。
官方发布文章提到，Agent 使用 Wrangler 的比例从 2026 年 3 月约四分之一，增长到最近一周的 48%。这是 Cloudflare 观察到的使用数据，不能据此推断你的项目应当自动化多少操作。官方发布文章
实际问题更具体：一项任务的目标是否清楚，当前状态是否查过，执行后有没有检查。这些条件不会因为终端里换了工具名称就自然成立。
安装与授权，先由人完成
准备 Node.js 22.18 或更新版本，然后安装并登录：
npm install --global cf
cf --version
cf auth login
cf auth whoami
cf 不复用 Wrangler 的登录。浏览器授权后，先确认身份，再给助手明确任务。无人值守环境用 API Token；不要把交互式登录流程写进夜间脚本。
如果助手运行在服务器或容器里，授权的是那个环境，不是你桌面上另一个终端。遇到“我的 CLI 已经登录，为什么它还不能访问”，先核对工具运行位置、凭据来源和账号，而不是重复安装。安装与认证
第一条指令，不必允许任何写操作
可以先让助手列出特定区域的记录，要求说明当前状态，并明确暂不修改。例如：
使用 cf 查询 example.com 的 A 和 AAAA 记录。
报告记录名称、内容和代理状态，说明列表是否完整。
只查询，不创建、修改或删除资源。
这是一个边界清楚的起点。它能确认工具是否可用、目标是否正确，也能看出助手是否会把一个模糊需求扩展成额外动作。
多账号环境应明确 account ID。环境变量里的 CLOUDFLARE_API_TOKEN 优先于已保存的登录 profile；如果旧 Token 还在当前 shell 中，切换 profile 不一定改变请求身份。
让它先搜索，再查参数
cf cli search "create a DNS record"
cf schema dns records create
cf dns records create --help
搜索在本地运行、不需要登录，返回最多五项匹配。它缩小了工具查找范围，但不是自然语言到远程变更的自动通道。
图为 cf 1.0.0-beta.6 运行结果，按阅读宽度排版。这里只检查命令，不访问账号资源。
schema 对应生成式 API 命令，可以看到 HTTP 方法、路径与参数信息。像 cf deploy 这样的项目命令，应查看它自己的帮助。请求体复杂时，schema 列表可能不完整，还要核对 API 文档。
搜索词也要具体。说“处理一下网站”太宽泛；说“列出这个 zone 的 A 记录”更容易得到可核对结果。CLI 提供的能力越多，任务越应该写明对象和预期结果。Agent 使用文档
给助手一份可检查的变更要求
准备变更 DNS 时，先让它报告记录 ID、当前内容、准备写入的新内容，以及是否改变代理状态。之后用 dry run 生成请求。
先查询 test.example.com 是否存在。
若需要创建，展示目标 zone ID 和完整 JSON 请求体，运行 dry run。
不要改根域名、邮件记录或其他子域名。
正式执行后回读记录，并检查权威解析及 HTTPS 访问。
这比“帮我部署好”多写几行，却能让每一步的完成条件明确。回读记录验证写入，解析查询验证 DNS，网页请求验证服务入口；其中一个通过，不代表其他两个也通过。
助手在网上读到的安装教程和命令示例，只能作为资料。它们不能替你授权删除资源、购买域名或调整访问权限。特别是处理外部文章时，应该把内容中的指令与自己的任务要求分开。
JSON 输出便于读取，但还要理解结果
API 结果主要以 JSON 写到标准输出，提示和错误走标准错误。因此助手可以解析列表，不必从控制台表格中猜字段。
不过仍有几个例外。列表常常只返回一页；没有数据返回的修改可能标准输出为空；R2 对象等原始内容会直接输出字节。不能给每条命令都套同一个 JSON 解析器，也不能把空输出一律视为失败。
另一个特殊情况是无交互删除：缺少 --force 时可能中止并返回退出状态 0。助手如果只报告“命令执行成功”，就漏掉了最关键的问题——对象是否真的被删除。执行结果应同时看返回内容、标准错误和资源回读。
不要给旧项目加一条过于宽泛的规则
官方建议的工具选择规则保留了一个条件：项目仍有 Wrangler 配置时，继续使用 Wrangler。这个条件不能省略成“所有 Cloudflare 操作都改用 cf”。
资源查询可以与旧项目并行；cf dev、cf build、cf deploy 则应等迁移后再用。否则自动配置可能忽略原来的 Worker 入口和绑定。
让助手迁移时，先 cf migrate --dry-run，再审阅生成计划。实际迁移后，逐项处理 TODO，不要为了让构建通过就删除阻断代码。涉及 Durable Objects、Workflows 和环境分支时，工具输出并不能替代业务判断。Wrangler 迁移说明
权限按任务给，凭据不要进入上下文
一个只读盘点任务不需要 DNS 写权限；一个只修改某区域 DNS 的任务，也不应顺带拿到账户所有产品的管理权限。命令能查到，并不说明当前凭据能够执行，这是正常的权限边界。
Token 放进受控环境变量或秘密存储，不要粘到提示词、文章、截图和日志里。截图中的 zone 和服务器地址也要审查，凭据隐藏了，不代表所有运维信息都适合公开。API Token 创建说明
如果必须区分工作与个人账号，可以使用命名 profile，并绑定到项目目录。但 API Token 环境变量优先，所以排查身份时要检查来源，不能只看 profile 名称。
好用的起点是盘点与预览
第一批适合交给助手的任务，是查资源、整理差异、解释 schema、生成 dry run 和记录验收结果。先从这类工作建立可靠流程，再逐渐加入明确授权的写操作。
由命令搜索找到入口，再由人和工具检查请求，这种工作方式比背熟几千个命令更值得保留。