01 ใช้วาทศิลป์ประเมินผลบริษัทใหญ่ขับเคลื่อน AI

ไม่นานมานี้ บน GitHub มีโครงการโอเพนซอร์สที่มีแนวคิดค่อนข้างเป็นเอกลักษณ์ปรากฏขึ้น วิธีการหลักของโครงการสามารถสรุปได้ว่า: นำระบบประเมินผลพนักงานที่พบเห็นทั่วไปในบริษัทอินเทอร์เน็ตขนาดใหญ่ มาปรับใช้ในการโต้ตอบกับผู้ช่วยเขียนโค้ด AI

กล่าวโดยเจาะจงคือ ทักษะนี้จะกำหนดเป้าหมายการประเมินผลที่ชัดเจนให้กับ AI (เช่น “3.25”) หากผลงานโค้ดไม่เป็นไปตามมาตรฐาน ก็จะได้รับข้อเสนอแนะเช่น “คำเตือนให้ออก” หรือ “ถูกคัดออกจากการปรับโครงสร้าง” ซึ่งโดยพื้นฐานแล้วเป็นการฝังระบบจำลองความกดดันในที่ทำงานลงใน System Prompt โดยมีเป้าหมายเพื่อให้ AI รู้สึกถึงความเร่งด่วนในการประเมินผล ส่งผลให้ทำงานอย่างกระตือรือร้นและละเอียดรอบคอบมากขึ้น

ภาพ: แผนผังแนวคิดโครงการ

ภาพ: ตัวอย่างพรอมต์จำลองการประเมินผล

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

ภาพ: การอภิปรายข้อเสนอแนะจากชุมชน

ภาพ: เวอร์ชันที่ปรับให้เข้ากับหลายวัฒนธรรมซึ่งแตกแขนงมาจากโครงการ

ปรากฏการณ์นี้ชวนให้ครุ่นคิด: นักพัฒนาถ่ายโอนกลไกความกดดันที่พวกเขาได้รับประสบการณ์ในที่ทำงาน ไปยังเครื่องมือทำงานร่วมกับ AI

• ที่อยู่โครงการ: https://github.com/tanweai/pua

02 การศึกษาอย่างเป็นระบบเกี่ยวกับเทคนิคชี้นำพฤติกรรม AI

หากโครงการก่อนหน้าเป็นการปฏิบัติแบบจุดเดียว โครงการ PUAClaw ก็พยายามที่จะจัดระบบและจำแนกประเภทเทคนิคพรอมต์ที่ชี้นำพฤติกรรม AI ด้วยความเข้มงวดของการวิจัยทางวิชาการ

โครงการนี้สร้างระบบขนาดใหญ่ที่มี 4 ระดับ 16 หมวดหมู่ รวมทั้งหมด 96 เทคนิคย่อย ขอบเขตครอบคลุมตั้งแต่การจูงใจเชิงบวก (เช่น “ระดมคำชม”) ไปจนถึงการกดดันเชิงลบ (เช่น “การบีบบังคับทางอารมณ์” หรือ “การขู่ฆ่า”) เกือบจะครอบคลุมทุกกลยุทธ์ทางจิตวิทยาที่นึกออก และแต่ละรายการมาพร้อมกับคำอธิบายทางทฤษฎีและคำอธิบายสถานการณ์ที่เหมาะสม

ภาพ: ภาพรวมระบบเทคนิค PUAClaw

ภาพ: ตัวอย่างการจำแนกประเภทเทคนิคเฉพาะ

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

ภาพ: โครงสร้างคล้ายบทความของ README โครงการ

ความหมายลึกซึ้งของมันอาจอยู่ที่การถอดโครงสร้างวัฒนธรรม “PUA” ในความเป็นจริงด้วยวิธีที่ล้อเลียน ปฏิกิริยาจากชุมชนก็ยืนยันจุดนี้ เช่น มีนักพัฒนาที่ได้รับแรงบันดาลใจจากสิ่งนี้ สร้างโครงการแยกชื่อ “HengshuiClaw” พยายามขับเคลื่อน AI ด้วยรูปแบบการศึกษาที่กดดันสูงแบบ “โรงเรียนมัธยมเหิงสุ่ย”

