eSimphony 是由一支 5 人工程团队打造的。这款产品覆盖 150 多个国家,提供原生 iOS 和 Android App,运行一个多区域的运营商集成栈,端到端支持五种语言,并且每周都在迭代产品。我们不是一家上千人的电信公司。我们是一支以有意为之的杠杆方式运转的小团队。

杠杆来自我们过去 18 个月内化下来的一套工程方法。我们称之为 AI 原生开发。下面是它在实际工作中真正长什么样。

团队的样子

五位工程师。一位产品设计师。一位仍会自己写产品文档的 CEO。没有专职的产品经理——文档由 CEO + Moza 辅助初稿 + 工程师判断共同产出。没有专职 QA 团队——测试是构建循环的一部分。没有独立的 DevOps——基础设施由交付该功能的人负责。

这不是炫耀,而是约束。在这个团队规模下,要交付一个 eSimphony 这种范围的产品,唯一的办法就是把每位工程师的产出放大。AI 是我们倚重的那个放大器。

五阶段工作流

eSimphony 的每一次变更——从一处文案修复到一次新运营商集成——都走同一套五阶段流程。每个阶段都有 AI 辅助;每个阶段都有人在回路里。

1. 探索(没有技术门槛)

当一项新需求出现("我们需要为埃及覆盖集成运营商 X"),工程师的第一步不是猜自己不知道的东西。而是用 AI 把未知领域用 20 分钟探明,而不是 2 天。

实际操作:一位从未集成过埃及 MVNO 的工程师,可以把运营商的 API 文档喂给 AI,得到一份结构化的集成面摘要,继续追问边角情况("这个市场典型的电子实名流程是怎样的?"),并在午餐前产出一份关于工作量、风险和未知项的一页评估。

变化在于:瓶颈不再是"我们有没有懂这个领域的工程师?",而是"我们手上的工程师,被 AI 增强后,能在几小时内变得在这个领域足够胜任吗?"。几乎总是可以。

2. 写文档(几小时,不是几周)

大多数公司的大多数产品文档要 1 到 3 周:产品经理起草、相关方评审、补充边角情况、打磨验收标准,然后工程再重新估算范围。等文档"定稿"时,原先的机会窗口已经移位。

我们的做法:工程师(或 CEO,视功能而定)起草一行产品想法。AI 把它扩成结构化的 PRD——用户流、边角情况、成功指标、验收标准、未决问题。团队在一次 45 分钟的工作会上打磨。文档当天就交给工程。

代价:这个流程产出的文档比传统的两周 PM 主导的文档要粗一些。我们接受这点。"到首次实现"的时间被压缩,值得这一点额外模糊;模糊在构建中解决,而不是在构建前。

3. 设计(快速反馈循环)

对于 UI 较重的功能,设计师和工程师在一个以分钟而非天为单位的"设计-构建-反馈"循环里并肩工作。AI 生成的草图(Figma 插件 + 图像生成器)用来快速探索方案。工程师几小时内交一份原型。设计师在真机上评审。迭代以当天为单位完成。

结果是设计和工程不再是串行——它们是并行的。当设计"定稿"时,实现已经接近上线了。

4. 构建(AI 写代码;人评审每一行 diff)

这是最直观的 AI 原生环节。eSimphony 今天的工程流程:

AI 生成约 90% 的新代码(Cursor、Claude、GitHub Copilot,常常组合使用)
工程师负责架构决策、集成边界、需要深度系统知识的棘手业务逻辑
100% 的代码在合并前会有人评审。 每一份 diff。每一个 PR。无例外。

最后一点至关重要,也常被误解。"AI 写代码"不等于"没人看代码"。它意味着工程师的角色从"敲实现"转变为"审实现"。认知工作——是否匹配文档、是否覆盖边角情况、是否契合架构、是否能扩展——依然是工程师的。机械工作——把意图翻译成语法正确、风格地道的代码——被外包。

eSimphony 一份典型的 PR 会包含:

200 到 800 行代码变更(对比 2024 年时代的团队约 100 到 200 行)
1 位工程师在做细致评审
常常有 AI 生成的单元测试,新代码覆盖率超过 80%
评审意见集中在架构上,而不是语法上

5. 发布(分钟级响应)

发布是渐进的:风险变更用功能开关,后端服务用金丝雀部署,AI 监测遥测在发布几分钟内就能发现异常。一旦发布出问题,回滚以分钟为单位,不是小时。

"AI 监测遥测"这部分值得多说一句:发布后,一个 AI 代理监测错误率、延迟、用户反馈和转化的异常。一旦异常越过阈值,值班工程师会收到包含可能根因摘要的告警。这把"问题被发现"的时间从"早上 9 点用户报 bug"压到"9:03 告警触发"。

