Quy trình hóa chiến lược giao dịch trước khi viết bot: 3 bước từ ý tưởng đến đặc tả

Kịch bản này tôi gặp liên tục. Một trader giao dịch tay vài năm quyết định viết bot: mở cTrader Automate, gõ khoảng một trăm năm mươi dòng C# trong một tối cuối tuần theo đúng "những gì mình vẫn hay làm". Backtest cho đường equity đẹp khó tin; ba tuần sau khi vào tài khoản thật, tài khoản đỏ — và không ai, kể cả người viết ra nó, giải thích được bot sai ở đâu. Bởi vì con bot không thực thi một chiến lược: nó thực thi một ấn tượng mơ hồ được gói trong cú pháp C#.

Người ta cứ nghĩ khó nhất là code — thực ra code là phần dễ. Phần quyết định bot sống hay chết nằm phía trước: bạn có mô tả nổi chiến lược thành một bản đặc tả chặt chẽ đến mức một người xa lạ — hoặc một cỗ máy — làm theo mà không cần hỏi câu nào không? Bài này viết từ góc kỹ sư: vì sao "chiến lược trong đầu" không thành bot được, quy trình hóa nghĩa là gì, 3 bước biến ý tưởng thành bộ yêu cầu có số hiệu, và một ví dụ hoàn chỉnh — breakout vùng tích lũy — từ câu mơ hồ đến bản spec code thẳng không cần đoán.

Vì sao "chiến lược trong đầu" là kẻ thù của bot

Thử bài kiểm tra tôi hay dùng: đưa ba câu mô tả kiểu "chiến lược trong đầu" và đề nghị bạn — với tư cách lập trình viên — dịch sang một điều kiện if:

• "Vào lệnh khi thị trường bắt đầu ủng hộ."
• "Cắt lỗ ở một mức hợp lý."
• "Thoát khi giá hết đà."

Mỗi câu buộc người nghe phải... tự bịa: "ủng hộ" là gì — giá trên đường trung bình, đỉnh sau cao hơn đỉnh trước? "Hợp lý" là bao nhiêu pip? Máy không có trực giác lấp khoảng trống; nó chỉ kiểm tra điều kiện bạn viết ra. Điều kiện mơ hồ, lập trình viên tự chọn cách hiểu — rất có thể không phải ý bạn.

Tệ hơn: ý tưởng không được định nghĩa rõ thì không đo lường được, mà thứ không đo lường được thì không cải tiến được. Trader "trong đầu" thắng không biết vì sao, thua không biết vì sao — cứ xoay vòng đổ lỗi cho thị trường, tin tức, tâm lý. Không có quy tắc cố định thì không có dữ liệu lặp lại, không có thống kê — mọi lần "sửa chiến lược" chỉ là đoán mò.

Quy trình hóa là gì dưới góc kỹ thuật: một đặc tả có thể kiểm chứng

Trong phát triển phần mềm, trước khi code người ta viết specification — bản đặc tả. Đặc tả tốt là một tập mệnh đề có thể kiểm chứng: đưa cho bất kỳ ai, bất kỳ máy nào, đều ra cùng kết luận đúng/sai. Quy trình hóa chiến lược chính là viết bản đặc tả kiểu đó cho việc vào lệnh, thoát lệnh và quản lý vốn.

Mỗi mệnh đề phải trả lời đủ bốn câu — mô hình N–T–Đ–H:

1. Nguồn dữ liệu: con số lấy từ đâu — giá đóng nến H1, đường trung bình chu kỳ bao nhiêu, mức cao nhất 20 nến? Đừng nói "giá", vì "giá" có thể là high, low hay close.
2. Thời điểm đánh giá: kiểm tra khi nào — ngay khi chạm mức hay khi nến đóng cửa? Bot cần một nhịp rời rạc; mốc nến đóng là chuẩn nhất vì giá lúc đó không đổi nữa.
3. Điều kiện: phép so sánh rõ ràng — lớn hơn, cắt lên, nằm trong khoảng — mỗi thuật ngữ có định nghĩa số học.
4. Hành động: đúng thì làm gì (mua bao nhiêu, SL/TP đâu), sai thì làm gì (đứng ngoài, chờ nến sau, đóng lệnh đang chạy).

