「Dockerfile 优化」是运维与平台工程师的高频任务。它的输入通常是Dockerfile，期望得到的是优化后的 Dockerfile 与对比。这类有固定流程、又需要一点判断力的工作，很适合封装成智能体 Skill。

下面是把「Dockerfile 优化」做成技能时最常见的 8 个问题，每条都给出改法。

1. 描述写成口号

智能体判断不出何时该用。改为“缩小镜像体积、利用缓存并减少安全隐患；当用户提到Dockerfile 优化时使用”。

2. 步骤太粗

只写“做好Dockerfile 优化”。改为编号的具体动作：分析层结构；合并与排序指令；采用多阶段构建；用非 root 用户运行。

3. 没有输出格式

每次交付的优化后的 Dockerfile 与对比结构不同。在技能中给出固定标题或表头。

4. 没写缺信息怎么办

智能体自行补全，产生编造内容。明确要求先列出缺失项并提问。

5. 忽略领域规矩

例如没写「变更类命令先在测试环境演练，并准备好回滚」。把这类底线写进约束段落。

6. 权限过大

为了省事给了写入、发送或执行命令的权限。按最小权限配置，涉及外部影响的动作设置确认。

7. 长资料塞进正文

每次加载都很重，关键规则被淹没。把规范、模板拆到参考文件按需读取。

8. 改完不测

一次改多处又不回归测试。保留测试用例，每次修改后重跑。

一个自查办法

把技能交给一位没参与编写的同事，让他只看 SKILL.md（或规则文件）回答三个问题：什么时候用？输入什么？交付什么？答不上来的地方，就是需要补写的地方。

风险提示：风险较低，但输出仍需快速过目再使用。

交付物结构示例

建议把优化后的 Dockerfile 与对比固定成下面的结构（示意），方便复核与归档：

## 结论
一句话说明最重要的发现或结果

## 主要内容
- 分析层结构：……
- 合并与排序指令：……
- 采用多阶段构建：……
- 用非 root 用户运行：……

## 依据
- 引用输入中的具体位置或数据

## 需人工确认
- ……（没有则写“无”）

结构固定之后，复核的人只要先看“结论”和“需人工确认”两部分，就能快速判断结果能否使用。

平台选择建议

同一个「Dockerfile 优化」技能可以落在不同平台上，选择时主要看你在哪里工作、要不要执行代码、要不要接外部系统：

  • Cursor Rules：Cursor 用项目规则（Project Rules）给智能体注入长期指令。详见Cursor Rules 版
  • Windsurf Rules：Windsurf 的规则用于约束 Cascade 智能体的行为。详见Windsurf Rules 版
  • Dify 工作流：Dify 是开源的大模型应用开发平台。详见Dify 工作流 版

这个技能需要运行本地脚本（解析文件、调用命令行工具等），要求运行环境允许执行代码，可据此排除不支持相应能力的平台。

智能体与人的分工

技能不是把工作全部交出去，而是把重复、机械的部分交给智能体，人把住判断和责任：

步骤智能体负责人负责
分析层结构按指令完成并给出依据抽查关键处，确认无误
合并与排序指令按指令完成并给出依据抽查关键处，确认无误
采用多阶段构建按指令完成并给出依据抽查关键处，确认无误
用非 root 用户运行按指令完成并给出依据抽查关键处，确认无误
最终交付整理优化后的 Dockerfile 与对比决定是否采用、是否对外

风险较低，但输出仍需快速过目再使用。

延伸阅读

说明：文中的配置、代码与目录结构均为示意，用于说明思路；各平台的入口、字段名与能力会更新，落地前请以对应官方文档为准。示例中的数据与场景为虚构，不代表真实案例。