Context Engineering Handbook

สิ่งที่โมเดลเห็น มีคนประกอบให้ทั้งหมด — และคนคนนั้นควรเป็นพี่ (Handbook #08 · บันไดสาย AI ขั้นที่สาม) · ภาคต่อของ Prompt 0 → Hero สำหรับคนที่ใช้ AI ทำงานจริงจนชนกำแพงว่า "คุยยาวแล้วมันโง่ลง" หรือ "ต้องเล่าเรื่องตัวเองใหม่ทุกแชต" — เล่มนี้ไม่ได้สอนว่าพิมพ์อะไร แต่สอนว่า ณ วินาทีที่โมเดลถูกเรียก อะไรอยู่ตรงหน้ามันบ้าง ใครเป็นคนใส่ และอะไรควรถูกเอาออก · ไม่ต้องเขียนโค้ดก็อ่านได้ทั้งเล่ม

• ระดับ: ใช้ AI เป็น → ประกอบบริบทเป็น (14 บท · 5 ระดับ)
• เวลาอ่าน: ~40 นาที (อ่านเป็น Level ได้)
• ภาษา: ไทย พร้อมไดอะแกรม

LEVEL 0 · ปูพื้นจากศูนย์

01โมเดลไม่มีความจำ — เราประกอบอะไรให้มันทุกครั้ง#

บทนี้สำคัญที่สุดในเล่มครับ ถ้าพี่เข้าใจบทเดียวนี้จริง ๆ อีกสิบสามบทที่เหลือจะกลายเป็นเรื่อง "เดาได้เอง" แทบทั้งหมด

เริ่มจากเรื่องที่พี่น่าจะเคยเจอ: คุยกับ AI มาชั่วโมงหนึ่ง มันจำชื่อโปรเจกต์ได้ จำข้อตกลงเมื่อสิบนาทีที่แล้วได้ เรียกเราด้วยสรรพนามที่ขอไว้ตอนต้น — พอวันรุ่งขึ้นเปิดแชตใหม่ มันไม่รู้จักพี่เลยสักนิด

คำอธิบายที่คนส่วนใหญ่ให้คือ "มันลืม" — ซึ่งผิดครับ และผิดในทางที่ทำให้เข้าใจเรื่องอื่นผิดตามไปหมดทั้งสาย

1.1 สิ่งที่เกิดขึ้นจริงตอนกด Enter

ทุกครั้งที่พี่กด Enter สิ่งที่ถูกส่งไปหาโมเดลไม่ใช่ประโยคที่พี่เพิ่งพิมพ์ — แต่คือ ก้อนข้อความก้อนเดียว ที่ถูกประกอบขึ้นใหม่ทั้งก้อน ประกอบด้วยคำสั่งประจำตัวมัน บวกประวัติการคุยทั้งหมดตั้งแต่ข้อความแรก บวกสิ่งที่พี่เพิ่งพิมพ์ ต่อกันเป็นสายเดียว

โมเดลอ่านก้อนนั้นตั้งแต่ต้นจนจบ ทำนายคำถัดไปออกมา แล้ว ลืมทุกอย่างทันทีที่ตอบจบ · รอบถัดไปประกอบใหม่หมดอีกครั้ง คราวนี้มีคำตอบที่มันเพิ่งตอบรวมอยู่ด้วย

โมเดลไม่มีสถานะ ไม่มีความจำ — สิ่งเดียวที่มันมีคือก้อนข้อความที่ถูกประกอบขึ้นใหม่ทุกครั้งที่ถูกเรียก

1.2 อุปมาที่ใช้ได้ และจุดที่มันใช้ไม่ได้

ลองนึกถึงพนักงานที่เก่งมาก ประสบการณ์สูงมาก แต่ ความจำถูกล้างทุกครั้งที่เดินเข้าห้อง สิ่งเดียวที่เขามีคือแฟ้มหนึ่งใบที่วางรออยู่บนโต๊ะ

ถ้าแฟ้มนั้นมีของครบ เขาทำงานได้ยอดเยี่ยม · ถ้าแฟ้มมีแต่กระดาษเก่าปนกันมั่ว เขาก็ทำงานเหมือนคนสับสน — ไม่ใช่เพราะเขาโง่ลง แต่เพราะแฟ้มมันแย่

1.3 สามคำถามที่บทนี้เพิ่งสร้างขึ้นมา

ถ้าพี่รับความจริงข้อนี้ไปเต็ม ๆ จะมีคำถามผุดขึ้นมาทันทีสามข้อ และเล่มนี้จะไขให้ครบทั้งสาม:

1. "ถ้ามันเห็นก้อนใหม่ทุกครั้ง แล้วทำไมมันจำเรื่องที่คุยเมื่อกี้ได้" → ไขในบทที่ 2
2. "ถ้าส่งใหม่ทั้งก้อนทุกรอบ ค่าใช้จ่ายไม่ระเบิดเหรอ" → ไขในบทที่ 6 และคำตอบสวยกว่าที่คิด
3. "ของที่อยู่ในก้อนแล้ว โมเดลเห็นเท่ากันหมดหรือเปล่า" → ไขในบทที่ 4 คำตอบคือ ไม่

02ในหน้าต่างมีอะไรบ้าง — ผ่ากองทั้งหมด#

"ผมพิมพ์ไปสามบรรทัดเอง ทำไมมันขึ้นว่าใช้ไปสองหมื่นโทเคน" — คำถามนี้ตอบได้ทันทีถ้าเปิดฝาดูว่าในหน้าต่างมีอะไรอยู่บ้าง เพราะสิ่งที่พี่พิมพ์คือกองที่ เล็กที่สุด ในนั้นเสมอ

เราจะดูทีละกอง แต่ละกองตอบสามคำถามเหมือนกันหมด: (ก) มันคืออะไร · (ข) ใครเป็นคนใส่ · (ค) มันโตขึ้นเมื่อไหร่

2.1 กองที่ 1 · คำสั่งประจำตัว

คืออะไร: กติกาที่จริงเสมอไม่ว่าคุยเรื่องอะไร — บุคลิก ภาษา สิ่งที่ห้ามทำ รูปแบบคำตอบ · วงการเรียกว่า system prompt

ใครใส่: คนที่สร้างระบบ และบางส่วนพี่ตั้งเองได้ผ่านหน้าตั้งค่า

โตเมื่อไหร่: แทบไม่โต — คงที่ตลอดทั้งบทสนทนา · คุณสมบัติข้อนี้จะกลายเป็นเรื่องเงินในบทที่ 6

2.2 กองที่ 2 · นิยามเครื่องมือ

คืออะไร: รายการเครื่องมือที่โมเดลเรียกใช้ได้ พร้อมคำอธิบายว่าแต่ละตัวทำอะไรและรับค่าอะไรบ้าง — ค้นเว็บ อ่านไฟล์ ส่งเมล เรียกระบบอื่น

ใครใส่: ระบบ ตั้งแต่ก่อนที่โมเดลจะได้เห็นข้อความแรกของพี่ด้วยซ้ำ

โตเมื่อไหร่: โตตามจำนวนเครื่องมือที่เปิดไว้ · ต่อเครื่องมือภายนอกเข้ามาสามสิบตัว นิยามทั้งสามสิบตัวก็นั่งกินที่ในหน้าต่างทุกรอบ ถึงจะไม่เคยถูกเรียกเลยสักครั้งก็ตาม

2.3 กองที่ 3 · ความจำที่ถูกโหลดเข้ามา

คืออะไร: ไฟล์คำสั่งของโปรเจกต์ สรุปบทสนทนาเก่า โน้ตที่เคยบันทึกไว้ — ของที่ไม่ได้อยู่ในแชตนี้ แต่ระบบหยิบมาแปะให้

ใครใส่: ระบบ ตามกติกาที่ตั้งไว้ เช่น "โหลดไฟล์คำสั่งของโปรเจกต์นี้เสมอ"

โตเมื่อไหร่: โตตามที่พี่เขียนสะสมไว้ — และมันโตแบบ ไม่มีใครเห็น จนกว่าจะไปเปิดดู เรื่องนี้ทั้งเรื่องอยู่ในบทที่ 9

2.4 กองที่ 4 · เอกสารที่ค้นมาได้

คืออะไร: ผลการค้นเอกสาร ไฟล์ที่แนบ หน้าเว็บที่ดึงมา

ใครใส่: ระบบค้นมาให้ก่อน หรือตัวโมเดลค้นเอง — สองแบบนี้ต่างกันมาก และเป็นทั้งบทที่ 7

โตเมื่อไหร่: โตตามความยาวของสิ่งที่ค้นเจอ ซึ่งเราคุมได้น้อยกว่าที่คิด

2.5 กองที่ 5 · ประวัติการคุย — ตัวการที่แท้จริง

คืออะไร: ทุกข้อความที่พี่พิมพ์ ทุกคำตอบที่มันตอบ และผลลัพธ์ของเครื่องมือทุกครั้งที่ถูกเรียก ตั้งแต่ข้อความแรกจนถึงตอนนี้

ใครใส่: ระบบ อัตโนมัติ ทุกรอบ

โตเมื่อไหร่: ตลอดเวลา และเร็วกว่าที่พี่รู้สึกมาก — เพราะตัวที่กินที่จริง ๆ ไม่ใช่ประโยคที่เราพิมพ์ แต่คือ ผลลัพธ์ของเครื่องมือ · อ่านไฟล์หนึ่งครั้งอาจได้มาหลายพันโทเคน รันเทสต์หนึ่งรอบได้ log ยาวเหยียด และของพวกนั้น กองอยู่ในหน้าต่างไปตลอดทั้งเซสชัน ถ้าไม่มีใครจัดการ

นี่คือคำตอบของคำถามที่ปลูกไว้ในบทที่ 1: ที่มันจำเรื่องเมื่อกี้ได้ เพราะเรื่องเมื่อกี้ถูกแนบไปด้วยทั้งก้อนในทุกรอบ ไม่ใช่เพราะมันจำ

2.6 กองที่ 6 · สิ่งที่พี่เพิ่งพิมพ์

กองที่เล็กที่สุด แต่เป็นกองเดียวที่คนส่วนใหญ่คิดว่ามีอยู่

03โทเคนกับกำแพง — นับให้เป็นก่อนบริหารเป็น#

พี่จะบริหารทรัพยากรอะไรก็ตาม ต้องวัดมันได้ก่อน — และหน่วยวัดของหน้าต่างบริบทคือ โทเคน

3.1 โทเคนไม่ใช่ตัวอักษร และไม่ใช่คำ

token (อ่านว่า "โทเคน") คือชิ้นข้อความที่โมเดลตัดออกมาเป็นหน่วยประมวลผล — ไม่ตรงกับตัวอักษร ไม่ตรงกับคำ และไม่ตรงกับอะไรที่มนุษย์นับได้ด้วยตาเปล่า · คำอังกฤษสั้น ๆ ที่พบบ่อยมักเป็นหนึ่งโทเคน ส่วนคำยาวหรือคำแปลกถูกหั่นเป็นหลายชิ้น

3.2 อย่าเดา — ถามระบบ

มีเครื่องมือนับโทเคนให้ใช้ตรง ๆ ไม่ต้องประมาณเอาเอง:

from anthropic import Anthropic

client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-5",
    messages=[{"role": "user", "content": open("CLAUDE.md").read()}],
)
print(resp.input_tokens)

