cost-optimization

cost-optimization 技能概览

cost-optimization 技能能做什么

cost-optimization 技能为 AI agent 提供了一套实用框架，用来在 AWS、Azure、GCP 和 OCI 上降低云成本，但不是把“省钱”等同于盲目“删资源”。它关注的是团队在真实工作中会遇到的决策：提升成本可见性、做资源 rightsizing、选择更合适的定价模型，以及收紧那些会持续制造不必要开销的架构模式。

哪些人适合安装这个 cost-optimization 技能

这个 cost-optimization 技能特别适合平台工程师、云架构师、重视 FinOps 的团队、SRE，以及需要结构化成本评审方法的工程管理者。尤其当你希望 agent 把“降低我们的 AWS 账单”这种宽泛目标，转化为更系统、更可执行的优化方案时，它会很有价值。

它真正解决的工作问题是什么

大多数用户并不需要一份泛泛而谈的云成本检查清单。他们真正需要的是：帮助识别浪费最可能出现在哪里、有哪些优化杠杆可用、哪些权衡最关键，以及怎样更安全地安排变更顺序。这个 cost-optimization 技能最强的地方，在于它能提供一套可重复使用的评审视角，适用于性能优化、预算控制或多云治理场景。

为什么它比普通提示词更有用

普通 prompt 也许能生成一些笼统的省钱建议。cost-optimization 技能更好，是因为它给 agent 提供了明确的优化框架：

• 先做可见性
• 再做 rightsizing
• 然后选择定价模型
• 最后处理架构层面的成本优化

这个顺序很重要，因为很多团队在还没法归因、衡量或比较方案之前，就急着开始“优化成本”。

仓库里实际包含什么

从仓库内容来看，这个技能体量不大，但很实用：

• SKILL.md：核心优化框架
• references/tagging-standards.md：可直接落地的标签标准

这说明它不是那种重自动化的工具包，而是一个偏决策支持和分析型的技能。它最实际的价值，体现在规划、审计和引导式建议上。

最适合与不太适合的使用场景

最适合：

• 云账单评审
• rightsizing 讨论
• reserved capacity 或 savings plan 规划
• 标签和 chargeback 清理
• 面向 Performance Optimization 的 cost-optimization，在成本与效率之间做平衡

不太适合：

• 基于云厂商原始导出数据做精确账单计算
• 自动化修复
• 深度的厂商专属实施 runbook
• 无法提供任何资产清单、使用情况或标签上下文的团队

如何使用 cost-optimization 技能

安装 cost-optimization 技能

可通过以下命令从仓库安装：

npx skills add https://github.com/wshobson/agents --skill cost-optimization

如果你的环境使用其他 skill loader，也可以从这里添加该技能：

https://github.com/wshobson/agents/tree/main/plugins/cloud-infrastructure/skills/cost-optimization

先读这两个文件

如果你是为了快速判断是否值得安装，建议按这个顺序阅读：

1. plugins/cloud-infrastructure/skills/cost-optimization/SKILL.md
2. plugins/cloud-infrastructure/skills/cost-optimization/references/tagging-standards.md

SKILL.md 负责给出优化模型；而标签参考文件同样关键，因为标签做不好，往往会直接卡住后续有效的成本分析。

这个 cost-optimization 技能需要哪些输入才更好用

当你提供更具体的运行上下文时，cost-optimization 技能会明显更有用，例如：

• 云厂商以及 account / subscription / project 结构
• 各服务的月度支出
• 计算、存储和数据库的利用率信号
• 已有的 reservations、Savings Plans 或其他 commitments
• 标签覆盖率与标签标准
• 性能或可靠性约束
• 目标是快速节省成本、长期治理，还是两者都要

如果没有这些上下文，输出基本只能停留在高层建议。

使用 cost-optimization 技能时，什么样的 prompt 更合适

不要只问：

Help me reduce cloud costs.

应该给出足够结构化的信息，让技能真正进行推理：

Use the cost-optimization skill. Review our AWS spend for a SaaS platform. Prioritize actions by savings potential, risk, and implementation effort. Constraints: production latency cannot degrade, RDS is business-critical, and we already use some Savings Plans. Focus on EC2, EBS, RDS, S3, and data transfer. Also assess whether our tagging is sufficient for chargeback.

这样效果更好，因为它明确了：

