Reverse Engineering Anything – ถ้า AI แกะระบบได้ แล้วเรายังต้องเขียนทุกอย่างใหม่อยู่ไหม?

REA หรือ Reverse Engineer Anything คือ เครื่องมือโอเพนซอร์สที่ช่วยให้ผู้ช่วย AI อย่าง Claude Code และ Codex ใช้เครื่องมือวิเคราะห์ซอฟต์แวร์ผ่าน MCP เพื่อศึกษาการทำงานและรวบรวมหลักฐาน โดยไม่ได้รับประกันว่าจะกู้คืนโค้ดต้นฉบับได้ครบทั้งหมด

เคยใช้แอปแล้วเจอฟีเจอร์ที่ทำให้คิดว่า “อยากให้ระบบของเราทำแบบนี้ได้บ้าง” ไหม?

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

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

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

REA คืออะไร? ลองนึกถึงการตามรอยการทำงานของแอป

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

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

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

REA เชื่อมผู้ช่วย AI เข้ากับเครื่องมือสำหรับสำรวจข้อมูลเหล่านี้ จากนั้น AI ช่วยเรียบเรียงสิ่งที่พบให้ทีมตรวจสอบต่อได้ (แหล่งที่มา ข้อมูลโครงการ REA)

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

การ “แกะระบบ” จึงไม่ได้หมายถึงการได้โค้ดต้นฉบับกลับมาครบทุกบรรทัด

REA ทำงานร่วมกับ Claude Code และ Codex อย่างไร?

สมมติว่าเราอยากรู้ว่า “เมื่อกดปุ่มนี้ ข้อมูลถูกส่งไปที่ไหน?”

เราเป็นคนกำหนดคำถามและขอบเขต จากนั้น Claude Code หรือ Codex ซึ่งเป็นผู้ช่วย AI สำหรับงานพัฒนาซอฟต์แวร์ จะช่วยวางแผนและเรียกใช้เครื่องมือของ REA

การติดต่อระหว่าง AI กับเครื่องมือทำผ่าน MCP หรือ Model Context Protocol ในที่นี้จำง่าย ๆ ว่าเป็นมาตรฐานการเชื่อมต่อ ส่วนการตรวจสอบซอฟต์แวร์จริงเป็นหน้าที่ของเครื่องมือที่ถูกเรียกใช้

เมื่อได้ผลกลับมา AI จะช่วยอธิบายสิ่งที่พบ หรือเสนอว่าควรตรวจสอบอะไรต่อ โดยทีมพัฒนายังคงเป็นผู้ตรวจสอบความถูกต้อง (ลำดับการทำงานของ REA)

REA ทำงานอย่างไร: จากคำถามสู่การวิเคราะห์

1. ตั้งคำถาม นักพัฒนา / ทีมงาน กำหนดว่าอยากรู้อะไร และอนุญาตให้ตรวจสอบส่วนไหน
2. AI ช่วยวางแผน Claude Code / Codex เลือกเรียกเครื่องมือที่เชื่อมต่อไว้ และช่วยอธิบายผล
3. เชื่อมต่อเครื่องมือ MCP ส่งคำขอและรับผลจากเครื่องมือ ไม่ได้วิเคราะห์ซอฟต์แวร์เอง
4. ลงมือวิเคราะห์ REA tools ตรวจสอบซอฟต์แวร์ตามความสามารถและสิทธิ์ที่มี

REA วิเคราะห์อะไรได้บ้าง และมีข้อจำกัดอะไร?

แม้ชื่อจะเป็น Reverse Engineer Anything แต่ไม่ได้หมายความว่าจะวิเคราะห์ทุกระบบได้ครบทั้งหมด

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

ประเภทซอฟต์แวร์	ตัวอย่างสิ่งที่ศึกษาได้
แอป JavaScript / Electron	โมดูลและการเชื่อมต่อระหว่างส่วนต่าง ๆ
ไฟล์โปรแกรมที่คอมไพล์แล้ว หรือ Native binaries	คำสั่งและความสัมพันธ์ของฟังก์ชัน ผ่านเครื่องมือที่รองรับ
เว็บไซต์	โครงสร้างหน้าเว็บ สคริปต์ และข้อมูลการรับส่งที่สังเกตได้
โปรแกรม .NET	ข้อมูลโครงสร้างและคำสั่งภายในไฟล์โปรแกรม

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