ตัวเลขที่ได้ขึ้นกับข้อความและรุ่นโมเดล — ประเด็นของบทนี้ไม่ใช่ตัวเลข แต่คือ ถาม อย่าเดา

3.3 กำแพงวันนี้อยู่ตรงไหน

รุ่นหลักในตระกูลปัจจุบัน (Opus 5, Sonnet 5, Fable 5) มีหน้าต่าง หนึ่งล้านโทเคน ส่วนรุ่นเล็กอย่าง Haiku 4.5 อยู่ที่สองแสนโทเคน

ฟังดูเยอะจนน่าจะจบปัญหาไปแล้ว — ซึ่งไม่จบครับ และเหตุผลอยู่ในบทที่ 4 กับบทที่ 10 ทั้งสองบท

3.4 เพดานขาออกก็นับด้วย

มีอีกตัวที่คนลืมบ่อย: เพดานความยาวคำตอบ (max_tokens) — และบนรุ่นใหม่ เพดานนี้นับรวมส่วนที่โมเดลใช้คิดในใจด้วย ไม่ได้นับแค่ข้อความที่เราเห็น

แปลว่างานที่เคยตั้งเพดานไว้พอดี ๆ พอย้ายมารุ่นที่คิดในใจเป็นค่าเริ่มต้น อาจโดนตัดกลางประโยคโดยไม่มีอะไรเตือน — อาการคือคำตอบขาดห้วนแบบไม่มีเหตุผล

LEVEL 1 · ใช้ทุกวัน

04ตำแหน่งมีราคา — ต้น กลาง ท้าย ไม่เท่ากัน#

นี่คือคำตอบของคำถามที่ปลูกไว้ตั้งแต่บทที่ 1 ว่า "ของที่อยู่ในหน้าต่างแล้ว โมเดลเห็นเท่ากันหมดหรือเปล่า"

ไม่ครับ และความเข้าใจผิดข้อนี้แพงมาก เพราะมันทำให้คนแก้ปัญหาผิดทาง: พอ AI มองข้ามอะไรไป เราก็ไปเติมข้อมูลเพิ่ม ทั้งที่ข้อมูลนั้นอยู่ในนั้นอยู่แล้ว — แค่อยู่ผิดที่

4.1 อาการที่วงการเรียกว่า "จมกลางน้ำ"

มีปรากฏการณ์ที่วัดกันมาซ้ำ ๆ ว่า ข้อมูลที่อยู่ กลาง บริบทยาว ๆ ถูกใช้งานได้แย่กว่าข้อมูลที่อยู่ต้นหรือท้าย — วงการเรียกว่า lost in the middle

