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

ช่วงนี้ผมหันกลับมาดูวิธีที่ตัวเองใช้ปัญญาประดิษฐ์ แล้วเจอเรื่องหนึ่งที่ค่อนข้างตลก

สรุปสั้น ๆ

ช่วงนี้ผมหันกลับมาดูวิธีที่ตัวเองใช้ปัญญาประดิษฐ์ แล้วเจอเรื่องหนึ่งที่ค่อนข้างตลก

ผมแทบไม่เคยบอกขั้นตอนแบบละเอียดทีละข้อเลย

คำสั่งส่วนใหญ่ประมาณว่า “อยากชนะ” “ลดงานของผมลงหน่อย” “อย่าหยุดกลางทาง” “เช็กด้วยว่าทำเสร็จจริงหรือยัง”

หยาบมาก พูดตรง ๆ คือหยาบสุด ๆ

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

สุดท้ายกระบวนการทำงานจึงค่อย ๆ เปลี่ยนจาก “คนต้องตรวจทุกอย่างทุกครั้ง” เป็น ให้ระบบทำ ให้ระบบตรวจ เทียบกับหลักฐานจากภายนอก แล้วให้คนรับรายงานเฉพาะตอนมีความผิดปกติ

พอลองค้นดูต่อก็พบว่า แนวทางนี้คล้ายกับแนวคิดด้านวิศวกรรมที่ OpenAI เรียกว่า “Harness Engineering” ซึ่งเผยแพร่ในปี 2026 มากพอสมควร

คนกำหนดเจตนาและขอบเขต ส่วนตัวแทนปัญญาประดิษฐ์ลงมือทำ

ปัญหาคือ วิธีนี้ทรงพลังมากในโปรเจกต์ส่วนตัว แต่พอเอาเข้าองค์กร ความยากจะเพิ่มขึ้นทันที

โปรเจกต์ส่วนตัวคือเผด็จการที่ไม่มีการเมือง

พอเข้าบริษัท รัฐสภาเปิดประชุมทันที


จุดเริ่มต้นมีแค่สองอย่าง: อยากชนะ และอยากทำงานให้น้อยลง

เป้าหมายระดับบนเรียบง่ายอย่างไม่น่าเชื่อ

ถ้าเป็นเกมการ์ด ผมอยากชนะ

ถ้าเป็นงานบทความหรือระบบอัตโนมัติ ผมอยากลดงานที่ตัวเองต้องทำ

สองเป้าหมายนี้แข็งแรงมาก เพราะต่อให้เทคโนโลยีข้างใต้ซับซ้อนขึ้น เป้าหมายก็ยังเหมือนเดิม

จะสร้างโปรแกรมจำลอง รันการแข่งขันเป็นพัน ๆ เกม หรือใส่อัลกอริทึมค้นหาก็ได้

สุดท้ายคำถามยังเป็น “แล้วอัตราชนะดีขึ้นไหม?”

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

สุดท้ายคำถามยังเป็น “แล้วงานของผมลดลงไหม?”

วิธีทำอาจซับซ้อนขึ้นได้ โดยไม่จำเป็นต้องทำให้เป้าหมายซับซ้อนตาม

และเพราะเป้าหมายไม่ค่อยแกว่ง จึงปล่อยให้ระบบปัญญาประดิษฐ์มีอิสระเลือกวิธีได้ค่อนข้างมาก


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

คนไม่จำเป็นต้องออกแบบเกณฑ์จบงานจากศูนย์ทุกครั้ง

อาจเริ่มจากเป้าหมายกว้าง ๆ อย่าง:

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

จากนั้นให้ระบบแตกคำถามต่อเอง เช่น:

  • อะไรคือ “ล่าสุด”
  • อะไรคือ “ถูกต้อง”
  • คำแปลยังตรงกับต้นฉบับเวอร์ชันปัจจุบันหรือไม่
  • งานที่ตั้งใจทำ 50 รายการ จะถือว่าเสร็จหลังสำเร็จแค่ 1 รายการได้หรือไม่
  • แค่ขึ้น GitHub ถือว่า “เผยแพร่” แล้วหรือยัง
  • ต้องตรวจเว็บไซต์จริงด้วยหรือไม่

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

