[AI 分享] PDF型RAG處理思路

 [AI 分享] PDF型RAG處理思路

摘要 : PDF做RAG不能只轉文字切片，重點在辨識類型、保留結構、語意切分、可追溯引用與多工具協作。

內容:

當 agent 做 RAG 時，知識庫裡是一堆 PDF 該怎麼處理，不能只回答「先轉文字、再切片、再丟向量庫」。這種答案太表面，因為真實專案裡的 PDF 往往不是乾淨的純文字，而是充滿各種複雜結構與格式問題。

實務上，PDF 可能是合約、財報、掃描件、技術文件，裡面會包含條款、表格、圖表、圖片、雙欄排版、流程圖、程式碼區塊、註腳、頁首頁尾等內容。若直接把它當成一般文本抽取，後續很容易出現切片斷裂、表格結構混亂、頁首頁尾重複召回、圖片資訊遺失等問題。最終模型雖然能回答，但常常無法正確引用原文，來源也難以對應。

這題真正考的，不是會不會把 PDF 存進向量庫，而是有沒有理解 PDF 型 RAG 的難點在於：能不能正確讀懂、正確切分、正確引用。

第一步是先判斷 PDF 類型，而不是急著抽文字。若是原生文字型 PDF，例如說明書、產品文件、論文，可以直接做文字解析；若是掃描型 PDF，例如紙本合約、發票或拍照轉成的檔案，就必須先透過 OCR 做文字辨識；若是圖文混排、表格密集或含大量流程圖與截圖的 PDF，就不能只靠文字抽取，而要搭配版面分析、視覺理解，甚至多模態模型一起處理。因為一開始類型判斷錯了，後面的切片、檢索與回答都會跟著失真。

第二步是盡量還原文件結構。PDF 處理很常見的錯誤，就是把整份文件抽成一大段純文字，這樣雖然快，但會犧牲掉很多關鍵上下文。例如合約中的章節、條款、附件編號，或財報中的表格名稱、年份、指標欄位，這些資訊如果遺失，模型即使抽到一句內容，也不知道它屬於哪一頁、哪一章、哪一個條文，自然難以驗證與追溯。

因此在生產環境中，應盡量保留頁碼、標題層級、章節關係、段落邊界、表格位置、圖片說明、註腳與頁首頁尾等結構資訊。更重要的是，每一段內容都要知道自己在原文中的位置，這樣後續才能支援引用、校驗與來源追蹤。

第三步是按語意切片，而不是機械式固定字數切分。很多人習慣每 500 字或 800 字切一段，但 PDF 的內容通常不適合這樣做。標題和正文不能隨便拆開，合約條款最好保持完整，表格也不能當一般段落切開，圖表內容更不能直接忽略。

更好的方式是根據語意與結構切分，例如同一標題下的數個段落可以組成一個 chunk，合約中的單一條款盡量完整保留，表格可以單獨轉為結構化文本，圖表則可先生成摘要，再連同頁碼與標題一起保存。每個 chunk 都應附上 metadata，例如文件 ID、頁碼、章節標題、條款編號、表格編號、圖片描述與版本時間等，讓檢索結果不只是孤立句子，而是帶著上下文與來源資訊的內容單元。

若要做得更精細，還可以為每個 chunk 補充一段上下文說明，例如註記這段內容來自某份合約的付款條款，主要說明尾款支付條件。這樣模型在檢索回來後，不只看到片段，還能更快理解它在整份文件中的語意角色。

第四步才是 agent 層的工具設計。到了 agent 使用階段，不建議把整份 PDF 一次塞進上下文，這樣既浪費 token，也容易讓模型抓不到重點。更合理的方法，是把 PDF 處理能力拆成多個工具，讓 agent 根據問題類型按需呼叫。

例如可以設計 Search PDF 來做片段檢索，Read Page 用來讀取指定頁內容，Extract Table 專門抽取表格，Chart Analysis 或視覺分析工具用來理解圖表，Citation Source 則負責返回頁碼與原文引用。這樣當使用者問簡單問題時，agent 可以先檢索相關段落；當使用者問跨年度比較、數據變化趨勢等複雜問題時，agent 就能進一步定位章節、抽取表格、做整理與歸納；如果問的是流程圖或圖片內容，就要交給視覺分析工具，而不是只靠文字搜尋。

回答這題，最後最好補充生產級細節：PDF 型 RAG 一定要做到可追溯引用，也一定要建立評測機制。回答內容最好附上頁碼、章節、原文片段，甚至表格編號，否則模型說得再自然，也很難確認它是不是憑空編造。

而評測也不能只看最後答案對不對，還要往下拆成更細的品質指標，例如檢索片段是否正確、頁碼是否準確、表格有沒有被解析錯亂、OCR 是否漏字、圖表資訊是否被正確理解、原文引用是否真的能支撐最終回答。這些細節，才是真實業務裡最容易出問題的地方。

總結來說，這題的成熟回答不是「PDF 轉文字後向量化」而已，而是先辨識 PDF 類型，再選擇合適的解析方式；接著保留文件結構，依語意進行切片；對表格、圖片與圖表做專門處理；最後讓 agent 透過工具鏈按需檢索、讀頁、抽表、看圖，並全程保留引用與評測閉環。這樣的回答，才能讓面試官知道你不是只做過簡單 demo，而是真的理解 PDF RAG 在生產環境中的核心難點。

[AI 分享] 吳恩達AI Agent課程重點整理

 [AI 分享] 吳恩達AI Agent課程重點整理

摘要 : 濃縮吳恩達8小時AI Agent課程，快速理解什麼是Agent、如何搭建，以及最常被忽略的評估關鍵。

內容:

這次內容主要是把吳恩達釋出的 AI Agent 完整課程重點濃縮整理，幫大家省下八小時的學習時間。即使你不會寫程式、沒有技術背景，只要平常有在使用 ChatGPT、Gemini 這類 AI 工具，也能透過這份整理快速掌握核心觀念。

首先，AI Agent 其實沒有很多人想像中那麼複雜。最簡單的理解方式，就是替 AI 加上「自己做決定」和「使用工具」的能力。過去的大語言模型通常是你問一句、它答一句，任務到此結束；但 Agent 不一樣，它可以自己拆解任務、決定步驟、選擇工具，逐步完成整件事。

