AI 全栈工程师 Full-Stack Engineer AI Native Base 迪拜/全远程(二选一) · 全职 · 3 年以上经验(参考) 有一件事值得先说清楚,因为它基本决定了你会不会喜欢这里:我们是真的靠 AI 工具在交付。过去一个月合并了七百多个 PR,非合并提交里超过一半带着 AI 协作者的署名。也正因为如此,我们把"怎么确认它是对的”做成了制度:机器闸、独立验收、可观测性要求,都是写进流程里的硬约束。用得猛和管得严,在这里是同一件事的两面。 关于这个机会 ① “一人到底”是真的,含义也比听上去重。 按模块切,每人前后端全包,模块内怎么实现由你自己定,不需要先写方案等人批。代价是”到底"包含最后一公里:要一直推到独立验收通过、业务同事也真用过并认可,才算结束。动到多人共用的公共部分和数据库结构变更时,需要先出方案、和受影响的同事一起过一遍。这部分我们不含糊,因为它们的影响面是全局的。 ② 把 AI 能力接进产品,是一个刚打开的工作面。出于安全约束,今天线上的模型推理不开放工具调用;要让产品里的 AI 从“给建议的副驾”走到”能替客户办事”,这条线基本是从零搭起,是接下来一年最大的一块新增量。agent 内核本身(记忆、知识检索、人设组装、模型调度)由专门的团队负责;你的活是把这些能力真正接进一个有客户在用的产品:接口契约、状态持久化、并发与限流、失败降级、人工接管与留痕、前端交互、用量计量。这是全栈工程的活,不是模型调优的活。 ③ 有几道真正的工程题在等人。多租户与组织层级正在落地(子树可见性、防环、读写两侧口径一致);再往后是两块已经排进路线的深水区——本地文件存储云化,以及把 IM 连接层从单进程拆成按租户调度的 worker 池。这些不是”以后可能会做”,是有排期的题。 ④ 你的判断会被认真挑战,而不是被流程磨平。团队小,决定谁来做、怎么做的链条很短,提一个方案会得到具体的技术反驳,而不是一句"走个流程”。对应地,你负责的模块从设计到线上表现都由你自己 own 。这是"一人到底"真正的分量。 岗位职责 日常是混着来的,不是分阶段的。 现网产品:功能交付与线上运行 ① 承接完整功能模块的端到端交付:需求拆解→接口设计数据库结构与迁移→后端实现→前端页面→上线观察。前端在这里是与后端同量级的主战场,不是"接口联调之外顺手写的页面”。 ② 把问题收到根上。跨语种的内容判定、消息的幂等与顺序、长连接断开后的状态恢复。这类问题的共同点是,表面症状只是一个点,真正的工作是把同一类情况一次梳理干净。我们看重的是后者。 ③ 持续的架构演进:拆分过大的模块、收敛重复实现、为关键路径补上自动化测试与可观测性。在有存量、有客户、不能停机的系统里安全地做这件事,比在空地上重建更考验判断。这也是我们最看重的能力之一。 Go 重写:在新仓里承接模块 ④ 按模块承接后端重构:读懂现网这块业务真正的行为,在新架构里重新实现它。迁功能不迁文件,只带走经过验证的业务语义。 ⑤ 在新架构的硬约束下工作,并参与把它建起来:状态只落 PostgreSQL 一层(锁与租约进库,与被保护的数据同一个事务)、一张表只归一个模块、状态转换只走中心化的统一入口。约束本身可以讨论,但不能绕——它们是写死在 CI 里的。 ⑥ 维护现网已有的 Go 组件:IM 协议连接器由主进程拉起、以长连接回程,它们的可靠性同样归你负责。 运维、部署、稳定性、并发 ⑦ 私有化交付的工程侧:客户开通、实例部署、版本升级与回滚、现场技术支持。这是这个岗位真实的一大块工作量,不是加分项里的一句话。 ⑧ 并发正确性是日常而不是专题:幂等与去重、认领竞态与租约、崩溃恢复、断线重连与消息顺序、跨进程状态一致性、限流与配额、优雅停机。在多账号、多平台、长连接的场景下,这些是每天都要做的设计判断,不是偶尔遇到的难题。 ⑨ 可观测性以"拿到告警的人知道该做什么”为标准:告警要能定位、能分级、能指向明确的下一步动作,而不只是把底层错误透传出去。 你会接手一个什么样的系统 ① 一个有真实客户、持续演进的生产系统。过去一年我们完成过几次幅度不小的改造:前端从原生 JS 整体重写为 React 、存储从文件迁到 PostgreSQL 、鉴权从单一 token 重做成细粒度权限体系、账号与群的状态流转收敛到带 CI 守卫的统一入口。我们干过这类事,知道它要花多少力气,也知道它值得。 ② 一个正在成型的 Go 新栈。单二进制后端加全新前台,模块边界、状态层唯一化、路由注册表、架构守卫都已写死成 CI 规则。它的设计意图很明确:把这些年验证过的东西带走,把不该复制的访问模式留下。你来的时间点,正好赶得上参与真正的业务实现阶段。 ③ 一条外部依赖密集、边界条件全是真的链路。IM 平台长连接、消息撤回与媒体补拉、第三方接口超时、跨时区跨语种的内容规则。这些不是面试题里的假设,是每天要处理的真实工程约束。 ④ 一套机器执行的工程纪律。我们的底线不靠自觉,也不靠写在某个文档里:不是每个人都用同一套工具,所以每条底线都必须有一个工具中立的载体——一条 CI 检查、提交模板里的一个必填栏,或者某个具体的人必须做的动作。每条守卫我们都会先验证它确实拦得住违例,而不是默认它有效。 ⑤ 一条独立于作者的验收链。每个交付要过独立的技术验收,再由业务同事按业务语言确认一遍。自动运行的改动还要回答三个问题:怎么触发它、怎么看到它真的跑了、跑错了从哪看出来。 任职要求(必备) ① 你能用 AI 工具把活真正干完,并且知道怎么验证它。我们不考核你是不是纯手写代码,考核的是你会不会用、会不会验证、会不会在 AI 给错答案时自己发现并纠正。我们会请你说清楚:你提交的某段 AI 参与生成的代码具体做了什么、你用什么证据确认它是对的、以及你有没有过一次"AI 给了一个很像对的错答案、被你自己发现并纠正”的经历。这是我们最看重的一条。 ② 3 年以上后端或全栈开发经验,独立主导过完整模块或产品的交付上线,并为它上线之后的表现负过责。 ③ 熟练的 TypeScript,以及 React 技术栈的真实交付产出。能独立完成有状态、有交互复杂度的功能页面,而不仅限于接口联调。 ④ 扎实的 PostgreSQL 工程能力:事务与隔离级别、索引与执行计划、schema 迁移方案、行级锁与租约、用 CAS 做并发安全的状态流转。这条是硬要求,因为新架构把状态收敛到了数据库这一层。 ⑤ 并发与分布式场景下的工程判断力:幂等、重试、超时、崩溃恢复、顺序保证,对你是具体的实现选择而不是概念名词。能说清"为什么这里需要一把分布式锁”,和能说清”为什么这里不需要”,同样重要。 ⑥ Go:已经在写当然好;没写过也可以投。我们现在写 Go 的主力也是从 TypeScript 转过来的。前提是你拥有强类型语言(Go/Java/C#/Rust/C++等)的扎实工程基础,并且愿意把 Go 变成自己的主力语言。 工作方式上还需要:接受迪拜现场办公或全远程其中一种,并能与团队保持稳定的时区重叠。 还有一句直白的:我们要的是给结论的人。列了两个方案不给推荐,等于把决策外包给信息比你少的人;"环境里没有测试账号所以没验"在这里也不是一个可接受的

  • 情报分类：工作与职业机会
  • 分类依据：内容涉及招聘、求职或职业发展
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/23 18:14:51