Plain Text is All You Need:當純文字遇上 LLM

TL;DR

Bash 工具鏈發展了幾十年,grep、find、目錄結構這些東西早就被驗證過了。當 LLM 取得操作這些工具的能力後,純文字 + 目錄結構突然從「最陽春的方案」變成「最強大的知識庫格式」。不需要花俏的 App,不用擔心服務倒閉,你的資料永遠是你的。


做軟體的人都知道一件事:Unix/Linux 的 Command Line tools,是整個作業系統的根本。

grep 搜文字、find 找檔案、mkdir 建目錄、mv 搬東西——這些指令從 1970 年代就存在了。五十年過去,今天全世界還是有幾百萬台伺服器每天在跑這些東西。每一行程式碼、每一份設定檔、每一筆系統日誌,全部都是純文字。

你有沒有想過為什麼?

不是因為沒有更好的格式,嘗試取代純文字的東西多的是——XML 試過、二進位格式試過、各種專有格式都試過。最後大家還是回到純文字。因為它滿足了工程上幾個最關鍵的特性:它持久,五十年前的 .txt 今天還是能打開;它可搜尋,一行 grep 就能從幾萬個檔案裡找到你要的東西;它可程式化,任何語言都能讀它寫它;它可以用 git 做版本控制,每一次修改都有紀錄;你想遷移的時候,複製資料夾就好了。

這些特性被驗證了半個世紀,從來沒有被推翻過。你用過的程式語言可能換了好幾種,框架可能每兩年就換一輪,但底層的純文字從來沒變。

不過,過去這些強大的工具有一個致命的限制:只有工程師在用,而且只用在程式碼上,更重要的是他使用上沒那麼好學習。

你不會用 grep 來管理自己的讀書筆記。你不會用 find 加上正規表達式來搜尋「上週讀的那篇關於注意力機制的論文」。你不會寫一個 shell script 來自動分類你的個人筆記。不是因為做不到,是因為太麻煩了——門檻太高,一般人不會用,就算是工程師,下班後也不想對著 terminal 管筆記。

所以這套強大的工具鏈,就一直安靜地待在它的世界裡,處理程式碼和伺服器的事情,跟個人知識管理完全沒有交集。

直到 LLM 出現。


這是我覺得很多人忽略的一件事——當 Claude、GPT 這些語言模型取得 Bash 執行能力的那一刻,它們不是學會了一個新技能。它們是接上了一整條已經被驗證了幾十年的成熟工具組合。

這個差別很重要。

如果 LLM 是從零開始建立檔案操作能力,那我們要擔心的事情很多:它的搜尋穩不穩定?它的檔案操作會不會出錯?它的格式處理夠不夠成熟?但實際上這些問題都不存在,因為底層跑的就是那些用了幾十年的老工具。grep 不會搜錯,mkdir 不會建錯資料夾,git 不會搞丟版本歷史。這些東西早就被幾十億次的使用驗證過了。

更重要的是 LLM 的訓練資料中就包含了這些工具的使用方式。LLM 做的事情,是在這些工具上面加了一層自然語言介面。

你跟它說「幫我找那篇講 transformer attention 原理的筆記」,它翻譯成一個 grep 指令去搜尋。你說「這篇文章存到 AI 研究的資料夾裡」,它翻譯成 mkdir 確認目錄存在,然後 write 把檔案寫進去。你說「幫我把上個月的會議紀錄整理成重點」,它用 find 找到對應的檔案,read 讀進來,用語意理解能力萃取重點,再 write 存成新的摘要。

每一步都是成熟的操作,LLM 只是多了「理解你在說什麼」這一層。

換個角度想:以前你要使用這些強大的 Bash 工具,你得先學會命令列,記得各種 flag 和參數,知道怎麼把不同指令串在一起。這個學習門檻把 99% 的人擋在門外。現在 LLM 幫你把這個門檻抹平了——你只要用人話講,它幫你操作。

