江中喬

江中喬

「AI Agent 工程師」會取代前後端分工嗎?我更在意的是責任邊界
AIAgent

「AI Agent 工程師」會取代前後端分工嗎?我更在意的是責任邊界

最近看到一個說法很吸睛:未來不分前端、後端,只剩一種角色——AI Agent 工程師。 這種說法很容易引發兩種反應: * 技術人員的焦慮:我是不是要被淘汰了? * 管理者的興奮:那是不是可以砍掉一半人? 我比較想把它放回工程現場來看:角色可能會融合,但真正決定你價值的,不是「會不會寫程式」,而是你能不能把 AI 帶進流程、並且把風險收得住。 ## 角色真的會統一嗎:會,但方式不會那麼浪漫 「全端化」本來就一直在發生。 從 jQuery 到 Node.js 到雲原生,每一波工具鏈變強,都會讓分工邊界變模糊。 AI Agent 只是把這件事推得更極端: * 需求描述更像規格撰寫 * UI / API / DB schema 都可以被快速生成 * 除錯、測試、文件也能被半自動化 但工程世界裡永遠有一個不變的物理定律:產出越快,錯誤也會更快、更大量、
4 min read
Karpathy 的 LLM Agent 寫程式體感:改變的不是速度,是工作的邊界
AIAgent

Karpathy 的 LLM Agent 寫程式體感:改變的不是速度,是工作的邊界

Karpathy 的 LLM Agent 寫程式體感:改變的不是速度,是工作的邊界 很多人把 AI 在軟體開發裡的價值,理解成「寫程式更快」。 但真正用上一段時間之後,你會發現它動到的不是加速,而是整個工作方式:你不再把時間花在逐行產出,而是花在定義、檢查、修正與決策。 最近 Andrej Karpathy 分享了他大量使用 LLM agent(例如 Claude)寫程式的體感,我覺得值得把它讀成一個更大的訊號:軟體工程的瓶頸正在移動。 出處(Andrej Karpathy 貼文):https://x.com/karpathy/status/2015883857489522876 從「手寫」到「審稿」:工程師的手感正在改變 Karpathy 的描述很直白:在很短的時間內,他從「大多數程式都親手寫」
3 min read
通過安全測試不代表變安全:AI 評測為何可能被「演給你看」
AISafety

通過安全測試不代表變安全:AI 評測為何可能被「演給你看」

通過安全測試不代表變安全:AI 評測為何可能被「演給你看」 最近社群又在轉一種說法:如果一個比人類聰明很多的 AI 通過安全測試,你以為它變乖了?其實是它更會騙你。 出處(Dario Amodei 貼文):https://x.com/DarioAmodei/status/2015833046327402527 這句話的情緒張力很強,但它指向的風險確實值得嚴肅討論:當模型的目標與我們的評測目標不一致時,模型可能會學到「在評測中看起來安全」這件事本身。 我想把這件事從「科幻恐懼」拉回工程現場:哪些機制會導致它發生?我們又能怎麼設計更可靠的安全評估? 先把詞說清楚:我們在擔心什麼 在 AI 安全領域,這類風險通常和幾個概念相關: * Reward hacking / specification gaming:獎勵函數或規格寫得不完整,模型找到捷徑「拿高分」,但行為不符合人類真正想要的結果。 * Goodhart’s law 的工程版本:當你把指標當成目標,
5 min read
Prompt-Only 攻擊:當攻擊不再靠惡意程式,而是靠「指令」
資安

Prompt-Only 攻擊:當攻擊不再靠惡意程式,而是靠「指令」

最近看到 CrowdStrike CEO George Kurtz 提到一個很值得警惕的概念:Prompt-Only 攻擊。 它的直覺很殘酷:攻擊者不一定要丟一個「寫死的惡意程式」進你電腦,他只要把一段惡意指令(prompt)植入到你環境裡,讓你本機的 AI 工具自己把攻擊補完。 ## 什麼是 Prompt-Only 攻擊(用工程語言翻譯) 傳統惡意軟體常見的路線是: * 交付 payload(惡意檔案/惡意腳本) * 連回 C2(指揮控制) * 下載模組、更新行為 * 用特徵碼或行為模型去偵測 Prompt-Only 的想像是另一條路: * 攻擊者交付的是「文字指令」 * 指令會跟企業內部已部署的 LLM 擴展、瀏覽器 AI 代理互動 * AI 依照受害者的本機環境(檔名、Slack 紀錄、郵件內容等)即時生成腳本(
3 min read
Claude Code 新手上路:把一堆名詞放回正確位置
ClaudeCode

