--- title: "AI 時代的招聘與範式轉換" date: "2026-08" category: "ai運用" tags: ["ai運用"] description: "有一點說法我覺得是沒錯的，那就是未來，尤其是現在的 AI 時代，招聘的整個方式和體系都一定會逐漸改變。因為所謂的古法程式設計，它帶來的收益會越來越低..." source: "https://enriquemark.com/zh-hant/posts/AI%20%E6%97%B6%E4%BB%A3%E7%9A%84%E6%8B%9B%E8%81%98%E4%B8%8E%E8%8C%83%E5%BC%8F%E8%BD%AC%E6%8D%A2" --- 有一點說法我覺得是沒錯的，那就是未來，尤其是現在的 AI 時代，招聘的整個方式和體系都一定會逐漸改變。因為所謂的古法程式設計，它帶來的收益會越來越低，而過去那些 Team Leader 所具備的技能價值會越來越高。這項核心技能是什麼呢？就是驗證。 AI 在生成上非常強，而過去程式設計師主要做的工作恰恰就是生成。這就導致我們傳統的招聘和麵試體系，都傾向於去核查生成能力，比如做白板題、考各種各樣的知識，或者問你某個語法上的問題。 但是，AI 時代最重要的工作過程，已經從生成轉移到了驗證。關鍵點在於：我今天生成了一萬行程式碼，請問這一萬行程式碼是不是穩健的、可生產級執行的？有沒有潛藏的坑？我認為一個好的 AI-native 工程師，他的核心技能應當就是去做驗證——無論是去設計一套體系，通過過程來保證生產結果的穩健性；還是憑藉自己足夠強的品味和結構性洞察，能一眼看出來 AI 的這套設計需要改、該往什麼方向改。他其實在時刻做著驗證的工作。 這種驗證的工作，也使得我們當今對於知識和技能的學習，需要轉向另一個方向。我認為對於那種過於特化的任務，應當減少精力的投入；而那些高度可遷移的知識，才是未來我們要去學的。也就是說，當今的時代在一定程度上，真的是廣度大於深度。 這並不是說深度不重要，而是廣度能帶給我們一大核心優勢——索引上的優勢。什麼叫索引上的優勢？就是當我遇到某個問題時，我可以立即想起來：「哦，我之前在哪裡看過這個東西。」雖然我對它的深度不瞭解，但我知道有這麼個東西存在。舉個例子，我知道在做 Agent 的時候要做 Eval（評估）。如果我完全沒接觸過這個領域，我會有做 Eval 的意識嗎？廣度恰恰提供了這樣一種能力，那就是在特定情況下，能讓我立即調取一個我本來不深入瞭解的概念。而這往往是解決問題的關鍵鑰匙。 索引帶來的優勢就在於，我可以快速用這個話題去問 AI。AI 的典型特點是，你不問的時候它可能根本不會主動回答，但一旦你問了，它就能回答得很深。只要我知道有這麼回事，我就可以去查、去了解，深度在這個過程中是可以快速補上的。當然，補到什麼程度取決於工程現場需要用到什麼程度。對工程師來講，夠用才是最關鍵的。 同時，廣度也會為驗證提供優勢。驗證的關鍵，恰恰在於「知道自己哪裡錯了」。過去的 Team Leader 一眼就能看出某個地方設計不對，為什麼 Junior 工程師看不出來？因為他沒有相關的廣度知識，他不知道自己不知道什麼。如果我現在補足了廣度，我也能意識到自己還有哪些認知盲區；雖然還沒有真正意義上的 Senior 那麼深刻，但我可以去問 AI，以前不知道該問什麼，現在知道了。這就是索引的能力。 因此，可遷移性越高的知識，在當代越值得學習。在電腦科學裡，這指的就是底層基礎，比如標準的系統設計、演算法、資料結構等等。至於刷 LeetCode，在我看來投入產出比不是特別高。除非你要去那種大廠，面臨硬性門檻，需要刷一大堆 Hard 級別的題，且進去之後收益很高，那可能是值得投入的。但如果你的目的僅僅是進中小型廠，或者拿一箇中位數的薪水，那麼比起盲目刷題，去積累結構性的、可遷移的知識才是更重要的。比如去補足計算機基礎、軟體工程設計、架構設計、分散式系統等等。 這些在過去其實是架構師和 Leader 才要學的東西，但在今天，哪怕是一個 Junior 也應該掌握。我們整個學校體系，尤其是工程導向的學校體系，也應該朝這個方向改變，尤其是重視學生的架構設計能力和知識廣度。AI 是我們的輔助，但想要判斷它的輔助到底正不正確，需要的恰恰就是這種廣度知識。 另一方面，深度的知識同樣重要，但這取決於專案的規模和層級。如果是一個非常重要的專案，深度的知識仍然是必要的；但對於大部分普通的消費級產品來講，可能真的用不到那麼深。比如做一箇中小型企業的專案，真的需要去考慮百萬併發那種級別的深度嗎？用不到。需要的時候再去學就行了。而且深度是存在階梯的，按照一般人的職業晉升體系，流量從一萬到十萬再到百萬級，如果你一直在這條路上走，深度的積累自然而然會增加。 至於演算法題，我的態度是，像 Easy 或 Medium 這種難度，尤其是高頻題，稍微刷個幾十、一百道也就差不多了。完全沒必要去卷千道題，那個投入產出比太低了。 這裡還有一個核心點，那就是很多時候企業需要的真的只是一個「訊號」，需要低成本地識別出你是一個可用的人才。對企業來說，招錯一個人的代價遠大於錯過一個好人。因為錯的人會帶來減損，而錯過好人最多隻是沒有額外收益。因此企業會更傾向於避免錯誤，尤其是破壞性的錯誤。 在當今時代，這種可識別的訊號會越來越重要。這也是為什麼我寫部落格的原因，我希望能把自己的見解和認知寫出來，以此來提高外界對我知識體系的識別度，包括我對 AI 的理解、對架構設計的理解等。這至少能讓企業在一定程度上對齊資訊，快速瞭解我這個人的技術底色。 除了部落格，GitHub 上的一些專案程式碼，本身也是一種質量的象徵。我不會去標榜「專案全是我手寫的」，這年頭誰還古法程式設計，標榜手寫反而有點虛偽了，程式碼當然有很多是 AI 生成的。但我認為，正因為是 AI 生成的，去讀一讀程式碼就能立馬看出質量高低——會用 AI 的，和不會用的，哪怕是同樣一個cc，也能用處截然不同的效果。比如是否有足夠的測試覆蓋？整體架構設計是否清晰？有沒有真正考慮到 AI 長期參與程式設計後會產生的漂移問題？換言之，就是我之前所說的，你到底有沒有去做好「驗證」這個東西。 典型的多 Agent 協同問題就是，我讓 AI 去改 A 模組，或者加一個小功能，結果它把我後面整個專案全改壞了。光是從程式碼的隔離上就能看出使用水平，沒有做到位，就說明大機率還沒踩過坑，那就是使用 AI 的技術還停留在比較早期的程度。在我看來，能不能把 AI 用好的關鍵點，就在於能不能把 AI 的行動範圍限制住。harness 就其字面意思來說就是「馬具」，可想讓馬兒跑起來，只有馬具是不夠的，騎馬的人也得有足夠的駕駛技巧。只有把範圍限制住了，我們後面才能對它的每一個模組進行可靠的驗證。 所以，一切其實還是落回到「可驗證」上面。大概這就是我今天的一些感觸。