編程 Agent 如何重塑工程、產品和設計
整理版優先睇
編程 Agent 改變 EPD 遊戲規則：從實現到評審，通才與系統思維成關鍵
呢篇文章探討編程 Agent（例如 Claude、Cursor 等 AI 編程工具）點樣重塑軟件公司嘅工程、產品同設計（EPD）團隊。作者認為，傳統以 PRD（產品需求文檔）為中心嘅開發流程已經終結，因為 Agent 可以將想法直接變成可運行嘅軟件，令實現成本極低。但呢個唔代表品質自動提升，反而將瓶頸從「寫代碼」轉移到「評審原型」——EPD 團隊要確保 Agent 生產嘅代碼架構合理、解決啱問題、用戶體驗好。
整體結論係：EPD 角色正喺度分化，通才因為減少溝通開銷而更有價值，系統思維成為差異化核心技能，而每個人都需要產品意識。如果唔識用 Agent 或者缺乏產品思維，就會被淘汰。作者仲指出，而家 EPD 團隊分為「建設者」（用 Agent 快速實現）同「評審者」（深度把關），專業化門檻更高，但每個人都覺得自己從 Agent 受益最大——而且可能都係啱嘅。
- 傳統 PRD 流程已死：由 PRD 到設計稿再到代碼嘅線性模式被顛覆，Agent 可以直接從想法生成原型。
- 瓶頸從實現轉向評審：因為生成原型太容易，EPD 團隊要大量評審原型，確保「足夠好」——架構合理、產品思維到位、設計易用。
- 通才嘅價值大增：一個人如果同時掌握產品、設計同工程 sense，可以唔使同其他人溝通，直接同 Agent 協作，效率遠超團隊。
- 系統思維係核心差異化能力：喺執行成本極低嘅世界，真正嘅價值在於對系統有清晰嘅心智模型，確保方向正確先再動手。
- EPD 角色兩極化：建設者（用 Agent 快速實現）同評審者（深度評審架構、產品、設計），專業化門檻更高，每個人都要向其中一邊發展。
流程顛覆：PRD 已死，評審為王
傳統 EPD 流程係 PRD → 設計稿 → 代碼，因為寫軟件要花好多時間同精力，所以有專門分工，PRD 就係串起一切嘅起點。但編程 Agent 顛覆咗呢個模式：佢可以將一個想法直接變成可運行嘅軟件。
PRD 已死
作者指出，呢個「死」嘅意思係指從寫 PRD 開始嘅傳統開發方式終結咗。
瓶頸從實現轉向評審
而家誰都能寫代碼，但唔代表做出嚟嘅野好，所以 EPD 要做嘅變成為評審，確保代碼「足夠好」。呢度嘅「足夠好」有幾層含義：
- 從工程系統角度看架構是否合理：代碼係咪可擴展、高性能、夠健壯？
- 從產品角度看思考是否到位：呢個真係解決咗用戶嘅痛點？
- 從設計角度看是否好用：界面係咪易用、直觀？
初版代碼生成成本極低，大量原型湧現，成為討論評審嘅中心。問題係生成代碼太容易，令在做的項目數量急增，所有職能嘅瓶頸都轉移到評審。
角色轉變：通才崛起，每人必須有產品意識
通才—即係喺產品、工程同設計三方面都有唔錯感覺嘅人—以往已經好有價值，但編程 Agent 令佢哋更加如魚得水。原因是溝通係最難嘅部分，一個人如果能同時搞定三樣，就比三個人的團隊快，因為省掉溝通開銷。
通才比以往更有價值
使用編程 Agent 係必選項，因為上手唔難，而且你唔用就會俾用嘅人替代。產品經理可以直接做原型驗證想法，設計師可以直接喺代碼迭代，工程師可以將時間從實現轉向系統思考。
使用編程 Agent 是必選項
- 好的 PM 更好，差的 PM 更差：好嘅產品思維能做出有用嘅嘢，差嘅就會浪費大量評審時間。
- 每個人都需要產品意識：否則只會製造更多要評審嘅垃圾。
- 專業化的門檻更高：唔單止要喺自己領域出色，仲要評審速度快、溝通能力強。
好的產品思維比以往更有價值
系統思維：新世界嘅核心技能
喺一個執行成本極低嘅世界，系統思維成為真正嘅差異化能力。你應該專注於磨練系統思維，建立起自己所在領域嘅清晰心智模型：工程方面要清楚點樣設計服務架構、API 同數據庫；產品方面要理解用戶真正需要乜；設計方面要明白點解某個嘢用起嚟順手。
系統思維是需要磨練的核心技能
建設者 vs 評審者：你要揀邊一邊？
EPD 中正在形成兩類角色：建設者同評審者。建設者有唔錯嘅產品思維，能用編程 Agent，具備基本設計直覺，可以將小功能從想法做到上線，或者將大功能做好原型。
你要麼是建設者，要麼是評審者
- 建設者：適合快速迭代，需要提升產品同設計能力。
- 評審者：需要係自己領域嘅頂尖系統思維者，評審速度要快，適合專注深度架構同把關。
每個人覺得自己從編程 Agent 中受益最大，而且可能都冇講錯—因為出身背景變得冇咁重要，真係可以來自產品、設計或工程任何一個方向。真正嘅全才少之又少，但而家係做建設者嘅好時代。
每個人都覺得自己的角色從編程 Agent 中受益最大——而且都沒說錯
軟件公司嘅 EPD（工程 Engineering、產品 Product、設計 Design）存在嘅意義就係整出好嘅軟件。雖然分咗唔同角色，但最終目標一樣：整出能夠解決業務問題、用戶用得着嘅功能軟件。講到尾，產出就係代碼。呢一點一定要認清——因為編程 Agent 突然令寫代碼變得極之簡單。咁樣，EPD 嘅角色定位會點變？
流程嘅變化：
• PRD 已死 • 瓶頸由實現轉向評審 • PRD 萬歲
對角色嘅影響：
• 通才比以前更加有價值 • 使用編程 Agent 係必選項 • 好嘅 PM 更好，差嘅 PM 更差 • 每個人都需要產品意識 • 專業化嘅門檻更高咗 • 你要咪係建設者，要咪係評審者 • 每個人都覺得自己嘅角色係編程 Agent 度得益最大——而且都冇講錯
PRD 已死
PRD（產品需求文檔）曾經係 Claude 時代之前軟件開發嘅核心樞紐。EPD 嘅流程大致係咁樣：
• 有人（通常係產品經理）突然有個想法 • 產品經理寫一份 PRD • 設計師攞住 PRD 整出設計稿 • 工程師將設計稿變成代碼
呢個並唔係鐵律（喺初創公司，呢啲步驟通常會撈埋一齊，最叻嘅人可以同時做好幾件事），但呢個就係教科書式嘅標準做法。
之所以需要呢套流程，係因為寫軟件（同整設計稿）要花好多時間同心機。於是就有咗專門嘅分工。分工越細，跨部門溝通嘅需求就越大。PRD 就係一切嘅起點，將成個流程串連起嚟。接力棒傳到設計，將文字變成靚嘅 UI 同順暢嘅交互體驗。最後工程師將呢啲變成現實。
編程 Agent 顛覆曬呢一切。編程 Agent 可以將一個想法直接變成可以運行嘅軟件。當我（同好多人）話"PRD 已死"嗰陣，真正嘅意思係：呢種由寫 PRD 開始嘅傳統軟件開發方式，完結咗。
瓶頸由實現轉向評審
而家任何人都可以寫代碼，即係任何人都可以整到出嚟。但呢個唔代表整出嚟嘅嘢架構合理、解決咗正確嘅問題、或者好用。工程、產品同設計應該成為呢啲方面嘅評審者同把關人。問題係，Agent 生成嘅代碼並唔係成日都"夠好"。EPD 要做嘅嘢變咗係評審，確保代碼"夠好"。呢度嘅"夠好"有幾個層面嘅意思：
• 從工程系統角度睇架構係咪合理：代碼係咪可以擴展、高性能、夠穩陣？ • 從產品角度睇思考係咪到位：呢個真係解決咗用戶嘅痛點嗎？ • 從設計角度睇係咪好用：界面係咪易用、直觀？
初版代碼嘅生成成本極低，大量原型湧現出嚟。呢啲原型成為咗大家討論評審嘅中心，產品、工程同設計都圍住佢哋轉。
問題係——生成代碼實在太容易喇。以前寫代碼需要好長時間，作為評審者，手上需要睇嘅項目唔會太多。但而家任何人都可以寫代碼，進行緊嘅項目數量急劇增加。所有三個職能嘅瓶頸都轉移咗去評審——拎到原型之後確保佢哋夠好。
PRD 萬歲
Claude 之前嘅軟件開發方式（由 PRD 開始）已經成為過去。但描述產品需求嘅文檔依然不可或缺。
假設有人諗到一個點子，快速整咗個原型。下一步點上線？需要 EPD 其他成員嚟評審。喺呢個過程入面，一份文字說明總係有幫助嘅，而且往往必不可少。其他人評審嗰陣，點知代碼裏面某個地方係故意定係偶然寫出嚟？要睇意圖。總要有一個方法將意圖傳達清楚。
我認為傳統嘅 PRD 流程（PRD → 設計稿 → 代碼）已經死咗。但描述產品需求嘅文字本身依然活得好哋哋。喺交付評審之前，呢份文檔應該係原型嘅必備拍檔。
最標準嘅形式係一份文檔，但都有啲有意思嘅想法——例如將生成功能所用嘅 prompt 分享出嚟作為溝通方式。如果將來嘅 PRD 就係結構化嘅、帶版本管理嘅 prompt 呢？
通才比以前更加有價值
呢度講嘅通才，係指喺產品、工程同設計三方面都有唔錯感覺嘅人。呢啲人一直以嚟都好有價值、好有影響力——但係有咗編程 Agent，佢哋更加如魚得水。點解？
溝通係所有嘢入面最難嗰部分，佢拖慢曬一切。一個人如果可以同時搞掂產品、設計同工程，就比三個人嘅團隊快，因為省咗溝通開銷。
以前實現本身係瓶頸，通才都要同人溝通先可以搞掂啲嘢。而家佢哋只需要同 Agent 溝通就得。呢個意味住一個人單打獨鬥嘅影響力比以往任何時候都大。
使用編程 Agent 係必選項
編程 Agent 令實現成本極低，用佢哋就係必選項。用得好編程 Agent 嘅人可以獨自完成更多事情：
• 產品經理可以直接整原型驗證想法，唔使寫需求文檔然後乾等 • 設計師可以直接喺代碼度迭代，而唔係淨係喺 Figma 度畫圖 • 工程師可以將時間由實現轉向系統思考
用編程 Agent 係必選項，因為上手唔難，而且你唔用嘅話，就會俾用嘅人替代。
好嘅 PM 更好，差嘅 PM 更差
好嘅產品思維比以前更加有價值——你可以整出真正有用嘅嘢。差嘅產品思維比以前更加浪費。如果某人有一個差嘅產品想法，佢可以帶住一個原型出現——但呢個原型展示嘅係一個冇用、或者冇諗清楚嘅功能。呢啲原型而家需要更多人嚟評審——工程、產品、設計都要睇。呢個會吞噬大量時間同資源。而且上線嘅慣性更大咗（"嘢都整咗出嚟！直接合並啦！"）。產品好可能會因此變得更差或者更臃腫。
系統思維係需要磨練嘅核心技能
喺一個執行成本極低嘅世界裏面，系統思維成為咗真正嘅差異化能力。你應該專注於磨練系統思維，建立起自己所在領域嘅清晰心智模型：
• 工程：對點樣設計服務架構、API 同數據庫有清晰嘅心智模型 • 產品：對用戶真正需要啲乜（而唔係佢哋口講話想要乜）有清晰嘅心智模型 • 設計：對點解某個嘢用起嚟睇起嚟感覺就係啱嘅有清晰嘅心智模型
系統思維一直以嚟都好重要——咁變化喺邊？實現成本大幅下降咗。整出嘢比以前更加容易——但唔代表整出嚟嘅嘢就好。好嘅系統思維令你喺動手之前就可以確保方向正確，亦令你評審別人嘅工作時更有判斷力。兩方面都說明，系統思維嘅重要性提升咗。
每個人都需要產品意識
編程 Agent 仍然需要有人嚟俾指令佢，話俾佢知應該做啲乜。如果你令佢做錯嘢——你就係喺度俾別人製造更多等住評審嘅垃圾。知道應該令 Agent 做啲乜（即係"產品意識"），係一項基本要求，否則你會拖累成個組織。呢個對工程、設計同（顯然）產品都適用。
EPD 而家有好大一部分工作係評審原型。有產品意識，評審起嚟更加容易，甚至評審嘅係設計或工程方面嘅內容。冇產品意識，就需要一份超級詳細嘅產品文檔嚟配合原型。有產品意識，只需要一份簡要說明就可以理解功能嘅意圖，加速溝通、評審同交付。
專業化嘅門檻更高咗
你需要識用編程 Agent。你需要有產品意識。所有角色都喺度融合。
角色之間一直有重疊。設計同產品一向緊密相連——喺 Apple 同 Airbnb 呢啲公司，設計師本身就兼任產品經理。"設計工程師"（Design Engineer，同時有設計同工程能力嘅角色）喺 Vercel 等公司都越嚟越流行。
但專業化仍然有佢嘅空間。一個專注系統架構嘅資深工程師仍然好有價值。一個冇學憑感覺編程（Vibe Coding）但對客戶問題同應該做啲乜有超清晰心智模型嘅 PM 都係咁。一個能夠理解同設計用戶旅程與交互嘅設計師都一樣，就算仲係喺 Figma 度工作。
只係專業化嘅門檻高咗好多。你唔單止要喺自己嘅領域出類拔萃，仲要評審速度極快、溝通能力極強。而且呢類角色喺任何公司裏面都唔會太多。
你要咪係建設者，要咪係評審者
我哋見到 EPD 中正在形成兩類角色。
第一類：建設者。呢類人有唔錯嘅產品思維，可以用編程 Agent，具備基本嘅設計直覺。有咗護欄（測試套件、組件庫），佢哋可以將小功能由想法做到上線，將大功能整出可用嘅原型。
第二類：評審者。對於大型複雜嘅功能，需要 EPD 層面嘅深度評審。門檻好高——你必須係自己領域嘅頂尖系統思維者。而且你要快——要評審嘅嘢太多喇。
如果你而家係工程師——要咪將系統設計練到極致，能夠從容評審架構，向評審者方向發展；要咪提升產品同設計能力，成為建設者。
如果你做產品或設計——要咪建立起頂級嘅產品/設計心智模型，主要做評審；要咪投入編程 Agent，提升自己嘅編程功底。
有意思嘅係，角色正在坍縮，從上面嘅圖可以見到所有 EPD 嘅人都分佈喺呢張圖嘅某個位置。角色開始融合——工程師有咗更多時間，可以更多咁思考產品同設計；產品同設計都可以寫代碼喇。
每個人都覺得自己嘅角色由編程 Agent 度得益最大——而且都冇講錯
Twitter 上面有一條好好嘅帖子[1]，講嘅係邊啲人由編程 Agent 度得益最大：
一個對現有產品有直覺般理解嘅人——知道邊度係短板、邊度係亮點、以及點樣迭代令產品變得更鋒利。
呢種人最稀有嘅版本，企喺文化與深度技術嘅交叉點上。真正嘅"雙語者"。佢哋既知道技術上啲乜係可能嘅，又能夠分辨邊啲文化潮流係真實而唔係曇花一現。正正係呢種組合，決定咗一個產品令人覺得"理應如此"定係"拼湊而成"。
呢條帖子精準概括咗呢個新世界，引發咗唔少嘅傳播。佢之所以傳開，部分原因係每個讀到嘅人都覺得講嘅就係自己或者自己嘅角色。我見到產品人喺度轉發，設計師都喺度轉，設計工程師都喺度轉，創始人都喺度轉……每個人都覺得講嘅就係自己。
而佢哋好可能都冇講錯！我覺得呢個新世界令人興奮嘅地方在於，出身背景冇咁重要喇。我真心相信呢種人可以來自產品、設計或工程中任何一個方向。但呢個唔代表每個人都可以成為咁樣嘅人——講就容易做就難。真正嘅全才少之又少。
呢個係一個做建設者嘅好時代 :)
引用連結
[1] 好好嘅帖子: https://x.com/signulll/status/2030404483897815089
軟件公司的 EPD（工程 Engineering、產品 Product、設計 Design）存在的意義就是做出好軟件。雖然分了不同角色，但最終目標一樣：做出能解決業務問題、用戶用得上的功能軟件。說到底，產出就是代碼。這一點必須認清——因為編程 Agent 突然讓寫代碼變得異常簡單。那麼，EPD 的角色定位會怎麼變？
流程的變化：
• PRD 已死 • 瓶頸從實現轉向評審 • PRD 萬歲
對角色的影響：
• 通才比以往更有價值 • 使用編程 Agent 是必選項 • 好的 PM 更好，差的 PM 更差 • 每個人都需要產品意識 • 專業化的門檻更高了 • 你要麼是建設者，要麼是評審者 • 每個人都覺得自己的角色從編程 Agent 中受益最大——而且都沒說錯
PRD 已死
PRD（產品需求文檔）曾是 Claude 時代之前軟件開發的核心樞紐。EPD 的流程大致是這樣的：
• 有人（通常是產品經理）冒出一個想法 • 產品經理寫一份 PRD • 設計師拿着 PRD 做出設計稿 • 工程師把設計稿變成代碼
這並不是鐵律（在初創公司，這些步驟往往混在一起，最強的人能同時做好幾件事），但這就是教科書式的標準做法。
之所以需要這套流程，是因為寫軟件（和做設計稿）要花大量時間和精力。於是就有了專門的分工。分工越細，跨部門溝通的需求就越大。PRD 就是一切的起點，把整個流程串了起來。接力棒傳到設計，把文字變成漂亮的 UI 和流暢的交互體驗。最後工程師把這些變成現實。
編程 Agent 顛覆了這一切。編程 Agent 能把一個想法直接變成可運行的軟件。當我（以及很多人）說"PRD 已死"時，真正的意思是：這種從寫 PRD 開始的傳統軟件開發方式，終結了。
瓶頸從實現轉向評審
現在誰都能寫代碼，意味着誰都能把東西做出來。但這不代表做出來的東西架構合理、解決了正確的問題、或者好用。工程、產品和設計應該成為這些方面的評審者和把關人。問題在於，Agent 生成的代碼並不總是"足夠好"。EPD 要做的事變成了評審，確保代碼"足夠好"。這裏的"足夠好"有幾層含義：
• 從工程系統角度看架構是否合理：代碼是否可擴展、高性能、足夠健壯？ • 從產品角度看思考是否到位：這真的解決了用戶的痛點嗎？ • 從設計角度看是否好用：界面是否易用、直觀？
初版代碼的生成成本極低，大量原型湧現出來。這些原型成了大家討論評審的中心，產品、工程和設計都圍着它們轉。
問題是——生成代碼實在太容易了。過去寫代碼需要很長時間，作為評審者，手上需要看的項目不會太多。但現在誰都能寫代碼，在做的項目數量急劇增加。所有三個職能的瓶頸都轉移到了評審——拿到原型後確保它們夠好。
PRD 萬歲
Claude 之前的軟件開發方式（從 PRD 開始）已經成為過去。但描述產品需求的文檔依然不可或缺。
假設有人想到一個點子，快速做出了原型。接下來怎麼上線？需要 EPD 其他成員來評審。在這個過程中，一份文字說明總是有幫助的，而且往往必不可少。其他人評審時，怎麼知道代碼裏某個地方是有意為之還是偶然寫成的？得看意圖。總得有辦法把意圖傳達清楚。
我認為傳統的 PRD 流程（PRD → 設計稿 → 代碼）已經死了。但描述產品需求的文字本身活得好好的。在交付評審之前，這份文檔應該是原型的必備搭檔。
最標準的形式是一份文檔，但也有一些有意思的想法——比如把生成功能所用的 prompt 分享出來作為溝通方式。如果未來的 PRD 就是結構化的、帶版本管理的 prompt 呢？
通才比以往更有價值
這裏說的通才，是指在產品、工程和設計三方面都有不錯感覺的人。這些人一直都很有價值、很有影響力——但有了編程 Agent，他們更加如魚得水。為什麼？
溝通是所有事情中最難的部分，它拖慢一切。一個人如果能同時搞定產品、設計和工程，就比三個人的團隊快，因為省掉了溝通開銷。
過去實現本身是瓶頸，通才也得和別人溝通才能把事情做完。現在他們只需要和 Agent 溝通就行。這意味着一個人單打獨鬥的影響力比以往任何時候都大。
使用編程 Agent 是必選項
編程 Agent 讓實現成本極低，使用它們就是必選項。能用好編程 Agent 的人可以獨自完成更多事情：
• 產品經理可以直接做原型驗證想法，不用寫需求文檔然後乾等 • 設計師可以直接在代碼裏迭代，而不只是在 Figma 裏畫圖 • 工程師可以把時間從實現轉向系統思考
用編程 Agent 是必選項，因為上手並不難，而且你不用的話，就會被用的人替代。
好的 PM 更好，差的 PM 更差
好的產品思維比以往更有價值——你能做出真正有用的東西。差的產品思維比以往更浪費。如果某人有一個糟糕的產品想法，他可以帶着一個原型出現——但這個原型展示的是一個無用的、或者沒想清楚的功能。這些原型現在需要更多人來評審——工程、產品、設計都得看。這會吞噬大量時間和資源。而且上線的慣性更大了（"東西都做出來了！直接合並吧！"）。產品很可能因此變得更差或更臃腫。
系統思維是需要磨練的核心技能
在一個執行成本極低的世界裏，系統思維成了真正的差異化能力。你應該專注於磨練系統思維，建立起自己所在領域的清晰心智模型：
• 工程：對如何設計服務架構、API 和數據庫有清晰的心智模型 • 產品：對用戶真正需要什麼（而非他們嘴上說想要什麼）有清晰的心智模型 • 設計：對為什麼某個東西用起來看着感覺就是對的有清晰的心智模型
系統思維一直都很重要——那變化在哪？實現成本大幅下降了。做出東西比以往更容易——但不代表做出來的就好。好的系統思維讓你在動手之前就能確保方向正確，也讓你評審別人的工作時更有判斷力。兩方面都說明，系統思維的重要性提升了。
每個人都需要產品意識
編程 Agent 仍然需要有人來給它下指令，告訴它該做什麼。如果你讓它做了錯誤的東西——你就是在給別人製造更多待評審的垃圾。知道該讓 Agent 做什麼（也就是"產品意識"），是一項基本要求，否則你會拖累整個組織。這對工程、設計和（顯然）產品都適用。
EPD 現在有很大一部分工作是評審原型。有產品意識，評審起來更容易，哪怕評審的是設計或工程方面的內容。沒有產品意識，就需要一份超級詳細的產品文檔來配合原型。有產品意識，只需要一份簡要說明就能理解功能的意圖，加速溝通、評審和交付。
專業化的門檻更高了
你需要會用編程 Agent。你需要有產品意識。所有角色都在融合。
角色之間一直有重疊。設計和產品向來緊密相連——在 Apple 和 Airbnb 這樣的公司，設計師本身就兼任產品經理。"設計工程師"（Design Engineer，兼具設計和工程能力的角色）在 Vercel 等公司也越來越流行。
但專業化仍然有它的空間。一個專注系統架構的資深工程師仍然很有價值。一個沒學憑感覺編程（Vibe Coding）但對客戶問題和該做什麼有超清晰心智模型的 PM 也是如此。一個能理解和設計用戶旅程與交互的設計師也一樣，哪怕還是在 Figma 裏工作。
只是專業化的門檻高多了。你不僅要在自己的領域出類拔萃，還要評審速度極快、溝通能力極強。而且這類角色在任何公司裏都不會太多。
你要麼是建設者，要麼是評審者
我們看到 EPD 中正在形成兩類角色。
第一類：建設者。這類人有不錯的產品思維，能用編程 Agent，具備基本的設計直覺。有了護欄（測試套件、組件庫），他們可以把小功能從想法做到上線，把大功能做出可用的原型。
第二類：評審者。對於大型複雜的功能，需要 EPD 層面的深度評審。門檻很高——你必須是自己領域的頂尖系統思維者。而且你得快——要評審的東西太多了。
如果你現在是工程師——要麼把系統設計練到極致，能從容評審架構，朝評審者方向發展；要麼提升產品和設計能力，成為建設者。
如果你做產品或設計——要麼建立起頂級的產品/設計心智模型，主要做評審；要麼投入編程 Agent，提升自己的編程功底。
有意思的是，角色正在坍縮，從上面的圖可以看到所有 EPD 的人都分佈在這張圖的某個位置。角色開始融合——工程師有了更多時間，可以更多地思考產品和設計；產品和設計也能寫代碼了。
每個人都覺得自己的角色從編程 Agent 中受益最大——而且都沒說錯
Twitter 上有一條很好的帖子[1]，講的是什麼樣的人從編程 Agent 中受益最大：
一個對現有產品有直覺般理解的人——知道哪裏是短板、哪裏是亮點、以及如何迭代讓產品變得更鋒利。
這種人最稀有的版本，站在文化與深度技術的交叉點上。真正的"雙語者"。他們既知道技術上什麼是可能的，又能分辨哪些文化潮流是真實的而非曇花一現。正是這種組合，決定了一個產品讓人感覺"理應如此"還是"拼湊而成"。
這條帖子精準概括了這個新世界，引發了不小的傳播。它之所以傳開，部分原因是每個讀到的人都覺得說的就是自己或自己的角色。我看到產品人在轉發，設計師也在轉，設計工程師也在轉，創始人也在轉……每個人都覺得說的就是自己。
而他們很可能都沒說錯！我覺得這個新世界令人興奮的地方在於，出身背景不那麼重要了。我真心相信這種人可以來自產品、設計或工程中的任何一個方向。但這不意味着每個人都能成為這樣的人——說起來容易做起來難。真正的全才少之又少。
這是一個做建設者的好時代 :)
引用連結
[1] 很好的帖子: https://x.com/signulll/status/2030404483897815089