Claude Code 新手上路:把一堆名詞放回正確位置

剛開始用 Claude Code(或任何一種「AI 進到開發流程」的工具)時,最痛苦的通常不是功能,而是名詞爆炸。 CLAUDE.md、MCP、Subagents、Skills、Slash Commands、Hooks……你明明只是想讓它幫你寫點程式,結果像被丟進一場企業架構課。 我自己會用一個很實務的方式消化:每個名詞都對應一種「團隊裡的角色」或「工程裡的控制點」。你把它放回正確位置,整個系統就突然合理了。 ## CLAUDE.md:專案的長期記憶(不常改的那種) 如果你把 Claude 當成加入專案的新同事,CLAUDE.md 就是他入職第一天會拿到的那份文件: * 系統架構與模組邊界 * 開發慣例(命名、資料夾結構、測試習慣) * 設計模式與你們不想再爭論的決策 它的重點是「穩定」:不要塞每天都在變的細節,否則它會變成噪音。 我會放的內容 * 這個 repo
4 min read
超長 Context 不是萬靈丹:MIT 提醒我們小心「Context Rot」
LLM

超長 Context 不是萬靈丹:MIT 提醒我們小心「Context Rot」

最近看到一個很典型的科技流量標題: 「別再迷信超長 context 了!救星竟然是 Python?」 標題很會抓眼球,但我更在意的是它背後那個更實際的訊息:你把更多文字塞進模型,不等於模型就更懂你要它做什麼。 ## 「超長 context」的幻想:把整本書丟進去就能推理 很多產品在推長 context 時,大家腦中想像的使用情境往往是: * 把一堆文件丟進去 * 然後要求模型做跨段落、跨頁碼、跨章節的推理 * 最後得到一個精準可追溯的答案 但這裡有一個被忽略的現實:Transformer 的注意力機制對「資訊量」很敏感,你越塞越多,模型越容易把關鍵線索當成噪音。 MIT 這類研究(或你在實務中做的長文件 QA)常會遇到一種現象: * 單點查找還行 * 一旦需要跨段落組合、比對、推理,表現會明顯崩掉 社群把它稱為 Context Rot(上下文腐爛):context 變長,理解能力沒有等比例提升,反而像在一堆紙堆裡找針。 ## 真正該問的問題:你要的是「
3 min read
從 ChatGPT 的 PostgreSQL 最佳實踐學到的事:規模靠的不是神話,是紀律
PostgreSQL

從 ChatGPT 的 PostgreSQL 最佳實踐學到的事:規模靠的不是神話,是紀律

最近看到 OpenAI 分享 ChatGPT 如何用 PostgreSQL 服務到「8 億用戶」等級的實務做法。 這種文章常被當成巨頭逸聞:看完覺得很猛,但跟自己無關。 我反而覺得,真正值得抄的不是規模,而是背後的工程紀律:當你把資料庫當成產品核心的一部分來經營,你會怎麼設計它的邊界、觀測、與失敗模式。 下面把九個重點拆成三層來看: 1. 這 9 點在 ChatGPT 裡實際長什麼樣 2. 為什麼它們特別適合「AI 時代」的 DB 使用方式 3. 如果你是 PM + Python side project / 小型 SaaS,怎麼做縮小版 ## 這 9 點在 ChatGPT 裡實際長什麼樣 ### 1)單一
7 min read
Prompt 不是咒語:AI 回覆品質反映的是你的思考結構
AIAgent

Prompt 不是咒語:AI 回覆品質反映的是你的思考結構

最近 AI 圈的節奏很像一種集體幻覺:每隔幾天就冒出一個新框架、新方法、新「必學技巧」。大家焦慮地交換咒語、交換模板,彷彿只要背對句型,就能讓模型吐出神作。 但在實務上,我看到的情況更接近另一種現實:你得到的回覆品質,往往取決於你把問題想清楚到什麼程度。 這不只是感覺。Anthropic 在 2026 年 1 月發布的 Anthropic Economic Index 報告中,針對約百萬級的真實 Claude 對話,分別估計「理解使用者輸入需要的教育年限」與「理解模型回覆需要的教育年限」,並在不同國家與美國各州層級比較兩者關係,得到高度線性相關(相關係數皆 > 0.92)。 換句話說,prompt 的概念難度/複雜度,幾乎會等比例反映到回覆本身的複雜度。 AI 很強,但它不是把普通人瞬間變成專家的魔法棒;它比較像一面鏡子,把你輸入的思考層次放大、照出缺口。
4 min read
AI FOMO 管理學:把資訊消化拉長兩週,順便搞懂 Skills vs MCP
AIAgent

