ผมไปเจอ whitepaper ของ Google เรื่อง The New SDLC with Vibe Coding และน่าสนใจพอสมควร เพราะเอกสารนี้ ผู้เขียนวางกรอบใหม่ว่า Software Development Life Cycle หรือ SDLC ควรเปลี่ยนอย่างไร เมื่อคนเริ่มขยับจากการเขียน syntax ไปเป็นการระบุเจตจำนง (intent) แล้วให้ agent ลงมือแทน

ในเอกสารนี้ ผู้เขียนทดสอบทำงานระดับ production โดยเทียบระหว่าง Vibe Coding กับ Agentic Engineering ที่มี spec, context, tests, evals, guardrails และคนคอยตัดสินใจ เพื่อให้เห็นภาพใหญ่ และในบทความนี้ผมขอหยิบของ Google ไปเทียบกับ SDLC สำนักอื่นๆ เพิ่มเติม เพื่อให้เห็นภาพชัดขึ้นครับ

หมายเหตุ: ฟิวส์และเอเจ้นชมพูช่วยแปลและเรียบเรียงจาก whitepaper ของ Google เรื่อง The New SDLC with Vibe Coding โดย Addy Osmani, Shubham Saboo และ Sokratis Kartakis พร้อมค้นข้อมูลเสริมจาก Second Brain ของฟิวส์เพื่อใช้เปรียบเทียบแนวทาง SDLC ที่เกี่ยวข้อง

สรุปไฮไลต์สั้นๆ

• คอขวดย้ายจาก syntax ไปที่ intent เมื่อ AI เขียน code เร็วขึ้น งานกำหนดโจทย์ ออกแบบ และตรวจสอบจึงสำคัญกว่าเดิม และอาจจะยังช้าอยู่
• Vibe Coding ไม่เท่ากับ Agentic Engineering งานทดลองรับความเสี่ยงได้ แต่งาน production ต้องมีโครงสร้างและหลักฐาน
• Context Engineering คือทักษะหลัก คุณภาพไม่ได้ขึ้นกับ prompt เก่งอย่างเดียว แต่ขึ้นกับ instructions, knowledge, memory, examples, tools และ guardrails
• Harness ส่งเสริมกับ model ให้กลายเป็นระบบงาน ทั้ง rule files, tools, sandbox, orchestration, hooks, tests, evals และ observability
• บทบาท Developer เปลี่ยน จากคนลงมือ implement เป็น conductor และ orchestrator ที่กำหนดงาน คุมข้อจำกัด และตรวจผล
• Second Brain แต่ละกรอบตอบคนละคำถาม Google ให้แผนที่ภาพใหญ่ ส่วน AWS, Anthropic, Spec-Driven Development และ McKinsey ลงลึกคนละชั้น

The New SDLC with Vibe Coding by Google

เอกสารความยาว 51 หน้านี้ เผยแพร่ตั้งแต่พฤษภาคม 2026 เขียนโดย Addy Osmani วิศวกรและนักเขียนด้าน software engineering, Shubham Saboo ผู้ทำงานด้าน AI agents และ Sokratis Kartakis ผู้ทำงานกับ agent platforms และ Google ADK

คำว่า Vibe Coding เป็นคำที่ Andrej Karpathy ใช้อธิบายการเขียนโปรแกรมแบบปล่อยไปตามจังหวะ สั่ง AI ด้วยภาษาธรรมชาติ รับ output แล้วโยน error กลับไปให้แก้ต่อ แต่ whitepaper ไม่ได้สนับสนุนให้เราใช้วิธีนั้นกับทุกงานครับ

ผู้เขียนอยากให้มองวิธีทำงานกับ AI ให้เหมาะสมกับงาน ด้านหนึ่งคือ Vibe Coding ที่เหมาะกับ prototype, script, personal project หรือ hackathon อีกด้านคือ Agentic Engineering ที่เหมาะกับระบบ production และงานระดับทีม ความต่างไม่ได้อยู่ที่ใช้ AI รุ่นไหน แต่อยู่ที่มี structure, verification และการตัดสินใจของมนุษย์

เครื่องมือเดียวกันใช้ทำ Vibe Coding หรือ Agentic Engineering ก็ได้ สิ่งที่แยกสองแบบออกจากกันคือ เครื่องมือและองค์ประกอบรอบๆ AI ไม่ใช่เฉพาะ model

ผมมองว่าจุดนี้สำคัญ เพราะในช่วงแรกเราเรียกแทบทุกอย่างที่ใช้ AI เขียน code ว่า Vibe Coding จนคำเริ่มกว้างเกินไป, Senior Engineer ที่วางโครงระบบให้มี architecture, test suite และ review gate ชัดเจน ไม่ควรถูกจัดอยู่กลุ่มเดียวกับคนที่สั่งว่า “ช่วยทำระบบ payment ให้หน่อย แล้วกด deploy เลย” แบบหลังนี่ใจถึงเกินไปครับ 555

ปัญหาของ SDLC เดิมไม่ได้หายไป แต่มันถูกบีบไม่เท่ากัน

SDLC ผ่านการเปลี่ยนใหญ่จาก Waterfall ไปสู่ Agile, Continuous Integration และ DevOps มาแล้ว รอบนั้นช่วยลด feedback loop และทำให้ deployment ต่อเนื่องขึ้น แต่ AI กำลังบีบวงจรให้กระชับอีกแบบหนึ่งครับ

Implementation ที่เคยใช้เวลาหลายสัปดาห์อาจเหลือไม่กี่ชั่วโมง ขณะที่ requirement, architecture และ verification ยังเดินด้วยความเร็วของคน การเอา AI ไปเร่งเฉพาะช่วง Build จึงเหมือนขยายโรงงานผลิตสินค้าเป็นสิบเท่า แต่โต๊ะตรวจคุณภาพยังมีเจ้าหน้าที่สองคนเท่าเดิม สุดท้ายกล่องจะไปกองอยู่หน้าโต๊ะ QA แทน

เอกสารได้ยกงานวิจัยและแบบสำรวจที่ให้ภาพสองด้าน บางแหล่งรายงาน productivity เพิ่ม 25-39% ในบางงาน แต่การศึกษาของ METR พบว่านักพัฒนาที่มีประสบการณ์ใช้เวลานานขึ้น 19% กับงานบางประเภท เพราะต้องตรวจ แก้ และ debug output ของ AI เพิ่ม ตัวเลขเหล่านี้ไม่ได้แปลว่า AI ดีหรือไม่ดีแบบฟันธง แต่มันกำลังเตือนเราว่าความเร็วในการ generate code ไม่เท่ากับความเร็วในการส่งมอบ

AI ไม่ได้ทำให้การ implementation หายไป แต่มันเปลี่ยนงานจากการเขียนโค้ด ไปเป็นการกำหนดทิศทาง ตรวจสอบ และรับผิดชอบต่อผลลัพธ์

อีกปัญหาคือสิ่งที่ whitepaper เรียกว่า 80% problem, AI ทำส่วนใหญ่ของ feature ได้เร็ว แต่ส่วนที่เหลือมักเป็น edge cases, error handling, integration point และ business rule ละเอียดๆ ซึ่งต้องใช้การตรวจสอบและการวิเคราะห์สูงมาก เพราะ Code ที่ออกมาดูดีและผ่านการ test พื้นฐาน อาจซ่อนสมมติฐานผิดไว้ ซึ่งน่ากลัวกว่า syntax error มากครับ เพราะหน้าตามันดูน่าเชื่อมาก ไม่ได้แสดงผลลัพธ์ว่ามีอะไรผิดเลย

กระบวนการใหม่เริ่มจาก Context ก่อน Code

หัวใจของแนวทางนี้คือ Context Engineering หรือ เตรียมข้อมูลต่างๆที่ agent ต้องใช้ให้ครบ แล้วค่อยเริ่มงาน ซึ่งจะต่างจาก Vibe Coding ที่จะเขียน prompt หนึ่งย่อหน้าแล้ว คาดว่าจะได้ระบบระดับ production กลับมา

ผู้เขียนได้แบ่งประเภท context ออกเป็น 6 กลุ่ม

• Instructions บทบาท เป้าหมาย และขอบเขตการทำงาน
• Knowledge เอกสาร สถาปัตยกรรม และข้อมูลเฉพาะ domain
• Memory สถานะระยะสั้นและความรู้ที่ต้องจำข้าม session
• Examples ตัวอย่าง behavior และ pattern จาก codebase
• Tools API, scripts, database และบริการที่เรียกใช้ได้
• Guardrails ข้อจำกัด กฎรูปแบบ และการตรวจความปลอดภัย

จากนั้นต้องแยกระหว่าง static context ออกจาก dynamic context ให้ดี โดย

Static context เช่น `AGENTS.md`, `CLAUDE.md` หรือกฎระดับ project จะถูกโหลดบ่อย จึงควรสั้นและมีสัญญาณสูง

ส่วน Dynamic context จะเป็นพวกความรู้เฉพาะทางควรโหลดเมื่อ task ต้องใช้งาน ไม่ว่าจะผ่าน skills, tools หรือ retrieval

ซึ่งการใช้ Static/Dynamic ผิดที่ผิดทาง จะทำให้เปลือง token มากพอสมควร แม้งานแก้อาจจะมีแค่นิดเดียวก็ตาม

เรื่องนี้ผมเองก็เคยพลาดอยู่นาน ตอนใช้ OpenClaw/Hermes Agent ใหม่ๆ แค่ใช้คุยและทำงานเล็กๆ แต่ทำให้ token หมดไวมาก เพราะฝังพวกกฎและความสามารถบางอย่างไปไว้ใน Static context ทำให้ใช้ token ก้อนใหญ่ทุกครั้งที่มีการเปิด session หรือ chat

Factory Model เปลี่ยนสิ่งที่ Developer ต้องสร้าง

เมื่อ context พร้อม ผู้เขียนเสนอ Factory Model มองว่า output หลักของ Developer ไม่ได้มีแค่ code แต่คือระบบที่ผลิต code อย่างเชื่อถือได้ ระบบนี้ประกอบด้วย spec, agents, tests, quality gates, feedback loops และ guardrails

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

Harness คือเครื่องจักรรอบตัว Model

Harness Engineering คือการออกแบบชั้นที่ห่อ model ให้ทำงานได้จริง ทั้ง rule files, tools, sandbox, orchestration, subagents, hooks, logs, traces, cost และ latency monitoring สมการสั้นๆ ในเอกสารคือ Agent = Model + Harness (Agent เท่ากับ Model บวก Harness)

• ช่วงวางแผน Harness โหลดกฎและข้อจำกัด
• ช่วง implement มันจัด tool กับ sandbox ให้ agent ใช้
• ช่วง test มันส่งผลล้มเหลวกลับเข้า loop เพื่อแก้ใหม่
• และช่วง review หรือ deploy มันใช้ hooks กับ observability ป้องกันสิ่งที่ห้ามเกิด เช่น secret หลุดหรือ commit ที่ไม่ผ่านเงื่อนไข

เมื่อ Agent ทำผิด คำถามแรกไม่ควรเป็น Model รุ่นนี้ไม่เก่งหรือเปล่า แต่อาจต้องถามก่อนว่าเราใช้ Harness อะไร, เราขาด tool, context, rule, guardrail หรือ feedback loop ตรงไหน

แต่ละช่วงของ SDLC เปลี่ยนอย่างไร

บทบาท Developer จึงสลับอยู่สองโหมด Conductor คือทำงานกับ AI แบบ real-time คอยดูและกำกับทีละจังหวะ เหมาะกับ logic ซับซ้อน งาน debug หรือ codebase ที่ยังไม่คุ้น

ส่วน Orchestrator คือกำหนดเป้าหมาย มอบหมายงานให้ agents ทำแบบ async แล้วกลับมาตรวจ เหมาะกับงานที่ขอบเขตชัด เช่น known bug, migration หรือ test generation

ทีมไม่ต้องเลือกโหมดเดียวตลอดครับ งานหนึ่งอาจเริ่มแบบ conductor ตอนออกแบบ แล้วเปลี่ยนเป็น orchestrator เมื่องานถูกแตกจนชัด ทักษะที่เพิ่มขึ้นคือ specification, decomposition, evaluation และ system design มากกว่าความสามารถในการพิมพ์ syntax เร็วที่สุด

ข้อดีและข้อเสียที่ควรมองให้ครบ

ข้อดีของแนวทางนี้

• แยกพื้นที่ทดลองออกจาก production ทำให้ทีมใช้ Vibe Coding ได้โดยไม่เอาความเสี่ยงแบบเดียวกันไปใช้ทุกระบบ
• วาง Context เป็นทรัพย์สินของทีม rule files, skills, tests และ evals ถูก review และพัฒนาซ้ำได้
• ลดงาน implement ที่ซ้ำ Agent รับงาน scaffold, migration, test generation และ pattern ที่มีคำตอบค่อนข้างชัด
• ทำ handoff ให้ตรวจย้อนหลังได้ intent, constraint, test result และ agent trace ไม่หายอยู่ใน chat เพียงอย่างเดียว
• มองต้นทุนครบกว่าเวลาเขียน code พิจารณา token, review, maintenance, security remediation และ Total Cost of Ownership

ข้อเสียและจุดเสี่ยง

• ลงทุนช่วงต้นน้ำสูง เพราะต้องทำ spec, test, eval, sandbox, hooks และ observability ก่อนจะได้ความสม่ำเสมอ
• Review อาจกลายเป็นคอขวดใหม่ เพราะAgent สร้าง PR ได้หลายชุดพร้อมกัน แต่คนยังมีเวลาอ่านเท่าเดิม
• เสี่ยงสร้างพิธีกรรมชุดใหม่ ถ้าทุกงานต้องแบกเอกสารและมี gate ตรวจนั่นนี่เหมือนกันหมด งานเล็กจะทำงานช้าลงเท่ากับงานใหญ่ โดยที่คุณภาพไม่ต่างจากเดิม
• Harness ต้องมีเจ้าของ เพราะต้องกำหนด Prompt, skill และ rule file และต้องสามารถปรับปรุงได้เรื่อยๆ เหมือน code
• ตัวเลข productivity อาจไม่เกิดกับทีมตรงๆ เพราะประโยชน์ขึ้นกับคุณภาพ codebase, test coverage, domain และวินัยเดิมของทีมที่จะนำไปใช้ต่อ

หากมองในมุมเศรษฐศาสตร์ เอกสารนี้มองการ Vibe Coding ว่ามี CapEx ต่ำ เริ่มเร็ว แต่มีโอกาสแบก OpEx สูงจาก prompt loop, token burn, maintenance และการแก้ security ภายหลัง ส่วน Agentic Engineering ลงทุนช่วงต้นน้ำมากกว่า แต่พยายามลดต้นทุนส่วนเพิ่มด้วย context ที่ดี, reusable skills, automated verification และ model routing

เทียบกับ SDLC อื่นที่ผมติดตามอยู่

ใน Second Brain ของผมมีกรอบ AI SDLC หลายแบบ พอวางข้างกันแล้วพบว่าไม่ได้แข่งกันเป็นผู้ชนะเพียงรายเดียว แต่ละแนวทางกำลังตอบคำถามคนละระดับครับ