整個概念可以分成三個層次來理解。第一層是大語言模型，也就是我們熟悉的 ChatGPT、Claude、Gemini。這類模型的特點是輸入問題、輸出答案，但它有兩個限制：第一，它不知道你的個人資料或外部即時資訊；第二，它是被動的，你不下指令，它就不會主動行動。

第二層是 AI Workflow，也就是 AI 工作流。這一層是在大語言模型上增加固定步驟，讓 AI 在回答問題前，先去查日曆、待辦事項或其他資料來源。這樣它能回答得更準確，但本質上仍然只是照著你事先設定好的流程走。只要真正做決策的人還是你，那它就還不算 Agent。像常聽到的 RAG，本質上也是一種先查資料再生成答案的工作流。

第三層才是真正的 AI Agent。從 Workflow 升級到 Agent 的核心差異，在於「做決定的人從你變成 AI」。你不需要替它規劃每一個步驟，只要告訴它最終目標，例如幫你完成一份週報，它就會自己決定去哪裡蒐集資料、怎麼整理內容、是否需要檢查品質，甚至反覆修改直到結果夠好為止。

這裡有一個重要概念叫做 ReAct，也就是 Reasoning 加上 Action，代表推理與行動。真正的 AI Agent 必須同時具備這兩種能力：先想清楚怎麼做，再實際去做。它不只是會回答問題，更能採取行動、使用工具、持續迭代。

如果要搭建一個 AI Agent，核心可以拆成三塊積木。第一塊是模型 Model，也就是 AI 的大腦，負責理解、推理、產生內容。第二塊是工具 Tool，也就是讓 AI 能與外部世界互動的能力，例如查詢資料庫、讀取日曆、存取訂單系統、發送訊息等。第三塊則是評估 Evaluation，負責檢查結果品質、替輸出打分，判斷任務是否真的完成得夠好。

其中，工具的作用特別容易從實際場景看出來。以電商客服為例，當客戶反映尺寸寄錯，AI 模型本身可以先理解訊息內容，抓出關鍵資訊；接著需要透過工具連接後台系統，查詢訂單、物流與庫存；最後再利用模型撰寫回覆，並透過另一個工具把訊息真正發送出去。這就是模型與工具互相配合的完整過程。

而整份內容最重要的一個提醒，就是大多數人最容易忽略的「評估」。很多人在談 AI Agent 時，只關注模型夠不夠強、工具接得多不多，卻忽略了最後怎麼判斷結果是好還是不好。其實評估才是讓 Agent 能真正穩定運作的關鍵，因為沒有評估，AI 就無法知道自己是否做對、是否需要修正，也無法持續提升表現。

總結來說，AI Agent 的本質不是神秘的新技術，而是讓 AI 從單純回答問題，升級成能自主思考、使用工具並完成任務的系統。理解它的最好方式，就是先分清楚大語言模型、工作流與 Agent 的差異，再掌握模型、工具、評估這三大核心結構。只要把這些概念搞懂，你就已經具備進一步實作 AI Agent 的基礎了。

[AI 分享] Codex三種電腦操控方式解析

 [AI 分享] Codex三種電腦操控方式解析

摘要 : 一文看懂Codex的Computer Use、Chrome擴充套件與內建瀏覽器差異，快速選出最適合自己的使用方式。

內容:

OpenAI開發者體驗工程師、前Meta資料科學家 Jason Liu 近期分享，Codex 目前有三種主要方式可以操控電腦執行任務，分別適合不同場景。理解它們的能力邊界，才能真正發揮 AI Agent 的效率。

第一種是 Computer Use，這是目前 Codex 在操控電腦方面能力最強、應用範圍最廣的方式。它可以模擬使用者在電腦上的大部分操作，只要是滑鼠能點、鍵盤能輸入的地方，理論上都能處理。不論是微信、飛書，還是 Excel 等桌面軟體，甚至跨多個應用切換，它都能執行。

Jason Liu 分享了一個實際案例：有次他的包裹被偷，但亞馬遜客服排隊等待時間長達 25 分鐘，於是他讓 Codex 每 5 分鐘檢查一次客服視窗，等客服即將接通後再改成每分鐘檢查，並嘗試完成退款申請。等他回來時，退款流程已經處理完成。這顯示出 Computer Use 很適合接手那些繁瑣、耗時、必須盯著流程的任務。

不過，Computer Use 也有明顯限制。由於它每一步都需要先理解畫面，再判斷位置、進行操作，因此速度相對較慢。這種方式不適合追求極致效率的情境，但很適合那些沒有 API、沒有外掛、只能依靠圖形介面完成的工作。

第二種是 Codex Chrome 擴充套件，這類方式更適合發生在瀏覽器中的任務，尤其是需要登入狀態的網站，例如飛書文件、淘寶商家後台、B站創作中心等。這些平台依賴使用者當前的帳號登入資訊，而 Chrome 擴充套件可以直接基於你已登入的瀏覽器環境進行操作。

它和 Computer Use 最大的不同在於，Computer Use 是透過「看螢幕、點按鈕」來完成任務，而 Chrome 擴充套件則是直接進入瀏覽器工作流。它能讀取網頁內容，也能在多個分頁之間切換，例如先查資料、再交叉比對、最後整理輸出結果。因此，在純瀏覽器場景下，Chrome 擴充套件通常會比 Computer Use 更快、更準確。

Jason Liu 表示，他自己經常使用 Chrome 擴充套件來檢查私訊、瀏覽新聞、蒐集回饋，並將有價值的內容整理儲存到本地檔案，方便後續反覆查看。不過，這種方式的權限也更敏感，因為它使用的是你的真實登入狀態，所以網站會將所有點擊、輸入與提交視為你本人操作。因此，資訊蒐集、內容整理可以交給它，但像傳送訊息、確認付款這類高風險動作，仍建議由使用者自行確認。

第三種是內建瀏覽器，這種方式更偏向開發者使用，特別適合做網頁開發、前端頁面預覽與本地工具除錯。例如當你正在開發一個前端頁面時，可以讓 Codex 開啟本地預覽網址，檢查版面配置是否正常、按鈕是否錯位、手機端是否有溢位問題。檢查完成後，它還可以直接修改程式碼，再重新打開頁面驗證結果。

