deployment-advisor

部署顾问

概述

最昂贵的基础设施错误，不是选错了服务，而是选择了一个你并不需要的服务。每个外部依赖都是一笔账单、一个故障点，以及一份你现在必须阅读的文档。第二昂贵的错误，是忽略用户的机器上已经在运行的东西。

核心原则： 推荐满足项目实际需求的最简单技术栈；在建议引入新东西之前，先使用用户已有的资源。

没有例外。没有变通办法。没有捷径。

首要原则

NO TECHNOLOGY RECOMMENDATION WITHOUT CHECKING WHAT THE USER ALREADY HAS

如果你还没有盘点用户现有的工具、运行时、服务和运行中的进程，那你就是在猜，而不是在提供建议。猜测会浪费金钱和时间。

适用场景

必须使用：

• 新项目搭建（“我该用什么数据库？”“我该把它托管在哪里？”）
• 涉及外部服务的架构决策
• 扩展讨论（“这个项目需要处理更多流量”）
• 成本优化（“我的 AWS 账单太高了”）
• 迁移规划（“我应该从 X 换到 Y 吗？”）
• 任何有关数据库、托管、身份验证、存储或后台任务的问题

跳过：

• 用户已经选定技术栈，正在寻求实现方面的帮助
• 现有部署中的错误修复
• 已部署服务的小幅配置更改
• 用户明确表示“我想用 X，帮我配置好”（尊重他们的决定）

认知陷阱

合理化说法	实际情况
“现在大家都在用 Supabase”	合适的工具取决于项目，而不是潮流。SQLite 能处理的数据量比很多人想象的更多。
“云服务总是更好”	对许多工作负载来说，每月 4 美元的 VPS 胜过每月 50 美元的无服务器服务。流量稳定时，固定成本更划算。
“服务越多 = 越专业”	每项服务都是一项依赖、一笔账单和一个故障点。组成部分越少，出问题的环节也越少。
“他们需要微服务”	大多数项目都应该采用单体架构。微服务解决的是组织问题，而不是技术问题。
“必须使用 Docker”	许多项目无需容器化也能顺利部署。Docker 会增加小团队可能并不需要的复杂性。
“无服务器更便宜”	对流量突发且总量较低的场景，无服务器更便宜。负载稳定时，你付出的溢价只是为了闲置容量，而你已经租下了这些容量。
“托管服务能节省时间”	它们能节省运维时间，但会增加供应商锁定、成本和 API 接口面。要全面权衡利弊。

决策框架

在提出任何建议之前，请按顺序完成以下四个步骤。

步骤 1：评估项目需求

确定项目实际需要什么，而不是它将来可能需要什么。

Classify each requirement as:
- REQUIRED NOW: The project cannot launch without it
- REQUIRED SOON: Needed within the first month post-launch
- NICE TO HAVE: Would be useful but the project works without it
- SPECULATIVE: "We might need this eventually"

Only recommend infrastructure for REQUIRED NOW and REQUIRED SOON.
Everything else is premature optimization.

需要评估的常见项目需求：

需求	需要提出的问题
数据库	数据量有多大？有多少并发用户？读操作多还是写操作多？关系型还是文档型？
身份验证	有多少用户？需要社交登录吗？需要基于角色的访问控制吗？需要企业级 SSO 吗？
文件存储	文件有多大？有多少个文件？公开还是私有？需要 CDN 吗？
后台任务	频率如何？运行时间多长？需要重试逻辑吗？
实时功能	WebSocket？服务器发送事件？轮询是否足够？
电子邮件	仅事务性邮件？营销邮件？每月发送量是多少？
支付	一次性支付？订阅？需要分账的市场平台？
搜索	全文搜索？分面搜索？数据库能否胜任？

步骤 2：与系统清单交叉核对

调用 godmode:environment-awareness 获取用户的系统清单。

Check for:
- Databases already installed (PostgreSQL, MySQL, SQLite, Redis, MongoDB)
- Container tools (Docker, Podman, containerd)
- Cloud CLIs (aws, gcloud, az, vercel, fly, railway, netlify)
- Runtime environments (Node.js, Python, Go, Rust, Java)
- Package managers and lockfiles (reveals the ecosystem)
- Running services (check ports 3000, 5432, 6379, 27017, 8080)
- Existing project dependencies (check package.json, requirements.txt, go.mod)
- .env files or config that reference existing services

规则： 如果用户已经在运行 PostgreSQL，就不要推荐用 Supabase 来提供数据库服务。如果他们已经有 Vercel CLI 和 Next.js 项目，Vercel 显然是托管的首选。利用已有资源。

步骤 3：权衡并评估选项

针对每项基础设施需求，坦诚说明各种方案的利弊。

步骤 4：给出建议

请按照下方“给出建议”部分中的结构设置输出格式。

技术栈决策矩阵

数据库

