ผมชอบเอกสารชิ้นหนึ่งของ Andrej Karpathy เรื่อง LLM Wiki มากครับ (อยากรู้ว่าคืออะไร ผมเคยเขียนไว้ที่ LLM Wiki : คลังความรู้ส่วนตัว ตามแบบฉบับของ Karpathy) ไม่ใช่แค่เพราะไอเดียเรื่อง LLM Wiki น่าสนใจ แต่เพราะวิธีเขียนของมันดีมาก คือมันอ่านเหมือนบทความให้มนุษย์เข้าใจ แต่ขณะเดียวกันก็เป็นเอกสารที่ส่งให้ AI agent เอาไป implement ต่อได้เลย
นี่เป็นรูปแบบที่ผมคิดว่าน่าสนใจมากสำหรับคนที่ต้องเขียน requirement, product spec, technical spec หรือแม้แต่ working agreement ให้ AI ทำงานด้วย เพราะมันไม่ได้เขียนเป็น requirement แข็งๆ แบบที่เคยทำกันมา หรือแบบเอกสารราชการ แต่ก็ไม่ได้หลวมจน AI หรือคนต้องเดาเองทั้งหมด
บทความนี้เลยอยากลองแกะรูปแบบการเขียนของเอกสารชิ้นนี้ว่า ทำไมมันถึงอ่านง่ายสำหรับคน และยังทำหน้าที่เป็น context engineering สำหรับ AI ได้ดีในเวลาเดียวกัน
หมายเหตุ: บทความนี้เป็นงานเขียนร่วมกันระหว่างผมกับ AI agent โดยอิงจากมุมมองและโจทย์ที่ผมสนใจจริง ส่วนข้อมูลเชิงอ้างอิงนำมาประกอบจากเอกสาร LLM Wiki gist ของ Andrej Karpathy และแหล่งที่มาที่ลิงก์ไว้ท้ายบทความ
เอกสารนี้ไม่ได้บอกแค่ “ต้องทำอะไร” แต่บอกว่า “ทำไมต้องทำ”
จุดแรกที่ผมชอบคือเอกสารไม่ได้เปิดด้วย technical อย่างการบอกโครงสร้าง directory structure, schema, command หรือ implementation detail ทันที แต่เปิดด้วยปัญหาของวิธีเดิมก่อน
Karpathy เริ่มจากภาพที่คนส่วนใหญ่คุ้นเคย คือการใช้ LLM กับเอกสารแบบ RAG หรือการ upload file แล้วให้โมเดลดึง chunk มาตอบคำถาม จากนั้นค่อยชี้ให้เห็นข้อจำกัดว่า วิธีนี้ทำให้ LLM ต้อง rediscover knowledge ใหม่ทุกครั้ง ไม่มีการสะสม ไม่มีการ build up ของความรู้
พอวาง problem แบบนี้แล้ว เขาค่อยเสนอ idea ใหม่ว่า แทนที่จะ retrieve raw document ทุกครั้ง ให้ LLM ค่อยๆ สร้างและ maintain wiki ที่เป็น markdown files อยู่ระหว่างผู้ใช้กับ raw sources
นี่คือ pattern การเขียน requirement ที่ดีมาก คือเริ่มจาก pain ของโลกเดิม แล้วค่อยพาไปสู่ architecture ของโลกใหม่
สำหรับมนุษย์ วิธีนี้ทำให้อ่านแล้วเข้าใจเหตุผล ไม่ใช่แค่รับคำสั่ง ส่วนสำหรับ AI มันทำให้โมเดลเข้าใจ intent ของระบบ ไม่ใช่ทำตาม checklist แบบไม่รู้บริบท
โครงสร้างหลักของเอกสาร
ถ้าแกะเป็นโครง เอกสารนี้มีลำดับที่ค่อนข้างชัดครับ
| ลำดับ | Section | หน้าที่ของ section |
|---|---|---|
| 1 | Title + one-line description | บอกชื่อ pattern และคำอธิบายสั้นมาก |
| 2 | Meta intent | บอกว่าเอกสารนี้ออกแบบมาให้ copy ไปให้ LLM agent อ่าน |
| 3 | The core idea | อธิบาย problem, contrast กับวิธีเดิม, แล้วเสนอ idea ใหม่ |
| 4 | Examples | ยก use case หลาย domain เพื่อให้คนเห็น applicability |
| 5 | Architecture | แตกเป็น 3 layer: raw sources, wiki, schema |
| 6 | Operations | อธิบาย workflow: ingest, query, lint |
| 7 | Indexing and logging | ระบุ artifact สำคัญที่ช่วยให้ระบบทำงานต่อเนื่อง |
| 8 | Optional tools | เสนอเครื่องมือเสริมโดยไม่บังคับ |
| 9 | Tips and tricks | เก็บ practical notes จากประสบการณ์ใช้งานจริง |
| 10 | Why this works | อธิบายเหตุผลเชิงระบบว่าทำไม LLM เหมาะกับงานนี้ |
| 11 | Note | ปิดท้ายด้วยขอบเขตและวิธีนำไป adapt |
สิ่งที่น่าสนใจคือมันไม่ได้เป็น spec แบบ sequence เดียวจาก requirement ไป design ไป implementation แต่เป็น “idea file” ที่ค่อยๆ เพิ่มระดับความชัดจาก concept ไปสู่ architecture และ operation
Pattern ใหญ่: Context ก่อน Requirement
ถ้าเขียน requirement แบบเดิม เราอาจเริ่มด้วยประโยคประมาณนี้
ระบบต้องสามารถ ingest เอกสาร, สร้าง wiki page, update index และตอบคำถามจาก wiki ได้
ประโยคนี้ไม่ได้ผิด แต่สำหรับ AI มันยังเปิดช่องให้เดาเยอะมาก เพราะยังไม่รู้ว่า ingest เพื่ออะไร, wiki ต่างจาก raw source อย่างไร, index สำคัญแค่ไหน, และใครเป็นเจ้าของ layer ไหน
เอกสารของ Karpathy ทำอีกแบบ คือให้ context ก่อน แล้ว requirement ค่อยโผล่ออกมาจาก context นั้น เช่นเมื่อเขาบอกว่า raw sources เป็น immutable และเป็น source of truth ส่วน wiki เป็น LLM-generated markdown ที่ LLM owns entirely เราจะเริ่มเข้าใจ rule ตามมาทันทีว่า AI อ่าน raw ได้แต่ไม่ควรแก้ raw, AI แก้ wiki ได้, schema เป็นตัวกำกับ behavior
นี่คือหัวใจของ context engineering ครับ ไม่ใช่ยัด requirement เยอะๆ แต่จัดบริบทให้ AI เห็น mental model ที่ถูกก่อน
โครงภาษาที่ทำให้มนุษย์อ่านง่าย
ในเชิงภาษาศาสตร์ เอกสารนี้มีหลายอย่างที่ทำให้อ่านง่ายมาก แม้จะเป็นเรื่องค่อนข้าง technical
1. ใช้ contrast ชัดเจน
เขาใช้คู่ตรงข้ามซ้ำๆ เช่น RAG แบบเดิมกับ wiki แบบใหม่, raw sources กับ wiki, human กับ LLM, index กับ log, required core กับ optional tools วิธีนี้ช่วยให้ผู้อ่านสร้างแผนที่ในหัวได้เร็ว
2. ใช้ sentence ที่มี thesis ชัด
หลายย่อหน้ามีประโยคแกนกลางที่จับใจความได้ทันที เช่น “the wiki is a persistent, compounding artifact” หรือ “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.” ประโยคแบบนี้ทำให้ idea จำง่ายและ quote ได้
3. ใช้ metaphor ที่แม่น
การเปรียบ Obsidian เป็น IDE, LLM เป็น programmer และ wiki เป็น codebase ช่วยย้ายเรื่อง knowledge management ที่อาจ abstract ให้กลายเป็นภาพที่ developer เข้าใจทันที
4. ใช้ bullet เพื่อเปิดพื้นที่ของ domain
แทนที่จะอธิบาย use case ยาวๆ เขาใช้ bullet list เช่น personal, research, reading a book, business/team, competitive analysis วิธีนี้ทำให้คนอ่าน map เข้ากับชีวิตตัวเองได้เร็ว
5. ใช้คำกริยาเชิง operation
คำอย่าง ingest, query, lint, update, maintain, file back, append, cross-reference เป็นภาษาที่มนุษย์อ่านแล้วเห็น workflow และ AI อ่านแล้วแปลงเป็น action ได้ง่าย
โครงสร้างแบบ Requirement + Context Engineering
ถ้ามองในมุม requirement engineering เอกสารนี้มีองค์ประกอบที่ครบกว่าที่เห็นตอนอ่านผ่านๆ ครับ
| องค์ประกอบ | มีในเอกสารอย่างไร | ประโยชน์กับ AI |
|---|---|---|
| Purpose | สร้าง personal knowledge base ด้วย LLM | รู้ goal ใหญ่ |
| Problem statement | RAG ต้อง rediscover knowledge ทุกครั้ง | รู้ว่าต้อง optimize อะไร |
| Core concept | Persistent, compounding wiki | รู้ object ที่ต้องรักษา |
| Domain examples | personal, research, business, trip planning | รู้ว่า pattern ใช้ได้กว้าง |
| Architecture | raw sources, wiki, schema | รู้ boundaries และ ownership |
| Operations | ingest, query, lint | รู้ workflow หลัก |
| Artifacts | index.md, log.md | รู้ไฟล์ที่ต้อง maintain |
| Optionality | tools, Obsidian, Marp, Dataview เป็น optional | รู้ว่าอะไร core อะไรปรับได้ |
| Rationale | LLM ไม่เบื่อ bookkeeping | เข้าใจว่าทำไม solution นี้เหมาะ |
| Adaptation note | รายละเอียดขึ้นกับ domain และ preference | ไม่ overfit กับ implementation เดียว |
สำหรับ AI นี่คือ context ที่ดีมาก เพราะไม่ได้บอกแค่ output ที่ต้องการ แต่บอก ontology ของระบบด้วยว่ามี object อะไรบ้าง, object แต่ละตัวสัมพันธ์กันอย่างไร, operation หลักคืออะไร, และอะไรเป็น optional
สิ่งที่ทำให้ AI เอาไป implement ได้
เอกสารนี้ไม่ได้ให้ code แต่ AI เอาไป implement ต่อได้ เพราะมันให้ constraint ที่สำคัญครบครับ
- มี layer ชัด raw sources, wiki, schema ทำให้ AI รู้ว่าจะสร้าง folder และไฟล์ประเภทไหน
- มี ownership ชัด raw immutable, wiki LLM-generated, schema co-evolved
- มี workflow verbs ingest, query, lint เอาไปแตกเป็น command หรือ task ได้
- มี artifact names index.md และ log.md ทำให้ implement ได้ทันที
- มี health check criteria contradictions, stale claims, orphan pages, missing cross-references
- มี adaptation boundary บอกว่า abstract และ modular จึงไม่บังคับ implementation เดียว
ถ้า AI อ่านเอกสารนี้แล้วต้องสร้างระบบ มันสามารถ infer ต่อได้ค่อนข้างดีว่าต้องมี directory เช่น raw, wiki, schema, index, log และ workflow สำหรับ ingest/query/lint แม้เอกสารจะไม่ได้ specify exact command ทุกอย่าง
สูตรการเขียนแบบนี้
ถ้าผมจะสรุปเป็นสูตรสำหรับเขียน requirement ที่คนอ่านเข้าใจและ AI เอาไปทำต่อได้ ผมจะใช้โครงนี้ครับ
# Title
One-line description
## Intent
เอกสารนี้ใช้เพื่ออะไร ใครเป็นผู้อ่าน มนุษย์หรือ AI หรือทั้งคู่
## The problem
โลกเดิมทำงานอย่างไร และติดปัญหาอะไร
## The core idea
แนวคิดใหม่คืออะไร ต่างจากเดิมอย่างไร
## Examples / use cases
ใช้กับสถานการณ์ไหนได้บ้าง
## Architecture
มี layer, object, actor, ownership อะไรบ้าง
## Operations
workflow หลักคืออะไร เช่น create, ingest, update, query, lint, approve
## Artifacts
ไฟล์ ตาราง log index หรือ output ที่ต้องมีคืออะไร
## Rules and constraints
อะไรทำได้ อะไรห้ามทำ อะไรต้องขอ approval
## Optional tools
อะไรเป็นตัวช่วย แต่ไม่ใช่ core requirement
## Why this works
ทำไมแนวทางนี้ถึงเหมาะ
## Adaptation note
อะไรต้องปรับตาม domain และอะไรควรคงไว้โครงนี้ไม่จำเป็นต้องใช้ทุก section ทุกครั้ง แต่ถ้าเป็นงานที่ต้องให้ทั้งคนและ AI เข้าใจร่วมกัน ผมว่ามันเป็น template ที่ดีมาก
ตัวอย่าง rewrite requirement แบบเดิมให้เป็นสไตล์นี้
ลองดู requirement แบบสั้นที่ยังไม่ค่อยมี context ก่อน
ระบบต้องบันทึก requirement และสร้าง traceability ระหว่าง requirement, API, database และ test case
ถ้าเขียนแบบ context-first อาจเปลี่ยนเป็นประมาณนี้
ทีมเรามีปัญหาว่า requirement, API, database change และ test case กระจายอยู่คนละที่ เวลามี change ใหม่ เรามักไม่รู้ว่าต้องแก้ endpoint ไหน table ไหน และ test ไหนตามไปด้วย แนวคิดของระบบนี้คือสร้าง requirement knowledge graph ที่เก็บ change เป็นแกนกลาง แล้วเชื่อม requirement, UX, API, table, field, test และ approval เข้าด้วยกัน เพื่อให้ทั้งคนและ AI ตรวจ impact ได้ก่อนเริ่ม implement
แบบหลังยาวกว่า แต่ AI เข้าใจมากกว่าเยอะ เพราะมันเห็น problem, object, relation และ goal ของระบบพร้อมกัน ไม่ใช่แค่เห็น feature ที่ต้องทำ
Checklist ก่อนส่งเอกสารให้ AI implement
เวลาผมจะเขียนเอกสารแนวนี้ ผมน่าจะใช้ checklist นี้เช็กตัวเองครับ
- คนอ่านรู้ไหมว่าปัญหาเดิมคืออะไร
- มีประโยค core idea ที่จำได้ใน 1-2 บรรทัดไหม
- มี actor และ ownership ชัดไหม
- มี layer หรือ entity หลักครบไหม
- มี operation verbs ที่ AI แปลงเป็น task ได้ไหม
- มี artifact ชัดไหม เช่น file, index, log, schema, report
- มี rule ว่าอะไรห้ามแก้ หรืออะไรต้องขอ approval ไหม
- มีตัวอย่าง use case ให้มนุษย์เห็นภาพไหม
- มี note ว่าอะไร optional และอะไร core ไหม
- อ่านแล้วคนเข้าใจโดยไม่ต้องถามเพิ่ม และ AI มี context พอจะเริ่ม plan ได้ไหม
สรุป
สิ่งที่ผมชอบในเอกสาร LLM Wiki ของ Karpathy คือมันอยู่ตรงกลางระหว่าง essay กับ spec ครับ มันไม่ได้แข็งแบบ requirement document เต็มรูปแบบ แต่ก็ไม่ได้เป็นบทความเล่าไอเดียลอยๆ
มันเขียนให้มนุษย์เข้าใจผ่าน problem, contrast, metaphor และตัวอย่าง แต่ในขณะเดียวกันก็ใส่ architecture, operation, artifact และ constraint พอให้ AI agent เอาไป instantiate ต่อได้
ถ้าต้องเขียน requirement ในยุคที่ AI เป็นคนช่วย implement ผมว่าเราอาจต้องเขียนเอกสารแบบนี้มากขึ้น คือไม่ใช่แค่ “ระบบต้องทำอะไร” แต่ต้องเขียนให้เห็นว่า “โลกนี้ทำงานอย่างไร, ปัญหาอยู่ตรงไหน, object สำคัญคืออะไร, ใครเป็นเจ้าของอะไร, workflow ควรไหลอย่างไร, และอะไรคือกติกาที่ห้ามหลุด”
พูดอีกแบบคือ requirement ที่ดีสำหรับ AI ไม่ใช่ requirement ที่ละเอียดที่สุดเสมอไป แต่คือ requirement ที่จัด context ได้ถูกที่สุดครับ
แหล่งอ้างอิง
- Andrej Karpathy: LLM Wiki gist
- Raw text version of the LLM Wiki gist
- Hacker News discussion: Karpathy LLM Wiki gist