內建瀏覽器最有價值的地方，在於它把「寫程式碼」與「看結果」串接成一個完整流程。因此，它不是拿來登入網站或處理帳號任務的工具，而更像是 Codex 在開發與介面除錯時的專屬工作台。

如果要快速選擇使用方式，可以這樣理解：需要登入狀態的網站任務，優先使用 Chrome 擴充套件；需要操作桌面軟體，或在多個應用之間切換時，選擇 Computer Use；需要開發網頁、預覽頁面、除錯介面時，則使用內建瀏覽器。

Jason Liu 也特別提醒，如果任務本身可以透過外掛、MCP 或 API 等結構化工具完成，應優先選擇這些方式。像是讀取飛書文件、整理線上表格，如果能直接呼叫介面，通常會比讓 Codex 透過畫面模擬點擊來得更準確、更高效。

這也說明了一個重要觀點：Codex 操控電腦不是越像人越厲害，而是越能根據任務選對入口越強。真正高效的 Agent，不是接到任務就盲目點滑鼠，而是知道什麼時候該用 API，什麼時候該進瀏覽器，什麼時候該接管桌面。

從這個角度來看，Codex 早已不只是寫程式碼的工具，而是逐漸成為一套圍繞電腦、瀏覽器與本地專案運轉的任務執行系統。對想提升效率的人來說，重點不只是會不會用 AI，而是能不能根據任務場景，挑對最合適的工具入口。

[AI 影響] AI程式碼審查失效危機

 [AI 影響] AI程式碼審查失效危機

摘要 : AI大幅提升產碼速度，卻讓人類審查跟不上，傳統Code Review正失效，團隊需改用分層與證據驅動審查。

內容:

這裡主要在談一個越來越明顯的現象：團隊裡使用 AI 寫程式的人愈來愈多，產出速度暴增，但人類審查程式碼的能力並沒有同步提升。結果就是，面對動輒幾百上千行的 diff，很多人其實已經無法真正看完，只能草草 approve。這不是工程師變懶，而是既有的審查機制正在被 AI 的產出速度壓垮。

過去 50 年，程式碼審查之所以能有效運作，關鍵原因其實很簡單：人類寫程式很慢。因為寫得慢，審查者才有時間在合理成本下讀完程式碼，順便找 bug、討論架構、傳承知識，形成健康的協作閉環。但現在不同了，只要對 AI 工具下個指令，幾秒鐘就能生成上千行程式碼。機器產出的速度翻了好幾十倍甚至上百倍，但人類閱讀與理解程式碼的速度並沒有改變，傳統 PR 流程因此開始失靈。

幾組工業界數據來說明問題的嚴重性。Ferros AI 追蹤 4000 個團隊、22000 多名開發者後發現，深度採用 AI 之後，程式碼變動率暴增 861%，而審查時間也增加了 441.5%。更驚人的是，有 31.3% 的 PR 幾乎沒有經過任何人類審查，就直接合進主分支。結果缺陷率從 9% 升到 54%，正式環境事故率提高了 2.4 倍。GitClear 的分析也指出，雖然 AI 讓程式碼量增加到原本的四倍，但實際業務價值只增加 12%。也就是說，團隊付出了大量閱讀與維護成本，換來的卻不一定是對等的價值提升。

為什麼 AI 生成的程式碼常常比人類初學者的程式碼還難審。第一個原因是「意圖與推理過程的消失」。人類寫程式時，背後通常有設計理由與取捨脈絡，審查時還能口頭補充；但 AI 在產出最終程式碼後，這些思考過程往往不會完整保留下來，審查者只能從結果反推它的意圖。第二個原因是 AI 擅長局部最佳化，卻缺乏完整的業務上下文與組織默契。它可能在技術上可行，但未必符合系統長期演進方向。第三個原因是 AI 很會寫「看似合理但實際空洞」的程式碼，包含過度包裝、冗長防禦性設計與華麗但低價值的實作，讓審查者需要花更多力氣辨識真正重要的邏輯。

面對這種情況，認為不能再用單一標準看待所有團隊，而要根據系統的「爆炸半徑」來決定審查策略。也就是說，這段程式碼一旦出錯，影響有多大？這套系統要維護多久？是否涉及高風險業務？這些因素才是決定審查方式的核心。

針對不同團隊型態，內容整理出三種策略。第一種是單人開發者或原型驗證專案。這類場景下，程式碼審查的知識共享價值不高，應把重心放在自動化測試上，不要把時間浪費在形式化審查或風格細節上。但前提是測試要足夠扎實，否則等於只是延後爆雷。

第二種是多數人所在的成長型團隊。這類團隊已有真實使用者，也需要多人共同維護程式碼，因此要採取「分層審查」。機器負責重複性高的髒活，例如靜態分析、安全掃描、CI/CD 自動檢查；人類則聚焦在真正高價值的部分，包括核心業務邏輯是否正確、架構是否被帶偏、知識是否有同步傳遞。高級工程師不應該把時間花在逐行檢查 AI 生成的小細節，而應該去判斷那些程式碼是否真的有存在必要。

第三種是企業級重型系統，例如核心交易鏈路、金融支付或高風險基礎設施。這類系統不能只收程式碼，必須要求「證據驅動審查」。也就是說，若使用 AI 產生 PR，就應附上決策日誌，例如 decision log.md，把推理脈絡、備選方案、取捨原因一起交出來。若只有程式碼、沒有說明，就不應該直接 merge。因為在高風險系統中，光看結果遠遠不夠，審查者還必須理解背後決策。

除了調整審查策略，內容還提出一個很關鍵的實作方向：用 AI 來審查 AI，也就是所謂的 loop engineering。既然機器生成程式碼的速度太快，那就應該在 CI 流程中加入專門的 review agent，讓它先根據團隊的架構規範、設計原則與常見風險，自動檢查 PR 是否違規、是否引入壞味道、是否偏離既定架構。這樣一來，人類工程師在正式看到 PR 之前，已經有一層機器初審幫忙過濾，能有效減少那些表面工整、實際價值不高的 AI 垃圾程式碼。