Một câu đặc tả chuẩn: "Tại mốc nến H1 đóng (T), nếu giá đóng (D) lớn hơn mức cao nhất 20 nến trước (Đ) thì gửi lệnh mua, khối lượng theo rủi ro 1% (H)." Dài, nhưng mỗi chữ đều "dịch được" sang code — không còn chỗ cho chữ "tùy". Con người hiểu câu "chờ giá xác nhận rồi vào" nhờ ngữ cảnh; máy thì không. Với mỗi cụm từ, hãy hỏi: nó gán được đơn vị đo không — pip, phần trăm, số nến? Không gán được nghĩa là nó che giấu một quyết định bạn chưa đưa ra.

Cũng cần nói về trạng thái (state) — thứ trader tay hay bỏ qua. Bot luôn ở một trạng thái: không lệnh, giữ lệnh mua, giữ lệnh bán, hay bị khóa; mỗi trạng thái có bộ quy tắc riêng và việc chuyển trạng thái phải định nghĩa — ví dụ "đang có lệnh mua mà tín hiệu mua mới xuất hiện thì làm gì?" Trader tay "cảm nhận" là không vào thêm; bot phải được bảo trước.

Bước 1 — Đặc tả điểm vào: tách tín hiệu, bối cảnh và điều kiện loại trừ

Bước đầu trả lời một câu: khi nào bot được phép vào lệnh? Đừng viết một câu dài — hãy tách thành ba lớp:

Lớp 1 — Sự kiện kích hoạt (trigger). "Cái nút bấm" — điều gì đó phải xảy ra trên biểu đồ để bot bắt đầu xem xét. Trigger luôn rời rạc, đếm được: một nến đóng ở vị trí nào đó, một đường cắt đường khác. Viết dạng "khi sự kiện X xảy ra tại mốc thời gian Y", tránh tuyệt đối kiểu "khi thị trường sẵn sàng".

Lớp 2 — Bối cảnh (filter). Trigger xuất hiện không có nghĩa phải vào. Bối cảnh là điều kiện "nền" lọc tín hiệu rác: chỉ giao dịch một hướng kỳ vọng, chỉ trong khung giờ thanh khoản, chỉ khi biến động đủ lớn. Nó trả lời "có đáng chơi ván này không"; trigger trả lời "thời điểm chính xác khi nào". Người mới hay gộp hai thứ làm một; tách ra thì mỗi lớp dễ kiểm chứng, dễ sửa.

Lớp 3 — Điều kiện loại trừ (invalidator). Lớp trader tay "có" nhưng không bao giờ viết ra vì với họ nó hiển nhiên: không vào trước tin lớn, không vào lúc spread giãn, không vào khi đã nhiều lệnh. Máy không biết chuyện hiển nhiên nào; bỏ sót lớp này, bot ngoan ngoãn vào lệnh đúng lúc bạn không bao giờ muốn.

Khi đã tách ba lớp, gói mỗi quyết định thành một mệnh đề một dòng kiểu boolean:

MUA khi: (nến H1 vừa đóng > mức cao 20 nến)          // trigger
          VÀ (độ rộng vùng >= 1.5 × ATR14)           // bối cảnh: biến động đủ lớn
          VÀ (giờ server trong 07:00–19:00)           // bối cảnh: phiên thanh khoản
          VÀ (chưa có lệnh mua đang mở)               // loại trừ: giới hạn 1 lệnh
          VÀ (không trong 15 phút trước tin lớn)      // loại trừ: lịch kinh tế

Viết được điểm vào thành một khối điều kiện như trên là bạn đã đi được phần khó nhất của Bước 1. Nếu chỉ viết được "mua khi giá phá lên", hãy quay lại: "phá" là nến đóng cửa hay chạm giá? "lên" vượt mức nào? Mỗi lần phải thêm một con số là một lần bạn nhận ra mình chưa từng có quyết định thật sự.

Cuối Bước 1, đừng quên giới hạn số lệnh và chuyện "trùng tín hiệu": đang có lệnh mua mà trigger mua xuất hiện lần nữa — vào một hay nhiều lệnh? Lệnh cũ đang thua mà tín hiệu ngược xuất hiện — đóng cũ vào mới hay giữ cả hai? Trader tay xử lý bằng cảm xúc từng phút; bot cần câu trả lời cố định viết từ trước, khi đầu óc còn tỉnh táo.