แปลเป็นภาษาคนทำงาน: พี่แนบเอกสารสี่สิบหน้าไปให้ แล้วคำตอบสำคัญอยู่หน้า 19 — โอกาสที่มันจะถูกมองข้าม สูงกว่าคำตอบเดียวกันที่อยู่หน้าแรกหรือหน้าสุดท้ายอย่างมีนัยสำคัญ

4.2 ทำไมท้ายถึงหนักที่สุด

กลไกการทำนายคำถัดไปทำให้สิ่งที่อยู่ ใกล้จุดที่กำลังเขียน มีน้ำหนักมากที่สุดโดยธรรมชาติ — และสิ่งที่ใกล้ที่สุดคือท้ายก้อนเสมอ · ส่วนต้นก้อนได้เปรียบรองลงมา เพราะมันเป็นกรอบที่ทุกอย่างหลังจากนั้นถูกอ่านผ่าน

ตรงกลางไม่ได้ทั้งสองอย่าง

4.3 สามท่าที่ใช้ได้ทันที

① คำสั่งที่สำคัญที่สุด วางท้ายสุด — ถ้าพี่แนบเอกสารยาวแล้วต่อท้ายด้วยคำถาม คำถามนั้นได้ตำแหน่งดีที่สุดอยู่แล้ว · แต่ถ้าพิมพ์คำสั่งก่อนแล้ววางเอกสารต่อท้าย คำสั่งนั้นเพิ่งถูกดันไปอยู่กลางน้ำ

② system prompt ยาว ให้ทวนกติกาสำคัญตอนท้ายอีกครั้ง — หนึ่งถึงสองบรรทัด ไม่ใช่ทวนทั้งหมด · นี่เป็นท่าที่ใช้กันจริงในระบบใหญ่:

<tone_preference>
ตอบสั้น ตรงประเด็น ไม่ต้องเกริ่น
</tone_preference>

③ อย่าฝังของสำคัญไว้กลางกองยาว — ถ้าจำเป็นต้องแนบยาว ให้สรุปประเด็นที่ต้องใช้ไว้ท้ายอีกรอบ · เสียโทเคนนิดเดียว แต่ย้ายของจากตำแหน่งที่แย่ที่สุดไปตำแหน่งที่ดีที่สุด

05คำสั่งถาวร vs เรื่องเฉพาะหน้า — เลเยอร์ที่ห้ามปนกัน#

อาการที่บอกว่าพี่กำลังมีปัญหาข้อนี้: AI เอากติกาของงานเมื่อวานมาใช้กับงานวันนี้ หรือกลับกัน — บอกกติกาสำคัญไปแล้วเมื่อวาน วันนี้ต้องบอกใหม่ทั้งชุด

สองอาการนี้มาจากสาเหตุเดียวกัน: เอาของคนละอายุไปไว้ที่เดียวกัน

5.1 สามอายุของสิ่งที่เราบอก AI

กติกาเดียวที่ต้องจำ: ของที่จะเป็นจริงอีกร้อยครั้ง ไม่ควรต้องพิมพ์ซ้ำร้อยครั้ง · ของที่จริงครั้งเดียว ไม่ควรไปนั่งอยู่ในที่ถาวร

5.2 คำสั่งถาวรที่ดีที่สุด มักไม่ใช่ "ทำยังไง"

ตรงนี้คือจุดที่คนส่วนใหญ่เขียนไฟล์คำสั่งผิด — เขียนแต่ว่าทำอะไรได้บ้าง ทั้งที่ของมีค่าที่สุดคือ "อย่าไปคิดใหม่"

ขอยกของจริงจากเว็บนี้เองมาให้ดู · นี่คือบรรทัดหนึ่งใน CLAUDE.md ของ tayakorn.dev ซึ่งเป็นไฟล์คำสั่งถาวรที่ AI ทุกตัวที่มาแตะโปรเจกต์นี้จะอ่านก่อนลงมือ:

- **audit gate = production scope เท่านั้น**
  (`npm run audit:prod` ต้อง 0)

  **ทดสอบจนสุดทางแล้ว 31 ก.ค. 2026 — ห้ามลองซ้ำ:**
  · eslint 10 พัง lint สองจุด (eslint-plugin-react เรียก
    context API ที่ถูกถอด · `scopeManager.addGlobals` หาย
    แม้อัป typescript-eslint 8.65 ที่ประกาศ peer `eslint ^10`)
    และปิด audit ได้แค่ 3/9
  · `overrides.brace-expansion` ทำ audit เป็น 0 จริง
    แต่ `minimatch@3` พังทันที

  ปลดล็อกเมื่อ upstream ขยับเท่านั้น

อ่านดี ๆ ครับว่าบรรทัดนี้ทำอะไร — มันไม่ได้สอนวิธีทำอะไรเลยสักอย่าง มันบอกว่า มีสามทางที่ดูน่าลอง เราลองมาหมดแล้ว ทั้งสามพัง อย่าไปเสียเวลาอีก

ถ้าไม่มีบรรทัดนี้ AI ที่เก่งและขยันจะมองเห็นปัญหา คิดวิธีแก้ที่สมเหตุสมผลที่สุด แล้วเดินไปเจอกำแพงเดิม — ทุกครั้งที่เปิดแชตใหม่ เพราะมันไม่มีความจำ (บทที่ 1)

คำสั่งถาวรที่แพงที่สุด คือคำสั่งที่กันไม่ให้ใครจ่ายราคาเดิมซ้ำสอง

5.3 เคล็ดลับตรวจไฟล์คำสั่งของตัวเอง

ไล่ทีละบรรทัดแล้วถามคำถามเดียว: "บรรทัดนี้กันความผิดพลาดอะไร"

• ตอบได้ → เก็บไว้
• ตอบว่า "มันก็รู้อยู่แล้วแหละ แต่เขียนไว้ให้ชัวร์" → ตัดทิ้ง มันจ่ายค่าเช่าทุกรอบโดยไม่ให้อะไรกลับมา
• ตอบว่า "เขียนไว้ตอนงานนั้น" แล้วงานนั้นจบไปแล้ว → ตัดทิ้ง

06เงินอยู่ที่ต้นแถว — cache กับกฎอย่าขยับของที่อยู่ต้นก้อน#

ถึงเวลาไขคำถามที่ปลูกไว้ในบทที่ 1 แล้วครับ: ถ้าทุกรอบส่งประวัติทั้งก้อนไปใหม่ ทำไมค่าใช้จ่ายไม่ระเบิด

คำตอบคือ ระบบไม่ได้อ่านทั้งก้อนใหม่จริง ๆ ทุกรอบ — มันจำผลการอ่าน "ท่อนหน้า" ที่เหมือนเดิมเอาไว้ วงการเรียกกลไกนี้ว่า prompt caching และมันเป็นเหตุผลว่าทำไมบทนี้ถึงเป็นบทที่มีผลต่อบิลมากที่สุดในเล่ม

6.1 กลไก — มันจำเป็น "คำนำหน้า" ไม่ใช่จำเป็นชิ้น

หัวใจอยู่ที่คำเดียว: prefix (คำนำหน้า)