最後，內容點出一個值得反思的結論。很多人擔心 AI 把寫程式的門檻拉低，會讓程式設計師失業；但真正有價值的能力，從來不是「把程式碼敲進電腦」本身，而是如何判斷一段程式碼能不能被信任、是否符合業務需求、會不會傷害系統長期穩定性。當 AI 讓產碼變得廉價，人類工程師真正重要的角色，反而會更集中在判斷、取捨、審查與系統思維上。

[AI 影響] AI時代下普通人的生存與應對

 [AI 影響] AI時代下普通人的生存與應對

摘要 : AI正重塑教育、就業與分配制度，普通人需趁視窗期轉換思維，從舊式教育路徑轉向更適合AI時代的生存策略。

內容:

關於「為什麼沒人討論高考了」的討論，進一步回應觀眾最關心的問題：當AI正在改變教育與就業市場時，普通人究竟該怎麼辦。作者指出，上一期節目主要談的是現象，這一次則希望補上「應對方案」，前半段談世界將出現的變化，後半段則聚焦普通人的實際處境。

先回顧了Anthropic執行長達里奧提出的「地靈世界理論」。其核心意思是，未來可能出現一小群與AI深度綁定的人，他們掌握模型、算力、資本、資料與工作流，逐漸形成一個與普通社會脫鉤的新經濟體。這個經濟體的增長速度可能遠超外部世界，而最令人不安的不只是成長差距，而是少數富人可能首次在歷史上不再需要大多數普通人的勞動力。

接著，文章引用幾個例子說明這種趨勢並非空想。像Shopify內部已經將AI使用視為基本要求，甚至在增加人手之前，團隊必須先證明AI無法完成工作。這顯示企業的基本邏輯正在改變：從過去忙不過來就招人，變成先用AI替代，只有AI實在做不到才考慮增加員工。這代表未來新工作機會可能會越來越少。

AI公司真正想吃下的市場，並不只是傳統SaaS訂閱收入，而是整個白領薪資池。客服、程式設計師、法務、分析師、助理、營運等職位，都是AI優先瞄準的領域。換句話說，AI產業龐大的資本投入，最終很可能要靠替代大量白領工作來回收，這也是為什麼白領會成為第一輪受衝擊最深的群體。

進一步強調，這次AI革命與過往技術革命最大的不同，在於它不只是替代工作方式，而是開始動搖教育本身的價值。過去的技術革命雖然淘汰了一些工作，但也透過提高教育門檻，讓人們可以學習新技能、進入新的產業。也就是說，過去是「用教育換效率」，人類仍能透過學習追上技術進步，建立新的職業壁壘。

但這一次不同。AI正在吞噬的正是那些過去透過教育累積起來的白領能力與知識技能。這意味著，傳統的讀書、升學、找穩定工作這條路，未來可能不再像過去那樣有效。問題不只是某個工作被取代，而是整套把人訓練成標準化勞動者的教育系統，正在失去原本的功能。

在這樣的背景下，未來社會勢必要面對新的分配問題。若AI持續提升生產力，卻讓大量人失業，而社會又沒有建立新的兜底機制，那麼貧富差距與社會情緒只會持續惡化。文章特別提到，全球已開始出現對全民基本收入（UBI）、AI稅等制度的討論與試點，像韓國、英國、愛爾蘭、威爾士、美國、加拿大等地，都曾針對特定群體發放現金補助或進行基本收入試驗。

這些政策背後的邏輯，不只是福利擴張，而是為了防止AI失業潮引發極端政治後果。當大量人被排除在生產體系之外，又看見極少數人因AI累積驚人財富，社會很容易產生強烈的嫉妒、怨恨與失控感，進而催生極左政治、共產主義回潮，甚至更激烈的社會衝突。作者強調，共產主義運動往往不是從嚴密理論出發，而是源自「憑什麼你有而我沒有」的情緒爆發。

不過，單靠發錢並不能解決所有問題。即使AI讓生產效率提升、商品與服務變便宜，也不代表普通人一定能立刻受惠。因為現實中許多昂貴的東西，像房地產、教育認證、土地、牌照與金融資源，其價格並不是單純由技術成本決定，而是由制度性稀缺所支撐。技術可以把蛋糕做大，但不能自動決定蛋糕如何分配，因此制度改革仍是無法迴避的問題。

在談到普通人該如何應對時，一個重要判斷：雖然在AGI真正完全成熟後，很多傳統努力可能會變得無效，但現在還沒走到那一步，仍存在一段關鍵視窗期。在這段期間內，努力仍然有意義，只是不能再沿用舊的教育與成長邏輯。

真正失效的不是所有努力，而是舊式教育路線。過去的教育系統，本質上是在培養標準化、服從性高、適合分工體制的打工者：當好學生、考好學校、聽老師的話、進入職場後聽領導的話，盡量規避風險，做好分內工作。但AI時代最先淘汰的，恰恰就是這種只會完成分內任務的「螺絲釘型人才」。

因此，對普通人來說，最重要的第一步，就是拋棄舊有教育體系灌輸的單一路徑依賴，不要再把全部生命押注在傳統升學、考證、進大公司、求穩定這套模式上。因為這條路曾經有效，是建立在工業時代與白領時代的制度背景之上，但面對AI時代，它的風險正在急速上升。

整體來看，核心訊息是：AI帶來的不只是產業升級，而是對教育、工作與社會分配制度的全面重構。對普通人而言，最危險的不是不夠努力，而是仍用過去的邏輯理解未來。真正有價值的，不是固守舊秩序，而是在AI全面接管之前的有限時間裡，盡快完成思維轉向與路徑切換。

[AI 衝擊] OPC時代：一個人也可能做出十億美元公司

 [AI 衝擊] OPC時代：一個人也可能做出十億美元公司

摘要：AI正重塑公司形態，一人公司崛起，關鍵不在工具，而在發現真問題並完成可落地交付。

內容：

就在昨天，人工智慧加生態大會 AIEC 2026 於北京中關村展示中心落幕，但真正引發熱議的，反而是會後持續升溫的一個話題：未來是否可能出現一家估值 10 億美元、卻只由一個人運作的公司？