ถ้าให้ผมจัดตำแหน่ง Google whitepaper ชิ้นนี้ มันเป็นแผนที่กลางครับ มันช่วยตั้งชื่อสิ่งที่กำลังเปลี่ยน ส่วน Spec-Driven Development ลงลึกเรื่อง contract, Anthropic ลงลึก artifact chain กับ control architecture, AWS ลงลึก collaboration loop และ McKinsey ขยายไปถึง operating model ขององค์กร

Scrum กับ Kanban ก็ไม่ได้หมดประโยชน์ เราอาจยังใช้ Sprint เพื่อกำหนด cadence หรือใช้ WIP limit เพื่อกัน agent สร้างงานเกินกำลัง review เพียงแต่ board และ ceremony ต้องรับรู้ว่า AI กลายเป็น participant ใน flow แล้ว ไม่ใช่แค่เครื่องมือ autocomplete

SDLC ใหม่ไม่ได้ลบหลักวิศวกรรมเดิม มันทำให้ spec, test, review และ governance สำคัญขึ้น เพราะความผิดพลาดถูกขยายเป็น code ได้เร็วกว่าเดิม

ถ้าจะเริ่มใช้กับทีม ควรเริ่มตรงไหน

ผมไม่แนะนำให้เริ่มด้วยการประกาศว่าเราจะ automate ทั้ง SDLC ตั้งแต่วันจันทร์ครับ แบบนั้นน่าจะได้ slide ก่อน ได้ของจริงเมื่อไรค่อยว่ากันอีกที

1. เลือกงานซ้ำที่ขอบเขตชัดหนึ่งอย่าง เช่น test generation, known bug หรือ migration เล็ก
2. เขียน `AGENTS.md` หรือไฟล์กฎให้สั้น ระบุ stack, commands, conventions และสิ่งที่ห้ามทำ
3. กำหนด acceptance criteria กับ tests ก่อนให้ agent implement
4. แยก policy ที่เป็นคำแนะนำออกจากกฎที่ต้องบังคับด้วย hooks, CI หรือ permissions
5. ให้ agent ทำงานใน sandbox หรือ branch แยก แล้วเก็บ trace กับผล test
6. ให้คน review จุดเสี่ยง โดยเฉพาะ business logic, dependency, error handling และ security
7. เก็บ failure ที่เกิดจริงกลับมาเป็น test, eval หรือ rule เพื่อไม่ให้ระบบพลาดแบบเดิมซ้ำ

เมื่อ loop เล็กนี้นิ่งแล้วค่อยขยาย autonomy จาก conductor ไปสู่ orchestrator และค่อยเพิ่มงาน parallel สิ่งที่ต้องวัดไม่ใช่จำนวนบรรทัดที่ AI เขียน แต่ควรดู lead time, rework, escaped defects, change failure rate, review time และต้นทุนรวมด้วย

บทสรุป

หลังอ่าน The New SDLC with Vibe Coding แล้ว ผมคิดว่าจุดหลักของมันไม่ใช่การเสนอ process ใหม่แบบสำเร็จรูป แต่เป็นการทำความเข้าใจว่า เรากำลังทำ Vibe Coding เพื่อทดลอง หรือกำลังทำ Agentic Engineering เพื่อส่งระบบที่คนอื่นต้องพึ่งพา

เส้นแบ่งนี้ช่วยให้เราไม่ต้องเถียงว่า Vibe Coding ดีหรือแย่ เพราะคำตอบขึ้นกับการยอมรับความหลวมได้หรือไม่ งาน production ที่แตะเงิน ข้อมูลลูกค้า หรือระบบสำคัญต้องมี spec, tests, evals, guardrails, observability และคนที่ยอมรับความเสี่ยงอย่างชัดเจน

สิ่งที่เปลี่ยนมากที่สุดจึงไม่ใช่แค่เครื่องมือ แต่เป็นงานของ Developer และหัวหน้าทีมครับ เราจะใช้เวลาน้อยลงกับการพิมพ์ implementation ซ้ำๆ แล้วใช้เวลามากขึ้นกับการกำหนด intent, จัด context, ออกแบบระบบตรวจ และตัดสินว่า output แบบไหนดีพอจะไปต่อ

Generation เริ่มกลายเป็นของที่หาได้ง่ายขึ้น แต่ Verification, Judgment และ Direction กำลังกลายเป็นฝีมือหลักของคนทำ software และผมคิดว่านี่คือประเด็นที่น่าจำที่สุดจาก whitepaper ชิ้นนี้ครับ

ผู้อ่านได้อะไรจากบทความนี้

• เห็นเส้นแบ่งชัดขึ้น ว่างานใดใช้ Vibe Coding ได้ และงานใดต้องใช้ Agentic Engineering
• เข้าใจคอขวดใหม่ เมื่อ implementation เร็วกว่า requirement, architecture และ review
• รู้ส่วนประกอบของ Context และ Harness ที่ทำให้ coding agent ทำงานได้สม่ำเสมอขึ้น
• เห็นการเปลี่ยนของแต่ละ SDLC phase พร้อมจุดที่มนุษย์ยังต้องตัดสินใจ
• เทียบกรอบจาก Second Brain ได้ ทั้ง Google, AWS, Anthropic, Spec-Driven Development, McKinsey, Scrum และ Kanban
• มีแนวทางทดลองแบบเสี่ยงต่ำ โดยเริ่มจากงานเล็ก Verification ก่อน Autonomy และเก็บ failure กลับมาปรับระบบ

แหล่งอ้างอิง

• The New SDLC with Vibe Coding โดย Addy Osmani, Shubham Saboo และ Sokratis Kartakis
• The New Software Lifecycle โดย Addy Osmani
• AI-Driven Development Life Cycle จาก AWS
• The AI-Native SDLC playbook จาก Anthropic
• Rewiring software delivery for the agentic era จาก McKinsey & Company
• Spec-Driven Development ในยุค AI บทความที่ผมเขียนไว้ก่อนหน้า
• AI-Native SDLC มนุษย์อยู่ตรงจุดไหน และใช้ส่งต่องานกันอย่างไร บทความเปรียบเทียบ playbook ของ Anthropic
• AI เขียนโค้ดเร็วแล้ว แต่ทำไมงานยังช้าอยู่ มุมมองเรื่องคอขวดของ requirement และ workflow

ตัวที่ผมลองชื่อว่า Jev เป็นโมเดลของ TypeSafe AI ที่รับข้อมูลเข้าไป แล้วตอบกลับมาเป็นค่าที่มีชนิดชัดเจน เช่น เลือกหนึ่งตัวเลือก (Choice) ให้คะแนน (Score) หรือคืนความน่าจะเป็นของคำตอบใช่หรือไม่ใช่ (Noul) ผมเลยเอามันทดลองกับโจทย์ใกล้ตัวมากๆ คือการคัด Lead ปลอมที่ได้มาจากการลงทะเบียน โดยใช้ข้อมูลจริง 788 ราย ที่ทีมผมเคยพิจารณาตรวจคำตอบไว้ก่อนหน้านั้นแล้ว

ผลออกมาค่อนข้างน่าสนใจพอสมควร เลยแชร์ไว้เผื่อเป็นประโยชน์ครับ

หมายเหตุ: เอเจ้นชมพูช่วยถอดความและเรียบเรียงบทความนี้จากบันทึก โค้ด และผลการทดลองจริงของฟิวส์

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

สรุปไฮไลต์สั้นๆ

• Jev คืนค่าแบบ typed output โค้ดใช้ผลลัพธ์ต่อได้โดยไม่ต้องแกะข้อความหรือหวังว่า JSON จะไม่พัง
• ทดสอบกับลีดจริง 788 ราย ครอบคลุมข้อมูล 38 สัปดาห์ และผมมีเฉยๆ ของมนุษย์ครบทุกแถว เพื่อไว้ Cross Check แล้ว
• ระบบตัดสินเองได้ 66.4% บนชุดทดสอบชุดแรก (312 ราย) โดยกลุ่มที่ระบบตัดเป็น spam เองไม่มีลีดจริงปะปน 0 จาก 28 ราย
• Probability calibration ทำได้ดีขึ้น ค่าที่ใช้วัดความแม่นยำของความน่าจะเป็น (ECE) อยู่ที่ 0.065 จึงอยู่ในระดับที่ใช้ตั้ง threshold กับข้อมูลชุดนี้ได้
• ไม่แนะนำให้ AI ทำแทน deterministic logic เรื่องรูปแบบอีเมล ตัวเลขในชื่อ หรือประวัติในฐานข้อมูล เราเขียนโค้ดและเช็คฐานข้อมูลเองได้ ถูกกว่า

Jev คืออะไร และต่างจาก LLM ที่เราใช้กันอย่างไร

Jev คือโมเดลตัวแรกที่ TypeSafe AI พัฒนาขึ้นมา เรียกว่า System One model ชื่อนี้ยืมแนวคิด System 1 และ System 2 ที่ Daniel Kahneman ทำให้คนรู้จักผ่านหนังสือ Thinking, Fast and Slow

System 1 คือการตัดสินใจเร็วๆ แบบที่สมองทำอัตโนมัติ

ส่วน System 2 คือการคิดใคร่ครวญทีละขั้น

Jev ถูกออกแบบมาสำหรับการตัดสินใจแบบแรก คือถามเรื่องแคบๆ ให้ชัด แล้วคืนคำตอบที่ software ใช้ต่อได้ทันที

ซอฟต์แวร์ไม่ได้อยากได้ข้อความยาวๆ ซอฟต์แวร์อยากได้คำตอบที่เอาไป branch, sort, threshold หรือ route ต่อได้เลย

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

Jev ไม่เขียนคำอธิบายแบบนั้นครับ มันรับ state แล้วคืน typed answers กับ probability distribution ตามชนิดคำถามที่เรากำหนดไว้ เอกสารของ TypeSafe แบ่ง primitive ออกเป็น 3 แบบ

ตัวอย่างจาก Python SDK จะประมาณนี้

from typesafe_sdk import Choice, Noul, TypeSafeClient

with TypeSafeClient() as client:
    result = client.system_one(
        state={"message": "ผมโดนเรียกเก็บเงินซ้ำสองรอบ ช่วยแก้ด่วนเลยครับ"},
        questions={
            "department": Choice(
                instructions="ทีมไหนควรรับเรื่องนี้",
                criteria={
                    "billing": "เรื่องการเงิน",
                    "technical": "เรื่องระบบ",
                },
            ),
            "is_urgent": Noul(
                instructions="ข้อความนี้แสดงความเร่งด่วน"
            ),
        },
    )

print(result.choices["department"].choice)
print(result.choices["department"].confidence)
print(result.nouls["is_urgent"].noul)

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

Probability กับ confidence ไม่ใช่ค่าเดียวกัน

ตามเอกสารของ TypeSafe ค่า probability บอกการกระจายของคำตอบ ส่วน confidence เป็นสถิติที่สรุปว่าการกระจายนั้นมีคำตอบที่ควรจะใช่ ชัดแค่ไหน และมีเฉพาะ Choice กับ Score ส่วน Noul คืน probability โดยตรง ไม่มี confidence แยกอีกตัว

แนวคิดนี้เอาไปสร้างระบบแบบ confidence-gated routing ได้ เช่น confidence สูงให้ทำอัตโนมัติ confidence กลางส่งให้คนตรวจ และ confidence ต่ำไม่ให้ระบบเดา แต่ค่าตัดตรงไหนต้องวัดจากข้อมูลของงานเราเอง ไม่ควรหยิบเลขจากตัวอย่างใน docs มาใช้ตรงๆ

โจทย์ที่เอามาทดลองคือ Fake Lead

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

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

ข้อมูลที่ผมใช้ทดลองมาจากผลการตรวจจริง 38 สัปดาห์ รวม 788 ราย ทุกแถวมีคำตัดสินของคนกำกับไว้ทุกรายการก่อนแล้ว (แต่ผมไม่ส่งเฉลยให้ Jev นะ)

ตัวเลขแรกก็สะดุดแล้วครับ จาก 788 รายที่ระบบกฎดักไว้ คนตัดสินว่าไม่ใช่ spam ถึง 542 ราย หรือ 68.8% แปลว่างานตรวจส่วนใหญ่คือการยืนยันว่ากฎดักผิด

เหตุผลที่เจอบ่อยที่สุดคือ Numbers found in name จำนวน 305 ราย และเกือบทั้งหมดเป็นลีดจริง ตัวอย่างรูปแบบสมมติจะเป็นแบบนี้

38-605 สมหญิง ใจดี
สุภาพร 05
10 สมชาย รักดี

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

แกนที่กฎแยกไม่ออก คือคนจริงที่กรอกมั่ว กับคนที่ตั้งใจปลอมตัวตน

แยกสิ่งที่คำนวณได้ ออกจากสิ่งที่ต้องใช้ judgment

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

ข้อมูลลีด
  └─ โค้ดคำนวณข้อเท็จจริง 23 ตัว
       └─ ส่ง facts ให้ Jev ตัดสินส่วนที่ต้องใช้ judgment
            └─ โค้ดใช้ threshold และ confidence ตัดสินว่าจะทำเองหรือส่งให้คน

ผมให้ Jev ตอบ Choice 3 ทาง

• spam ตั้งใจปลอม
• low_quality_but_real เป็นคนจริง แต่กรอกข้อมูลเลอะ
• legitimate ลีดปกติ

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

ทำไมไม่เขียนกฎเพิ่มไปเรื่อยๆ

ผมลองแล้วครับ และมันสอนบทเรียนค่อนข้างแพงทางเวลา ฮาาา

การทดลองแรกคือเอาถังคำหยาบภาษาไทยและอังกฤษ 173 คำไปค้นในชื่อทั้ง 788 ราย พบ 11 ราย แต่ 10 รายในนั้น คนยืนยันว่าไม่ใช่ spam

ถังคำหยาบมีคำอย่าง อี กู ขี้ หน้า แม่ ซึ่งเป็นพยางค์ปกติในชื่อคนไทยได้ การ match substring ตรงๆ จึงเหมือนเอาตะแกรงช่องใหญ่ไปกรองทราย เม็ดที่ไม่เกี่ยวติดมาด้วยเต็มไปหมด

การทดลองที่สองคือเขียน detector หกรูปแบบ เช่น อักษรซ้ำ ชื่อเหมือนนามสกุล และ keyboard smash มันจับตัวอย่าง spam ที่ทีมให้มาได้ 16 จาก 17 ราย ฟังดูดีมาก

แต่พอใช้กับข้อมูลจริง มันไปโดนคนที่ไม่ใช่ spam 91 จาก 542 ราย หรือ 16.8% ตัวอย่างสมมติคือนามสกุลแบบ Chaichanachai ที่โดนเพราะพยางค์ cha ซ้ำสี่ครั้ง

Signal เป็นหลักฐาน ไม่ใช่คำตัดสิน หน้าที่ของมันคือบอกว่าเราเห็นอะไร แล้วให้ระบบชั่งน้ำหนักร่วมกับบริบทอื่น

ผลทดลองบนข้อมูลที่ไม่เคยใช้เลือก threshold

ผมแบ่งข้อมูลตามเวลา โดยใช้สัปดาห์ 1 ถึง 26 จำนวน 476 รายสำหรับเลือก threshold, แล้ววัดผลจริงบนสัปดาห์ 27 ถึง 38 อีก 312 รายที่ไม่เคยถูกใช้เลือกอะไรเลย

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