這讓我開始認真想一件事:如果 LLM 天生就擅長理解和處理文字,而且現在它又能操作檔案系統——那我們管理個人知識的方式,是不是可以從根本上重新想過?


在繼續往下之前,先看一下之前在 HN 上看的文章。

Brown 大學有個教授叫 Jeff Huang,他做了一件很有意思的事:用同一個 .txt 檔案管理自己的生產力超過 14 年。所有待辦事項、會議筆記、想法,全部丟進同一個純文字檔,用日期分隔,就這樣。

14 年。一個檔案。

他不是什麼技術宅在炫耀極簡主義。Jeff Huang 是電腦科學教授,他比大多數人都懂什麼工具好用。他之所以堅持用 .txt,是因為他看過太多東西來了又走。

裡面有句話讓我感同身受:

“I’ve been doing this for more than 14 years now. Let’s see your productivity app survive that long.”

你仔細想想,14 年前很流行的 Evernote,現在你身邊還有多少人在用?Google Keep 出了又好像沒什麼人在乎。Bear、Notion、Obsidian、Roam Research——每隔幾年就有新的「筆記革命」,每一個都很興奮,每一個都說自己是最後一個你需要的筆記工具。然後呢?有些還在,有些已經涼了,有些你還在付月費但其實半年沒打開過了。

而 .txt 檔案在這 14 年裡從來沒有讓 Jeff Huang 失望過。因為純文字不依賴任何公司、任何平台、任何軟體。它就是一個檔案,放在你的硬碟上,用任何文字編輯器都能開。

這件事讓我開始反思:也許問題不是出在我們不夠努力去學新工具,而是我們一開始就選錯了方向。我們一直在找「更好的軟體」,但也許真正需要的不是更好的軟體,而是更好的方法來使用最基本的格式。


但 Jeff Huang 的方法有個很明顯的限制:他的使用情境是單一時間序列的生產力追蹤。一個人、一條時間線、一個檔案。

如果我們要處理真實生活的各種知識,這方法自然不夠。

你的腦袋裡同時裝著很多完全不同的東西。上午可能在看一篇關於 LLM 架構的論文,中午開了個專案會議記了一堆決策,下午回了幾封重要的 email 然後覺得有些內容值得保存下來,晚上突然想記一下這個月的花費好像有點失控。這些東西的性質天差地遠,但它們都是你的知識、你的紀錄。

硬塞在一個檔案裡,三個月後你就再也找不到任何東西了。

那分類呢?你建了一堆資料夾,結果每次存筆記都在猶豫「這篇到底放工作還是放研究」,猶豫完就不想存了。或是存了,但命名亂七八糟,三個月後跟沒存一樣。

這就是為什麼 Notion、Obsidian 這類工具出現的時候,大家會覺得救星來了。它們提供標籤、分類、搜尋、資料庫視圖、雙向連結——把「找東西」和「組織東西」的問題都幫你處理好了。你只管往裡面丟,軟體幫你整理。

聽起來完美。

但代價是什麼?

你的資料變成了專有格式。Notion 的東西存在 Notion 的伺服器上,用它的 block 結構。Obsidian 好一點,底層是 Markdown,但一旦你用了它的外掛、embedded query、canvas,那些東西離開 Obsidian 就跑不了。Evernote 更不用說,匯出來的 .enex 格式根本沒有其他軟體原生支援。更重要的是,整理這些筆記和分類,還是消耗了你相當多的精力。

你花了三年、五年累積的知識庫,被鎖在一個商業公司的產品裡。哪天他們漲價漲到你受不了,或是改版改到你不認識,或是乾脆倒了——你就站在那裡,看著一堆匯出來格式半殘的檔案,思考人生。

Evernote 的老用戶應該特別有感觸。那個曾經被稱為「第二個大腦」的軟體,現在變成什麼樣了。

一直以來,這就是個兩難的問題:你想要簡單和自由,就得放棄結構和智慧;你想要結構和智慧,就得把資料交給別人保管。過去我們只能二選一。


現在不用了。

