REA (Reverse Engineer Anything): ให้ AI วิเคราะห์ซอฟต์แวร์จากหลักฐาน พร้อม Workshop

• 1. REA คืออะไร
• 2. ทำไมจึงน่าสนใจสำหรับ Software Engineering
• 3. แบ่งหน้าที่ระหว่าง Agent, MCP และ REA
• 4. วิเคราะห์อะไรได้บ้าง
• 5. Static analysis กับ Runtime analysis
• 6. ติดตั้งและเชื่อมต่อกับ Agent
  • 6.1 เตรียมสภาพแวดล้อม
  • 6.2 เรียก Setup
  • 6.3 ตรวจสอบการเชื่อมต่อ
  • 6.4 ใช้งานผ่าน CLI
• 7. Workshop: ค้นหากฎค่าจัดส่งจากแอปตัวอย่าง
  • ขั้นที่ 1: สร้างเป้าหมาย
  • ขั้นที่ 2: ขอให้ Agent ตรวจสอบ
  • ขั้นที่ 3: ตรวจข้อสรุปกับหลักฐาน
  • ขั้นที่ 4: สร้างกรณีทดสอบขอบเขต
  • ขั้นที่ 5: ส่งรายงานหนึ่งหน้า
• 8. รูปแบบ Prompt ที่นำไปใช้กับงานจริงได้
  • ทำความเข้าใจระบบเก่า
  • เตรียมย้ายระบบ
  • ตรวจคำตอบของ Agent
• 9. ข้อจำกัดที่มีผลต่อการใช้งาน
• แหล่งอ้างอิง

#1. REA คืออะไร

REA — Reverse Engineer Anything เป็นเครื่องมือโอเพนซอร์สที่เชื่อม AI coding agent กับเครื่องมือสำหรับตรวจสอบซอฟต์แวร์ ผ่าน MCP (Model Context Protocol) และมี CLI สำหรับสั่งงานจากเทอร์มินัล ชื่อแพ็กเกจบน npm คือ rea-agents โครงการหลักอยู่ที่ morluto/rea และเว็บไซต์ทางการคือ rea.tools

ตัวอย่างโจทย์คือ “แอปนี้ส่งออกข้อมูลอย่างไร ฟังก์ชันใดเกี่ยวข้อง และมีหลักฐานอยู่ตรงไหน” Agent ใช้ REA ตรวจสอบเป้าหมาย แล้วนำผลมาวิเคราะห์หรือเขียน implementation สำหรับโครงการของเรา [1]

โค้ดของ REA ใช้สัญญาอนุญาต MIT ส่วนเครื่องมือภายนอกที่นำมาเชื่อมต่อมีเงื่อนไขของตนเอง [5]

#2. ทำไมจึงน่าสนใจสำหรับ Software Engineering

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

แนวทางที่เหมาะกับการใช้ REA คือเริ่มจากพฤติกรรมเล็ก ๆ เช่น การคำนวณค่าจัดส่ง การสร้างไฟล์ CSV หรือการติดต่อระหว่างส่วน UI กับส่วนประมวลผล แล้วให้ agent ตอบพร้อมหลักฐานที่ตรวจสอบย้อนกลับได้

ประโยชน์ที่เสนอสำหรับการสอนและการพัฒนา ได้แก่

• Program comprehension: ฝึกอธิบายเส้นทางข้อมูลและเงื่อนไขตัดสินใจ
• Legacy modernization: เก็บกฎธุรกิจก่อนเปลี่ยนเทคโนโลยี
• Regression testing: เปลี่ยนข้อค้นพบให้เป็นกรณีทดสอบ โดยเฉพาะค่าบริเวณขอบเขต
• Architecture recovery: สร้างภาพความสัมพันธ์ของโมดูลจากสิ่งที่ตรวจพบ
• Debugging: ใช้อาการผิดพลาดเป็นจุดตั้งต้น แล้วติดตามโค้ดที่อาจเกี่ยวข้อง

รายการนี้เป็นแนวทางประยุกต์ของผู้เขียน ไม่ใช่ผลการทดลองประสิทธิภาพของ REA

#3. แบ่งหน้าที่ระหว่าง Agent, MCP และ REA

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

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

#4. วิเคราะห์อะไรได้บ้าง

เอกสารโครงการระบุเป้าหมายหลายประเภท ตารางนี้คัดเฉพาะกลุ่มที่เหมาะกับการเริ่มเรียนรู้ [1]

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

#5. Static analysis กับ Runtime analysis

Static analysis อ่านสิ่งที่มีอยู่ในไฟล์ ส่วน runtime analysis สังเกตสิ่งที่เกิดขึ้นระหว่างทำงาน เอกสารระบุว่า static JavaScript และ .NET inspection ไม่รันแอปเป้าหมาย [1]

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

#6. ติดตั้งและเชื่อมต่อกับ Agent

#6.1 เตรียมสภาพแวดล้อม

ตรวจสอบ Node.js และ npm:

node -v
npm -v