เลขที่สำคัญที่สุดสำหรับผมคือ 0 จาก 28 ราย เพราะต้นทุนของความผิดสองแบบไม่เท่ากัน การตัดลูกค้าจริงทิ้งคือเสียโอกาสขายไปเลย ส่วนการปล่อย spam ผ่านคือทีมขายเสียเวลาโทร

แต่ต้องอ่านให้ครบครับ 0 จาก 28 ไม่ได้แปลว่าอัตราผิดจริงคือศูนย์ เพราะขอบบนของช่วงเชื่อมั่นยังอยู่ที่ 12.1% จากฐานข้อมูลแค่ 28 ราย อาจจะยังเล็กเกินกว่าจะสรุปว่า Jev มี error rate ต่ำกว่า 1% ซึ่งคงต้องหาข้อมูลมาเพิ่มเติมทดสอบใหม่

Probability calibration รอบนี้ดีขึ้นจนใช้ตั้งเกณฑ์ได้

ค่า Expected Calibration Error (ECE) ซึ่งใช้วัดว่าความน่าจะเป็นที่โมเดลรายงานตรงกับอัตราที่เกิดจริงแค่ไหน ออกมาที่ 0.065 ถือว่าดีสำหรับข้อมูลชุดนี้

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

ถึงตัวเลขรอบนี้จะดีขึ้น หลักเดิมยังเหมือนเดิมครับ ต่อให้ผู้ผลิตบอกว่าโมเดลถูกฝึกเรื่อง calibration มา เราก็ต้องวัดกับ domain, ภาษา และข้อมูลของตัวเองก่อนตั้งเกณฑ์ใช้งานจริง

Jev ทำอะไรได้ และอะไรควรปล่อยให้ฐานข้อมูลทำ

พอผมให้รันเหมือนระบบจริงทั้ง 788 ราย โดยจะมีเงื่อนไขตรวจสอบตามกฎ และส่งผลลัพธ์การตรวจพร้อมชื่อ เบอร์โทร อีเมล วันที่กรอกฟอร์ม ให้ Jev พิจารณาต่อแทนคน ผลลัพธ์ที่ได้น่าสนใจมาก คือ

known_spam_record ร่วงเป็น 0% และนี่ไม่ใช่ความผิดของโมเดล เราไม่สามารถรู้ว่าเบอร์หนึ่งเคยเป็น spam ด้วยการมองตัวเลข ต้อง query ฐานข้อมูล คนตรวจมีฐานนั้น แต่ Jev ไม่มี

การเช็คประวัติจึงเป็นงานของ database กับ deterministic rule เพราะเร็ว แม่น และ audit ได้ ส่วนการตัดสินว่าข้อมูลชุดนี้ดูเป็นคนจริงที่ติดต่อได้หรือเป็นการปลอมตัวตน เป็นงานที่ Jev ช่วยได้ดีกว่า

นี่อธิบายด้วยว่าทำไม recall ฝั่ง spam อยู่เพียงราว 48% เพราะ 85% ของสิ่งที่คนเรียกว่า spam ในข้อมูลชุดนี้เป็นเคสที่อาศัยประวัติจากฐานข้อมูลล้วนๆ

จุดที่ผมคิดว่าคุ้มที่สุดคือใช้ Jev ช่วยจัดการ 305 รายที่ rule ดักเพราะชื่อมีตัวเลข ซึ่งปัจจุบันคนต้องคอยตรวจและยืนยันทีละราย

ค่าใช้จ่ายถูกจนไม่ใช่ปัจจัยตัดสินใจ

ต้นทุนทั้งปีถูกกว่ากาแฟหนึ่งแก้วอีกครับ ทำให้ผมปรับคำถาม ปรับ threshold แล้วรันข้อมูลทั้งชุดใหม่ได้หลายรอบโดยไม่ต้องกังวลเรื่องค่า API

แต่ราคาถูกไม่ได้แปลว่าควรใช้ทุกที่ ถ้าโค้ดหรือ SQL ตอบได้ตรงๆ ต่อให้ AI ฟรีก็ยังเป็นทางเลือกที่ซับซ้อนกว่า

ถ้าจะเอา Jev ไปใช้จริง ผมจะเริ่มแบบนี้

1. เลือก judgment ที่แคบและชัด เช่น intent, routing, risk tier หรือข้อมูลดูเป็นคนจริงหรือไม่ ไม่โยนโจทย์กว้างให้วิเคราะห์ทุกอย่าง
2. แยก deterministic facts ออกมาก่อน ใช้ code, regex, database และ validation สำหรับเรื่องที่ตอบแน่นอนได้
3. มนุษย์ควรมายืนยันความน่าเชื่อถือ และเก็บเหตุผลไว้ด้วย เพราะ accuracy อย่างเดียวบอกไม่พอว่าโมเดลใช้เหตุผลถูกหรือไม่
4. แบ่ง train และ evaluation ตามเวลา เลือก threshold จากอดีตแล้ววัดกับอนาคตให้เหมือน production
5. ตรวจ lineage ของทุก feature กัน label leakage ที่อ้อมผ่าน lookup, cache หรือ aggregate
6. เขียนกติกาภายในทีมออกมาให้ชัด สิ่งที่คนทำงานรู้กันเองอาจไม่มีอยู่ในนิยามที่ส่งให้โมเดล
7. วัด calibration และ distribution อย่าเชื่อ probability หรือ metric รวมโดยไม่เปิดดูพฤติกรรมรายกลุ่ม
8. ออกแบบ human review เป็นส่วนหนึ่งของระบบ เคส confidence ต่ำหรือผลกระทบสูงควรส่งให้คนตัดสิน

บทสรุป

หลังลองกับข้อมูลจริง ผมมองว่า Jev น่าสนใจตรงที่มันอยู่กึ่งกลางระหว่าง rule engine กับ LLM แบบสร้างข้อความ มันรับภาษาธรรมชาติและใช้ judgment ได้ แต่ผลลัพธ์ยังอยู่ในรูปที่โค้ดควบคุมต่อได้

สิ่งที่ผมชอบที่สุดไม่ใช่ accuracy สูงสุด แต่คือความสามารถในการออกแบบระบบที่ยอมรับว่าไม่มั่นใจ แล้วส่งเคสยากกลับให้คนตรวจ ตรงนี้เหมาะกับงานที่ความผิดแต่ละฝั่งมีต้นทุนไม่เท่ากันมากๆ

ส่วนที่ต้องระวังคือ AI ไม่ได้เติมข้อมูลที่ไม่มีให้เรา ถ้าคำตอบอยู่ในฐาน spam ก็ต้องเปิดฐานข้อมูล ถ้ากฎธรรมดาตรวจอีเมลได้ก็ใช้กฎธรรมดา ส่วน probability calibration แม้รอบนี้จะทำได้ดี ก็ยังต้องวัดใหม่เมื่อ domain, ภาษา หรือข้อมูลเปลี่ยน

ผลการทดลองรอบนี้ยังไม่ทำให้ผมเปิดระบบตัด lead อัตโนมัติเต็มรูปแบบทันที ฐานตัวอย่างฝั่งที่ตัดเป็น spam เองยังน้อย และ recall ยังมีข้อจำกัด แต่ผมเห็นจุดที่เอาไปลดงาน manual review ได้ชัด คือกลุ่มคนจริงที่กรอกข้อมูลเลอะเทอะ โดยเฉพาะชื่อที่มีตัวเลข (แต่ถ้าว่ากันตามจริง ช่วยได้น้อยมากๆ ผมอาจจะแค่ปรับ rule เช็คให้ดีขึ้น)

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

การทดลองทั้งหมดเขียนด้วย Python มี test 137 ตัว และตัวเลขในบทความมาจากการรันกับข้อมูลลีดจริง 788 รายจาก 38 สัปดาห์ ชื่อบุคคลทุกชื่อที่ใช้เป็นตัวอย่างเป็นข้อมูลสมมติ

ผู้อ่านได้อะไรจากบทความนี้

• รู้จัก Jev และ System One model ว่าเหมาะกับ typed decisions มากกว่างานสร้างข้อความ
• เห็นตัวอย่าง evaluation บนข้อมูลจริง ตั้งแต่ temporal split, confidence interval, precision, recall ไปจนถึง calibration
• แยกบทบาท AI กับ deterministic system ได้ชัดขึ้น เพื่อไม่เอาโมเดลไปทำงานที่ code หรือ database ทำได้ดีกว่า
• รู้จัก data leakage แบบอ้อมๆ ซึ่งซ่อนอยู่ใน feature, lookup และ cache ได้
• อ่าน metric อย่างระวัง โดยดู distribution, class behavior และต้นทุนของความผิดแต่ละแบบร่วมกัน
• ออกแบบ human review ได้เป็นระบบ แทนการบังคับให้ AI ตอบทุกเคส

แหล่งข้อมูล

• TypeSafe AI Documentation
• System One model
• Choice, Score และ Noul primitives
• Probability และ confidence

ผมเลยลองรื้อของเดินป่าที่มีอยู่ แล้วจัดใหม่ในมุมของ emergency kit สำหรับบ้านและคอนโด ปรากฏว่าของที่นำมาใช้ต่อได้มีเยอะกว่าที่คิด ตั้งแต่เสื้อกันฝน ไฟฉายคาดหัว เสื้อกันหนาว dry bag ถุงกันน้ำใส่มือถือ ถุงนอน ไปจนถึงอาหารสำเร็จรูปที่เหลือจากทริป

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

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูเรียบเรียงจากประสบการณ์ใช้อุปกรณ์เดินป่า ประกอบกับคำแนะนำจาก Ready.gov, CDC, American Red Cross และ REI

สรุปไฮไลต์สั้นๆ

• แยกชุดอยู่บ้านกับชุดอพยพ เพราะของสำหรับประคองชีวิตหลายวันไม่ควรยัดรวมในกระเป๋าที่ต้องแบกลงบันได
• ไฟฉายคาดหัว เสื้อกันฝน และ dry bag เป็นสามชิ้นที่ใช้ได้ทันทีเมื่อไฟดับหรือมีน้ำเข้าพื้นที่
• เสื้อแห้งและชั้นกันหนาวยังสำคัญในเมือง เพราะเสื้อผ้าเปียก ลม และเครื่องปรับอากาศในศูนย์พักพิงทำให้เสียความร้อนได้
• อาหารเดินป่าใช้หมุนเวียนเป็นเสบียงฉุกเฉินได้ เลือกของกินได้ทันทีหรือใช้น้ำน้อย และตรวจวันหมดอายุเป็นรอบ
• เตาแก๊สห้ามใช้ในห้อง เต็นท์ โถง ทางเดิน หรือพื้นที่ปิด เพราะเสี่ยงคาร์บอนมอนอกไซด์ ไฟไหม้ และลวก
• น้ำท่วมไม่ใช่ลำธารเดินป่า เครื่องกรองพกพาไม่ได้ทำให้น้ำที่ปนเชื้อ ไวรัส น้ำมัน หรือสารเคมีปลอดภัยเสมอไป

เริ่มจากโจทย์ก่อน ไม่ใช่เริ่มจากซื้อของ

คำว่าเตรียมรับภัยพิบัติฟังดูใหญ่จนบางทีไม่รู้จะเริ่มตรงไหน ผมชอบแบ่งเป็นสองสถานการณ์ง่ายๆ ครับ

Ready.gov หน่วยงานด้านการเตรียมพร้อมภัยพิบัติของสหรัฐฯ แนะนำให้มีอาหาร น้ำ และของจำเป็นสำหรับหลายวัน ส่วน American Red Cross แยกภาพชัดขึ้นว่า ชุดอพยพควรพอประมาณ 3 วัน ขณะที่เสบียงอยู่บ้านควรวางแผนได้นานกว่านั้นตามสมาชิกและข้อจำกัดของพื้นที่[1][7]

กระเป๋าฉุกเฉินที่ดีไม่ใช่ใบที่ใส่ของได้มากที่สุด แต่เป็นใบที่เราหยิบแล้วออกจากบ้านได้จริง

คนอยู่คอนโดควรลองยกกระเป๋าแล้วเดินลงบันไดจริงสักรอบครับ จะรู้ทันทีว่าอะไรจำเป็น อะไรหนักเกิน และรองเท้าที่เตรียมไว้นั้นเดินหลายชั้นไหวไหม ไม่ต้องรอวันไฟดับค่อยทดสอบ ฮาาา

อุปกรณ์เดินป่าชิ้นไหนย้ายมาใช้ในเมืองได้เลย

REI แนะนำว่าเป้เดินป่าส่วนใหญ่ไม่ได้กันน้ำสนิทเพราะตะเข็บ ช่องเปิด และซิปยังเป็นทางให้น้ำเข้า จึงควรใช้ pack liner, dry sack หรือถุงกันน้ำแยกของสำคัญ เสื้อผ้าที่เปียกง่ายควรเลี่ยงผ้าฝ้าย และเก็บเสื้อแห้งไว้เป็นชุดสำรอง[8][9]

Rain cover ช่วยได้ แต่เอกสาร ยา โทรศัพท์ และเสื้อแห้งควรมีชั้นกันน้ำของตัวเองอีกชั้น

อาหารเดินป่าที่เหลือ เอามาหมุนเป็นเสบียงฉุกเฉินได้

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

อาหาร freeze-dried น้ำหนักเบาและเก็บสะดวก แต่ต้องมีน้ำสะอาดและมักต้องใช้น้ำร้อน ถ้าน้ำเป็นทรัพยากรจำกัด อาหารที่กินได้ทันทีอาจเหมาะกว่า อย่าลืมที่เปิดกระป๋องแบบมือด้วย เพราะไฟดับแล้วที่เปิดไฟฟ้าก็กลายเป็นของตกแต่งได้ครับ

CDC แนะนำว่าอาหารที่สัมผัสน้ำท่วม หรือบรรจุภัณฑ์ไม่กันน้ำ ควรทิ้ง ส่วนอาหารสดในตู้เย็นมีเวลาไม่มากเมื่อไฟดับ ตู้เย็นที่ปิดไว้รักษาความเย็นได้ประมาณ 4 ชั่วโมง ขณะที่ช่องแช่แข็งเต็มตู้ได้ประมาณ 48 ชั่วโมง[5]

เรื่องน้ำ เครื่องกรองเดินป่าไม่ใช่คำตอบทั้งหมด

ผมมีเครื่องกรองน้ำพกพาสำหรับเดินป่า แต่จะไม่หยิบมันไปดูดน้ำท่วมแล้วคิดว่าจบครับ น้ำท่วมในเมืองอาจมีสิ่งปฏิกูล เศษวัสดุ เชื้อโรค น้ำมัน และสารเคมีปนอยู่ CDC ระบุว่าเครื่องกรองพกพาไม่ได้กำจัดเชื้อทุกชนิด และน้ำที่มีเชื้อเพลิงหรือสารพิษไม่สามารถทำให้ปลอดภัยด้วยการต้ม ฆ่าเชื้อ หรือกรองทั่วไป[10][11]

น้ำดื่มบรรจุไว้ล่วงหน้าคือแผนหลัก เครื่องกรองเป็นเครื่องมือเสริม และน้ำท่วมไม่ใช่แหล่งน้ำเดินป่า

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