當 LLM 能操作檔案系統之後,純文字的瓶頸被打通了。不是靠更複雜的軟體,是靠一個「聽得懂人話、又會操作 Bash」的 AI 助手。

過去你的筆記太多找不到東西,是因為 grep 對普通人來說太難用了。現在你不用會 grep,你只要說「找一下我之前寫的關於 context window 的東西」,LLM 幫你轉成 grep 去搜。

過去你不知道新筆記該放哪裡,每次分類都在猶豫,猶豫到最後就不存了。現在你可以把分類規則寫下來,LLM 每次存檔前會自己讀規則、自己判斷。你說「存這篇」,它看了內容,判斷這是 AI 研究的文章,就放到對應的資料夾裡。不用問你。

過去索引很難維護——你建了一份內容清單,但每次新增刪除都忘記更新,三個月後那份清單就變成廢紙。現在 LLM 每次動了檔案就自動更新索引,你不需要操心。

過去不同筆記的格式亂七八糟,有的有日期有的沒有,有的有標籤有的沒有,後來想統一格式已經來不及了。現在 LLM 每次建檔都會先讀你定好的格式規範,照規矩來。

而在這一切的過程中,你的資料始終是 .md 檔案。Markdown 格式的純文字。你用 VS Code 能開,用記事本能開,用 cat 在 terminal 裡也能看。你想備份就 git push,想搬家就 copy 整個資料夾。你不依賴任何公司、任何訂閱、任何服務。

你同時擁有了純文字的自由,和智慧筆記軟體的便利。


我後來真的從這個想法出發,實際建了一套系統,跑了一段時間。在這裡把所有細節都講出來太繁瑣了,簡單分享一下核心設計——因為它真的很簡單,簡單到你看完後跟Claude的說,照著這篇文章講的設計就可以了。

就三件事。

第一件事:目錄結構就是知識分類。 不需要資料庫,不需要標籤系統,就是資料夾。Research/AI/ 放 AI 相關的研究筆記,Work/ 放工作文件,Personal/Finance/ 放個人財務。你打開檔案管理員看一眼就知道什麼在哪裡,不用背任何系統的操作邏輯。

你可能覺得資料夾不就是最原始的分類方式嗎?沒錯。但重點不是資料夾本身,而是當你用資料夾來分類知識,同時有一個 LLM 懂得你的分類邏輯的時候,這個「最原始的方式」就變成了最高效的方式。因為 LLM 不需要學什麼 API,不需要適應什麼 block 結構——它只要知道這個目錄叫什麼名字、裡面放什麼東西,就能開始幫你工作。

第二件事:每個目錄可以放一個規則檔。 我叫它 RULE.md。裡面定義這個目錄的遊戲規則——允許什麼操作?檔案要怎麼命名?需要哪些 metadata?有沒有什麼特殊政策,比如唯讀或只能新增不能刪除?

LLM 在對一個目錄做任何事之前,會先讀這個規則檔,然後照規矩來。你不用每次叮嚀它「記得加日期前綴」「記得寫 frontmatter」「記得這個目錄不能刪東西」——規則寫一次,它每次都會遵守。

這聽起來像是在「教 AI 守規矩」,但其實更像是在建立一套治理機制。你把知識庫的管理規則用純文字寫清楚,LLM 就成了你的管理員。

第三件事:每個目錄有一份索引,就是 README.md 列出目錄裡有什麼檔案、每個檔案是什麼、最近有什麼更新。人能看、AI 也能看。人看到的是一份內容清單方便快速瀏覽;AI 看到的是一張導航地圖,讓它知道不用從頭搜尋就能快速定位。

每次檔案有異動,LLM 自動更新索引,你完全不用手動維護。

就這三個東西:資料夾、規則檔、索引。全部都是 Markdown,全部都是純文字,全部都能用任何文字編輯器打開。

而且因為規則跟著資料夾走,這整套結構天生就是可遞迴的——你把一個子目錄搬到別的地方,它的規則和索引都還在,不用重新設定任何東西。這跟那些把設定存在某個中央資料庫的軟體完全不同。

