Docker Gordon：在容器工作流中引入可审批的 AI 助手
Gordon 是嵌入 Docker Desktop、CLI、文档和 Docker Hub 的 AI 助手；安全落地的关键是限定目录与权限，并逐项审批会改变环境的动作。
Docker Gordon developer-tools ai-agent containers Gordon 是嵌入 Docker Desktop、CLI、文档和 Docker Hub 的 AI 助手；安全落地的关键是限定目录与权限，并逐项审批会改变环境的动作。
1. 产品定位
Docker 官方文档把 Gordon 描述为可分析环境、提出解决办法并在用户许可后执行命令的 AI 助手。[S1] 它围绕 Docker 工作流提供自然语言交互，应被视为带环境上下文的操作助手，而不是无需复核的自动运维人员。
2. 使用入口
官方文档列出 Docker Desktop 侧栏、docker ai 命令行、Docker Hub 和 Docker 文档站等入口。[S1] 不同入口接触的数据不同：文档问答不等于读取本机环境，Desktop 与 CLI 则可能看到项目文件、容器、镜像和日志。上线说明应明确每个入口能访问什么，以及哪些功能会计入方案用量。
3. 首批场景
建议从低风险、容易验证的任务开始：解释 Docker 概念、阅读失败日志、审查 Dockerfile、列出镜像或提出构建改进。生成文件时先输出差异，资源管理时先列出对象。不要在首轮试点直接清理卷、删除镜像、停止生产容器或修改共享配置，因为自然语言中的“没用”可能与团队的保留规则不同。
4. 目录与上下文
CLI 会以当前工作目录作为文件操作上下文，也可显式指定其他目录。[S2] 团队应从最小项目目录启动，排除密钥、个人配置、生产导出和无关仓库。提示中写清目标文件与允许修改的范围；若助手请求扩大目录或读取主目录，应中止并重新评估，而不是为方便一次性开放全部访问。
5. 命令审批
官方机制会在执行动作前提出方案并要求用户批准，权限可按单次动作或当前会话处理。[S1] 审批人仍需理解命令会改哪些容器、网络、卷和文件。高风险命令应先在测试环境运行，输出明确对象列表，并禁止通配删除。会话结束后确认临时授权已重置，同时保存必要的变更记录。
6. 调试工作流
一个稳妥流程是先让 Gordon 只读分析日志和配置，再要求给出假设、验证命令与回退办法。执行后比较预期和实际输出，若不一致立即停止连续动作。对构建失败，要区分代码、依赖、网络、缓存和平台架构问题；对运行故障，则先记录容器状态再修改，避免修复过程破坏原始证据。
7. 数据与隐私
日志、环境变量和镜像元数据可能包含令牌、内部域名或客户信息。试点前应确认组织方案的数据处理、留存与管理员控制，使用脱敏样例验证能力。不要把完整生产日志直接粘贴进对话；可以先截取必要行并移除秘密。若回答引用网页，也要防止外部内容诱导执行与当前目标无关的命令。
8. 组织治理
企业管理员应按团队启用，区分个人开发机、共享构建机和生产主机。为可执行动作设置禁止清单，为文件生成设置代码评审要求，并给事故处理保留人工负责人。成员需要知道如何关闭 Gordon、如何报告错误建议，以及发生误操作后从何处恢复文件或重建容器资源。
9. 验收标准
选择五到十个可复现任务，比较人工流程与助手流程的时间、正确率和返工。验收包括：只访问指定目录；所有动作先展示后执行；拒绝后不继续；生成 Dockerfile 能通过构建与安全扫描；故障建议不破坏数据卷；日志中不出现未脱敏秘密。任何一项越权都应阻止扩大使用范围。
10. 来源与更新时间
本文依据 Docker 的 Gordon 主文档和 CLI 文档，核对产品身份、入口、环境分析与审批机制。[S1][S2] Docker Desktop 版本要求、计划用量和企业设置可能变化，启用前应以当前文档和组织控制台为准。