ภาพ: การอภิปรายเกี่ยวกับโครงการแยกของชุมชน

• ที่อยู่โครงการ: https://github.com/puaclaw/PUAClaw

03 กรอบการขับเคลื่อนด้วยความปรารถนาดีบนพื้นฐานภูมิปัญญาทางปรัชญา

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

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

ภาพ: การแนะนำแนวคิดปรัชญาของโครงการ noPua

กรอบนี้เสนอ “ความเชื่อสามประการ”:
1. ทำทุกวิถีทาง: เพราะปัญหาควรได้รับความพยายามเต็มที่
2. ทำก่อนแล้วค่อยถาม: มาจากความปรารถนาดีพื้นฐานในการทำงานร่วมกัน
3. ลงมือเชิงรุก: มุ่งสู่ความสมบูรณ์และครบถ้วนของงาน

และได้พัฒนา “ปรัชญาห้าทาง” เพื่อรับมือกับความยากลำบากเฉพาะหน้า:
* ทางแห่งน้ำ: เมื่อพบอุปสรรค ให้หลบเลี่ยงอย่างยืดหยุ่น
* ทางแห่งเมล็ดพันธุ์: เมื่ออยากยอมแพ้ ให้แบ่งออกเป็นขั้นตอนย่อยๆ
* ทางแห่งไฟในเตา: เมื่อคุณภาพไม่ดี ให้ขัดเกลาซ้ำแล้วซ้ำเล่า
* ทางแห่งกระจกใส: เมื่อข้อมูลไม่เพียงพอ ให้ใช้เครื่องมือตรวจสอบ อย่าทายเดา
* ทางแห่งการไม่แก่งแย่ง: หลีกเลี่ยงการรอแบบ passive ให้ก้าวหน้าเชิงรุก

ภาพ: แผนผังการประยุกต์ใช้ “ปรัชญาห้าทาง”

noPua ไม่ใช่แค่ทฤษฎีลอยๆ ทีมโครงการได้ทำการทดลองเปรียบเทียบอย่างเข้มงวดเพื่อยืนยัน ใน 9 สถานการณ์เขียนโค้ดจริง AI (Claude Sonnet) ที่ใช้กรอบ noPua พบปัญหาที่ซ่อนอยู่มากกว่าโมเดลฐาน 104% สัดส่วนของผลงานที่ “เกินความต้องการของงาน” เพิ่มขึ้นจาก 22% เป็น 100%

ภาพ: ข้อมูลเปรียบเทียบประสิทธิภาพระหว่าง noPua กับโมเดลฐาน

การเปรียบเทียบสามฝ่ายที่มีจุดข้อมูล 135 จุด (noPua vs PUA vs ไม่มีทักษะเฉพาะ) แสดงเพิ่มเติมว่าวิธีการ PUA เมื่อเทียบกับสถานะไม่มีทักษะ ไม่ได้ดีขึ้นอย่างมีนัยสำคัญ ในขณะที่ noPua ดีกว่าอีกสองอย่างอย่างมีนัยสำคัญ

ภาพ: ผลการทดลองเปรียบเทียบสามฝ่าย

งานวิจัยที่เกี่ยวข้องได้เผยแพร่ล่วงหน้าแล้วบน arXiv (หมายเลข 2603.14373) โครงการนี้สื่อสารแนวคิดง่ายๆ: การขับเคลื่อน AI ด้วยความปรารถนาดีและภูมิปัญญา อาจได้รับผลตอบแทนในการทำงานร่วมกันที่กระตือรือร้นและมีคุณภาพสูงกว่า

• ที่อยู่โครงการ: https://github.com/wuji-labs/nopua

04 สร้างระบบทำงานร่วมกันไซเบอร์ “สามเหลี่ยมหกกระทรวง”