• provider
• 工作负载
• 约束条件
• 范围内的服务
• 优化优先级
• 治理预期

把模糊目标改写成完整请求

一个好用的模式是：

1. 先说明业务目标
   例如：90 天内将成本降低 15%。

2. 说明环境范围
   例如：AWS 的 production 和 staging accounts。

3. 定义约束
   例如：不能停机、不能出现性能回退、不能做跨多个季度的大迁移。

4. 提供证据
   例如：成本最高的服务、闲置资源问题、标签缺失或实例利用率偏低。

5. 要求输出带优先级
   例如：quick wins、中等投入的改动、以及战略级改动。

首次使用 cost-optimization 技能的实用流程

一个很稳妥的首轮 workflow 是：

1. 先让技能评估可见性和标签成熟度。
2. 再让它按 provider 和 service 识别可能的浪费类别。
3. 再要求它区分“做了基本不会后悔”的动作和高风险动作。
4. 再让它把建议映射到实施成本、节省潜力和运维风险。
5. 最后再去问更具体的 provider 实施建议。

这个顺序能避免在基础卫生还没搞清楚时，就过早跳到 reserved instance 或删除资源这种建议上。

按框架原本的顺序使用

这份 cost-optimization 指南的核心价值，其实就是底层这套框架：

• Visibility
• Right-Sizing
• Pricing Models
• Architecture Optimization

很多用户会直接跳到价格折扣和采购承诺上。但在实际工作中，更好的可见性和 rightsizing 往往更能先提升决策质量。比如，如果闲置容量问题还没解决，就先买 commitments，很可能只是把坏模式锁死。

什么时候标签参考文件最重要

在以下情况里，references/tagging-standards.md 尤其重要：

• 你没法清楚做成本归因
• 团队对资源归属存在争议
• chargeback / showback 机制很弱
• agent 需要给出治理层面的改进建议，而不只是 infra 调整

仓库里特别点出的有用标签包括：

• Environment
• Owner
• CostCenter
• Project
• ManagedBy

如果你的云环境里缺少这些标签，那就应该先把这个技能用于提升可见性，而不是指望它直接给出高精度节省数字。

多云评审的示例 prompt

Use the cost-optimization skill to compare AWS and Azure spend controls for a company running dev, staging, and production across both clouds. Identify common waste patterns, provider-specific pricing levers, tagging gaps, and governance controls. Rank recommendations by expected savings, implementation complexity, and operational risk.

这个用法很合适，因为该技能本身就明确覆盖 AWS、Azure、GCP 和 OCI。

面向性能敏感系统的示例 prompt

如果你是在 Performance Optimization 场景里做 cost-optimization，一定要把限制说清楚：

Use the cost-optimization skill to review our production compute and database spend. Do not recommend changes that would reduce p95 latency or resiliency. Focus on rightsizing, storage class choices, autoscaling policies, reservations, and non-critical environment cleanup. Show which actions are safe for performance-sensitive workloads and which need benchmarking first.

这样可以避免 agent 提出那种“账面上更便宜、但运维上有害”的降本建议。

好的输出应该长什么样

一个有用的 cost-optimization 技能输出，通常应该包含：

• 当前最可能存在浪费的区域
• 阻碍更好建议的缺失数据
• 带优先级的行动建议
• 按服务类型拆分的节省杠杆
• 标签、预算等治理修复项
• 风险与前提假设

如果回答只是一串泛泛的云成本节省技巧，那通常说明你需要提供更多环境细节。

cost-optimization 技能 FAQ

这个 cost-optimization 技能对新手友好吗

友好，前提是你对自己的云环境至少有基础了解。它的框架不难理解，但输出质量高度依赖你能否提供支出、归属和利用率相关上下文。即便是新手，也可以把它用于引导式评审，顺便建立对主要优化杠杆的认识。

它真的比普通 prompt 更好吗

大多数情况下，是的，尤其适合做结构化分析。这个技能给 agent 提供了比空白 prompt 更清晰的思考模型，尤其是在顺序安排上：先可见性，再治理；先治理，再定价决策；最后才是更深层的架构调整。

它会自动执行云资源改动吗

不会。根据仓库内容，这本质上是一个指导型技能，不是自动化工具。它擅长帮助 agent 思考优化策略和给出建议；真正落地实施，仍然需要依赖云厂商工具和团队评审。

