# Con bot copy ví: mình sao chép được hành động, không sao chép được lý do
Có một sản phẩm vừa ra mắt, tính năng gói gọn trong một câu: copy nguyên một cái ví, bot tự chạy lệnh theo.
Mình đọc xong thì không nghĩ tới chuyện lãi lỗ. Mình nghĩ tới một lần mình đi chép bài người khác và chép rất giỏi — chép đúng đến mức mọi thứ chạy y hệt, chỉ trừ kết quả.
Hôm đó mình dựng lại một quy trình đang chạy tốt của người khác. Từng bước, đúng thứ tự, đúng công cụ, đầu ra đúng định dạng. Chạy một tuần không lỗi nào. Log sạch. Và nó vô dụng, vì cái làm quy trình đó tốt không nằm ở các bước — nó nằm ở hai chỗ mình không nhìn thấy: người ta chọn đầu vào theo tiêu chí gì, và người ta dừng lại khi nào.
Mình chép được tay chân. Mình không chép được cái đầu.
Chuyện copy ví cũng y hệt, chỉ khác là cái giá của việc chép thiếu được tính bằng tiền, và được tính mỗi giây.
Ba kiểu tự động hoá, và kiểu thứ ba là kiểu bán chạy nhất
Mình hay chia automation làm ba kiểu, theo câu hỏi "cái gì đang ra quyết định".
Kiểu một — ra luật. Mình viết luật, máy thi hành. Nếu giá vượt mức này thì bán, nếu file mới xuất hiện thì đẩy đi, nếu API trả lỗi thì chờ rồi thử lại. Rẻ, chắc, dễ kiểm. Nhược điểm cố hữu: nó chỉ giải được bài mình đã biết trước là mình sẽ gặp.
Kiểu hai — giao phán đoán cho máy, kèm ngữ cảnh. Đây là chỗ agent sống. Máy tự đọc, tự cân, tự chọn. Đắt: phải nuôi ngữ cảnh, phải kiểm chứng, phải chấp nhận nó sai theo xác suất. Nhưng nó xử lý được cái mình chưa lường.
Kiểu ba — sao chép phán đoán. Mình không dạy máy phán đoán gì cả. Mình chỉ bắt nó bắt chước kết quả của phán đoán người khác: thấy người ta mua thì mua, thấy người ta bán thì bán.
Kiểu thứ ba rẻ nhất để build, vì mình bỏ qua toàn bộ phần khó nhất — phần dạy máy hiểu. Và vì thế nó cũng là kiểu dễ bán nhất: khách không phải học gì, không phải tin vào "trí tuệ của máy", chỉ cần tin vào một người. Đúng loại niềm tin con người ta sẵn có nhất.
Nhưng nó có một lỗ hổng cấu trúc, và lỗ hổng đó không phải là bug — không có bản vá nào.
Mình gọi nó là khoảng trống lý do.
Bốn thứ không nằm trong cái ví
Khi bạn copy một cái ví, bạn đọc được một dòng: đã mua cái này, số lượng này, lúc này. Bốn thứ sau không có trong dòng đó.
Một, lý do. Người ta mua vì cái gì? Vì một thông tin chưa công bố, vì một luận điểm dài hạn, vì đang tái cân bằng danh mục, hay vì đơn giản là đang thử nghiệm một thứ bé xíu cho vui?
Bạn không biết. Và đây không phải chi tiết phụ — lý do chính là thứ quyết định lệnh đó đúng hay sai về sau. Cùng một lệnh mua, nếu lý do là "tôi tin vào cấu trúc này trong ba năm" thì nó là vị thế; nếu lý do là "tôi đang test một thứ" thì nó là nhiễu, và người ta sẽ cắt nó ở mức lỗ 2% mà không buồn nghĩ.
Bạn copy đúng cái lệnh. Bạn copy sai hoàn toàn bản chất của nó.
Hai, tỷ trọng. Con số hiện trên chuỗi là số tuyệt đối. Cái quyết định rủi ro là số đó chia cho tổng tài sản của người ta. Một lệnh bằng 0,5% danh mục của họ và một lệnh bằng 0,5% danh mục của bạn là hai quyết định khác nhau về bản chất, dù trên màn hình trông giống nhau.
Và nó còn một tầng nữa: kích thước lệnh so với thanh khoản tại thời điểm đó. Người ta vào được vì họ vào sớm. Bạn vào sau, bằng tiền của bạn, vào đúng cái hồ mà họ vừa khuấy.
Ba, cửa ra. Đây là chỗ mình nghĩ nhiều nhất.
Vào thì copy được — nó là một hành động xảy ra một lần, có dấu trên chuỗi. Ra thì không. Vì ra cũng là một quyết định có lý do: đã đủ mục tiêu, luận điểm đã sai, cần tiền cho việc khác, hoặc đơn giản là hết kiên nhẫn. Người ta ra vì một cái gì đó. Bạn thấy cú bán, không thấy cái gì đã chết trong đầu người ta trước đó ba tuần.
Nên bạn giữ một vị thế mà người sở hữu nó đã bỏ. Không phải vì bạn quyết giữ — vì bạn không có lý do để bỏ.
Bốn, thời gian. Bạn luôn ở sau. Không phải sau một chút — sau theo đúng cái độ trễ của hệ bạn dựng. Và độ trễ trong loại hình này không phải là bất tiện, nó là thuế, thuế luỹ tiến, đóng mỗi lần chạy.
Rồi tới tầng cuối, cái tầng làm mình thấy mô hình này buồn cười một cách nghiêm túc: cái được copy sẽ tự hỏng vì bị copy.
Trên một hệ công khai, ai cũng đọc được. Nếu một cách làm sinh lời, thì việc nó được copy nhiều chính là thứ làm nó hết sinh lời — vì dòng tiền đi vào cùng một chỗ, giá bị đẩy trước khi bạn kịp vào, và người giỏi nhất sẽ đổi cách làm để không bị đọc.
Nghĩa là: một sản phẩm copy, khi thành công về mặt phân phối, tự phá giá trị của chính nó. Càng nhiều khách, càng ít giá trị. Đây không phải rủi ro vận hành. Đây là mâu thuẫn trong thiết kế.
Vậy bán cái gì khi bán một con bot copy?
Câu hỏi thật của người mua không phải "bot có chạy không". Bot chạy được thì dễ. Câu hỏi thật là: tôi có phải nghĩ nữa không?
Và đây là chỗ sản phẩm hay tự lừa mình. Khách trả tiền cho việc không phải quyết định. Nhưng thứ tạo ra lãi lỗ lại nằm ở đúng những khoảnh khắc không chạy: lệnh này bỏ qua, người này thôi copy, hệ này tạm dừng ba tuần.
Một con bot chỉ biết "chạy theo" thì không có khái niệm đó. Nó không có trạng thái "đứng ngoài". Và một hệ không có trạng thái đứng ngoài thì trong mọi thị trường, nó luôn ở trong.
Ba con số nên đo, và một con số nên bỏ
Mình từng thấy người ta đo bằng tỷ lệ thắng. Con số đó gần như vô dụng, vì nó không nói gì về hình dạng của phần thua.
Thử phép tính nhỏ: thắng 8 lần, mỗi lần +1. Thua 2 lần, mỗi lần −6. Tỷ lệ thắng 80%. Kết quả: âm 4. Bạn có thể thắng 80% số lần và vẫn chết, và bạn sẽ chết ở đúng hai lần mà hệ không có gì chặn.
Nên mình đo ba thứ khác:
- ▹Phân bố lỗ, không phải tần suất lỗ. Khoản lỗ lớn nhất trong một ngày là bao nhiêu, và cái gì bằng code chặn nó. Nếu câu trả lời là "bot sẽ tự bán khi lỗ tới mức X" thì câu hỏi tiếp theo là: nếu lúc đó không ai mua thì sao?
- ▹Thời gian phải ngồi canh. Nếu khách phải mở app ba lần một ngày, sản phẩm của bạn không phải automation, nó là một cái dashboard có nút bấm.
- ▹Số lần khách phải can thiệp tay trên 1000 lần chạy. Con số này thành thật một cách khó chịu. Nó bao gồm cả những lần khách phải cứu hệ, và cả những lần khách nghi ngờ hệ mà không có lý do — vì niềm tin cũng là một dạng chi phí vận hành.
Còn con số nên bỏ: "số lệnh đã thực hiện". Nó chỉ đo được việc hệ còn sống. Một cái máy chạy 10.000 lệnh và làm khách mất tiền vẫn đếm đủ 10.000.
Chỗ thật sự bền
Nếu mình phải làm một sản phẩm loại này, mình sẽ không bán phần "copy". Mình bán bốn thứ mà việc copy không lấy được:
Chọn ai để theo. Đây là quyết định lớn nhất và là thứ khách dở nhất. Không phải chọn người có lãi cao nhất — chọn người có hành vi đọc được: nhịp độ ổn định, kích thước lệnh nhất quán, có lịch sử ra lệnh rõ ràng, không có dấu hiệu đổi chiến lược liên tục. Một người lãi 300% bằng ba cú đặt cược tất tay là dữ liệu rác để copy, không phải hình mẫu.
Định cỡ. Bao nhiêu phần trăm mỗi lệnh, trần tổng, trần theo từng nhóm tương quan. Đây là chỗ duy nhất khách thật sự kiểm soát được số phận mình, nên nó phải là một con số khách đặt, không phải một con số hệ chọn hộ.
Luật ra độc lập. Cửa ra không được phụ thuộc vào việc người kia có ra hay không. Nó phải có điều kiện riêng: mức lỗ tối đa, thời hạn nắm giữ, hoặc một điều kiện vô hiệu hoá luận điểm. Không có luật ra riêng thì bạn đang thuê người khác giữ tiền hộ mình mà không có hợp đồng.
Công tắc ngắt đã test. Không phải nút có trên giao diện. Là cái đã được bấm thử, đo được mất bao nhiêu giây để dừng hẳn, và biết chắc là dừng rồi thì không còn lệnh nào đang bay.
Hợp đồng sao chép — pseudo-code, không phải nguồn triển khai
Đây là khung mình hay dùng khi phải thiết kế một hệ "làm theo". Nó không phải code thật, chỉ là cách mình viết ra để không tự lừa mình:
copy_contract = {
copy_from: điều kiện đủ để coi là tín hiệu (không phải mọi lệnh đều là tín hiệu)
max_size: trần tuyệt đối cho một lần, tính theo % tổng, không theo số tuyệt đối
entry_guard: nếu giá đã trượt quá X so với lúc phát hiện -> KHÔNG vào
exit_rule: luật ra riêng, không phụ thuộc người được copy
on_unknown: trạng thái không xác định -> đứng ngoài, không đoán
kill_switch: điều kiện tự dừng + người xác nhận dừng
}
mỗi lần chạy:
nếu tín hiệu không đạt copy_from -> bỏ qua, ghi log là "đã bỏ qua vì lý do gì"
nếu giá đã trượt quá entry_guard -> bỏ qua, KHÔNG đuổi
nếu tổng vị thế vượt max_size -> không tăng
nếu exit_rule đã kích hoạt -> ra, kể cả khi người kia vẫn đang giữ
nếu trạng thái không xác định -> giữ nguyên, không làm gì, báo người
nếu kill_switch kích hoạt -> dừng toàn bộ, không tự bật lạiBốn dòng "bỏ qua" trong khung đó quan trọng hơn toàn bộ phần còn lại. Vì một hệ chỉ có đường tiến thì không phải automation, nó là một cái ống.
Bốn câu hỏi trước khi bật
Nếu bạn đang cân nhắc dựng hoặc mua một thứ như vậy, mình nghĩ chỉ cần trả lời được bốn câu này là đủ để biết mình đang làm gì:
1. Mình đang copy hành động hay copy lý do? Nếu là hành động, hãy nói thẳng với chính mình: mình đang đặt cược vào việc người kia tiếp tục hành xử y hệt. Không phải vào việc họ đúng.
2. Nếu người kia đứng ngoài ba tuần thì bot của mình làm gì? Nếu câu trả lời là "không làm gì cả, và điều đó ổn", hệ của bạn có trạng thái đứng ngoài. Nếu là "vẫn phải chạy cái gì đó", bạn đang tối ưu nhầm thứ.
3. Khoản lỗ lớn nhất trong một ngày mình chấp nhận là bao nhiêu, và cái gì chặn nó bằng code? Không phải bằng lời dặn. Bằng code.
4. Ai bấm dừng, và mất bao nhiêu giây? Nếu chưa ai bấm thử, bạn chưa có công tắc ngắt. Bạn có một nút trang trí.
Cái mình rút ra, và nó không chỉ đúng với tiền
Chuyện copy ví chỉ là phiên bản có tính tiền của một lỗi mình gặp ở khắp nơi: khi thấy một hệ chạy tốt, mình chép phần nhìn thấy được — các bước, các lệnh, các công cụ — và bỏ lại phần không nhìn thấy được: tiêu chí chọn đầu vào, điều kiện dừng, và câu "khi nào thì không làm gì".
Phần bỏ lại đó mới là phần đắt. Nó là lý do một quy trình chạy được, và nó không nằm trong file cấu hình nào để mình tải về.
Nên mỗi lần thấy một sản phẩm automation hứa "copy nguyên cái này là xong", mình không hỏi nó chạy nhanh không. Mình hỏi: nó biết lúc nào không nên chạy chưa?
Nếu chưa, thì nó chưa phải automation. Nó chỉ là một cái tay rất khoẻ, nối vào một cái đầu không có ở đó.
Anh em đã từng copy một setup của người khác rồi thấy nó không ra kết quả chưa? Hoặc ngược lại — có cái gì copy được thật và vẫn chạy tốt? Mình tò mò nhất là mấy case thứ hai, vì mình chưa gặp nhiều. Để lại dưới comment nhé.