大家好，我是TIMEWELL的濱本。這是「AI原生新事業開發方法論」的最終篇。我在大型企業做了十年以上的新事業，曾擔任有超過一百家大型企業參與的挑戰者支援計畫「CHANGE by ONE JAPAN」的營運負責人，現在營運面向創業者與企業內創業者的AI驅動開發計畫「WARP ENTRE」。第1篇到第3篇，依序寫了聽、化為假設、化為文件。最終篇，談的是把這些不是「做一次」，而是「每週、穩定地」跑起來的機制。
系列「AI原生新事業開發方法論」 ①在顧客訪談中當場做出示意畫面的技術 ②一天內跑完精實畫布、7 Powers與設計概念 ③規格驅動開發（SDD）重回焦點，文件正在變成程式碼 ④用AGENTS.md、Skills、Hooks與cron養出組織的脈絡（本文）
新事業的工作，分為一次性的工作和重複的工作。訪談的擷取、假設追蹤表的更新、監控競爭對手的動向、每週的進度報告、經營會議資料的草稿。把重複的工作交給代理，第一次順利，到了第三次左右品質開始飄。原因幾乎都不在提示詞，而是代理在讀的「脈絡」從第一次之後就沒更新、混進了多餘的東西，或者根本沒讀到組織的脈絡。
我之前在脈絡工程入門用宮大工棟樑的「準備八分」來比喻，寫了讓代理一擊完成工作的脈絡設計。那篇談的是個人把一次工作做好；這一篇是續篇，談組織如何讓重複的工作穩定。
摘要：定期執行工作的表現，由AGENTS.md（每次都讀的事實與規範，200行以內）、Skills（需要時才讀的程序，SKILL.md與輔助腳本）、Hooks（機械式擋下文件擋不住的操作）、cron（依時刻啟動）四個零件，以及把公司內部知識知識圖譜化的資料集決定。以組織運作時的紀律有三：持續更新脈絡（同樣的錯誤出現第二次就寫下來）、排除脈絡之外的資訊（防止context rot；從程式碼或資料能推導的事不寫）、提高技能更新頻率（每週跑Lint與評估）。穩定的表現，就繫於這三件事做不做得到。
把脈絡工程重新理解為「組織的機制」
從定義開始。2025年6月，Shopify執行長Tobi Lütke寫道，「脈絡工程」比「提示工程」更能表達核心技能：「為了讓LLM有可能解決任務而提供所有脈絡的技術」1。Andrej Karpathy回應「+1」，把脈絡工程定義為「為了下一步，用恰到好處的資訊填滿脈絡視窗的精細藝術與科學」，並接著說：太少、形式不對，就沒有性能；太多、不相關，成本上升而性能下降1。
Anthropic在2025年9月的技術文章中，把這個「太多也會下降」整理成實驗上的知見。脈絡是「重要但有限的資源」，token越多，模型正確回想脈絡內資訊的能力就越低。他們稱之為「context rot」，並指出好的脈絡工程是「找到能最大化期望結果機率的、盡可能小的高訊號token集合」2。
到這裡為止，都是以一位工程師做一個應用的角度在談。我想說的是，這必須以組織的角度重讀。組織裡有大量的隱性前提。這位客戶的稱謂要這樣用。這個產品名不用舊名稱呼。簽核路徑依金額而不同。去年失敗的原因是這個。把這些前提，維持在代理「每次都能讀到恰到好處的量」的狀態，就是組織的脈絡工程。就算有一個人很會寫提示詞，那個人休假的那一週品質就下滑，就不算機制。
四個零件：AGENTS.md、Skills、Hooks、cron
機制由四個零件構成。名稱依工具略有不同，角色是共通的。這裡以Claude Code的官方文件與開放規格為依據，依角色整理。
| 零件 | 角色 | 何時被讀 | 內容的性質 |
|---|---|---|---|
| AGENTS.md / CLAUDE.md | 常態的前提。規範、禁止事項、專案的事實 | 每個工作階段開始時一定讀 | 事實。200行以內 |
| Skills（SKILL.md） | 特定工作的程序書與輔助腳本 | 只在需要那項工作時 | 程序 |
| Hooks | 操作前後機械式執行的處理：擋下、記錄、通知 | 工具執行前後、工作階段開始時等 | 強制 |
| cron / 排程 | 依時刻或間隔啟動工作 | 指定的時刻 | 時鐘 |
AGENTS.md是給代理的README。這是OpenAI的Codex、Google的Jules等許多代理都會讀的共通格式，已有超過6萬個開源專案採用3。Claude Code讀的是CLAUDE.md，但寫上@AGENTS.md就能匯入，所以一份文件可以讓兩邊都讀4。寫法的要點，官方文件寫得很清楚。以每個檔案200行以內為準；越長越消耗脈絡，遵守率越低。要寫得具體、可驗證：不是「把程式碼寫乾淨」而是「縮排用2個空格」，不是「測試你的變更」而是「commit前執行npm test」4。
該寫什麼的判斷基準，同一份文件也有。代理犯了第二次同樣的錯時。程式碼審查指出了它本該知道的事時。上一次工作階段打過的更正，這次又打了時。新成員需要同樣的脈絡時。只在這些時候補上4。反過來說，其他情況就不寫。
Skills是程序書。在Agent Skills的開放規格中，技能是包含SKILL.md檔案的資料夾，寫有名稱與說明的中繼資料以及程序，需要的話還同捆執行腳本、參考資料、範本5。和AGENTS.md的分工，官方文件的一句話就說盡了：「反覆貼上同樣的指示、檢查清單或多步驟程序時，或CLAUDE.md的某一段已從事實長成程序時，就建立技能。和CLAUDE.md不同，技能的本文只在被使用時載入」6。事實放在每次都讀的文件，程序放在技能。這個分離，是把脈絡維持得小的第一個手段。
Hooks是強制。這是很多人忽略的零件。Claude Code的官方文件明確寫道，CLAUDE.md與記憶都被「當成脈絡處理，而非強制的設定」，並指引「若要不論代理的判斷都擋下操作，請使用PreToolUse的Hook」4。文件裡寫「不要碰正式環境」，那是脈絡：被遵守的機率高，但不是保證。Hook是在工具執行前一刻執行外部腳本、不符條件就擋下的機制，所以是保證。對外送出、變更正式環境、讀取機密資訊。這類「錯一次就麻煩」的操作，用Hook而不是文件來擋。我之前在Claude Code Hooks完全指南整理了事件的種類與寫法。
cron是時鐘。Claude Code有三種方式：在工作階段開著的狀態下重複的/loop、在自己機器上跑的Desktop排程工作，以及在Anthropic管理的雲端上跑的Routines。依官方的比較表，雲端方式不需要讓機器開著、不會跳出許可提示而自主執行，最短間隔1小時，碰不到本機檔案，在新clone的環境中執行7。無人執行的工作放雲端，需要本機檔案的工作放Desktop，這樣區分。我之前在Hermes Agent入門介紹的開源代理也有同類的cron，無人執行時碰到危險指令會預設拒絕。無人的工作，要先決定擋下的線。這在任何工具都一樣。
把公司內部的脈絡當成「知識圖譜化的資料集」來養
四個零件齊了，代理讀的「公司內部知識」本身若是散落各處，每次都得從零開始找。這裡要談我認為最重要的想法：把公司內部的脈絡，不當成待檢索的文件堆，而是當成要養大的資料集來持有。
Karpathy在2026年4月公開的「LLM Wiki」這篇短文，最簡潔地說明了這個想法。多數人使用LLM與文件的方式是RAG，也就是每次提問時從原始文件檢索相關段落來回答，那裡沒有累積。他提出的是：讓LLM把讀到的資訊納入，持續維護相互連結的Markdown wiki。每有新資訊進來，LLM就做摘要、更新既有頁面、在與舊主張矛盾的地方做記號。「知識編譯一次，之後持續保持最新。」他把這個架構形容為「Obsidian是編輯器，LLM是程式設計師，wiki是程式庫」8。
這篇文件裡我認為特別重要的有三點。一是三層結構：原始資料來源（不變。LLM讀但不改）、wiki（LLM擁有、書寫、維護）、以及schema（CLAUDE.md或AGENTS.md，定義wiki結構與作法的「關鍵設定檔」）。二是「Lint」這個操作：定期讓LLM為wiki做健康檢查，找出頁面之間的矛盾、被新資料來源覆蓋的過時主張、沒有連結的孤立頁面、被提及卻沒有專頁的概念。三是對業務團隊的應用：以Slack討論串、會議紀錄、專案文件、客戶通話為材料，由人審查、LLM維護的公司內部wiki8。
「知識圖譜化」，就是把這些相互連結，明確地以人名、產品名、客戶名、課題等實體與它們之間的關係來持有。我們的ZEROCK就是以這種形式（GraphRAG）持有公司內部文件，讓代理能追溯「這位客戶、這個產品、去年的失敗」之間的連結。不過這裡要說的不是產品，而是順序。不要一開始就想建圖譜。先把第1篇的訪談擷取結果、第2篇的假設追蹤表、第3篇的四份文件，當成Markdown的wiki放在同一個地方，讓代理維護，每週跑一次Lint。光是這樣，下一週的代理就能以「到上週為止知道的事」為前提開始工作。圖譜，是wiki養大之後、真的有需要時才畫的。
以組織運作時的三項紀律：更新、排除、頻率
這是本文最想傳達的部分。個人整理脈絡，和組織運作脈絡，難度的性質不同。個人的話，能察覺自己腦中和文件的落差；在組織裡，寫的人調走了、前提變了、沒人修正，文件就這樣留著。代理每次都忠實地讀那份過時的文件。能不能穩定地拿出表現，繫於以下三件事。
紀律1：持續更新脈絡。 先決定更新的觸發條件。把前面提到的「同樣的錯出現第二次就寫」「審查被指出就寫」「同樣的更正打第二次就寫」訂成團隊規則。也決定由誰寫。我建議的方式，是讓代理打草稿，由人審查後合併。如第3篇所寫，文件是程式碼。AGENTS.md的變更也透過pull request看差異。負責人換了，紀錄還在。
紀律2：排除脈絡之外的資訊。 比更新更難的是刪。Anthropic所說的context rot，過時的敘述、重複、不相關的資訊累積得越多就越嚴重。判斷基準有兩個。一是「從程式碼或資料能推導的事不寫」。Claude Code的/doctor會提議刪除目錄結構、函式庫清單這類從程式碼就能推導的內容，只保留陷阱、理由、與預設不同的規範4。把這個基準也套用在人寫的文件上。二是「不需要每次都讀的東西，移到路徑限定或技能」。只在特定目錄需要的規範，放成路徑限定的規則，就只在碰到相關檔案時才被讀4。程序移到技能。這樣把每次都讀的文件維持在200行以內。刪除是令人害怕的作業，所以讓代理跑Lint：「請列出這份文件中，從程式碼就能推導的敘述、這半年未被參照的敘述、與其他文件矛盾的敘述。」刪的判斷由人做，列候選是代理的工作。
紀律3：提高技能的更新頻率。 技能是程序書，業務一變就過時。忠實執行過時程序書的代理，最危險。Claude Code的官方文件備有找出未使用技能的方法，以及評估並改善技能的程序6。我建議的頻率是每週。一週一次，由人為那週用過的技能結果打分數，修正偏掉的程序。沒被用到的技能，不是說明寫得差，就是已經不需要了，修或刪。這個「每週的Lint與打分」有沒有在跑，三個月後代理的穩定度會完全不同。
三項紀律的共通點，在於重心是「維持」而不是「寫」。一開始寫出一份漂亮的AGENTS.md，誰都做得到。半年後，它是否仍然是200行、正確、沒有矛盾。組織AI活用的成敗，就在那裡決定。
用四個零件設計一項定期執行的工作
舉一個完整的具體例子：把第1篇寫的顧客訪談擷取與假設追蹤表更新，每週五自動跑。
首先，在AGENTS.md寫事實：假設追蹤表檔案的位置、表格各欄的意義、「一則發言不能變成已驗證」的規範、只能讀已遮蔽個人資料的檔案這個禁止事項。20行就夠。接著，把擷取的程序做成技能。SKILL.md裡放第1篇的提示詞原文、引用與時間戳記為必填的規則、示意畫面出現後的發言要加標記的規則、輸出格式。同捆一支輔助腳本，機械式地從逐字稿偵測個人資料的候選。
Hook放兩個。一個是代理試圖讀取遮蔽尚未完成的檔案時擋下；另一個是把結果送到Slack或公司外部的操作之前，要求人的核准。不是在文件裡寫「不要送」，而是機械式地擋。最後用cron在週五17點啟動技能。要無人執行的話，選不會跳出許可提示的雲端方式，相對地用Hook讓送出等待核准。
然後是下週一。負責人花10分鐘讀代理更新的假設追蹤表差異與擷取結果。混進沒有引用的洞察，就修技能的程序；表格欄位不夠，就修AGENTS.md。這10分鐘，就是紀律1和3的實體。每月一次，讓代理對整個wiki跑Lint，刪除矛盾與過時的主張。這是紀律2。
大型企業跑這套時的陷阱，在於公司內部wiki的過去。很多公司都有一個再也沒人更新的內部wiki。為了不用代理重蹈覆轍，一開始就要定好分工：「維護的工作交給代理，人只做審查」。借Karpathy的話，「團隊裡沒人想做的維護工作由LLM來做，所以wiki能保持最新」8。人做的，是審查，以及刪的判斷。
在WARP裡，我們用參與者的主題實際組起這四個零件，並無人執行一週看看。四篇系列所寫的方法論全貌，對應到WARP頁面上的計畫結構。
結語
重複工作的表現，不由提示詞決定，而由脈絡的機制決定。事實放AGENTS.md，程序放Skills，擋下的線放Hooks，時刻放cron。公司內部的知識，不當成待檢索的堆，而是當成由代理維護、由人審查的wiki來養，需要時再畫成圖譜。而以組織運作時，一切繫於三項紀律：持續更新、排除脈絡之外的資訊、提高技能的更新頻率。
四篇系列寫下來，說的終究是順序。先問再做。把做出來的東西化為假設。把假設化為文件。把文件做成機制，每週跑。AI能在其中任何一步提高速度，但不會替你決定順序。明天就要動手的話，先打開自家的AGENTS.md數一數行數。超過200行的話，就從找出從程式碼或資料能推導的行開始。想和我們一起設計組織的脈絡的話，歡迎透過個別諮詢聊聊。
Footnotes
-
Andrej Karpathy（X，2025年6月25日）「+1 for "context engineering" over "prompt engineering"…」（回應tobi lutke 6月19日的貼文「the art of providing all the context for the task to be plausibly solvable by the LLM」） ↩ ↩2
-
Effective context engineering for AI agents（Anthropic Engineering，2025年9月29日） ↩
-
AGENTS.md — A simple, open format for guiding coding agents（「used by over 60k open-source projects」，2026年9月12日取得） ↩
-
How Claude remembers your project — Claude Code Docs（CLAUDE.md與auto memory、200行的基準、新增的判斷基準、匯入AGENTS.md、/doctor、路徑限定規則、「context, not enforced configuration」） ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Extend Claude with skills — Claude Code Docs（建立技能的判斷基準、偵測未使用的技能、評估與改善） ↩ ↩2
-
Run prompts on a schedule — Claude Code Docs（/loop、Desktop排程工作、雲端Routines的比較表） ↩
-
LLM Wiki — A pattern for building personal knowledge bases using LLMs（Andrej Karpathy，GitHub Gist，2026年4月4日） ↩ ↩2 ↩3
