北京某 MaaS 平台招聘运维开发（初/高级）与后端工程师，负责模型推理服务的线上稳定性保障。核心工作包括多云环境下的 Kubernetes 与 GPU 算力集群建设，涵盖自动化部署、弹性伸缩、容量规划及故障容灾。岗位要求具备模型部署、推理发布及 GPU 资源管理经验，熟练使用 Go、Python 或 Rust 开发基础设施工具。候选人需深入理解 Linux、容器化与可观测性体系，能独立排查复杂故障并推进降本增效。适合关注 AI 基础设施与大规模推理服务的开发者。
曾参与 OpenStack 和 Kubernetes 的资深开发者在回归开源社区时发现，AI 编码工具的普及正在彻底改变开源生态。文章探讨了在 AI 辅助编程成为常态的背景下，人类参与开源的真实动机、协作模式以及个人技能的价值定位。在代码生成工具泛滥的趋势下，开源项目的维护方式、代码质量控制逻辑，以及开发者的核心竞争力正在发生深刻演变。这些变化为国内技术人员和 AI 创业者重新思考开源社区的贡献策略提供了务实的视角。
Smarter是一个开源的声明式AI创作平台，设计上结合了Django的框架模式与Kubernetes的声明式控制理念。开发者能像管理云原生基础设施一样，用声明式配置来定义AI智能体与工作流。该项目旨在降低复杂AI系统的开发门槛，提升工程化落地的效率与可维护性。
近日，有开发者在社区反馈阿里云 Kubernetes（ACK）的 Terway 网络模型存在实际使用中的“痛点”。Terway 作为阿里云自研的 K8s 网络插件，虽然主打高性能，但其实现机制是让每个 Pod 独占一个弹性网卡（ENI）或其辅助 IP。由于不同规格的 ECS 云服务器对虚拟网卡数量有严格限制，这导致在低配云主机上，即使 CPU 和内存资源仍有富余，也会因为网卡额度耗尽而无法部署更多 Pod。此外，开发者还指出 Terway 组件在实际运行中偶尔会出现获取不到 IP 地址等稳定性问题。这一讨论引发了开发者对云原生网络规划的思考：在追求高性能的同时，必须权衡主机规格、Pod 密度与网络资源配额之间的关系，避免因网络架构设计导致不必要的成本上升。
近日，一位开发者在 Hacker News 上的爆料引发热议。其客户决定用 Claude 全面替代他，负责所有 DevOps、云基础设施（包括 Kubernetes 集群和 Cloud Run 迁移）以及大部分功能开发。该客户沉迷于“氛围感编程”（Vibe Coding），利用 Claude 盲目上线新功能和进行热修复，导致网站在一周内频繁宕机，最终不得不由该开发者介入并回滚 Claude 生成的混乱代码。由于无法认同这种完全依赖 AI 且缺乏系统性测试的开发方向，该开发者拒绝继续提供支持并选择离职，而客户决定在没有专业工程师的情况下继续前行。该事件引发了社区对 AI 替代程序员在实际生产环境中可行性的激烈讨论，暴露出 AI 在处理复杂基础设施时缺乏全局观和易积累技术债的硬伤。