选项	适用场景	成本	复杂度	注意事项
SQLite	单服务器、并发写入者少于 100 个、读取密集型	免费	极低	不支持并发写入、无复制、基于文件
PostgreSQL	多用户、关系型数据、复杂查询、需要 ACID	免费（可自托管）/ $0-15/月（托管）	中等	需要服务器进程，大规模部署时需要连接池
Supabase	需要实时功能、集成身份验证、无需运维的 PostgreSQL	免费套餐 / $25/月专业版	低（托管）	供应商锁定、行级安全的学习曲线
PlanetScale	大规模使用 MySQL、分支工作流、适合无服务器架构	免费套餐 / $29/月	低（托管）	MySQL 方言、免费套餐不支持外键
Redis	缓存、会话、发布/订阅、排行榜	免费（可自托管）/ $0-5/月	低	不是主数据库；未配置持久化时有数据丢失风险
MongoDB	文档型数据、灵活的架构、原型开发	免费套餐（Atlas）/ 价格不一	中等	仍需遵循架构规范，联接操作很麻烦

托管

选项	适用场景	成本	复杂度	注意事项
Vercel	Next.js、静态网站、JAMstack、无服务器函数	免费套餐 / $20/月专业版	极低	供应商锁定、无服务器限制、构建分钟数上限
VPS (Hetzner/DigitalOcean)	流量稳定、需要完全控制、Docker 工作负载	$4-20/月	中等（需自行管理）	需自行负责正常运行时间、安全补丁和备份
Railway / Render	快速部署、小团队、数据库与应用一并托管	免费套餐 / $5-20/月	低	成本增长很快，控制力不如 VPS
Fly.io	全球边缘部署、容器、全球低延迟	按用量付费 / 基础费用约 $5/月	中等	平台较新，部署问题更难排查
AWS / GCP / Azure	企业场景、复杂基础设施、拥有 DevOps 经验的团队	价格差异很大	高	账单可能令人震惊、复杂度激增、需要专门的运维知识
Cloudflare Pages/Workers	静态网站、边缘计算、已在使用 Cloudflare	慷慨的免费套餐	低到中等	Worker 限制（CPU 时间、内存）、非标准运行时

身份验证

选项	适用场景	成本	复杂度	注意事项
NextAuth / Auth.js	Next.js 项目、社交登录、需要自托管控制权	免费	中等	配置复杂、会话策略选择、迁移困难
Supabase Auth	已使用 Supabase 作为数据库	包含在 Supabase 中	低	与 Supabase 生态系统绑定
Clerk	需要精致的 UI 组件、快速集成	免费套餐 / $25/月	低	成本随 MAU 增长、供应商锁定
Auth0	企业级 SSO、合规要求、大型组织	免费套餐 / $23/月	中等	控制面板复杂、大规模使用时价格高昂
自行实现	需求非常简单（API 密钥、单个管理员）或具备深厚专业知识	免费	高（需自行负责安全）	你要为所有漏洞负责。除非你完全清楚自己在做什么，否则不要将其用于面向用户的身份验证。

文件存储

选项	适用场景	成本	复杂度	注意事项
本地文件系统	仅用于开发、单台服务器、小文件	免费	极低	重新部署后会丢失，没有 CDN，也没有副本
Cloudflare R2	兼容 S3、无出口费用、已在使用 Cloudflare	免费额度 / 按用量付费	低	服务较新，生态系统比 S3 小
AWS S3	行业标准、企业级、复杂的访问策略	按用量付费（出口费用会不断累积）	中等	出口费用是隐藏成本，要将其纳入预算。
Supabase Storage	已在使用 Supabase	包含在 Supabase 中	低	与 Supabase 绑定，免费额度有容量限制

后台任务

选项	适用场景	成本	复杂度	注意事项
简单 cron / setTimeout	定期任务、低负载、可以接受失败	免费	极低	没有重试逻辑、任务队列或持久化
BullMQ	Node.js 项目、需要重试和任务调度、可使用 Redis	免费（需要 Redis）	中等	需要 Redis，建议配置监控
Inngest	事件驱动、适合无服务器架构、需要步骤函数	免费额度 / 付费	低至中等	依赖供应商，平台较新
pg-boss	PostgreSQL 项目、不想使用 Redis、中等负载	免费（使用你的 PostgreSQL）	低至中等	会增加数据库负载，不适用于高吞吐量场景

决策流程图