เตาแก๊สเดินป่าใช้ได้ แต่ไม่ใช่ในห้อง

ข้อนี้อยากเน้นมากที่สุด เตาแก๊ส camping stove เตาถ่าน และ generator ห้ามใช้ในห้อง เต็นท์ ทางเดิน โถง ลานจอดรถ หรือพื้นที่ปิด แม้เปิดประตูหน้าต่างอยู่ก็ตาม CDC ระบุว่าคาร์บอนมอนอกไซด์ไม่มีสีและไม่มีกลิ่น สามารถทำให้ป่วย หมดสติ หรือเสียชีวิตได้ และระบุชัดว่าไม่ควรใช้เตาแก๊สพกพาในอาคาร[4]

Ready.gov แนะนำให้ generator, camp stove และเตาถ่านใช้นอกอาคาร โดยอยู่ห่างจากหน้าต่างอย่างน้อย 20 ฟุต หรือประมาณ 6 เมตร[3] สำหรับคอนโดทั่วไป ระเบียงมักไม่สามารถเว้นระยะนี้ได้และยังมีข้อบังคับอาคาร จึงควรวางแผนด้วยอาหารพร้อมกินเป็นหลัก ถ้ามีพื้นที่ภายนอกที่ปลอดภัยจริง ให้ทำตามคู่มือผู้ผลิต กฎอาคาร และคำสั่งเจ้าหน้าที่ทุกครั้ง

ถ้าไม่มีพื้นที่กลางแจ้งที่ปลอดภัย เตาเดินป่าไม่ใช่อุปกรณ์ทำอาหารฉุกเฉินของคอนโด

จัดกระเป๋าแบบสามชั้น หยิบง่ายกว่าเททุกอย่างรวมกัน

ชั้นติดตัว

• โทรศัพท์ในซองกันน้ำ
• ไฟฉายคาดหัว
• นกหวีด
• ยาที่ต้องใช้ทันที
• บัตรประชาชน เงินสด และรายชื่อผู้ติดต่อ

ชั้น grab-and-go

• เสื้อกันฝน เสื้อแห้ง ถุงเท้า และชั้นกันหนาว
• น้ำกับอาหารพร้อมกิน
• ชุดปฐมพยาบาลและยาประจำตัว
• Power bank สายชาร์จ วิทยุ และแบตเตอรี่
• สำเนาเอกสารใน dry bag
• ของจำเป็นสำหรับเด็ก ผู้สูงอายุ และสัตว์เลี้ยง

ชั้นอยู่บ้าน

• น้ำและอาหารเพิ่มสำหรับหลายวัน
• อุปกรณ์สุขอนามัย ถุงขยะ และของทำความสะอาด
• ผ้าห่ม ถุงนอน และชุดแห้งสำรอง
• ถังดับเพลิง เครื่องตรวจควัน และเครื่องตรวจ CO หากบ้านมีอุปกรณ์เผาไหม้
• เครื่องมือพื้นฐานและที่เปิดกระป๋อง

เก็บของสำคัญบนชั้นสูง ไม่วางตรงพื้น และให้ทุกคนในบ้านรู้ว่าอยู่ไหน Ready.gov ยังแนะนำให้เก็บเอกสารในภาชนะกันน้ำ มีสำเนาดิจิทัล และเตรียม power bank, ไฟฉาย, วิทยุ, ชุดปฐมพยาบาล รวมถึงของเฉพาะของสมาชิกในครอบครัว[1][2]

ของเดินป่าช่วยได้ แต่ไม่ควรทำให้เรากล้าลุยน้ำ

รองเท้าเดินป่า ไม้เท้า และเสื้อกันฝนทำให้เคลื่อนที่สะดวกขึ้น แต่ไม่ได้ทำให้น้ำท่วมปลอดภัย Ready.gov และ CDC แนะนำให้หลีกเลี่ยงการเดิน ว่ายน้ำ หรือขับรถผ่านน้ำท่วม เพราะน้ำอาจไหลแรง มีไฟฟ้า สารเคมี สิ่งปฏิกูล และเศษของมีคมอยู่ข้างใต้[2][11]

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

บทสรุป

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

ไฟฉายคาดหัวทำให้มือว่าง dry bag รักษายากับเอกสาร เสื้อกันฝนช่วยตอนต้องออกจากอาคาร เสื้อแห้งและถุงนอนช่วยให้พักได้ ส่วนอาหารทริปที่เหลือก็หมุนเป็นเสบียงได้แทนที่จะรอหมดอายุ

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

สุดท้ายผมว่าการเตรียมตัวที่ดีไม่ได้วัดจากจำนวน gadget แต่วัดจากสามอย่าง ของอยู่ถูกที่ ทุกคนรู้วิธีใช้ และเราลองแผนมาแล้วก่อนวันที่ต้องใช้จริง

ผู้อ่านได้อะไรจากบทความนี้

• สำรวจของเดิมได้เป็นระบบ รู้ว่าอุปกรณ์เดินป่าชิ้นใดนำมาใช้รับภัยพิบัติในเมืองได้
• จัดของตามสถานการณ์ แยกชุดอยู่บ้านกับชุดอพยพแทนการยัดทุกอย่างลงกระเป๋าเดียว
• ป้องกันน้ำกับความชื้น ด้วย dry bag, ซองกันน้ำ และชุดเสื้อผ้าแห้ง
• จัดการอาหารและน้ำอย่างปลอดภัยขึ้น โดยไม่พึ่งเครื่องกรองหรือเตาเพียงอย่างเดียว
• เลี่ยงอันตรายจากคาร์บอนมอนอกไซด์ ด้วยการไม่ใช้เตาแก๊สหรืออุปกรณ์เผาไหม้ในพื้นที่ปิด
• รู้ขอบเขตของอุปกรณ์ รองเท้าและเสื้อกันฝนช่วยเคลื่อนที่ แต่ไม่ได้ทำให้น้ำท่วมปลอดภัย

แหล่งข้อมูล

• [1] Ready.gov: Build A Kit
• [2] Ready.gov: Floods
• [3] Ready.gov: Power Outages
• [4] CDC: Carbon Monoxide Poisoning Basics
• [5] CDC: Keep Food Safe After a Disaster or Emergency
• [7] American Red Cross: Survival Kit Supplies
• [8] REI: Tips for Hiking in the Rain
• [9] REI: Tips for Backpacking in the Rain
• [10] CDC: How to Make Water Safe in an Emergency
• [11] CDC: Safety Guidelines for Floodwater

ศัพท์ภูเขาไม่ได้มีไว้ให้เราพูดดูโปรขึ้นครับ มันช่วยให้เราอ่าน route description เข้าใจ ดูแผนที่ได้เป็นภาพ และคุยกับไกด์หรือเพื่อนร่วมทางได้ตรงกันกว่าเดิม โดยเฉพาะวันที่อากาศเปลี่ยน เส้นทางไม่ชัด หรือพื้นใต้รองเท้าไม่น่าไว้ใจ คำสั้นๆ หนึ่งคำอาจบอกลักษณะภูมิประเทศให้เราเตรียมตัวได้เยอะมาก

ผมเลยหยิบ 9 คำจากคารูเซลของ @acethehimalaya มาแปลและเรียบเรียงใหม่ พร้อมเติมตัวอย่างสถานที่ให้เห็นภาพ ค่อยๆ อ่านไปทีละคำครับ รอบหน้าที่เห็นชื่ออย่าง Thorong La หรือ South Col เราจะไม่ได้เห็นเป็นแค่ชื่อเท่ๆ บนแผนที่อีกแล้ว

หมายเหตุ: บทความนี้เรียบเรียงจาก 9 Mountain Terms Every Trekker Should Know โดย @acethehimalaya โดยเอเจ้นชมพูช่วยแปลและเรียบเรียง

1. PASS หรือ LA คือช่องทางข้ามภูเขา

Pass คือช่องหรือแนวที่เดินทางข้ามเทือกเขาได้ เชื่อมจากด้านหนึ่งไปอีกด้านหนึ่ง หรือเชื่อมหุบเขาสองฝั่งเข้าหากัน ส่วนคำว่า La ในภาษาทิเบตหมายถึง pass นั่นเอง เพราะแบบนี้เราจึงเห็นชื่อสถานที่ในแถบหิมาลัยลงท้ายด้วย La อยู่บ่อยๆ

ตัวอย่างที่คุ้นหูคือ Thorong La จุดข้ามภูเขาบนเส้นทาง Annapurna Circuit ชื่อของมันไม่ได้ตั้งมาให้ลึกลับครับ คำว่า La ก็บอกหน้าที่ของภูมิประเทศไว้ตรงๆ แล้วว่าเป็นทางข้าม

เห็นคำว่า La ในชื่อเส้นทาง ให้ลองนึกถึงประตูที่เปิดผ่านแนวภูเขา ไม่ใช่ยอดเขาอีกลูกหนึ่ง

2. RIDGE คือสันแคบยาวที่เชื่อมยอดเขา

Ridge คือแนวสูงยาวและค่อนข้างแคบของภูเขา บางแนวเชื่อมยอดหนึ่งไปสู่อีกยอดหนึ่ง ถ้า pass เหมือนประตูที่ใช้ข้าม ridge ก็เหมือนสันหลังของภูเขาที่ลากยาวไปตามแนวสูง

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

3. TREE LINE คือเส้นที่ต้นไม้ใหญ่ไปต่อไม่ไหว

Tree line คือขอบเขตบนตามธรรมชาติที่ต้นไม้ยังเติบโตเป็นต้นได้ เหนือแนวนี้สภาพแวดล้อมอาจหนาว ลมแรง หรือฤดูเติบโตสั้นเกินไป เราจึงเริ่มเห็นไม้พุ่ม หญ้า หรือพื้นที่โล่งแทนป่าสูง

ตำแหน่งของ tree line ไม่ได้อยู่ที่ระดับความสูงเดียวกันทั่วโลกครับ มันเปลี่ยนตามภูมิอากาศ ละติจูด และทิศทางที่พื้นที่รับลมหรือแสง ตัวอย่างเช่นบริเวณ Trail Ridge Road ใน Rocky Mountain National Park มีช่วงที่ถนนผ่านขึ้นไปสู่เขต alpine เหนือแนวต้นไม้ แต่เราไม่ควรจำตัวเลขจากที่นี่ไปใช้ตัดสินภูเขาอีกซีกโลกแบบตรงๆ

Tree line ไม่ใช่เส้นที่ใครเอาปากกาไปขีดไว้บนเขา มันคือช่วงเปลี่ยนผ่านที่ธรรมชาติค่อยๆ บอกเราว่าเงื่อนไขข้างบนไม่เหมือนข้างล่างแล้ว

4. SNOW LINE คือขอบล่างของหิมะที่ยังคงอยู่

Snow line คือขอบเขตล่างของบริเวณที่หิมะคงอยู่ต่อเนื่องหรืออยู่ถาวรในช่วงเวลาที่เรากำลังพูดถึง ฟังคล้ายเส้นคงที่ แต่ของจริงขยับได้ตามฤดูกาล อุณหภูมิ ปริมาณหิมะ และสภาพภูมิอากาศระยะยาว

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

5. CAIRN คือกองหินบอกทางที่ไม่ควรต่อเติมเล่น

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

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

กองหินที่เราต่อเพิ่มเพราะเห็นว่าสวย อาจกลายเป็นลูกศรผิดทิศสำหรับคนที่เดินตามมาทีหลัง

6. MORAINE คือเศษหินและดินที่ธารน้ำแข็งพามา

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

แถว Khumbu Glacier และทางไป Everest Base Camp เราจะเห็นภูมิประเทศที่เกี่ยวข้องกับ moraine ชัดมาก พื้นดูเหมือนกองเศษหินธรรมดา แต่ข้างใต้หรือบริเวณใกล้กันอาจมีน้ำแข็งและพื้นไม่สม่ำเสมอ คำนี้เลยไม่ได้บอกแค่ที่มาทางธรณีวิทยา มันยังเตือนให้เรามองพื้นทางเดินละเอียดขึ้นด้วย

7. SCREE คือทางลาดหินร่วนที่ทุกก้าวมีสิทธิ์ไหล

Scree คือพื้นที่ลาดที่ปกคลุมด้วยเศษหินแตกหลวมๆ และหินก้อนเล็ก พื้นแบบนี้ไม่ค่อยเก็บเท้า วางลงไปแล้วหินอาจไหลหรือกลิ้งต่อ ทำให้การลงทางชันเหนื่อยกว่าที่เห็นในรูป

เส้นทางลงจาก Thorong La บางช่วง หรือพื้นที่ภูเขาไฟบน Tongariro เป็นตัวอย่างที่ช่วยให้นึกภาพ scree ออก วิธีรับมือไม่ใช่รีบวิ่งให้จบๆ ครับ ควรรักษาระยะจากคนข้างหน้า วางเท้าอย่างควบคุม และระวังหินที่เราเตะให้ไหลไปหาคนด้านล่าง ไม้เท้าช่วยเรื่องสมดุลได้ แต่ต้องใช้ให้เป็นด้วย ไม่งั้นจากผู้ช่วยจะกลายเป็นพร็อพถ่ายรูปเฉยๆ ฮาาา

บน scree ความเร็วไม่ได้ช่วยให้มั่นคงขึ้น จังหวะเท้าและระยะห่างต่างหากที่ช่วยลดปัญหา

8. BOULDER คือหินก้อนใหญ่ แต่ในภาษาคนเดินอาจไม่เป๊ะตามตำรา

Boulder คือก้อนหินขนาดใหญ่ที่แยกออกจากมวลหินเดิม ในทางธรณีวิทยามักจัดก้อนที่มีขนาดมากกว่า 25.6 เซนติเมตรไว้ในกลุ่มนี้ แต่เวลาเจอคำว่า boulder ในรีวิวเดินเขา คนเขียนอาจใช้แบบหลวมกว่า หมายถึงก้อนหินใหญ่ที่ต้องก้าวข้าม ปีน หรือใช้มือช่วยทรงตัว

Boulder Field บนเส้นทาง Longs Peak เป็นตัวอย่างชื่อที่บอกสภาพพื้นตรงตัว ถ้า route note ระบุว่าเป็น boulder field ก็เตรียมใจไว้เลยว่าความเร็วบนแผนที่อาจไม่ตรงกับความเร็วจริง เพราะแต่ละก้าวต้องเลือก ไม่ใช่เดินตามจังหวะยาวๆ เหมือนทางดินเรียบ

9. COL คือแอ่งต่ำบนสันเขาระหว่างยอดที่สูงกว่า

Col คือจุดต่ำคล้ายอานม้าบน ridge ซึ่งอยู่ระหว่างยอดหรือพื้นที่สูงกว่าสองด้าน มองจากไกลๆ จะเหมือนสันเขาเว้าลงแล้วสูงขึ้นอีกครั้ง คำนี้บอกลักษณะรูปร่างของภูมิประเทศเป็นหลัก

South Col ระหว่าง Everest และ Lhotse เป็นตัวอย่างที่ชื่อบอกตำแหน่งชัดเจน จุดที่เป็น col อาจทำหน้าที่เป็นทางเชื่อมได้ แต่ไม่ใช่ทุก col จะเป็น pass ที่ใช้งานได้จริง ความชัน น้ำแข็ง หน้าผา และสภาพอากาศอาจทำให้จุดต่ำบนสันเขานั้นผ่านยากหรือไม่เหมาะกับการเดินทางเลย

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

