แกะรูปแบบการเขียน Requirement ระบบ LLM Wiki ของ Karpathy

ผมชอบเอกสารชิ้นหนึ่งของ 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 แบบไม่รู้บริบท

โครงสร้างหลักของเอกสาร

ถ้าแกะเป็นโครง เอกสารนี้มีลำดับที่ค่อนข้างชัดครับ

สิ่งที่น่าสนใจคือมันไม่ได้เป็น 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 นี่คือ 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