Bước 2 — Đặc tả rủi ro: stop có lý do, khối lượng có công thức, và công tắc dừng

Quy trình hóa không chỉ là mô tả điểm vào cho rõ — phần quyết định bạn còn chơi được hay không nằm ở câu: mỗi lệnh thua lấy đi bao nhiêu, và điều gì xảy ra khi mọi thứ cùng sai một lúc? Đặc tả rủi ro thành bốn tầng:

Tầng đầu — vị trí stop — là nơi trader tay "linh hoạt" nhất, nên phải đặc tả cứng nhắc nhất. Stop có lý do là stop gắn với cấu trúc thị trường: dưới đáy gần nhất, dưới biên vùng giá. Đừng đặt "theo cảm giác"; hãy viết công thức "SL lệnh mua = min(đáy nến breakout) − 2 pip" — có công thức, mọi lệnh mới được đối xử như nhau.

Tầng hai và ba đi với nhau: từ khoảng rủi ro (pip) và ngân sách (tiền) tính ra khối lượng:

Khối lượng (lot) = (Số dư × % rủi ro mỗi lệnh) ÷ (Số pip entry–SL × Giá trị 1 pip của 1 lot)

Ví dụ: tài khoản 10.000 USD, rủi ro 1% = 100 USD, entry–SL = 20 pip, 1 lot chuẩn giá trị 10 USD/pip → khối lượng = 100 ÷ (20 × 10) = 0.5 lot. Phép tính tách quyết định "bao nhiêu tiền dám mất" (1% — chọn lúc bình tĩnh) khỏi quyết định "vào bao nhiêu lot" (0.5 — do công thức). Trader tay gộp hai thứ, để cảm xúc chi phối cả hai nên không biết hệ thống lời lỗ thế nào; chuẩn hóa về cùng ngân sách, mọi kết quả quy về cùng thước đo — nền tảng của Bước 3.

Tầng cuối — công tắc dừng (kill switch) — phân biệt người nghiệp dư và người làm hệ thống. Bot phải có điều kiện "tự tắt": số dư tụt X% từ đỉnh thì ngừng mở lệnh mới cho tới khi bạn chủ động reset. Đa số tài khoản chết không vì một lệnh thua to mà vì chuỗi thua liên tiếp không ai kéo phanh; một dòng trong đặc tả — "equity giảm 8% so với đỉnh 30 ngày → chuyển trạng thái 'khóa', chỉ đóng lệnh theo quy tắc thoát" — cứu được rất nhiều tiền.

Bước 3 — Đặc tả vòng đo lường: journal theo R, KPI và tiêu chí nghiệm thu

Bước này dễ bị bỏ qua vì không tạo ra thứ gì "chạy được" ngay, nhưng nó biến bot thành hệ thống có thể cải tiến: định nghĩa trước — trước khi code — thế nào là "bot hoạt động tốt" bằng con số, không phải cảm giác.

Mọi thứ đo bằng R (bội số của ngân sách rủi ro): lệnh thắng +1R kiếm đúng bằng số tiền bạn định mất ở lệnh đó. Quy mô vị thế chuẩn hóa ở Bước 2 nên mọi lệnh, mọi symbol, đều gộp về cùng thang đo. Từ đó tính bốn KPI:

Ví dụ: thắng 45%, lệnh thắng trung bình +1.4R, lệnh thua −1R → expectancy = (0.45 × 1.4) − (0.55 × 1.0) = +0.08R/lệnh; sau 100 lệnh kỳ vọng +8R. Nhỏ, nhưng thật và đo được — khác hẳn cảm giác "tuần này đang lời".

Còn một lớp đo nữa: chất lượng thực thi — bot có làm đúng đặc tả không: mở lệnh trễ bao nhiêu giây, trượt giá bao nhiêu pip, có tín hiệu bị bỏ lỡ? Vì vậy hãy yêu cầu bot ghi log mọi quyết định kèm mã yêu cầu để đối chiếu với journal. Cuối cùng, viết tiêu chí nghiệm thu (acceptance criteria): "chỉ lên tài khoản thật khi expectancy ≥ +0.1R trên ≥ 300 lệnh ngoài mẫu, profit factor ≥ 1.4 và max drawdown ≤ 10%". Có tiêu chí này, bạn không rơi vào bẫy "backtest đẹp là code ngay", vì "đẹp" giờ có định nghĩa số học.