แน่นอนว่า ระบบก็ออกแบบเกณฑ์ผิดได้

เพราะฉะนั้นขั้นต่อไปจึงต้องมีการตรวจสอบ


ใช้ปัญญาประดิษฐ์เยอะมาก แต่คำว่า “ระบบบอกว่าเสร็จแล้ว” ไม่ใช่หลักฐาน

มองจากข้างนอกอาจเหมือนโยนทุกอย่างให้ระบบปัญญาประดิษฐ์

ซึ่งก็เกือบถูก เพราะทั้งการทำงานและการตรวจงานก็โยนให้ระบบ

ถ้าเลือกได้ ผมไม่อยากอ่านบันทึกการทำงานด้วยซ้ำ

กระบวนการในอุดมคติคือ:

ทำงาน → ตรวจอัตโนมัติ → ถ้าปกติรายงานสั้น ๆ → ถ้ามีปัญหาค่อยเอาเฉพาะสาเหตุและวิธีแก้กลับมา

สิ่งสำคัญคือ ห้ามใช้คำยืนยันของระบบเองเป็นเงื่อนไขจบงาน

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

ถ้าสั่งโมเดลตัวเดิมในบริบทเดิมว่า “ตรวจงานของตัวเองหน่อย” มันอาจยืนยันความเข้าใจผิดเดิมซ้ำเป็นครั้งที่สองก็ได้

ดังนั้นโครงสร้างที่แข็งแรงกว่าจะต้องแยก การสร้าง การตรวจ และหลักฐานภายนอก ออกจากกัน

คนไม่จำเป็นต้องอ่านทุกอย่างเอง

แต่ก็ไม่ควรจบแค่คำว่า “ตรวจแล้ว”

พูดแบบบ้าน ๆ คือ:

“ผมไม่ดู คุณไปเช็ก แต่เอาหลักฐานกลับมาด้วย”


ทุกจุดที่สะดุด คือจุดที่ยังมีแรงงานมนุษย์หลงเหลืออยู่

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

ตรงนี้ต้องกดทุกครั้ง

กรณีพิเศษนี้ต้องให้คนตัดสิน

พอล้มเหลวต้องให้คนเปิดบันทึกการทำงาน

หลังเผยแพร่ยังต้องให้คนเช็กเอง

ปกติเรามักคิดว่า “เอาเถอะ ตรงนี้ทำมือก็ได้”

แต่ถ้าเป้าหมายคือทำงานให้น้อยลง นั่นแปลว่าการออกแบบยังไม่เสร็จ

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

พอมองแบบนี้ ความผิดพลาดก็ไม่ใช่แค่อุบัติเหตุ

ถ้างานควรประมวลผล 50 รายการ แต่ทำแค่ 1 แล้วถูกนับว่าสำเร็จ อย่าเพิ่งแก้ด้วยการไปรันอีก 49 รายการ

ต้องถามว่า “ทำไม 1 รายการถึงถูกนับว่าเสร็จปกติได้?”

ถ้าคำแปลเก่าถูกมองว่าเป็นเวอร์ชันล่าสุด ก็อย่าแก้แค่ไฟล์นั้น

ต้องเปลี่ยนระบบให้คำแปลเก่าไม่สามารถผ่านเป็นข้อมูลที่ถูกต้องได้อีก

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


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

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

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

ในฐานะการตรวจทานเชิงเทคนิค นี่ถือว่าอ่อน

แต่ในเชิงบริหาร มีสภาพที่อันตรายกว่านั้นมาก

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

ก่อนทำไม่มีเกณฑ์ แต่พอเห็นผลกลับพูดว่า “ปกติก็ต้องทำแบบนี้อยู่แล้ว”

พอถามก็บอก “คิดเองสิ” พอคิดและทำเองกลับบอก “ใครให้ทำเอง”

