我們?cè)谡幸粋€(gè)新崗位。

說(shuō)出來(lái)你可能會(huì)有點(diǎn)意外：

在很多人還在討論“AI 會(huì)不會(huì)讓程序員失業(yè)”的時(shí)候，我們最想找的，恰恰是——

既懂業(yè)務(wù)，又懂系統(tǒng)，還真用 AI 做過(guò)交付的程序員。

我們把這個(gè)崗位叫做：

ITBP。

IT Business Partner。IT 業(yè)務(wù)伙伴。

它有點(diǎn)像 HRBP。

HRBP 不是坐在辦公室里等用人部門提需求，而是貼著業(yè)務(wù)跑，理解組織真正缺什么。

ITBP 也一樣。

不是等別人把需求寫清楚再來(lái)開發(fā)。而是走到業(yè)務(wù)現(xiàn)場(chǎng)，把模糊問(wèn)題拆清楚，把 AI 變成真正能上線、能使用、能創(chuàng)造價(jià)值的系統(tǒng)。

今天這篇文章，我想講清楚：

什么是 ITBP。這個(gè)崗位到底在做什么。什么樣的人，適合來(lái)。

01

代碼變便宜之后，判斷力變貴了

最近我常聽到兩種說(shuō)法。

一種說(shuō)：

“AI 都能寫代碼了，程序員是不是要沒(méi)了？”

另一種說(shuō)：

“AI 寫出來(lái)的東西根本不能用，離替代還早。”

聽起來(lái)針鋒相對(duì)。

但其實(shí)，他們討論的不是同一件事。

寫代碼，是一個(gè)任務(wù)。程序員，是一個(gè)角色。

過(guò)去幾十年，我們把“寫代碼”這個(gè)任務(wù)，默認(rèn)裝進(jìn)了“程序員”這個(gè)角色里。

所以一說(shuō)“AI 會(huì)不會(huì)替代程序員”，大家就吵起來(lái)了。

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

當(dāng) AI 越來(lái)越擅長(zhǎng)把明確指令變成代碼，真正稀缺的，就不再只是‘把代碼敲出來(lái)’。

而是：

• 這個(gè)需求到底值不值得做？

• 業(yè)務(wù)方說(shuō)的，是表面訴求，還是真問(wèn)題？

• 該自研，還是用現(xiàn)成工具拼出更快的解法？

• 這個(gè)系統(tǒng)做出來(lái)，真的有人會(huì)用嗎？

• AI 生成的代碼，看起來(lái)能跑，實(shí)際上有沒(méi)有坑？

這些問(wèn)題，靠的不是手速。

靠的是：

業(yè)務(wù)理解。系統(tǒng)判斷。真實(shí)交付過(guò)項(xiàng)目之后留下來(lái)的經(jīng)驗(yàn)。

換句話說(shuō)：

AI 讓執(zhí)行變快。也讓判斷變貴。

而 ITBP，就是站在這個(gè)變化中心的新角色。

02

ITBP，不是三個(gè)舊崗位的拼盤

第一次聽到 ITBP，有人會(huì)說(shuō)：

“哦，不就是產(chǎn)品經(jīng)理 + 架構(gòu)師 + AI 工程師嗎？”

是。但也不只是。更準(zhǔn)確地說(shuō)：

ITBP =產(chǎn)品經(jīng)理能力 × 架構(gòu)師能力 × AI 驅(qū)動(dòng)交付能力

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

任何一項(xiàng)是 0，整體都會(huì)失效。

只有產(chǎn)品能力，沒(méi)有技術(shù)判斷，容易把需求寫得很漂亮，卻落不了地。

只有架構(gòu)能力，沒(méi)有業(yè)務(wù)理解，容易把系統(tǒng)設(shè)計(jì)得很完整，卻解決了一個(gè)不重要的問(wèn)題。

只會(huì)用 AI 編程工具，沒(méi)有產(chǎn)品和架構(gòu)判斷，最后只是：

更快地做錯(cuò)事。

所以，我們要找的，不是某個(gè)傳統(tǒng)崗位的升級(jí)版。

而是一種新的復(fù)合型人才：

能聽懂業(yè)務(wù)。能設(shè)計(jì)方案。能驅(qū)動(dòng) AI 把系統(tǒng)做出來(lái)。還能對(duì)最后的結(jié)果負(fù)責(zé)。

03

ITBP 每天到底在做什么？

我們用一個(gè)具體場(chǎng)景來(lái)理解。

上午 10 點(diǎn)，業(yè)務(wù)負(fù)責(zé)人走過(guò)來(lái)：

