Agent Skills
返回列表
💻

CTO 架构拷问

开发编程 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3c6cb52e/cto-review。

技能介绍

很多架构决策在评审时看起来像“当前能跑”，但真正的风险要等到用户量、请求量或数据体积上台阶才会暴露。团队扩编、自研与采购、可靠性投入也常因为缺少统一口径而被情绪或短期成本牵着走。/cs:cto-review 把这类问题压缩成一次可执行的拷问，目标是在拍板前先找到下一个扩展悬崖。

解决什么问题

  • 架构变更、平台/语言/数据库切换前，缺少对 扩展上限 的明确判断
  • 团队翻倍时，没有把 ramp time 和贡献模型算进计划
  • Build-vs-Buy 只谈控制力或难度，缺少多年总拥有成本视角
  • 系统出现 SLO 未达标时，无法解释可靠性损耗来自哪里

如何工作

技能用六个 CTO 问题形成压力测试：

  1. Scaling Cliff：明确当前架构在用户/请求/数据量到多少倍时会坏，例如主库写入饱和；不知道就先做负载测试
  2. Tech Debt Inventory：找出最高优先级技术债，估算每周成本和何时变成 blocking
  3. Team Scaling：对每个 open req，定义 ramp time 与贡献模型
  4. Build vs Buy：追问为什么自研，并比较三年 TCO；如果答案是“要控制”或“不难”，继续反驳；如果真是核心护城河，再谈自研
  5. SLO / Reliability：定义系统 SLO，检查当前 error budget burn；没有 SLO 就无法推理可靠性取舍
  6. Security & Compliance Surface：确认变更暴露了什么，并让 cs-ciso-advisor 参与签核

工作流会先跑技术债分析器和团队扩展计算器，再显式写出扩展假设，随后用 cs-ciso-advisor 交叉检查安全影响，最后给出可执行结论。

适用边界

  • 数据面发生变化时，需要强制走 /cs:ciso-review
  • Build-vs-Buy 超过 $100K/year 时，建议再走 /cs:cfo-review
  • 季度计划用 /cs:execute；架构转向用 /cs:boardroom
  • 具体 SLO 设计可参考 ../../../../engineering/slo-architect/

使用场景

  • 评审重大架构变更前，需要定位当前架构在用户、请求或数据量增长下的扩展瓶颈。
  • 工程团队准备扩编前，需要逐条评估每个招聘岗位的 ramp time 与预期贡献。
  • 面对超过 $100K/年的自研或采购方案，需要用 3 年 TCO 和核心护城河做判断。
  • 系统持续错过 SLO 时，需要明确错误预算消耗并找到可靠性取舍依据。

适合人员

  • 需要在重大架构变更前做压力测试的技术负责人
  • 负责团队扩编与招聘优先级的工程管理者
  • 需要对高成本自研或采购方案做决策的技术决策者
  • 需要在 SLO 未达标时定位可靠性问题的 SRE 或后端负责人