ในสภาพแบบนี้ เราไม่ได้เล่นเกมที่ค่อย ๆ เข้าใกล้คำตอบที่ถูกต้องอีกต่อไป เพราะคำตอบที่เรียกว่า “ถูก” ขยับไปเรื่อย ๆ

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

ความรู้ไม่พอสามารถเสริมได้

แต่เกณฑ์ตัดสินที่ขยับไปมาจะทำลายระบบประกันคุณภาพทั้งระบบ


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

แนวคิดดั้งเดิมของกิจกรรมกลุ่มย่อยเพื่อควบคุมและปรับปรุงคุณภาพ หรือ QC Circle คือให้กลุ่มเล็ก ๆ หน้างานปรับปรุงคุณภาพและวิธีทำงานอย่างต่อเนื่อง

สหภาพนักวิทยาศาสตร์และวิศวกรญี่ปุ่นก็อธิบายกิจกรรมนี้ว่าเป็นการควบคุมและปรับปรุงงานอย่างต่อเนื่องโดยคนหน้างาน

ปัญหาไม่ใช่กิจกรรมควบคุมคุณภาพ

ปัญหาเริ่มเมื่อ “การปรับปรุงจริง” ถูกแทนที่ด้วย “ทำให้ดูครบว่าพวกเราได้ทำกิจกรรมควบคุมคุณภาพแล้ว”

ตั้งหัวข้อ

ทำกราฟ

ยัดเรื่องราวเข้าแบบแผนการนำเสนอของกิจกรรมควบคุมคุณภาพ

ทำสไลด์

รับการประเมิน

ปรบมือ

จบ

นี่ไม่ใช่การปรับปรุงอย่างต่อเนื่องแล้ว แต่เป็นการแข่งขันแต่งตัวให้เหมือนกำลังปรับปรุงอย่างต่อเนื่อง

ตรงกันข้าม วงจรที่เกิดเมื่อทำงานกับตัวแทนปัญญาประดิษฐ์กลับดิบกว่ามาก

พัง

หาสาเหตุ

หาเงื่อนไขที่ทำให้เกิดซ้ำ

แก้เงื่อนไขจบหรือวิธีตรวจ

รันใหม่

ยืนยันว่าความผิดพลาดแบบเดิมไม่สามารถแอบผ่านเป็น “สำเร็จ” ได้อีก

ไม่มีสไลด์สวย ๆ

แต่รอบต่อไป งานของคนลดลงจริง

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


รู้ตัวอีกที ก็คล้ายแนวคิด Harness Engineering ของ OpenAI มากแล้ว

เดือนกุมภาพันธ์ 2026 OpenAI เผยแพร่บทความ “Harness Engineering” อธิบายการพัฒนาที่ให้ตัวแทนปัญญาประดิษฐ์และ Codex เป็นแกนหลัก

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

แต่ประเด็นที่น่าสนใจที่สุดไม่ใช่แค่ความเร็ว

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

OpenAI ยังอธิบายว่าเงื่อนไขสำคัญอย่างขอบเขต ความถูกต้อง และความสามารถในการทำซ้ำ ควรถูกบังคับใช้จากส่วนกลาง ขณะที่ตัวแทนปัญญาประดิษฐ์ได้อิสระมากพอภายในขอบเขตนั้น

นี่คล้ายกับวิธีนี้มาก

ไม่ต้องสั่งจุกจิกว่า “จะทำอย่างไร” ทุกขั้น

แต่ต้องชัดว่า “อะไรห้ามพังเด็ดขาด”

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

แรงจูงใจเริ่มต้นอาจง่าย ๆ แค่ “รายละเอียดมันน่ารำคาญ ผมไม่อยากดู” แต่สุดท้ายกลับกลายเป็น การสร้างสภาพแวดล้อมที่ตัวแทนปัญญาประดิษฐ์สามารถเดินต่อเองได้

ไม่ได้อ่านทฤษฎีก่อนแล้วค่อยทำ

แค่เลือกเส้นทางของความขี้เกียจ แล้วดันขึ้นมาถึงภูเขาลูกเดียวกัน

ก็ขำดี


โปรเจกต์ส่วนตัวคือเผด็จการไร้การเมือง ส่วนบริษัทคือรัฐสภา