ก้อนข้อความถูกประกอบตามลำดับตายตัวเสมอ: นิยามเครื่องมือ → คำสั่งประจำตัว → ประวัติการคุย · ระบบจะจำผลการอ่าน "ตั้งแต่ต้นก้อนถึงจุดที่เรากำหนด" ไว้เป็นก้อนเดียว รอบต่อไปถ้าท่อนนั้น เหมือนเดิมทุกไบต์ มันหยิบของที่จำไว้มาใช้เลย

หนึ่งไบต์ที่เปลี่ยนต้นแถว ล้างทุกอย่างที่อยู่หลังมัน

นี่ไม่ใช่คำเปรียบ — มันคือกฎตรงตัว ถ้าไบต์ที่ตำแหน่งกลางก้อนเปลี่ยน ของที่จำไว้ทั้งหมดตั้งแต่ตำแหน่งนั้นไปจนสุดใช้ไม่ได้อีกเลย

6.2 ราคาจริง และจุดคุ้มทุน

• อ่านจากของที่จำไว้ ≈ 0.1 เท่า ของราคาปกติ
• เขียนของลงไปจำ = 1.25 เท่า (อายุ 5 นาที) หรือ 2 เท่า (อายุ 1 ชั่วโมง)

คิดจุดคุ้มทุนง่าย ๆ:

แปลว่า อายุ 5 นาทีคุ้มตั้งแต่คำขอที่สอง · อายุ 1 ชั่วโมงต้องใช้อย่างน้อยสามรอบถึงจะคุ้ม — เลือกอายุยาวเมื่อทราฟฟิกมาเป็นช่วง ๆ มีช่องว่างเกินห้านาที ไม่ใช่เลือกเพราะฟังดูดีกว่า

6.3 ตัวการเงียบที่ทำให้ไม่มีอะไรถูก cache เลย

ทั้งหมดนี้พังด้วยเรื่องเดียวกัน — มีของที่เปลี่ยนทุกรอบไปนั่งอยู่ต้นแถว:

# ❌ ต้นแถวเปลี่ยนทุกครั้ง — ไม่มีอะไรถูก cache เลยสักไบต์
system = f"วันนี้คือ {datetime.now()}. คุณคือผู้ช่วย..."

# ✅ ต้นแถวนิ่ง — ย้ายวันที่ไปไว้ท้ายสุด
system = "คุณคือผู้ช่วย..."
messages = [..., {"role": "user", "content": f"(วันนี้ {today}) ช่วย..."}]

รายชื่อตัวการที่เจอบ่อยที่สุด:

• เวลา / วันที่ / เลขสุ่ม ใน system prompt
• แปลง JSON โดยไม่เรียงคีย์ — ได้ผลลัพธ์คนละลำดับทุกครั้ง ทั้งที่ข้อมูลเหมือนกัน
• เปลี่ยนชุดเครื่องมือกลางทาง — เครื่องมืออยู่ตำแหน่งแรกสุด เพิ่มหรือถอดตัวเดียวล้างหมดทั้งก้อน
• สลับรุ่นโมเดลกลางบทสนทนา — ของที่จำไว้ผูกกับรุ่น

6.4 ลองพิสูจน์ด้วยตาเอง

ทุกคำตอบที่ระบบส่งกลับมามีตัวเลขสามตัวติดมาด้วย:

ยิงคำขอเดิมสองรอบติดกันแล้วดูตัวที่หนึ่ง — ถ้ารอบสองยังเป็นศูนย์ทั้งที่ท่อนหน้าไม่ควรเปลี่ยน แปลว่ามีตัวการเงียบซ่อนอยู่ ไปไล่หาตามรายชื่อข้างบน

6.5 สั้นเกินไปก็ไม่ถูก cache — และไม่มีใครบอก

มีขั้นต่ำอยู่ · ท่อนหน้าที่สั้นกว่าประมาณ 512 ถึง 4,096 โทเคน แล้วแต่รุ่น จะไม่ถูก cache เลย และ ไม่มี error ไม่มีคำเตือน — เงียบสนิท ตัวเลขก็แค่เป็นศูนย์

LEVEL 2 · ระดับกลาง

07เอาข้อมูลเข้าเมื่อจำเป็น — push กับ pull#

พอรู้ว่าหน้าต่างมีหนึ่งล้านโทเคน ความคิดแรกของเกือบทุกคนคือ "งั้นยัดทุกอย่างเข้าไปเลยสิ" — เอกสารทั้งโฟลเดอร์ โค้ดทั้งโปรเจกต์ ฐานความรู้ทั้งบริษัท

บทที่ 4 บอกไปแล้วว่าทำไมไม่ควร (ของกลางกองจมหาย) และบทที่ 10 จะบอกอีกเหตุผลที่หนักกว่า · บทนี้ว่าด้วยทางเลือกที่ถูกต้อง

7.1 สองวิธีเอาข้อมูลเข้า

แบบ push — ระบบเดาแล้วป้อนให้ก่อน · ผู้ใช้ถามมา ระบบเอาคำถามไปค้นฐานเอกสาร หยิบชิ้นที่ดูเกี่ยวที่สุดสามถึงห้าชิ้นมาแปะไว้ในหน้าต่าง แล้วค่อยให้โมเดลตอบ · วงการเรียกท่านี้ว่า RAG

แบบ pull — โมเดลถือเครื่องมือค้นเอง · ระบบไม่ค้นอะไรให้เลย แต่ยื่นเครื่องมือค้นให้ แล้วปล่อยให้โมเดลตัดสินใจเองว่าจะค้นอะไร ค้นกี่รอบ ค้นเจอแล้วพอหรือยัง · วงการเรียกว่า agentic search

7.2 เทียบกันตรง ๆ

7.3 สมมติฐานที่ทั้งสองแบบเห็นตรงกัน

ต่างกันแค่ว่า ใครตัดสินใจ — แต่ทั้งคู่ยืนอยู่บนความเชื่อเดียวกัน:

ของที่ไม่ได้ใช้ ไม่ควรอยู่ในหน้าต่าง — ต่อให้มีที่ว่างเหลือก็ตาม

นี่คือเหตุผลที่ AI เขียนโค้ดยุคนี้ไม่โหลดทั้งโปรเจกต์เข้าหน้าต่าง แต่ยื่นเครื่องมือ "ค้นไฟล์" กับ "อ่านไฟล์" ให้แทน — จ่ายเฉพาะสิ่งที่หยิบมาใช้จริง

7.4 ท่าสำหรับคนไม่เขียนโค้ด

พี่ใช้หลักการเดียวกันได้โดยไม่ต้องแตะโค้ดเลย:

• แนบไฟล์ แทนที่จะ paste ทั้งฉบับลงแชต — ของที่ paste เข้าไปอยู่ในหน้าต่างทันทีและอยู่ตลอด แต่ไฟล์แนบระบบส่วนใหญ่จะหยิบเฉพาะส่วนที่เกี่ยว
• ถามเจาะจงก่อนถามกว้าง — "ในเอกสารนี้ ข้อ 4.2 เขียนว่าอะไร" ดึงของเข้ามาน้อยกว่าและแม่นกว่า "สรุปเอกสารนี้ให้หน่อย"
• แยกแชตตามงาน — เอกสารของงาน A ไม่ควรตามไปกินที่ในงาน B