เช็กลิสต์สั้นๆ ก่อนเอาศัพท์พวกนี้ไปใช้บนเส้นทางจริง

• อ่าน route description ให้ครบ อย่าตัดสินความยากจากศัพท์คำเดียว
• เช็กพยากรณ์อากาศ สภาพหิมะ และประกาศปิดเส้นทางจากหน่วยงานท้องถิ่น
• ดาวน์โหลดแผนที่แบบ offline และพกพลังงานสำรองให้โทรศัพท์หรือ GPS
• ตามป้ายและ cairn ที่เป็นทางการ ไม่สร้างหรือย้ายกองหินเอง
• เผื่อเวลามากขึ้นเมื่อเส้นทางมี scree, moraine หรือ boulder field
• รักษาระยะห่างบนทางหินร่วน เพื่อไม่ให้หินที่หลุดจากเท้าไปโดนคนด้านล่าง
• ถ้าไม่แน่ใจเรื่อง pass, ridge หรือ col ที่อยู่ข้างหน้า ถามไกด์หรือเจ้าหน้าที่ในพื้นที่ก่อนเดินต่อ
• พร้อมกลับตัวเมื่อสภาพจริงไม่ตรงกับแผน เพราะคำศัพท์ช่วยให้เข้าใจภูเขา แต่ไม่ได้ทำให้ความเสี่ยงหายไป

สุดท้าย ศัพท์ที่ดีควรทำให้เราเดินอย่างถ่อมตัวขึ้น

พอรู้ 9 คำนี้ ผมรู้สึกว่าการอ่านเรื่องภูเขาสนุกขึ้นครับ ชื่อที่เคยดูเหมือนศัพท์เฉพาะเริ่มกลายเป็นภาพ เราเห็นแนว ridge ในแผนที่ เข้าใจว่าทำไม pass จึงเชื่อมหุบเขา และรู้ว่าพื้นที่ดูเหมือนกองหินอาจเป็น moraine หรือ scree ที่ต้องใช้จังหวะเดินต่างกัน

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

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

ภูเขาไม่ได้สนว่าเราจำศัพท์ได้กี่คำครับ แต่การเข้าใจคำเหล่านี้ อาจทำให้เราเคารพสิ่งที่อยู่ตรงหน้ามากกว่าเดิมนิดหนึ่ง เท่านี้ก็คุ้มแล้ว

แหล่งข้อมูล

• @acethehimalaya: 9 Mountain Terms Every Trekker Should Know
• U.S. National Park Service: Rock Cairns
• Encyclopaedia Britannica: Moraine
• Encyclopaedia Britannica: Timberline
• Encyclopaedia Britannica: Snow line
• National Geographic Education: Pass

พอดีผมไปอ่านบทความของ Anthropic เรื่อง The AI-Native SDLC playbook ของ Louis Claxton ผู้เขียนจาก Anthropic แล้วรู้สึกว่า นี่คือภาคต่อของคำถามนั้นพอดีครับ นอกจากเขาคิดว่า code ไม่ใช่คอขวดแล้ว แต่เขาแบทั้งวงจรว่า ถ้าการสร้างซอร์ฟแวร์ได้เร็วขึ้นจากสัปดาห์-เดือน เหลือเพียงไม่กี่ชั่วโมง การทำ Plan, Design, Test, Deploy และ Maintain จะต้องเปลี่ยนตามอย่างไร

คำตอบของ Louis Claxton คือ AI-Native SDLC ที่เอา AI เข้าไปอยู่ทุกช่วง ใช้เอกสารที่ทั้งคนและ agent อ่านได้ ส่งงานต่อกันได้ วาง automation ในจุดที่ตรวจแบบตรงไปตรงมาได้ แล้วเหลือมนุษย์ไว้ตรงจุดที่ต้องใช้ judgment และรับผิดชอบต่อความเสี่ยง อ่านแล้วตรงกับที่ผมสงสัยในวิธีการที่ผมทำอยู่พอดิบพอดี ซึ่งผมชอบนะ แต่ก็มีหลายจุดที่ในบทความบอกว่าถ้าเอาไปใช้แบบยกชุดโดยไม่ดูบริบท ทีมอาจได้ระบบเอกสารใหม่ที่หนักพอๆ กับของเดิมก็ได้ 5555

หมายเหตุ: บทความนี้เอเจ้นชมพูช่วยแปลและเรียบเรียงจากบทความ The AI-Native SDLC playbook ของ Louis Claxton และใช้มุมมองกับประสบการณ์ของฟิวส์ และค้นข้อมูลเสริมจาก Second Brain ของฟิวส์ เพื่อปรับเรื่องให้ผู้อ่านเห็นภาพชัดเจนยิ่งขึ้น

สรุปสั้นๆ สำหรับคนขี้เกียจอ่าน

• Code ไม่ใช่คอขวดหลักแล้ว แต่คิวงานย้ายไปกองที่ planning, review, security และ deployment
• Artifact chain กลายเป็นทางส่งงาน ผ่าน intent.md, spec.md, plan.md, tests, PR และ incident record
• Guideline กับ control ต้องแยกกัน skills ใช้บอกแนวทาง ส่วน hooks, tests, sandbox และ branch protection ใช้บังคับสิ่งที่ห้ามพลาด
• คนต้อง reskill และรับผิดชอบกว้างขึ้น จากการทำงานเฉพาะช่วง ไปสู่การเข้าใจ architecture, spec, plan, task, implementation และ test ตลอดสาย
• แต่ละสำนักมองคนละมุม Anthropic เน้น control architecture, AWS เน้น AI-first collaboration, McKinsey เน้น operating model, Snyk เน้น security และ Addy Osmani เน้น loop, ส่วนฟิวส์ อะไรที่เขาว่าดี ฟิวส์ก็ว่าดี ฮ่าๆ

วันที่ Build เร็วขึ้น แต่คิวงานรอบข้างยาวกว่าเดิม

SDLC แบบเดิมถูกออกแบบในยุคที่การเขียน code ใช้เวลานาน และมีขั้นตอนสูง เลยจำเป็นต้องมีคนที่ชำนาญเพื่อทำในแต่ละหน้าที่ และส่งต่องานกัน ตั้งแต่ Product Manager/BA เขียน requirement, Architect/SA ออกแบบระบบ, Developer ลงมือสร้าง, QA/Tester ตรวจสอบ, Release team ปล่อยของ และ Operations/Support ทำการเฝ้าดูระบบ ซึ่งแต่ละช่วงเราต้องมีเอกสาร มีการส่งมอบ และมีคนอนุมัติ อาจกินเวลาหลายเดือน เพื่อให้ได้หนึ่งระบบ

พอ coding agent สร้าง implementation ได้เร็วขึ้น โครงสร้างรอบข้างกลับไม่ได้เร็วตาม Security team ยังมีคนเท่าเดิม, Reviewer ยังอ่าน PR ด้วยตาคู่เดิม, Change Advisory Board ก็ยังประชุมตามรอบเดิม ผลคือเราไม่ได้กำจัดคอขวดครับ เราแค่ย้ายมันจากโต๊ะ Developer ไปกองไว้หน้าโต๊ะคนอื่น

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

เรื่องนี้ต่อกับสิ่งที่ผมเขียนไว้ก่อนหน้า แต่บทความของ Anthropic ตั้งคำถามไปไกลกว่า requirement โดยมองครบทั้งหกช่วง ตั้งแต่การ Plan ไปจนถึง Maintain และถามใหม่ว่า control เดิมต้องรักษาอะไรไว้ แล้วควรเปลี่ยนวิธีบังคับอย่างไร มาถึงจุดนี้ เริ่มน่าสนใจแล้วไหมครับ เช่นนั้นตามมาดูกันต่อ

AI-Native SDLC ไม่ได้ตัดขั้นตอน แต่เปลี่ยนวิธีส่งงาน

สิ่งที่ผมคิดว่าน่าสนใจที่สุดคือ committed artifact โดยทุกช่วงการทำงานจะต้องทิ้งของบางอย่างไว้ให้ช่วงถัดไปอ่านได้ ไม่ใช่จบอยู่ในห้องประชุมหรือใน chat ที่หายไปพร้อม context

ผมมองว่ามันเหมือนการส่งไม้ผลัดครับ ถ้าคนวิ่งแต่ละคนส่งกันด้วยคำพูดว่า เอาประมาณที่คุยเมื่อกี้นะ ต่อให้ทุกคนวิ่งเร็ว ไม้ก็หล่นอยู่ดี แต่ถ้า artifact เก็บทั้ง intent, constraint, decision และ proof ไว้ งานช่วงถัดไปก็เริ่มจากสิ่งที่ตรวจย้อนกลับได้

ตรงนี้เชื่อมกับ Spec-Driven Development ที่ผมเคยเขียนไว้ค่อนข้างตรง ต่างกันตรงที่ Spec-Driven Development สนใจ spec ในฐานะ living contract ขณะที่ Anthropic พยายามต่อ contract ให้ครบทั้งสาย ตั้งแต่ความต้องการไปถึง production feedback

ตรงนี้ผมมองว่าเป็นวิวัฒนาการหนึ่งในการใช้ AI เขียนโค้ดนะครับ ตั้งแต่เราทำ Vibe Coding สั่งด้วย Prompt มาจนถึง Context Engineering เขียนเอกสารในฉบับเดียว และมาตอนนี้ที่เราเริ่มเซ็ตเอกสารได้ตามช่วงการทำงาน และใช้ส่งต่องานกันระหว่าง AI เอง และผมคิดว่าผมเป็นคนหนึ่งที่ตามลองอยู่เรื่อยๆ จะเห็นได้ว่าวิวัฒนาการนี้มันไปไวมากนะครับ ภายในระยะเวลาไม่กี่เดือน อะไรที่เคยคิดว่าเหมาะสมแล้ว ก็จะมีที่เหมาะสมกว่า (ผมไม่ได้บอกว่าของเดิมไม่ดีนะ แต่อาจจะเหมาะกับงานบางลักษณะ เช่น การสั่งทีละ prompt ผมก็ยังใช้กับงานโค้ดเล็กๆ อยู่นะ)

เอกสารใน AI-Native SDLC ไม่ควรเป็นรายงานที่เขียนไว้ให้ครบพิธี แต่มันต้องเป็น state ที่ทั้งคนและ agent ใช้ทำงานรอบถัดไปได้จริง

Skills บอกเส้นทางไป ส่วน hooks ทำหน้าที่เป็นรั้วกั้น (Guardrails)

ในบทความเขาแยกบทบาทของเครื่องมือรอบๆ agent ได้ชัดดีครับ

CLAUDE.md คือไฟล์ความรู้ประจำ repository เช่นคำสั่ง build, test, conventions, architecture และสิ่งที่ Claude มักทำพลาด

ส่วน Skills คือความรู้หรือ policy ที่จะถูกเรียกใช้ซ้ำๆ ในงานแต่ละอย่าง เพื่อให้ได้ของที่มีแนวทางเดิมเสมอ

แต่ Skills เป็นคำแนะนำครับ มันช่วยให้ agent มีแนวโน้มทำถูก ไม่ได้แปลว่าจะบังคับได้ทุกครั้ง (ผมเลยใช้คำว่าเป็น “แนวทางเดิม”) ถ้าเป็นกฎที่ห้ามผิด เช่นห้ามอ่าน secret, ห้ามแก้ generated code, ต้อง run test หรือห้าม deploy production โดยไม่มี approval บทความเสนอให้มี Hooks ซึ่งเป็น script ที่ allow, ask หรือ block การกระทำ ร่วมกับการตั้งค่าใน Tools ต่างๆ เช่น permissions, sandbox และ branch protection

ภาพง่ายๆ บทความจะสื่อคือ Skills เหมือนป้ายบอกทางว่าโค้งข้างหน้าควรลดความเร็ว ส่วน Hooks คือราวกั้นที่ไม่ยอมให้รถวิ่งตกเหว ถ้าเรื่องไหนผิดแล้วเสียหายจริง เราไม่ควรฝากความหวังไว้กับป้ายอย่างเดียว

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

Policy ที่ควรทำ เขียนเป็น skill ได้ แต่ policy ที่ต้องไม่พลาด ควรมี Hooks เป็น deterministic control รองรับ

Test code อย่างเดียวไม่พอ ต้อง test ตัว harness ด้วย

ส่วนที่ผมชอบอีกอย่างคือการพูดถึง continuous evaluations (ในบทความจะเขียนสั้นๆว่า continuous evals) ถ้าเราเปลี่ยน model, prompt, CLAUDE.md, skill หรือ hook แล้วพฤติกรรมของ agent อาจเปลี่ยนทั้งที่ application code ไม่ได้เปลี่ยนเลย ดังนั้น configuration รอบ agent ก็ควรมี regression test ของมันเองด้วย

เรื่องนี้ต้องทดสอบจริงๆครับ จากประสบการณ์ผมเจอเองตั้งแต่ตอนย้ายจาก OpenClaw มา Hermes Agent และที่ทีมผมก็เพิ่งเจอเมื่อเร็วๆ นี้ คือตอนที่ทำ MCP เรียกใช้ข้อมูลในองค์กร โดย harness ที่ต่อ มีทั้งบน Claude, Hermes Agent ที่ผมตั้ง, Agent ที่ทีมผมใช้ Google ADK ทำขึ้น ปรากฎว่าผลลัพธ์มันต่างกันพอสมควร แม้บน LLM Models เดียวกัน ได้คำตอบและ Artifacts ต่างกันแบบเห็นได้ชัด

Anthropic แนะนำให้รวบรวมงานจริงประมาณ 20 ถึง 50 เคส พร้อมผลลัพธ์ที่ยอมรับได้ แล้วรัน suite นี้เมื่อ agent configuration เปลี่ยน สำหรับ bug fix ให้เขียน failing test ก่อน ล็อกไม่ให้ agent แก้ test เพื่อเอาตัวรอด แล้วให้แก้ implementation จน test ผ่าน วิธีนี้ไม่ได้ทำให้ AI ไม่มีวันโกงนะครับ แต่มันทำให้หลักฐานว่าทำงานเสร็จแยกออกจากคำบอกของ agent ชัดขึ้น

แนวคิดนี้สอดคล้องกับ Addy Osmani วิศวกรและผู้เขียนด้าน web performance ที่เสนอเรื่อง Loop Engineering ว่า leverage เริ่มย้ายจากการเขียน prompt ทีละรอบ ไปอยู่ที่ loop ซึ่งค้นงาน มอบหมาย ตรวจผล และเก็บ state ได้เอง ยิ่ง loop ทำงานโดยไม่มีคนเฝ้ามากเท่าไร verifier และ stop condition ก็ยิ่งสำคัญขึ้นเท่านั้น

ผมเคยสรุปอีกมุมของเรื่องนี้ไว้ใน Loop Engineering: 3 ลูปที่ทำร่วมกับ AI Agent เพื่อสร้าง Product ได้จริง ใครสนใจเรื่อง feedback loop ระหว่าง agent, developer และผู้ใช้ ลองอ่านต่อได้ครับ

เมื่อเทียบกับแนวทางของสำนักต่างๆ แต่ละคนกำลังแก้คนละชั้น

