Trang chủHome / Bài viếtWriting / Công cụTools

Để AI viết công cụ, nhưng người vẫn là người bấm nút

Let AI write the tool, but a person still presses the button

5 tháng 9, 20265 September 2026 · Công cụTools · 6 phút đọc4 min read

Tôi không phải dân lập trình. Tôi là người chạy quảng cáo. Nhưng hiện tại chúng tôi có năm công cụ tự viết — ba cái chạy hằng ngày trong nội bộ, hai cái đang làm dở — và gần như toàn bộ phần code là do AI viết dưới sự chỉ đạo của tôi.

Bài này là về cách làm việc đó, và quan trọng hơn, về ranh giới tôi đặt ra cho nó.

Vì sao lại tự viết

Phần lớn công việc chạy quảng cáo là việc lặp lại. Đọc báo cáo. Tìm từ đang lãng phí. Viết biến thể quảng cáo mới. Đối chiếu số liệu giữa các tài khoản. Không có việc nào trong đó khó về mặt trí tuệ. Chúng chỉ tốn thời gian, và tốn đúng loại thời gian mà đáng lẽ nên dành cho phần cần suy nghĩ.

Có công cụ sẵn trên thị trường làm được phần lớn những việc này. Vấn đề là chúng được thiết kế cho quy trình trung bình của mọi người, còn quy trình của tôi thì không trung bình. Cuối cùng tôi vẫn phải xuất dữ liệu ra rồi xử lý tay — tức là trả tiền cho công cụ để vẫn làm việc bằng tay.

Cách tôi thật sự làm việc với AI

Bắt đầu bằng quy trình, không bằng phần mềm

Cách hỏng nhanh nhất là mở AI ra và bảo “viết cho tôi công cụ quản lý Google Ads”. Cái nhận về là một đống code chạy được nhưng không giải quyết đúng việc nào cả.

Cách đúng: viết ra bằng tiếng Việt, thật chi tiết, cái việc tôi đang làm bằng tay. Mở màn hình nào, lấy cột nào, so với cái gì, quyết định thế nào, xuất ra dạng gì. Khi tôi mô tả được quy trình đến mức một người mới vào làm cũng theo được, thì AI cũng dựng được. Chừng nào tôi còn mô tả mơ hồ, AI sẽ đoán — và nó đoán rất tự tin.

Phần khó không phải là viết code. Phần khó là biết chính xác mình muốn gì. AI xóa bỏ phần đầu, và làm lộ ra rằng phần sau mới là việc thật.

Làm từng mảnh nhỏ, chạy được ngay

Tôi không bao giờ đặt hàng một hệ thống hoàn chỉnh. Tôi làm một việc nhỏ nhất mà đã có ích: “đọc file báo cáo cụm từ tìm kiếm này, in ra 50 cụm tiêu nhiều tiền nhất mà không có chuyển đổi”. Chạy được, dùng thử một tuần, rồi mới thêm phần tiếp theo.

Cách này chậm hơn trên giấy nhưng nhanh hơn trong thực tế, vì mỗi mảnh đều được kiểm chứng bằng công việc thật trước khi có mảnh kế tiếp chồng lên.

Luôn kiểm tra đầu ra bằng một trường hợp mình đã biết đáp án

Đây là thói quen tôi mang từ nghề quảng cáo sang. Trước khi tin bất kỳ con số nào công cụ đưa ra, tôi chạy nó trên một tài khoản mà tôi đã tự đọc bằng tay và biết kết quả phải ra sao. Nếu hai bên khớp, tôi mới dùng nó cho tài khoản khác.

Thứ đáng sợ không phải là công cụ báo lỗi — lỗi thì thấy ngay. Đáng sợ là nó đưa ra một danh sách trông hoàn toàn hợp lý trong khi đang bỏ sót thứ gì đó, chẳng hạn các chuyển đổi được ghi nhận trễ. Cắt theo danh sách đó là cắt nhầm mà không hề biết. Một công cụ sai nhưng trông đúng thì nguy hiểm hơn một công cụ không chạy.

Ranh giới: máy đề xuất, người quyết định

Đây là phần quan trọng nhất của bài viết này.

Về mặt kỹ thuật, không có gì ngăn tôi cho công cụ tự động áp dụng thay đổi lên tài khoản — tự thêm từ khóa phủ định, tự chỉnh ngân sách, tự tắt nhóm quảng cáo kém. API cho phép, và code thì đã có sẵn.

Tôi không làm vậy, và sẽ không làm.

Công cụ của chúng tôi đề xuất. Người đọc đề xuất đó, đối chiếu với thứ mà máy không biết, rồi bấm nút. Chưa bao giờ có chuyện phần mềm tự đổi ngân sách của khách lúc nửa đêm.

Lý do không phải vì tôi sợ công nghệ. Có ba lý do rất cụ thể:

Máy không biết bối cảnh ngoài tài khoản. Nó không biết khách sắp hết hàng, không biết tuần sau có đợt khuyến mãi, không biết một dòng sản phẩm đang bị nhà cung cấp cắt. Những thứ đó thay đổi hoàn toàn quyết định đúng.
Sai lầm tự động thì lan nhanh. Một người làm sai một chiến dịch. Một script sai làm sai cả tài khoản, trong lúc không ai nhìn, và bạn chỉ phát hiện khi tiền đã đi.
Trách nhiệm phải có địa chỉ. Khi khách hỏi vì sao ngân sách đổi hôm thứ Ba, câu trả lời phải là một cái tên và một lý do, không phải “hệ thống tự động điều chỉnh”.