08เอาของออกจากโต๊ะ — สรุปยังไงไม่ให้ลืมข้อตกลง#

คุยกันมายาว ระบบขึ้นข้อความว่ากำลังบีบอัดบทสนทนา แล้วหลังจากนั้น AI ก็ ลืมข้อตกลงที่คุยกันไว้ตอนต้น — กลับไปทำสิ่งที่เราบอกไปแล้วว่าอย่าทำ

นี่ไม่ใช่บั๊ก มันคือราคาที่กลไกนี้เก็บ และเราเลือกได้ว่าจะจ่ายด้วยอะไร

8.1 สองวิธีเอาของออก — ลบ กับ ย่อ

① ลบทิ้ง (context editing) — เอาผลลัพธ์เครื่องมือเก่า ๆ ออกจากหน้าต่างตรง ๆ ของที่ถูกลบหายไปเลย ไม่มีอะไรมาแทน · เหมาะกับผลที่ใช้เสร็จแล้วจบ เช่น log ที่อ่านไปแล้ว

② ย่อ (compaction) — สรุปประวัติเก่าให้เหลือย่อหน้าสั้น ๆ แล้วเริ่มหน้าต่างใหม่จากสรุปนั้น · เหมาะกับบทสนทนายาวที่ยังต้องรู้ว่าคุยอะไรกันมา

สองอย่างนี้ ไม่ใช่อย่างเดียวกัน และคนสับสนบ่อยมาก — ลบคือของหายไปเฉย ๆ ย่อคือของยังอยู่แต่เหลือแค่โครง

8.2 คำถามที่ถูกไม่ใช่ "ย่อยังไง" แต่คือ "อะไรต้องรอด"

การย่อคือการบีบอัดแบบมีของหายเสมอ — คำถามเดียวที่มีค่าคือ เลือกให้อะไรรอด

สิ่งที่ต้องรอดเรียงตามลำดับ:

1. การตัดสินใจ และเหตุผลของมัน — "ตกลงใช้วิธี ก. เพราะวิธี ข. ทำให้ระบบเก่าพัง"
2. ข้อห้าม — "ห้ามแตะไฟล์นี้" · "ห้ามลองวิธีนั้นซ้ำ"
3. สถานะปัจจุบัน — ทำถึงไหนแล้ว เหลืออะไร

สิ่งที่ไม่ต้องรอด: คำพูดดิบ ๆ ทั้งหมด ผลเครื่องมือเก่า ทางที่ลองแล้วเลิก (ยกเว้นข้อสรุปว่ามันพัง)

เก็บการตัดสินใจกับเหตุผล อย่าเก็บบทสนทนา

8.3 เคล็ดลับ — สรุปเองก่อนที่ระบบจะสรุปให้

อันนี้ใช้ได้ทันทีวันนี้ ไม่ต้องมีเครื่องมืออะไรเลย · พอรู้สึกว่าบทสนทนายาวจนใกล้ถูกบีบ ให้พิมพ์ไปตรง ๆ:

ก่อนจะคุยต่อ สรุปให้หน่อยว่าเราตกลงอะไรกันไว้แล้วบ้าง
เขียนเป็นข้อ ๆ เอาเฉพาะการตัดสินใจกับเหตุผล และข้อห้าม
ไม่ต้องเล่ากระบวนการ

แล้วเปิดแชตใหม่โดยวางสรุปนั้นเป็นข้อความแรก · พี่เพิ่งควบคุมด้วยตัวเองว่าอะไรรอด แทนที่จะปล่อยให้ระบบเลือกให้

แล้วสรุปก้อนนั้นควรเก็บไว้ที่ไหน — คำถามนี้คือทั้งบทถัดไปครับ

09ความจำที่อยู่นอกหน้าต่าง — สามชั้นความจำ#

บทที่ 8 จบด้วยคำถามว่าสรุปเก็บไว้ที่ไหน · คำตอบคือ ข้างนอกหน้าต่าง และเมื่อออกไปข้างนอกแล้ว มันมีชั้นของมันเอง

9.1 สามชั้น กับต้นทุนของแต่ละชั้น

กติกาการวางของ: ชั้น 2 ต้องเล็กและนิ่ง เพราะจ่ายทุกรอบ · ของหนักไปอยู่ชั้น 3 ให้หมด แล้วให้ชั้น 2 เก็บแค่ดัชนีว่าของอยู่ตรงไหน

9.2 ของจริง — สมองที่สองบนเครื่องนี้

ขอยกโครงจริงของคลังความรู้ที่เจ้าของเว็บนี้ใช้อยู่ทุกวันมาให้ดู เฉพาะโครงกับจำนวนไฟล์ ไม่แตะเนื้อใน:

Brain/
  Knowledge/   110 ไฟล์   ← บทเรียนที่จ่ายราคาไปแล้ว
  Daily/        16 ไฟล์   ← บันทึกรายวัน
  Decisions/    13 ไฟล์   ← เคาะอะไรไปบ้าง เพราะอะไร
  Projects/      9 ไฟล์
  _meta/         7 ไฟล์
  _System/       4 ไฟล์   ← ตัวตน วิธีทำงาน สิ่งที่ชอบ/ไม่ชอบ
  People/        3 ไฟล์

162 ไฟล์ ไม่มีทางอยู่ในหน้าต่างพร้อมกันได้ และไม่ควรอยู่ด้วย · สิ่งที่อยู่ในหน้าต่างจริง ๆ คือ ดัชนีหนึ่งใบ กับไฟล์ที่ถูกหยิบเข้ามาเพราะงานวันนี้ต้องใช้ — บทที่ 7 ทั้งบทคือกลไกที่ทำให้เรื่องนี้เป็นไปได้

สังเกตโฟลเดอร์ Knowledge ที่ใหญ่ที่สุด — มันไม่ได้เก็บ "ความรู้ทั่วไป" ที่โมเดลรู้อยู่แล้ว แต่เก็บของที่โมเดลไม่มีทางรู้: บทเรียนที่คนคนนี้จ่ายราคาไปแล้วบนเครื่องเครื่องนี้

9.3 อันตรายที่ไม่มีใครเตือน — ความจำที่ผิดอยู่ยาวกว่าความจำที่ถูก

ความจำที่ถูกต้องถูกใช้ ถูกยืนยัน ถูกอัปเดต · ส่วนความจำที่ผิดจะนอนนิ่ง ๆ อยู่อย่างนั้น รอวันที่มีใครหยิบมันขึ้นมาใช้ แล้วพาไปผิดทาง

ทางแก้ที่ใช้จริงคือ สแตมป์ — บนเครื่องนี้ ใบความจำที่หมดอายุแล้วจะถูกเขียนทับหัวไว้เลยว่า:

✅ สแตมป์ปิดสถานะค้าง 2026-08-17 — รอบคู่ขนาน ก.ค. 2026 จบครบทุกสายแล้ว
   ⚠️ ไฟล์กติกาที่ใบนี้สั่งให้ไปอ่านตายหมดแล้ว
   ของในใบนี้ที่ยังต้องรู้จริง ๆ เหลือสามข้อ: ...

ใบนั้นไม่ถูกลบ เพราะมันยังมีของดีอยู่สามข้อ — แต่มันถูก ติดป้ายว่าอย่าเชื่อทั้งใบ · ต้นทุนของการเขียนหัวแบบนี้คือสามบรรทัด ต้นทุนของการไม่เขียนคืออีกเดือนหนึ่งที่ใครสักคนทำตามกติกาที่ตายไปแล้ว

9.4 กฎการเขียนความจำที่ใช้ได้จริง

• หนึ่งเรื่อง หนึ่งไฟล์ — ไฟล์รวมทุกอย่างคือไฟล์ที่ไม่มีใครอัปเดต
• บรรทัดแรกต้องบอกว่าไฟล์นี้เกี่ยวกับอะไร — เพราะการค้นจะเห็นแค่บรรทัดนั้น
• เขียนเหตุผลลงไปด้วยเสมอ — "ห้ามทำ ก." ไม่มีค่าเท่ากับ "ห้ามทำ ก. เพราะเคยทำแล้ว ข. พัง"
• ของที่ผิดต้องลบหรือสแตมป์ ไม่ใช่ปล่อยไว้
• อย่าเขียนสิ่งที่โค้ดหรือประวัติบอกอยู่แล้ว — มันจ่ายค่าเช่าซ้ำโดยไม่ให้อะไรใหม่

LEVEL 3 · ระดับสูง

10เมื่อ context เป็นพิษ — สี่อาการ และวิธีแยกจากกัน#

ทุกคนรู้จักอาการรวม ๆ ว่า "คุยยาวแล้วมันโง่ลง" — แต่คำนี้กว้างเกินกว่าจะแก้อะไรได้ เพราะข้างในมันมีสี่โรคคนละโรค คนละวิธีรักษา

วงการแยกไว้สี่อาการ และการแยกให้ออกคือทั้งหมดของบทนี้

10.1 อาการที่ 1 · เป็นพิษ (poisoning)

คืออะไร: มีของผิดหลุดเข้าไปในหน้าต่างหนึ่งชิ้น แล้วมันอยู่ต่อไปทุกรอบ · ทุกการตัดสินใจหลังจากนั้นอ้างอิงของชิ้นนั้น ทั้งที่มันผิดตั้งแต่แรก

ของจริงจากเครื่องนี้ — ตอนรันงานหลายสายพร้อมกัน เจอว่า:

Atlassian MCP ตอบกลับหลงสายข้าม session ได้ —
request ไปถูกใบเสมอ แต่ response อาจเป็นของบอร์ดอื่นที่วิ่งพร้อมกัน
→ เขียนเสร็จต้องยืนยันด้วยการอ่านกลับทุกครั้ง และอย่ารีบ "แก้กลับ" ก่อนตรวจ

อ่านให้ดีว่าเกิดอะไรขึ้น — ผลลัพธ์เครื่องมือของ งานอื่น เข้ามานั่งอยู่ในหน้าต่างของงานนี้ · ทุกอย่างที่ทำต่อจากนั้นตั้งอยู่บนข้อมูลผิด และประโยคสุดท้ายคือบทเรียนที่แพงที่สุด: อย่ารีบแก้กลับ เพราะการแก้ตามข้อมูลผิด ทำให้ของที่ถูกอยู่แล้วพังไปด้วย

วิธีแก้: ยืนยันด้วยแหล่งใหม่ก่อนลงมือต่อ · ถ้ารู้ตัวว่ามีของผิดเข้าไปแล้ว เริ่มหน้าต่างใหม่ อย่านั่งแก้ในหน้าต่างเดิม เพราะของผิดยังอยู่

10.2 อาการที่ 2 · เสียสมาธิ (distraction)

คืออะไร: ของในหน้าต่างถูกทุกชิ้น แต่เยอะเกินไป · โมเดลเริ่มเกาะประวัติแทนที่จะคิดใหม่ — ทำซ้ำสิ่งที่เคยทำ ทั้งที่โจทย์เปลี่ยนไปแล้ว

สังเกตยังไง: มันเริ่มตอบด้วยรูปแบบเดิมซ้ำ ๆ หรือย้อนไปทำขั้นตอนที่ทำผ่านไปแล้ว

วิธีแก้: บีบอัดตามบทที่ 8 · หรือเริ่มใหม่จากสรุป

10.3 อาการที่ 3 · สับสน (confusion)

คืออะไร: ในหน้าต่างมีของสองชิ้นที่ หน้าตาใกล้กันมากแต่คนละเรื่อง — โมเดลหยิบผิดชิ้น

นี่คืออาการที่แก้ด้วยการ "ให้ข้อมูลเพิ่ม" ไม่ได้ เพราะปัญหาไม่ใช่ข้อมูลไม่พอ แต่คือไม่มีเส้นแบ่ง

ของจริงจากเว็บนี้ — ใน CLAUDE.md มีบรรทัดที่หน้าตาแปลก ๆ อยู่บรรทัดหนึ่ง:

⚠️ อาการหลังหน้าตาเหมือนข้อ `node_modules` ข้างล่างมาก แต่คนละเรื่องคนละวิธีแก้ —
   ถ้าเพิ่งฆ่าเซิร์ฟเวอร์มา ให้ `rm -rf .next` ก่อนเสมอ **อย่าเพิ่งไปรื้อ `node_modules`**

บรรทัดนี้ไม่ได้เพิ่มความรู้ใหม่เลยสักคำ — ความรู้ทั้งสองเรื่องอยู่ในไฟล์นั้นอยู่แล้วทั้งคู่ · สิ่งที่มันเพิ่มคือ เส้นแบ่ง พร้อมสัญญาณว่าจะแยกยังไง ("ถ้าเพิ่งฆ่าเซิร์ฟเวอร์มา")

และมันถูกเขียนขึ้นมาเพราะเคยหยิบผิดมาแล้วจริง ๆ — ไปรื้อของที่ไม่ได้พัง

วิธีแก้: เขียนเส้นแบ่งใส่เข้าไป ไม่ใช่เขียนความรู้เพิ่ม · ถ้าของสองอย่างสับสนกันได้ ให้บอกไปเลยว่าแยกยังไงและอันไหนมาก่อน

10.4 อาการที่ 4 · ขัดกันเอง (clash)

คืออะไร: ในหน้าต่างมีของสองชิ้นที่ บอกคนละอย่าง — กติกาเก่ากับกติกาใหม่ ข้อมูลเวอร์ชันเดือนที่แล้วกับของวันนี้ · โมเดลไม่มีทางรู้ว่าอันไหนชนะ

สังเกตยังไง: มันลังเล ตอบก้ำกึ่ง หรือทำตามอันเก่าโดยไม่บอกว่าทำไม

วิธีแก้: ของเก่าต้องถูกลบ ไม่ใช่แค่ถูกทับ · ถ้าลบไม่ได้ ต้องติดสแตมป์ว่าอันไหนใช้ไม่ได้แล้ว (บทที่ 9)