日常用起來的感覺大概是這樣——我跟 AI 說「幫我存這篇關於 AI Agent 的文章」,它先看了各個目錄的規則檔,判斷這篇最適合放在 Research/AI/ 底下,然後按照那個目錄要求的格式建好檔案,附上日期、標籤、來源連結,最後更新索引。整個過程不到十秒鐘,我什麼都不用操心。

或者我說「找一下我之前看過關於 context window 的東西」,它搜一搜回來說「找到兩篇,一篇是去年 12 月的論文摘要,一篇是你自己寫的實作心得,要看哪個?」

就是這麼平淡無奇的事情。沒有華麗的 UI,沒有月費帳單,沒有要你看的 onboarding 教學。但它每天都在幫你把知識管好。


不過說真的,如果這套做法只是「管筆記方便」,我不會覺得它值得分享出來。

真正讓我覺得這件事有意思的,是它在處理「完全不同類型的知識」時展現出來的能力。

你想想看你日常在處理的資訊有多雜:工作上有軟體專案的架構文件、需求規格、會議紀錄。個人有理財紀錄、信用卡帳單分析、投資筆記。學習上有研究論文的重點摘要、技術文章的心得、讀書筆記。生活上有旅遊規劃、家庭行事曆、各種帳號密碼。

這些東西的性質天差地遠。過去你大概是這樣處理的:Notion 管筆記和待辦、Excel 管帳務、Confluence 管工作文件、再開個 Trello 管專案進度。四、五個平台,資料完全不互通。你想從上週的會議紀錄裡找到一個決策然後關聯到專案文件?好運,你得自己記得那是在哪個平台的哪個頁面。

但在純文字的世界裡,這些東西都在同一棵目錄樹底下。軟體專案有軟體專案的規則檔,財務有財務的規則檔,研究有研究的規則檔。它們各自有各自的分類和格式要求,但在物理上,它們就是同一台電腦同一個資料夾裡面的不同子目錄。

這代表什麼?

這代表 LLM 可以做到真正的跨領域操作。它能一條 grep 貫穿所有目錄,從研究筆記裡找到一個觀點,然後發現它跟你正在進行的工作專案有關。它能從你的會議紀錄裡提取行動項目,直接建到待辦清單裡去。它能分析你三月份的信用卡帳單,跟二月份的比一比,告訴你哪裡花多了。它能做到這些,是因為所有的資料都用同一種格式、在同一個地方,沒有格式轉換的問題,沒有平台之間的隔閡。

這是任何一個筆記軟體——不管它多厲害——都做不到的事。不是技術不行,是因為每個軟體天生就把資料鎖在自己的世界裡。你的 Notion 筆記不會自動跟你的 Excel 帳務對話。但純文字從一開始就沒有這個問題。

某種程度上,這也是 LLM 最被低估的能力之一。大家都在談 AI 寫程式、AI 畫圖、AI 做影片。但 LLM 最根本的能力其實是理解和操作文字,而我們日常產出最多的東西,就是文字。把 LLM 放在一堆純文字上面,讓它去理解、搜尋、整理、關聯——這才是最自然、最高效的使用方式。


回到 Jeff Huang 的故事。

他的 .txt 活了 14 年,而且還在繼續。我完全相信純文字會繼續活下去——這個格式從 1970 年代就存在,從來沒有讓任何人失望過。14 年算什麼,它已經活了 50 年。

不同的是,以前純文字是一種取捨。你選擇了自由和持久,就得放棄結構和智慧,所有的整理工作都要自己來。Jeff Huang 能堅持 14 年,靠的是超乎常人的紀律。

現在不一樣了。LLM 讓純文字從一個人苦撐的極簡主義,變成一個有 AI 助手在旁邊協作的完整知識管理系統。你還是擁有純文字的所有好處——持久、自由、不依賴任何平台。但你不再需要一個人做所有苦工,因為有一個懂語意、又會操作 Bash 的助手幫你打理。