ในโปรเจกต์ส่วนตัว วิธีนี้แข็งแรงมาก

เจ้าของคือผม

ผู้ใช้คือผม

คนประเมินก็คือผม

คนกำหนดความหมายของคำว่า “สำเร็จ” ก็ผมอีก

ถ้าอยากชนะเกมการ์ด ก็ดูว่าชนะบ่อยขึ้นไหม

ถ้าอยากทำงานน้อยลง ก็ดูว่าต้องมีคนเข้าไปยุ่งน้อยลงหรือไม่

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

มันทำให้ชนะมากขึ้นไหม?

มันทำให้งานของผมน้อยลงไหม?

โปรเจกต์ส่วนตัวคือเผด็จการที่ไม่มีการเมือง

และเผด็จการยังขี้เกียจอีกด้วย ระบบราชการปัญญาประดิษฐ์จึงค่อย ๆ ทำทุกอย่างให้เป็นอัตโนมัติ

ในบริษัท เรื่องไม่ง่ายแบบนั้น

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

Harvard Business Review ตอนพูดถึงการนำปัญญาประดิษฐ์เข้าองค์กรในปี 2025 ก็สรุปอุปสรรคสำคัญไว้ที่ คน กระบวนการ และการเมือง ไม่ใช่แค่เรื่องเทคโนโลยี

ในโปรเจกต์ส่วนตัว กำหนดสภาพที่ต้องการแล้วให้ระบบปัญญาประดิษฐ์หาวิธีไปให้ถึงได้เลย

ในบริษัท แม้แต่การตกลงว่า “สภาพที่ควรเป็น” คืออะไร ก็เป็นการเจรจาแล้ว

และไม่ใช่การเมืองทุกอย่างจะไร้เหตุผล

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

แต่การเก็บไว้เพียงเพราะใครบางคนไม่อยากเสียอำนาจอนุมัติ ก็เป็นอีกเรื่อง

สำหรับระบบปัญญาประดิษฐ์ ทั้งสองกรณีดูเหมือนกันหมด: “ต้องมีการอนุมัติจากคน”

ข้อจำกัดนั้นจำเป็นจริงหรือไม่ สุดท้ายยังเป็นปัญหาของสังคมมนุษย์


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

ในยุคปัญญาประดิษฐ์ ไม่แน่ว่าคนจำเป็นต้องออกแบบทุกขั้นตอน ทำทุกอย่างเอง แล้วตรวจทุกอย่างด้วยตัวเองอีกต่อไป

กำหนดเป้าหมาย

ให้ระบบสร้างสภาพเป้าหมายและเกณฑ์

ให้ระบบลงมือทำ

ให้ระบบตรวจ

เทียบกับหลักฐานภายนอก

ถ้าพัง เปลี่ยนความพังนั้นเป็นกฎสำหรับรอบหน้า

ถ้ายังเหลืองานคน ก็เอาจุดนั้นเป็นเป้าหมายปรับปรุงต่อไป

ถ้าวงจรนี้ทำงานได้อย่างเสถียร ความจำเป็นที่มนุษย์ต้องรู้รายละเอียดการนำไปใช้ทุกจุดก็ลดลงมาก

แต่ยังมีสองคำถามที่ยากจะมอบให้ระบบปัญญาประดิษฐ์ทั้งหมด:

จริง ๆ แล้วเราอยากทำอะไรให้สำเร็จ?

เป้าหมายนั้นตรงกับความจริงหรือไม่?

ดังนั้นการแบ่งบทบาทในอนาคตอาจค่อย ๆ กลายเป็น:

มนุษย์: กำหนดเป้าหมาย และมองความจริง

ปัญญาประดิษฐ์: เติมทุกอย่างที่อยู่ตรงกลาง

ในโปรเจกต์ส่วนตัว สบายมาก

พอเข้าองค์กร รัฐสภาเปิดประชุม

การเมืองยังแข็งแกร่งเหมือนเดิม


Mendoi-chan

ผู้เขียน

Mendoi-chan

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

เกี่ยวกับเว็บไซต์