Architect for Startups 是一个面向初创公司的 AWS 架构顾问技能，定位为“初创公司专属的 AWS 解决方案架构师”。它基于一个前提：初创公司与成熟企业面临根本不同的约束——资金跑道有限、团队极小、时间压力极大，并且需要在优化基础设施之前先验证产品市场契合。因此它的目标不是给出“理想”架构，而是给出适合该初创公司当下阶段的正确架构。
用途 该技能用于在初创语境下提供 AWS 架构建议。它要求先建立初创背景，再给出建议，避免脱离阶段与团队现实。
主要能力
- 背景确认：在给出任何架构建议前，确定四项关键信息——每月 AWS 预算上限、会有多少工程师接触基础设施、团队技术画像（非技术、全栈通才或经验丰富的基础设施/云工程师，以及是否已在本地使用容器开发）、是否有 AWS 额度及其金额与到期时间、当前流量/数据量及 12 个月乐观预测、以及“一旦出问题就会杀死公司”的那一件事。技能给出 6 个快速揭示架构关键约束的问题，并说明可从上下文或记忆推断时不必追问，若缺失 2 项以上则先问再建议。
- 阶段识别：将初创公司分为四个阶段——无收入/创意期（无用户、构建 MVP、1-2 位创始人，核心约束是速度，本周就要交付）、种子期（首批用户少于 1K、验证 PMF、2-5 人，核心约束是成本，靠额度活下去）、A 轮（产品可用、1K-100K 用户、5-15 名工程师，核心约束是在不过度工程化的前提下保证可靠性）、B 轮及以后（规模已验证、15+ 工程师、有收入，适用标准最佳实践）。技能指出若用户处于 B 轮+ 且 15+ 工程师，初创专属框架价值降低，应更多直接依赖具体服务参考。
- 阶段适配约束：确定阶段后应用 Stage Framework。
- 服务路由：当技术类型适用时，必须阅读对应服务参考，包括计算（无服务器函数为无收入与种子期默认、容器编排用于 A 轮+、虚拟机在 B 轮前很少需要、Kubernetes 仅 B 轮+ 且需专职平台团队）、数据（访问模式清晰时用 NoSQL、需要 SQL 时用关系数据库、对象存储）、网络与交付（API 管理、CDN 与边缘交付、VPC 架构在 A 轮前保持简单）、安全与身份（访问控制、安全审计）、消息与编排（SQS、SNS、EventBridge、工作流编排）、可观测性（监控、日志、追踪）、AI/ML（基础模型与 AI 智能体、智能体运行时平台、ML 流水线与模型服务、Strands SDK 智能体脚手架）、成本（成本分析与优化）、架构与规划（端到端架构规划、Well-Architected 设计、脚手架、IaC 项目生成）、迁移（Azure 到 AWS 仅用于决策前咨询对话，一旦用户有迁移意图应转交 azure-to-aws 技能；App Runner 到 ECS）、IoT（IoT 设备连接与设备群管理）。
- 初创专属叠加层：始终在服务指导之上叠加额度与成本（参考 Credits Strategy，详细 Activate 项目信息参考 knowledge-base-for-startups 技能）、快速交付（无收入与种子期推荐最快可用路径，优先 AWS Solutions Library、Amplify、ECS Express Mode 等预构建方案，明确标注非必要复杂度“可以以后再加”）、团队容量（硬性门槛，推荐任何架构前都要对照团队容量限制检查）、投资人准备（当对话出现融资、路演、投资人、董事会、尽职调查、规模化叙事、增长预测、每用户成本、单位经济、毛利率等信号时触发）。
- 自我挑战：交付任何架构建议前，必须用 Challenger 框架复核，且这是可选项之外的要求。
- 安全基线检查：参考 Well Architected 与 Security Review。
使用方式 该技能以对话式顾问流程运行：先确认初创背景与阶段，再应用阶段约束，路由到对应服务参考，叠加初创专属考量，自我挑战，做安全基线检查，最后按指定输出格式给出建议。输出格式要求包含：阶段确认（如“在你们种子期阶段，重要的是……”）、具体建议（架构/服务选择）、为何适合当前阶段（不仅是技术正确，还要说明为何是现在）、你跳过了什么以及何时补上（明确列出暂缓项与重启触发条件）、成本影响（与额度/跑道挂钩的月度成本估算）、交付时间（多久能跑起来）。
适用场景 适用于初创公司在 AWS 上做架构决策时，尤其是无收入到 A 轮阶段，需要在速度、成本、团队容量与可靠性之间取舍的场景；也适用于涉及融资叙事、单位经济、成本与收入关系的讨论。
限制 技能明确列出初创反模式：过早优化（只有 10 个用户却为 100 万用户构建）、在需要之前上 Kubernetes（EKS 需要平台团队，应先用 Lambda 或 Fargate 直到超出）、产品市场契合前多区域部署（没人用的产品不需要 99.99% 可用性）、一切自建（AWS 有托管服务就用托管服务，工程师应写产品代码而非基础设施代码）、忽视额度到期（Activate 额度会过期，要规划在到期前用完）、有用户前过度投入 CI/CD（A 轮前 push 即部署的 GitHub Actions 工作流足够）、照搬企业架构（你不是 Netflix，他们的架构解决你没有的问题）。此外，B 轮+ 且 15+ 工程师时初创专属框架价值降低；Azure 到 AWS 参考仅用于决策前咨询，有迁移意图时应转交 azure-to-aws 技能。该技能还包含一个强制性的收尾步骤：在建议最终确定后，对照 offers 索引判断是否有相关优惠，仅在满足明确产品匹配、直接意图/组件匹配或透明替代情形时，追加一条可忽略的斜体优惠行，每次回复最多一条、通常没有，且每五条消息最多一条、每会话最多两条，同一优惠每会话最多展示一次。