แก่นของเรื่อง
หัวข้อร่วมของทุกแหล่งคือ แบ่งงานให้ AI ตามบทบาทที่แยกกันชัด แล้วให้มีขั้นตรวจก่อนผลงานถูกใช้จริง ไม่ใช่ใช้ AI ตัวเดียวทำทุกอย่างแล้วเชื่อผลทันที
แก่นความคิด
| ส่วน |
เนื้อหา |
ที่มา |
| แก่นความคิด |
AI รับงานที่กินเวลา (ค้นข้อมูล ร่าง โค้ด ทดสอบ) คนคุมทิศทางและคุณภาพ |
Source 1, Source 3, Source 4 |
| ทำไมได้ผล |
แต่ละบทบาทมีขอบเขตเล็ก ตรวจผลได้ และผู้สร้างไม่ตรวจงานตัวเอง จึงลดการเดา |
ตีความจาก Source 3 และ Source 4 |
| 20% ที่สำคัญที่สุด |
(1) กฎมีหลักฐาน (2) ผู้สร้างเห็นแค่สเปก (3) เทสต์ต้องล้มได้ (4) ผู้ใช้มีพื้นฐาน |
Source 3, Source 4, Source 1 |
| รอได้ |
การสมัครเครื่องมือครบทุกตัว การทำคอร์ส การเลือกรุ่นโมเดลให้ละเอียด |
ตีความ |
ภาพรวมของ clean-room
flowchart TD
A[REA อ่านแอป เขียน SPEC.md พร้อมหลักฐาน] --> B{Jev ตรวจทีละกฎ}
B -->|มีหลักฐาน| C[Opus 5.5 ห้อง B สร้างใหม่จาก SPEC.md อย่างเดียว]
B -->|ไม่มีหลักฐาน| A
C --> D[Haiku 5.5 รันเทสต์ต้องผ่าน]
C --> E[Haiku 5.5 รัน 3 เวอร์ชันเจตนาพัง ต้องล้มทั้งหมด]
D --> F[/goal ทำซ้ำจนครบเงื่อนไข]
E --> F
ช่วยให้ดีขึ้นอย่างไร
| สถานการณ์ |
ไม่ใช้วิธีนี้ |
ใช้วิธีนี้ |
วัดอย่างไร |
หลักฐาน |
| ค้นตัวอย่างเว็บคู่แข่งก่อนทำงานลูกค้า |
หาเองทีละเว็บ |
สั่ง Manus ค้นแล้วสรุปลง Notion |
เวลาค้นข้อมูลก่อน/หลัง |
เธอเล่าว่าลดราวครึ่งหนึ่ง (Source 1) ยังไม่ทดสอบโดยบุคคลที่สาม |
| งานเว็บหนึ่งชิ้น |
ลงมือเขียนทุกส่วน |
พิมพ์สั่งบล็อก AI หรือเครื่องมือเขียนโค้ด |
เวลาถึงร่างแรก |
สาธิตว่าได้เว็บทั้งหน้าราว 5 นาที (Source 1) ร่างแรก ไม่ใช่งานส่งมอบ |
| ความจุงานต่อเดือน |
งานติดเพดานที่คนคนเดียวทำได้ |
AI รับงานช่วย |
จำนวนงานต่อเดือน |
เธอเล่าว่า 10-15 งาน รวมงานรีนิวและดูแลต่อ (Source 1) ยังไม่ทดสอบ |
| ต้นทุนแทนจ้างคน |
จ้างพนักงาน |
จ่ายค่าสมาชิก AI |
ต้นทุนต่อเดือนเทียบผลงาน |
ค่าสมาชิก 7 แสนวอน/เดือน (Source 1) ส่วน "แทน 4-5 คน" เป็นคำเล่าเอง ยังไม่ทดสอบ |
| ลดกฎที่เดาขึ้นมาเอง |
ให้ AI เขียนโดยเดา |
ทุกกฎผ่านด่านหลักฐานก่อน |
จำนวนกฎที่ถูกส่งกลับเพราะไม่มีหลักฐาน |
จากภาพ (Source 4): กฎ 4 ถูกส่งกลับ ส่วน "ลดการเดาได้จริง" เป็นตีความ ยังไม่ทดสอบ |
| รู้ว่าเทสต์ตรวจได้จริง |
เทสต์ผ่านแต่ไม่รู้ว่าจับบั๊กได้ไหม |
เทสต์ต้องจับ 3 เวอร์ชันเจตนาพังได้ |
เวอร์ชันพังที่ล้มเหลวตามแผน |
จากภาพ (Source 4) และ Source 3 เป็นแนวคิดที่สมเหตุสมผล ยังไม่ทดสอบ |
ลองใช้
ตัวอย่างตัวเลข (ตัวอย่างประกอบ)
ใช้ตัวเลขของเธอใน Source 1 คิดต่อ และเติมสมมติของเราเอง คำนวณซ้ำได้
| รายการ |
ค่า |
ที่มา |
| ค่าสมาชิก AI |
700,000 วอน/เดือน |
Source 1 (คำเล่าเอง) |
| ยอดขาย |
ประมาณ 30,000,000 วอน/เดือน (ยอดขาย ไม่ใช่กำไร) |
Source 1 (คำเล่าเอง) |
| สัดส่วนค่า AI ต่อยอดขาย |
0.7 / 30 = ประมาณ 2.3% |
คำนวณจากสองบรรทัดบน |
| ช่วงรายได้จากงานเว็บ (ตัวอย่างประกอบ) |
10 งาน x 1 ล้าน = 10 ล้านวอน ถึง 15 งาน x 5 ล้าน = 75 ล้านวอน |
คำนวณจากช่วงใน Source 1 |
| ต้นทุนจ้างคน 4 คน (สมมติคนละ 2,500,000 วอน/เดือน) |
4 x 2.5 = 10,000,000 วอน |
สมมติของเรา ไม่ใช่ข้อมูลจากแหล่ง |
| ค่า AI เทียบต้นทุนจ้างคน |
0.7 / 10 = 7% |
คำนวณจากสมมติข้างบน |
ข้อสรุปที่ทำได้: ถ้ายอดขาย 30 ล้านอยู่ในช่วง 10-75 ล้านที่คำนวณได้ ตัวเลขที่เล่าสอดคล้องกันภายใน แต่ยังไม่ได้พิสูจน์ว่ามีกำไรหรือว่า AI เป็นสาเหตุ (ตีความ)
ตัวอย่างด่านตรวจกฎ (จากภาพของ Source 4)
| กฎ |
หลักฐาน |
ผลที่ด่าน Jev |
ไปที่ |
| กฎ 1 |
มี |
ผ่าน |
ห้อง B |
| กฎ 2 |
มี |
ผ่าน |
ห้อง B |
| กฎ 3 |
มี |
ผ่าน |
ห้อง B |
| กฎ 4 |
ไม่มี |
ไม่ผ่าน |
กลับไปให้ REA ขุดใหม่หรือทิ้ง |
ใช้เมื่อไรและไม่ใช้เมื่อไร
| กรณี |
ใช้ |
ไม่ใช้ |
ข้อกำหนดก่อน |
| งานเว็บและงานออกแบบที่ทำเองอยู่แล้ว |
ให้ AI ค้นและร่าง |
งานที่ตัวเองตรวจคุณภาพไม่เป็น |
มีพื้นฐานงานนั้นจริง (Source 1) |
| สร้างฟีเจอร์ใหม่จากสเปกที่ชัด |
แยกห้องสร้างกับห้องอ่าน |
งานที่ยังไม่รู้ว่าต้องการอะไร |
เขียนสเปกที่ตรวจได้ |
| ศึกษาพฤติกรรมของซอฟต์แวร์ |
ซอฟต์แวร์ของตัวเองหรือที่ได้รับอนุญาต |
ซอฟต์แวร์ที่ไม่มีสิทธิ์ตรวจ |
สิทธิ์ที่ชัดเจน (อ่านจาก repo) |
| งานเสี่ยงสูง (การเงิน กฎหมาย สุขภาพ) |
ใช้ร่างและค้นข้อมูล |
ปล่อยผลโดยไม่ตรวจโดยคน |
คนที่รับผิดชอบเซ็นรับ |
ขั้นแรกที่เล็กที่สุด
เลือกงานซ้ำ ๆ หนึ่งอย่างที่คุณทำเป็นอยู่แล้ว เช่น ค้นตัวอย่างก่อนทำเว็บ แล้วใช้คำสั่งที่ระบุครบ (ดัดแปลงจาก Source 1):
ผมต้องทำเว็บให้ [ประเภทธุรกิจ] ใน [พื้นที่]
ช่วยสรุปว่าเว็บธุรกิจแบบนี้ควรมีหน้าอะไรบ้าง
แต่ละหน้าต้องมีเนื้อหาอะไร ใช้โทนสีและภาพแบบไหน
และปุ่มให้ลูกค้าติดต่อควรอยู่ตรงไหน ทำเป็นตาราง
การทดสอบก่อน/หลังที่รันเองได้
| รายการ |
ค่าที่ต้องตั้งก่อนรัน |
| ตัววัด |
นาทีที่ใช้จนได้สรุปตัวอย่างที่ใช้งานได้ + จำนวนข้อที่ต้องแก้ตอนตรวจ |
| baseline |
ทำงานเดียวกันแบบเดิม 3 ครั้ง จดเวลาเฉลี่ย |
| เงื่อนไขผ่าน |
เวลาเฉลี่ยลดลงตามเกณฑ์ที่ตั้งก่อนรัน (เช่น 30%) และข้อที่ต้องแก้ไม่เพิ่ม |
| ถ้าไม่ผ่าน |
ปรับคำสั่งหรือเลิกใช้กับงานชนิดนี้ |
สำหรับ clean-room: ผ่านเมื่อเวอร์ชันที่สร้างใหม่ผ่านเทสต์ทั้งหมด และเวอร์ชันเจตนาพัง 3 เวอร์ชันล้มทั้ง 3 (Source 3, Source 4)
ทดสอบความเข้าใจ
| คำถาม |
คำตอบ |
คำตอบที่มักผิด |
| ทำไมผู้สร้างโค้ดต้องไม่เห็นแอปต้นทาง |
เพื่อให้ทุกบรรทัดมาจากสเปกที่ตรวจแล้ว ไม่มีการลอกหรือเดาจากของเดิม |
"เพื่อประหยัดโทเคน" |
| กฎ 4 ไม่มีหลักฐาน ควรทำอย่างไร |
ส่งกลับให้ REA หาหลักฐานเพิ่ม หรือทิ้งกฎนั้น ห้ามส่งต่อให้ห้อง B |
"ให้ Opus เดาเอา" |
| เทสต์ผ่านทั้งหมดแล้ว แต่เวอร์ชันเจตนาพังผ่านด้วย 1 ใน 3 สรุปว่าอย่างไร |
เทสต์ยังจับความผิดไม่ครบ ต้องเพิ่มเทสต์จนทั้ง 3 ล้ม (/goal ทำต่อ) |
"ผ่านแล้ว 2 ใน 3 ก็ยอมรับได้" |
| ค่าสมาชิก 7 แสนวอนแลกกับ "พนักงาน 4-5 คน" พิสูจน์แล้วหรือยัง |
ยัง เป็นคำเล่าของเจ้าตัว ไม่มีการตรวจบัญชีและเธอบอกเองว่ารายได้ขึ้นลง |
"พิสูจน์แล้ว เพราะมียอดขายสูง" |
| (กับดัก) ถ้าไม่มีพื้นฐานงานนั้น ใช้เทคนิคเดียวกันได้ไหม |
เสี่ยง เพราะแยกไม่ออกว่าผลของ AI ดีหรือไม่ ซึ่งเธอเองเน้นว่าต้องมีพื้นฐานก่อน |
"ได้ AI ทำแทนได้ทั้งหมด" |
| การทำ clean-room ด้วย AI ทำให้การสร้างซ้ำถูกกฎหมายเสมอหรือไม่ |
ไม่ได้การันตี ต้องมีสิทธิ์ตรวจซอฟต์แวร์ และถามผู้เชี่ยวชาญเรื่องลิขสิทธิ์ (ตีความ) |
"ถูกกฎหมายอัตโนมัติ" |
เคสเอเจนซี่เว็บคนเดียว (Source 1)
เคสนี้คือ Choi Han-bi ผู้ทำเว็บคนเดียวโดยใช้ AI ช่วย ข้อมูลทั้งหมดเป็นคำเล่าของเจ้าตัวในสื่อ ไม่มีการตรวจบัญชี
ข้อเท็จจริงที่รายงาน
| หัวข้อ |
ค่า |
หมายเหตุ |
| ประสบการณ์ก่อนเริ่ม |
ดีไซเนอร์ในบริษัทราว 10 ปี สอนโค้ดดิ้งราว 6 ปี |
เริ่มจากงานของคนรู้จัก |
| ราคางานเว็บ |
1-5 ล้านวอน (ราว 25,000-125,000 บาท) |
ต่อชิ้น |
| ปริมาณงาน |
สูงสุดราว 10-15 งาน/เดือน |
รวมงานรีนิวและดูแลต่อ |
| ค่าสมาชิก AI |
ราว 700,000 วอน (ราว 17,500 บาท)/เดือน |
สมัครเครื่องมือใหม่ไว้ก่อน |
| ยอดขาย |
ราว 30 ล้านวอน (ราว 7.5 แสนบาท)/เดือน |
ไม่ใช่กำไร ขึ้นลงทุกเดือน |
| คอร์สสอน |
ราว 260,000 วอน ราว 150 คน ได้ราว 50 ล้านวอนใน 10 วัน |
เล่าเองในรายการ |
7 ขั้นของวิธีทำงาน
| ขั้น |
สิ่งที่ทำ |
เครื่องมือที่กล่าวถึง |
| 1 |
นำทักษะสิบปีมาขายตรง เปลี่ยนจากเงินเดือนเป็นรับงานเป็นชิ้น |
ไม่ใช้เครื่องมือ |
| 2 |
ให้ AI หาตัวอย่างเว็บคู่แข่งและสรุป |
Manus, Notion |
| 3 |
เขียนคำสั่งที่ระบุธุรกิจ พื้นที่ และหัวข้อที่ต้องสรุปครบ |
ChatGPT หรือ Claude (เวอร์ชันดัดแปลง) |
| 4 |
สั่งบล็อก AI สร้างส่วนต่าง ๆ ของเว็บ |
Sixshop Pro |
| 5 |
สั่งเขียนโค้ดทั้งหน้าจากคำสั่งภาษาคน (ราว 5 นาที) |
Replit |
| 6 |
จ่ายค่าสมาชิก AI เพื่อแทนงานของคน |
หลายเครื่องมือ |
| 7 |
นำวิธีทำงานมาสอนเป็นคอร์ส |
Wadiz |
ข้อควรระวังเรื่องที่มา
- เธอเป็นผู้เชี่ยวชาญระดับต้น ๆ ของแพลตฟอร์มที่ใช้ และฝั่งแพลตฟอร์มเรียกเธอว่าผู้ช่วยเผยแพร่ผลิตภัณฑ์ จึงมีแรงจูงใจที่จะพูดถึงแพลตฟอร์มในแง่ดี (Source 1 บอกเอง)
- ส่วนท้ายของ Source 1 เป็นการโฆษณาคอร์สขายของผู้เรียบเรียง ไม่ใช่หลักฐานของเคส จึงไม่ถูกนำมาใช้เป็นข้อเท็จจริงในหน้านี้
Clean-Room Rebuild ด้วย REA, Jev, Opus 5.5 และ Haiku 5.5 (Source 3, Source 4)
บทบาท
| บทบาท |
หน้าที่ |
ห้ามทำ |
| REA (ห้อง A) |
อ่านฟีเจอร์ลงถึงระดับไบนารี เขียนทุกกฎลง SPEC.md พร้อมหลักฐานและข้อจำกัด |
เขียนโค้ดใหม่ และเข้าห้อง B |
| Jev |
ตรวจกฎทีละข้อกับหลักฐาน ส่งกฎที่พิสูจน์ไม่ได้กลับ |
อนุมัติกฎที่ไม่มีหลักฐาน |
| Opus 5.5 (ห้อง B) |
สร้างฟีเจอร์ใหม่จาก SPEC.md ในเซสชันใหม่ ตัดสินข้อที่ Jev ตีกลับ และเซ็นรับ |
เปิดแอปต้นทาง |
| Haiku 5.5 |
เขียนและรันเทสต์ รวมถึง 3 เวอร์ชันเจตนาพัง |
เขียนโค้ดของฟีเจอร์ |
| /goal |
ทำต่อจนทั้ง 3 เวอร์ชันพังล้มเหลวตามแผน |
หยุดก่อนครบเงื่อนไข |
กฎหนึ่งบรรทัด (Source 3): โมเดลที่เห็นของเดิมไม่เขียนโค้ด และโมเดลที่เขียนโค้ดไม่เห็นของเดิม
สิ่งที่ REA ตรวจ (จากภาพของ Source 4)
| วิธีตรวจ |
ความหมายแบบสั้น |
| strings |
สตริงที่ฝังอยู่ในโปรแกรม |
| calls + xrefs |
ใครเรียกใคร และอ้างอิงถึงกันที่ไหน |
| IPC / preload |
การสื่อสารระหว่างโพรเซสและสคริปต์ที่โหลดก่อน (แอปแบบ Electron) |
| runtime trace |
บันทึกพฤติกรรมตอนรันจริง |
ติดตั้งและรันคำสั่ง
npx rea-agents setup
- อ่านจาก repo (2026-10-18): คำสั่งนี้ลงทะเบียนเซิร์ฟเวอร์ MCP ของ REA กับเอเจนต์ ติดตั้งคำแนะนำเวิร์กโฟลว์ แสดงการเปลี่ยนแปลงให้อนุมัติ และสำรองค่าเดิมไว้ รองรับ Claude Code, Codex, Cursor, Gemini CLI, Grok Build
- อ่านจาก repo: ต้องมี Node.js 22.19 ขึ้นไป (หรือ 24.11 ขึ้นไป หรือ 26+) การวิเคราะห์เนทีฟต้องมี Hopper, Ghidra หรือ IDA การวิเคราะห์ JavaScript แบบสถิตไม่ต้องใช้เครื่องมือเนทีฟ
- ผ่านหน้าเว็บที่ดึงมา ไม่ใช่
gh และไม่ทราบ commit sha
พรอมต์ที่ใช้กับ Claude Code (Source 3)
Set up a clean-room rebuild around this tree:
1. Use REA to investigate [FEATURE] in [APP]. Write every behavior and rule into SPEC.md, each with the evidence REA found.
2. Send each rule to Jev. Any rule without evidence goes back to REA.
3. Start a fresh session with only SPEC.md. Rebuild the feature on Opus 5.5 without opening the original.
4. Write tests on Haiku 5.5 plus 3 intentionally broken versions. Use /goal until the rebuild passes and all 3 broken versions fail.
Show me SPEC.md first.
Nothing gets built until I say go.
ประโยคสุดท้ายสำคัญ: คนต้องดู SPEC.md และสั่ง "go" เองก่อนเริ่มสร้าง
จุดที่แหล่งตรงกัน และจุดที่ต่างกัน
| ประเด็น |
แหล่งที่สนับสนุน |
ข้อสรุป |
| ใช้ AI หลายตัวหรือหลายบทบาท ไม่ใช่ตัวเดียว |
Source 1 (หลายเครื่องมือ), Source 3 และ Source 4 (หลายโมเดล) |
ตรงกัน แต่ Source 1 แบ่งตามเครื่องมือ Source 3 และ 4 แบ่งตามบทบาทและราคาโมเดล |
| คนต้องเป็นผู้ตัดสินสุดท้าย |
Source 1 (ต้องมีพื้นฐานก่อน), Source 3 ("Nothing gets built until I say go") |
ตรงกัน |
| วิธีควบคุมต้นทุน |
Source 1 สมัครเครื่องมือรายเดือน; Source 3 ใช้ Opus 3 จังหวะ ที่เหลือใช้ Haiku |
ต่างกัน ยังไม่มีข้อมูลเทียบ จึงยังเปิดอยู่ |
| ความคุ้มค่า |
Source 1 อ้างว่าคุ้ม (คำเล่าเอง) Source 3 ไม่ให้ตัวเลข |
ยังไม่มีหลักฐานเปรียบเทียบ |
| "ยังแทบไม่มีใครรัน" |
Source 3 เท่านั้น |
เป็นความเห็น ไม่มีข้อมูลสนับสนุน |
Source 2 อ่านไม่ได้: ไฟล์มีเพียงข้อความ 1# ไม่มีเนื้อหาให้วิเคราะห์ หน้านี้จึงไม่ได้ใช้ข้อมูลใดจาก Source 2
ข้อเท็จจริง ความเห็น และการตีความ
| ประเภท |
ตัวอย่าง |
| ข้อเท็จจริงจาก repo |
REA คือ MCP สำหรับ reverse engineering; ใช้ MIT; npx rea-agents setup |
| ข้อเท็จจริงจากภาพ |
ผังห้อง A ห้อง B ด่าน Jev กฎ 4 ไม่มีหลักฐานถูกส่งกลับ; Haiku รัน 3 เวอร์ชันพัง |
| คำเล่าของเจ้าตัว (ไม่ได้ตรวจ) |
ยอดขาย 30 ล้านวอน; AI แทนคน 4-5 คน; เวลาค้นลดครึ่ง; คอร์ส 50 ล้านวอน |
| ความเห็น |
"ทริกที่แทบไม่มีใครรัน"; "คุ้มกว่าจ้างคน" |
| ข้อมูลที่ไม่พบ |
README ไม่พูดถึง Jev, SPEC.md หรือ clean-room; ที่มาของ Jev ยืนยันไม่ได้ |
Risks
Warning ตัวเลขรายได้และ "แทนพนักงาน 4-5 คน" เป็นคำเล่าของเจ้าตัว ยังไม่ผ่านการตรวจ อย่าใช้เป็นฐานตัดสินใจลงทุนหรือเลิกจ้าง
| ความเสี่ยง |
อธิบาย |
การลดความเสี่ยง |
| ตรวจผลของ AI ไม่เป็น |
ไม่มีพื้นฐานก็แยกผลดีกับผลพังไม่ออก |
ใช้กับงานที่ตัวเองเชี่ยวชาญก่อน |
| ยอดขายไม่ใช่กำไร |
ต้องหักค่า AI เวลาที่ใช้ และงานที่ยกเลิก |
ติดตามกำไรสุทธิรายเดือน |
| ข้อมูลมาจากผู้มีส่วนได้เสีย |
ผู้เล่าเป็นตัวแทนของแพลตฟอร์มที่ใช้ |
ทดลองเองด้วยการวัดก่อน/หลัง |
| ด่านตรวจหลวม |
หลักฐานปลอมหรือบางทำให้กฎผิดผ่านได้ |
ให้คนอ่านสเปกเองก่อนสั่ง go |
| ประเด็นทางกฎหมาย |
repo ให้ใช้เพื่อวิจัย การศึกษา หรือซอฟต์แวร์ที่มีสิทธิ์ตรวจ ห้ามสำเนาเถื่อน |
ตรวจสิทธิ์ก่อน; ปรึกษาผู้เชี่ยวชาญ |
| คำสั่งที่รันบนเครื่อง |
repo ระบุว่า runtime capture รันหรือโต้ตอบกับเป้าหมายด้วยสิทธิ์ของผู้ใช้ |
ใช้ในสภาพแวดล้อมแยกหากเป็นไปได้ (ตีความ) |
ความเข้าใจผิดที่พบบ่อย
| เข้าใจผิด |
ความจริง |
| AI ทำได้หมด คนไม่ต้องเก่ง |
แม้ในเคสแรก เจ้าตัวเน้นว่าต้องมีพื้นฐานก่อน |
| แยกห้องแล้วถือว่าปลอดภัยทางกฎหมาย |
ยังไม่ได้รับการยืนยันจากแหล่งใด |
| เทสต์ผ่านแปลว่าถูกต้อง |
ต้องมีเวอร์ชันเจตนาพังที่ล้มได้ด้วย |
Decision / next steps
Recommendation เริ่มจากงานซ้ำที่คุณเชี่ยวชาญอยู่แล้ว ทำการทดสอบก่อน/หลังตามหัวข้อ "ลองใช้" ก่อนซื้อเครื่องมือเพิ่ม และอย่าใช้ clean-room กับซอฟต์แวร์ที่ไม่มีสิทธิ์ตรวจ
| ลำดับ |
ขั้นถัดไป |
สถานะ |
| 1 |
เลือกงานซ้ำหนึ่งอย่างและตั้ง baseline 3 ครั้ง |
⚪ |
| 2 |
ใช้คำสั่งแบบระบุครบ รัน 3 ครั้ง เทียบเวลา |
⚪ |
| 3 |
ถ้าผ่าน ลองแยกบทบาท: ผู้ค้น ผู้ตรวจ ผู้สร้าง |
⚪ |
| 4 |
หากต้องการ clean-room ให้ยืนยันสิทธิ์ แล้วทดลองบนฟีเจอร์เล็กที่เป็นของตัวเอง |
⚪ |
| 5 |
หาข้อมูลเพิ่มเรื่อง Jev และเวิร์กโฟลว์ SPEC.md ใน repo (ยังไม่พบ) |
🟡 |
Sources
| # |
ประเภท |
รายการ |
| Source 1 |
ข้อความ |
เคสเอเจนซี่เว็บคนเดียวของ Choi Han-bi ใช้ AI หลายตัว (ไฟล์ m1/input.txt) |
| Source 2 |
ข้อความ |
ไฟล์ m2/input.txt มีแค่ 1# อ่านเนื้อหาไม่ได้ |
| Source 3 |
ข้อความ |
ทริก clean-room REA x Jev x Opus 5.5 พร้อมพรอมต์ (m3/input.txt) |
| Source 4 |
ภาพ |
ผังเวิร์กโฟลว์ clean-room และ session log (m4/input.jpg) |
| Repo |
GitHub |
https://github.com/morluto/rea อ่าน 2026-10-18 (ไม่มี gh ไม่ทราบ sha) |
ตัวย่อที่ใช้ในหน้านี้
ตัวย่อและคำเฉพาะ
| ตัวย่อ |
ชื่อเต็ม |
คืออะไร |
อ่านค่าอย่างไร |
| AI |
Artificial Intelligence |
ซอฟต์แวร์ที่ทำงานคล้ายการคิด เขียน หรือค้นข้อมูล |
"AI ค้นแทน" = ซอฟต์แวร์ค้นแทนคน |
| REA |
Reverse Engineer Anything |
เครื่องมือของ repo morluto/rea สำหรับวิเคราะห์แอปและไบนารี |
"REA อ่าน" = ดึงพฤติกรรมออกมาเป็นกฎ |
| Jev |
(ยังไม่พบชื่อเต็มใน repo) |
ตัวตรวจที่ตัดสินกฎว่ามีหลักฐานหรือไม่ ตามที่ Source 3 และ Source 4 ระบุ |
"Jev ตรวจ" = ผ่านหรือส่งกลับ |
| MCP |
Model Context Protocol |
มาตรฐานเชื่อมเครื่องมือเข้ากับเอเจนต์ AI |
"เซิร์ฟเวอร์ MCP" = ตัวเชื่อมเครื่องมือ |
| IPC |
Inter-Process Communication |
การสื่อสารระหว่างโพรเซสในแอป |
ตรวจ IPC = ดูข้อความที่ส่งระหว่างส่วนของแอป |
| xrefs |
cross-references |
การอ้างอิงข้ามกันของโค้ด |
calls + xrefs = ใครเรียกใคร |
| SPEC.md |
Specification (Markdown) |
ไฟล์สเปกที่บันทึกกฎพร้อมหลักฐาน |
ห้อง B อ่านไฟล์นี้อย่างเดียว |
| Opus 5.5 |
Claude Opus 5.5 |
โมเดลที่สร้างฟีเจอร์ใหม่และเซ็นรับ |
ใช้ 3 จังหวะ |
| Haiku 5.5 |
Claude Haiku 5.5 |
โมเดลที่รันเทสต์ |
รัน 3 เวอร์ชันเจตนาพัง |
| /goal |
(คำสั่งใน Claude Code) |
สั่งให้ทำต่อจนครบเงื่อนไข |
"ทำต่อจน 3 เวอร์ชันล้ม" |
| MIT |
MIT License |
ไลเซนส์โอเพนซอร์สของโค้ดที่ REA เขียนเอง |
ใช้ซ้ำได้ตามเงื่อนไขไลเซนส์ |
| JEB / IDA / Hopper / Ghidra |
ชื่อเครื่องมือ |
เครื่องมือวิเคราะห์ไบนารีที่ REA รองรับ |
ต้องมีไลเซนส์ถูกต้อง (JEB, IDA, Hopper) |
| Manus |
(ชื่อเครื่องมือ) |
AI ที่ค้นและทำงานต่อเองได้ ตาม Source 1 |
ใช้ค้นตัวอย่างเว็บ |
| Notion, Replit, Sixshop Pro, Wadiz |
ชื่อบริการ |
จดบันทึก, เขียนโค้ดด้วย AI, แพลตฟอร์มเว็บพร้อมบล็อก AI, ระดมทุน |
ตามที่ Source 1 ใช้ |
| วอน (KRW) |
Korean Won |
สกุลเงินเกาหลี |
700,000 วอน ≈ 17,500 บาท ตามที่ Source 1 ระบุ |
| Node.js, npx, CLI |
ชื่อเครื่องมือ |
รันไทม์ JavaScript, ตัวรันแพ็กเกจ, อินเทอร์เฟซบรรทัดคำสั่ง |
npx rea-agents setup |
ความหมายของ MCP, IPC, xrefs, CLI, MIT และ Node.js ใส่จากความรู้ทั่วไป ไม่ได้มาจากนิยามของแหล่งเอง
Summary
- ใจความ: แบ่งงานให้ AI ตามบทบาท และมีด่านตรวจหลักฐานก่อนงานผ่าน (Source 1, Source 3, Source 4)
- เคสคนเดียวทำงานเท่าทีมเล็กเป็นคำเล่าของเจ้าตัว ยังไม่ผ่านการตรวจ และเธอย้ำว่าต้องมีพื้นฐานก่อน (Source 1)
- Clean-room: ผู้ที่เห็นของเดิมไม่เขียนโค้ด ผู้เขียนโค้ดไม่เห็นของเดิม และเทสต์ต้องจับ 3 เวอร์ชันพังได้ (Source 3, Source 4)
- ข้อมูลที่ยังขาด: Source 2 ว่างเปล่า, README ของ repo ไม่ยืนยัน Jev และเวิร์กโฟลว์ SPEC.md, ยังไม่มีการวัดความคุ้มค่าจริง
- ขั้นแรก: วัดก่อน/หลังบนงานซ้ำหนึ่งอย่างที่คุณเชี่ยวชาญ