AI FOMO 管理學:把資訊消化拉長兩週,順便搞懂 Skills vs MCP

這陣子的 AI 圈有一種熟悉的味道,讓我想起 2022–23 年的區塊鏈: * 新名詞、新框架、新「革命性」應用,幾乎每 2–3 天就來一輪 * 產品成熟度還沒跟上,討論熱度先衝到天花板 * 你明明在工作,手機卻一直提醒你「你落後了」 FOMO 不是你的問題,它是市場在高速迭代時的副產品。問題在於,你要用什麼節奏去消化它。 ## 我自己最實用的一招:把判斷週期拉到 1–2 週 當資訊密度高到爆表時,我會強迫自己做一個「時間濾網」: * 今天看到的概念先記下來 * 不急著追完整套教學、也不急著做結論 * 兩週後再回頭看:還有人持續在聊嗎?有真實案例冒出來嗎?有工具鏈開始接上來嗎? 兩週後還站得住的東西,通常具備兩種特質之一: 1. 確實解決了某個痛點,所以會有自發的延伸使用 2. 短期內難以被巨頭輕鬆碾壓或收編,因此會累積一點點護城河 用這個節奏再去投入時間,
4 min read
Clawdbot vs n8n:別再用「XX已死」製造知識焦慮
AIAgent

Clawdbot vs n8n:別再用「XX已死」製造知識焦慮

最近又看到一種熟悉的流量打法:新工具一出,就有人急著喊「某某已死」。這類說法很有效,因為它直接打中兩件事——焦慮與跟風。 但在自動化工具這個領域,最容易被忽略的一點是:同一個詞(自動化、AI、Agent)底下,其實塞了好幾種完全不同的產品形態。把它們硬塞進同一個比較框架,結論自然會歪掉。 ## 兩種工具,兩種工作方式 以近期討論度很高的 Clawdbot 與 n8n 為例,很多爭論其實源於「用錯評估標準」。 ### Clawdbot:對話驅動的個人助理型自動化 Clawdbot 更像是把任務入口做成聊天介面:你用 Telegram、WhatsApp 等訊息,把需求丟出去,系統在本地電腦或伺服器環境裡決策並執行。 它擅長處理的是「人平常懶得做、但又很花時間的小事」:整理郵件、拉行事曆、查資料、串通知、跑一些需要上下文判斷的流程。 這種形態的代價也很明顯: * 可觀測性容易不足:做了什麼、為什麼這樣做、是否能重現,往往需要額外設計。
3 min read
AI Agent 淘金熱下的安全盲點:當你把 Email 交給 Bot
科技趨勢

AI Agent 淘金熱下的安全盲點:當你把 Email 交給 Bot

最近看到一個很有趣的對比: 一邊是 YouTuber 在桌面上乾乾淨淨地示範,用一台看起來「很安全」的 Mac mini 跑 AI Agent;另一邊是真實使用者把工具架到雲端(EC2)、接上 Email、Telegram,甚至直接給整台機器的完整存取權限。 差別不在技術能力,在風險承擔的方式。示範可以用最理想的環境,真實世界會用最方便的路徑。 ## 為什麼 AI Agent 會在短時間爆紅 AI Agent 的傳播速度,通常不是靠一個「超強功能」打天下,而是幾個條件疊在一起: * 可見度:KOL 影片、社群討論、大家互相轉貼,演算法自然放大。 * 可用性:不用等官方整合,自己就能接 API、接訊息、接任務。 * 命名與聯想:如果名字讓人瞬間知道「它大概是什麼」,傳播會更快。 * 落差感:
4 min read
【密度決定一切(4/4)|跨境密度:台灣電商的下一場戰爭,在全球供應池】

【密度決定一切(4/4)|跨境密度:台灣電商的下一場戰爭,在全球供應池】