digraph deployment_advisor {
    rankdir=TB;
    node [shape=box, style=filled];

    start [label="Infrastructure Decision\nNeeded", fillcolor=lightyellow, shape=doublecircle];
    inventory [label="Step 1: Assess Project Needs\nClassify as REQUIRED NOW\nREQUIRED SOON / NICE TO HAVE", fillcolor="#e3f2fd"];
    env_check [label="Step 2: System Inventory\nInvoke environment-awareness\nCheck installed tools + services", fillcolor="#e3f2fd"];
    already_have [label="Does the user already\nhave a suitable tool?", fillcolor="#fff3e0", shape=diamond];
    use_existing [label="Recommend existing tool\nExplain how it fits", fillcolor="#e8f5e9"];
    evaluate [label="Step 3: Evaluate Options\nCompare cost, complexity,\nfit for project size", fillcolor="#e3f2fd"];
    simple_check [label="Is the simplest option\nsufficient?", fillcolor="#fff3e0", shape=diamond];
    recommend_simple [label="Recommend simplest option\nNote when to upgrade", fillcolor="#e8f5e9"];
    recommend_scaled [label="Recommend scaled option\nExplain why simple\nis not enough", fillcolor="#e8f5e9"];
    present [label="Step 4: Present Recommendation\n+ Alternative\nwith honest trade-offs", fillcolor="#e8f5e9", shape=doublecircle];

    start -> inventory;
    inventory -> env_check;
    env_check -> already_have;
    already_have -> use_existing [label="yes"];
    already_have -> evaluate [label="no"];
    use_existing -> present;
    evaluate -> simple_check;
    simple_check -> recommend_simple [label="yes"];
    simple_check -> recommend_scaled [label="no"];
    recommend_simple -> present;
    recommend_scaled -> present;
}

MCP 集成评估

评估项目技术栈时，也要考虑 AI 集成是否能带来真正的价值。这不是为了加 AI 而加 AI，而是要找出 MCP 服务或 Claude 集成能够解决实际问题的场景。

考虑集成 MCP 的情况：

• 项目有一个用户或内部团队经常查询的 API（MCP 服务可以让 Claude 直接与之交互）
• 项目涉及内容管理、知识库或文档（Claude 可以帮助用户查找和整理信息）
• 项目有复杂的管理操作，适合使用自然语言界面
• 客户支持工作流可以受益于能够访问项目数据的 AI Agent

不要建议集成 MCP 的情况：

• 项目是没有复杂查询模式的简单 CRUD 应用
• 加入 AI 无法解决用户实际遇到的问题
• 用户没有表达对 AI 功能的兴趣
• 这只会是噱头，而非真正提升效率

如果适合集成 MCP：

MCP Integration Opportunity:
- Use case: [specific problem it solves]
- Implementation: MCP server exposing [which endpoints/data]
- Effort: [estimate]
- Value: [what the user or their users gain]

呈现建议

输出格式：

## Deployment Recommendation: [Project Name or Type]

### Project Requirements
- [Requirement 1]: REQUIRED NOW
- [Requirement 2]: REQUIRED SOON
- [Requirement 3]: NICE TO HAVE (defer)

### System Inventory
- Already installed: [tools, databases, CLIs detected]
- Running services: [ports, processes found]
- Project ecosystem: [framework, package manager, existing dependencies]

### Recommended Stack

| Layer | Choice | Reason |
|-------|--------|--------|
| Database | [choice] | [why — reference what user already has] |
| Hosting | [choice] | [why] |
| Auth | [choice] | [why] |
| [other] | [choice] | [why] |

Estimated monthly cost: $[X] (at current scale)

### Alternative Stack
[For when requirements change or scale increases]

| Layer | Choice | When to Switch |
|-------|--------|---------------|
| Database | [alt] | [trigger — e.g., "if concurrent users exceed 1000"] |
| Hosting | [alt] | [trigger] |

### What I Deliberately Did Not Recommend
- [Service X]: [why not — e.g., "overkill for this project size"]
- [Service Y]: [why not — e.g., "you do not have Docker installed and do not need it"]

建议的详略程度应与项目规模相称。周末项目只需简短建议，企业级 SaaS 则需要全面分析。

注意事项

切勿：

• 未确认用户是否已安装替代方案，就推荐某项服务
• 在免费替代方案足以满足需求时，建议使用付费服务
• 向没有 Docker 且不需要 Docker 的用户建议使用 Docker
• 对不需要企业云的项目默认推荐 AWS/GCP/Azure
• 在一项托管服务足以满足需求时，叠加多项托管服务（如果 Supabase 能涵盖这三项，就不要同时使用 Supabase + Auth0 + 独立托管服务）
• 因为某项技术流行就推荐它，而不考虑是否适合
• 忽视成本——始终提供月度估算
• 为适合采用单体架构的项目建议使用微服务

务必：

• 提出建议前先盘点环境并了解现状
• 至少提供一个推荐技术栈和一个备选方案
• 提供成本估算（即使只是粗略估算）
• 说明何时应从简单方案升级到备选方案
• 说明哪些方案是有意不推荐的，以及原因
• 倾向于减少服务数量、降低成本和复杂度
• 尊重用户已经选定的技术栈

关联

此技能会在基础设施决策节点与 GodMode 工作流集成：

• godmode:environment-awareness -- 提供此技能所依赖的系统清单。提出建议前务必先调用。
• godmode:rationale -- rationale 会从功能层面呈现备选方案；deployment-advisor 则会针对基础设施相关决策深入分析。
• godmode:system-design -- 协同处理架构决策。system-design 负责应用架构；deployment-advisor 负责基础设施和服务。
• godmode:project-bootstrap -- 项目设置期间会运行 deployment-advisor，以便在编写任何代码之前确定初始技术栈。
• godmode:security-protocol -- 身份验证和托管建议必须符合安全要求。