数字

近 12 个月的大致指标:

迭代周期:1 周。 新功能按周发布;小修复按天发布。
5 名工程师 全职做产品。另一名工程师兼职。
超过 90% 的新代码 由 AI 生成(主要是 Cursor + Claude)。
100% 的合并代码 经过人工评审。
功能文档到生产的时间中位数:5 到 10 天。
每季度生产事故:1 到 2 起。 低于行业平均水平。
每周升级到工程的客服工单:约 5 起。 大多数当天解决。

这些不是理论。它们是我们团队真实的运行节奏。

它不是什么

值得明确说一下,在 eSimphony 这里,AI 原生开发不等于什么。

不是"凭感觉写代码"。 代码是一行行评审的。架构决策由人做。AI 加速的是打字,不是思考。

不是"不测试"。 AI 生成的测试有特定弱点(它们倾向于更全面地覆盖正常路径,而不是边角),所以工程师会手写边角的测试。新代码的覆盖率一直保持在 80% 以上。

不是"不需要资深工程师"。 恰恰相反。AI 大幅提升了资深判断的价值,因为资深工程师评审和打磨 AI 输出的速度比自己从头写要快 5 到 10 倍。初级工程师在没有资深评审的情况下用 AI,产出的代码往往能编译却结构脆弱。

不是"不需要设计或产品思考"。 没有清晰的规格和深思熟虑的用户流,AI 是没用的。"该建什么、为什么、为谁建"这种认知工作仍然是人的。

它需要什么

三件事,按重要性排列。

1. 硬性的人工评审

每一行 AI 生成的代码都会在合并前过一位资深工程师的评审。对"明显正确"的小改动想跳过评审的诱惑是真实而危险的。我们死守 100% 评审的底线。

2. 严格的架构边界

AI 生成代码时,会跟随当地约定。强约定 = 强 AI 输出。我们大量投入到清晰的模块边界、一致的命名、强类型接口,以及"我们这里是这么做事的"的明确文档,以便 AI 能干净地模式匹配。

3. 把 AI 作为默认这件事的文化认同

团队明确认同:AI 辅助在每个工作流中都是默认选项。新工程师入职时也会按这个默认接入。对"但我更喜欢自己写"的反对意见会被倾听和讨论,但团队规范是:除非有特定原因,机械工作都交给 AI。

我们不用 AI 做的事

评审 AI 生成的代码(我们要新鲜的人眼)
决定要做什么(产品策略由人来)
直接的客服升级(困难案例由人处理)
绩效评估和团队反馈(只能由人)
录用决定(只能由人,招聘端的搜寻和初筛可用 AI 辅助)

模式是:AI 增强执行;人拥有决策。

这对产品意味着什么

这套工作流的产出体现在产品上。我们已经交付:

终身 eSIM 架构(在大多数公司里是一个数个季度的项目)
Moza,AI 旅行伙伴,支持五种语言
覆盖三大区域的 AI 动态套餐
带自愈能力的 AI 故障排查
每周发布的原生 iOS 和 Android App
99.9%+ 可用率的多区域后端
全产品面 5 语种本地化

这份清单通常需要 30 到 50 名工程师和 3 年以上时间。我们用 5 名工程师在 18 个月内交付了它。

关于招聘

我们正在谨慎地扩大团队。在这里做得好的工程师有三个共同特征:

判断力优于产出量。 AI 负责打字;我们要的是擅长评审、决策和塑形的工程师。
能把 AI 当作同事。 把 AI 当作可以委派、需要评审、可以反驳的同事,而不是把它当成万能神谕或威胁自己身份的怪物。
关心用户。 AI 原生工作流足以产出大量能编译却没价值的代码。能在每个 PR 里追问"这对用户真的有用吗"的工程师,产出最好的工作。

如果这描述的是你,我们在招人。通过职位页联系我们,或直接给 Trung 留言。

接下来要交付什么

打造当前产品的同一套工作流正在交付路线图:

多 eSIM 管理(2026 年 5 月)
家庭套餐(2026 年 6 月)
忠诚度与奖励(2026 年 8 月)
全球直连运营商覆盖(2027 年)

每一项在传统电信公司都是一个数月级项目。我们的内部估计是,这四项都会按时交付,仍然由这五人团队完成。

那就是杠杆。那就是赌注。那就是一个小团队如何对抗整个行业的惯性。

体验 eSimphony、阅读我们的定位文章,或查看我们在 MVNO Nation Americas 的演讲材料。

一支 5 人团队如何以 10× 速度交付:eSimphony 的 AI 原生工程实践