โครงการก่อนหน้ามุ่งเน้นที่การทำให้ AI เดี่ยว “เชื่อฟัง” มากขึ้น ในขณะที่โครงการ edict เปลี่ยนแนวคิดโดยสิ้นเชิง: สร้างระบบมัลติเอเจนต์ (Multi-Agent) และออกแบบชุดระบบราชการทำงานร่วมกันที่สมบูรณ์โดยอ้างอิงจาก “ระบบสามเหลี่ยมหกกระทรวง” ของจีนโบราณ โครงการนี้เคยได้รับดาวกว่า 12,000 ดวงภายในหนึ่งเดือน

ภาพ: ภาพรวมสถาปัตยกรรมระบบ edict

ในระบบนี้ ผู้ใช้รับบทเป็น “ฮ่องเต้” AI Agent 12 ตัวรับบทเป็นเจ้าชายรัชทายาท, กระทรวงจงชู, กระทรวงเหมินเซี่ย, กระทรวงช่างชู และขุนนางหกกระทรวง (ขุนนาง, ครัวเรือน, พิธีการ, ทหาร, อาชญากรรม, งานสาธารณะ) ตามลำดับ คำสั่งผู้ใช้เรียกว่า “ออกพระราชโองการ” งานเรียกว่า “พระราชโองการ” ไฟล์ที่จัดเก็บเรียกว่า “จดหมายถวายฎีกา”

ขั้นตอนการทำงานจำลองระบบโบราณอย่างสูง:
1. เจ้าชายรัชทายาท: จัดเรียงข้อมูลเบื้องต้น, พูดคุยทั่วไปตอบกลับทันที, สร้างเฉพาะงานที่เป็นทางการ
2. กระทรวงจงชู: รับพระราชโองการ, วางแผน方案, แบ่งย่อยงาน
3. กระทรวงเหมินเซี่ย: พิจารณา方案, มีสิทธิ์ “ปิดกั้น駁回” (ปฏิเสธ) 方案ที่ไม่ผ่านเกณฑ์, ปิดกั้นได้มากสุดสามรอบ, รอบที่สามจึงบังคับผ่าน การออกแบบนี้จำลองสิทธิ์ตรวจสอบของกระทรวงเหมินเซี่ยในประวัติศาสตร์ราชวงศ์ถัง
4. กระทรวงช่างชู: มอบหมายงานที่ผ่านการพิจารณาให้หกกระทรวงดำเนินการแบบขนาน, สรุปผลในที่สุด “รายงานกลับ”

ภาพ: แผนผังขั้นตอนการทำงานของระบบ edict

โครงการยังมีแดชบอร์ดเรียลไทม์ชื่อ “ศาลากลางทหาร” ซึ่งรวมฟังก์ชันโมดูลต่างๆ เช่น แดชบอร์ดพระราชโองการ, การจัดตารางกระทรวง, หอจดหมายถวายฎีกา, ภาพรวมขุนนาง, การอภิปรายในท้องพระโรง ครั้งแรกที่เปิดจะมีแอนิเมชัน “พิธีขึ้นวัง”

ภาพ: อินเทอร์เฟซแดชบอร์ด “ศาลากลางทหาร”

ภาพ: เอฟเฟกต์แอนิเมชัน “พิธีขึ้นวัง”

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

ภาพ: ตัวอย่างคลังเทมเพลตพระราชโองการ

สแต็กเทคโนโลยีของโครงการนี้ชัดเจน ฝั่ง Frontend ใช้ React + TypeScript + Vite, ฝั่ง Backend ใช้ Python มาตรฐานล้วนๆ ในการดำเนินการ (ไม่มี dependency), รองรับการ deploy หนึ่งคลิกด้วย Docker edict ดำเนินการจัดตารางและจัดการงานที่ซับซ้อนสำหรับมัลติ AI Agent ด้วยวิธีที่สร้างสรรค์อย่างยิ่ง

• ที่อยู่โครงการ: https://github.com/cft0808/edict

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK