LLM Wiki คืออะไร และต่างจากโน้ตธรรมดายังไง | Claude + Obsidian คลังความรู้ส่วนตัวที่ AI ใช้งานได้จริง | Vibe Coding Thailand
$ cat 03-what-is-llm-wiki.md บทที่ 3
LLM Wiki คืออะไร และต่างจากโน้ตธรรมดายังไง gist เรื่อง LLM Wiki ของ Andrej Karpathy: ที่มาของแนวคิดจัดความรู้ให้ LLM ใช้ต่อได้
ภาพ: gist เรื่อง LLM Wiki ของ Andrej Karpathy: ที่มาของแนวคิดจัดความรู้ให้ LLM ใช้ต่อได้
ตอนนี้เรามีสองอย่างแล้ว
จากบทที่ 1:
Obsidian = บ้านของความรู้ คัดลอก
จากบทที่ 2:
Claude = ผู้ช่วยอ่านและจัดบ้าน คัดลอก
บทนี้คือคำตอบของคำถามต่อไป:
แล้วในบ้านหลังนี้ เราควรจัดของเป็นแบบไหน?
คำตอบคือ LLM Wiki
ไม่ต้องตกใจกับชื่อ
LLM Wiki ไม่ใช่ระบบ technical สำหรับ programmer
สำหรับคนทำงานทั่วไป ให้เข้าใจแบบนี้:
LLM Wiki คือคลังความรู้ที่เขียนให้ทั้งคนและ AI อ่านรู้เรื่อง
มันต่างจากโน้ตธรรมดาตรงที่ไม่ได้เก็บแค่ “สิ่งที่เราเคยจด”
แต่มันจัดความรู้ให้ตอบคำถามได้ เช่น:
เรื่องนี้มาจาก source ไหน
fact คืออะไร
ข้อสรุปของเราคืออะไร
เกี่ยวกับโปรเจกต์ไหน
มี decision อะไรเกิดขึ้นแล้ว
ถ้าจะให้ Claude ช่วยต่อ ต้องอ่าน note ไหนก่อน
LLM Wiki เก็บข้อมูล + ความสัมพันธ์ + ที่มา + วิธีใช้ต่อ
1. ปัญหาของโน้ตธรรมดา คนทำงานจำนวนมากไม่ได้ขาดข้อมูล
เรามีข้อมูลเยอะเกินไปด้วยซ้ำ
ปัญหาคือข้อมูลอยู่แบบนี้:
ไฟล์ meeting อยู่ที่หนึ่ง
ไอเดียอยู่ใน chat
ลิงก์อยู่ใน browser
เอกสารลูกค้าอยู่ใน drive
สรุปที่ Claude เคยทำอยู่ในบทสนทนาเก่า
decision อยู่ในหัวใครบางคน คัดลอก ต่อให้คุณเอาทุกอย่างมาใส่ Obsidian ถ้าไม่มีโครง มันก็แค่ย้ายความรกจากหลายที่มาอยู่ที่เดียว
LLM Wiki จึงไม่ใช่แค่ “เก็บทุกอย่าง”
แต่คือการทำให้ความรู้แต่ละชิ้นมีหน้าที่ชัด
พอแยกแบบนี้ คุณจะหาเจอง่ายขึ้น และ Claude จะช่วยต่อได้แม่นขึ้น
2. แก่นของ LLM Wiki ในเล่มนี้ GitHub repo claude-obsidian: ตัวอย่าง LLM Wiki ที่ใช้ Claude กับ Obsidian จริง ภาพ: GitHub repo claude-obsidian: ตัวอย่าง LLM Wiki ที่ใช้ Claude กับ Obsidian จริง
สำหรับเล่มนี้ เราจะใช้ LLM Wiki แบบเรียบง่ายที่สุด
ใช้แค่ Markdown note + link + source + index ก็เริ่มได้แล้ว
Raw source ต้องอยู่ได้ : สิ่งที่เป็นต้นทางควรเก็บไว้หรืออ้างกลับได้
Wiki note ต้องอ่านง่าย : สรุปแล้ว แยกหัวข้อแล้ว ใช้ต่อได้
Link ต้องช่วยเดินทาง : note สำคัญควรเชื่อมกัน
Index ต้องพาไปถูกที่ : ไม่ต้องเปิดทุก folder เอง
Claude ต้องรู้บทบาท : ช่วยจัดและสรุป แต่ไม่แต่ง fact
ถ้าทำได้ 5 ข้อนี้ คุณมี LLM Wiki แบบใช้งานจริงแล้ว
ยังไม่ต้องสนใจคำว่า RAG, vector, embedding หรือ automation
3. Raw source กับ Wiki note ต้องแยกกัน นี่คือกติกาที่สำคัญที่สุดข้อหนึ่ง
Source คือของต้นทาง เช่น:
บทความ
PDF
meeting transcript
email จากลูกค้า
หน้าเว็บ official
research note
ข้อความสัมภาษณ์
Wiki note คือสิ่งที่เราหรือ Claude สรุปและจัดระเบียบจาก source นั้น
ส่วน wiki note คือความเข้าใจที่อาจถูกปรับได้
source: transcript ประชุมทีม sales
wiki note: สรุป pain point ลูกค้าเรื่อง AI training คัดลอก ถ้าวันหนึ่ง wiki note สรุปผิด คุณยังกลับไปดู source ได้
ถ้าวันหนึ่ง Claude เขียนสวยแต่มั่ว คุณยังมีต้นทางให้ตรวจ
ถ้าวันหนึ่งมีข้อมูลใหม่ คุณอัปเดต wiki note ได้โดยไม่ทำลาย source เดิม
นี่คือเหตุผลที่เราพูดคำว่า source-first ตลอดเล่ม
ไม่ใช่เพราะอยากให้ดูเป็นทางการ
แต่เพราะมันกัน wiki กลายเป็นกองคำตอบสวย ๆ ที่ไม่รู้ว่ามาจากไหน
4. ชนิดของ note ที่ควรมี LLM Wiki เริ่มจาก note ไม่กี่ชนิด แต่เชื่อมกันให้คนและ AI อ่านต่อได้ง่าย ภาพ: LLM Wiki เริ่มจาก note ไม่กี่ชนิด แต่เชื่อมกันให้คนและ AI อ่านต่อได้ง่าย
ตัวอย่าง Wiki Map: ใช้ให้เห็นภาพความเชื่อมโยง ไม่ใช่สิ่งที่มือใหม่ต้องทำตั้งแต่วันแรก ภาพ: ตัวอย่าง Wiki Map: ใช้ให้เห็นภาพความเชื่อมโยง ไม่ใช่สิ่งที่มือใหม่ต้องทำตั้งแต่วันแรก
สำหรับคนเริ่มต้น ใช้ note แค่ 5 ชนิดพอ
1. Source note
2. Concept note
3. Project note
4. Decision note
5. Index/Home note คัดลอก ไม่ต้องมีมากกว่านี้ในช่วงแรก
ถ้าคุณเริ่มจากชนิด note 15 แบบ คุณจะเสียเวลาคิดมากกว่าทำงาน
5. Source note: โน้ตที่บอกว่า “ข้อมูลนี้มาจากไหน” Source note ใช้เก็บข้อมูลจากแหล่งต้นทางหนึ่งชิ้น
หนึ่งบทความ = หนึ่ง source note
หนึ่ง meeting = หนึ่ง source note
หนึ่ง PDF = หนึ่ง source note
หนึ่งหน้าเว็บสำคัญ = หนึ่ง source note
Source note ควรตอบคำถามเหล่านี้:
source นี้คืออะไร
มาจากไหน
มี fact สำคัญอะไร
เกี่ยวกับงานเราอย่างไร
ควรแตกเป็น concept note อะไรบ้าง
# ชื่อ source
type: source
status: inbox
date: YYYY-MM-DD
source: ใส่ลิงก์หรือที่มา
## Summary
สรุปสั้น ๆ 3–5 บรรทัด
## Key facts
-
-
-
## Useful for
- ใช้กับงาน/โปรเจกต์ไหน
## Related notes
- [[ชื่อ note ที่เกี่ยวข้อง]]
## Questions
- คำถามที่ควรค้นต่อ คัดลอก # Meeting ทีม sales เรื่องคำถามลูกค้า AI training
type: source
status: reviewed
date: 2026-05-25
source: meeting ทีม sales
## Summary
ทีม sales พบว่าลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม และกังวลว่าทีมจะใช้ AI ไม่เป็น ทีมจึงอยากได้ FAQ หน้าเว็บ และมีไอเดียเรื่อง webinar สำหรับผู้บริหารที่ไม่ technical
## Key facts
- ลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม
- ลูกค้ากังวลว่าทีมจะใช้ AI ไม่เป็น
- ทีม sales ขอ FAQ สำหรับหน้าเว็บ
- ต้องส่ง draft FAQ ภายในศุกร์นี้
## Useful for
- [[FAQ หน้าเว็บคอร์ส AI]]
- [[AI training สำหรับคนไม่รู้โค้ด]]
## Related notes
- [[Pain point ของเจ้าของธุรกิจ SME]]
- [[AI training สำหรับคนไม่รู้โค้ด]]
## Questions
- ลูกค้ากลุ่มไหนถามเรื่องนี้มากที่สุด
- มีคำถามจริงจากลูกค้าอีกกี่ข้อ คัดลอก Source note ทำให้ Claude รู้ว่าอะไรคือข้อมูลต้นทาง
เวลาคุณถาม Claude ในอนาคต มันจะไม่ต้องเดาว่าเรื่องนี้มาจากไหน
6. Concept note: โน้ตที่อธิบายแนวคิดหนึ่งเรื่อง Concept note คือโน้ตที่อธิบาย “เรื่อง” หรือ “แนวคิด” ที่ใช้ซ้ำได้
Pain point ของเจ้าของธุรกิจ SME
AI training สำหรับคนไม่รู้โค้ด
Source-first thinking
Weekly review
Customer objection คัดลอก Concept note ต่างจาก source note ตรงนี้:
Source note ผูกกับแหล่งข้อมูลหนึ่งชิ้น
Concept note รวมความเข้าใจจากหลาย source
เรื่องนี้คืออะไร
ทำไมสำคัญ
มีตัวอย่างอะไร
ใช้กับงานไหน
มี source ไหนรองรับ
# ชื่อ concept
type: concept
status: draft
## ความหมายสั้น ๆ
อธิบายด้วยภาษาคนทั่วไป
## ทำไมเรื่องนี้สำคัญ
-
## ตัวอย่าง
-
## ใช้กับงานไหน
- [[ชื่อ project]]
## Sources
- [[ชื่อ source note]]
## Related concepts
- [[ชื่อ concept อื่น]] คัดลอก # AI training สำหรับคนไม่รู้โค้ด
type: concept
status: draft
## ความหมายสั้น ๆ
การสอนใช้ AI เพื่อช่วยงานธุรกิจ โดยไม่ตั้งต้นจากการเขียนโปรแกรม แต่ตั้งต้นจากงานจริง เช่น marketing, sales, operation, research และเอกสาร
## ทำไมเรื่องนี้สำคัญ
- ลูกค้าหลายคนเข้าใจว่า AI training ต้องเกี่ยวกับ programming
- ถ้าสื่อสารไม่ชัด ลูกค้าอาจคิดว่าคอร์สไม่เหมาะกับทีมของเขา
## ตัวอย่าง
- ใช้ Claude สรุป meeting
- ใช้ Claude ทำ FAQ จากคำถามลูกค้า
- ใช้ Claude ช่วยร่าง FAQ หรือ outline webinar
## ใช้กับงานไหน
- [[FAQ หน้าเว็บคอร์ส AI]]
- [[Webinar AI สำหรับผู้บริหาร]] ถ้าทีมตัดสินใจทำจริง
## Sources
- [[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
## Related concepts
- [[Pain point ของเจ้าของธุรกิจ SME]]
- [[ผู้บริหารไม่รู้จะเริ่มใช้ AI ตรงไหน]] คัดลอก Concept note คือสิ่งที่ทำให้ wiki เริ่ม “คิดได้”
เพราะมันไม่ใช่แค่เก็บข้อมูล แต่เริ่มรวม pattern จากหลาย source
7. Project note: ศูนย์กลางของงานหนึ่งชิ้น Project note คือหน้าเดียวที่รวม context ของงานหนึ่งงาน
Webinar AI เดือนมิถุนายน
ปรับหน้าเว็บคอร์ส AI
ทำ knowledge base ทีม sales
เขียนหนังสือ Claude + Obsidian คัดลอก Project note ช่วยให้คุณไม่ต้องถามว่า “ไฟล์ของโปรเจกต์นี้อยู่ไหนบ้าง?”
ทุกอย่างควรกลับมาที่ project note
# ชื่อโปรเจกต์
type: project
status: active
owner:
deadline:
## เป้าหมาย
โปรเจกต์นี้ต้องการผลลัพธ์อะไร
## Context สำคัญ
-
## Sources
- [[source note]]
## Concepts ที่เกี่ยวข้อง
- [[concept note]]
## Decisions
- [[decision note]]
## Todo
- [ ]
- [ ]
## Next review
YYYY-MM-DD คัดลอก # FAQ หน้าเว็บคอร์ส AI
type: project
status: active
owner: หมิว
deadline: ศุกร์นี้
## เป้าหมาย
สร้าง FAQ หน้าเว็บเพื่อตอบข้อกังวลของลูกค้าว่า AI training ต้องรู้โค้ดไหม และทีม business ใช้ได้จริงหรือไม่
## Context สำคัญ
- ลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม
- ลูกค้าหลายคนกังวลว่าทีมจะใช้ AI ไม่เป็น
- ทีม sales ต้องการ FAQ สำหรับหน้าเว็บ
## Sources
- [[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
## Concepts ที่เกี่ยวข้อง
- [[AI training สำหรับคนไม่รู้โค้ด]]
- [[Pain point ลูกค้าเรื่องทีมใช้ AI ไม่เป็น]]
## Decisions
- ยังไม่มี decision ชัดเจนใน source นี้
## Todo
- [ ] ขอคำถามจริงจากทีม sales
- [ ] ร่าง FAQ 10 ข้อ
- [ ] ส่ง draft ให้ทีม sales ตรวจ
## Next review
YYYY-MM-DD คัดลอก เวลาให้ Claude ช่วยงาน project นี้ คุณไม่ต้องเล่าทุกอย่างใหม่
ส่ง project note พร้อม note ที่ link อยู่ แล้วให้ Claude สรุป context กลับมาก่อนเริ่มทำงาน
8. Decision note: โน้ตที่บอกว่า “เราตัดสินใจอะไรไปแล้ว” นี่คือ note ที่หลายคนไม่มี แต่ควรมีมาก
เพราะงานจริงไม่ได้พังเพราะไม่มีไอเดีย
งานจริงพังเพราะลืมว่าเคยตัดสินใจอะไรไปแล้ว
Decision note ใช้เก็บการตัดสินใจสำคัญ เช่น:
เลือกกลุ่มเป้าหมายไหนก่อน
ใช้ชื่อ campaign ว่าอะไร
ตัด feature ไหนออก
เลื่อน deadline เพราะอะไร
ทำไมไม่เลือกทางเลือกหนึ่ง
# ชื่อ decision
type: decision
date: YYYY-MM-DD
status: decided
## Decision
เราตัดสินใจว่าอะไร
## Why
เหตุผลคืออะไร
## Options considered
- ทางเลือก A
- ทางเลือก B
## Evidence / Sources
- [[source note]]
## Impact
สิ่งที่ต้องทำต่อหรือสิ่งที่จะเปลี่ยน
## Related project
- [[project note]] คัดลอก ตัวอย่างด้านล่างใช้ในกรณีที่ทีม “ยืนยันแล้ว” ว่าจะทำ webinar จริง
ถ้ายังเป็นแค่คำว่า “ควรมี webinar” ให้เก็บไว้เป็น Idea ก่อน อย่าเพิ่งสร้าง decision note
# Decision - ทำ webinar สำหรับผู้บริหารที่ไม่ technical - 2026-05-25
type: decision
date: 2026-05-25
status: decided
## Decision
ทีมตัดสินใจทำ webinar หัวข้อ AI สำหรับผู้บริหารที่ไม่รู้โค้ด
## Why
ทีมต้องการตอบข้อกังวลของลูกค้าว่า AI training ต้องรู้โค้ดไหม และทีม business ใช้ได้จริงหรือไม่
## Options considered
- ทำเฉพาะ FAQ หน้าเว็บ
- ทำ webinar สำหรับผู้บริหารเพิ่มเติม
## Evidence / Sources
- [[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
- [[Meeting ที่ทีมยืนยันแผน webinar]]
## Impact
- ต้องสร้าง project note สำหรับ webinar
- หน้า landing page ต้องย้ำว่าไม่ต้องรู้โค้ด
- ตัวอย่างใน webinar ต้องเป็นงาน business จริง
## Related project
- [[Webinar AI สำหรับผู้บริหาร]] คัดลอก Decision note ช่วย Claude มาก เพราะมันกันไม่ให้ Claude พูดเหมือน idea เป็นสิ่งที่ตกลงแล้ว
9. Index note: ประตูหน้าบ้านของ Wiki ถ้า wiki มี note เยอะขึ้น แต่ไม่มี index คุณจะเริ่มหลง
Index note ไม่ต้องซับซ้อน
เริ่มจากหน้า Home หรือ Index แบบนี้:
# Home
## Projects สำคัญ
- [[FAQ หน้าเว็บคอร์ส AI]]
## Concepts สำคัญ
- [[AI training สำหรับคนไม่รู้โค้ด]]
- [[Pain point ของเจ้าของธุรกิจ SME]]
## Sources ล่าสุด
- [[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
## Decisions ล่าสุด
- ยังไม่มี decision ชัดเจนจาก source แรก
## ต้อง review
- [ [ 00-inbox ] ] คัดลอก ให้คิดว่า index note คือหน้าแรกที่คุณและ Claude ควรอ่านก่อนเริ่มงาน
ถ้า project ใหญ่ขึ้น อาจมีหลาย index เช่น:
Index ลูกค้า
Index content ideas
Index โปรเจกต์ active
Index sources
แต่เริ่มจาก Home หน้าเดียวก่อนพอ
10. Wiki ที่ดีต้องมี log แบบง่าย ถ้าคุณอยากเพิ่มอีกหนึ่งไฟล์ ให้เพิ่ม Log.md
Log คือบันทึกว่า wiki เปลี่ยนอะไรไปบ้าง
# Log
## 2026-05-25
- เพิ่ม source note จาก meeting ทีม sales
- แตก concept note: [[AI training สำหรับคนไม่รู้โค้ด]]
- สร้าง project note: [[FAQ หน้าเว็บคอร์ส AI]]
- บันทึก idea: webinar สำหรับผู้บริหารที่ไม่ technical คัดลอก Log มีประโยชน์เมื่อคุณกลับมาหลังจากหายไปหลายวัน แล้วจำไม่ได้ว่าทำอะไรไว้
และมีประโยชน์มากเมื่อให้ Claude ช่วยต่อ
คุณสามารถส่ง Home + Log + project note ให้ Claude แล้วถามว่า:
ช่วยสรุปสถานะล่าสุดของ wiki นี้ และบอกว่าควรทำอะไรต่อ คัดลอก
11. LLM Wiki ต่างจาก RAG ยังไง แบบไม่ technical RAG = ตอนถาม ค่อยไปค้นเอกสารมาประกอบคำตอบ
LLM Wiki = อ่านและจัดความรู้ไว้ก่อน แล้วค่อยถามจากสิ่งที่จัดแล้ว คัดลอก RAG เหมือนคุณมีกล่องเอกสารใหญ่ ๆ แล้วทุกครั้งที่มีคำถาม ผู้ช่วยต้องรื้อกล่องใหม่
LLM Wiki เหมือนคุณมีแฟ้มที่จัดหมวดแล้ว มีสารบัญ มีสรุป มี post-it บอกว่าเรื่องไหนเกี่ยวกับเรื่องไหน
สำหรับคนทำงานทั่วไปที่มี source หลักสิบถึงหลักร้อย LLM Wiki มักเริ่มง่ายกว่า เพราะใช้แค่ note + link + index
แต่ไม่ต้องเอาไปเถียงว่าอะไรดีกว่าทุกกรณี
เล่มนี้สนใจแค่คำถามเดียว:
วิธีไหนทำให้คุณใช้ Claude กับความรู้ของตัวเองได้ดีขึ้นเร็วที่สุด?
สำหรับเป้าหมายนี้ LLM Wiki แบบเรียบง่ายตอบโจทย์
12. กติกา 6 ข้อของ LLM Wiki ขนาดเล็ก ถ้าจำทั้งบทไม่ได้ ให้จำ 6 ข้อนี้
1. Source ไม่ใช่ Summary อย่าให้สรุปของ Claude แทนที่ source ทั้งหมด
ถ้ามี source สำคัญ ให้เก็บที่มาไว้เสมอ
2. หนึ่ง note หนึ่งหน้าที่ อย่าเอา source, concept, todo, decision และ project มาปนกันหมดในหน้าเดียว
3. Link เฉพาะที่ช่วยให้คิดต่อ link เฉพาะเรื่องที่ควรเปิดอ่านต่อจริง ๆ
4. Index ต้องมีชีวิต ถ้าสร้าง note สำคัญ ให้เพิ่มเข้า Home หรือ index ที่เกี่ยวข้อง
5. Claude ช่วยจัด แต่คุณตรวจ ให้ Claude เสนอได้ แต่อย่าให้ Claude ตัดสินใจแทนทุกอย่าง
6. Wiki ต้องเล็กพอให้ใช้ต่อ ถ้าระบบเริ่มซับซ้อนจนคุณไม่อยากเปิด แปลว่าระบบใหญ่เกินไป
13. Prompt สำหรับให้ Claude สร้างชุด note จาก source หนึ่งชิ้น เมื่อคุณมี source หนึ่งชิ้น ลองใช้ prompt นี้
ฉันกำลังทำ LLM Wiki ใน Obsidian
ช่วยแปลง source นี้เป็นชุด note ที่ใช้ต่อได้
ขอผลลัพธ์เป็น 5 ส่วน:
1. Source note: สรุป source และ key facts
2. Concept notes ที่ควรแตกออกมา
3. Project note ที่เกี่ยวข้อง ถ้ามี
4. Decision note ถ้ามีการตัดสินใจใน source
5. Index update: ควรเพิ่ม link อะไรเข้า Home หรือ Index
กติกา:
- แยก fact / inference / idea ให้ชัด
- อย่าแต่งข้อมูลที่ไม่มีใน source
- ถ้าไม่ควรสร้าง note ใหม่ ให้บอกว่าไม่ควรสร้าง
- ใช้ชื่อ note ที่คนทำงานทั่วไปอ่านแล้วเข้าใจ
- เขียนเป็น Markdown ที่ copy ไปใส่ Obsidian ได้ คัดลอก อย่าเพิ่งใช้กับ source 20 ชิ้น
เริ่มจาก source เดียวก่อน
อ่านผลลัพธ์ ตรวจ แก้ แล้วค่อยเก็บ
14. ตัวอย่างจาก meeting note เดิม จากบทที่ 2 เรามี meeting note นี้:
ประชุมทีม sales 25 พ.ค.
ลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม
หลายคนกลัวทีมใช้ไม่เป็น
ทีม sales อยากได้ FAQ หน้าเว็บ
ควรมี webinar สำหรับผู้บริหารที่ไม่รู้ technical
ต้องส่ง draft FAQ ภายในศุกร์นี้ คัดลอก ถ้าแปลงเป็น LLM Wiki จริง ๆ เราอาจได้ 3–4 note ก่อน:
/10-sources/Meeting ทีม sales เรื่องคำถามลูกค้า AI training.md
/30-concepts/AI training สำหรับคนไม่รู้โค้ด.md
/30-concepts/Pain point ลูกค้าเรื่องทีมใช้ AI ไม่เป็น.md
/40-projects/FAQ หน้าเว็บคอร์ส AI.md คัดลอก ส่วน webinar ยังเป็น idea จนกว่าทีมจะยืนยันจริง
จาก meeting note ดิบ 6 บรรทัด เราไม่ได้แค่ “สรุป”
เราเปลี่ยนมันเป็นโครงความรู้ที่ใช้ต่อได้หลายทาง:
ทีม sales ใช้ทำ FAQ
ทีม marketing ใช้ต่อยอดเป็น landing page
Claude ใช้อ่าน context ก่อนร่าง FAQ หรือ content
ทีมคุยต่อได้ว่า webinar เป็นแค่ idea หรือจะตัดสินใจทำจริง
นี่คือความต่างระหว่างโน้ตธรรมดากับ LLM Wiki
15. อย่าทำให้ Wiki ใหญ่เกินชีวิตจริง ข้อผิดพลาดที่พบบ่อยคือเริ่มสนุกกับระบบ
สุดท้ายไม่ได้ใช้ทำงานจริง
LLM Wiki ที่ดีไม่ใช่ wiki ที่ซับซ้อนที่สุด
แต่คือ wiki ที่คุณกลับมาใช้ได้ทุกสัปดาห์
ถ้าคุณอธิบายระบบของตัวเองให้เพื่อนร่วมงานเข้าใจไม่ได้ใน 2 นาที ระบบนั้นซับซ้อนเกินไป
ระบบเริ่มต้นของเราจึงมีแค่นี้:
Source note = ข้อมูลมาจากไหน
Concept note = เรื่องนี้คืออะไร
Project note = งานนี้กำลังทำอะไร
Decision note = ตัดสินใจอะไรไปแล้ว
Index note = เริ่มอ่านตรงไหน คัดลอก
สรุปท้ายบท LLM Wiki ไม่ใช่การจดโน้ตให้เยอะขึ้น
แต่คือการจัดความรู้ให้ใช้ต่อได้ง่ายขึ้น
Raw source คือหลักฐาน
Wiki note คือความเข้าใจที่จัดระเบียบแล้ว
Source note เก็บข้อมูลจากแหล่งต้นทาง
Concept note รวมแนวคิดที่ใช้ซ้ำ
Project note เป็นศูนย์กลางของงาน
Decision note กันลืมว่าเคยเลือกอะไรไปแล้ว
Index note คือประตูหน้าบ้าน
Log ช่วยบอกว่า wiki เปลี่ยนอะไรไปบ้าง
Claude ช่วยสร้างและดูแล note ได้ แต่คุณต้องตรวจ
บทต่อไป เราจะลงมือจัดบ้านจริง
ตั้งค่า Vault แรกใน 30 นาที
ไม่ใช่แค่รู้ว่า note มีกี่ชนิด แต่จะสร้าง folder, Home, template และ note แรกให้พร้อมใช้
Artifact ท้ายบท: Note 5 ชนิดที่ต้องรู้ Source note = ข้อมูลนี้มาจากไหน
Concept note = เรื่องนี้คืออะไร
Project note = งานนี้กำลังทำอะไร
Decision note = ตัดสินใจอะไรไปแล้ว
Index note = เริ่มอ่านตรงไหน คัดลอก
Artifact ท้ายบท: Prompt สร้างชุด note จาก source หนึ่งชิ้น ฉันกำลังทำ LLM Wiki ใน Obsidian
ช่วยแปลง source นี้เป็นชุด note ที่ใช้ต่อได้
ขอผลลัพธ์เป็น 5 ส่วน:
1. Source note: สรุป source และ key facts
2. Concept notes ที่ควรแตกออกมา
3. Project note ที่เกี่ยวข้อง ถ้ามี
4. Decision note ถ้ามีการตัดสินใจใน source
5. Index update: ควรเพิ่ม link อะไรเข้า Home หรือ Index
กติกา:
- แยก fact / inference / idea ให้ชัด
- อย่าแต่งข้อมูลที่ไม่มีใน source
- ถ้าไม่ควรสร้าง note ใหม่ ให้บอกว่าไม่ควรสร้าง
- ใช้ชื่อ note ที่คนทำงานทั่วไปอ่านแล้วเข้าใจ
- เขียนเป็น Markdown ที่ copy ไปใส่ Obsidian ได้ คัดลอก
อ้างอิงหลักของบทนี้
Andrej Karpathy: LLM Wiki gist
AgriciDaniel/claude-obsidian: LLM Wiki Pattern note
AgriciDaniel/claude-obsidian: Wiki vs RAG note
AgriciDaniel/claude-obsidian: Source-First Synthesis note
AgriciDaniel/claude-obsidian: source/concept/question/comparison templates
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย