润米招聘程序员，做AI时代的ITBP！

我们在招一个新岗位。

说出来你可能会有点意外：

在很多人还在讨论“AI 会不会让程序员失业”的时候，我们最想找的，恰恰是——

既懂业务，又懂系统，还真用 AI 做过交付的程序员。

我们把这个岗位叫做：

ITBP。

IT Business Partner。IT 业务伙伴。

它有点像 HRBP。

HRBP 不是坐在办公室里等用人部门提需求，而是贴着业务跑，理解组织真正缺什么。

ITBP 也一样。

不是等别人把需求写清楚再来开发。而是走到业务现场，把模糊问题拆清楚，把 AI 变成真正能上线、能使用、能创造价值的系统。

今天这篇文章，我想讲清楚：

什么是 ITBP。这个岗位到底在做什么。什么样的人，适合来。

01

代码变便宜之后，判断力变贵了

最近我常听到两种说法。

一种说：

“AI 都能写代码了，程序员是不是要没了？”

另一种说：

“AI 写出来的东西根本不能用，离替代还早。”

听起来针锋相对。

但其实，他们讨论的不是同一件事。

写代码，是一个任务。程序员，是一个角色。

过去几十年，我们把“写代码”这个任务，默认装进了“程序员”这个角色里。

所以一说“AI 会不会替代程序员”，大家就吵起来了。

但真正正在变化的，是另一件事：

当 AI 越来越擅长把明确指令变成代码，真正稀缺的，就不再只是‘把代码敲出来’。

而是：

• 这个需求到底值不值得做？

• 业务方说的，是表面诉求，还是真问题？

• 该自研，还是用现成工具拼出更快的解法？

• 这个系统做出来，真的有人会用吗？

• AI 生成的代码，看起来能跑，实际上有没有坑？

这些问题，靠的不是手速。

靠的是：

业务理解。系统判断。真实交付过项目之后留下来的经验。

换句话说：

AI 让执行变快。也让判断变贵。

而 ITBP，就是站在这个变化中心的新角色。

02

ITBP，不是三个旧岗位的拼盘

第一次听到 ITBP，有人会说：

“哦，不就是产品经理 + 架构师 + AI 工程师吗？”

是。但也不只是。更准确地说：

ITBP =产品经理能力 × 架构师能力 × AI 驱动交付能力

注意，是乘法。不是加法。

任何一项是 0，整体都会失效。

只有产品能力，没有技术判断，容易把需求写得很漂亮，却落不了地。

只有架构能力，没有业务理解，容易把系统设计得很完整，却解决了一个不重要的问题。

只会用 AI 编程工具，没有产品和架构判断，最后只是：

更快地做错事。

所以，我们要找的，不是某个传统岗位的升级版。

而是一种新的复合型人才：

能听懂业务。能设计方案。能驱动 AI 把系统做出来。还能对最后的结果负责。

03

ITBP 每天到底在做什么？

我们用一个具体场景来理解。

上午 10 点，业务负责人走过来：

“我想看一下公众号每篇文章的详细数据，最好把数据之间的相关性展示出来。”

如果按传统方式推进，通常是：

先记下来。

再开会。

再补需求。

再排期。

再等开发。

几个月过去，业务可能都变了。

ITBP 不一样。

他会先问：

• 你看这个数据，是为了做什么决策？

• 谁会每天用？

• 数据从哪里来？

• 是先做一个能用的版本，还是一上来就要完整 BI？

• 有没有现成工具，能更快解决？

一小时后，他大致判断清楚：

这不是一个“做大系统”的需求。

这是一个“让业务这周就能看懂关键指标”的需求。

于是，他可能会选择：

先用现成数据源 + 轻量前端 + AI 辅助生成分析逻辑，快速做出第一版；

如果后续确实高频使用，再升级成更完整的系统。

当天，第一版跑通。

第二天，和业务一起看。

第三天，再改掉最关键的 3 个细节。

一周，一个真业务开始运转。

这就是 ITBP 的工作。

不是写 PPT，做会议搬运工。

不是“你提需求，我来排期”。

而是：

把业务问题，压缩成可交付结果。

我们期待你，能把这件事真正做起来。

1. 先看懂业务，再决定怎么做

业务给你的，往往不是标准答案，而是一句模糊诉求。

比如：

“我们想做个 AI 助手。”

你要继续往下问：

• 谁在用？

• 用来问什么？

• 资料从哪来？

• 答案需不需要标注出处？

• 允许回答“不知道”吗？