ใช้ Node.js รุ่นที่ตรงกับข้อกำหนดของ REA release ที่เลือก เอกสาร Get started ที่ตรวจสอบระบุสาย 22.x, 24.x และ 26+ พร้อมขั้นต่ำระดับ patch ที่ต่างกัน จึงควรตรวจสอบ ข้อกำหนดปัจจุบัน ก่อนติดตั้ง [2]

#6.2 เรียก Setup

เปิดเทอร์มินัลในโฟลเดอร์ทำงานที่เชื่อถือได้ แล้วรัน:

npx rea-agents@latest setup

เลือก client อ่านแผนการเปลี่ยน configuration และยืนยันผ่าน setup จากนั้นปิดและเปิด agent ใหม่ การติดตั้งเชื่อม MCP พร้อม workflow instructions ที่ตรงกัน [2]

เลือก client โดยตรงได้ เช่น:

npx rea-agents@latest setup --client codex

หรือ:

npx rea-agents@latest setup --client claude_code

สำหรับ Windows PowerShell หากติดข้อจำกัดการเรียกสคริปต์ ให้ใช้ npx.cmd ตามเอกสาร [2]

#6.3 ตรวจสอบการเชื่อมต่อ

npx -y rea-agents@latest doctor --client codex --json

เปลี่ยน codex เป็น ID ของ client ที่เลือก จากนั้นถาม agent ว่า:

ตรวจสอบว่า REA เชื่อมต่อแล้ว และแสดงเครื่องมือ REA ที่เรียกใช้ได้ใน session นี้

หากไม่พบเครื่องมือ ให้ restart/reconnect และอ่านรายละเอียดจาก doctor ก่อนติดตั้งซ้ำ [3]

#6.4 ใช้งานผ่าน CLI

คำสั่งสำหรับโฟลเดอร์ JavaScript/Electron หรือไฟล์ ASAR ตามคู่มือ CLI [4]:

npx -y rea-agents@latest analyze-javascript-application \
  /absolute/path/to/app --json > app-evidence.json

ไฟล์ผลอาจมีขนาดใหญ่ ควรเก็บผลฉบับเต็มแล้วเลือกอ่านส่วนที่เกี่ยวข้อง การเรียก CLI แต่ละครั้งเป็น process ใหม่ จึงควรบันทึกผลหากจะใช้ต่อ [4]

บทความใช้ @latest เพื่อให้อ่านคำสั่งเริ่มต้นได้ง่าย สำหรับการอบรมหลายเครื่องหรืองานวิจัย ควรตรึงเวอร์ชันเดียวกันหลังจากผู้สอนได้ทดลองแล้ว และบันทึกเวอร์ชัน agent, model, provider และระบบปฏิบัติการด้วย

#7. Workshop: ค้นหากฎค่าจัดส่งจากแอปตัวอย่าง

เวลาที่เสนอ: 45–60 นาที

ตัวอย่างต่อไปนี้ผู้เขียนออกแบบขึ้นเพื่อการเรียนรู้ ใช้โค้ดของเราเอง และไม่มี dependency ภายนอก จุดประสงค์คือฝึกไล่เงื่อนไขจากหลักฐานไปสู่การทดสอบ ไม่ใช่สาธิตการถอด native binary

#ขั้นที่ 1: สร้างเป้าหมาย

สร้างโฟลเดอร์ rea-lab/target และใส่สามไฟล์ต่อไปนี้

ไฟล์ target/package.json:

{
  "name": "rea-shipping-lab",
  "version": "1.0.0",
  "private": true,
  "type": "module",
  "main": "main.mjs"
}

ไฟล์ target/rules.mjs:

export function quote(subtotal, discount = 0) {
  if (
    !Number.isFinite(subtotal) ||
    !Number.isFinite(discount) ||
    subtotal < 0 ||
    discount < 0 ||
    discount > subtotal
  ) {
    throw new RangeError('Invalid amount');
  }

  const net = subtotal - discount;
  const shipping = net >= 1000 ? 0 : 50;
  return { net, shipping, total: net + shipping };
}

ไฟล์ target/main.mjs:

import { quote } from './rules.mjs';

const subtotal = Number(process.argv[2] ?? 1200);
const discount = Number(process.argv[3] ?? 250);
console.log(JSON.stringify(quote(subtotal, discount)));

ผู้สอนสามารถเตรียมโฟลเดอร์นี้ล่วงหน้าและมอบให้ผู้เรียนเฉพาะโจทย์ โดยเก็บเฉลยและชุดทดสอบไว้นอก target

#ขั้นที่ 2: ขอให้ Agent ตรวจสอบ

แทนที่ path ด้วยตำแหน่งจริงของ target:

ใช้ REA วิเคราะห์ JavaScript application ที่ /absolute/path/to/rea-lab/target
โดยเริ่มจาก static analysis

ตอบคำถาม:
1. โปรแกรมรับข้อมูลอะไร และส่งต่อไปยังฟังก์ชันใด
2. เงื่อนไขส่งฟรีใช้ยอดก่อนหรือหลังส่วนลด
3. ถ้ายอดซื้อ 1,200 และส่วนลด 250 ค่าจัดส่งและยอดรวมควรเป็นเท่าไร
4. ข้อมูลลักษณะใดทำให้เกิดข้อผิดพลาด

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

