Ước tính chi phí xây dựng AI theo tính năng: phương pháp ngân sách đơn giản

Tại sao chi phí xây dựng AI lại cảm thấy khó đoán

Việc xây dựng có trợ giúp bởi AI ban đầu có vẻ rẻ cho đến khi bỗng nhiên không còn rẻ nữa. Đó là vì bạn không trả cho một mức giá cố định cho tính năng. Bạn trả cho các lần thử: tin nhắn, mã sinh ra, chỉnh sửa, kiểm thử và làm lại. Khi kế hoạch mơ hồ, số lần thử tăng rất nhanh.

Hầu hết các đột biến chi phí đến từ một vài mẫu phổ biến:

• Phạm vi được ngầm định, không viết ra (ví dụ, "thêm auth" mà không có role, nhà cung cấp, hoặc đặt lại mật khẩu).

• Các lần thử chồng lên (một prompt gần đúng dẫn đến 3–10 lần theo dõi).

• Thay đổi spec giữa chừng (thêm trường, màn hình mới, quy tắc khác), khiến công việc cũ bị thay thế.

• Yêu cầu ẩn xuất hiện muộn (tải dữ liệu, validation, các edge case, trạng thái lỗi).

• "Thêm một chỉnh sửa nữa" lặng lẽ biến thành thiết kế lại trên nhiều màn hình.

Khi ước tính, hãy rõ ràng về những gì bạn đang thực sự đưa vào ngân sách:

1. Credits hoặc đơn vị sử dụng nền tảng của bạn thu phí
2. Tokens (kích thước prompt và output)
3. Thời gian (thời gian bạn xem xét, kiểm thử và sửa lỗi)

Xem bất kỳ ước tính nào là một khoảng, không phải một con số duy nhất. Một tính năng có thể trông nhỏ ở UI nhưng lại lớn về logic, hoặc ngược lại. Trường hợp tốt nhất là một bản nháp đầu đủ. Trường hợp xấu nhất là vài vòng sửa.

Phần còn lại của hướng dẫn này dùng các nhóm tính năng lặp lại: auth, CRUD, integrations, và redesign UI. Nếu bạn dùng nền tảng kiểu credit-based vibe-coding như Koder.ai (koder.ai), bạn sẽ cảm nhận điều này nhanh: bắt đầu với "build a dashboard" rồi sau đó thêm roles, audit logs, và layout mới sẽ tiêu nhiều credits hơn nhiều so với việc viết những ràng buộc đó ngay từ đầu.

Credits và tokens nói một cách đơn giản

Mọi người thường trộn ba ý tưởng khác nhau: tokens, credits và bước xây dựng. Tách chúng ra làm chi phí dễ đoán hơn.

Một token là một đoạn nhỏ văn bản mà mô hình đọc hoặc viết. Prompt của bạn dùng token, phản hồi của mô hình dùng token, và một lịch sử chat dài cũng dùng token vì mô hình phải đọc lại nó.

Một credit là đơn vị thanh toán mà nền tảng bạn dùng tính. Trên các công cụ như Koder.ai, credits thường bao gồm việc sử dụng mô hình cộng với công việc nền của nền tảng phía sau chat (ví dụ, agent chạy tác vụ, tạo file và kiểm tra kết quả). Bạn không cần biết chi tiết nội bộ để lập ngân sách, nhưng bạn cần nhận ra điều gì làm usage tăng lên.

Một bước xây dựng là một thay đổi có ý nghĩa cho dự án: "thêm đăng nhập email," "tạo bảng users," hoặc "nối màn hình này với endpoint." Một tính năng thường cần nhiều bước, và mỗi bước có thể kích hoạt nhiều lần gọi mô hình.

Usage tăng nhanh nhất khi bạn có ngữ cảnh dài (spec lớn, lịch sử chat đồ sộ, nhiều file được tham chiếu), nhiều vòng lặp, output lớn (viết lại file đầy đủ, khối mã lớn), hoặc yêu cầu mơ hồ buộc mô hình phải đoán.

