ใช้ AI ทุกวันแบบไม่ให้สมองฝ่อ: 7 กติกาง่ายๆ สำหรับคนทำงานสายความรู้

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

ใช้ AI ทุกวันแบบไม่ให้สมองฝ่อ: 7 กติกาง่ายๆ สำหรับคนทำงานสายความรู้

AI, Productivity, Knowledge Work, Developer, Designer

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

1) คิดเองก่อน 5 นาที แล้วค่อยเปิด AI

กติกาง่ายที่สุด แต่ช่วยได้เยอะที่สุดคือ ห้ามเปิด AI ทันทีที่เจอโจทย์ ผมจะให้เวลาตัวเอง 5-10 นาทีในการร่างคำตอบหรือแนวทางก่อนเสมอ

  • ถ้าเป็นงานเขียน: ร่างหัวข้อเอง 3 ข้อ
  • ถ้าเป็นงานโค้ด: ลองคิด logic หรือ pseudo-code ก่อน
  • ถ้าเป็นงานดีไซน์: เขียน constraint กับ user goal ก่อน
  • ข้อดีคือเรายังได้ฝึกการจัดโครงสร้างความคิด และเวลาเอาไปคุยกับ AI เราจะถามได้คมขึ้นมาก ไม่ใช่โยนโจทย์กว้างๆ แล้วหวังคำตอบสำเร็จรูป

    > ใช้ AI หลังจากเริ่มคิดเองแล้ว คุณจะได้ "คู่คิด" ไม่ใช่ "คนคิดแทน"

    2) แบ่งช่วงเวลาเป็น no-AI block

    ผมชอบตั้งช่วง no-AI block วันละ 30-90 นาที โดยเฉพาะงานที่เป็นทักษะแกน เช่น การเขียน การอ่านยากๆ การ debug หรือการคิด concept ใหม่

    ช่วงนี้กติกาคือ

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

    สำหรับคนทำงานสาย dev หรือ design ผมว่าช่วง no-AI block สำคัญมาก เพราะมันรักษา instinct เรื่อง architecture, edge case และ taste ในงาน ซึ่งเป็นของที่สร้างจากการฝึก ไม่ใช่จากการกด prompt เก่งอย่างเดียว

    3) ให้ AI วิจารณ์ มากกว่าสร้างแทนทั้งหมด

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

    ตัวอย่างที่ใช้ได้จริง

  • เขียน draft เองก่อน แล้วให้ AI ช่วยชี้ว่าตรงไหนวกวน
  • เขียนโค้ดเองก่อน แล้วให้ AI หา bug, edge case หรือ naming ที่ควรปรับ
  • ทำ wireframe เองก่อน แล้วให้ AI ช่วย critique flow จากมุมผู้ใช้ใหม่
  • prompt ที่เวิร์กมักไม่ใช่ "ช่วยทำให้หน่อย" แต่เป็นแนวนี้

  • "ช่วยวิจารณ์ในมุมคนอ่านที่ไม่มี context"
  • "ช่วยหา 3 ความเสี่ยงของ approach นี้"
  • "ถ้าจะ refactor ให้ maintain ง่ายขึ้น ควรเริ่มตรงไหน"
  • ผลที่ได้คือเรายังเป็นเจ้าของความคิดหลัก แต่มี reviewer ที่พร้อมอ่านงานให้ตลอดเวลา ซึ่งสำหรับคนทำงานความรู้ มันคุ้มมาก

    4) ใช้ AI กับงานซ้ำๆ ไม่ใช่งานตัดสินใจสำคัญ

    AI เหมาะมากกับงานประเภท เร่งความเร็ว เช่น

  • สรุปประชุมให้เป็น bullet
  • ปรับโทนภาษาในอีเมล
  • แปลงข้อมูลกระจัดกระจายให้เป็นโครงร่าง
  • ช่วยเขียน test case, checklist หรือ first-pass documentation
  • แต่ผมพยายามไม่โยนงานที่ต้องใช้ judgment หลักให้มันตรงๆ เช่น

  • ตัดสินใจ product direction
  • สรุป insight จาก user research แบบไม่อ่านต้นฉบับ
  • เลือก trade-off ทางเทคนิคแทนทีม
  • เหตุผลคือ AI ให้คำตอบที่ฟังดูมั่นใจได้ง่ายมาก และบางครั้งมันเก่งพอจะทำให้เราหยุดตั้งคำถามเร็วเกินไป งานที่มีผลระยะยาวกับทีม กับลูกค้า หรือกับคุณภาพงาน ควรให้ AI ช่วยจัดระเบียบข้อมูล แต่คนยังต้องเป็นคนตัดสินใจ

    5) ตรวจคำตอบเสมอ โดยเฉพาะเรื่องที่ “เหมือนจะใช่”

    จุดอันตรายของ AI ไม่ใช่คำตอบที่ผิดแบบชัดๆ แต่เป็นคำตอบที่ ฟังดีจนเราไม่เช็กต่อ ผมเจอกับตัวบ่อยมาก ทั้งเรื่อง syntax, library behavior, summary ของบทความ หรือแม้แต่คำอธิบาย concept ที่อ่านลื่นแต่มีจุดเพี้ยนเล็กๆ

    กติกาที่ใช้คือ

  • ถ้าเป็น fact: เปิด source จริงเช็ก
  • ถ้าเป็นโค้ด: รันจริง ทดสอบจริง
  • ถ้าเป็นงานเขียน: อ่านออกเสียงดูว่ามันเป็นภาษาของเราจริงไหม
  • ถ้าเป็นข้อเสนอเชิงกลยุทธ์: ถามกลับหาข้อเสียและ assumptions
  • บางทีผมจะตั้งใจถาม AI ต่อว่า

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

    6) เก็บ log ว่าเราใช้ AI ตอนไหน และคุ้มจริงไหม

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

    ตัวอย่างที่น่าสนใจคือ

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

    7) ฝึกอธิบายสิ่งที่ได้จาก AI กลับเป็นภาษาของตัวเอง

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

    วิธีนี้ใช้ได้กับทุกสายงาน

  • dev: อธิบายว่าทำไม patch นี้แก้ปัญหาได้
  • designer: อธิบายเหตุผลของ flow ที่เลือก
  • PM/knowledge worker: อธิบายสรุปประเด็นโดยไม่เปิดหน้าจอช่วย
  • สุดท้าย AI ที่ดีที่สุดไม่ใช่ตัวที่ตอบเก่งที่สุด แต่คือตัวที่ช่วยให้เราคิดชัดขึ้น ทำงานไวขึ้น และยังรักษาฝีมือของตัวเองไว้ได้ ถ้าจะเริ่มวันนี้ ผมแนะนำง่ายๆ เลยคือ คิดเองก่อน, ตั้ง no-AI block, และใช้ AI เป็นคนวิจารณ์มากกว่าคนเขียนแทนทั้งหมด แค่นี้เราก็ใช้ AI ได้คุ้ม โดยไม่ต้องแลกกับสมองที่ค่อยๆ ขี้เกียจคิดลงทุกวัน

    ข้อมูลอ้างอิง

    1. OpenAI Blog
    2. Anthropic
    3. Google Workspace Blog

    กลับไปยังบล็อก OVERFLOW