我們在招一個新崗位。

說出來你可能會有點意外：

在很多人還在討論“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上海），暫無線上遠程和兼職崗位。

期待你的加入。