Strategy Specification คือสัญญาระหว่างแนวคิดกับซอฟต์แวร์ ยิ่งนิยามชัด ยิ่งลดการตีความและทำให้ทดสอบได้ เอกสารที่ดีไม่ต้องยาวที่สุด แต่ต้องตอบได้ว่าระบบควรทำอะไรในกรณีปกติและกรณีผิดปกติ
บริบทและข้อมูลนำเข้า
ระบุสินทรัพย์, timeframe, session, timezone, แหล่งข้อมูล และข้อกำหนดบัญชี อธิบาย Indicator ทุกตัวด้วยสูตรและพารามิเตอร์ รวมถึงการจัดการข้อมูลหายและแท่งที่ยังไม่ปิด
เขียนวัตถุประสงค์และสิ่งที่ไม่ทำ เช่น ระบบเปิดสถานะอย่างเดียวหรือจัดการสถานะเดิมด้วย ขอบเขตที่ชัดป้องกัน feature แฝงระหว่างพัฒนา
Signal, Order และ State
ใช้ตาราง decision rule ระบุ entry, exit, invalidation และ priority เมื่อหลายเหตุการณ์เกิดพร้อมกัน กำหนด order type, price rounding, retry, timeout, partial fill และ duplicate protection
วาด state machine เช่น idle, pending, open, closing, halted พร้อม event ที่เปลี่ยนสถานะ วิธีนี้ช่วยให้ restart และ reconciliation มีพฤติกรรมที่คาดการณ์ได้
Risk, Test และ Operations
ระบุ position sizing, exposure limit, loss limit, kill switch และข้อห้าม จากนั้นสร้าง test case แบบ Given/When/Then ครอบคลุม happy path และ failure เช่น disconnect, spread สูง หรือคำสั่งถูกปฏิเสธ
กำหนด log, metric, alert, deployment, rollback และผู้อนุมัติ การส่งมอบควรยืนยันว่าโค้ดตรง specification ไม่ใช่ยืนยันกำไร เพราะตลาดและผลในอนาคตไม่สามารถรับประกันได้
โครงสร้างเอกสาร 8 ส่วน
เอกสารที่ใช้งานได้จริงมักมีหัวข้อตามลำดับนี้ แต่ละส่วนตอบคำถามเดียวและอ้างอิงกันได้ด้วยรหัสกฎ
- Overviewวัตถุประสงค์ สมมติฐานของกลยุทธ์ สิ่งที่ระบบทำและไม่ทำ
- Market & Datasymbol, timeframe, session, timezone, แหล่งข้อมูล และวิธีจัดการข้อมูลหายหรือแท่งที่ยังไม่ปิด
- Indicators & Featuresสูตร พารามิเตอร์ และช่วงค่าที่อนุญาตของ Indicator หรือ feature ทุกตัว
- Decision Rulesตาราง entry, exit, invalidation พร้อม priority เมื่อหลายเหตุการณ์เกิดพร้อมกัน
- Orders & Executionorder type, price rounding, retry, timeout, partial fill และ duplicate protection
- State Machineสถานะ idle, pending, open, closing, halted และ event ที่เปลี่ยนสถานะ
- Risk Controlsposition sizing, exposure limit, loss limit, kill switch และข้อห้าม
- Test & Operationstest case แบบ Given/When/Then, log, metric, alert, deployment, rollback และผู้อนุมัติ
ตัวอย่างตาราง Decision Rule
ตารางกฎทำให้ผู้พัฒนาเขียน test ได้ทันทีโดยไม่ต้องเดาเจตนา และทำให้เจ้าของกลยุทธ์เห็นช่องว่างของตัวเองก่อนเสียเวลาโค้ด
ตัวอย่าง · Decision Rule ของระบบ Long-only บน H1
| กฎ | เงื่อนไข | การกระทำ | Priority |
|---|---|---|---|
| R0 Halt | ขาดทุนวันนี้ ≥ 3% หรือ error ต่อเนื่อง 5 ครั้ง | เข้าสถานะ halted จนกว่าจะอนุมัติด้วยมือ | 0 (ตรวจก่อน) |
| R1 Invalidation | อยู่ในช่วง 30 นาทีก่อน-หลังข่าวแรงสูงตามปฏิทินที่กำหนด | ไม่เปิดคำสั่งใหม่ สถานะเดิมคงไว้ | 1 |
| R2 Exit Long | ราคาแตะ SL หรือ TP · หรือ RSI(14) > 70 เมื่อแท่งปิด | ปิดสถานะทั้งหมด | 2 |
| R3 Entry Long | แท่ง H1 ปิด · Close > SMA(50) · RSI(14) ตัดขึ้น 30 · ไม่มีสถานะเปิด | ส่ง market buy ตาม position sizing | 3 |
Priority ตัวเลขน้อยแปลว่าตรวจก่อน เมื่อ R0 เป็นจริงกฎอื่นจะไม่ถูกประเมิน ตัวเลขทั้งหมดเป็นเพียงตัวอย่างประกอบ ไม่ใช่คำแนะนำการตั้งค่า
ตัวอย่าง Pseudo-rules จากตารางเดียวกัน
เมื่อตารางชัด pseudo-code จะเขียนตามได้เกือบบรรทัดต่อบรรทัด และผู้พัฒนาสามารถแปลงเป็น MQL4, MQL5 หรือ Python ได้โดยไม่ต้องถามกลับ
ON bar_close(H1):
IF state == HALTED: RETURN
IF daily_loss >= 3% OR consecutive_errors >= 5: # R0
state = HALTED; alert("halted"); RETURN
IF news_window_active(): RETURN # R1
IF position == LONG AND (hit_sl_tp() OR rsi(14) > 70):
close_all() # R2
ELSE IF position == NONE AND close > sma(50) AND rsi_cross_up(30):
size = risk_size(balance * 1%, sl_distance)
IF size < min_lot: log("skipped: size"); RETURN
send_market_buy(size, sl, tp) # R3โค้ดจริงต้องเพิ่มการจัดการ error, retry, partial fill และ reconciliation ตามส่วน Orders & Execution และ State Machine ของเอกสาร การส่งมอบยืนยันว่าโค้ดตรงกับกฎเหล่านี้ ไม่ใช่ยืนยันว่ากฎจะทำกำไร