Từ quy trình hóa đến bản spec có số hiệu yêu cầu

Ba bước trên cho một bộ quy tắc rõ ràng. Để bàn giao cho lập trình viên — hoặc chính bạn sau ba tháng, khi đã quên ý định ban đầu — bộ quy tắc phải được đóng gói thành bản đặc tả có cấu trúc, mỗi quy tắc gán một số hiệu yêu cầu (requirement ID) — thói quen của kỹ sư phần mềm: khi bot chạy ra lệnh lạ, hai người không tranh cãi "ý anh là sao" nếu cùng chỉ vào một mã số.

Cấu trúc tối thiểu gồm bảy phần: (1) mục tiêu & phạm vi; (2) dữ liệu đầu vào và tham số; (3) trạng thái & luồng quyết định, kèm cả edge case; (4) quản trị rủi ro; (5) thoát & quản lý vị thế; (6) logging & dữ liệu đo lường; (7) tiêu chí nghiệm thu. Mã số nên theo nhóm chức năng:

Đi kèm, một công cụ nâng cao đáng dùng là ma trận truy vết (traceability matrix) — bảng nối mỗi mã yêu cầu với cách kiểm chứng và phần code tương ứng. Sửa một quy tắc, ma trận chỉ rõ chỗ nào trong code và bài kiểm tra nào bị ảnh hưởng — tránh "sửa một chỗ, quên ba chỗ" khiến bot chạy sai nhiều tuần không ai hay.

Mẫu hoàn chỉnh: quy trình hóa chiến lược breakout vùng tích lũy (range)

Giờ làm một ví dụ trọn vẹn để thấy ba bước chảy vào một bản spec: chiến lược breakout khỏi vùng tích lũy (range breakout) trên EURUSD khung H1 — cố ý khác kiểu "hai đường trung bình cắt nhau" để thấy phương pháp áp dụng được cho mọi phong cách.

Ý tưởng ban đầu (mơ hồ): "Giá nằm im một vùng rồi phá ra thì theo hướng phá. Đừng vào khi thị trường đang rối."

Bước 1 — điểm vào: định nghĩa "vùng nằm im" bằng dữ liệu — cao/thấp nhất của 20 nến H1 đã đóng. "Phá ra" là nến đóng vượt biên trên (mua) hoặc xuyên biên dưới (bán). Bối cảnh: vùng quá hẹp thì cú phá chỉ là nhiễu, nên đòi độ rộng ≥ 1.5 × ATR14, chỉ giao dịch trong khung giờ thanh khoản 07:00–19:00. Loại trừ: không vào trong 15 phút trước tin lớn, không vào khi đã có lệnh cùng chiều.

Bước 2 — rủi ro: SL lệnh mua dưới đáy nến breakout trừ 2 pip; khoảng rủi ro R = entry − SL; ngân sách 1% số dư; khối lượng tính tự động. Bước 3 — đo lường: TP = 1.6R; lời đạt 0.8R thì dời SL về hòa vốn; giá quay lại đóng trong vùng thì thoát sớm; công tắc dừng ở drawdown 8%. Bản đặc tả gom lại:

Đưa bảng này cho lập trình viên C# — không cần hỏi "range là gì", "phá là sao", "cắt lỗ ở đâu". Code phần lõi dịch gần như từng dòng từ bảng:

protected override void OnBar()
{
    int lastClosed = 1;                       // nến H1 vừa đóng
    double rangeHigh = double.MinValue;
    double rangeLow  = double.MaxValue;
    for (int i = 2; i <= 21; i++)             // 20 nến đã đóng (ENTRY-01/02)
    {
        rangeHigh = Math.Max(rangeHigh, Bars.HighPrices[i]);
        rangeLow  = Math.Min(rangeLow,  Bars.LowPrices[i]);
    }
    double width = rangeHigh - rangeLow;
    double atr = _atr.Result.Last(lastClosed);
    double close = Bars.ClosePrices[lastClosed];
    double barHigh = Bars.HighPrices[lastClosed];
    double barLow  = Bars.LowPrices[lastClosed];
    bool wideEnough = width >= 1.5 * atr;                        // FILTER-01
    bool inSession  = Server.Time.Hour >= 7 && Server.Time.Hour < 19; // FILTER-02
    bool idle       = !HasOpenPosition();                        // STATE-01

    if (wideEnough && inSession && idle && close > rangeHigh)    // ENTRY-03
    {
        double sl = barLow - 2 * Symbol.PipSize;   // EXIT-01
        double r  = close - sl;
        double tp = close + 1.6 * r;               // EXIT-02
        double volume = ComputeVolumeByRisk(0.01, r); // RISK-01
        ExecuteMarketOrder(TradeType.Buy, SymbolName, volume, "RangeBreakout", sl, tp);
    }
    // Nhánh bán, EXIT-03 (dời SL), EXIT-04 (thoát sớm) đặt ở hàm riêng.
}

Code là khung minh họa — bản đầy đủ còn xử lý nhánh bán và API thực tế của cTrader (Bars.LastBar, Symbol.QuantityToVolumeInUnits). Điểm cốt lõi: mỗi dòng code "dịch" từ một dòng có mã số trong bảng đặc tả — không dòng nào do lập trình viên "tự nghĩ ra". Đặc tả tốt đến vậy thì code gần như cơ học.

Cạm bẫy khi code trước khi quy trình hóa — và cách đo hiệu quả sớm

Cứ "code thử, vừa làm vừa sửa" cũng được — nhiều người học bằng cách làm — nhưng bạn nên biết mình trả giá gì:

Ngoài tránh cạm bẫy, hãy chủ động đo hiệu quả sớm — trước khi tốn hàng chục giờ code một chiến lược có thể vốn đã vô dụng. Ba phép đo rẻ tiền, làm ngay khi đặc tả vừa xong:

Một — chạy tay trên lịch sử. Cuộn biểu đồ H1 về quá khứ và — đúng vai con bot — chỉ hành động theo từng dòng trong bảng đặc tả, ghi lại lệnh giả định kèm kết quả. Vài chục tín hiệu là có ước lượng expectancy sơ bộ. Nếu chạy tay mà muốn "linh hoạt" — bỏ tín hiệu vì "cảm giác lần này khác" — thì đặc tả còn lỗ hổng, không phải bạn thông minh hơn bot.

Hai — kiểm tra ngoài mẫu từ đầu. Khi dò tham số (bao nhiêu nến cho range, hệ số ATR), đừng dùng toàn bộ lịch sử: chia đôi dữ liệu, một phần phát triển, một phần giữ nguyên — chỉ chạy thử phần sau khi chốt tham số. Chiến lược chỉ "sống" được ở dữ liệu chưa từng thấy mới đáng code tiếp.

Ba — định giá chi phí trước khi code. Ước lượng với tần suất tín hiệu của đặc tả, mỗi tháng bạn trả bao nhiêu pip cho spread và hoa hồng. Chi phí ngốn hết expectancy ước tính thì dù code hoàn hảo chiến lược vẫn chết — biết sớm để khỏi lãng phí thời gian.

Câu hỏi thường gặp về quy trình hóa chiến lược trước khi viết bot

Hỏi: Tôi phải quy trình hóa 100% mọi tình huống, hay được giữ phần "phán đoán" riêng?

Đáp: Muốn bot chạy tự động, mọi quyết định bot phải đưa ra đều phải được đặc tả. Nhưng bạn được giữ phán đoán ở lớp "con người giám sát": bot gợi ý tín hiệu còn bạn bấm nút, hoặc bot tự chạy giờ hành chính còn bạn tắt khi có sự kiện bất thường. Ranh giới phán đoán ở đâu do bạn chọn — miễn là nó cũng được viết ra.

Hỏi: Đặc tả chi tiết đến đâu thì đủ để bắt đầu code, tránh "tê liệt vì phân tích"?

Đáp: Điểm dừng là khi bạn trả lời không do dự ba câu: bot vào lệnh khi nào (điều kiện số), mỗi lệnh mạo hiểm bao nhiêu và SL/TP ở đâu, và đạt chỉ số gì mới đáng chạy. Khi đó hãy code bản đầu để backtest và forward test "chỉ điểm" chỗ còn thiếu — quy trình hóa là vòng lặp, không phải nghi thức một lần là xong.