วิธีเริ่มต้นที่ช่วยให้ทำงานต่อได้ง่ายกว่าคือ ตั้งคำถามให้เล็กและชัดก่อน

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

ตัวอย่าง REA: แค่กด Copy ใน Notion เบื้องหลังมีอะไรเกิดขึ้น?

บนหน้าจอ การคัดลอกข้อมูลดูเป็นเรื่องง่าย เราเลือกข้อความ กด Copy แล้วนำไปวางที่อื่น

แต่เบื้องหลังอาจมีหลายส่วนของแอปส่งต่องานกัน ก่อนข้อมูลจะพร้อมใช้งาน

กรณีศึกษาที่โครงการ REA เผยแพร่ได้ตามรอย Clipboard หรือพื้นที่พักข้อมูลที่คัดลอกไว้ใน Notion โดยตรวจสอบเส้นทางจาก Renderer ผ่าน Preload และ IPC ไปยัง Main Process (กรณีศึกษา Notion)

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

ภาพด้านล่างช่วยย่อเส้นทางนั้นให้เห็นง่ายขึ้น

ตามรอยงานเบื้องหลังการกด Copy

1. เริ่มจากส่วนแสดงผล Renderer ส่วนที่แสดงหน้าจอเริ่มเรียกใช้งาน Clipboard
2. ผ่านชั้นตัวกลาง Preload เปิดทางให้ส่วนแสดงผลเรียกใช้ความสามารถของแอป
3. ส่งข้อความต่อ IPC ส่งคำขอระหว่างส่วนการทำงานที่แยกจากกัน
4. รับไปจัดการต่อ Main Process กระบวนการหลักรับคำขอเพื่อจัดการงาน Clipboard

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

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

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

ใช้ REA แล้ว ยังต้องเขียนโค้ดใหม่ไหม?

หลายกรณีก็ยังต้องเขียน แต่เราอาจรู้ชัดขึ้นว่าควรเขียนอะไร

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

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

สิ่งที่เรียนรู้จากการวิเคราะห์จึงต้องผ่านการออกแบบให้เหมาะกับบริบทของเราอีกครั้ง

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

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

ก่อนนำผลวิเคราะห์ไปใช้ ลองถาม AI อีกสามข้อ

คำอธิบายที่ฟังดูมั่นใจอาจยังมีส่วนที่ต้องตรวจสอบ ลองถามต่อว่า

• พบอะไรจริง ๆ?
• มีหลักฐานตรงไหนรองรับ?
• ยังมีอะไรที่ไม่รู้หรือยังไม่ได้ตรวจสอบ?

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

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

REA กับ Reverse Engineering Anything เป็นชื่อเดียวกันไหม?

หากหมายถึงโครงการที่กล่าวถึงในบทความนี้ ชื่อทางการคือ REA หรือ Reverse Engineer Anything

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

จากการเข้าใจระบบเดิม สู่การสร้างสิ่งที่เหมาะกับเรา

REA ทำให้เห็นว่า AI ในงานพัฒนาซอฟต์แวร์ช่วยได้มากกว่าการเขียนโค้ด มันยังช่วยเราสำรวจสิ่งที่มีอยู่ และค่อย ๆ หาคำตอบจากหลักฐาน

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

เพราะหลังจากรู้ว่าระบบเดิมทำงานอย่างไร เรายังต้องตอบคำถามสำคัญอีกข้อว่า “แล้วระบบของเราควรทำงานอย่างไร?”

เข้าใจสิ่งที่มี ก่อนเลือกว่าจะสร้างอะไรต่อ

1. ระบบเดิม Existing Software เริ่มจากซอฟต์แวร์ที่อยากทำความเข้าใจ
2. วิเคราะห์ Analyze ตรวจสอบและรวบรวมหลักฐาน
3. ทำความเข้าใจ Understand เชื่อมโยงสิ่งที่พบ และตรวจสอบว่ายังขาดอะไร
4. ออกแบบ Design เลือกแนวทางที่เหมาะกับงานของเรา
5. พัฒนาต่อ Build สร้าง ทดสอบ และปรับปรุงให้ใช้งานได้จริง

สำหรับองค์กรที่กำลังปรับปรุงระบบเดิมหรือพัฒนาระบบใหม่ Ayodia ให้ความสำคัญกับการทำความเข้าใจโจทย์ธุรกิจ ควบคู่กับการออกแบบและพัฒนาซอฟต์แวร์ เพื่อให้แนวทางที่เลือกเหมาะกับการใช้งานจริง