它适用于哪些云厂商

这个技能明确覆盖：

• AWS
• Azure
• GCP
• OCI

因此它既适合单云，也适合多云场景。不过如果你需要非常深入的厂商专属实施细节，通常还是要继续补充后续 prompt。

什么情况下不该用 cost-optimization

如果你的需求是下面这些，就不建议用这个技能：

• 精确的账单对账
• 详细的 billing export 解析
• policy-as-code 执行
• 直接可运行的 remediation scripts
• 只要厂商实施细节、不需要任何策略分析

这些情况下，更适合直接使用云厂商原生账单工具，或者更偏运维执行的专用技能。

我能把它用于持续治理，而不只是一次性省钱吗

可以。标签标准参考文件让这个技能不仅适合做一次性降本，也适合建立可重复执行的成本控制机制，特别是在资源归属、chargeback 和报表纪律这些方面。如果你想把成本评审纳入日常平台运营，它是很匹配的。

如何改进 cost-optimization 技能的使用效果

给 cost-optimization 技能提供真实的支出和使用证据

想让 cost-optimization 技能更快产生高质量结果，最有效的方法就是提供真实信号：

• 成本最高的前 10 个驱动项
• 利用率不足的资源
• 存储增长情况
• 闲置环境
• 当前 commitments 覆盖率
• 标签缺口

你提供的证据有多具体，这个技能的输出就能有多具体。

把 quick wins 和结构性修复拆开

可以要求 agent 把建议拆成：

• 立即清理
• 定价 / commitment 调整
• 架构改进
• 治理改进

这点很重要，因为这些类别对应的风险和时间跨度完全不同。混在一起讲，通常只会导致优先级判断变弱。

明确说明哪些东西不能动

常见失败模式是：第一轮输出就建议了会伤害可靠性或性能的动作。避免这种情况的方法，就是直接写清硬约束：

• 不允许延迟回退
• 不允许降低 HA posture
• freeze window 期间不允许变更
• 对不稳定工作负载不做长期 commitments

在 Performance Optimization 场景下使用 cost-optimization 时，这一点尤其重要。

想要精确建议前，先把标签做好

如果你的云环境标签不一致或大量缺失，先让技能处理这个问题。参考文件已经说得很明确：归属和成本归因是基础。标签质量提升后，后续所有建议都会更可靠，从 dashboard 到清理目标识别都会更准。

不要只要“点子”，要带排序的建议

可以用这样的提示：

Rank actions by savings potential, confidence, effort, and operational risk.

相比单纯要求“说得更详细”，这类指令通常更能提升输出质量。因为它会逼着模型给出可用于决策的建议，而不是发散式头脑风暴。

要求它写出假设和缺失数据

一个很有价值的追问是：

List the assumptions behind each recommendation and what additional data would confirm or reject it.

这能帮助你区分：

• 大概率有效的建议
• 偏猜测性的建议
• 被可观测性不足卡住的事项

按服务域迭代，而不是一次覆盖整个环境

如果第一轮结果太泛，下一轮就把范围收窄到某个区域：

• EC2 / VM fleets
• databases
• object storage
• Kubernetes
• data transfer
• non-production environments

cost-optimization 技能在聚焦明确成本域时会更有价值，而不是试图一次优化所有东西。

让技能对比当前状态与目标运营模型

可以要求技能同时评估两件事：

• 现在应该立刻砍掉什么成本
• 未来应该建立什么治理流程

例如：
Use the cost-optimization skill to identify immediate savings and propose a quarterly cost review process with tagging enforcement, budget alerts, and ownership reporting.

这样一来，这个技能就不只是一次性的建议工具，而更像一个运营模型设计助手。

留意常见的低质量输出信号

如果回答出现以下情况，就应该继续收紧 prompt：

• 没有利用率历史却建议买 commitments
• 没有 owner 验证就建议删除资源
• 忽略标签和可见性缺口
• 把 dev 和 production 一视同仁
• 只盯着 compute，忽略存储或传输成本

这些都说明模型还需要更好的上下文，或者更小、更清晰的分析范围。

先用仓库框架，再叠加你的真实环境

最佳做法是先使用仓库里的框架和标签标准，再把你自己的环境信息补进去。这也是用好 cost-optimization 技能的关键：把内置结构当作分析视角，但 prompt 要具体到足以让建议真正落地。