ข้ามไปยังเนื้อหา
Tayakorn
· ai-dev

อธิบายกลไก ไม่ใช่ขั้นตอน

ทำไมคู่มือทุกเล่มที่ผมเขียนถึงเริ่มจาก "มันทำงานยังไง" ไม่ใช่ "กด 1-2-3"

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

ขั้นตอนเน่าเสียได้ กลไกไม่

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

กลไกไม่เน่าแบบนั้น เข้าใจว่า git เก็บ commit เป็นกราฟ snapshot คุณจะเดา behavior ของคำสั่งที่ไม่เคยใช้ได้เอง แต่ถ้าจำแค่ว่า "พิมพ์ git rebase -i แล้วกด..." พอเจอ conflict จริงเมื่อไหร่ก็จบเห่

"เข้าใจถึงแก่น" คือมีโมเดลอยู่ในหัว

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

โมเดลที่ดีทำสองอย่างพร้อมกัน

  • บีบอัด — แทนที่จะจำร้อยขั้น เหลือจำหลักไม่กี่ข้อ
  • ต่อยอด — จากหลักไม่กี่ข้อนั้น แตกขั้นตอนใหม่ ๆ ออกมาได้เอง

นี่คือเหตุผลที่คู่มือ git ของผมมีไดอะแกรมของ "กลไกข้างใน" ไม่ใช่แค่ลิสต์คำสั่ง และทำไม AI Brain ถึงอธิบายว่า Second Brain ทำงานยังไง ไม่ใช่แค่ "ลงแอปไหน กดตรงไหน"

ต้นทุนมีจริง แต่จ่ายครั้งเดียว

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

ส่วน step-by-step ให้ dopamine เร็วกว่าเยอะ — ทำตามปุ๊บเห็นผลปั๊บ

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

ถ้ารู้แค่ขั้นตอนสร้างกราฟ ตรงนี้คือทางตัน เพราะหน้าจอไม่มีปุ่มไหนบอกว่าต้นตออยู่ตรงนี้

แต่ตัวเลขหนึ่งตัวบนจอมีเส้นทางของมัน

  1. ข้อมูลต้นทาง
  2. ความสัมพันธ์ในโมเดล
  3. สูตร measure
  4. แล้วค่อยโผล่บน visual

พอถือเส้นทางนี้ไว้ในหัว เห็นอาการปุ๊บก็นึกย้อนกลับถึงรากได้เลยว่าพังอยู่ชั้นไหน

ผมเลยมองว่ามันคือการเลือกระหว่างสองอย่างนี้

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

สำหรับเครื่องมือที่ผมต้องใช้ไปทั้งชีวิต — git, การออกแบบระบบ, การเขียน prompt — ผมเลือกอย่างหลังเสมอ

แล้วมันก็วนกลับ

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

อธิบายกลไกให้ชัด แล้วขั้นตอนจะตามมาเอง — ทุกครั้ง