你需要的東西其實出乎意料地少:

一個資料夾,這就是你的知識庫。幾個 Markdown 檔案,人和 AI 都讀得懂的格式。一些寫好的規則,告訴 AI 你的規矩。然後,任何一個能跑 Bash 的 LLM——Claude、GPT、本地跑的開源模型都行。只要它讀得懂文字、操作得了檔案系統,它就能幫你管理知識。

不需要在「簡單」和「強大」之間做選擇。純文字加上 LLM,兩個都拿。

少即是多,大道至簡。

Your AI Isn't Stupid—It Just Doesn't Know Anything: Why Context Control Matters

TL;DR

AI has no memory. Context is all it can see. Give it the right Context, and it’s brilliant. Give it the wrong one, and it’s clueless. Mastering Context is the key to working effectively with AI.


By now, most of us have used some kind of AI chatbot—whether it’s ChatGPT, Claude, or whatever AI assistant your company just rolled out. And you’ve probably noticed something strange: it’s clearly smart, yet it keeps doing dumb things.

For example, you set some ground rules at the start of a conversation, and halfway through, it forgets them. Or you explain your background once, and next time you chat, you have to explain it all over again.

Even the most powerful models in 2025—GPT-5, Claude 4.5, Gemini 3—still have this problem. To understand why, we need to look at how language models actually interact with us.


Context: The Starting Point and Boundary of Every Conversation

Once a language model is trained, its capabilities and knowledge are essentially locked in. Everything you type during a conversation—that’s not part of its training. We call this Context.

Here’s the simplest way to put it: Context is everything the AI can see in the current conversation.

This includes:

  • Your chat history with it
  • System settings (the hidden instructions you don’t see—like when the platform secretly tells it “you are a polite assistant”)
  • Any documents or data you paste in

Add all of that up, and you get the Context.

Think of it like hiring a brilliant new employee who knows nothing about you. Every time you assign them a task, you have to explain your company background, project status, and personal preferences from scratch. Context is essentially the briefing you hand them—without it, even the smartest person won’t know how to help you.

Here’s the catch: every language model has a limited Context capacity. Some can handle more, some less—basically, there’s a limit to how much text it can “see” at once. And every time you start a new conversation, the model doesn’t remember anything from before. It’s a blank slate. Every single time.


Why Does AI Get Dumber the Longer You Talk?

This isn’t just your imagination.

Think of AI like an intern you’re giving verbal instructions to. If you tell them to do 20 steps in a row, and they mishear a few along the way, the final result is going to be off. AI works the same way.

Research has shown that AI makes small errors at each step of a task. Say there’s a 5% error rate per action—sounds low, right? But errors compound:

Conversation Turns Success Rate
5 turns 77.4%
10 turns 59.9%
20 turns 35.8%
50 turns 7.7%

The more steps, the more things go sideways. And this doesn’t even account for what happens when the Context window fills up and the model starts “forgetting” earlier parts of the conversation.

To be fair, this mainly affects complex, multi-step tasks. If you’re just chatting casually, you probably won’t notice the errors. But if you’re writing code, doing analysis, or working through logic problems, one wrong step can derail everything.

That’s why AI seems sharp at the start of a conversation but feels dumber after an hour or two. It’s not actually getting dumber—the Context is getting too long and noisy, and errors are piling up.


How Do Platforms Make AI “Remember” You?

You might feel like ChatGPT or Claude remembers things about you from previous conversations.

But here’s the truth: the model itself has zero long-term memory—like a goldfish, it starts fresh every single time.

So why does it feel like it remembers? Because the platform is secretly slipping it a cheat sheet:

  1. Summarized history: The platform condenses your past conversations into a summary and injects it at the start of each new chat
  2. Dynamic retrieval: When you ask a question, the platform quietly searches your old data and feeds relevant bits to the model

The reality is: AI doesn’t actually remember you. It’s just reading a condensed version of your history with it every time.