• 对上线速度、预算、安全有没有要求？

你要先把问题想清楚，再判断路径。

有些需求，飞书多维表格就够了。

有些需求，用 Coze、Dify、n8n 拼起来更快。

有些需求，值得自研。

第一反应，不是‘我来用 AI 写一个’，而是‘怎样最快、最稳、最值得地解决问题’。

1. 你要懂系统，也要真的能把系统交付出来

你不用亲手敲完每一行代码。

但你得看得懂系统全貌：

前端、后端、数据库、API、云部署之间是什么关系；

你得熟悉至少一种前端框架和一种后端技术栈；

你得理解数据库设计、Docker、Linux、HTTP、DNS、反向代理这些真正上线时会遇到的事。

更重要的是，你要真的用过 AI 做开发。

不是偶尔问问 ChatGPT。

而是在真实任务里使用过 Claude Code、Codex等 Agentic Coding 工具，知道：

• 怎样写 Spec，AI 才不容易跑偏；

• AI 常在哪些地方犯错；

• 出 Bug 时，怎么从日志、代码、上下文里定位问题；

• 不同模型在质量、速度、成本上的差异。

• 你理解 RAG、Agent、Embedding、大模型 API、Harness Engineering，并且真做过东西。

1. 你要会做取舍，也要会和人沟通

这个岗位不是躲在电脑后面独立完成一切。

你要面对业务方。

面对不懂技术、但很在意结果的人。

你得能用大白话讲清楚：

为什么这个需求不该这样做。

为什么这个方案今天先做 60 分，反而是更负责的决定。

你也要能根据预算、时间、客户规模和未来扩展，并讲清楚为什么选这个、不选那个。

1. 经验上，我们希望你已经打过一些硬仗

• 有 2 年以上软件开发经验，至少独立主导过 2 个从需求到上线的完整项目。

• 做过乙方软件公司全栈、初创团队、独立开发、咨询售前相关工作，会很适配。

• 如果你还有企业数字化系统经验、在 GitHub等平台有持续的技术输出，那会更好。

• 科班出身、工程感很强的人。vibe coder已经独立做出过非常不错案例也可考虑。

1. 年龄不是门槛，状态才是

这个岗位，我们不太按年龄筛人。

年轻的人，惯性更少，包袱更轻，往往更愿意试错，也更敢重新定义做事方式。

而有经验的人，如果还保留开放、好奇和行动力，

那些踩过的坑、做过的判断，反而会在 AI 时代变得格外值钱。我们反而会特别珍惜那些已经走过一段路、真正打过硬仗的人。

过去，“35 岁危机”在程序员群体里尤其刺眼。

可 AI 出现之后，局面正在发生变化。

当“把代码写出来”这件事越来越多地交给 AI，

真正变贵的，反而是：

• 你见过多少复杂场景；

• 你踩过多少坑；

• 你能不能判断一个方案哪里会出问题；

• 你能不能在业务、技术、成本之间做出成熟取舍。

这些东西，不是一天学会的。

它们往往来自很多年的项目经验，来自真正把系统做上线、做稳定、做出结果。

所以，35 岁不一定意味着“性价比下降”。

在 AI 时代，它也可能意味着：

你终于积累到了最值钱的那部分能力。

所以我们不设一个僵硬的年龄框。

我们更在意的是：

你还愿不愿意学，敢不敢跨界，能不能持续把事情做成。

04

我们提供

• 充足的 AI 开发预算， token max，不担心你用得多，只害怕你用得太少；

• 稳定的网络和开发环境，各类主流模型与工具账号；

• 有竞争力的年薪包，绩效优异者，奖金超乎预期；

• 早九晚六，周末双休，五险一金实缴。

05

多年后，人类可能会意识到，AGI 正式降临的那一天，是 2026 年 2 月 5 日。

这一天，Codex 5.3 和 Opus 4.6 同时发布。

Agent 从电脑里跳出来，坐在电脑前，开始自己写自己。

之后你看到的一切巨变，

也许都只是在迎接 2027。

而我们想找的，

正是愿意站到这场变化最前面的人。

如果你也想亲手把 AI 变成真实世界里的生产力，欢迎来聊聊。

请将：

简历 +GitHub项目链接/代表作品

发送至：

hr@run2me.com

邮件标题：

ITBP 应聘 - 姓名

如果简历和作品合适，我们会邀约面试。

特别说明， 我司特别重视团队协作，所有岗位均需面对面一起办公（base上海），暂无线上远程和兼职岗位。

期待你的加入。