10.5 ตารางแยกโรค

11หลายหน้าต่างดีกว่าหน้าต่างเดียว — แยกบริบทกับค่าส่งต่อ#

มีงานประเภทหนึ่งที่ทำในหน้าต่างเดียวไม่ไหวเลย: งานที่ต้องอ่านเยอะแต่ใช้จริงนิดเดียว — สำรวจสิบไฟล์เพื่อหาคำตอบสามบรรทัด · อ่านห้าแหล่งเพื่อสรุปหนึ่งย่อหน้า

ปัญหาไม่ใช่ว่าอ่านไม่ทัน แต่คือ ทุกอย่างที่อ่านไปค้างอยู่ในหน้าต่างตลอดกาล ตามบทที่ 2 — แล้วก็เกิดอาการเสียสมาธิตามบทที่ 10 ตามมา

11.1 เหตุผลจริงที่การแตกงานเวิร์ก

คนส่วนใหญ่เข้าใจว่าการแตกงานให้ตัวช่วยหลายตัวดีเพราะ ทำพร้อมกันได้เร็วกว่า — ความเร็วเป็นของแถมครับ

เหตุผลจริงที่มันเวิร์ก คือแต่ละตัวได้หน้าต่างสะอาดของตัวเอง แล้วส่งกลับมาแค่ข้อสรุป

ตัวลูกอ่านไฟล์เป็นหมื่นโทเคนในหน้าต่างของมันเอง แล้วส่งกลับมาสามบรรทัด · หน้าต่างของตัวแม่โตขึ้นแค่สามบรรทัดนั้น ไม่ใช่หมื่นโทเคน

11.2 ราคาที่ต้องจ่าย — ค่าบรีฟ

ตัวลูก ไม่เห็นบทสนทนาของตัวแม่เลยสักตัวอักษร — มันเกิดมาพร้อมหน้าต่างเปล่า

แปลว่าโจทย์ที่ส่งไปต้องครบในตัวเอง: ของอยู่ที่ไหน ข้อจำกัดคืออะไร อยากได้รายงานหน้าตาแบบไหน · โจทย์ที่เขียนว่า "ตรวจอันนั้นให้หน่อย" ใช้ไม่ได้ เพราะไม่มี "อันนั้น" ในหน้าต่างของมัน

เมื่อไหร่ไม่ควรแตก: งานที่ทำเองจบใน 3–4 ก้าว · ค่าบรีฟกับค่าอ่านรายงานกลับ แพงกว่าตัวงาน

11.3 บทเรียนจากการรันหลายสายจริง

ตอนที่เว็บนี้ถูกพัฒนาหลายสายพร้อมกัน กติกาที่รอดมาเหลือสองข้อ และทั้งสองข้อเป็นเรื่องบริบททั้งคู่:

1. แบ่งเขตความเป็นเจ้าของตามโซนไฟล์ — สายไหนแตะไฟล์ไหนได้ ระบุให้ชัดตั้งแต่ต้น · ไม่ใช่เพื่อกันไฟล์ชนกันอย่างเดียว แต่เพื่อให้แต่ละสาย ไม่ต้องแบกบริบทของสายอื่น
2. บังคับลำดับการรวมงาน — สายที่รวมทีหลังต้องตรวจซ้ำ ณ วันที่รวม เพราะโลกข้างนอกขยับได้ระหว่างที่สายนั้นทำงานอยู่

ข้อสองคือรูปหนึ่งของอาการ "ขัดกันเอง" ในบทที่ 10 — บริบทที่ถูกต้อง ณ วันที่เริ่ม อาจผิดแล้ว ณ วันที่จบ

12รู้ได้ยังไงว่า context ดีขึ้น — ตัดออกทีละก้อนแล้ววัด#

พี่เพิ่มไฟล์คำสั่งเข้าไปสามย่อหน้า แล้วรู้สึกว่ามันตอบดีขึ้น — พิสูจน์ได้ไหมครับ

ส่วนใหญ่พิสูจน์ไม่ได้ และนั่นคือเหตุผลที่ไฟล์คำสั่งของทุกคนมีแต่โตขึ้น ไม่เคยเล็กลง · ไม่มีใครกล้าตัดอะไรออก เพราะไม่มีใครรู้ว่าอันไหนทำงานอยู่จริง

12.1 วิธีเดียวที่ตอบได้ — ตัดออกแล้ววัด

วิธีนี้เรียบง่ายจนน่าตกใจ:

1. ทำชุดโจทย์ประจำไว้ 10–20 ข้อ ที่พี่รู้คำตอบที่ถูกอยู่แล้ว
2. รันด้วยบริบทเต็ม จดผลไว้
3. ตัดออกทีละก้อน แล้วรันชุดเดิมซ้ำ
4. ก้อนที่ตัดแล้วผลไม่เปลี่ยน = ก้อนที่พี่จ่ายค่าเช่าอยู่ทุกรอบโดยไม่ได้อะไรกลับมา

จุดที่คนทำผิดคือทำกลับด้าน — เอาแต่ เพิ่ม แล้วดูว่าดีขึ้นไหม · การเพิ่มมักดูเหมือนดีขึ้นเสมอ เพราะเราเป็นคนตัดสินเอง และเราเพิ่งลงแรงเพิ่มมันไป

12.2 ตัวเลขที่ดูได้ฟรีทุกครั้ง

จากบทที่ 6 พี่มีตัวเลขสามตัวอยู่แล้วโดยไม่ต้องตั้งอะไรเพิ่ม · เอามาใช้เป็นเครื่องวัดพื้นฐานได้เลย:

• ผลรวมสามตัว = ขนาดคำขอจริง ดูว่ามันโตขึ้นทุกสัปดาห์ไหม
• สัดส่วนที่มาจาก cache = สุขภาพของการจัดลำดับ ถ้าตกลงเรื่อย ๆ แปลว่ามีอะไรไปกวนต้นแถว
• ส่วนที่ต้องอ่านใหม่ = ของที่เปลี่ยนจริงในรอบนี้

12.3 กติกาความซื่อสัตย์สามข้อ

• อย่าวัดในวันเดียวกับที่เพิ่งแก้ — เราจะเห็นสิ่งที่อยากเห็น
• อย่าวัดด้วยความรู้สึกว่า "คำตอบอ่านลื่นขึ้น" — ลื่นขึ้นกับถูกขึ้นเป็นคนละเรื่อง
• เปลี่ยนทีละอย่าง — เปลี่ยนสามอย่างพร้อมกันแล้วดีขึ้น พี่ไม่มีทางรู้ว่าอันไหนช่วย และอาจมีอันหนึ่งกำลังทำร้ายอยู่แต่ถูกกลบ

LEVEL 4 · ระดับเทพ

13ประกอบ context ของตัวเอง — ผ่าของจริงหนึ่งเทิร์น#