這裡所說的，不是個人開店，也不是單打獨鬥做自媒體，而是一個人借助 AI 完成程式開發、產品設計、行銷推廣、資料分析、客服交付等多項工作，最終跑出一家真正意義上的大型企業。這個想法乍聽像科幻，但 OpenAI 執行長奧特曼早已將它帶到公眾視野，甚至提到矽谷科技 CEO 圈子裡，已經有人在討論甚至下注：第一家「一人十億美元公司」究竟會在哪一年出現。

Anthropic 創辦人阿莫迪也提出更激進的判斷。他認為，隨著 AI 工具持續自動化行銷、資料分析、程式開發與營運管理，一個人或極小團隊打造巨型公司的可能性正在快速上升。真正值得警惕的，不只是「一個人能賺多少錢」，而是「公司」這種組織形式本身，正在被 AI 重新拆解。

過去創業，通常得先找合夥人、招員工、租辦公室、建立財務與營運機制，再去做產品和跑銷售。換句話說，創業者往往不是先做生意，而是先搭起一家公司。但現在，AI 正把許多原本屬於組織內部的能力，變成可隨時調用的工具。從 AI 程式碼助手、低程式碼平台，到大模型做需求拆解、文件生成、銷售話術撰寫、客戶回饋分析，一整套工具已能頂上半個團隊。

因此，「一人公司」的真正含義，不是一個人變成超人，而是一個真正懂行業的人，第一次有機會調動一支看不見的隱形公司。這就是 OPC，One Person Company 的核心概念。

這次大會後，OPC 的討論熱度被推到新高。而最具衝擊力的案例，不是來自網路產品或寫字樓，而是來自水泥廠。年輕創業者韓嘉樂，將 AI 帶入了一座傳統水泥工廠。那裡沒有炫目的發表會場景，只有原料堆場、預熱器、粉塵、生產線，以及老師傅多年累積的工藝經驗。

水泥廠最難的地方，在於原料品質每天都在變，但結果卻不會立刻顯現。很多配料與工藝調整，長期依賴老師傅的經驗判斷。這些經驗非常珍貴，卻也極難複製。韓嘉樂團隊做的事情，就是把這個「經驗黑箱」拆開，將產線資料、原料變化、品質預測、配方建議、人工確認與執行回饋串成一個完整閉環。根據公開報導，這套為水泥廠定製的智慧體，能幫助尋找更優的原料配比，並帶來年化上千萬元等級的成本節約。

這正是 AI 最令人震撼的地方。它不只會寫詩、畫圖、聊天，也正在進入最傳統、最重資產、最不性感的產業，並且一進去就開始改寫成本結構。

這件事的重要性在於，它提醒人們：未來的大機會，不一定在最熱鬧的風口，也不一定是下一個聊天機器人、短影音工具或 AI 繪圖網站。真正的大機會，可能藏在那些大公司看不上、傳統團隊做不快、而行業專家又缺乏技術工具的細分場景裡。

例如水泥廠的配料優化、醫院科室的文件流程、跨境賣家的選品系統、律師團隊的合約審查、花植養護機器人的情緒陪伴，或是把五線譜轉成簡譜的音樂工具。這些需求看似很小，小到大公司未必願意投入，但它們又足夠真實，真實到用戶願意付錢。這就是 OPC 的機會：不是做大而全的平台，而是做小而硬、能直擊需求的刀片型產品，直接切入真實場景與真實現金流。

從經濟學角度來看，科斯在 1937 年提出過經典問題：公司為什麼存在？他的答案大意是，因為市場交易有成本，將人組織進公司內部，有時比每次都去外部協作更有效率。但今天，這個問題正在被反轉。如果 AI 持續壓低協作成本、溝通成本、試錯成本與轉移成本，公司是否會變小？答案很可能是會，但不是所有公司都會消失，而是組織形態將開始分層。

未來，大公司仍會負責平台、基礎設施與生態建設；中型公司仍會做系統化交付；而大量超級個體與小團隊，則會像毛細血管一樣深入無數垂直場景，解決過去沒人願意做、也沒人能以低成本做的問題。

這也是為什麼中關村成為這場 OPC 討論的重要樣本。這裡同時具備算力、模型、開發者、資本、產業客戶與孵化社群等條件。公開報導指出，中關村 AI 北偉社群已吸引多個早期專案入駐，涵蓋 AIGC、能源、工業供應鏈、生物醫藥等領域。截至 2026 年 6 月，OPC 專案累計申請報名達 322 家，通過評審並正式入駐社群的超過 70 家。

這代表中國版 OPC 並不是一個人關在房間裡單打獨鬥，而更像是一個人站在完整生態之上創業。背後有雲端服務、模型能力、智慧體、開源社群、產業客戶與政策支持共同托舉。

但這裡也必須潑一盆冷水。一人公司，不等於一個人隨便問問 AI 就能輕鬆成功。AI 降低的是執行成本，不會替你承擔結果責任；AI 壓縮的是轉譯成本，不會替你補齊行業認知；AI 能幫你寫程式碼，卻不能保證你真的理解客戶；AI 能幫你做方案，卻不能保證方案一定落地；AI 能幫你生成產品，也不能保證市場一定願意付費。

因此，在 OPC 時代，最稀缺的能力不是「會不會用 AI」，而是三件事。

第一，你能不能發現一個足夠真實的問題。  

第二，你能不能把這個問題拆成 AI 可以執行的任務。  

第三，你能不能對最後的結果負責。

而其中最關鍵的，就是「拆問題」的能力。如果再往下深挖，會發現這其實是一個極簡的三步閉環。

第一步，把模糊的客戶痛點，轉譯成 AI 能精確理解的結構化指令，而不是籠統發問。  

第二步，讓 AI 批量生成多個粗顆粒度的解決路徑，再用自己的行業判斷快速做減法，砍掉最虛、最不實際的方案。  

第三步，只挑最有希望的一條，去做最小可行性驗證，並用真實客戶的付費意願或回饋資料，倒逼 AI 與產品持續迭代。

只要這三步打通，就完成了從想法走向產品的關鍵躍遷。絕大多數人卡住，不是因為不會問 AI，而是根本不知道自己到底要解決什麼問題，或者把問題描述得連人類同事都聽不懂。

