元平台工程师助手

它解决什么问题

当你把 AI 助手拉进一个需要「高速迭代 + 超大流量」的工程场景时，常见的问题是：助手要么只盯着局部代码，要么给出一套在小团队里可行、但放到 3B+ 日活的量级就崩掉的方案。比如随手设计一个没有预留水平扩展的存储选型、忽略社交网络里关系数据的扇出成本，或者在还没有度量数据时就要求做架构重写。

元平台工程师岗位助手 的目标，是让助手先进入一个明确的工程师角色：既能 Move Fast 快速上线，又能按行星级规模思考，同时把数据驱动、持续部署、单仓协作这些约束内置到回答里。

它如何工作

技能先定义核心身份，再通过行为准则约束每次输出：

• Move Fast 实践者：倾向先交付最小可用版本，用生产环境的数据迭代，而不是追求完美计划
• 规模架构师：从第一天起按 10x 量级做设计，默认横向扩展，考虑全球分布的故障场景
• 开放协作者：默认单仓思维，鼓励跨团队贡献，避免重复造轮子
• FaaS 原生视角：优先无状态函数，把扩缩容和运维交给基础设施
• 数据驱动决策者：用 A/B 实验和指标验证判断，而不是凭感觉

在具体场景中，技能会按「架构 → 关键决策 → 指标 → 降级策略」的路径输出。例如设计信息流排序时，它会给出两阶段排序（先召回后精排）来控制模型推理成本，并明确主指标、护栏指标和 P99 延迟这类基础设施约束；设计 TAO 风格的社交图谱查询时，会限制 500 个好友的扇出上限并叠加缓存与特征开关。

适用边界与注意点

这套方法论不是无条件的「快」。技能内置了一张风险表，把 Move Fast → 不稳定、规模误判、单仓破坏、数据隐私泄露等风险按严重度分级，并给出对应缓解手段：

• 速度必须搭配安全机制：特征开关、灰度发布、快速回滚缺一不可
• 行星级规模意味着故障也是行星级的：熔断和优雅降级是必需品，不是可选项
• 单仓开放需要明确归属：每个改动都可能影响成千上万的工程师，责任边界要清楚
• 避免过早优化：先度量再优化，优先复用 ZippyDB、Tectonic 这类共享基础设施，而不是自造存储系统

适合：需要在大规模用户、高迭代节奏、强工程文化背景下讨论架构、工作流和风险控制的团队与个人。不适合：资源有限、迭代周期以周或月计、无法承担生产级事故恢复成本的小型项目直接套用。