万网 DomainCLI 把域名操作按影响面分成三级确认：第一级只读查询不设确认关卡，第二级写操作默认只输出预览、必须显式带上 --confirm=true 才真正提交，第三级涉及未来周期扣费的操作，在写操作确认之外还要再加 --ack-future-charge 单独确认费用预期。配套的输出契约会屏蔽 AK/SK、临时 Token、转移码、联系人原文四类敏感信息，凭证走 OAuth 临时授权，不随日志和工单扩散。这套机制的核心思路是把 "动作要不要发生" 和 "费用是否知悉" 拆成两道独立关卡，让 AI Agent、流水线和脚本最多跑到预览这一步，没有人工显式确认就不落库，从而把误操作挡在提交之前。需要说明的是，三级机制防的是手滑和凭证泄露，不替代业务判断、备案合规和实人核验这类需要人负责的环节。
一、为什么命令行改域名更需要刹车
在控制台修改一条解析，要经过找域名、进解析、点编辑、保存几个页面，每一步都留有反应时间；到了命令行，一条命令敲完回车就执行，中间没有页面提醒。而域名属于 "改错一条 A 记录可能整站下线、漏续一次品牌入口可能易主" 的资产，操作代价高，所以命令行工具必须在提交前设置分级刹车。
二、三级安全机制总览
| 级别 | 操作类型 | 确认方式 | 确认参数 | 典型操作 |
|---|---|---|---|---|
| 第一级 | 只读查询 | 无需确认 | 无 | 域名列表、详情、whois、可注册性判断、解析记录读取、备案进度查询 |
| 第二级 | 即时影响的写操作 | 默认仅预览，人工核对后显式提交 | --confirm=true | DNS 记录增改、名称服务器切换、转移锁、域名转出、建站发布 |
| 第三级 | 未来周期扣费操作 | 写操作确认之外，再单独确认后续扣款 | --ack-future-charge | 自动续费状态设置等涉及周期性扣费的动作 |
三、第一级：只读查询，不设确认关卡
查询类命令不改资源、不产生订单，因此不需要额外确认，设计取向是 "先看清楚"。
常见只读命令
- list：盘点账号下的域名资产；
- detail：查看单个域名详情；
- whois：查询注册信息；
- check：判断域名可注册性；
- search：扩展候选后缀；
- dns list：读取解析记录；
- icp status：查询备案进度。
使用要点
- 输出是经过字段白名单过滤的结构化摘要，可直接交给 jq 处理，也可写进巡检脚本或内部看板；
- 这一级的风险不在 "改错"，而在 "读错"：查询结果只代表执行那一刻的账号状态，域名状态和价格会实时变化，不能当成长期不变的结论。
四、第二级：写操作默认预览，--confirm=true 才提交
DNS 记录增改、名称服务器切换、转移锁、域名转出这类动作有即时影响，DomainCLI 的处理方式是：默认只输出预览，不落变更；核对无误后，显式加上确认参数才真正提交。
确认路径
- 默认预览：先展示将要发生的变更，不写入；
- 人工核对：对照域名、记录值、TTL、指向等信息逐项检查；
- 显式确认：命令带上 --confirm=true；
- 提交变更：确认后才真正落库；未确认则不落库。
第一次执行：只输出将要发生的变更
aliyun domain dns update <域名与记录参数>
核对预览后再次执行，带确认参数才提交
aliyun domain dns update <域名与记录参数> --confirm=true
自动化场景下的价值
- Agent 可以生成方案、调用命令，但拿不到 "人已确认" 这个信号，就提交不了变更；
- 流水线同样只能跑到预览步，能否真正落库取决于有没有显式传入确认参数；
- 建站发布沿用同一套逻辑：wxz chat-start 与 wxz deploy 默认输出预览，确认后才发布；发布在服务端异步执行，命令返回任务状态不等于页面已生效，需要用 deploy --operation status 跟踪进度；
- 回滚使用发布历史里的编号，而不是列表位置序号 —— 位置会变，编号不会。
五、第三级：周期扣费双重确认
自动续费改的不是当下一条记录，而是未来每个周期的扣款安排。一次 --confirm=true 只能证明 "知道现在要改续费状态"，证明不了 "知道以后会周期性扣钱"，所以这类操作要再加一层确认。
| 确认类型 | 对应参数 | 确认内容 |
|---|---|---|
| 本次变更确认 | --confirm=true | 确认本次提交的动作本身 |
| 未来扣费确认 | --ack-future-charge | 知悉后续周期会产生扣款 |
两点澄清
- 把 "这次提交" 和 "以后每月扣" 拆成两个参数，是把两种不同性质的同意分开：前者是操作确认，后者是费用预期确认；
- CLI 不直接扣费：购买、续费、赎回、转入都在官方订单页完成，最终价格、账号和支付由页面确认；命令行里改的是续费状态，不是在终端里刷走一笔钱。
做团队权限设计时可以沿用这个思路：能改解析的人，不一定应该拥有设置自动续费的权限。
六、配套：输出契约与凭证处理
三级确认管 "动作要不要发生"，输出契约管 "动作之后留下什么"。
稳定输出中屏蔽的四类信息
- AK/SK；
- 临时 Token；
- 转移码；
- 联系人原文。
这四类信息最容易在截图、工单、CI 日志里扩散：密钥会进构建日志，转移码会进聊天记录，联系人原文会进排查文档。
凭证管理方式
- 凭证走 OAuth：login 只保存临时凭证配置，插件不读取也不打印凭证；
- 多账号或多站点维护时，用 --name 给本地配置起专用名字；
- 不再使用时，logout 清理本地配置；
- MCP 接入同样走 OAuth，不需要在对话里粘贴 AccessKey。
失败路径可判断
- 命令失败返回非零退出码和结构化 JSON，包含 error.code、error.retryable、error.next_action 等字段；
- 脚本据此决定重试还是转人工，不需要去 grep 人类可读的报错；
- retryable 只表示 "适合重试"，不代表重试一定成功；写操作尤其是批量变更，自动重放之前仍应先看预览。
七、机制边界与注意事项
- 不防判断错误：域名该不该续、品牌要不要多注册后缀、备案材料是否合规，仍属于人和业务流程的责任；
- 备案与实人核验不在 CLI 替代范围：备案提交需要真实主体信息，实人核验要本人手机扫码完成，审核结果以主管部门为准；
- 参数以官方文档为准：确认参数按当前命令契约设计，具体参数名和用法应以 aliyun domain --help 和官方命令文档为准；插件升级后遇到行为差异，先查文档再改脚本，不要把旧参数直接套到新版本上。
八、团队落地顺序
- 只读跑通：先用 list、detail、dns list 拉一份资产与解析现状，确认输出能被现有巡检或工单系统消费；
- 最小权限拆分：生产和测试账号分开，按操作类型分配权限；
- 再开放写操作：把 "预览 — 人工核对 — 带确认参数提交" 写成脚本分支或审批节点，而不是靠口头约定；
- 按场景选择工具：偶尔改一条解析、查一个域名，控制台更直接；域名数量上来、操作重复、需要交给 Agent 或流水线时，分层确认的价值才开始体现。
九、小结
DomainCLI 的三级安全机制，本质是按操作影响面逐级加严确认成本：只读层放开效率，写操作层强制预览后提交，扣费层把动作同意和费用知悉分开，再配合输出契约防止凭证扩散。它不承诺零风险，只是把风险从 "手滑" 收敛到 "你明确确认过的动作"，让命令行和自动化流程在管理域名资产时既有效率，又有提交前的刹车。
【常见问题】
问题 1：DomainCLI 的三级安全机制分别对应哪些操作，确认方式有什么不同？
回答 1：DomainCLI 三级安全机制中，第一级是只读查询，无需确认；第二级是 DNS 修改、转移锁、转出等即时写操作，默认只出预览，需 --confirm=true 才提交；第三级是自动续费等未来扣费操作，除写确认外还需 --ack-future-charge 单独知悉后续扣款。
问题 2：命令行改域名时，不带确认参数直接执行写命令会怎样？
回答 2：按照 DomainCLI 的设计，第二级写操作在缺少 --confirm=true 时只会输出变更预览，不会真正落库；未确认的变更不会提交，Agent 和流水线也无法绕过人工确认直接写入，这样可以把手滑误操作挡在提交前。
问题 3：DomainCLI 里设置自动续费，为什么需要两个确认参数？
回答 3：--confirm=true 确认的是本次变更动作，--ack-future-charge 确认的是知悉后续周期性扣费，两者性质不同所以分开设置；另外 CLI 不直接扣费，续费购买等资金动作最终仍在官方订单页确认。
问题 4：DomainCLI 的三级安全机制能不能替代人工做业务判断？
回答 4：不能。三级机制主要防范误操作和凭证扩散，域名是否续费、后缀选择、备案合规等业务判断仍由人和流程负责；备案提交与实人核验需要真实主体信息和本人扫码，不在 DomainCLI 可替代的范围内。
【参考资料】
- [2026-11-13]（DomainCLI 的三级安全机制：命令行改域名，怎样把 "手滑" 挡在提交前）阿里云开发者社区
- [2026-11-10]（管 300 个域名的人，最怕的不是报警）阿里云开发者社区
- [2026-11-05]（安全策略_用户指南（码道 CLI））华为云
- [2026-09-21]（域名管理 - 域名 (Domain)）阿里云帮助中心
- [2026-01-30]（开启或关闭禁止更新锁防止域名信息被篡改）阿里云帮助中心
- [官方指南]（aliyun domain 使用指南）阿里云万网
【免责声明】
本文内容基于公开官方文档与开发者社区资料整理，仅用于命令行工具安全机制交流与参考，不构成域名管理操作、权限配置或自动化脚本设计的直接建议。文中命令、参数名称、确认流程和能力边界以阿里云 DomainCLI 官方文档及 --help 实时输出为准；不同版本插件行为可能存在差异，生产环境操作前请先在测试账号验证，并遵守账号最小权限与域名注册、备案相关合规要求。引用的外部资料版权归原出处所有，如表述存在偏差，以官方原始说明为准。