這也是韓嘉樂水泥廠案例最值得普通創業者學習的地方。他不是坐在辦公室裡空想「我要顛覆水泥行業」，而是真正走進現場，理解原料、理解工藝、理解老師傅，也理解工廠為什麼願意為一個小優化付錢。他把模糊的「降本增效」，轉譯成了「原料配比預測」這個精確任務，讓 AI 找到了真正的發力點。

說到底，AI 只是放大器，被放大的前提必須是專業。沒有專業，AI 只會放大幻覺；沒有場景，AI 只會放大空話；沒有客戶，AI 只會放大自嗨。

因此，在 OPC 時代，生態負責提供槍炮、算力、模型、開源與基礎設施，而創業者必須親自負責扣動扳機：判斷方向、建立信任、完成交付、承擔風險。中關村 AI 北偉社群那 70 多家入駐專案，某種程度上已經證明了這種模式的可行性。單兵作戰的底氣，從來不是一個人扛下所有，而是背後有雲廠商、開源社群與產業客戶組成的隱形重裝體系。

所以，奧特曼等人所談論的「一人十億美元公司」，本質上不只是創業神話，而是人類生產方式正在重組的訊號。未來，一個人最重要的能力，可能不再是親手完成所有工作，而是定義問題、調度智慧體、判斷結果與承擔責任。

過去，一個人想做一家公司，得先把人招齊；現在，一個人想驗證一個商業想法，則可以先用 AI 跑出最小閉環，先驗證價值，再長出組織，先找到客戶，再決定要不要把公司真正做大。

[AI 影響] Codex不只是寫程式，而是AI工作方式的轉變

 [AI 影響] Codex不只是寫程式，而是AI工作方式的轉變

摘要 : 輝達全面推動員工使用Codex，顯示AI正從聊天工具升級為可執行任務的agent。

內容:

過去很多人把 Codex 視為單純的寫程式工具，但現在更值得注意的是，它正在代表一種全新的工作模式。輝達 CEO 黃仁勳要求所有員工使用 Codex，背後反映的重點，不是 AI 會不會寫程式，而是 AI 的角色已經開始改變。

傳統聊天機器人的核心是回答問題，你問一句，它回一句；但像 Codex 這類工具，正朝向 agent 的方向演進，也就是不只提供建議，而是能直接接下任務、理解專案、執行命令、修改檔案，最後交付結果。

例如當你提出「幫我找出這個專案為什麼構建失敗」時，一般 AI 可能只會列出一串排查方向；但 Codex 類型的 agent，則可能直接進入程式碼倉庫、閱讀錯誤日誌、定位問題檔案、修改程式碼、執行測試，並把修改內容與測試結果整理後交給你確認。這種差異，就像是從「詢問一位聰明的人」變成「多了一位能實際動手的同事」。

OpenCloud 創始人 Peter Steinberger 加入 OpenAI，也被視為這股趨勢的延伸。下一代 AI 的競爭關鍵，已不只是模型是否更聰明，而是能不能安全、穩定、持續地替人完成真實世界的工作任務。

因此，對一般人來說，現在最重要的不只是學更多 AI 名詞，而是學會如何把工作拆解成 agent 可以執行的任務。不要只停留在「幫我寫一下」，而要進一步明確指示，例如「先讀這三個檔案、找出問題、提出兩個方案、選擇風險最低的做法並執行測試」。

這才是 Codex 時代真正重要的提示能力。未來真正能善用 AI 的人，未必是最懂技術的人，而更可能是最會分配任務、驗收成果與控制風險的人。

[AI 警示] 納德拉談AI生態風險

 [AI 警示] 納德拉談AI生態風險

摘要 : 納德拉警告，若AI紅利被少數巨頭壟斷，企業將失去自身能力；真正關鍵是沉澱自己的AI經驗資本。

內容:

微軟CEO納德拉近日一篇長文在美國社群媒體引發熱烈討論，單日閱讀量高達數千萬，連馬斯克也親自評論。文中他提出嚴正警告：如果AI紅利最終只集中在少數科技巨頭手中，整個產業將面臨被掏空的風險，而這樣的AI未來，社會終將無法接受。

納德拉提出一個新的框架，認為未來每家公司都必須管理好兩種資本。第一種是「人力資本」，也就是員工所擁有的知識、判斷力、人脈、創造力與模式識別能力。第二種則是他提出的新概念「token資本」，也就是企業自身累積的AI經驗資本。

所謂token資本，並不是單純使用現成的通用大模型，而是要把企業內部的流程、經驗、判斷方式與專業知識，沉澱成屬於自己的AI系統。這兩種資本並不是互相取代，而是彼此放大：AI負責執行、擴張與規模化，人則負責設定目標、建立關係、做出判斷與決策。若沒有人來引導，再強的算力也可能只是原地打轉。

他特別強調，任務可以外包，工作甚至可以外包，但學習本身永遠不能外包。真正屬於企業與個人的能力，來自於持續沉澱與吸收，而不是只依賴工具代勞。

納德拉也提出一個非常實用的判斷標準，叫做「換模型測試」。也就是說，一家公司應該有能力隨時更換底層的通用AI模型，卻不會因此失去自己系統裡累積下來的經驗與能力。如果一換模型，整個業務就癱瘓，那就代表這家公司其實並沒有真正掌握自己的AI能力。

而他最擔心的，不是AI發展得不夠快，而是AI可能重演全球化初期的悲劇。當年許多發達國家把製造業外包出去，表面上GDP仍在增長，但實際上產業鏈逐漸被掏空，導致工人失業、地方衰退，這些後遺症至今仍未完全消失。

納德拉警告，如果AI也走上同樣的路，後果可能更加嚴重。企業若把內部資料、流程與專業知識全部餵給少數大模型，最後模型學走了所有本事，企業自己卻變成空殼。最終價值會流向極少數模型供應商，多數產業只能淪為配角，自己的知識被商品化，卻無法真正分享收益。這樣的政治與經濟結構，社會根本難以承受。

因此，他認為當前最重要的任務，不是只打造最前沿的模型，而是建立一個「前沿生態系統」。這個生態系統應該讓每家公司、每個產業、每個國家都能建立自己的學習閉環，持續累積人力資本與token資本，形成自己的競爭優勢。