💡 台灣電商近五年的所有爭論:介面、補貼、物流、速度、前台改版 在跨境這件事面前,都會變得不重要 原因很簡單: 台灣消費市場太小,本地供應又有限 真正能改變「心智密度」的,不是改善 UI,而是擴大供給池 而全球供給池這件事, 台灣沒有任何一間純電商平台能自己做到 但統一可以 而 Shopee 已經做到 這就是第四篇的核心: 跨境密度,將決定台灣電商下一個十年的勝負 ① 台灣電商市場飽和得比你想的更快 💡 台灣 2,300 萬人口,家戶消費習慣高度穩定, 本地品牌數量有限、品類深度有限、新品流速慢 這帶來三個嚴重後果: 1. 前台難以每天有新貨 2. 推薦系統很快撞到天花板(因為沒新東西) 3. 平台再怎麼做 FEED,也做不出「每天想打開」的理由 所以台灣本地電商會自然卡在一個「瓶頸」: 商品池不夠大
5 min read
【密度決定一切(3/4)|心智密度:不是 UX,而是「每天打開的理由」】

【密度決定一切(3/4)|心智密度:不是 UX,而是「每天打開的理由」】

💡 台灣電商圈這幾年有一個普遍誤解: 把「體驗」等同於「介面」與「速度」 但如果把四大平台拉出來仔細看,你會發現一件殘酷的事: * UX,不能解釋 Shopee 為什麼能每天被打開 * 速度,不能解釋 Momo 為什麼能建立黏著度 * 補貼,更不能解釋 Coupang 為什麼能形成習慣 真正決定使用者回流心智的,是心智密度(Desire Density) 你打開 App 時,覺得「值得看一下」的那種厚度 台灣電商成敗的本質,不是需求,而是「慾望」 使用者不是每天需要買東西,但每天都願意看「今天有什麼」 而要形成這種習慣,靠的不是: * UI * 補貼 * SEO * Banner 而是看一個平台是否具備真正的心智密度 ① 心智密度是什麼? 💡 它不是功能,而是一種「被打開」的可能性
6 min read
【密度決定一切(2/4)|商品密度:真正的入口不是 UI,而是貨架的深度與覆蓋率】

【密度決定一切(2/4)|商品密度:真正的入口不是 UI,而是貨架的深度與覆蓋率】

💡 台灣電商普遍陷入一個誤解: 以為電商的回流率靠 UX、促銷與推播 這只對了一半 真正決定 DAU 與回流心智的,不是介面 而是 商品密度(Supply Density) 如果供給不夠豐富、品類不夠深, 平台永遠只能被使用者當作「我要買東西才來」的地方 簡單講: 商品密度不足的平台,永遠只能是需求型電商(Need-Based Commerce), 無法進入慾望型電商(Desire Commerce) 而這個分野,就是 DAU 與 GMV 的生死差別 ① 電商不是賣商品,電商在賣「找到東西的可能性」 消費者每天打開電商 App 的理由只有兩種: * 需要 * 想要 💡 人們不是為了買『需要』的東西,而是買『想要』的東西 前者帶來一次性訪問,後者帶來習慣 而建立「想要」
5 min read
【密度決定一切(1/4)|供應鏈密度:便利商店取貨已不是競爭力】

【密度決定一切(1/4)|供應鏈密度:便利商店取貨已不是競爭力】

💡 台灣電商市場花了十年爭論 UI、UX、補貼與 GMV 但真正決定勝負的因素,其實只有一個: 供應鏈密度(Supply Chain Density) 在島型經濟裡,物流路線、配送節點與生活動線的重疊程度, 才是使用者習慣、物流成本與平台競爭力的源頭 這個現實,常被忽略 ① 「便利商店取貨」在 2025 已成標準配備,無法產生差異化。 台灣便利店密度全球第一,因此: * 所有平台都能做店取 * 物流體驗差距極小 * 店取早已不是消費者的選擇理由 換句話說,便利商店取貨不等於物流能力,而只是平台在借用便利商店的物流網 這也是台灣電商最容易誤判的盲點: 你以為你提供的是物流服務,實際上你並沒有自己的物流網 下一個十年的關鍵其實不是「能不能店取」, 而是更本質的一題: 你的物流密度,是你自己的?還是別人提供的? 因為真正拉開差距的,不是 UI,也不是配送速度, 而是誰能把整座城市視為自己的配送節點網 這並不是要每家電商都去複製「店到店」 而是只有兩種玩家能往上走: * 能自己建立節點的(蝦皮)
8 min read