This “memory” is an illusion—a clever one, but still an illusion. And here’s the thing: these “memories” also take up Context space.


Why Controlling Context Is Everything

Once you understand what Context is, something becomes clear: how precisely you control Context determines how well AI performs.

In the way language models work, the more relevant the Context is to the task, the better the output. The less relevant, the worse. So if you want AI to perform at its best, the key is: how do you provide high-quality Context?

In 2025, Anthropic (the company behind Claude) proposed a shift in thinking: we should move from “Prompt Engineering” to “Context Engineering.”

What’s the difference?

  • Old mindset (Prompt Engineering): “How should I phrase this instruction?”
  • New mindset (Context Engineering): “What Context configuration will most likely get the model to produce what I want?”

Here’s a cooking analogy:

  • The old approach: “Let me teach you step-by-step how to make this dish.”
  • The new approach: “Here are all the ingredients and my taste preferences—figure out the best way to cook it.”

This shift matters. We used to focus on how to ask. Now it’s more about how to inform.


What Makes Good Context?

Anthropic offers a precise definition: Find the smallest but most relevant set of information to maximize the desired outcome.

In plain English: Give information that’s precise, relevant, and free of fluff.

More Context isn’t always better. Stuff it with irrelevant information, and the model gets distracted and loses focus. It’s like handing your employee a briefing packed with unrelated company history, last year’s project notes, and office gossip—they won’t know what actually matters.

Good Context should be:

  • Highly relevant to the current task
  • Free of noise
  • Complete with the key information needed to do the job
  • Clearly structured so the model can parse it easily

Real Example: Same Question, Different Context

Let’s look at an example:

No Context:

“Write me an email.”
→ AI gives you a generic, boilerplate email. Nothing specific.

Basic Context:

“Write me an email to a client we’ve worked with for three years. They just got a new manager. Keep it formal but warm.”
→ Completely different result. At least it’s targeted.

Full Context:

On top of the above, you also provide:

  • Basic info about the client
  • Past email exchanges with them
  • The purpose and background of this email
  • Your company’s history with theirs

→ The output quality jumps another level.

The difference? The quality of Context.

If you don’t want to go that far, at least remember this simple formula:

Who’s the audience + What’s the purpose + What tone to strike

Just clarify these three things, and your results will be way better than a bare “write me an email.”


From “Teaching AI How to Do Things” to “Giving AI Enough Information”

Earlier, I mentioned the shift from Prompt Engineering to Context Engineering. Another way to look at it: we’re moving from “teaching AI how to do things” to “giving AI enough information to figure it out.”

Back when language models weren’t as capable, our prompts were mostly instructions—telling AI what steps to follow. AI was like a newbie who needed hand-holding.

Now, with 2025-level models, things are different. They’re smart enough to know how to do things. Our job is to provide enough relevant information so they can produce great output.

Anthropic observed something interesting internally: in just one year, the percentage of engineers using AI jumped from 28% to 59%, and self-reported productivity gains increased significantly. What changed their work wasn’t the model getting smarter—it was people learning how to feed it the right Context.


Conclusion

Understanding Context is the first step to working effectively with AI.

Once you realize that Context is all AI can see, you start asking different questions: How do I put the right information in? How do I make sure it sees what it needs to see? How do I avoid stuffing it with noise?

Next time AI seems to get dumber, try this mindset:

Think about what information to give before thinking about what instruction to give.

Instead of jumping straight to “what command should I type,” ask yourself: “If this were a new hire helping me, what background, data, and constraints would I tell them?” Write that down—and you’re doing Context Engineering.

In future posts, we’ll dive deeper into how to control Context effectively. This discipline is called Context Engineering.

你的 AI 不笨,只是什麼都不知道:為什麼控制 Context 重要

TL;DR

AI 沒有記憶,Context 就是它能看到的全部。給對 Context,它就聰明;給錯,它就像失憶。掌控 Context,是用好 AI 的關鍵。