對企業來說，這是一個非常現實的道理：AI工具可以購買，但透過AI使用過程中所累積的經驗、流程與知識，必須掌握在自己手中。若只是依附在通用模型之上，隨波逐流，等到環境變化時，才可能發現自己根本沒有真正的護城河。

對大公司而言，這是戰略問題；但對中小企業和普通工作者來說，這甚至是生存法則。若一個人只是依賴各種AI工具寫報告、回郵件、做方案，卻從不總結、不沉澱，也沒有建立自己的判斷框架，那麼一旦換了模型或工具，很可能就會失去獨立工作的能力。

AI可以替人完成工作，但無法代替一個人的成長。納德拉這封信的核心意思其實很簡單：不要把自己的腦子外包給機器。

對打工人來說，不要只當AI的操作員，而要成為AI的指揮官，學會用AI放大自己的判斷力，而不是讓AI取代判斷力。對老闆來說，不要只停留在採購AI工具，更要有意識地沉澱自己的業務流程與資料資產，否則大家都在用同一套外部大腦，公司自然難以建立真正的競爭力。

歸根到底，AI浪潮不會淘汰人，但一定會淘汰那些只會使用AI、卻不會培養與沉澱AI能力的人和組織。

[AI 分享] 提升AI生產力的核心Skill架構

 [AI 分享] 提升AI生產力的核心Skill架構

摘要 : 真正拉開AI效率差距的，不是模型強弱，而是Skill配置與工作流設計。

內容:

很多人使用 AI 時，常陷入一個誤區：一直糾結到底哪個平台最強、哪個大模型最聰明。但真正決定生產力上限的，往往不只是平台本身，而是你替它配置了什麼 Skill。若底層能力沒有補齊，再強的 Agent 也可能只是空轉。

這套核心 Skill 架構大致可以分成四個部分。第一部分是原生基礎 Skill，它不直接負責執行具體任務，而更像是替 AI 裝上一個自我進化引擎，讓它能自己寫新工具，或是到外部尋找現成幫手。這是無論未來想讓 AI 做什麼，都應該最先打好的基礎。

第二部分聚焦在程式開發時常見的幻覺問題。AI 生成的程式碼經常看起來邏輯完整，但實際執行卻會報錯。因此這裡引入工程化規則，例如測試驅動開發與專家審計，讓 AI 不再憑直覺亂寫，而是依照嚴格標準來完成程式碼。

第三部分談的是前端設計。現在許多 AI 生成的網頁都有一種明顯的「AI 味」，缺少質感與耐看度。因此需要專業設計類 Skill，協助 AI 產出更成熟、更有審美與商業感的介面設計。

第四部分則是內容創作。目標不只是讓 AI 寫出好內容，而是打通從配圖、資訊圖表繪製、排版、翻譯，到一鍵多平台發布的完整流程，形成真正的自動化閉環，把大量瑣碎工作交由 Agent 處理。

在原生基礎 Skill 中，第一個重要工具是 Skill Creator，這是 Anthropic 官方推出的工具。它的核心作用，是把成熟工作流打包成可以高頻重複使用的原子工具。過去如果想自己製作 Skill，往往需要研究繁瑣格式、手動修改配置檔，稍有錯誤就容易報錯，而且做出來的效果也未必理想。

有了 Skill Creator 後，流程被大幅簡化。使用者不需要硬啃開發文件，只要像對同事交辦工作一樣，用自然語言描述流程，或者直接提供既有 SOP 與操作手冊，它就能協助生成 Skill。整體流程大致分成三步：先用口語提出需求，再由系統在後台自動測試、打磨與迭代，最後不到一分鐘，就能產出標準且可用的 Skill。這大幅降低了手寫配置與除錯的負擔。

第二個原生 Skill 是 Find Skills。它不只是傳統意義上的應用商店搜尋工具，而是把被動搜尋變成主動指派。當使用者交給 Agent 一個複雜任務，例如設計帶有一鍵結算機制的系統 UI，若 Agent 本身不具備 UI 設計能力，它不會直接卡住，而是會在後台先把需求拆解成像 UI Design 這樣的原子意圖，再連接到 skill.sh 平台，主動盤點合適的 Skill。

它會評估哪些 Skill 安裝量高、作者可靠、口碑佳，並過濾掉冗餘或廢棄的工具，再把最適合的選項呈現給使用者。確認後，還能透過一行指令自動下載安裝。簡單來說，Skill Creator 讓 Agent 能自己造工具，Find Skills 則讓它能主動尋找外援。這兩者搭配後，Agent 的能力邊界會被大幅打開。

進入實戰場景後，軟體開發是一個很重要的應用方向。這裡提到的第一個 Skill 是 Superpowers。它的核心邏輯很硬核，直接把測試驅動開發的工程標準，變成 Agent 必須遵守的規則。很多人用 AI 寫程式時，第一直覺是讓它幫忙寫測試，而 Superpowers 則把整個流程徹底制度化。

它會強制 Agent 進入標準的紅綠重構循環。第一步是先寫一個必然失敗的測試，用來證明功能尚未實現；第二步只允許撰寫最少量、剛好能讓測試通過的程式碼；第三步則是在測試通過後，再進行結構優化與程式碼重構，去除不良設計與壞味道。

更穩健的是，完成程式後它不會立刻交差，而是啟動兩輪內部交叉審計。第一層是藍圖對齊審視，重點不是只看程式碼是否能跑，而是檢查實作邏輯是否真正對齊最初需求。第二層則是高危邊界挑刺，專門去找像空指標、例外狀況與隱藏邊界條件這類問題。雖然這套流程看似更花時間，但因為第一版程式碼品質更高，能大幅降低後續反覆 debug 的成本，長期來看反而更省時間與 token。

此外，它在流程最後仍保留人工決策空間，使用者可以選擇直接 merge 合併、暫時 stay 觀察，或是 drop 作廢。這代表 AI 並不是完全接管，而是以工程化方式輔助人類做更高品質的判斷。

如果要打造的不是單一功能模組，而是完整的商業系統，那麼單靠一位程式設計師的視角通常不夠。這時候就需要更像團隊協作的工具，例如 G-Stack。這個工具由 YC 總裁 Gary Tan 推出，最大的特色是在 Agent 裡直接內建 23 個不同專家角色，例如 CEO、視覺設計師、後端架構師、安全專家與發布架構師等。使用者可以透過斜線命令直接召喚這些角色，讓 AI 在單一工作流中模擬跨職能團隊協作。

