課程 Wiki 工作流
把課堂講義與 PDF 整理成課程 Wiki
把一門課的可讀講義、課件與 PDF 整理成有來源的課程 Wiki，保留概念、先備知識、來源修訂與複核狀態。
關於這篇指南
工作流程
已有一門課的可讀課堂講義、課件或 PDF，想維護可檢查學習 Wiki 的學生、自學者與教師
8 分鐘閱讀
01
先固定一門課與一組有權使用的可讀課程資料。
02
每個概念各自成頁，連回確切來源與先備知識。
03
記錄來源修訂與複核狀態，避免課件改版後筆記仍看似正確。
完整示範
用課堂筆記建立課程 wiki
這是三份講義的虛構練習：追蹤座位預訂從資料庫寫入到快取失效，再用 10 對 9 的反例檢查流程。
試做這個任務
只根據講義，回答座位預訂應如何安排資料庫寫入與快取失效。包含快取過期的反例，並列出講義沒有指定的每個數值。每個主張都用 [[filename]] 引用。
預期推理
資料庫是權威來源；先寫入資料庫，再讓快取失效。失效失敗時，下一次座位讀取必須查資料庫。資料庫有 9 個座位而快取仍顯示 10 個，證明只看快取做預訂決定不安全；租期與重試次數仍未知。
為什麼要保持這些內容連結
幾份講義可以手動複核。當修訂後的教材、反例與尚未決定的實作選擇需要在後續學習中保持連結時，來源連結的課程 wiki 才有幫助。
審查邊界
核對 10 對 9、先寫資料庫再讓快取失效，以及失效失敗後的處理；租期和重試次數保持未知。
在 Wenlan 裡查看這個範例
Wenlan v0.18.3 介面，呈現隔離測試後讀回的資料。來源是虛構教學資料，參考答案為這次練習人工編寫；畫面沒有展示 AI 自動生成或審批完成。
引用的來源變更後，Wenlan 將頁面標記為過期，正文仍保留原文。這裡的「updating…」表示等待重建，不代表已完成修正。請先檢查變更的來源，再重建並審查新答案。
來源檔案
打開檔案即可閱讀完整的人工編寫 Markdown。
三種語言檢視使用相同的人工編寫英文來源資料集。
01lecture-01-consistency.mdLecture 01 — Database is the source of truth
# Lecture 01 — Database is the source of truth In this course example, the course_seats table in the database is authoritative for available seats. A cache may accelerate reads and carries an expires_at value, but a cached value is not a booking decision. After a successful database reservation commit, the cache may still hold the old value until it is invalidated.
02lecture-02-cache-invalidation.mdLecture 02 — Invalidation follows a write
# Lecture 02 — Invalidation follows a write For a seat reservation, commit the database transaction first. Then invalidate the concrete key course-seats:course-42. If invalidation fails, mark the key stale and force the next seat read from the database; retry invalidation. Never write the cache first and assume that the database commit will succeed.
03lecture-03-counterexample.mdLecture 03 — Counterexample and unknowns
# Lecture 03 — Counterexample and unknowns At 09:00, the database says 10 seats and the cache says 10. At 09:01, a reservation commits in the database, leaving 9 seats. The invalidation worker is down, so the cache remains at 10. A cache-only availability check now overstates the seats and is unsafe for a reservation decision. These notes do not specify a cache lease duration or an automatic invalidation retry count. Leave both values unknown.
參考答案
Reference answer: write to the database first, distrust stale cache state
The database is authoritative. Commit it before invalidating the cache; after a failed invalidation, the next seat read must use the database. The 10-versus-9 counterexample proves that a cache-only reservation decision is unsafe, while lease duration and retry count remain unspecified.
Course-seat consistency — reference
Answer
The database is the source of truth for available seats. A cache can accelerate a read, but its value cannot by itself authorize a reservation. lecture-01-consistency.md
The safe order is to commit the reservation in the database first and invalidate the course-seats cache key afterward. The workflow must never write the cache first and assume that the database commit will succeed. lecture-02-cache-invalidation.md
If invalidation fails, mark the key stale, make the next seat read come from the database, and retry invalidation. lecture-02-cache-invalidation.md
Counterexample
The notes give a concrete stale-read case: the database moves from 10 to 9 seats after a reservation while the cache remains at 10 because its worker is down. A cache-only availability check therefore overstates availability and is unsafe for a reservation decision. lecture-03-counterexample.md
The lease duration and automatic invalidation retry count are not defined by these notes. Keep both as unknowns instead of inventing settings. lecture-03-counterexample.md
變更後的來源: lecture-02-cache-invalidation.md
這項變更後的預期更新
The initial reference's phrase next seat read from the database becomes too narrow. After the revised lecture, every seat decision must bypass the cache until a successful invalidation clears the stale state. Database-first ordering, the 10-versus-9 counterexample, and the unknown lease duration remain unchanged; no retry count may be invented.
# Lecture 02 — Invalidation follows a write, revision 2 For a seat reservation, commit the database transaction first. Then invalidate the concrete key course-seats:course-42. If invalidation fails, mark the key stale and route every seat decision to the database until a successful invalidation clears the stale state. Never write the cache first and assume that the database commit will succeed. The notes still do not specify an automatic retry count.
01
先說結論：一個概念配一頁與一組確切來源
先為一門課建立明確來源邊界，登錄可讀的課堂講義、筆記與可擷取文字 PDF，再把每個可重用概念維護成獨立頁面。每頁都要回答一個問題、列出先備知識、引用確切講次或頁碼、記錄來源修訂，並標示目前有效、過期、矛盾或待複核。
Wenlan 可以同步支援的文件來源、建立有來源 Pages、保留引用與 wikilink、顯示過期依賴並留下可審查修訂。它不等同 NotebookLM，不會產生單字卡、不會自動出題、不會轉錄音訊、不會執行 OCR、不會評分、不會當家教、不會解題，也不會規劃考試。
02
為什麼一份大摘要很快就會過期
一個定義可能在第二週講義，先備概念在第一週，修正在後續課件，例外又藏在閱讀筆記裡。一次性摘要會把這些關係壓成流暢文字，也可能在教師更新來源後繼續保留舊答案。
可維護的課程 Wiki 應該讓概念、來源與修訂保持分離，讓學習者能看出哪一段受哪份資料支持，以及哪一頁需要重新複核。即使不用 Wenlan，這種結構也能作為獨立、可檢查的學習成果。
03
建立課程資料到概念頁的閉環
先用少量資料驗證流程。只納入你有權儲存與閱讀的內容，並指定課程版本、學期、來源擁有者、排除資料與複核人員。
- 登錄 Markdown、文字與可擷取文字的 PDF；掃描或純圖片 PDF 先在外部完成 OCR，再人工核對文字。
- 每個概念頁只回答一個穩定問題，不要把整門課壓成一份巨型摘要。
- 明確連結先備知識、相鄰概念、矛盾說法、例題與尚未解決的問題。
- 每個重要主張附上講次、頁碼、段落或 source ID，並保存學期、檔案版本或資料日期。
- 講義或課件更新後重新同步，把受影響概念標為過期或待複核，再打開新來源確認。
- 最後執行 lint 與人工審查；來源不足時保留未知，不用 AI 自動補答案。
完成 Wenlan 與 AI 客戶端設定後
wenlan status
wenlan sources add ~/Courses/distributed-systems/materials
# 在 Wenlan plugin client 中：
/distill <課程概念>
/pages <課程概念>
/lint
/curate04
概念頁應該記錄什麼
下面的中立範本不是答案卡，而是一筆可檢查的學習紀錄。每個欄位都要回到有權使用的課程資料與具名複核人員。
中立的課程概念紀錄
concept: leader election
question: 為什麼同一個 term 不能長期存在兩個 leader？
prerequisites: term；quorum intersection
answer: <目前課程資料真正支持的短答>
sources: <講次、投影片或頁碼與 source ID>
source_revision: <學期、檔案修訂或資料日期>
review_state: <目前有效｜過期｜矛盾｜未解>
reviewer: <學生或教師>
next_review: <來源變更觸發條件或日期>05
知道這不是 AI 家教或考試工具
這個工作流只整理有來源的課程概念。Wenlan 不會製作單字卡或測驗，不會轉錄影音，不會對掃描檔執行 OCR，不會評分、代寫、解題、預測考題或安排複習進度。學生或教師仍要負責來源權利、理解、學術誠信與最後複核。
先建立一頁可檢查的課程概念
加入一小組核准來源，維護一頁有先備知識與確切來源的概念，再於課件變動後複核。
常見問題