Hỏi: Tình huống hiếm như giá nhảy gap, mất kết nối lúc đặt lệnh thì đưa vào đâu?

Đáp: Đưa vào mục "trạng thái & edge case" của spec. Với gap: quyết định trước — giá mở cửa vượt mức SL thì bot chấp nhận đóng ở giá xấu hơn (market) hay giữ lệnh chờ. Với mất kết nối: bot "bất động chờ reconnect" hay có cơ chế dự phòng. Chính vì hiếm nên bạn phải viết trước, không thể "ứng biến" lúc nó xảy ra.

Hỏi: Backtest của tôi rất đẹp nhưng live lại thua — có phải đặc tả thiếu gì?

Đáp: Rất có thể thiếu phần trung thực về chi phí: backtest chưa tính spread biến động, hoa hồng và trượt giá khi lệnh khớp ở giá xấu hơn giá đặc tả. Kiểm tra ba thứ: backtest có bật đúng chi phí, chiến lược có nhạy cảm với tick, và bạn có chạy đủ lâu ngoài mẫu.

Hỏi: Tôi vào lệnh ngay khi giá chạm mức (intrabar) chứ không chờ nến đóng — đặc tả kiểu nào đúng?

Đáp: Chờ nến đóng cửa là lựa chọn an toàn và dễ kiểm chứng nhất: giá lúc đó đã "chốt", ai kiểm tra cũng ra cùng kết quả, backtest không bị thiên lệch nhìn về tương lai. Vào intrabar nghe nhanh hơn nhưng dễ nhiễu (giá chạm rồi quay đầu) và backtest kiểu này dễ lạc quan giả tạo vì bạn "biết trước" nến sẽ đóng thế nào.

Hỏi: Bao nhiêu lệnh (hoặc forward test bao lâu) thì đủ để tin vào expectancy?

Đáp: Không có con số tuyệt đối: vài trăm lệnh ngoài mẫu để tin backtest, và tối thiểu vài chục lệnh demo (hoặc 1–2 tháng) để xác nhận bot thực thi đúng đặc tả ở điều kiện thật. Expectancy từ 20–30 lệnh chỉ là nhiễu thống kê. Chi phí của sự kiên nhẫn rẻ hơn nhiều so với một lần vào live vội vàng.

Kết luận

Con đường từ ý tưởng đến một con bot chạy ổn định không bắt đầu bằng trình biên dịch — nó bắt đầu bằng một tờ giấy trắng và sự trung thực. Bạn phải trả lời, bằng con số, ba câu: bot vào lệnh khi nào; mỗi lệnh thua lấy đi bao nhiêu và điều gì buộc bot dừng; làm sao đo lường và cải tiến theo dữ liệu. Đó là 3 bước quy trình hóa — đặc tả điểm vào, đặc tả rủi ro, đặc tả vòng đo lường — sản phẩm cuối là một bản đặc tả có số hiệu yêu cầu, nơi mỗi quy tắc kiểm chứng được và mỗi dòng code truy vết về một quy tắc.

Hãy nhớ chuỗi giá trị đúng: ý tưởng → quy trình hóa → đặc tả có mã yêu cầu → code → backtest trung thực → demo → live. Đi tắt mắt xích nào ở phía trước, bạn trả giá ở phía sau — thường bằng chính tài khoản. Ngược lại, vài buổi tối đầu tư viết bộ quy tắc rõ ràng sẽ biến phần lập trình phía sau thành công việc gần như cơ học, minh bạch và kiểm chứng được. Kỹ năng viết đặc tả còn biến bạn thành người vận hành hệ thống, thay vì người bị hệ thống của chính mình vận hành.

Nếu muốn đi trọn con đường từ một ý tưởng còn mơ hồ đến một cBot C# được quy trình hóa bài bản, chạy backtest trung thực và vận hành an toàn, các khóa học lập trình bot của DNT Digital được thiết kế theo đúng lộ trình thực hành có người dẫn dắt — để bạn khỏi tự trả giá bằng chính tài khoản cho những bài học có thể học trước.

▶️ Xem video: Quy trình hóa chiến lược giao dịch — 3 bước