Mọi thay đổi trên tài khoản khách đều được ghi lại và gửi cho họ. Đó là một trong bốn điều chúng tôi cam kết bằng văn bản, và nó chỉ giữ được nếu con người thật sự là người ra quyết định cuối cùng.

Nếu bạn muốn thử tự dựng công cụ của mình

Vài điều tôi ước có ai nói với mình sớm hơn:

Bắt đầu từ việc bạn ghét làm nhất và làm nhiều nhất. Đó gần như luôn là ứng viên tốt nhất, vì bạn hiểu nó tường tận và bạn sẽ dùng nó thật.
Đừng đụng vào tài khoản thật ở phiên bản đầu. Cho công cụ đọc file xuất ra trước. Khi nào bạn tin nó rồi hãy tính đến chuyện nối API, và kể cả khi đó cũng nên chỉ xin quyền đọc.
Giữ bí mật ra khỏi code. Khóa API, thông tin đăng nhập — để ở biến môi trường, đừng để AI gắn thẳng vào file rồi vô tình đẩy lên đâu đó. Đây là chỗ dễ hỏng nhất với người mới.
Viết lại bằng lời quy trình trước khi viết prompt. Nếu bạn không diễn đạt được thành lời, công cụ sinh ra sẽ là phiên bản code hóa của sự mơ hồ đó.

Xem thêm

Trang công nghệ của ALFA Media nói rõ từng công cụ làm được gì — và cái nào cố ý không làm gì. Xem tại đây.

I’m not a programmer. I run ads. But we currently have five tools we wrote ourselves — three running daily in-house, two unfinished — and almost all of the code was written by AI under my direction.

This post is about how that works, and more importantly, about the line I draw around it.

Why build them at all

Most of running ads is repetitive. Reading reports. Finding wasted terms. Writing new ad variants. Reconciling numbers across accounts. None of it is intellectually hard. It just costs time — and exactly the kind of time that should be going to the part that needs thinking.

There are off-the-shelf tools that do most of this. The problem is they’re designed for the average person’s process, and mine isn’t average. I’d end up exporting the data and finishing by hand anyway — which is paying for a tool in order to still do the work manually.

How I actually work with AI

Start with the process, not the software

The fastest way to get this wrong is to open an AI and say “build me a Google Ads management tool.” What comes back is a pile of working code that solves no particular problem.

The right way: write out, in plain language and in detail, the thing I do by hand. Which screen I open, which column I take, what I compare it against, how I decide, what I output. Once I can describe the process well enough for a new hire to follow it, AI can build it. As long as I stay vague, AI will guess — and it guesses very confidently.

The hard part isn’t writing code. The hard part is knowing exactly what you want. AI removes the first part, and reveals that the second was always the real work.

Build in small pieces that run immediately

I never order a complete system. I build the smallest thing that is already useful: “read this search terms export, print the 50 terms with the most spend and no conversions.” Get it running, use it for a week, then add the next piece.

On paper this is slower; in practice it’s faster, because every piece is checked against real work before the next one is stacked on top of it.

Always test the output against a case where you know the answer

This is a habit I brought over from the ads side. Before trusting any number a tool produces, I run it against an account I’ve already read by hand and know the answer for. If the two match, then I use it elsewhere.

The frightening case isn’t a tool that throws an error — you see those immediately. It’s a tool that hands you a list looking entirely reasonable while it is quietly missing something, say conversions recorded with a delay. Cut against that list and you cut the wrong things without ever knowing. A tool that is wrong but looks right is more dangerous than a tool that doesn’t run.

The line: the machine proposes, the person decides

This is the most important part of this post.

Technically nothing stops me from letting a tool apply changes to an account by itself — add negatives, adjust budgets, pause weak ad groups. The API allows it, and the code already exists.

I don’t, and I won’t.

Our tools propose. A person reads the proposal, weighs it against what the machine can’t know, and presses the button. Software has never changed a client’s budget at midnight on its own.

Not because I’m afraid of the technology. Three specific reasons:

The machine doesn’t know the context outside the account. It doesn’t know the client is about to run out of stock, that there’s a promotion next week, that a supplier just dropped a product line. Those change what the correct decision is entirely.
Automated mistakes spread fast. A person gets one campaign wrong. A wrong script gets the whole account wrong, while nobody is watching, and you find out after the money is gone.
Accountability needs an address. When a client asks why the budget changed on Tuesday, the answer has to be a name and a reason, not “the system adjusted automatically.”

Every change on a client account is logged and sent to them. That’s one of the four things we commit to in writing, and it only holds if a human is genuinely the one making the final call.

If you want to build your own

A few things I wish someone had told me sooner:

Start with the task you hate most and do most often. It’s almost always the best candidate, because you understand it thoroughly and you’ll actually use the result.
Don’t touch a live account in version one. Let the tool read an export first. Once you trust it, consider connecting the API — and even then, ask only for read access.
Keep secrets out of the code. API keys, logins — put them in environment variables. Don’t let AI paste them straight into a file that you then push somewhere by accident. This is where beginners get burned most.
Write the process out in words before you write the prompt. If you can’t put it into words, the tool you get will be a code-shaped version of that same vagueness.