[AI 分享] 可交付AI Agent系統構建

 [AI 分享] 可交付AI Agent系統構建

摘要 : 從產品認知、上下文管理到評估體系，整理可交付AI Agent系統的實戰方法與原則。

內容:

這篇內容主要在討論：**如何構建真正可交付的 AI Agent 系統**。整體思路來自 5 月 31 日 AI Engineer 的一支 YouTube 影片，但也與企業 AI Agent 交付、AI Coding Harness 以及陪跑專案中的實際經驗高度契合，因此很值得整理分享。

全文大致可分成五個核心方向，從最底層的認知開始，談人類與 Agent 使用產品的方式差異，接著談上下文管理、狀態機制、評估體系建設，以及提示詞與技術實作上的原則。其中作者特別強調：**評估體系是最關鍵、也最容易被忽略的一環**。

首先，最核心的認知是：**人類與 Agent 消費產品的方式並不一樣**。  

以 HTML 為例，人類在看網頁時，往往是從視覺、元素、關聯與互動效果去理解；但 Agent 在處理 HTML 時，更多是從文字結構與語意關係去推斷內容。因此，當我們設計產品或資料給 AI 使用時，不能完全沿用「給人看的方式」，而要開始思考怎樣讓模型更容易抓取、總結與理解。

這也帶出第一個重要原則：**不需要把所有文件都丟給 AI**。  

因為很多通用知識模型本來就知道了，真正需要補充的，反而是那些模型最容易誤解的地方，例如產品中的特殊規則、常見踩坑點、容易混淆的邏輯等。換句話說，給 AI 的資訊不在於多，而在於是否能幫助它避開誤解。

此外，在設計產品時，也可以逐步往 **更容易被 AI 理解的結構** 靠攏。比如以往很多頁面設計是優先給人類瀏覽體驗，但未來也許需要兼顧「是否有利於 Agent 抓取、解析、摘要與推理」。這些與人的差異雖然微妙，卻會在實作過程中持續影響成效。

第二個重點是**上下文管理**。  

在 AI Coding 或 Agent 工作流中，常常有大量時間花在補充背景資訊與前置條件上，而且每次新開一個上下文，都要重新講一次，效率很低。比較好的做法，是把這些重複性高、可複用的資訊提前整理起來，做成可被調用的內容模組，例如 skills 或 agent cmd，讓模型在需要時自動載入。

這樣做的價值在於：當你發現某些背景資訊、操作說明或工作流程總是要重複提供，就應該把它們結構化，沉澱成系統能力，而不是每次人工重新輸入。這能大幅降低前置溝通成本。

不過，就算把 skills 都準備好了，也不代表模型就一定能從頭到尾穩定執行。  

因為大模型本質上仍然是機率性系統，即便 temperature 設為 0，穩定性仍有限，也可能出現幻覺或中途偏離。因此，在 AI Agent 產品中，不論是 AI Coding 還是其他 Agent 類型系統，**狀態機制** 都是很有效的處理方式，可以幫助流程更可控。

接著進入全文最重要的部分：**評估體系建設**。  

這裡引用了一個很關鍵的觀點：如果沒有評估，就沒有改進。對可交付的 AI Agent 系統來說，評估不是附屬品，而是核心能力。

曾把過去大量的人類經驗文件整理成 skills，讓 AI 在處理問題時調用，原本以為這樣效果會更好；但在建立評估體系後卻發現，**把所有 skills 都給模型時，準確率只有 70%；反而什麼 skills 都不給時，準確率可以達到 97%**。這是一個非常有啟發性的結果。

原因在於，skills 本身也會佔據上下文，而且其中可能混入過時文件、不夠精準的指導，或與當前專案結構不一致的內容。這些資訊不但沒有幫助，反而可能干擾模型判斷。因此，這裡得到一個非常重要的結論：  

**與其給模型固定規定，不如給它指導原則。**

也就是說，不要試圖用大量細碎、陳舊、僵硬的規則去束縛模型，而應該提供方向性的引導，讓模型依據當前情境做合理判斷。這被認為是整支影片中最有價值的一個觀點。

至於評估體系怎麼建立，可以分成幾個層次：

第一層是**確定性驗證**。  

例如在程式碼提交流程中，透過單元測試、Lint、Build 驗證等方式做檢查，這些屬於 CI/CD 中本來就應該存在的固定環節。AI 介入後，這些機制不能省，反而更重要，因為它們能提供穩定、可重複的品質保障。

第二層是**規則化檢查**。  

像是程式碼規範、靜態檢查、格式化與一些明確可定義的規則，這些也應該交給工具或系統做，而不是完全依賴模型的主觀判斷。

第三層才是**模型評估**。  

但這裡有個關鍵技巧：不要讓模型做過於寬泛的評價。例如不要問「這段程式碼好不好」，而應該把問題窄化成具體維度，例如：「找出這段程式碼中與需求不一致的地方」、「列出可能缺失的邊界條件」、「指出風險較高的區域」。當評估範圍被縮小後，模型的焦點會更集中，輸出品質也更穩定。

最後一層仍然是**人工審查**。  

即使前面有規則檢查與模型評估，人依然不能完全退出。對於重要程式碼、關鍵業務邏輯、風險區域，例如支付流程、核心架構、可維護性等，人還是需要親自看。也就是說，真正可交付的系統，不是把責任全部推給 AI，而是建立一個多層次驗證機制，讓 AI、規則與人工彼此補位。

因此，不只是 AI Agent，包含 RAG、Harness、AI Coding 流程，只要是要落地交付的系統，**都必須有評估體系**。這一點非常關鍵。

最後回到 skills 的問題，這段內容也再次提醒：**不是 skills 給得越多越好**。  

當模型本身的理解與執行能力越來越強時，我們需要做的，不是塞滿所有文件，而是「輕推一下」，把它引導到正確方向。真正有效的做法，不是用大量陳舊規則綁住模型，而是提供清楚、簡潔、方向明確的原則，讓模型在具體任務中靈活發揮。