XAULearn

งานวิจัย · ตัวอย่างงานตรวจ · ระดับซอร์สโค้ด

ตรวจซอร์ส EA ห้าไฟล์
สามในห้าข้อที่พบ backtest มองไม่เห็นโดยโครงสร้าง

การทดสอบย้อนหลังตอบได้แค่ว่า “โค้ดชุดนี้ให้ตัวเลขอะไรบนข้อมูลชุดนี้” · มันตอบไม่ได้ว่า โค้ดทำในสิ่งที่ผู้เขียนคิดว่ามันทำหรือเปล่า · หน้านี้คือผลตรวจซอร์สจริง — และสามในห้าข้อที่พบ ไม่มีทางปรากฏใน backtest ไม่ว่าจะรันนานแค่ไหน

5 ข้อบกพร่อง · 3 ข้อ backtest มองไม่เห็น 5 ไฟล์ · ตรวจ 9 ก.ย. 2026 EA ของเราเอง ถูกปฏิเสธไปแล้วทุกตัว

⚑ EA ทั้งห้าไฟล์เป็นของผู้เขียนเว็บนี้เอง และถูกปฏิเสธที่ walk-forward ไปแล้วทุกตัว · เราเผยแพร่ข้อบกพร่องของงานตัวเองเพราะ เราขายการตรวจ ไม่ได้ขายใบผ่าน — และเพราะการอ้างว่าตรวจเก่ง โดยไม่เคยแสดงว่าตรวจอะไรเจอบ้าง เป็นคำโฆษณา ไม่ใช่ผลงาน

ทำไม backtest ถึงมองไม่เห็นสามข้อนี้

ชนิดของข้อบกพร่องเหตุผลที่ตัวทดสอบจับไม่ได้
ทำสิ่งที่ผิดกับไม้ของ EA ตัวอื่น ตัวทดสอบรัน EA ตัวเดียวในบัญชีเปล่า สถานการณ์นี้ไม่มีวันเกิด
สถานะหายเมื่อรีสตาร์ตกลางทาง ตัวทดสอบไม่เคยรีสตาร์ตกลางการรัน
ตรรกะที่ตายแล้ว หรือเขียนผิดเจตนา มันรันได้ ไม่ error และให้ตัวเลขออกมาเสมอ · ไม่มีตัวเลขไหนชี้กลับไปที่บรรทัดที่ผิด

⚑ และข้อที่หนักที่สุดกลับด้านกว่านั้น — มันทำให้ตัวเลข backtest เองเชื่อไม่ได้ เพราะตัวทดสอบรันโค้ดที่มองอนาคตชุดเดียวกัน · ยิ่งรันนาน ยิ่งได้ตัวเลขที่ผิดอย่างมั่นใจขึ้น

ข้อที่พบ

F1 มองอนาคตตอนอุ่นเครื่อง — และมันไหลเข้าการเทรดจริง หนัก backtest มองไม่เห็น

GexCluster_Retest_v1

// ProcessBar() ถูกเรียกวนจาก WarmUp() ย้อนหลัง 900 แท่ง
double atr14 = (CopyBuffer(hATR,0,1,1,atr)==1) ? atr[0] : 0.0;
//                             ↑ shift 1 = แท่งล่าสุดเสมอ ไม่ใช่แท่ง s ที่กำลัง replay

เกิดอะไรขึ้น: ตอนเล่นย้อนแท่งที่ 900 แท่งก่อน โค้ดหยิบ ATR ของ "วันนี้" มาใช้ · ค่านั้นไหลเข้า g_sigma → กรอบ g1u/g1d → เครื่องสถานะระบอบ

ทำไมถึงสำคัญ: และเครื่องสถานะจงใจคงระบอบเดิมไว้เมื่อไม่มีเงื่อนไขพลิก (else: persist previous regime) — ระบอบที่ปนเปื้อนตอนอุ่นเครื่องจึงติดเข้าไปในการตัดสินใจเทรดจริง

แล้ว backtest จะบอกอะไร: ตัวทดสอบย้อนหลังรันโค้ดเดียวกัน จึงปนเปื้อนเหมือนกัน — ตัวเลข backtest เองก็เชื่อไม่ได้ ไม่ใช่แค่ตอนเทรดสด

F2 ตั้ง SL/TP ทับไม้ที่ไม่ใช่ของตัวเอง หนัก backtest มองไม่เห็น

ExhaustionFade_MAOsc_v1