“我想看一下公眾號(hào)每篇文章的詳細(xì)數(shù)據(jù)，最好把數(shù)據(jù)之間的相關(guān)性展示出來(lái)。”

如果按傳統(tǒng)方式推進(jìn)，通常是：

先記下來(lái)。

再開會(huì)。

再補(bǔ)需求。

再排期。

再等開發(fā)。

幾個(gè)月過(guò)去，業(yè)務(wù)可能都變了。

ITBP 不一樣。

他會(huì)先問(wèn)：

• 你看這個(gè)數(shù)據(jù)，是為了做什么決策？

• 誰(shuí)會(huì)每天用？

• 數(shù)據(jù)從哪里來(lái)？

• 是先做一個(gè)能用的版本，還是一上來(lái)就要完整 BI？

• 有沒(méi)有現(xiàn)成工具，能更快解決？

一小時(shí)后，他大致判斷清楚：

這不是一個(gè)“做大系統(tǒng)”的需求。

這是一個(gè)“讓業(yè)務(wù)這周就能看懂關(guān)鍵指標(biāo)”的需求。

于是，他可能會(huì)選擇：

先用現(xiàn)成數(shù)據(jù)源 + 輕量前端 + AI 輔助生成分析邏輯，快速做出第一版；

如果后續(xù)確實(shí)高頻使用，再升級(jí)成更完整的系統(tǒng)。

當(dāng)天，第一版跑通。

第二天，和業(yè)務(wù)一起看。

第三天，再改掉最關(guān)鍵的 3 個(gè)細(xì)節(jié)。

一周，一個(gè)真業(yè)務(wù)開始運(yùn)轉(zhuǎn)。

這就是 ITBP 的工作。

不是寫 PPT，做會(huì)議搬運(yùn)工。

不是“你提需求，我來(lái)排期”。

而是：

把業(yè)務(wù)問(wèn)題，壓縮成可交付結(jié)果。

我們期待你，能把這件事真正做起來(lái)。

1. 先看懂業(yè)務(wù)，再?zèng)Q定怎么做

業(yè)務(wù)給你的，往往不是標(biāo)準(zhǔn)答案，而是一句模糊訴求。

比如：

“我們想做個(gè) AI 助手。”

你要繼續(xù)往下問(wèn)：

• 誰(shuí)在用？

• 用來(lái)問(wèn)什么？

• 資料從哪來(lái)？

• 答案需不需要標(biāo)注出處？

• 允許回答“不知道”嗎？

• 對(duì)上線速度、預(yù)算、安全有沒(méi)有要求？

你要先把問(wèn)題想清楚，再判斷路徑。

有些需求，飛書多維表格就夠了。

有些需求，用 Coze、Dify、n8n 拼起來(lái)更快。

有些需求，值得自研。

第一反應(yīng)，不是‘我來(lái)用 AI 寫一個(gè)’，而是‘怎樣最快、最穩(wěn)、最值得地解決問(wèn)題’。

1. 你要懂系統(tǒng)，也要真的能把系統(tǒng)交付出來(lái)

你不用親手敲完每一行代碼。

但你得看得懂系統(tǒng)全貌：

前端、后端、數(shù)據(jù)庫(kù)、API、云部署之間是什么關(guān)系；

你得熟悉至少一種前端框架和一種后端技術(shù)棧；

你得理解數(shù)據(jù)庫(kù)設(shè)計(jì)、Docker、Linux、HTTP、DNS、反向代理這些真正上線時(shí)會(huì)遇到的事。

更重要的是，你要真的用過(guò) AI 做開發(fā)。

不是偶爾問(wèn)問(wèn) ChatGPT。

而是在真實(shí)任務(wù)里使用過(guò) Claude Code、Codex等 Agentic Coding 工具，知道：

• 怎樣寫 Spec，AI 才不容易跑偏；

• AI 常在哪些地方犯錯(cuò)；

• 出 Bug 時(shí)，怎么從日志、代碼、上下文里定位問(wèn)題；

• 不同模型在質(zhì)量、速度、成本上的差異。

• 你理解 RAG、Agent、Embedding、大模型 API、Harness Engineering，并且真做過(guò)東西。

1. 你要會(huì)做取舍，也要會(huì)和人溝通

這個(gè)崗位不是躲在電腦后面獨(dú)立完成一切。

你要面對(duì)業(yè)務(wù)方。

面對(duì)不懂技術(shù)、但很在意結(jié)果的人。

你得能用大白話講清楚：

為什么這個(gè)需求不該這樣做。

為什么這個(gè)方案今天先做 60 分，反而是更負(fù)責(zé)的決定。