สิบสองบทที่ผ่านมาคือชิ้นส่วน บทนี้คือการประกอบ · เราจะเดินดูว่า หนึ่งเทิร์น ของ AI ที่ทำงานจริงบนโปรเจกต์หนึ่ง มีอะไรถูกประกอบเข้าไปบ้าง เรียงตามลำดับจริง

13.1 เดินทีละกอง

สังเกตว่าลำดับนี้ ไม่ได้เรียงตามความสำคัญ แต่เรียงตาม ความนิ่ง — ของนิ่งอยู่ต้น ของเปลี่ยนบ่อยอยู่ท้าย เพราะกฎในบทที่ 6

ของยิ่งนิ่ง ยิ่งควรอยู่ต้นแถว · ของยิ่งเปลี่ยนบ่อย ยิ่งต้องอยู่ท้าย

13.2 ลองพิสูจน์ด้วยตาเอง

เปิดแชตที่พี่ใช้ทำงานอยู่ประจำ แล้วถามมันตรง ๆ:

ตอนนี้อะไรอยู่ในบริบทของคุณบ้าง เรียงตามลำดับที่มันถูกใส่เข้ามา
บอกด้วยว่าอันไหนมาจากคำสั่งประจำตัว อันไหนมาจากไฟล์ อันไหนมาจากบทสนทนานี้

คำตอบจะไม่เป๊ะ 100% และไม่ต้องคาดหวังว่าจะเป๊ะ · จุดที่มีค่าคือจุดที่มันตอบไม่ตรงกับที่พี่คิด — ตรงนั้นคือของที่พี่ไม่รู้ว่ากำลังจ่ายค่าเช่าให้อยู่

13.3 เช็กลิสต์หกข้อ ก่อนปล่อยงานยาว

• ของนิ่งอยู่ต้น ของเปลี่ยนบ่อยอยู่ท้าย — ไม่มีเวลา วันที่ หรือเลขสุ่มใน system prompt (บท 6)
• ทุกบรรทัดในไฟล์คำสั่งตอบได้ว่ากันความผิดพลาดอะไร (บท 5)
• เครื่องมือที่ไม่ได้ใช้ ถูกปิดแล้ว — นิยามที่ไม่เคยถูกเรียกก็ยังจ่ายทุกรอบ (บท 2)
• ของหนักอยู่ข้างนอก ไม่ใช่ในไฟล์ที่โหลดเสมอ (บท 9)
• คำสั่งสำคัญที่สุดอยู่ท้ายสุด (บท 4)
• รู้ว่าจะสรุปยังไงตอนหน้าต่างใกล้เต็ม และรู้ว่าอะไรต้องรอด (บท 8)

13.4 ถ้าจำได้ข้อเดียวจากทั้งเล่ม

ให้เป็นข้อนี้ครับ:

ทุกโทเคนที่อยู่ในหน้าต่าง ต้องตอบได้ว่ามันอยู่ตรงนั้นทำไม — และคำว่า "เผื่อได้ใช้" ไม่ใช่คำตอบ

14ทักษะที่ไม่หมดอายุ — และปิดเล่ม#

14.1 เทคนิคจะหมดอายุ กลไกจะอยู่

หน้าต่างจะใหญ่ขึ้น การบีบอัดจะฉลาดขึ้น การจัดลำดับบางอย่างจะถูกระบบทำให้เองโดยเราไม่ต้องรู้ · เทคนิคหลายข้อในเล่มนี้จะกลายเป็นเรื่องที่ไม่ต้องคิดในอีกไม่กี่ปี

แต่กลไกแกนไม่หายไปไหน เพราะมันไม่ใช่ข้อจำกัดชั่วคราว — มันคือรูปร่างของตัวเทคโนโลยีเอง · ตราบใดที่โมเดลยังทำงานด้วยการอ่านก้อนข้อความแล้วทำนายคำถัดไป ตราบนั้นจะยังมีคนต้องตัดสินใจว่าอะไรอยู่ในก้อนนั้น

14.2 สี่ทักษะที่เล่มนี้ฝึกจริง ๆ

ถ้าถอดศัพท์เทคนิคออกให้หมด สิ่งที่เหลืออยู่คือทักษะของคนทำงาน ไม่ใช่ทักษะ AI:

1. ตัดสินว่าอะไรเกี่ยว — ทักษะเดียวกับการเตรียมวาระประชุมให้คนที่ไม่ได้อยู่ตั้งแต่ต้น (บท 2, 7)
2. เขียนสิ่งที่รู้แล้วให้คนอื่นใช้ซ้ำได้ — ทักษะเดียวกับการเขียนคู่มือที่คนอ่านแล้วไม่ต้องมาถามซ้ำ (บท 5, 9)
3. รู้ว่าอะไรควรลืม — ทักษะที่ยากที่สุดในสี่ข้อ เพราะการเก็บของไว้รู้สึกปลอดภัยกว่าเสมอ (บท 8, 10)
4. วัดอย่างซื่อสัตย์ — ทักษะเดียวกับการยอมรับว่าสิ่งที่เราเพิ่งทำอาจไม่ได้ช่วยอะไร (บท 12)

สี่ข้อนี้มีมาก่อน AI และจะอยู่ต่อหลังโมเดลรุ่นที่เรารู้จักวันนี้เกษียณไปหมดแล้ว

14.3 ปิดเล่ม

เริ่มเล่มด้วยประโยคว่าโมเดลไม่มีความจำ — ตอนนี้พี่น่าจะเห็นแล้วว่านั่นไม่ใช่ข้อจำกัดที่ต้องทน แต่เป็น จุดที่เราเข้าไปควบคุมได้

เพราะถ้ามันไม่มีความจำ แปลว่าความจำของมันคือสิ่งที่เราเขียนขึ้น · ถ้ามันเห็นก้อนใหม่ทุกครั้ง แปลว่าเราเป็นคนตัดสินใจว่าก้อนนั้นมีอะไร

✅ จบขั้นที่สามของบันไดสาย AI — เดินมาสามขั้นแล้ว: ใช้ AI เป็น (เข้าใจกลไกเดาคำถัดไป เขียน prompt ครบส่วน) → สั่ง AI ระดับโปร (few-shot, grounding, chaining, ต่อเครื่องมือ) → ประกอบบริบทเป็น (รู้ว่าอะไรอยู่ในหน้าต่าง เรียงยังไง อะไรต้องออก และวัดยังไงว่าดีขึ้นจริง) · ที่เหลือคือสิ่งเดียวกับทุกเล่มใน collection นี้ครับ — เอาไปใช้จริง แล้วให้ของจริงสอนต่อ

อ่านต่อ: Harness Engineering#

Context Engineering — ฉบับเข้าใจถึงแก่น — ศาสตร์ของการตัดสินใจว่าอะไรควรอยู่ตรงหน้าโมเดล ณ วินาทีที่มันถูกเรียก สำหรับคนที่ใช้ AI ทำงานจริงจนชนกำแพงว่าทำไมคุยยาวแล้วมันโง่ลง

ภาคต่อของ Prompt 0 → Hero · ส่วนหนึ่งของ Handbooks — เขียนเพื่อเข้าใจ ไม่ใช่เพื่อท่องจำ · โดย @tayakorn221 · 2026