Những thay đổi nhỏ trong prompt có thể thay đổi chi phí vì chúng làm thay đổi số lần thử bạn cần. "Một hệ thống auth hoàn chỉnh" mời gọi các tùy chọn bạn không yêu cầu. "Chỉ email và mật khẩu, không social login, đúng hai màn hình" cắt giảm các phần chuyển động.

Một quy tắc giữ vững: càng ít phần chuyển động càng ít lần thử.

Cách ước tính theo tính năng trước tiên

Ngừng ước tính theo "màn hình" hay "tin nhắn." Ước tính theo các tính năng mà người dùng sẽ gọi to thành lời. Điều đó gắn ngân sách với kết quả, chứ không phải với mức độ nói nhiều của quá trình xây dựng.

Với mỗi tính năng, ước tính ba phần:

• Build: sinh mã và nối nó vào app
• Test: chạy luồng, sửa lỗi rõ rệt, xử lý các edge case chính
• Revise: lần sửa thứ hai sau khi bạn thấy nó hoạt động (chỉnh copy, validation, sửa UX nhỏ)

Hầu hết vượt ngân sách xảy ra ở testing và revise, không phải ở bản nháp đầu.

Dùng khoảng cho mỗi phần: low (đơn giản), typical (một vài lần qua lại), high (bất ngờ). Nếu nền tảng bạn tính theo credit, theo dõi bằng credits. Nếu bạn theo dõi tokens trực tiếp, theo dõi tokens. Ý nghĩa vẫn là một dự báo giữ trung thực khi thực tế thay đổi.

Hai dòng giúp tránh tự làm tăng chi phí:

1. Unknowns buffer (10–20%) như một dòng riêng. Đừng giấu nó bên trong các tính năng.

2. Later changes requested như một hạng mục riêng cho ý tưởng mới sau khi một tính năng được chấp nhận ("thêm teams", "làm dashboard giống X"). Nếu bạn không tách nó ra, cuối cùng bạn sẽ đổ lỗi cho ước tính ban đầu về sự tăng trưởng bình thường của phạm vi.

Đây là template nhẹ bạn có thể sao chép:

Feature: Password login
- Build:    low 30 | typical 60 | high 120
- Test:     low 15 | typical 30 | high 60
- Revise:   low 10 | typical 20 | high 40
Subtotal (typical): 110

Buffer (15%): 17
Later changes (held): 50

Lặp lại cho từng tính năng (auth, CRUD, một integration, một UI refresh). Cộng chúng lại bằng "typical" cho kế hoạch của bạn và "high" như kiểm tra worst-case.

Ước tính các tính năng phổ biến: auth và CRUD

Auth và CRUD trông cơ bản, nhưng tốn kém khi phạm vi mơ hồ. Hãy đối xử chúng như một menu: mỗi tùy chọn thêm chi phí.

Auth: định hình chính xác, đừng chỉ nói "login"

Ghi ra thế nào là "xong" cho kiểm soát truy cập. Các yếu tố lớn nhất là số phương thức đăng nhập và số đường phân quyền.

Hãy cụ thể về:

• Phương thức đăng nhập (email/mật khẩu, magic link, Google, Apple, SSO)
• Roles và quyền (admin/editor/viewer, kèm theo những gì mỗi role có thể làm)
• Quy tắc mật khẩu (độ dài, độ phức tạp, khóa, luồng đặt lại)
• Quy tắc session (hết hạn, đăng xuất, nhớ đăng nhập)
• Vòng đời tài khoản (invite, deactivate/delete, verify email)

Nếu bạn chỉ nói "add auth", bạn sẽ nhận được một giải pháp chung chung rồi sau đó trả tiền để vá các edge case. Quyết định hình dạng ngay từ đầu rẻ hơn.

CRUD: đếm số màn hình và quy tắc, không chỉ bảng

Chi phí CRUD do số thực thể và mức độ hành vi mỗi thực thể cần. Một mô hình thực tế: mỗi entity thường hàm ý 3–6 màn hình (list, detail, create, edit, thỉnh thoảng admin hoặc audit view), cộng công việc API và validation.

Khi bạn scope CRUD, nêu tên các entity và bao gồm trường, kiểu và quy tắc validation (bắt buộc, duy nhất, khoảng giá trị). Rồi định nghĩa hành vi danh sách: filter, sort, phân trang, và tìm kiếm. "Tìm kiếm" có thể là filter chứa đơn giản hoặc thứ nặng hơn nhiều.

Cũng quyết định xem màn hình admin có khác màn hình user không. Layout riêng, trường thêm, và hành động hàng loạt có thể gấp đôi khối lượng công việc.

Các edge case làm tăng chi phí nhanh gồm quyền theo hàng, audit logs, import/export CSV, soft delete, và workflow phê duyệt. Tất cả đều làm được, nhưng ngân sách dễ đoán khi bạn chọn rõ ràng trước khi sinh tính năng.

Ước tính integrations mà không đoán mò

Integrations tốn kém vì ẩn công việc. Cách khắc phục là chia chúng thành các bước nhỏ, có thể kiểm thử thay vì "kết nối đến X." Điều đó làm cho ước tính dễ đoán hơn và prompt sạch hơn.

Một phạm vi tích hợp hợp lý thường gồm:

• Kết nối và xác thực (API key hoặc OAuth, refresh token)
• Một đối tượng end-to-end (một request happy-path)
• Hành vi sync (webhook hoặc theo lịch, phân trang, rate limit)
• Xử lý lỗi (retry, idempotency, đường chạy re-run)
• Kiểm thử và edge case (dữ liệu xấu, quyền thiếu, timeout)

Trước khi prompt, khóa data contract. Liệt kê đối tượng và các trường chính xác bạn cần. "Sync customers" là mơ hồ. "Sync Customer{id, email, status} và Order{id, total, updated_at}" giữ mô hình khỏi tự thêm bảng, màn hình và endpoint.

Tiếp theo, quyết định hướng và tần suất. Đồng bộ một chiều (chỉ import) rẻ hơn nhiều so với hai chiều vì hai chiều cần luật xung đột và nhiều kiểm thử hơn. Nếu phải làm hai chiều, chọn luật thắng (nguồn dữ liệu chính, last-write-wins, hoặc duyệt thủ công) ngay từ đầu.

Lập kế hoạch cho thất bại như thể nó chắc chắn xảy ra. Quyết định điều gì xảy ra khi API xuống. Một entry log cộng cảnh báo và nút "re-run sync" thủ công thường là đủ. Giữ tối giản ngăn bạn phải trả cho một hệ thống ops đầy đủ mà bạn không yêu cầu.

Cuối cùng, thêm buffer cho các quirk của bên thứ ba và kiểm thử. Ngay cả API "đơn giản" cũng có phân trang, enum lạ, docs không nhất quán và rate limit. Dự trù thêm 20–40% cho kiểm thử integration và sửa lỗi là thực tế.

Ước tính redesign và thay đổi UI

Công việc UI là nơi ngân sách âm thầm rò rỉ. "Redesign" có thể nghĩa là đổi màu hoặc dựng lại toàn bộ luồng, vì vậy hãy nói rõ những gì thay đổi: layout, component, copy hay bước người dùng.

Tách rõ thay đổi chỉ về mặt hình ảnh khỏi thay đổi ảnh hưởng hành vi. Chỉ chạm visual ảnh hưởng kiểu, khoảng cách và cấu trúc component. Khi bạn thay đổi hành vi một nút, cách validation hoạt động, hoặc cách dữ liệu tải, đó là công việc tính năng.

Scope nó như một danh sách trang

Tránh "redesign toàn bộ app." Liệt kê các màn hình và trạng thái cụ thể. Nếu bạn không thể liệt kê các trang, bạn không thể ước tính.

Giữ phạm vi ngắn và cụ thể:

• Các trang bao gồm (ví dụ: Login, Dashboard, Settings)
• Trạng thái bao gồm (empty, loading, error, success)
• Những gì thay đổi (layout, component, copy, flow)
• Style tham chiếu (một vài ghi chú: màu, typography, khoảng cách)
• Số lần pass cho phép (ví dụ: 1 build pass + 1 polish pass)

Loại prompt này ngăn mô hình đoán thiết kế khắp codebase, điều dẫn đến qua lại.

Đừng bỏ qua các lần QA

Thay đổi UI thường cần ít nhất hai kiểm tra: desktop và mobile. Thêm một pass cơ bản về accessibility (tương phản, focus states, điều hướng bằng bàn phím), ngay cả khi bạn không làm audit đầy đủ.

Một phương pháp ước tính thực tế là:

(số trang) x (độ sâu thay đổi) x (số lần pass)

Ví dụ: 3 trang x độ sâu trung bình (layout mới cộng sửa component) x 2 pass (build + polish) là một khối credits dễ dự đoán. Nếu bạn cũng thay đổi onboarding, hãy coi đó như dòng tính năng riêng.

Bước từng bước: xây một phạm vi đã dự toán trong prompt

Cách rẻ nhất để kiểm soát credits là quyết định bạn muốn gì trước khi yêu cầu mô hình xây. Làm lại là nơi chi phí tăng.

Bắt đầu với một đoạn ngắn mô tả người dùng và mục tiêu. Ví dụ: "Một lễ tân phòng khám nhỏ đăng nhập, thêm bệnh nhân, đặt lịch hẹn, và xem danh sách hôm nay." Điều này đặt ranh giới và ngăn mô hình tự tạo thêm role, màn hình hoặc luồng.

Rồi mô tả sản phẩm như màn hình và hành động, không phải module mơ hồ. Thay vì "module appointments," hãy viết "Màn hình Lịch: tạo, dời lịch, hủy, tìm." Nó làm cho khối lượng công việc có thể đếm được.

Chỉ bao gồm dữ liệu thiết yếu. Bạn chưa cần mọi trường, chỉ những gì làm tính năng thật. Một prompt tốt thường chứa:

• Người dùng và role (ai làm gì)
• Màn hình với hành động (người dùng bấm gì)
• Bảng cốt lõi và trường chính (cần lưu gì)
• Kiểm tra chấp nhận (làm sao biết nó chạy)
• Ngoài phạm vi (những gì không được xây)

Các kiểm tra chấp nhận ngăn bạn phải trả tiền hai lần. Với mỗi tính năng, viết 2–4 kiểm tra như "Người dùng có thể đặt lại mật khẩu qua email" hoặc "Tạo lịch hẹn tránh trùng giờ." Nếu bạn dùng Koder.ai, những kiểm tra đó cũng phù hợp vào Planning Mode trước khi sinh mã.

Hãy rõ ràng về những thứ ngoài phạm vi: "không có admin dashboard," "không có payments," "không đa ngôn ngữ," "không sync lịch ngoài." Điều này ngăn công việc "nice to have" bất ngờ xuất hiện.

Xây nhỏ và ước tính lại sau mỗi phần. Nhịp độ đơn giản: sinh một màn hình hoặc endpoint, chạy nó, sửa lỗi, rồi chuyển tiếp. Nếu một phần tiêu tốn nhiều hơn mong đợi, cắt scope hoặc giảm phần tiếp theo trước khi bạn đi lệch.

Giữ prompt rẻ hơn mà không mất chất lượng

Hầu hết đột biến chi phí đến từ làm quá nhiều trong một tin nhắn. Hãy đối xử với mô hình như đồng đội: brief nó theo bước nhỏ và rõ ràng.

Bắt đầu với kế hoạch, không phải code. Yêu cầu một kế hoạch ngắn có giả định và câu hỏi mở, xác nhận nó, rồi yêu cầu bước triển khai nhỏ đầu tiên. Khi bạn gộp planning, build, test, copywriting, và styling vào một prompt, bạn mời đầu ra dài và nhiều lỗi hơn.

Giữ ngữ cảnh gọn. Chỉ bao gồm màn hình, component, hoặc ghi chú API liên quan cho thay đổi. Nếu bạn dùng Koder.ai, chọn file cụ thể liên quan và tham chiếu tên file. File thừa làm tăng tokens và kéo chỉnh sửa vào các khu vực không liên quan.

Yêu cầu diff nhỏ. Một prompt nên thay đổi một thứ khi có thể: một endpoint, một form, một trạng thái lỗi, một màn hình. Thay đổi nhỏ dễ kiểm tra, và nếu có gì sai bạn không trả tiền cho việc làm lại những phần không liên quan.

Một bộ quy tắc đơn giản:

• Hỏi: trước tiên là kế hoạch, rồi một bước triển khai, rồi checklist review ngắn
• Cung cấp: ngữ cảnh tối thiểu (hành vi hiện tại, hành vi mong muốn, ràng buộc)
• Giới hạn: số lần sửa cố định (ví dụ, hai lần)
• Yêu cầu: tóm tắt ngắn những gì thay đổi để bất ngờ dễ thấy
• Ghi lại: nguyên nhân làm lại và cập nhật template prompt của bạn

Dừng vòng lặp sớm. Nếu lần thử thứ hai vẫn sai, thay đổi input chứ không phải chỉ chỉnh lời. Thêm chi tiết thiếu, bỏ yêu cầu mâu thuẫn, hoặc cho ví dụ thất bại cụ thể. Lặp lại "thử lại" nhiều lần thường đốt tokens mà không tiến gần hơn.

Ví dụ: bạn muốn "login + forgot password" và giao diện đẹp hơn. Làm nó trong ba prompt: (1) phác thảo luồng và màn hình cần, (2) triển khai chỉ auth flow, (3) điều chỉnh khoảng cách UI và màu sắc. Mỗi bước dễ kiểm tra và rẻ hơn.

Sai lầm phổ biến làm ngân sách vỡ

Hầu hết vượt ngân sách không đến từ tính năng lớn. Chúng đến từ các khoảng trống phạm vi nhỏ nhân lên thành thêm vòng prompt, nhiều mã sinh ra, và nhiều sửa.

Năm kẻ phá ngân sách (và nên làm gì thay thế)

Xây trước khi thống nhất "xong"

Nếu bạn sinh mã mà không có kiểm tra chấp nhận, bạn sẽ trả tiền cho việc viết lại. Viết 3–5 kiểm tra trước: người dùng làm gì, lỗi hiển thị gì, dữ liệu nào phải lưu.

Dùng từ mơ hồ

"Hiện đại," "đẹp," và "làm tốt hơn" mời gọi trao đổi dài. Thay bằng cụ thể như "layout hai cột trên desktop, một cột trên mobile" hoặc "màu nút chính #1F6FEB."

Nhồi nhiều tính năng vào một prompt

"Thêm auth, thêm billing, thêm admin dashboard" khiến khó theo dõi thay đổi và ước tính follow-up. Làm từng tính năng một và yêu cầu tóm tắt ngắn các file bị chạm.

Thay đổi mô hình dữ liệu muộn

Đổi tên bảng, thay đổi quan hệ, hoặc chuyển ID giữa chừng buộc sửa khắp UI, API, và migration. Khóa thực thể cốt lõi sớm, ngay cả khi một vài trường để "tương lai."

Bỏ kiểm thử cho đến cuối

Bug biến thành vòng regenerate-fix-regenerate. Yêu cầu một bộ test nhỏ cho mỗi tính năng, không phải một lần kiểm thử lớn sau cùng.

Một ví dụ cụ thể: bạn yêu cầu Koder.ai "làm CRM tốt hơn" và nó thay layout, đổi tên trường, và điều chỉnh endpoint trong một bước. Sau đó integration hỏng, và bạn tiêu credits chỉ để tìm chỗ bị thay. Nếu thay vào đó bạn nói "không đổi mô hình dữ liệu, chỉ cập nhật trang list UI, không chạm route API, và vượt 4 kiểm tra này," bạn hạn chế churn và giữ chi phí ổn định.

Checklist nhanh trước khi bắt đầu

Xem việc lập ngân sách như lập kế hoạch một dự án nhỏ, không phải một prompt kỳ diệu. Một kiểm tra 2 phút bắt được hầu hết vấn đề tiêu tốn quá mức sớm.

Chạy qua các mục này và sửa mọi "không" trước khi sinh mã thêm:

• Bạn có danh sách tính năng với ranh giới rõ: làm gì, không làm gì, bắt đầu và kết thúc ở đâu.
• Bạn có khoảng cho mỗi tính năng (low, typical, high), và bạn cam kết một con số cho lần xây đầu tiên.
• Prompt của bạn bao gồm kiểm tra chấp nhận và dòng ngoài phạm vi rõ ràng.
• Bạn xây theo từng phần nhỏ và review sau mỗi phần: kiểm tra hành vi, đọc thay đổi, rồi quyết xem phần tiếp theo có đáng hay không.
• Bạn dành ngân sách cho những phần thường mở rộng: integrations và chỉnh sửa UI.

Nếu bạn dùng Koder.ai, coi mỗi phần như một điểm snapshot: sinh một phần, kiểm thử, rồi tiếp tục. Snapshot và rollback quý giá nhất ngay trước các thay đổi rủi ro (sửa mô hình dữ liệu, refactor UI rộng, hoặc rewrite integration).

Ví dụ đơn giản: thay vì prompt "Build user management," scope thành "Chỉ email login, bao gồm đặt lại mật khẩu, không social login, admin có thể deactivate users, phải có test cho login và reset." Các kiểm tra rõ ràng giảm lượt thử lại, và lượt thử lại là nơi token và credits biến mất.

Ví dụ: ước tính một app nhỏ từ danh sách tính năng

Đây là ví dụ nhỏ, thực tế bạn có thể sao chép. App là công cụ nội bộ cho một đội: login, hai module đơn giản, và một integration.

Giả sử một "build cycle" là: kế hoạch ngắn, sinh hoặc cập nhật mã, review nhanh và sửa. Credits của bạn chủ yếu theo số cycle bạn chạy và kích thước mỗi cycle.

Danh sách tính năng cho công cụ nội bộ:

Một chuỗi prompt giữ checkpoint chặt:

1. Planning: xác nhận trường, màn hình, quy tắc cho từng tính năng, cộng những gì ngoài phạm vi.
2. Build module 1 chỉ: sinh Employees end-to-end, rồi dừng.
3. Review: kiểm thử luồng, sửa lỗi, và khóa trường trước khi chuyển.
4. Lặp cho module 2.
5. Thêm integration cuối cùng, sau khi các luồng chính ổn định.

Chi phí tăng khi bạn thay quyết định sau khi mã đã tồn tại. Những kích hoạt phổ biến là thay role (role mới hoặc đường phân quyền), trường thêm muộn (đặc biệt nếu chạm cả hai module và integration), lỗi integration (xác thực thất bại, mismatch payload), và redesign UI sau khi form đã có.

Bước tiếp theo: lập kế hoạch theo tính năng, xây theo cycle, và kiểm tra credits sau mỗi cycle. Dùng snapshot trước các thay đổi rủi ro để khôi phục nhanh và giữ dự án trong khoảng typical của bạn.