你也要能根據(jù)預(yù)算、時(shí)間、客戶規(guī)模和未來(lái)擴(kuò)展，并講清楚為什么選這個(gè)、不選那個(gè)。

1. 經(jīng)驗(yàn)上，我們希望你已經(jīng)打過(guò)一些硬仗

• 有 2 年以上軟件開發(fā)經(jīng)驗(yàn)，至少獨(dú)立主導(dǎo)過(guò) 2 個(gè)從需求到上線的完整項(xiàng)目。

• 做過(guò)乙方軟件公司全棧、初創(chuàng)團(tuán)隊(duì)、獨(dú)立開發(fā)、咨詢售前相關(guān)工作，會(huì)很適配。

• 如果你還有企業(yè)數(shù)字化系統(tǒng)經(jīng)驗(yàn)、在 GitHub等平臺(tái)有持續(xù)的技術(shù)輸出，那會(huì)更好。

• 科班出身、工程感很強(qiáng)的人。vibe coder已經(jīng)獨(dú)立做出過(guò)非常不錯(cuò)案例也可考慮。

1. 年齡不是門檻，狀態(tài)才是

這個(gè)崗位，我們不太按年齡篩人。

年輕的人，慣性更少，包袱更輕，往往更愿意試錯(cuò)，也更敢重新定義做事方式。

而有經(jīng)驗(yàn)的人，如果還保留開放、好奇和行動(dòng)力，

那些踩過(guò)的坑、做過(guò)的判斷，反而會(huì)在 AI 時(shí)代變得格外值錢。我們反而會(huì)特別珍惜那些已經(jīng)走過(guò)一段路、真正打過(guò)硬仗的人。

過(guò)去，“35 歲危機(jī)”在程序員群體里尤其刺眼。

可 AI 出現(xiàn)之后，局面正在發(fā)生變化。

當(dāng)“把代碼寫出來(lái)”這件事越來(lái)越多地交給 AI，

真正變貴的，反而是：

• 你見過(guò)多少?gòu)?fù)雜場(chǎng)景；

• 你踩過(guò)多少坑；

• 你能不能判斷一個(gè)方案哪里會(huì)出問(wèn)題；

• 你能不能在業(yè)務(wù)、技術(shù)、成本之間做出成熟取舍。

這些東西，不是一天學(xué)會(huì)的。

它們往往來(lái)自很多年的項(xiàng)目經(jīng)驗(yàn)，來(lái)自真正把系統(tǒng)做上線、做穩(wěn)定、做出結(jié)果。

所以，35 歲不一定意味著“性價(jià)比下降”。

在 AI 時(shí)代，它也可能意味著：

你終于積累到了最值錢的那部分能力。

所以我們不設(shè)一個(gè)僵硬的年齡框。

我們更在意的是：

你還愿不愿意學(xué)，敢不敢跨界，能不能持續(xù)把事情做成。

04

我們提供

• 充足的 AI 開發(fā)預(yù)算， token max，不擔(dān)心你用得多，只害怕你用得太少；

• 穩(wěn)定的網(wǎng)絡(luò)和開發(fā)環(huán)境，各類主流模型與工具賬號(hào)；

• 有競(jìng)爭(zhēng)力的年薪包，績(jī)效優(yōu)異者，獎(jiǎng)金超乎預(yù)期；

• 早九晚六，周末雙休，五險(xiǎn)一金實(shí)繳。

05

多年后，人類可能會(huì)意識(shí)到，AGI 正式降臨的那一天，是 2026 年 2 月 5 日。

這一天，Codex 5.3 和 Opus 4.6 同時(shí)發(fā)布。

Agent 從電腦里跳出來(lái)，坐在電腦前，開始自己寫自己。

之后你看到的一切巨變，

也許都只是在迎接 2027。

而我們想找的，

正是愿意站到這場(chǎng)變化最前面的人。

如果你也想親手把 AI 變成真實(shí)世界里的生產(chǎn)力，歡迎來(lái)聊聊。

請(qǐng)將：

簡(jiǎn)歷 +GitHub項(xiàng)目鏈接/代表作品

發(fā)送至：

hr@run2me.com

郵件標(biāo)題：

ITBP 應(yīng)聘 - 姓名

如果簡(jiǎn)歷和作品合適，我們會(huì)邀約面試。

特別說(shuō)明， 我司特別重視團(tuán)隊(duì)協(xié)作，所有崗位均需面對(duì)面一起辦公（base上海），暫無(wú)線上遠(yuǎn)程和兼職崗位。

期待你的加入。