Latest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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