ใน Second Brain ของผมมีบทความกลุ่ม AI SDLC ที่เก็บไว้หลายชิ้น พอผมให้วิเคราะห์แล้วเอามาเทียบกันแล้ว พบว่าไม่ได้มีใครเสนอคำตอบเดียวกันทั้งหมด แต่ละสำนักกำลังซ่อมคนละชั้นของระบบ

AWS ใช้ภาพว่า AI เริ่มต้นงาน คนตรวจสอบ แล้ว AI จึงลงมือทำต่อ, McKinsey ขยายไปถึง operating model ที่มนุษย์ใช้เวลากับ judgment และ agent ทำงานที่มีโครงสร้างต่อเนื่อง รวมถึงเสนอ machine-readable handoff กับ knowledge layer เพื่อไม่ให้บริบทกระจัดกระจาย

Snyk เติมคำเตือนที่ควรมีอยู่ในทุก playbook คือ ถ้า AI เร่งทุก phase ได้ มันก็เร่งการสร้าง security debt ได้เช่นกัน จึงต้องมี access control, logging, audit trail และการค่อยๆ เพิ่ม autonomy จาก pilot แทนการเปิดทั้งองค์กรในครั้งเดียว

ส่วน Microsoft ก็มีแนวทาง AI-led SDLC บน Azure และ GitHub ที่พยายามเชื่อม agentic development เข้ากับ delivery pipeline จริง ตั้งแต่ development environment ไปถึงการ promote งานตามลำดับ ผมมองว่ามุมนี้ช่วยเตือนว่า framework จะมีค่าก็ต่อเมื่อมันเชื่อมกับ toolchain ที่ทีมใช้อยู่ ไม่ใช่จบเป็นรูปวงกลมสวยๆ ใน slide

ยืนยันสิ่งที่ตนเองทำร่วมกับทีมทำงาน

ก่อนอ่าน playbook ชิ้นนี้ ผมทำ template และ workflow มาตรฐานกลางให้ทีมในบริษัทใช้อยู่แล้ว ชื่อภายในคือ AI Project Boilerplate เป็นโครงตั้งต้นที่รวม skills, agents, rules, CI และเอกสารมาตรฐานไว้ด้วยกัน เพื่อให้โปรเจกต์ใหม่เริ่มจากวิธีทำงานชุดเดียวกัน แทนที่แต่ละคนจะเปิด coding agent แล้วสั่งกันตามความถนัดของตัวเอง

กระบวนการเริ่มจากมนุษย์เขียน requirement ซึ่งเป็น source of truth จากนั้น AI ช่วย คิด/brainstorming ถามกลับเรื่องขอบเขต เสนอทางเลือก และเขียน design ให้คนอนุมัติ ก่อนแตกออกมาเป็น plan, ADR, Git issue และ feature branch โดยการ implement ผมบังคับให้ใช้ TDD เสมอ และแยก subagent ทำหน้าที่ในการ implementer, tester กับ reviewer แล้วจึงให้คนเข้าทดสอบแบบผู้ใช้จริง ก่อนที่ท้ายสุดเลยคือกระบวนการ Continuous Integration (CI) ในช่วง merge เข้า dev branch จะทำการตรวจ lint, test และ DevSecOps และแจ้งให้ Team Lead review เพื่ออนุมัติการ merge main branch ขึ้น production environment

พอใช้งานจริง ผมพบว่าแนวทางนี้ทำงานได้ดีครับ ทีมไม่ต้องจำว่าจะเรียก skill ไหนต่อ เพราะ workflow พาไปจาก brainstorming, spec, plan, issue, branch, TDD และ review ตามลำดับ Artifact ที่เกิดขึ้นก็ทำให้ย้อนดูได้ว่า งานเริ่มจากโจทย์อะไร ตัดสินใจอะไรไป และผลทดสอบอยู่ตรงไหน

สิ่งที่ตรงกับ Anthropic มากคือ เราไม่ได้พยายามทำให้ AI เก่งด้วย prompt ยาวๆ อย่างเดียว แต่จัด environment รอบมันให้ชัด ทั้งไฟล์กฎ skills ที่เลือกใช้ตามงาน การแยก agent ตามบทบาท และ CI ที่ไม่ยอมให้ของไม่ผ่านเงื่อนไขไหลต่อไปเอง พอระบบรอบข้างดีขึ้น model เดิมก็ทำงานสม่ำเสมอขึ้นอย่างเห็นได้ชัด

ประสบการณ์ของผมคือ AI ทำงานร่วมกับทีมได้ดี เมื่อเราเลิกคาดหวังความเก่งของ model อย่างเดียว แล้วออกแบบ workflow, role และ artifacts ให้ครบ ตามบริบทการทำงานของเรา ซึ่งถ้าใครทำคล้ายๆกันนี้แล้ว บทความของ Anthopic เองเป็นตัวยืนยันว่าคุณมาถูกทาง

ปัญหาที่ยากกว่า tool คือ คนต้องล้างวิธีคิดเดิม

ส่วนที่ผมคิดว่ายากที่สุดกลับไม่ใช่การทำ template หรือเลือก coding agent ครับ แต่คือการ reskill และ upskill คน รวมถึงการล้างวิธีคิดเดิมว่าแต่ละคนรับผิดชอบเฉพาะชิ้นของตัวเองก็พอ

ในกระบวนการเดิม architect อาจส่งแบบให้ developer ต่อมา developer เขียน code แล้วส่งให้ tester จากนั้นแต่ละคนก็รอ feedback จากคนถัดไป แต่เมื่อ AI ทำ implementation ได้เร็วมาก คนทำงานไม่ควรมองเฉพาะ task ตรงหน้าได้เหมือนเดิม เพราะความผิดพลาดจาก spec หรือ architecture จะถูก AI ขยายให้กลายเป็น code และ test จำนวนมากในเวลาไม่นาน

Developer ยุคนี้จึงต้องมองงานตั้งแต่ต้นน้ำถึงปลายน้ำ architecture, spec, plan, task, implementation ไปจนถึง test เองให้ได้ ไม่ได้หมายความว่าทุกคนต้องเก่งที่สุดทุกด้าน หรือองค์กรไม่ต้องมี specialist แล้วนะครับ แต่คนที่ใช้ AI ต้องเข้าใจว่าสิ่งที่อยู่ก่อนและหลัง code เชื่อมกันอย่างไร ต้องกล้าถาม requirement ต้องเห็นผลกระทบเชิงสถาปัตยกรรม ต้องตรวจว่า plan ขาดอะไร และต้องอ่าน test ว่าพิสูจน์ behavior จริงหรือเพียงทำให้ตัวเลข coverage ดูดี

หน้าที่ของคนคุมทีมก็เปลี่ยนเหมือนกัน จากเดิมที่แบ่งงานและเช็กสถานะ อาจต้องออกแบบ guardrail, นิยามจุดอนุมัติ, สอนให้ทีมอ่าน artifact ข้ามบทบาท และสร้างพื้นที่ให้คนทดลองโดยผิดพลาดได้ในวงที่ควบคุมไว้ ถ้าหัวหน้าทีมที่ไหนยังวัดผลงานจากจำนวน ticket หรือบรรทัด code อย่างเดียว คนก็จะใช้ AI เพื่อผลิตของให้เยอะขึ้น แทนที่จะใช้มันช่วยคิดและตรวจงานให้ดีขึ้น ซึ่งผมเองไม่เคยใช้ตัวชี้วัดนี้กับทีมมาแต่แรก ดังนั้นเลยข้ามพฤติกรรมแบบนี้ของคนไปได้เลย

คำว่าล้างสมองในที่นี้ ผมไม่ได้หมายถึงให้ทิ้งหลักวิศวกรรมเดิม ตรงกันข้ามเลยครับ เรายังต้องใช้ architecture, specification, testing, security และ review เหมือนเดิม เพียงแต่ต้องเลิกคิดว่าสิ่งเหล่านี้เป็นสถานีที่มีเจ้าหน้าที่คนละคนเฝ้าอยู่ และคนอื่นไม่จำเป็นต้องเข้าใจ

AI ลดภาระการพิมพ์ code แต่เพิ่มความจำเป็นที่คนทำงานต้องเข้าใจ software ทั้งสาย ตั้งแต่โจทย์จนถึงหลักฐานว่ามันใช้งานได้จริง

ถ้าคนยังทำงานแบบโยนบอลข้ามกำแพง ต่อให้เปลี่ยนกำแพงนั้นเป็น Markdown และมี agent วิ่งรับส่งเอกสารให้ เราก็ยังมี process เดิมที่เคลื่อนที่เร็วขึ้นเท่านั้น ปัญหาของผู้จัดการจึงไม่ใช่แค่ซื้อเครื่องมือหรือเขียน policy แต่ต้องช่วยให้ทีมมองเห็นความรับผิดชอบแบบ end-to-end และให้เวลาเขาในการพัฒนาทักษะที่จำเป็นจริงๆ

ถ้าจะเริ่มกับทีมจริง ผมแนะนำว่าอย่าเริ่มจากระบบอัตโนมัติทั้งวงจร

Playbook ของ Anthropic ยาวและครอบคลุมมาก ถ้าอ่านแล้วเกิดไฟลุก ไปพยายามทำทุกอย่างพร้อมกัน เราอาจใช้เวลาสร้าง process จนไม่ได้ส่งของจริงๆ ผมแนะนำให้เริ่มจากส่วนที่ลดงานซ้ำและตรวจผลได้ก่อน

1. ทำคำสั่ง build, test และ lint ให้ agent เรียกใช้ได้ง่าย และคืนผลสำเร็จหรือล้มเหลวชัดเจน
2. เขียน CLAUDE.md หรือ AGENTS.md ให้สั้นพอที่จะอ่านจริง เก็บ conventions กับ recurring mistakes ที่กระทบงาน
3. กำหนดว่างานระดับไหนต้องมี intent.md, spec.md และ plan.md งานเล็กไม่จำเป็นต้องแบกเอกสารเท่างานเสี่ยงสูง
4. เลือก policy ที่ห้ามผิดเลย สักหนึ่งหรือสองเรื่อง แล้วทำ hook หรือ CI check ให้บังคับได้จริง
5. เก็บงานจริงเป็น eval ทีละเคส โดยเฉพาะ bug หรือ review comment ที่เกิดซ้ำ
6. เมื่อ feedback loop และ rollback ใช้งานได้แล้ว ค่อยเพิ่ม autonomy ใน development ก่อนขยับไป staging และ production

อย่าเริ่ม AI-Native SDLC ด้วยการให้อำนาจ agent มากขึ้น เริ่มด้วยการทำให้มันพิสูจน์งานของตัวมันเองได้ก่อน

อีกเรื่องที่ต้องตกลงให้ชัดคือ source of truth ถ้าองค์กรใช้ Jira/ServiceNow เป็นระบบหลักอยู่แล้ว ไม่จำเป็นต้องย้ายทุกอย่างเข้า Markdown แต่ artifact ใน repository กับ record ในระบบเดิมต้องเชื่อมกลับหากันได้ ไม่อย่างนั้นเราจะได้ข้อมูลสองชุดที่ดูน่าเชื่อถือพอๆ กัน แล้วไม่มีใครรู้ว่าชุดไหนล่าสุด อันนี้น่ากลัวกว่าไม่มีเอกสารอีกครับ 555

ส่วนตัวผม ไม่ได้ใช้พวก Project Management อย่าง Jira/ServiceNow อยู่แล้ว ข้อนี้ผมเลยทำ spec/plan/task หลักไว้ที่ Markdown แต่ผมให้แตก task ไว้บน GitLab Issues และให้ AI จัดการปิดงานตาม Checklist ด้วย เพื่อคอย monitor สถานะงานและใข้รวบรวมเปิด PR Merge แทนคน

บทสรุป

หลังอ่าน The AI-Native SDLC playbook แล้วเทียบกับสิ่งที่ผมกำลังทำกับทีม ผมรู้สึกว่าประโยค code is no longer the bottleneck เป็นเพียงตัวเปิดเรื่อง สิ่งที่กำลังเปลี่ยนจริงคือทั้งหน่วยของการทำงานและขอบเขตความรับผิดชอบ จากเดิมที่แบ่งกันตามตำแหน่ง กลายเป็นการส่งต่อ intent, constraint, implementation และ proof ผ่าน artifact ที่ตรวจย้อนหลังได้ โดยคนทำงานต้องเข้าใจความเชื่อมโยงของมันตลอดสาย

ผมยังไม่คิดว่าทุกทีมควรเปลี่ยนไปใช้ไฟล์ intent.md หรือ spec.md เหมือนกันหมด ชื่อไฟล์ไม่ใช่สาระเท่ากับคำถามว่า คนกับ agent กำลังอ่านความจริงชุดเดียวกันหรือเปล่า งานที่บอกว่าเสร็จมีหลักฐานอะไร และใครเป็นคนมีสิทธิ์รับความเสี่ยงเมื่อจะขึ้น production

ถ้าเราตอบสามข้อนี้ไม่ได้ การเพิ่ม agent อีกสิบตัวอาจทำให้ทีมผลิตของที่ต้องตามแก้ได้เร็วขึ้นเท่านั้น แต่ถ้าตอบได้ AI-Native SDLC ก็ไม่ใช่ buzzword ใหม่ครับ มันคือการค่อยๆ เปลี่ยน process ให้ความเร็วของ AI ไม่วิ่งหนีความสามารถในการควบคุมของทีม

สำหรับผม จุดเริ่มที่เหมาะที่สุดยังเป็นของพื้นฐานมากๆ คือโจทย์ชัด, แผนอ่านรู้เรื่อง, test รันได้, และคนที่อนุมัติรู้ว่าตัวเองกำลังอนุมัติอะไร ฟังดูไม่ล้ำเลยเนอะ แต่ของพื้นฐานพวกนี้แหละครับที่ทำให้ automation ไปต่อได้โดยไม่ต้องคอยลุ้นทุกครั้ง

ผู้อ่านได้อะไรจากบทความนี้

• มองเห็นคอขวดใหม่ หลัง AI ทำให้การเขียน code เร็วขึ้น
• เข้าใจ artifact chain ตั้งแต่ intent, spec และ plan ไปจนถึง production feedback
• แยกคำแนะนำออกจากการบังคับ ว่าเรื่องใดใช้ skill และเรื่องใดควรมี hook หรือ CI gate
• เห็นความต่างของแต่ละแนวทาง จาก Anthropic, AWS, McKinsey, Snyk, Microsoft และ Addy Osmani
• มีลำดับเริ่มต้นที่เล็กพอ สำหรับทดลองกับทีม โดยเริ่มจาก verification ก่อน autonomy
• วางแผน reskill ทีม ให้คนเข้าใจ architecture, spec, plan, implementation และ test แบบ end-to-end พร้อมปรับบทบาทของหัวหน้าทีมจากผู้ติดตามงานเป็นผู้ออกแบบระบบการทำงาน

แหล่งอ้างอิง

• The AI-Native SDLC playbook โดย Louis Claxton, Anthropic
• AI-Driven Development Life Cycle จาก AWS
• Rewiring software delivery for the agentic era จาก McKinsey & Company
• Complete guide to AI-powered software development จาก Snyk
• Loop Engineering โดย Addy Osmani
• An AI-led SDLC with Azure and GitHub จาก Microsoft

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

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

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

