Bài này nằm trong chuỗi mổ xẻ kỹ thuật tại zeodavu.com/blog. Mình từng nghĩ câu chuyện tự động hoá rất đơn giản: chọn model xịn là xong. Rồi mình vấp, và hoá ra thứ giết một hệ thống tự động hoá không phải là prompt, không phải là model — mà là cái khung đằng sau nó. Bài này kể về cái "máy" mình dựng để mỗi ngày bắt các ý tưởng làm tiền, vì sao nó chết hai lần, và điều mình rút ra để sửa lại.
Nói về "dùng AI để làm tiền", đa số người mới hình dung một khung cảnh rất hào nhoáng: một con bot thông minh, một câu lệnh thần thánh, và tiền tự động chảy vào. Mình cũng từng tin vậy. Thế nên khi mình dựng một hệ thống mỗi ngày quét một đống nguồn tin trên mạng — từ các diễn đàn công nghệ tới các bản tin về no-code, automation, AI agent — mình cứ nghĩ phần khó nhất là chọn đúng con AI.
Mình sai.
Phần khó nhất hoá ra là phần không hề dùng trí tuệ nhân tạo. Và bài này kể vì sao.
Kịch bản thất bại: "nghe mạnh, chạy thì vỡ"
Ban đầu mình dùng một nền tảng AI assistant qua trình duyệt — kiểu mở một tab ra, đăng nhập, rồi hỏi nó đọc và tổng hợp tin. Nghe rất mượt. Nhưng khi mình giao cho nó một việc thật — quét hàng loạt nguồn, mỗi ngày — thì mọi thứ toé ra.
Vấn đề đầu tiên là ngữ cảnh không được mapping. Mình đưa nó mười nguồn tin, nó trả về mười cái tóm tắt, mỗi cái như thể nó chưa từng thấy phần còn lại. Không có sự nối: nguồn này liên quan tới nguồn kia ra sao, đâu là ý chính, đâu là trùng lặp. Nó đọc từng cái riêng lẻ, rồi bỏ cuộc trước việc "nối dây" — đúng cái phần làm nên giá trị của một bản tin.
Vấn đề thứ hai tệ hơn: nó bắt mình thao tác tay. Mỗi lần research xong, nó đưa ra một file rồi yêu cầu mình tải xuống. Tải xong, mình phải tự cất vào chỗ lưu trữ riêng, rồi mới dùng được. Nói trắng ra: cái "máy tự động" mà mình định dựng, thực tế vẫn cần mình đứng canh từng bước — kích hoạt, chờ, tải, cất. Cái việc mình định giao hết cho máy, cuối cùng mình vẫn làm phần lớn.
Đây mới là chỗ đau. Vì nó không phải vấn đề của "model xịn hay không". Đó là thứ model xịn mấy cũng không cứu được — vì cái workflow đằng sau nó đã sai từ bản thiết kế.
Một model giỏi đặt vào một cái quy trình tồi, vẫn cho ra kết quả tồi. Cái "chất xám" nằm ở đúng chỗ, nhưng đường nước chảy thì tắc.
Chẩn đoán: bill và độ tin cậy đều là vấn đề kiến trúc
Khi mình gỡ lại từng lớp, một điều rõ dần: mình đang đổ hết trách nhiệm lên prompt và model, trong khi hai thứ đó rất ít liên quan tới nút thắt thật.
Nút thắt thứ nhất là chi phí được tính theo cách sai. Mọi người cứ bàn về "prompt thế nào cho rẻ", nhưng gần như cái bill của mình không nằm ở prompt. Nó nằm ở chỗ: mình gọi model cho toàn bộ mọi thứ, kể cả những việc một quy tắc cơ bản làm được. Đọc mười nguồn, phân loại "cái nào liên quan", loại bỏ những thứ hiển nhiên là nhiễu — những bước đó đâu cần tới một con AI. Vậy mà mình cứ mở nó ra cho model bò từng cái. Bill leo lên, mà phần "suy nghĩ" thật thì lại loãng.
Nút thắt thứ hai là độ tin cậy. Mình muốn cái máy chạy đều, không nổ giữa chừng, không lúc thì hiểu lúc thì không. Nhưng khi mọi bước đều phó thác cho model, thì mỗi bước là một chỗ "mò", và xác suất lệch cộng dồn lên. Một cái workflow mà mỗi mắt xích đều đoán già đoán non thì không bao giờ chạy ổn định. Muốn ổn định, bạn cần một phần xác định — deterministic — nơi mà cùng một đầu vào luôn cho cùng một đầu ra, không mơ hồ, không tốn token.
Đến đây mình nhận ra mình cần thứ người ta hay gọi là một tầng vận hành chung: một nơi quy định rõ ai làm gì trong dòng chảy, bước nào là "chắc chắn", bước nào mới cho model xen vào.
Cách sửa: đặt một tầng lọc "cứng" trước khi mở model
Thay vì thay model, mình sửa lại cái khung. Yêu cầu đặt ra: model chỉ làm đúng phần nó giỏi; phần còn lại là logic cứng, rẻ gần như không.
Cấu trúc mình đi tới là một vòng lặp hai tầng:
Tầng một — bộ lọc thô, gần như không tốn token. Đây là luật, không phải AI. Nó quyết định bằng quy tắc đơn giản: nguồn nào là nhiễu (danh sách bài học tổng hợp, benchmark, bug-fix kỹ thuật thuần), nguồn nào có dấu hiệu "làm tiền / tự động hoá" (từ khoá như workflow, agent, no-code, project, gọi tốn tiền...). Bước này chạy bằng so khớp, không gọi model, nên chi phí gần như về không.
Tầng hai — để model đánh giá phần còn lại. Chỉ những mục vượt qua tầng một mới được đưa lên model, kèm đúng bối cảnh. Model giờ không phải lọc mớ hỗn độn hai mươi mục, mà chỉ đánh giá sâu vài mục thật sự liên quan. Nhờ vậy, "suy nghĩ" của nó tập trung hơn, góc nhìn sắc hơn, và token bỏ ra phục vụ đúng việc nó giỏi.
# pseudo-code minh hoạ — KHÔNG phải nguồn triển khai
def daily_digest(feed_items):
# TẦNG 1: lọc thô bằng quy tắc, gần như 0 token
no_noise = [it for it in feed_items if not is_obvious_noise(it)]
relevant = [it for it in no_noise if has_money_signal(it)]
# TẦNG 2: model chỉ đọc phần đã lọc, kèm bối cảnh gộp lại
context = join_with_links(relevant) # giữ mối liên hệ giữa các mục
return ai_model("Đánh giá và chi ra mục đáng hành động:
" + context)Đừng để con AI làm việc mà một câu
iflàm được. Tiền và độ tin cậy đều nằm ở việc trả đúng việc cho đúng tầng.
Mình còn bổ sung hai mảnh nhỏ nhưng ăn đứt hiệu quả:
Thứ nhất, giới hạn quyền của agent — thứ người ta gọi là "guardrails". Trước kia agent tự do bay khắp nơi, gọi đủ loại thao tác. Giờ nó chỉ được gọi một số hành động nhất định, và mình biết chính xác nó được phép làm gì. Giảm quyền, tăng kiểm soát — không phải vì sợ, mà vì một cái máy chạy trong phạm vi rõ ràng bao giờ cũng đáng tin hơn.
Thứ hai, chọn nơi gọi model và thời điểm gọi cho đúng. Mình bỏ việc chạy model ở chỗ nào cũng được, và dời những tác vụ lớn sang đúng nơi mà giá "rẻ theo cách vận hành": phần lặp lại cố định thì đưa vào cache, phần gấp thì ưu tiên, phần không gấp thì chạy a-fo-kên. Không phải mẹo giảm giá nhỏ lẻ — mà là kiến trúc sinh ra để không phí.
Nâng lên: đây là cái "tầng vận hành chung" cho mọi workflow làm tiền
Cái mình học từ cái máy tìm ý tưởng này không dừng ở riêng nó. Nó là bài học cho bất kỳ ai muốn dùng AI để chạy một quy trình lặp lại sinh ra giá trị.
Ba điều gói lại được:
1. Chi phí là chuyện kiến trúc, không phải chuyện prompt. Trước khi hỏi "sao bill cao", hãy hỏi "mình có đang gọi model cho việc không cần model không". Phần lớn cái giá bạn trả thường nằm ở những bước lẽ ra một quy tắc làm được. Chia nhỏ ra, dịch phần "cứng" sang logic, model chỉ giữ phần "mềm".
2. Độ tin cậy đến từ quyết định, không đến từ "cái siêu". Một cái agent tin cậy không phải là một cái agent bất khả chiến bại. Nó là một cái agent chạy trong một dòng chảy mà bạn biết trước từng bước, trong đó phần mạnh (model) được đặt vào đúng chỗ, phần yếu (tùy hứng) được đặt sau một cái đệm cứng. Cái mà người ta gọi là "deterministic control flow" — mình gọi là phần mình ngủ ngon vì nó không mò.
3. Đừng để agent "bới" món dữ liệu bẩn. Cái máy của mình từng fail vì ngữ cảnh không được nối. Dữ liệu dính, thiếu liên kết, không chuẩn hoá — là thứ làm agent chết ngay lập tức, chẳng cần tới model tồi. Trước khi đưa AI vào bất kỳ quy trình số liệu nào (một CRM, một kho sản phẩm, một bộ nguồn tin), hãy kiểm tra đã có "hồ sơ sạch" chưa, đã có bản đồ liên kết chưa. Đó là bước mà nhiều người bỏ qua và trả giá.
Tự động hoá không phải là để con AI làm mọi thứ. Nó là để con AI làm đúng phần, và bạn làm chắc phần còn lại — một cách có chủ đích.
Kết luận
Cái mình đem về từ câu chuyện này không phải "có một mẹo giảm giá". Mà là một cách nhìn: trước khi đổ lỗi cho model hay prompt, hãy xem lại cái khung.
Nếu bạn đang dựng một con bot, một cái máy tổng hợp tin, một quy trình tự động để làm tiền — hãy bắt đầu bằng cách vẽ ra dòng chảy, rồi hỏi từng bước: bước này có cần một con AI không? Đâu là chỗ một quy tắc làm được rẻ hơn, chắc hơn, nhanh hơn? Bạn sẽ bất ngờ vì hoá ra một nửa cái giá và một nửa sự rủi ro nằm ở những bước "cứng" mà bạn từng giao cho model.
Cái máy tìm ý tưởng làm tiền của mình giờ chạy mỗi ngày, chi phí gần như không đáng kể, và đáng tin hơn nhiều. Không phải vì model xịn hơn — mà vì mình biết đưa đúng việc cho đúng tay.
Ba điều mình rút ra:
- ▹Tách phần "cứng" khỏi phần "mềm" trong mọi workflow. Logic, lọc, định tuyến, lưu trữ — để ở tầng cứng. Đánh giá, góc nhìn, tổng hợp — mới gọi model.
- ▹Giới hạn quyền của agent. Một agent chạy trong ranh giới rõ ràng là một agent đáng tin.
- ▹Chuẩn bị dữ liệu trước khi đưa AI vào. Ngữ cảnh nối tốt, dữ liệu sạch — là thứ làm agent sống, không phải prompt.
Bài này cố ý không nêu tên nền tảng, provider, hay đoạn code cụ thể. Mỗi code block là minh hoạ cơ chế, không phải source triển khai. Điều đáng giữ là cách nhìn ra "đâu là nơi một con AI nên đứng" — không phải một công cụ hay một con số giá.
Toàn bộ trải nghiệm mình ghi lại ở zeodavu.com/blog.
Một phần của chuỗi mổ xẻ kỹ thuật tại zeodavu.com/blog. Nội dung là bài học mở, không phải blueprint để sao chép — thứ đáng giữ là cách tư duy, không phải danh sách công cụ.
Nếu thấy hữu ích, theo dõi zeodavu.com — mỗi bài là một thứ mình thật sự dùng, vấp, và sửa lại.