if(PositionSelect(sym))          // เลือก "ไม้ใดไม้หนึ่ง" ของสัญลักษณ์นี้
{
   ulong pt = (ulong)PositionGetInteger(POSITION_TICKET);
   trade.PositionModify(pt, sl, tp);   // ← อาจไม่ใช่ไม้ที่เพิ่งเปิด
}

เกิดอะไรขึ้น: EA ตัวนี้บังคับใช้บัญชี hedging · บนบัญชีแบบนั้น PositionSelect(symbol) คืนไม้แรกที่เจอ ไม่ใช่ไม้ที่เพิ่งเปิด

ทำไมถึงสำคัญ: ถ้ามี EA ตัวอื่นถือ XAUUSD อยู่ในบัญชีเดียวกัน มันจะไปเขียนทับ SL/TP ของไม้นั้น · v2 แก้แล้วด้วย PosByComment("EX A") ซึ่งแปลว่าผู้เขียนเจอเองภายหลัง แต่ v1 ยังอยู่ในโฟลเดอร์และยังรันได้

แล้ว backtest จะบอกอะไร: ตัวทดสอบรัน EA ตัวเดียวในบัญชีเปล่า จึงไม่มีวันเกิด — มองไม่เห็นโดยโครงสร้าง

F3 ไม้ moon bag ไม่ถูกเทรลอีกเลยหลังรีสตาร์ต หนัก backtest มองไม่เห็น

ExhaustionFade v2 · KVF v1 · KVF v2

// ตัวแปรสถานะอยู่ในหน่วยความจำล้วน ไม่ได้บันทึกลงดิสก์
double g_bEntry=0, g_bR=0; bool g_beDone=false;

// OnInit หลังรีสตาร์ต: รับไม้เดิมมา แต่ไม่ได้กู้สถานะ
if(CountMyPositions()>0) g_setActive=true;

// Manage(): ออกทุกครั้ง ตลอดไป
if(g_bR<=0.0) return;

เกิดอะไรขึ้น: EA รับไม้ที่ค้างอยู่กลับมาดูแล แต่ค่า R และราคาเข้าหายไปแล้ว · ExhaustionFade v2 ออกที่ `g_bR<=0` ตรง ๆ · KVF ตกไปเข้าสาขาฝั่งตรงข้าม (g_setDir กลับเป็น 0) ซึ่งเงื่อนไขไม่มีทางเป็นจริงเมื่อสถานะเป็นศูนย์

ทำไมถึงสำคัญ: ผลปลายทางเหมือนกัน: ไม้ที่ออกแบบให้เทรลตาม Chandelier จะค้างอยู่กับ SL เดิมถาวร · ไม้ที่ควรวิ่งตามเทรนด์กลายเป็นไม้ที่ไม่มีใครดูแล

แล้ว backtest จะบอกอะไร: ตัวทดสอบไม่เคยรีสตาร์ตกลางการรัน — มองไม่เห็นโดยโครงสร้าง

F4 อินพุตชื่อ “ทดสอบความไวต่อต้นทุน” ไม่ได้จำลองต้นทุน กลาง

GexCluster_Retest_v1

input double InpSpreadPadUSD = 0.0;  // Spread-cost stress: pad ($/trade)

trade.BuyLimit(lot, e, sym, NP(g_C5-InpSL+p), NP(g_C5+InpTP+p), ...);
//                              SL ใกล้เข้า ↑       TP ไกลออก ↑

เกิดอะไรขึ้น: ค่านี้ขยับทั้ง SL และ TP ไปทางเดียวกัน ทำให้ stop แคบลงและเป้าไกลขึ้น

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

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

F5 เงื่อนไขที่ไม่มีผล ปิดบังการเอียงของสัญญาณช่วงต้น เบา backtest มองไม่เห็น

KVF_MACD_TrendRider_v1

double M_sig = (g_count>=InpKSig) ? MeanBuf(mnBuf) : MeanBuf(mnBuf);
//                                   ↑ สองสาขาเหมือนกันทุกตัวอักษร

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

ทำไมถึงสำคัญ: ช่วงอุ่นเครื่องจึงเฉลี่ยบัฟเฟอร์ที่ยังมีศูนย์ปนอยู่ → เส้นสัญญาณ KVF เอียงต่ำในช่วงต้น และ “เทรนด์ขึ้น” จะติดง่ายเกินจริง · v2 ตัดเงื่อนไขทิ้งแต่ไม่ได้แก้เรื่องศูนย์

แล้ว backtest จะบอกอะไร: ไม่มีตัวเลขไหนใน backtest ที่ชี้ไปที่บรรทัดนี้ได้

ขอบเขตของการตรวจแบบนี้

อยากให้ตรวจระบบของคุณ · ดูขอบเขตงานและราคา