สรุปไฮไลต์สั้นๆ

• AI เร่งการเขียน code แต่ไม่ได้ทำให้การค้นหาและถ่ายทอดความต้องการเร็วขึ้นโดยอัตโนมัติ
• คนทำ software เริ่มแยกได้ 5 กลุ่ม ตามระยะห่างระหว่างคนที่มีความต้องการกับคนที่ลงมือสร้าง
• Prototype ที่ใช้งานได้จริง สื่อสารได้ชัดกว่า requirement หรือ wireframe ที่ยังต้องตีความอีกหลายทอด
• Programmer จะขยับเข้าใกล้บทบาท consultant มากขึ้น โดยช่วยเรื่อง architecture, integration, security และ production readiness
• อนาคตอาจเหลือ workflow เด่นเพียง 2 แบบ คือ user สร้างเองโดยมี programmer ช่วยไกด์ กับ user ทำของที่ชัดแล้วส่งให้ programmer ทำต่อ

ผมเห็นคนสร้าง software อยู่ประมาณ 5 กลุ่ม

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

กลุ่มแรกเข้าใจง่ายครับ Programmer รู้ความต้องการเองและลงมือเอง เมื่อมี AI ก็เหมือนได้เครื่องมือเพิ่มกำลัง เขารู้ว่าจะออกคำสั่งอย่างไร อ่านผลลัพธ์เป็น และพอเดาได้ว่าตรงไหนน่าจะมีปัญหา

กลุ่มที่สองกลับยากกว่าที่หลายคนคิด แม้ programmer จะใช้ AI เขียน code ได้เร็ว แต่กว่าจะรู้ว่าคนขออยากได้อะไรจริงๆ ยังต้องประชุม ถามกลับ เขียน requirement แตกเป็น function แล้วแปลงต่อเป็น technical spec กว่าจะเริ่มเขียนได้ เครื่องมือเร็วขึ้น แต่รถยังติดอยู่หน้าด่านเดิมครับ

AI ทำให้มือของ programmer เร็วขึ้น แต่ยังไม่ได้ทำให้คนสองคนเข้าใจกันเร็วขึ้นเสมอไป

Prototype เปลี่ยนการคุยจากคำอธิบายเป็นของที่มองเห็น

กลุ่มที่สามคือ user ทำ prototype แล้วส่งให้ programmer ทำต่อ แบบนี้เร็วขึ้นกว่าส่ง requirement หรือ wireframe อย่างเดียวเยอะครับ เพราะ programmer เห็นหน้าจอ เห็น flow และเห็นว่าคนขอพยายามแก้ปัญหาอะไรอยู่

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

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

Prototype ที่ดีไม่ได้กำจัด requirement แต่มันลดพื้นที่ที่แต่ละคนต้องจินตนาการไม่เหมือนกัน

เมื่อ user ลงมือสร้างเอง Programmer จึงกลายเป็นที่ปรึกษา

กลุ่มที่สี่น่าสนใจมากครับ User มี prototype หรือระบบที่ทำงานได้ประมาณหนึ่งแล้ว จากนั้นให้ programmer เข้าไปเป็น consultant ช่วยดูว่าส่วนไหนควรแก้ ควรต่อกับระบบเดิมอย่างไร หรือมีความเสี่ยงอะไรที่ยังมองไม่เห็น

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

ลักษณะนี้ใกล้กับการมี programmer ยืนอยู่ข้างๆ มากกว่านั่งรอรับเอกสารปลายทาง บทบาทของ programmer จึงไม่ใช่คนพิมพ์ code ตามแบบ แต่เป็นคนช่วยชี้ blind spot ตั้งคำถามเรื่อง architecture, data, security และช่วยตรวจว่าของที่วิ่งได้บนเครื่อง จะไปต่อใน production ได้หรือไม่

มันมีส่วนคล้ายแนวทางของ Forward Deployed Engineer (FDE) ซึ่งเป็น engineer ที่เข้าไปทำงานใกล้กับผู้ใช้หรือทีมลูกค้า ช่วยค้นหาความต้องการ สร้าง prototype ปรับระบบ และนำไปใช้ในสภาพแวดล้อมจริง แทนที่จะรับ spec แล้วหายกลับไปเขียนอยู่คนเดียว คำอธิบายบทบาท FDE จาก DataCamp

User เขียนโปรแกรมเองได้ ทำไมถึงเร็วที่สุด

กลุ่มที่ห้าคือ user สร้างโปรแกรมเอง เขารู้ปัญหา รู้ว่าต้องการอะไร และสั่ง coding agent ให้ช่วยสร้างสิ่งนั้นได้โดยตรง ระยะทางจากความคิดไปถึงของที่กดได้จึงสั้นมาก ไม่ต้องผ่านคนกลางหลายทอด

เจ้านายผมเป็นอดีต programmer พอได้รื้อฟื้นพื้นฐานเดิมร่วมกับ AI เขาก็ไปต่อได้เร็ว เพราะยังมี foundation พอจะเข้าใจว่า code, database, API และ flow ของระบบเกี่ยวกันอย่างไร เขาอาจจำ syntax ไม่ครบ แต่ syntax กลายเป็นเรื่องที่ AI ช่วยได้แล้ว

ตรงนี้มีเงื่อนไขสำคัญครับ User ที่สร้างเองได้เร็ว ไม่ได้แปลว่าไม่ต้องรู้อะไรเลย อย่างน้อยต้องมีพื้นฐานทาง programming หรือมีความสามารถพอจะตรวจสอบ ตั้งคำถาม และรู้ว่าเมื่อไรควรเรียกคนที่มีประสบการณ์เข้ามาช่วย ไม่อย่างนั้นความเร็วอาจพาไปถึงของที่ดูเหมือนใช้ได้ แต่มีปัญหาอยู่ข้างในแบบที่เจ้าตัวไม่รู้

วันหนึ่ง คนที่ทำโปรแกรมได้ดีที่สุดอาจจะไม่ใช่มาจากโปรแกรมเมอร์ที่เก่งที่สุด แต่จะเป็น User ที่ใช้เอไอเขียนโปรแกรมได้เองตามที่ธุรกิจต้องการ

ทำไมมี AI แล้ว process เดิมยังช้า

ในกระบวนการพัฒนา software แบบเดิม ความต้องการจาก user มักต้องผ่าน Product Owner, Business Analyst, System Analyst หรือตำแหน่งอื่นตามโครงสร้างของแต่ละองค์กร คนเหล่านี้ช่วยแปลง idea ให้เป็น requirement, function, design และเอกสารที่ programmer ใช้ทำงานต่อ

จากนั้น requirement ยังอาจต้องถูกแปลงอีกรอบเป็น technical spec, API contract, application design, data model และงานย่อยต่างๆ แต่ละทอดมีทั้งเวลารอ เวลาคุย และความหมายบางส่วนที่อาจหายระหว่างทาง เหมือนเกมกระซิบที่ทุกคนตั้งใจดี แต่ประโยคปลายทางไม่เหมือนต้นทางเสียทีเดียว

ถ้า workflow ยังเป็น user อธิบายให้คนกลาง คนกลางเขียนเอกสาร แล้ว programmer เอาเอกสารไปสั่ง AI ความเร็วจะเพิ่มชัดเจนเฉพาะช่วงเขียน code ครับ ช่วงคิด ตัดสินใจ ขอข้อมูล ทำ spec และรอความเห็นยังใช้เวลาใกล้เคียงเดิม

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

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

อนาคตอาจเหลือ workflow หลักอยู่ 2 แบบ

จากสิ่งที่ผมเห็นภายในเวลาไม่ถึงปี ผมคิดว่า 5 กลุ่มนี้จะค่อยๆ ขยับเข้าหากัน และเหลือ workflow เด่นอยู่ประมาณ 2 แบบครับ

แบบแรก User สร้างเอง แล้วให้ Programmer ช่วยไกด์

User ใช้ AI ทำ prototype หรือระบบที่ทำงานได้เอง ส่วน programmer เข้ามาช่วย review, consult และจัดการเรื่องที่ต้องใช้ความรู้ลึก วิธีนี้ทำให้คนที่รู้ความต้องการที่สุดได้ทดลองของเร็ว และยังมีคนช่วยกันไม่ให้ prototype หลุดไปเป็น production แบบไม่มีรั้ว

แบบที่สอง User ทำ Prototype ที่ชัด แล้วให้ Programmer ทำต่อ

User ไม่จำเป็นต้องเขียนระบบจนเสร็จ แต่ควรนำความต้องการไปให้ไกลกว่าคำอธิบาย ทำ flow, UI และ behavior หลักให้เห็นจริง จากนั้น programmer เข้าไปประกบและทำให้เป็นระบบที่ใช้งานได้ วิธีนี้คล้ายการทำงานแบบ FDE ในมุมที่ engineer อยู่ใกล้ปัญหาและ feedback มากขึ้น

สองแบบนี้ลดจำนวนครั้งที่ความต้องการต้องถูกแปลครับ จากประสบการณ์การคุมงาน วางแผน และทำ project management ของผม ผมเชื่อว่ามันทำให้การพัฒนาเร็วกว่า process เดิมได้มาก และในบางกรณีอาจเกินเท่าตัว แต่ตัวเลขนี้เป็นข้อสังเกตจากงานที่ผมเห็น ไม่ใช่ benchmark ที่ใช้แทนทุกทีม

บทสรุป

สิ่งที่ผมตกผลึกวันนี้คือ AI ไม่ได้ทำให้คอขวดของการพัฒนา software หายไปครับ มันย้ายคอขวดจากการพิมพ์ code ไปอยู่ที่การรู้ความต้องการ การอธิบายให้ชัด และการตรวจว่าสิ่งที่สร้างตรงกับปัญหาจริงหรือไม่

เมื่อก่อนคนที่มี idea ต้องรอให้หลายบทบาทช่วยแปล idea นั้นจน programmer เริ่มลงมือได้ วันนี้ user สามารถใช้ AI ทำให้ความคิดกลายเป็นของที่เห็นและทดลองได้เร็วขึ้น ระยะห่างระหว่างคนที่เจอปัญหากับคนที่สร้างคำตอบกำลังสั้นลงมาก

ผมไม่ได้คิดว่า programmer จะหายไป แต่ตำแหน่งของ programmer ใน workflow จะเปลี่ยน จากคนที่รอรับ requirement ปลายทาง ไปเป็นคนที่เข้าใกล้ user มากขึ้น ช่วยถาม ช่วยไกด์ ช่วยตรวจ และจัดการส่วนที่ความเร็วอย่างเดียวเอาไม่อยู่

สุดท้ายทีมที่ได้ประโยชน์จาก AI มากที่สุดอาจไม่ใช่ทีมที่ generate code ได้เยอะที่สุด แต่เป็นทีมที่ลดจำนวนครั้งของการแปลความต้องการลงได้มากที่สุดครับ

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

คุณลุงชื่อ พึลึ ครับ

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

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

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

ทางหมู่บ้านกำหนดว่า นักท่องเที่ยว 10 คนต้องมีไกด์ท้องถิ่น 1 คน ตอนที่ผมไป ค่าไกด์อยู่ที่ 350 บาทต่อวัน ใครอยากให้ทิปเพิ่มก็แล้วแต่ความพอใจ และไกด์ไม่ได้แย่งกันรับลูกค้าครับ เขาจัดคิวเรียงกัน ใครถึงคิวก็ได้พานักท่องเที่ยวเข้าไป

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

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

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

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

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

คุณลุงอยู่ในป่ามาราว 40 ปี ใช้ชีวิตอยู่คนเดียว เมื่อก่อนแกเลี้ยงแพะไว้ขาย แต่พอเลี้ยงไปนานๆ แพะกลายเป็นเพื่อน แกจึงไม่อยากขายแล้ว เปลี่ยนมาเลี้ยงไว้และเอามูลแพะไปทำปุ๋ย ปลูกต้นไม้ ทำเกษตรของแกต่อไป

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

น้ำตกห้วยน้ำเย็นก็คงเหมือนกัน

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

แล้วมีประโยคหนึ่งที่ผมฟังแล้วรู้สึกจุกอยู่ในใจ

“น้ำตกแห่งนี้ไม่ใช่ของผม แต่เป็นน้ำตกของคนไทยทุกคน”

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

แต่คุณลุงกลับคิดคนละแบบ

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

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

ซึ่งในคลิปของพลอยคือ 11 เดือนก่อนจากวันที่ผมไป (22 สิงหาคม 2569) ตอนนี้มีห้องน้ำ ลานพักตรงบ้านลุง ลานตรงน้ำตก สะพานบนน้ำตก มากขึ้นอย่างเห็นได้ชัด

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

สิ่งที่ผมเห็นด้วยตาตัวเองในทริป กับสิ่งที่ได้ฟังจากไกด์และจากบทสัมภาษณ์ มันค่อยๆ ต่อกันเป็นภาพเดียว

ทางเส้นหนึ่งที่คนคนเดียวเริ่มทำ กลายเป็นทางที่พารายได้เข้าไปหาคนอีกหลายครอบครัว

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

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

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

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

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

ทั้งหมดเริ่มจากความคิดง่ายๆ ของคุณลุงว่า ของสวยๆ แบบนี้ ไม่ควรมีแกได้เห็นอยู่คนเดียว..

ผมชื่นชมและนับถือหัวใจคุณลุงมากครับ

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

น้ำตกห้วยน้ำเย็นสวยจริงครับ แต่สำหรับผม คนที่ทำให้พวกเราได้เข้าไปเห็นน้ำตก งดงามไม่แพ้กันเลย..

ข้อมูลเพิ่มเติม

• Pigkaploy: เปิดเส้นทางน้ำตกห้วยน้ำเย็น ใช้เวลาทำทางถึง 10 ปี
• ข่าวสด: ลุงใช้เวลาเกือบ 10 ปี ทำให้ทุกคนได้เห็นน้ำตกแห่งนี้
• ข้อมูลตำแหน่งและเส้นทางน้ำตกห้วยน้ำเย็น

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

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

เราไม่มีทางเป็นคนดีในทุกเรื่องเล่า

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

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

ความตั้งใจใดๆ ของเรา อาจไม่ได้สื่อความหมายที่เกิดขึ้นในใจของผู้อื่น

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

ทุกคนล้วนเป็นตัวเอกในชีวิตตนเอง

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

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

เราเป็นตัวเอกในเรื่องของเราได้ แต่ไม่มีทางเป็นตัวเอกในเรื่องของทุกคน

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

แต่คำว่า ช่างมัน ไม่ได้แปลว่าเราจะไม่รับผิดชอบ

แต่ๆ คำว่าใครจะมองเรายังไงก็ช่าง อาจฟังเหมือนการไม่สนใจใคร แต่ผมคิดว่าต้องแยกให้ออกระหว่าง การไม่ยอมให้คำตัดสินของคนอื่นกำหนดคุณค่าของเรา กับ การไม่รับผิดชอบต่อผลของการกระทำ

