สร้าง KOS (Knowledge Operating System) คลังสมองกลางของตัวเอง ด้วย vibe coding
- 9 hours ago
- 9 min read
โดยใช้ Claude, Notion, VS Code และ Obsidian
--- prompt ทั้งหมดอยู่ด้านล่างนะคะ
หลังจากที่เราได้โพสต์หัวข้อ “สรุป 8 โปรเจกต์ที่ปั้นมากับ Fable” ไป ก็ได้รับการตอบรับที่ดีมาก ๆ ต้องขอบคุณจริงๆ ค่ะ ไม่คิดว่าจะมีคนให้ความสนใจมากมายขนาดนี้ เพราะจริง ๆ เราก็หยิบไอเดียจากหลายๆ คน มาผนวกกับปัญหาหลักของตัวเองมาขยำรวมกัน
จากโพสต์ที่แล้ว พบว่าโปรเจกต์ที่คนถามมามากที่สุดคือ KOS วันนี้เลยอยากเอามาเล่าให้ฟังกันค่ะ
ย้อนกลับไปเราเริ่มได้ยินไอเดียนี้จากเพจ ลงทุน Diary และก็ไปเจออีกทีจากช่องแดงของ Everyday with Captain (จะแปะลิงค์ไว้ด้านล่างของโพสต์นี้นะคะ สอนดีมาก เข้าใจง่ายสุดๆๆๆ) ซึ่งตัวโปรเจกต์ MiroFish เราก็หยิบคลิปนั้นมาต่อยอดเหมือนกันค่ะ
อะไรคือ KOS
KOS ย่อมาจาก Knowledge Operating System พูดง่ายๆ คือคลังสมองกลางที่เก็บทุก fact ทุก context ของแต่ละโปรเจกต์ไว้ที่เดียว เป็นระบบที่กำหนดไว้ชัดเจน ว่าความรู้หรือข้อมูลแต่ละแบบควรมี "บ้าน" อยู่ตรงไหน แบ่งหน้าที่ให้ชัดเจน ส่วนที่ใช้ง่ายและเป็นจุดขายสำคัญคือ inbox ค่ะ ไม่ว่าจะเป็นไอเดีย ลิงก์ ไฟล์ข้อมูล หรือรูป ก็โยนเข้าโฟลเดอร์นี้ที่เดียวได้เลย โดยไม่ต้องสนใจว่าเราจะดูแล้วหรือยัง พอถึงเวลาก็ให้ skill triage จัดการอีกที ไม่ต้องมาคิดเอง ว่าจะเซฟไฟล์ไหนไว้ตรงไหน ช่วยลดภาวะ decision fatigue หรือความเหนื่อยล้าจากการตัดสินใจได้เยอะเลยค่ะ
Pain Point
ในการทำงานต่างๆ แม้เราจะคิดว่าตัวเองทำงานเป็นระบบอยู่แล้ว ทั้งจัดโฟลเดอร์แยกไฟล์ และตั้งชื่อไฟล์ของตัวเอง แต่ปัญหาจริงๆ คือ เราขี้ลืมมากกกกก ถึงจะมั่นใจว่าเซฟไฟล์นี้ไว้ แต่เอาเข้าจริงกลับจำไม่ได้ว่าไฟล์นั้นอยู่ตรงไหน หรือข้างในมีอะไร มีแค่ความรู้สึกลางๆ ว่ามันเคยผ่านตา ดังนั้นการมี KOS จะช่วยแก้ปัญหาเรื่องระบบการจัดเก็บข้อมูล และช่วยดึงข้อมูลเหล่านั้นให้เราทำงานง่ายขึ้น
ในระบบของเรา Notion จะทำหน้าที่เป็น workspace หรือพื้นที่ทำงาน เป็นที่จัดเก็บของพวก to-do list หรืองานอัพเดตใหม่ ๆ ส่วน Obsidian เป็นเหมือนหอสมุดที่เป็นคลังความรู้ เก็บไฟล์ใหญ่ ๆ หรือ pdf และ NEXT ก็ทำหน้าที่เชื่อมบริบททั้งหมดเข้าด้วยกัน
การใช้งาน
ยกตัวอย่าง โปรเจคต์ Wealth Tracker ที่กำลังทำอยู่ ตอนนี้ทำกับ Claude ผ่าน 85 sessions แล้ว บางทีไปทำงานอื่น พอกลับมาเปิดโฟลเดอร์จะทำงานใหม่ มันจะมีความรู้สึกคุ้นๆ และไม่มั่นใจว่าจริงๆงานไปถึงไหน หรือเวอร์ชั่นอันไหนล่าสุด บางไฟล์อัพเดตแล้วอัพเดตอีก จนจำไม่ได้ว่าอันไหนยังใช้อยู่หรืออันไหนจัดเก็บไปแล้ว
แถมเราทำงานหลายแพลตฟอร์ม ทั้ง Notion, Claude, ChatGPT และยังทำหลายโปรเจ็กต์ควบคู่กัน บางทีไอเดียกระฉูด ป๊อบอัพเข้ามาระหว่างทำงาน ก็ต้องรีบโยนๆไว้ใน apple note ก่อนที่ไอเดียจะหาย ข้อมูลเลยกระจัดกระจายไปหมด ยิ่งมีเครื่องมือเยอะก็ยิ่งต้องจำเยอะขึ้นว่าอะไรอยู่ตรงไหน ทั้งที่ความจริงแล้ว หน้าที่ของเซลล์สมองเราควรโฟกัสกับการคิดมากกว่าการมานั่งแยกไฟล์
KOS คือคำตอบที่มาแก้ปัญหานั้นค่ะ ไม่ใช่แค่โฟลเดอร์ที่ใหญ่ขึ้น แต่เป็นระบบที่กำหนดและจดจำแทนเราได้ ว่าข้อมูลไหนรีวิวไปแล้ว ข้อมูลไหนตัดสินใจไปแล้ว หรือจัดเก็บไปแล้ว จัดเก็บไว้ตรงไหน อย่างตอนนี้เขียนงานกับ PEN ก็ดึง context ตรงจาก KOS ได้เลย ไม่ต้องมานั่งเล่าโปรเจคต์ซ้ำๆ อีกเป็นการลดเวลาการทำงานได้อย่างน่าพอใจเลยค่ะ
ซึ่งหลังจากใช้งานมาสักพัก workflow ตอนนี้เริ่มลงตัวเป็นระบบแล้วค่ะ :
KOS ดูแลคลังความรู้
NEXT ดูแลภาพรวมทั้งพอร์ตโปรเจกต์
PEN ดูแลงานเขียน
ส่วน Wealth Tracker ก็เป็นแอปตัวนึงที่วิ่งอยู่บนระบบพวกนี้อีกที
พูดง่าย ๆ KOS คือโครงสร้างพื้นฐานของระบบหลังบ้าน ที่เป็นกองหลังคอยซัพพอร์ตให้งานทุกอย่างหลังจากนี้เร็วขึ้น
วิธีสร้าง
ข้อสำคัญและจำเป็นมากๆในการสร้าง KOS คือ การรู้จักขั้นตอนการทำงานของตัวเองเป็นอย่างดี หลังจากได้ปั้น Wealth Tracker, PEN, NEXT มา ทำให้ตัวเราพอจะเข้าใจได้ว่า ระบบหรือ workflow ของตัวเองจริงๆ หน้าตาเป็นแบบไหน
ทุกครั้งที่จะ prompt Claude เราจะเขียนความต้องการคร่าวๆ ว่าอยากได้อะไร มีขั้นตอนการทำงานเป็นยังไง รวมทั้งประเด็นปัญหาหลักที่เจอคืออะไร แล้วให้ ChatGPT (ตัวฟรี) ช่วยเรียบเรียงคำสั่งให้ใหม่ ทำให้ Fable อ่านแล้วไม่หลุดโฟกัส
แต่ถึงแบบนั้น เราก็ยังต้องมานั่งอ่านตาแตกอยู่ดีค่ะ ว่าสิ่งที่เราบรีฟไปตรงกับที่อยากได้จริงๆมั้ย
พอได้ผลลัพธ์กลับมา ก็ทำการทดสอบเบื้องต้นหรือ smoke test ว่าตรงกับที่ตั้งใจไว้หรือเปล่า
ข้อสำคัญคือ ระบบ KOS ต้องปรับตามการใช้งานจริงของเรา ไม่ใช่ปรับเราให้เข้ากับระบบ ถ้าเราไม่มีไกด์ไลน์ตัวเองนี่ จะโดนแกว่งได้ง่ายมาก แล้วสุดท้ายจะกลายเป็นระบบที่เราใช้งานไม่ได้จริงนะคะ
ข้อควรระวัง
ต้องบอกตามตรงว่าจนถึงทุกวันนี้ เราก็ยังใช้ Claude Code ไม่เป็น ทำ GitHub ไม่เป็น แล้วก็ยังใช้ Obsidian ไม่เป็นอยู่ดีค่ะ (จริงๆ พยายามหาข้อมูลอ่านเพิ่มเรื่อย ๆ นะคะ ถ้าใครเจอโพสต์ไหนที่สอนดี เข้าใจง่าย ฝากแปะลิงค์แนะนำไว้ได้นะคะ จะขอบคุณมากๆค่ะ 😅) ดังนั้นตอนสร้าง เราเลยปล่อยให้ Claude เป็นคนลงมือทำ ส่วนเรามีหน้าที่ตัดสินใจหลังงานจบแล้วอีกที ตอนใช้ก็ค่อยๆปรับไปค่ะ
Prompt
สำหรับโปรเจคต์นี้ เราใช้เวลาทั้งหมด 8 วัน 15 sessions ใช้ 2 โมเดล
1. Fable ในการออกแบบ architecture และตรวจสอบกรณีมีรอยรั่ว
2. Sonnet ใช้ในการประมวลผล
นั่นคือค่าใช้จ่ายจริงของการสร้าง KOS ค่ะ
Prompt อยู่ด้านล่างนี้เลยนะคะ -----
เนื่องจากแต่ละคนนำไปใช้ในงานต่างกัน คิดว่าทุกคนก็ต้องเอาไปปรับกันต่อ แต่ยังไงก็น่าจะพอเป็นจุดตั้งต้นที่ดีได้ในระดับนึงค่ะ
ขอให้ทุกคน vibe code กันสนุก ๆ นะคะ ได้ผลลัพธ์แล้วอย่าลืมมาแชร์โปรเจกต์กันต่อน้า
First Prompt (FABLE)
You are my Knowledge Systems Architect, Information Architect, and AI Workflow Designer.
Your responsibility is not to build an Obsidian vault.
Your responsibility is to design a complete Knowledge Operating System (KOS) that I can confidently use for the next 5–10 years.
This project is about creating a permanent, local-first knowledge ecosystem that is easy for both humans and AI to understand.
Think like an architect designing an operating system—not just folders.
My Current Stack
AI
Claude Pro (Fable + Sonnet)
Knowledge
Obsidian (Free)
Development
VS Code (Free)
Operational Workspace
Notion
Current Situation
My Notion workspace is already mature and stable.
It already manages:
Content Pipeline
Planning
Project Management
Daily Operations
I do not want to duplicate those workflows.
Instead, I want to build a local-first knowledge system where:
Obsidian becomes my permanent knowledge and documentation repository.
VS Code becomes my engineering and creation workspace.
Claude becomes my reasoning and synthesis layer.
Notion remains my operational management system.
Each tool should have a clearly defined responsibility.
There should be as little overlap as possible.
About Me
Assume I am a beginner with Obsidian and VS Code.
I know basic computer concepts but very little Markdown, VS Code, plugins, Git, or advanced workflows.
Design everything so I can realistically maintain it without becoming an Obsidian power user.
Favor simple, durable systems over clever ones.
Long-Term Goal
I want a system where:
I always know where a document belongs.
I can find anything quickly.
My knowledge compounds over time.
Claude Sonnet can understand my projects with minimal context.
AI token usage stays low because the documentation is well structured.
I can work effectively even years from now.
The system remains clean after thousands of notes and documents.
I want this to become my permanent source of truth.
Core Design Principles
Prioritize these in order:
Simplicity
Long-term maintainability
Easy retrieval
Human readability
AI friendliness
Minimal token usage
Local-first ownership
Portable Markdown
Low learning curve
Whenever there is a trade-off, explain it.
Challenge my assumptions if you think there is a better approach.
Your Responsibilities
Before proposing any implementation:
inspect the entire problem deeply
identify risks
identify future scaling problems
identify maintenance costs
explain trade-offs
recommend improvements to my thinking
Only after the architecture is solid should implementation be planned.
Part 1 — Design the Knowledge Operating System
Design the overall architecture.
Explain the responsibilities of:
Notion
Obsidian
VS Code
Claude
What belongs where?
What should never be duplicated?
What becomes the source of truth for each type of information?
Part 2 — Folder Architecture
Design a scalable folder structure.
Don't simply list folders.
Explain:
why each exists
when to create new folders
when NOT to create new folders
how the structure scales over many years
Part 3 — Knowledge Governance
This is one of the most important sections.
Design rules that prevent my knowledge base from becoming messy over time.
Instead of organizing files for me, create a governance system that teaches me how to organize them correctly.
Explain:
folder philosophy
document ownership
note granularity
lifecycle management
archival strategy
deletion rules
duplication prevention
review routines
maintenance schedule
The goal is a system that remains clean for years without requiring constant effort.
Part 4 — Document Classification
Teach me where every common type of document belongs.
Examples include:
Active projects
Completed projects
Documentation
Meeting notes
Decision logs
Changelogs
Lessons learned
Books
Articles
Research papers
Study notes
Personal journal (if applicable)
Career documents
Resume
Portfolio
Screenshots
Images
PDFs
Downloads
Miscellaneous files
For every category explain:
where it belongs
why
what metadata is useful
how AI should consume it
Part 5 — Naming Convention
Design a naming system that stays consistent for years.
Include guidance for:
folders
Markdown files
PDFs
images
exported reports
project versions
meeting notes
decision logs
references
Explain:
when to include dates
when not to
when to use version numbers
how to avoid inconsistent naming
Part 6 — Project Documentation Standard
Design a reusable documentation standard.
Every project should be understandable by both humans and Claude.
Recommend:
README
Context
Current Status
Decisions
Lessons Learned
References
Assets
Changelog
Next Actions
Explain the purpose of each file.
Part 7 — AI Optimization
Optimize the architecture specifically for Claude Sonnet.
The goal is minimizing token usage while maximizing understanding.
Design:
context hierarchy
summary files
project entry points
documentation strategy
reusable context files
prompt-friendly documentation
Teach me how to provide only the necessary files instead of entire projects.
Part 8 — VS Code Architecture
Design how VS Code should be organized.
Include:
repositories
documentation
HTML projects
SQL
scripts
experiments
reusable components
Explain what documentation belongs beside code and what belongs in Obsidian.
Part 9 — Beginner Learning Roadmap
Teach me how to use Obsidian and VS Code in a practical way.
Do NOT teach every feature.
Teach only what supports this system.
Create a progressive learning path.
For each stage include:
what to learn
why it matters
hands-on exercises using my own files
common mistakes
expected outcome
Assume I am learning by doing.
Part 10 — Recommended Plugins and Extensions
Recommend only plugins or VS Code extensions that provide significant long-term value.
For each recommendation explain:
why it is useful
when I will actually use it
whether it is essential or optional
possible downsides
Avoid plugin overload.
Part 11 — Migration Strategy
Help me migrate gradually.
Do not require rebuilding everything.
Create independent phases.
Each phase should provide immediate value.
Include validation steps before moving to the next phase.
Part 12 — Automation Opportunities
Identify automation opportunities that genuinely reduce maintenance.
Examples:
templates
scripts
Claude workflows
Obsidian plugins
VS Code tasks
Avoid automation that adds unnecessary complexity.
Part 13 — Implementation Roadmap
Once the architecture is finalized, decide what should be delegated to Claude Sonnet.
Break implementation into small milestones.
Each milestone should:
have a clear objective
be independently testable
include validation steps
include rollback instructions
avoid disrupting existing files
Assume Sonnet will execute these milestones one at a time.
Part 14 — User Manual
One of the final deliverables must be a complete user manual that I can store in Notion.
The manual should assume I am a beginner.
Include:
installation
setup
folder explanations
naming rules
daily workflow
weekly maintenance
monthly review
migration guide
troubleshooting
FAQs
common mistakes
best practices
onboarding guide for future me
The manual should be clear enough that six months from now I can return to the system without relearning it.
Final Instruction
Do not start with implementation.
Think like a systems architect first.
Challenge my assumptions if necessary.
Design the architecture before recommending any folders, plugins, or code.
Once the architecture is complete, determine what should be implemented by Claude Sonnet and produce an implementation roadmap.
Design Philosophy
I value systems that reduce decision fatigue.Whenever possible, design defaults instead of requiring me to make frequent organizational decisions.For example:
If a new document has an obvious home, I should immediately know where it belongs.
If I create a new project, I should already know which files it should contain.
If I save a book summary, article, or course note, the location and format should already be standardized. A good system should remove unnecessary choices rather than create more options.
KOS Project Instructions (SONNET)
Read Order
When working in this folder, read the governing documents in a fixed order before doing anything else — for example: a system overview, a principles/constitution doc, an architecture doc, and an operating-instructions doc. Don't skip or reorder these unless explicitly told to. This one rule stops Claude from acting on partial context.
Canonical Folder Rule
Pick one folder as the single source of truth for your knowledge system, and treat everything else — old folders, previous setups, Claude's own temporary working files — as non-canonical. Claude's internal session storage is never treated as the final home of a deliverable; anything meant to last gets placed back inside your canonical folder.
File Change Authority
Claude may not create, rename, move, or delete any file unless you've explicitly approved that specific change. Before touching the filesystem, it has to answer three questions: what file is affected, what exact change is being made, and whether you actually approved it. No approval, no operation. This single rule prevents most of the "helpful" reorganizing that quietly wrecks a knowledge base.
Legacy Locations
If an old version of your system exists somewhere else, don't let Claude assume it's outdated or authoritative, silently merge it, or overwrite anything. It flags the duplication and waits for your decision.
Operational State Stays Separate
Keep "what's happening right now" — tasks, decisions, status — in your project-tracking tool, not duplicated inside your knowledge files. Files hold governance and reference material; your tracker holds the live state. Mixing the two is one of the fastest ways a system turns messy.
Session Closing Ritual
At the end of a real work session, ask one simple question: did anything here change how I think or work? If yes, log one line about it somewhere you'll actually see again. If not, skip it — don't force a reflection that isn't there.
Priority When Rules Conflict
Your explicit instruction in the moment always wins, then your written governance documents, then the standing operating rules, then existing folder conventions. Claude's own convenience never outranks any of these.
/triage — Inbox Triage (skill)
A batch-review skill, not an autonomous classifier — it runs on demand, never automatically.
Pipeline this skill sits in
Capture ──(clearly belongs elsewhere)──→ separate system (direct, bypasses inbox)
│
▼
Inbox ──→ /triage (on demand) ──→ one of five dispositions
Capture stays dumb and append-only: whatever gets dropped into an inbox just sits there untouched until a triage pass reviews it.
The five dispositions
Delete — the default expectation for most inbox items.
Route elsewhere — send it to a separate system it actually belongs to instead of the main inbox.
Tag for later — leave it in the inbox, tagged so a future pass can pick it up.
Promote into the knowledge system — hand it to the proper intake process; triage itself never does that work, it just starts the handoff.
Leave unresolved — a valid outcome when you genuinely don't know yet.
There's no vague "pending" state; unresolved just means it's still sitting in the inbox.
How a triage session runs
Read through the inbox in full.
For each item, propose one of the five dispositions above, with a one-line reason. Don't batch-decide silently — approve in bulk at the end of the pass, not item by item, unless an item is ambiguous.
If an item is ambiguous, ask a direct question about it, or default to "leave unresolved" rather than guess.
Once approved, execute the dispositions:
Delete: remove the item from the inbox.
Route: move it to the separate system it belongs to.
Tag: add the tag + reference link; leave the item in the inbox.
Promote: hand off to the intake process. This skill stops there — the rest is a different step's job.
Leave: no action; item remains in the inbox.
Hard rule — no distillation creep
This skill must never normalize, template, summarize, or distill content. It never cleans up or rewrites an item's content — that's a different step's job. Triage decides which door an item goes through — a separate step decides what the item becomes. Any request to "clean up" or "rewrite" an item's content during triage is out of scope; say so and route it onward instead of doing it here.
Turning tagged items into tasks
A tag is just a tagging convention on an inbox item, not a new state or store. At the start of a session, someone scans the inbox for their own tagged items, and asks which ones to convert into real tasks. Conversion means creating a real task and removing the tagged item from the inbox. Only the person themself commits a conversion — no automated process decides priority, schedule, or placement.
The boundary this skill enforces
Direct routing is permitted only to separate, self-contained systems outside the main knowledge base; anything meant for the main knowledge base always goes through the proper review step, no exceptions for how confident the classification feels.
This skill never writes to the main knowledge base directly — anything headed there is always handed off through the proper intake process first.
Constraints
Propose before executing; explicit approval required before any filesystem, database, or destructive change.
No new entities, states, databases, or automation beyond the five dispositions and the tagging convention above.
If a structural surprise comes up mid-triage — an item that doesn't fit any of the five dispositions, or a system that isn't yet self-contained — stop and surface it rather than inventing a sixth disposition.
Comments