這兩年大家多少都用過 AI 聊天工具,不管是 ChatGPT、Claude,還是公司導入的 AI 助理。你可能發現一件很矛盾的事:它明明很聰明,卻常常做出很笨的事。

比如說,明明一開始跟它說好規則,聊一聊它就忘了;或是你跟它講過的背景,下次好像又得重講一次。

就算是 2025 年主流的強大模型(像 GPT-5、Claude 4.5、Gemini 3),也都有這個現象。在理解為什麼會這樣之前,我們要先了解語言模型是怎麼和我們互動的。


Context:每次對話的起點與邊界

不論哪種語言模型,在它們訓練好後,它們的能力和知識就已經被固定下來了。而使用者在與語言模型對話的內容,這些不是一開始就被訓練進模型的內容,我們稱作 Context

先用一句話解釋:Context 就是這次對話中,AI 眼前能看到的所有文字。

這包括:

  • 你跟它的聊天紀錄
  • 系統設定(System Prompt,你看不到的、設定 AI 角色的隱藏指令,例如平台偷偷告訴它「你是一個有禮貌的助理」)
  • 你貼給它的任何資料

這些全部加起來,就是 Context。

想像你請了一個很聰明但完全不認識你的新員工。每次交辦任務,你都要重新告訴他公司背景、專案狀況、你的偏好。Context 就是你交給他的那份 briefing —— 沒有這份資料,再聰明的人也不知道該怎麼幫你。

而在目前的技術下,每種語言模型的 Context 容量都是有限的,有的大,有的小,簡單說就是「它一次能看多少字」也有上限。 理論上我們每次開一個新對話,模型是不會記得你之前跟它講過什麼的。每次對話的模型都像一張白紙,每次都是全新的開始。


為什麼對話越長,AI 越笨?

這不是錯覺。

你可以把 AI 想成一個幫你做事的實習生:你口頭交代他做 20 個步驟,中間只要有幾步聽錯,最後成果就會歪掉。AI 也一樣。

有研究實際測試過:AI 在處理任務時,每一步都有一定的錯誤機率。假設每個動作有 5% 的錯誤率,聽起來很低對吧?但問題是這些錯誤會累積:

對話輪數 成功率
5 輪 77.4%
10 輪 59.9%
20 輪 35.8%
50 輪 7.7%

步驟越多,累積起來就越容易歪樓。這還沒算上 Context 容量塞滿後,模型開始「遺忘」早期內容的問題。

需要說明的是,這主要發生在複雜的連續任務上。如果只是閒聊,錯了你可能也沒感覺。但如果是寫程式、做分析、或是邏輯推理,一步錯就容易全盤皆輸。

這就是為什麼你會發現:剛開始對話時 AI 很聰明,聊了一兩個小時後,它好像變笨了。不是它真的變笨,是 Context 變得太長、太雜,錯誤開始累積。


那些平台怎麼讓 AI「記得」你?

你在 ChatGPT 或 Claude 上可能會覺得:「AI 好像記得我之前說過什麼」。

但實際上,模型本身是完全沒有長期記憶的——像金魚腦一樣,每次對話都是從零開始。

那為什麼感覺它記得你?因為平台在背後幫它「帶小抄」:

  1. 摘要歷史:平台把你之前的對話整理成摘要,塞進新對話的開頭
  2. 動態搜尋:當你問問題時,平台偷偷去翻你的舊資料,把找到的內容一起丟給模型看

所以真相是:AI 不是真的記得你,而是每次都在看一份「精簡過的你和它的歷史」。

這個「記憶」是假象,但也是很聰明的設計。只是你要知道,這些「記憶」也佔用 Context 的空間。


為什麼控制 Context 是一切的關鍵

當我們了解 Context 是什麼後,大家會逐漸發現,依照語言模型的特性,如何精準掌握 Context 變得攸關重要。

因為在語言模型的演算法特性中,Context 跟任務的相關性越高,產出的品質越好;越低則越差。所以如果我們要讓 AI 發揮能力,關鍵就在於:怎麼提供高品質的 Context。

Anthropic(Claude 的開發公司)在 2025 年提出了一個觀點:我們應該從「Prompt Engineering」轉向「Context Engineering」。

差別在哪?

  • 舊思維(Prompt Engineering):「我該怎麼表達這個指令?」
  • 新思維(Context Engineering):「什麼樣的 Context 配置,最有可能讓模型產出我要的結果?」

用做菜來比喻:

  • 過去的做法是:「我教你一步一步怎麼做菜。」
  • 新的做法是:「我把所有食材和口味偏好告訴你,讓你自己決定怎麼煮最好吃。」

這個轉變很重要。過去我們專注在怎麼「問」,現在更重要的是怎麼「給資訊」。


怎樣算是好的 Context?

Anthropic 給了一個很精準的定義:找到最小但最相關的資訊組合,來達到最好的結果。

翻譯成白話就是:給的資訊要精準、相關、沒有廢話。

Context 不是越多越好。塞太多不相關的東西,反而會讓模型分心、迷失在雜訊中。就像你交辦任務給員工時,如果 briefing 裡面塞了一堆不相關的公司歷史、去年的專案紀錄、其他部門的八卦,他反而會搞不清楚重點在哪。

好的 Context 應該:

  • 和當前任務高度相關
  • 沒有多餘的雜訊
  • 包含完成任務所需的關鍵資訊
  • 結構清晰,讓模型容易理解

實際例子:同樣的問題,不同的 Context

舉個例子:

沒給 Context:

「幫我寫一封信」
→ AI 給你一封普通的制式信,什麼都沒針對。

給了基本 Context:

「幫我寫一封信給合作三年的客戶,對方最近剛換主管,語氣要正式但親切」
→ 結果完全不一樣,至少有針對性了。

給了完整 Context:

除了上面那些,你還提供:

  • 客戶的基本資料
  • 過去和客戶來往的 email
  • 這次寫信的目的和背景
  • 你們公司和對方的合作歷史

→ AI 產出的品質再上一個層次。

差別在哪?就是 Context 的質量。

如果你不想那麼麻煩,至少記住一個懶人公式:

對象是誰 + 目的是什麼 + 語氣怎麼拿捏

只要把這三件事講清楚,AI 產出的東西就會比一句「幫我寫一封信」好很多。


從「教 AI 怎麼做」到「給 AI 足夠的資訊」

前面提到,我們正從「Prompt Engineering」走向「Context Engineering」。用另一個角度來看,就是:從「教 AI 怎麼做」,變成「給 AI 足夠的資訊讓它自己決定怎麼做」。

過去在語言模型能力不足的情況下,我們給的 prompt 大多是指導 AI 該怎麼做、要遵守哪些步驟。那時候的 AI 比較像是需要詳細指令的新手。

而現在語言模型的智力和能力上來後,情況不一樣了。2025 年的模型已經夠聰明,它們知道怎麼做事。我們更多的是在提供語言模型足夠的相關內容,並藉由它的能力進行好的產出。

在 Anthropic 自己內部,他們觀察到一件有趣的事:一年之內,工程師使用 AI 的比例從 28% 漲到 59%,而且自評「產能變高了」的人也大幅增加。真正改變他們工作的,不是模型又升級了多少,而是大家越來越知道要怎麼餵對 Context。


結語

理解 Context,是跟 AI 協作的第一步。

當你知道 AI 的世界只有 Context,你就會開始思考:我該怎麼把對的資訊放進去?怎麼讓它看到它需要看到的東西?怎麼避免塞太多雜訊讓它分心?

下次你覺得 AI 變笨時,可以記一個簡單的心法:

先想「我要給什麼資訊」,再想「我要下什麼指令」。

先不要急著想「我要下什麼指令」,而是問自己:「如果這是一個新人來幫我,我會把哪些背景、資料、限制條件告訴他?」把這些寫進去,就是在做 Context Engineering。

後續我們會用不同篇幅來描述具體上我們要怎麼好好地控制 Context,而這項技術就叫做 Context Engineering