Workflow: จาก source หนึ่งชิ้นเป็น Wiki ที่ใช้ต่อได้ | Claude + Obsidian คลังความรู้ส่วนตัวที่ AI ใช้งานได้จริง | Vibe Coding Thailand$ cat 05-source-to-wiki-workflow.md บทที่ 5Workflow: จาก source หนึ่งชิ้นเป็น Wiki ที่ใช้ต่อได้
บทที่ 4 เราตั้งบ้านแล้ว
ตอนนี้คุณมี vault มี folder มี Home มี Log และมี template พื้นฐาน
บทนี้คือหัวใจของการใช้จริง:
ทำยังไงให้ข้อมูลหนึ่งชิ้น กลายเป็นความรู้ที่ใช้ต่อได้
ข้อมูลหนึ่งชิ้นอาจเป็นอะไรก็ได้:
- meeting note
- บทความ
- PDF
- email ลูกค้า
- หน้าเว็บคู่แข่ง
- transcript จาก call
- สรุปที่ Claude เคยทำไว้
- ไอเดียที่คุณจดตอนเดินทาง
ถ้าคุณแค่โยนทั้งหมดเข้า Obsidian มันจะกลายเป็นกองของที่หาไม่เจอ
แต่ถ้าคุณใช้ workflow ที่ชัด ข้อมูลหนึ่งชิ้นจะกลายเป็น:
- source note ที่มีที่มา
- concept note ที่ใช้ซ้ำได้
- project note ที่ทำงานต่อได้
- decision note ที่กันลืม
- link ใน Home หรือ index ที่หาเจอ
นี่คือจุดที่ LLM Wiki เริ่มมีประโยชน์จริง
Workflow ทั้งบทใน 7 ขั้น
Workflow หลักคือเปลี่ยน source หนึ่งชิ้นให้กลายเป็น Wiki ที่ใช้ต่อได้
ภาพ: Workflow หลักคือเปลี่ยน source หนึ่งชิ้นให้กลายเป็น Wiki ที่ใช้ต่อได้
จำแค่ 7 คำนี้พอ:
Capture → Clean → Ask Claude → Split → Link → Save → Review
- Capture: เก็บข้อมูลเข้า inbox
- Clean: ทำให้ข้อมูลอ่านได้
- Ask Claude: ให้ Claude ช่วยสรุปและจัดรูป
- Split: แยกเป็น note ที่ถูกชนิด
- Link: เชื่อมกับ note เดิม
- Save: ย้ายเข้าที่และอัปเดต Home/Log
- Review: อ่านตรวจ ไม่เชื่อ AI แบบอัตโนมัติ
หนึ่ง source ใช้เวลาประมาณ 10–20 นาที
ถ้าเป็น source สำคัญมาก อาจนานกว่านั้น
แต่ถ้า source ธรรมดาแล้วใช้เวลาเป็นชั่วโมง แปลว่าคุณกำลังทำละเอียดเกินไป
ตัวอย่าง source ของบทนี้
เราจะใช้ตัวอย่างเดิมจากบทก่อน เพื่อให้เห็นภาพต่อเนื่อง
ประชุมทีม sales 25 พ.ค.
ลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม
หลายคนกลัวทีมใช้ไม่เป็น
ทีม sales อยากได้ FAQ หน้าเว็บ
ควรมี webinar สำหรับผู้บริหารที่ไม่รู้ technical
ต้องส่ง draft FAQ ภายในศุกร์นี้
Source นี้สั้นมาก แต่มีข้อมูลหลายแบบปนกัน:
- fact จากทีม sales
- pain point ของลูกค้า
- idea เรื่อง webinar
- project เรื่อง FAQ
- deadline
ถ้าจดไว้เฉย ๆ มันเป็นแค่บันทึกประชุม
ถ้าแปลงเป็น LLM Wiki มันกลายเป็น knowledge asset
Step 1: Capture: เก็บเข้าที่เดียวก่อน
เวลาเจอข้อมูลใหม่ อย่าเพิ่งคิดว่าจะจัดลง folder ไหน
Inbox - Meeting ทีม sales 2026-05-25
ใส่ source ดิบลงไปแบบนี้:
# Inbox - Meeting ทีม sales 2026-05-25
type: inbox
status: raw
date: 2026-05-25
source: meeting ทีม sales
## Raw note
ประชุมทีม sales 25 พ.ค.
ลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม
หลายคนกลัวทีมใช้ไม่เป็น
ทีม sales อยากได้ FAQ หน้าเว็บ
ควรมี webinar สำหรับผู้บริหารที่ไม่รู้ technical
ต้องส่ง draft FAQ ภายในศุกร์นี้
ทำไมต้องเก็บแบบ raw ก่อน?
เพราะตอน capture เป้าหมายคือ “อย่าให้ข้อมูลหาย”
ยังไม่ต้องคิดชื่อ concept
ยังไม่ต้องทำ project note
Step 2: Clean: ทำให้ source อ่านได้
ก่อนส่งให้ Claude อ่าน ลองเช็ก 5 อย่าง:
- มีวันที่ไหม
- มีที่มาไหม
- มีบริบทสั้น ๆ ไหมว่า source นี้คืออะไร
- มีคำย่อหรือชื่อเฉพาะที่ Claude อาจไม่เข้าใจไหม
- มีข้อมูลที่ไม่ควรส่งให้ AI ไหม
ตัวอย่าง source ดิบเมื่อกี้ ยังขาด context นิดหน่อย
# Inbox - Meeting ทีม sales 2026-05-25
type: inbox
status: raw
date: 2026-05-25
source: internal sales meeting
context: บริษัทกำลังขายคอร์ส AI training สำหรับเจ้าของธุรกิจและทีม business ที่ไม่จำเป็นต้องรู้โค้ด
## Raw note
ประชุมทีม sales 25 พ.ค.
ลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม
หลายคนกลัวทีมใช้ไม่เป็น
ทีม sales อยากได้ FAQ หน้าเว็บ
ควรมี webinar สำหรับผู้บริหารที่ไม่รู้ technical
ต้องส่ง draft FAQ ภายในศุกร์นี้
เพิ่มแค่บรรทัด context Claude ก็เข้าใจดีขึ้นมาก
Clean ไม่ได้แปลว่าต้องเขียนใหม่ทั้งหมด
Step 3: Ask Claude: ให้โจทย์ชัด ไม่ใช่แค่ “สรุปให้หน่อย”
หน้า Claude Support เรื่องการ upload files: Claude อ่านไฟล์ได้ แต่เราต้องเลือก context ให้พอดีภาพ: หน้า Claude Support เรื่องการ upload files: Claude อ่านไฟล์ได้ แต่เราต้องเลือก context ให้พอดี
ช่วยสรุป meeting นี้ให้หน่อย
Claude อาจสรุปได้ แต่ยังไม่พร้อมเข้า Wiki
ฉันกำลังทำ LLM Wiki ใน Obsidian
นี่คือ source จาก meeting ทีม sales
ช่วยแปลง source นี้เป็นชุด note สำหรับ wiki โดยทำ 7 อย่าง:
1. สรุป source เป็น Source note
2. แยก fact / inference / idea
3. เสนอ Concept notes ที่ควรสร้าง
4. เสนอ Project notes ที่เกี่ยวข้อง
5. เสนอ Decision note ถ้ามีการตัดสินใจชัดเจน
6. เสนอ internal links ที่ควรใช้
7. บอกว่า Home.md และ Log.md ควรอัปเดตอะไร
กติกา:
- ใช้เฉพาะข้อมูลที่ให้มา
- อย่าแต่งชื่อคน ชื่อลูกค้า ตัวเลข หรือรายละเอียดใหม่
- ถ้าข้อมูลไม่พอ ให้เขียนว่า "ข้อมูลไม่พอ"
- เขียนเป็น Markdown ที่ copy ไปใช้ใน Obsidian ได้
- ใช้ภาษาคนทำงานทั่วไป ไม่ต้อง technical
สังเกตว่า prompt นี้ไม่ได้ขอแค่ summary
แต่ขอให้ Claude ช่วยจัดระบบ
Step 4: อ่านผลลัพธ์ของ Claude แบบ editor
หลัง Claude ตอบ อย่า copy ทั้งหมดทันที
อ่านเหมือนคุณตรวจงานผู้ช่วย
[ ] มีข้อมูลที่ Claude แต่งเพิ่มไหม
[ ] fact กับ inference แยกกันไหม
[ ] ชื่อ note อ่านรู้เรื่องไหม
[ ] มี note ที่ไม่จำเป็นหรือเยอะเกินไปไหม
[ ] link ที่เสนอมีประโยชน์จริงไหม
[ ] deadline หรือ decision ถูกต้องไหม
[ ] มีอะไรควรถามทีม/ลูกค้าเพิ่มไหม
Claude อาจเสนอ note เยอะเกินไป เช่น:
- ลูกค้ากังวลเรื่อง AI
- AI training
- ทีม sales
- FAQ
- Webinar
- ผู้บริหาร
- ไม่รู้โค้ด
note นี้อนาคตจะกลับมาใช้ไหม?
ถ้าไม่แน่ใจ อย่าเพิ่งสร้าง
LLM Wiki ที่ดีต้องกล้าตัด
Step 5: Split: แยกเป็น note ที่ถูกชนิด
จาก source ตัวอย่าง เราควรสร้างแค่ 3–4 note ก่อน
1. Source note
10-sources/Meeting ทีม sales เรื่องคำถามลูกค้า AI training.md
เพราะ meeting นี้คือ source ต้นทาง
2. Concept note
30-concepts/AI training สำหรับคนไม่รู้โค้ด.md
เพราะเรื่องนี้น่าจะใช้ซ้ำใน FAQ, webinar, landing page และ sales script
3. Project note
40-projects/FAQ หน้าเว็บคอร์ส AI.md
เพราะทีม sales ขอ output ชัดเจน
4. Project หรือ idea note อีกอัน ถ้าจำเป็น
40-projects/Webinar AI สำหรับผู้บริหาร.md
แต่ถ้ายังไม่เริ่มทำจริง ให้ใส่ไว้ใน section Idea ก่อน ยังไม่ต้องสร้าง project note
Decision note ต้องมีไหม?
source บอกว่า “ควรมี webinar” แต่ยังไม่ชัดว่าใครตัดสินใจแล้ว
ดังนั้นยังไม่ควรสร้าง decision note แบบมั่นใจ
ให้เขียนใน source note ว่า:
## Idea
- อาจทำ webinar สำหรับผู้บริหารที่ไม่ technical
## Decision
ตัดสินใจทำ webinar แล้ว
นี่คือการแยก fact/inference/idea ในชีวิตจริง
Step 6: เขียน Source note ให้แน่น
Source note ที่ดีไม่ต้องยาว แต่ต้องตอบว่า source นี้มีอะไรและมาจากไหน
# Meeting ทีม sales เรื่องคำถามลูกค้า AI training
type: source
status: reviewed
date: 2026-05-25
source: internal sales meeting
## Context
บริษัทกำลังขายคอร์ส AI training สำหรับเจ้าของธุรกิจและทีม business ที่ไม่จำเป็นต้องรู้โค้ด
## Summary
ทีม sales พบว่าลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม และกังวลว่าทีมจะใช้ AI ไม่เป็น ทีมจึงอยากได้ FAQ สำหรับหน้าเว็บ และมีไอเดียเรื่อง webinar สำหรับผู้บริหารที่ไม่ technical
## Fact
- ลูกค้าถามบ่อยว่า AI training ต้องรู้โค้ดไหม
- ลูกค้าหลายคนกลัวทีมใช้ AI ไม่เป็น
- ทีม sales อยากได้ FAQ หน้าเว็บ
- ต้องส่ง draft FAQ ภายในศุกร์นี้
## Inference
- ลูกค้าอาจเข้าใจว่า AI training = programming
- เนื้อหาการขายควรย้ำว่าเหมาะกับทีม business ที่ไม่ technical
## Idea
- อาจทำ webinar สำหรับผู้บริหารที่ไม่ technical
## Useful for
- [[FAQ หน้าเว็บคอร์ส AI]]
- [[AI training สำหรับคนไม่รู้โค้ด]]
## Questions
- คำถามจริงจากลูกค้ามี wording ว่าอะไร
- FAQ ควรตอบกี่ข้อ
- Webinar เป็น decision แล้วหรือยัง เป็นแค่ idea
จุดสำคัญคือ note นี้ไม่พยายามทำทุกอย่าง
มันเก็บ source ให้ชัด แล้วชี้ไป note อื่น
Step 7: เขียน Concept note ให้ใช้ซ้ำได้
Concept note ควรสั้นและคม
อย่าเอาทุกอย่างจาก source มาใส่ซ้ำ
# AI training สำหรับคนไม่รู้โค้ด
type: concept
status: draft
## ความหมายสั้น ๆ
AI training สำหรับคนไม่รู้โค้ด คือการสอนใช้ AI กับงานธุรกิจ โดยเริ่มจากงานจริง เช่น meeting, email, sales, marketing, research และเอกสาร ไม่ได้เริ่มจาก programming
## ทำไมเรื่องนี้สำคัญ
- ลูกค้าบางส่วนกังวลว่าการเรียน AI ต้องมีพื้นฐาน code
- ถ้าสื่อสารไม่ชัด ลูกค้าอาจคิดว่าคอร์สไม่เหมาะกับทีม business
- แนวคิดนี้ควรปรากฏใน FAQ, landing page และ webinar
## ตัวอย่าง use case
- ใช้ Claude สรุป meeting
- ใช้ Claude ช่วยร่าง FAQ
- ใช้ Claude วิเคราะห์คำถามลูกค้า
- ใช้ Claude ทำ outline webinar
## Sources
- [[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
## Related
- [[FAQ หน้าเว็บคอร์ส AI]]
Concept note มีหน้าที่เป็น “ความเข้าใจกลาง”
ถ้ามี source ใหม่ในอนาคต เช่น feedback จากลูกค้า หรือ survey ทีม sales คุณมาอัปเดต concept note นี้ได้
Step 8: เขียน Project note ให้ทำงานต่อได้
Project note ต้องช่วยให้ลงมือทำต่อ ไม่ใช่แค่สรุปสวย
# 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 สำหรับคนไม่รู้โค้ด]]
## Draft FAQ ideas
- ต้องรู้โค้ดก่อนไหม
- ถ้าทีมไม่เคยใช้ AI จะเรียนทันไหม
- ใช้กับงาน sales/marketing/admin ได้ไหม
- หลังอบรมจะได้ output อะไร
## Todo
- [ ] ขอคำถามจริงจากทีม sales
- [ ] ร่าง FAQ 10 ข้อ
- [ ] ให้ทีม sales ตรวจ wording
- [ ] ส่งให้คนดูแลเว็บอัปเดตหน้า landing page
## Next review
YYYY-MM-DD
Project note ที่ดีทำให้คุณกลับมาทำต่อได้ทันที
ไม่ต้องอ่าน source ใหม่ทั้งหมด
Step 9: Link: เชื่อมเท่าที่จำเป็น
ก่อนสร้างหรือเชื่อม note ใหม่ ให้ search คำหลักใน Obsidian สั้น ๆ ก่อน
ถ้ามี note เดิมอยู่แล้ว ให้ link ไปหา note เดิม แทนที่จะสร้าง note ซ้ำอีกหน้า
หลังสร้าง note แล้ว เช็ก link หลัก ๆ
ใน source note ควร link ไป:
[[AI training สำหรับคนไม่รู้โค้ด]]
[[FAQ หน้าเว็บคอร์ส AI]]
ใน concept note ควร link กลับไป source:
[[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
ใน project note ควร link ไป source และ concept:
[[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
[[AI training สำหรับคนไม่รู้โค้ด]]
อย่าทำ link เยอะจนอ่านยาก
Link เฉพาะเรื่องที่ถ้าคลิกไปแล้วช่วยให้เข้าใจงานต่อ
เช่นคำว่า “ลูกค้า”, “AI”, “เว็บ”, “ทีม” ไม่จำเป็นต้อง link ทุกครั้ง
Step 10: Save: ย้ายเข้าที่
ตอนนี้ย้าย note ไป folder ที่ถูกต้อง
10-sources/Meeting ทีม sales เรื่องคำถามลูกค้า AI training.md
30-concepts/AI training สำหรับคนไม่รู้โค้ด.md
40-projects/FAQ หน้าเว็บคอร์ส AI.md
- ลบ inbox note ถ้าข้อมูลย้ายครบแล้ว
- เก็บไว้เป็น raw source
- ย้ายไป
10-sources/raw ถ้าคุณอยากเก็บต้นฉบับแยก
สำหรับมือใหม่ แนะนำให้เก็บ raw source ไว้ก่อน
เพราะมันช่วยตรวจว่า Claude สรุปผิดไหม
Step 11: อัปเดต Home
เปิด Home.md แล้วเพิ่ม link สำคัญ
## Projects สำคัญ
- [[FAQ หน้าเว็บคอร์ส AI]]
## Concepts สำคัญ
- [[AI training สำหรับคนไม่รู้โค้ด]]
## Sources ล่าสุด
- [[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
ถ้า Home มี link มากขึ้นเรื่อย ๆ อย่าตกใจ
แต่ถ้าเริ่มยาวเกินอ่าน ให้แยก index ย่อยในบทหลัง ๆ
ตอนนี้แค่ให้ Home เป็นทางเข้าได้ก็พอ
Step 12: อัปเดต Log
## 2026-05-25
- Processed source: [[Meeting ทีม sales เรื่องคำถามลูกค้า AI training]]
- Created concept: [[AI training สำหรับคนไม่รู้โค้ด]]
- Created project: [[FAQ หน้าเว็บคอร์ส AI]]
- Updated Home.md
- Open question: webinar เป็น decision แล้วหรือยัง
แค่บอกว่าเกิดอะไรขึ้น และมีคำถามอะไรค้างอยู่
Step 13: Review: ตรวจ 5 นาทีสุดท้าย
ก่อนจบ workflow ให้ตรวจ 5 นาที
[ ] Source note มีที่มาชัดไหม
[ ] Fact / inference / idea แยกกันไหม
[ ] Concept note ซ้ำกับ source เกินไปไหม
[ ] Project note มี next action ชัดไหม
[ ] Link สำคัญครบไหม
[ ] Home อัปเดตไหม
[ ] Log อัปเดตไหม
[ ] มีคำถามค้างที่ต้องถามคนจริงไหม
ถ้าครบ แปลว่า source นี้ถูกแปลงเป็น wiki แล้ว
Prompt หลักของบทนี้
นี่คือ prompt ที่ใช้ซ้ำได้กับ source แทบทุกแบบ
ฉันกำลังทำ LLM Wiki ใน Obsidian
ช่วยแปลง source นี้เป็น wiki notes ที่ใช้ต่อได้จริง
ข้อมูล context:
- งาน/โปรเจกต์ที่เกี่ยวข้อง:
- กลุ่มคนที่เกี่ยวข้อง:
- เป้าหมายของการเก็บ source นี้:
สิ่งที่ต้องการ:
1. Source note พร้อม Summary, Fact, Inference, Idea, Questions
2. Concept notes ที่ควรสร้างหรืออัปเดต
3. Project note ที่เกี่ยวข้อง ถ้ามี
4. Decision note ถ้ามี decision ชัดเจนเท่านั้น
5. Internal links ที่ควรเชื่อม
6. Home.md ควรเพิ่ม link อะไร
7. Log.md ควรบันทึกอะไร
กติกา:
- ใช้เฉพาะข้อมูลที่ฉันให้
- อย่าแต่งข้อมูลให้ดูสมบูรณ์
- ถ้าข้อมูลไม่พอ ให้เขียนว่า "ข้อมูลไม่พอ"
- แยก fact / inference / idea ให้ชัด
- ถ้าเป็นแค่ idea อย่าเขียนเป็น decision
- ใช้ชื่อ note ที่คนทำงานทั่วไปอ่านแล้วเข้าใจ
- เขียนเป็น Markdown ที่ copy ไปใช้ใน Obsidian ได้
คุณสามารถเก็บ prompt นี้ไว้ใน Obsidian เป็น note ชื่อ:
Prompt - Source to Wiki
Workflow สำหรับ source แบบต่าง ๆ
Source แต่ละแบบใช้หลักเดียวกัน แต่มีจุดที่ต้องระวังต่างกัน
1. Meeting note
- ใครประชุม
- คุยเรื่องอะไร
- fact คืออะไร
- decision คืออะไร
- todo คืออะไร
- อย่าให้ Claude เดาว่าใครรับผิดชอบ ถ้าใน note ไม่ได้เขียน
- อย่าเปลี่ยน idea ให้กลายเป็น decision
2. บทความ
- บทความนี้พูดเรื่องอะไร
- key claims คืออะไร
- source น่าเชื่อแค่ไหน
- ใช้กับงานเราได้ตรงไหน
- ควรแตก concept อะไร
- อย่า copy บทความยาว ๆ มาแทนความเข้าใจ
- อย่าเชื่อทุก claim ถ้าไม่มี source รองรับ
3. หน้าเว็บคู่แข่ง
- เขาขายอะไร
- message หลักคืออะไร
- กลุ่มเป้าหมายคือใคร
- เขาตอบ objection อะไร
- เราเรียนรู้อะไรได้
- อย่าลอก wording
- แยก observation กับ strategy ของเรา
4. Email ลูกค้า
- ลูกค้าถามอะไร
- pain point คืออะไร
- ต้องตอบกลับอะไร
- เกี่ยวกับ project ไหน
- มีข้อมูล sensitive ไหม
- ลบข้อมูลส่วนตัวที่ไม่จำเป็นก่อนส่งให้ AI
- อย่าให้ Claude ตอบในนามบริษัทโดยไม่ตรวจ
5. Chat เก่ากับ Claude
- คุยเรื่องอะไร
- ได้ข้อสรุปอะไร
- มี prompt หรือ output ที่ควรเก็บไหม
- อะไรเป็นแค่ draft
- อะไรควรกลายเป็น concept note
- Chat เก่าอาจมีคำตอบผิดปนอยู่
- ให้เก็บเฉพาะสิ่งที่ตรวจแล้วหรือมีประโยชน์จริง
กติกา “หนึ่ง source ไม่ต้องสร้างสิบ note เสมอ”
ใน LLM Wiki บางแนวทาง source หนึ่งชิ้นอาจแตกเป็นหลายหน้า
แต่สำหรับคนทำงานทั่วไป อย่าเริ่มแบบนั้น
source ธรรมดา → 1 source note
source ที่มี pattern ใช้ซ้ำ → +1 concept note
source ที่เกี่ยวกับงานจริง → +1 project note
source ที่มี decision ชัด → +1 decision note
แปลว่า source หนึ่งชิ้นอาจได้แค่ note เดียวก็ได้
อย่าสร้าง note เพื่อให้ระบบดูฉลาด
สร้าง note เมื่อมันช่วยให้คุณทำงานต่อได้
วิธีรู้ว่า source นี้ควรแตก concept หรือไม่
- เรื่องนี้จะโผล่อีกไหม
- จะใช้กับมากกว่าหนึ่ง project ไหม
- ถ้า Claude รู้ concept นี้ จะช่วยงานเราได้ดีขึ้นไหม
- มี source มากกว่าหนึ่งชิ้นรองรับหรือมีโอกาสจะมีเพิ่มไหม
ถ้าตอบ “ใช่” อย่างน้อย 2 ข้อ ค่อยสร้าง concept note
ถ้าไม่ใช่ เก็บไว้ใน source note ก่อน
วิธีรู้ว่า source นี้ควรสร้าง project note หรือไม่
- มี output ที่ต้องทำต่อไหม
- มี deadline ไหม
- มีคนรับผิดชอบไหม
- มี todo มากกว่าหนึ่งข้อไหม
- ต้องกลับมาดูซ้ำไหม
ถ้าใช่ ให้สร้าง project note
ถ้าเป็นแค่ไอเดียลอย ๆ ยังไม่ต้อง
ใส่ไว้ใน section Idea ของ source note ก่อน
วิธีรู้ว่า source นี้ควรสร้าง decision note หรือไม่
Decision note ต้องใช้เมื่อมีการตัดสินใจจริง
คำที่บอกว่าอาจเป็น decision:
- ตกลงว่า...
- เลือก...
- ไม่ทำ...
- เลื่อนไป...
- ตัดออก...
- ให้ใช้แนวทาง...
- น่าจะ...
- ควรลอง...
- อาจทำ...
- มีไอเดียว่า...
- ทีมเสนอว่า...
ถ้ายังไม่ชัด ให้เขียนว่า Idea หรือ Open question
อย่ารีบเขียนเป็น decision
ความผิดพลาดที่ควรเลี่ยง
1. เก็บเยอะ แต่ไม่ process
ถ้า inbox มีแต่ของดิบ Wiki จะไม่ช่วยอะไร
ต้องมีเวลาสั้น ๆ สำหรับ process
2. ให้ Claude สร้าง note เยอะเกินไป
แต่คุณไม่จำเป็นต้องเก็บทุกอย่างที่มันเสนอ
3. ไม่เก็บ source
สรุปที่ไม่มี source จะตรวจยาก
โดยเฉพาะเมื่อใช้กับงานจริง
4. ไม่อัปเดต Home
ถ้า note สำคัญไม่อยู่ใน Home หรือ index วันหลังจะหาไม่เจอ
5. ไม่แยก idea กับ decision
decision คือสิ่งที่ตกลงแล้ว
6. ทำระบบใหญ่กว่างาน
ถ้าจัด note นานกว่าทำงานจริง ระบบกำลังเริ่มผิดทาง
ใช้เวลาเท่าไรต่อ source หนึ่งชิ้น
Capture: 1–2 นาที
Clean: 2–3 นาที
Ask Claude: 2 นาที
Review output: 3–5 นาที
Save + link + log: 5 นาที
สำหรับ source สำคัญ อาจใช้ 30–45 นาที
ให้เลือกทำละเอียดเฉพาะ source ที่มีผลกับงานจริง
เลือกโหมดตามเวลาที่มี
Workflow เดียวกัน ไม่ได้แปลว่าต้องใช้เวลานานเท่ากันทุกครั้ง
โหมด 15 นาที
ใช้กับ source ธรรมดา เช่น meeting note สั้น ๆ email หนึ่งฉบับ หรือบทความที่ไม่ได้สำคัญมาก
1. เก็บ source พร้อม date/source/context
2. ให้ Claude สรุป fact / inference / idea
3. สร้างหรืออัปเดต note ที่จำเป็นที่สุด 1–2 หน้า
4. ใส่ link กลับไป source
5. อัปเดต Log สั้น ๆ
โหมดนี้เน้น “พอใช้ต่อได้” ไม่ใช่สมบูรณ์แบบ
โหมด 45 นาที
ใช้กับ source สำคัญ เช่น research สำคัญ feedback ลูกค้าหลายราย strategy meeting หรือเอกสารที่กระทบงานใหญ่
1. ตรวจ source ดิบละเอียดขึ้น
2. แยก concept ที่จะใช้ซ้ำจริง
3. อัปเดต project note ให้มี next action
4. เช็กว่า decision มีจริงไหม
5. ให้ Claude ช่วยหาช่องว่างหรือคำถามที่ควรถามต่อ
6. อัปเดต Home หรือ index ให้หาเจอ
โหมดนี้ใช้เมื่อ source มีผลกับงานจริง
อย่าใช้โหมด 45 นาทีกับทุกอย่าง
ถ้าทุก source ต้องละเอียดหมด คุณจะเลิกทำภายในสองสัปดาห์
สรุปท้ายบท
LLM Wiki ไม่ได้เกิดจากการเก็บทุกอย่าง
มันเกิดจากการ process source ทีละชิ้นให้กลายเป็นความรู้ที่ใช้ต่อได้
Capture → Clean → Ask Claude → Split → Link → Save → Review
ถ้าทำซ้ำได้สัปดาห์ละไม่กี่ครั้ง Wiki จะเริ่มโตแบบมีคุณภาพ
และเมื่อ Wiki โตขึ้น Claude จะช่วยได้ดีขึ้น เพราะมันไม่ได้อ่านกองข้อมูลดิบ แต่มันอ่านความรู้ที่คุณค่อย ๆ จัดไว้แล้ว
บทต่อไป เราจะดูเรื่องการดูแล Wiki ไม่ให้รก
เพราะระบบความรู้ไม่ได้พังตอนเริ่ม
มันพังหลังจากใช้ไป 3 สัปดาห์แล้วไม่เคย cleanup
Artifact ท้ายบท: Workflow 7 ขั้น
1. Capture เก็บข้อมูลเข้า inbox
2. Clean ทำให้ source อ่านรู้เรื่อง
3. Ask Claude ให้ Claude ช่วยสรุป/จัดรูป
4. Split แยกเป็น note ที่ถูกชนิด
5. Link เชื่อมกับ note เดิม
6. Save ย้ายเข้าที่ อัปเดต Home/Log
7. Review อ่านตรวจก่อนถือว่าเสร็จ
Artifact ท้ายบท: Source processing checklist
[ ] Source มีวันที่และที่มา
[ ] เพิ่ม context สั้น ๆ แล้ว
[ ] ส่งให้ Claude ด้วย prompt ที่ชัด
[ ] ตรวจว่า Claude ไม่แต่งข้อมูลเพิ่ม
[ ] แยก fact / inference / idea แล้ว
[ ] สร้าง note เท่าที่จำเป็น
[ ] เชื่อม link สำคัญ
[ ] อัปเดต Home
[ ] อัปเดต Log
[ ] มี open questions ถ้าข้อมูลยังขาด
อ้างอิงหลักของบทนี้
- Andrej Karpathy: LLM Wiki gist: ingest, query, lint, index/log pattern
AgriciDaniel/claude-obsidian: LLM Wiki Pattern noteAgriciDaniel/claude-obsidian: Source-First Synthesis note- Obsidian Help: Internal links
- Obsidian Help: Properties
- Claude Help Center: Upload files to Claude
- Claude Help Center: Projects and project knowledge
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย