Trang chủHome / Bài viếtWriting / Công cụTools
Dựng công cụ đầu tiên bằng AI khi không biết lập trình
Building your first tool with AI when you can’t code
Bài trước tôi viết về cách làm việc với AI và ranh giới đặt ra cho nó. Bài này lùi lại một bước: bạn chưa có công cụ nào, chưa viết dòng code nào, và muốn bắt đầu.
Chọn đúng việc đầu tiên
Việc đầu tiên nên có đủ ba tính chất: bạn làm nó thường xuyên, bạn ghét làm nó, và nó có đầu vào đầu ra rõ ràng.
“Rõ ràng” nghĩa là bạn nói được: nhận vào cái gì, trả ra cái gì.
- Rõ: “đọ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”
- Không rõ: “giúp tôi tối ưu tài khoản”
Việc đầu tiên tốt gần như luôn là một việc bạn đang làm bằng tay mỗi tuần, chứ không phải một ý tưởng hay mà bạn chưa từng làm bao giờ.
Viết quy trình ra giấy trước khi mở AI
Đây là bước hay bị bỏ nhất, và là bước quyết định kết quả.
Ngồi làm việc đó một lần bằng tay, vừa làm vừa ghi: mở màn hình nào, lấy cột nào, so với cái gì, bỏ cái gì đi, kết quả cuối trông ra sao. Viết bằng tiếng Việt, chi tiết tới mức một người mới vào làm đọc là theo được.
Chừng nào bạn còn mô tả mơ hồ, AI sẽ đoán phần thiếu — và nó đoán rất tự tin. Phần khó không nằm ở viết code, nó nằm ở biết chính xác mình muốn gì.
Bắt đầu từ file xuất ra, đừng bắt đầu từ API
Phiên bản đầu tiên chỉ nên làm hai việc: đọc một file bạn tự tải về, và in kết quả ra màn hình. Không nối API, không xin quyền, không đụng vào tài khoản thật.
Lý do rất thực tế: một công cụ đọc file mà sai thì bạn mất vài phút. Một công cụ nối thẳng vào tài khoản mà sai thì bạn mất tiền của khách.
Khi nào bạn đã tin nó thì hãy tính đến chuyện nối API — và kể cả lúc đó, xin quyền đọc trước, quyền ghi tính sau.
Cách kiểm nó có đúng không
Chạy trên một trường hợp bạn đã biết đáp án: một tháng bạn từng tự làm bằng tay và còn nhớ kết quả.
So từng dòng, đừng chỉ so tổng. Tổng khớp mà chi tiết sai là chuyện rất hay xảy ra — hai sai số ngược chiều triệt tiêu nhau là tổng đẹp ngay.
Chưa khớp thì đừng đem dùng cho việc khác. Một kết quả trông hợp lý mà sai còn tệ hơn một lỗi hiện rõ: lỗi thì bạn sửa, còn cái sai êm thì bạn tin.
Bốn cái bẫy hay gặp nhất
- Nhờ AI làm cả hệ thống trong một lần. 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. Làm từng mảnh nhỏ, mỗi mảnh dùng được ngay, rồi mới chồng mảnh tiếp theo.
- Để khóa API nằm trong code. Đưa vào 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ỗ người mới hỏng nhiều nhất, và hỏng thì không sửa được bằng cách xoá — phải xoay khoá.
- Tin một con số vì nó trông hợp lý. Xem mục trên.
- Không lưu lại quy trình và câu lệnh đã dùng. Ba tháng sau cần sửa, bạn sẽ không nhớ vì sao nó làm như thế. Lưu cùng chỗ với code.
Khi nào thì dừng
Công cụ nội bộ không cần đẹp, không cần người khác dùng được, không cần chạy trên mây.
Nó xong khi thời gian nó tiết kiệm cho bạn nhiều hơn thời gian bạn bỏ ra để nuôi nó.
Vượt qua điểm đó mà vẫn thêm tính năng thì bạn không còn đang làm công cụ nữa — bạn đang làm sản phẩm. Đó là một quyết định khác hẳn, và nên được quyết một cách có ý thức chứ không phải trôi vào.
The previous post was about how I work with AI and the line I draw around it. This one steps back: you have no tools yet, you’ve never written a line of code, and you want to start.
Pick the right first job
The first job should have all three properties: you do it often, you hate doing it, and it has a clear input and output.
“Clear” means you can state what goes in and what comes out.
- Clear: “read this search terms export, print the 50 terms with the most spend and no conversions”
- Not clear: “help me optimise the account”
A good first job is almost always something you already do by hand every week — not a good idea you have never actually done.
Write the process down before you open an AI
This is the step people skip most, and the one that decides the outcome.
Sit down and do the job once by hand, writing as you go: which screen you open, which column you take, what you compare it against, what you discard, what the final output looks like. Write it in plain language, detailed enough that a new hire could follow it.
As long as your description stays vague, the AI will guess the missing parts — and it guesses very confidently. The hard part isn’t writing code; it’s knowing exactly what you want.
Start from an export, not from an API
Version one should do exactly two things: read a file you downloaded yourself, and print the result to the screen. No API, no permissions, nothing touching a live account.
The reason is practical: a file-reading tool that’s wrong costs you a few minutes. A tool wired into a live account that’s wrong costs your client money.
Once you trust it, then consider connecting the API — and even then, ask for read access first and write access much later.
How to check whether it’s right
Run it against a case where you already know the answer: a month you did by hand and still remember.
Compare row by row, not just the total. A matching total with wrong details is very common — two errors in opposite directions cancel out and the total looks fine.
Until it matches, don’t use it anywhere else. A result that looks reasonable but is wrong is worse than a visible error: an error you fix, a quiet mistake you believe.
The four traps people hit most
- Asking the AI for the whole system at once. What comes back is a pile of working code that solves no particular job. Build small pieces, each usable immediately, then stack the next one on top.
- Leaving API keys in the code. Put them in environment variables. Don’t let the AI paste them into a file you later push somewhere by accident. This is where beginners get burned most, and you can’t fix it by deleting — you have to rotate the key.
- Believing a number because it looks reasonable. See above.
- Not saving the process and the prompts you used. Three months later you’ll need to change it and won’t remember why it works that way. Store them alongside the code.
When to stop
An in-house tool doesn’t need to be pretty, doesn’t need to work for anyone else, doesn’t need to run in the cloud.
It’s finished when the time it saves you exceeds the time you spend keeping it alive.
Keep adding features past that point and you’re no longer building a tool — you’re building a product. That’s an entirely different decision, and it deserves to be made deliberately rather than drifted into.