หากใช้ CLI ให้ส่ง absolute path เดียวกันเข้าคำสั่ง analyze-javascript-application ในหัวข้อก่อนหน้า แล้วให้ agent ตรวจสอบผลที่บันทึกไว้

#ขั้นที่ 3: ตรวจข้อสรุปกับหลักฐาน

คำตอบที่คาดหวังจากโค้ดตัวอย่างคือเกณฑ์ส่งฟรีใช้ยอดหลังส่วนลด เพราะคำนวณ net ก่อนตรวจ net >= 1000 กรณี 1,200 ลด 250 จึงเหลือ 950 ค่าจัดส่ง 50 และยอดรวม 1,000

นี่คือ ผลที่อนุมานจากโค้ดตัวอย่าง ไม่ใช่รายงานผลที่ได้จากการรัน REA ในบทความนี้

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

#ขั้นที่ 4: สร้างกรณีทดสอบขอบเขต

หลังเก็บคำตอบรอบแรกแล้ว สร้าง rea-lab/quote.test.mjs นอกโฟลเดอร์ target:

import test from 'node:test';
import assert from 'node:assert/strict';
import { quote } from './target/rules.mjs';

test('below free-shipping threshold', () => {
  assert.deepEqual(quote(999), {
    net: 999, shipping: 50, total: 1049
  });
});

test('exact free-shipping threshold', () => {
  assert.deepEqual(quote(1000), {
    net: 1000, shipping: 0, total: 1000
  });
});

test('discount changes shipping eligibility', () => {
  assert.deepEqual(quote(1200, 250), {
    net: 950, shipping: 50, total: 1000
  });
});

test('invalid amounts are rejected', () => {
  for (const args of [[100, 101], [-1, 0], [NaN, 0]]) {
    assert.throws(() => quote(...args), RangeError);
  }
});

รันจากโฟลเดอร์ rea-lab:

node --test quote.test.mjs

ถ้าต้องการต่อยอด ให้ผู้เรียนสร้าง implementation ใหม่ในโฟลเดอร์แยก แล้วนำกรณีทดสอบเดียวกันไปตรวจ โดยไม่เปลี่ยน expected values เพื่อให้การทดสอบผ่าน

#ขั้นที่ 5: ส่งรายงานหนึ่งหน้า

#8. รูปแบบ Prompt ที่นำไปใช้กับงานจริงได้

#ทำความเข้าใจระบบเก่า

ใช้ REA ตรวจสอบเป้าหมาย [absolute path]
ติดตามเฉพาะฟีเจอร์ [ชื่อฟีเจอร์]
อธิบาย input, validation, transformation และ output
ให้หลักฐานของแต่ละขั้น และระบุส่วนที่ยังไม่ครอบคลุม
จัดทำรายการกรณีทดสอบสำหรับรักษาพฤติกรรมเดิม

#เตรียมย้ายระบบ

จากข้อค้นพบที่มีหลักฐาน ให้เขียน behavioral specification ของฟีเจอร์นี้
แยกกฎธุรกิจออกจากรายละเอียดเทคโนโลยี
ระบุ boundary cases, error cases และสมมติฐานที่ต้องทดลองเพิ่ม
เสนอ acceptance tests ก่อนเริ่มเขียน implementation ใหม่

#ตรวจคำตอบของ Agent

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

#9. ข้อจำกัดที่มีผลต่อการใช้งาน

Pseudocode ต้องผ่านการตรวจสอบ: การได้โค้ดที่อ่านง่ายขึ้นยังไม่ยืนยันว่าเทียบเท่าซอฟต์แวร์ต้นฉบับครบทุกกรณี โดยเฉพาะส่วนที่ถูก optimize, obfuscate หรือสร้างขึ้นขณะทำงาน เอกสารอธิบายว่า native analysis ให้ assembly และ pseudocode ส่วน JavaScript analysis ให้ข้อมูลโมดูลและตำแหน่งที่เกี่ยวข้อง [3]

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

Local analysis กับการใช้โมเดลเป็นคนละส่วน: REA ตรวจสอบเป้าหมายในเครื่อง แต่ agent ได้รับผลเครื่องมือ และนโยบายข้อมูลของผู้ให้บริการโมเดลยังมีผลกับผลเหล่านั้น [3]

แยกเวอร์ชันเอกสารกับแพ็กเกจ: ฟีเจอร์บน main อาจยังไม่อยู่ใน npm release ที่ติดตั้ง ควรเก็บเวอร์ชันที่ใช้คู่กับรายงานและผลทดสอบ

ใช้ตัวอย่างที่สร้างเองหรือซอฟต์แวร์ที่ได้รับอนุญาตให้ตรวจสอบ เพื่อให้แชร์หลักฐานและจัดการเรียนรู้ได้สะดวก

#แหล่งอ้างอิง

1. REA official repository — ภาพรวมและชนิดเป้าหมาย
2. REA Get started — การติดตั้งและเชื่อมต่อ client
3. REA FAQ — การวิเคราะห์ การแก้ปัญหา และข้อมูล
4. REA CLI and Evidence — คู่มือจาก repository ทางการ
5. REA MIT License