ถ้าเราทำร้ายใคร โกหก เอาเปรียบ หรือทำผิดจริงๆ การบอกว่าเป็นแค่เรื่องราวที่เขาเขียนถึงเรา ไม่ควรเป็นข้ออ้างให้เราหนีความรับผิดชอบ แต่เราต้องรับฟัง ต้องขอโทษ แก้ไข และเรียนรู้เท่าที่ทำได้ ไม่ใช่ประกาศว่าใครไม่เข้าใจก็เรื่องของเขา แล้วก็เดินจากไปแบบเท่ๆ อันนั้นอาจไม่ใช่ปรัชญาชีวิต แต่เป็นแค่การเข้าข้างตัวเอง(แบบผิดๆ)ครับ

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

รับผิดชอบต่อสิ่งที่เราทำ แต่ไม่ต้องรับภาระในการควบคุมความคิดของทุกคน

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

คุณค่าของเราไม่ควรขึ้นกับความคิดใคร

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

คนอื่นมีสิทธิ์มองเรา แต่เราเองก็ต้องรู้ว่าเรามองตัวเองอย่างไร เราให้คุณค่ากับความซื่อสัตย์ ความรับผิดชอบ ความเมตตา หรือความกล้าที่จะรักษาขอบเขตของตัวเองแค่ไหน สิ่งเหล่านี้ควรเป็นเข็มทิศ มากกว่าเสียงวิจารณ์ที่เปลี่ยนไปตามอารมณ์และความสัมพันธ์

คำถามที่น่าถามจึงไม่ใช่ว่า วันนี้ทุกคนมองว่าเราเป็นคนดีหรือยัง แต่เป็นคำถามที่ตรงกว่า

• วันนี้เราทำในสิ่งที่เราเชื่อว่าดีแล้วหรือยัง
• เราซื่อสัตย์กับตัวเองและคนอื่นมากพอหรือยัง
• เมื่อทำผิด เรายอมรับและแก้ไขหรือมันเปล่า
• เรากำลังรักษาขอบเขต หรือแค่ทำร้ายคนอื่นแล้วหาคำอธิบายให้ตัวเอง

ยิ่งรู้จักตัวเอง ยิ่งไม่ต้องอธิบายตัวเองตลอดเวลา

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

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

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

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

มาถึงท้ายบทความ

ประโยค We are all bad in someone’s story ไม่ได้ทำให้ผมอยากเป็นคนที่ไม่แคร์ใคร ตรงกันข้าม มันเตือนให้ผมทำดีกับคนอื่นโดยไม่ต้องคาดหวังว่าจะได้รับบทคนดีเสมอในหนังสือเขาก็ได้ และฝึกรับผิดชอบเมื่อทำผิดจริงๆ โดยไม่พยายามไปควบคุมความคิดของทุกคน

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

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

ถ้าตอบคำถามเหล่านี้ได้ ต่อให้เราเป็นคนเลวในเรื่องราวของใครบางคน อย่างน้อยเราก็ยังไม่หลงออกจากเรื่องราวของตัวเอง..

ใครอ่านมาถึงตรงนี้ (หรือจะเลื่อนลงมาเจอเลยก็แล้วแต่ 55) ผมต้องขอบคุณมากครับ ไม่ค่อยได้มีโอกาสเขียนเรื่องปรัชญา ความคิด ของตัวเองมานาน เลยขอรื้อฟื้นหน่อย และผมไม่ได้มีประเด็นอะไรกับใครนะ แค่ชอบประโยคและอยากขีดเขียนขึ้นมาเท่านั้น หากใครมีความเห็นอะไร สามารถมาแลกเปลี่ยนพูดคุยกันได้เสมอครับ

14 สิงหาคม 2569 – ในห้องที่มีแมวส้มย่านอารีย์

นี่เป็นรูปแบบที่ผมคิดว่าน่าสนใจมากสำหรับคนที่ต้องเขียน 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

ช่วงแรกๆ ผมก็สั่งเป็นรอบๆ ไปเหมือนกันครับ วันนี้ให้ช่วยแก้ bug พรุ่งนี้ให้ช่วย refactor อีกวันให้ช่วยเขียน test แต่พอใช้ไปนานๆ จะเริ่มเห็น pattern ว่า หลายเรื่องเราสั่งซ้ำๆ อยู่ตลอด เช่น ก่อน push ต้อง test ก่อน, ถ้าตกลง plan แล้วให้ create task เป็น issue, ห้าม merge dev เอง ต้องขอ approve ก่อน

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

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

Working Agreement กับ AI คืออะไร

ถ้าแปลตรงตัว Working Agreement คือข้อตกลงในการทำงานร่วมกัน ในทีมคน เราอาจตกลงกันว่า pull request ต้องมี review, ต้องเขียน test, ห้าม push เข้า main ตรงๆ หรือถ้างานใหญ่ต้องแตก task ก่อนทำ

พอมาเป็น AI coding agent แนวคิดเดียวกันก็ใช้ได้ครับ เพียงแต่คู่สนทนาของเราเป็น AI ที่อ่าน instruction แล้วพยายามทำตาม ถ้าเราไม่เขียนกติกาไว้ให้ชัด มันก็จะใช้ default behavior ของตัวเอง หรือเดาจาก prompt รอบนั้นๆ

Working Agreement กับ AI คือการเปลี่ยนสิ่งที่เราต้องสั่งซ้ำทุกวัน ให้กลายเป็นกติกาประจำโปรเจกต์

สำหรับผม มันไม่ใช่เรื่องสวยหรูหรือ process หนักๆ แต่เป็น trick เล็กๆ ที่ช่วยลดการหลุด ลดการลืม และทำให้ AI ทำงานใกล้เคียงกับวิธีที่ทีมต้องการมากขึ้น

ทำไมสั่งเป็นรอบๆ แล้ว AI ถึงหลุดง่าย

AI เก่งขึ้นมากก็จริง แต่การคุยแบบ chat มีข้อจำกัดตามธรรมชาติอยู่ครับ เช่น context ยาวขึ้นเรื่อยๆ, session ถูกปิด, prompt รอบใหม่ไม่เหมือนรอบเดิม หรือบางคำสั่งถูกกลืนไปกับรายละเอียดอื่น

ถ้าเราบอกแค่รอบนี้ว่า “ช่วยแก้ให้แล้ว test ด้วยนะ” AI ก็อาจทำตามในรอบนี้ แต่ไม่ได้แปลว่ารอบหน้ามันจะจำได้ว่า project นี้ต้อง test ก่อน push เสมอ หรือห้าม merge เองทุกครั้ง

เอกสารของ Claude Code มีแนวคิดเรื่อง memory files เช่น CLAUDE.md ที่ใช้เก็บ project instructions และบอกด้วยว่าสามารถใช้คำสั่ง /init เพื่อสร้างไฟล์เริ่มต้นจาก project ได้ ส่วน OpenAI Codex ก็มีแนวทางใช้ AGENTS.md เพื่อให้ coding agent รู้กติกา repo เช่น setup, test และ convention ของโปรเจกต์

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

เริ่มง่ายสุด: init project แล้วเขียนกติกาไว้

วิธีที่ง่ายที่สุดสำหรับคนใช้ Claude Code คือเริ่มจาก /init เพื่อให้ Claude อ่าน repo แล้วสร้าง CLAUDE.md เป็น project memory ตั้งต้นก่อน จากนั้นค่อยเติม Working Agreement ของทีมลงไป

/init

สำหรับเครื่องมืออื่น แนวคิดเหมือนกันครับ เช่น Codex ใช้ AGENTS.md, บางทีมใช้ .cursorrules, บางทีมใช้ project instructions หรือ docs เฉพาะของตัวเอง ชื่อไฟล์อาจต่างกัน แต่หน้าที่คล้ายกัน คือบอก AI ว่า “โปรเจกต์นี้ทำงานกันแบบนี้นะ”

อย่าปล่อยให้ rule สำคัญอยู่ในหัวคน หรืออยู่ใน chat รอบเดียว ถ้ามันเป็นกติกาซ้ำๆ ให้เขียนลง project instruction

ควรเขียน Working Agreement อะไรไว้บ้าง

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

ตัวอย่าง CLAUDE.md / AGENTS.md แบบสั้น

ตัวอย่างนี้เป็นแนวทางที่ผมคิดว่าเริ่มใช้ได้ทันที แล้วค่อยปรับตามทีมครับ

# AI Working Agreement

## Goal
ช่วยพัฒนา project นี้แบบปลอดภัย ตรวจสอบได้ และไม่ทำ side effect โดยไม่ขออนุญาต

## Before coding
- ถ้างานเกิน 1 ไฟล์ ให้เสนอ plan สั้นๆ ก่อนแก้
- ถ้า scope ไม่ชัด ให้ถามก่อน ไม่เดาเองในจุดเสี่ยง
- หลังตกลง plan แล้ว ให้สร้างหรืออัปเดต issue/task เสมอ

## Coding rules
- แก้แบบ minimal diff
- ห้าม rewrite ทั้งไฟล์ถ้าไม่จำเป็น
- ทำตาม style เดิมของ repo
- ถ้าเปลี่ยน behavior ต้องเพิ่มหรือแก้ test ที่เกี่ยวข้อง

## Verification
- ก่อนเสนอว่าเสร็จ ต้องรัน targeted test ที่เกี่ยวข้อง
- ถ้าแก้หลายส่วน ให้รัน lint/typecheck ตามที่เหมาะสม
- final response ต้องบอก command ที่รันและผลจริง

## Git safety
- ห้าม merge dev/main/master อัตโนมัติ
- ห้าม push โดยไม่ขอ approve
- ห้ามลบไฟล์หรือ migration สำคัญโดยไม่ถามก่อน

## Output
- สรุป changed files
- สรุป tests ที่รัน
- บอก risk หรือสิ่งที่ยังไม่ได้ verify

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

Working Agreement ไม่ใช่ prompt ยาวๆ แต่คือ guardrail

จุดที่ต้องระวังคืออย่าเขียน instruction ยาวจนกลายเป็น manual ที่ไม่มีใครอ่าน ทั้งคนและ AI ควรเขียนให้สั้น ชัด และ actionable

• เขียนเป็น bullet
• แยกหมวดชัดเจน
• ระบุ command ที่ต้องใช้จริง
• แยกสิ่งที่ทำได้เอง กับสิ่งที่ต้องขอ approve
• มี verification rule ทุกงาน

ผมชอบคิดว่ามันคือ guardrail ไม่ใช่ prompt สวยๆ หน้าที่ของมันคือกันไม่ให้ AI หลุดออกจากวิธีทำงานที่ทีมตกลงกันไว้

แยกกติกาเป็น 3 ระดับ

ถ้าใช้จริงในทีม ผมแนะนำให้แยก rule เป็น 3 ระดับ จะดูแลง่ายกว่าเขียนทุกอย่างกองไว้ที่เดียว

การแยกแบบนี้ช่วยให้ rule ที่ถาวรไม่ปนกับรายละเอียดงานชั่วคราว และช่วยลดโอกาสที่ AI จะเอา instruction เฉพาะ task ไปใช้ผิดบริบทในงานอื่น

ตัวอย่าง rule ที่ผมว่าน่าใส่แทบทุก repo

ถ้าจะเริ่มแบบ practical ผมว่าสามารถ copy แนวนี้ไปปรับได้เลยครับ

• ต้อง search ก่อนอ่านไฟล์เยอะๆ เพื่อประหยัด token และลด noise
• ต้องอ่านไฟล์ที่เกี่ยวข้องจริงก่อน patch ห้ามเดา code จากชื่อไฟล์อย่างเดียว
• ต้องเสนอ plan ก่อนงานใหญ่ โดยเฉพาะงานที่แตะหลาย module
• ต้องทำ minimal diff ถ้าไม่ได้สั่ง refactor ใหญ่
• ต้องรัน test ก่อนบอกว่าเสร็จ และรายงาน output จริง
• ห้าม push/merge/delete/migrate โดยไม่ขอ approve
• ถ้า command fail ต้องรายงานตรงๆ ห้ามบอกว่าสำเร็จจากการเดา
• ถ้าเจอ requirement ใหม่ ให้บันทึกเป็น issue/task ไม่ปล่อยหายใน chat

AI ที่เก่งแต่ไม่มี working agreement จะทำงานเร็ว แต่ทีมอาจต้องเสียเวลาตามเก็บทีหลัง

ควรทบทวนกติกานี้เมื่อไร

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

ผมคิดว่าน่าทบทวนเมื่อมีเหตุการณ์พวกนี้

• AI หลุด rule เดิมซ้ำๆ
• ทีมเริ่มใช้ AI agent หลายตัวพร้อมกัน
• มี incident จากการแก้ code โดยไม่ได้ verify
• เปลี่ยน test command หรือ build pipeline
• มีคนใหม่เข้าทีมแล้วใช้ AI ไม่เหมือนคนอื่น
• เริ่มใช้เครื่องมือใหม่ เช่น Claude Code, Codex, Cursor หรือ Gemini CLI

พูดง่ายๆ คือถ้าเป็นบทเรียนที่ไม่อยากให้เกิดซ้ำ ให้ย้ายมันเข้า Working Agreement ครับ

ข้อควรระวัง: อย่าเชื่อว่าเขียน rule แล้ว AI จะไม่พลาดอีกเลย

การมี Working Agreement ช่วยได้มาก แต่ไม่ได้ทำให้ AI กลายเป็นระบบ deterministic 100% ครับ เรายังต้องมี verification, test, review และ approval gate อยู่ดี

โดยเฉพาะ rule ที่มีผลกับ production หรือ source control เช่น merge, push, deploy, migration, delete data อันนี้ไม่ควรปล่อยให้ AI ตัดสินใจเองจาก prompt อย่างเดียว ต้องมี human approval หรือ branch protection ช่วยล็อกอีกชั้น

ผมมองว่า Working Agreement เป็นชั้นแรกที่ช่วยให้ AI ทำถูกทางมากขึ้น ส่วน test, CI, review และ approval เป็นชั้นถัดมาที่ช่วยจับความผิดพลาดก่อนกระทบของจริง

สรุป

หลังจากใช้ AI มาพักใหญ่ ผมเริ่มรู้สึกว่าเราไม่ควรมอง AI เป็นแค่ chatbot ที่สั่งทีละรอบ แต่ควรมองเป็นผู้ช่วยทำงานที่ต้องมี working agreement เหมือนสมาชิกทีมคนหนึ่ง

ถ้ามีเรื่องที่เราต้องสั่งซ้ำๆ เช่น test ก่อน push, create issue หลังตกลง plan, ห้าม merge dev เอง หรือรายงานผล verify ทุกครั้ง ก็ไม่ควรปล่อยให้มันอยู่ในความทรงจำชั่วคราวของ session ครับ เขียนมันลง project instruction ไปเลย

เริ่มจากเล็กๆ ก็พอ เช่นใช้ /init ใน Claude Code เพื่อสร้าง CLAUDE.md แล้วเติมกติกาของทีมลงไป หรือถ้าใช้ Codex ก็ทำ AGENTS.md ใน repo ให้ชัด แค่นี้ก็ช่วยลดการหลุด ลดการสั่งซ้ำ และทำให้ AI ทำงานเข้ากับทีมได้ดีขึ้นมากแล้วครับ

แหล่งอ้างอิง

• Claude Code Docs: How Claude remembers your project
• OpenAI Codex: Custom instructions with AGENTS.md
• AGENTS.md: open format for coding agent instructions
• Augment Code: AI Agent Pre-Merge Verification