「Nginx 配置审查」Skill 常见坑：8 个问题与改法
运维与平台工程师经常要做「Nginx 配置审查」这类事：检查 Nginx 配置的安全头、缓存与反向代理设置。每次都从头写提示词，结果时好时坏；把它做成智能体 Skill，就能让智能体每次按同一套步骤执行，输出结构也更稳定。
下面是把「Nginx 配置审查」做成技能时最常见的 8 个问题，每条都给出改法。
1. 描述写成口号
智能体判断不出何时该用。改为“检查 Nginx 配置的安全头、缓存与反向代理设置；当用户提到Nginx 配置审查时使用”。
2. 步骤太粗
只写“做好Nginx 配置审查”。改为编号的具体动作：检查 TLS 与安全头；检查缓存规则；检查代理超时；给出修改片段并提醒先测试。
3. 没有输出格式
每次交付的问题与建议结构不同。在技能中给出固定标题或表头。
4. 没写缺信息怎么办
智能体自行补全，产生编造内容。明确要求先列出缺失项并提问。
5. 忽略领域规矩
例如没写「变更类命令先在测试环境演练，并准备好回滚」。把这类底线写进约束段落。
6. 权限过大
把纯指令技能和带执行权限的工具混在一起。纯提示词能完成的就不要挂工具。
7. 长资料塞进正文
每次加载都很重，关键规则被淹没。把规范、模板拆到参考文件按需读取。
8. 改完不测
一次改多处又不回归测试。保留测试用例，每次修改后重跑。
一个自查办法
把技能交给一位没参与编写的同事，让他只看 SKILL.md（或规则文件）回答三个问题：什么时候用？输入什么？交付什么？答不上来的地方，就是需要补写的地方。
风险提示：属于中等风险：结果会影响业务判断，建议在输出前设置人工审核点。
交付物结构示例
建议把问题与建议固定成下面的结构（示意），方便复核与归档：
## 结论
一句话说明最重要的发现或结果
## 主要内容
- 检查 TLS 与安全头：……
- 检查缓存规则：……
- 检查代理超时：……
- 给出修改片段并提醒先测试：……
## 依据
- 引用输入中的具体位置或数据
## 需人工确认
- ……（没有则写“无”）
结构固定之后，复核的人只要先看“结论”和“需人工确认”两部分，就能快速判断结果能否使用。
平台选择建议
同一个「Nginx 配置审查」技能可以落在不同平台上，选择时主要看你在哪里工作、要不要执行代码、要不要接外部系统：
- Gemini CLI：Gemini CLI 会读取项目中的 GEMINI.md 作为长期上下文。详见Gemini CLI 版
- Function Calling：Function Calling（工具调用）是主流大模型 API 的通用能力：你用 JSON Schema 描述函数。详见Function Calling 版
- 扣子（Coze）智能体与工作流：扣子（Coze）是字节跳动推出的智能体开发平台。详见扣子（Coze）智能体与工作流 版
这个技能纯指令型，不需要额外脚本或外部连接，复制到大多数平台都能用，可据此排除不支持相应能力的平台。
智能体与人的分工
技能不是把工作全部交出去，而是把重复、机械的部分交给智能体，人把住判断和责任：
| 步骤 | 智能体负责 | 人负责 |
|---|---|---|
| 检查 TLS 与安全头 | 按指令完成并给出依据 | 抽查关键处，确认无误 |
| 检查缓存规则 | 按指令完成并给出依据 | 抽查关键处，确认无误 |
| 检查代理超时 | 按指令完成并给出依据 | 抽查关键处，确认无误 |
| 给出修改片段并提醒先测试 | 按指令完成并给出依据 | 抽查关键处，确认无误 |
| 最终交付 | 整理问题与建议 | 决定是否采用、是否对外 |
属于中等风险：结果会影响业务判断，建议在输出前设置人工审核点。
延伸阅读
- Nginx 配置审查 · Dify 工作流 版
- Nginx 配置审查 · SKILL.md 写法
- Nginx 配置审查 · 组合用法
- 磁盘清理建议 · 常见坑
- 架构图生成 · 常见坑
- 智能体Skills 分类：625 个技能 × 32 个角度
说明：文中的配置、代码与目录结构均为示意，用于说明思路；各平台的入口、字段名与能力会更新，落地前请以对应官方文档为准。示例中的数据与场景为虚构，不代表真实案例。