Ước tính chi phí xây dựng AI đơn giản: dự báo credits và tokens cho từng tính năng, xác định phạm vi prompt và tránh làm lại để ứng dụng nằm trong ngân sách.
text\nFeature: Password login\n- Build: low 30 | typical 60 | high 120\n- Test: low 15 | typical 30 | high 60\n- Revise: low 10 | typical 20 | high 40\nSubtotal (typical): 110\n\nBuffer (15%): 17\nLater changes (held): 50\n\n\nLặ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.\n\n## Ước tính các tính năng phổ biến: auth và CRUD\n\nAuth 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í.\n\n### Auth: định hình chính xác, đừng chỉ nói "login"\n\nGhi 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.\n\nHãy cụ thể về:\n\n- Phương thức đăng nhập (email/mật khẩu, magic link, Google, Apple, SSO)\n- Roles và quyền (admin/editor/viewer, kèm theo những gì mỗi role có thể làm)\n- Quy tắc mật khẩu (độ dài, độ phức tạp, khóa, luồng đặt lại)\n- Quy tắc session (hết hạn, đăng xuất, nhớ đăng nhập)\n- Vòng đời tài khoản (invite, deactivate/delete, verify email)\n\nNế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.\n\n### CRUD: đếm số màn hình và quy tắc, không chỉ bảng\n\nChi 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.\n\nKhi 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.\n\nCũ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.\n\nCá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.\n\n## Ước tính integrations mà không đoán mò\n\nIntegrations 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.\n\nMột phạm vi tích hợp hợp lý thường gồm:\n\n- Kết nối và xác thực (API key hoặc OAuth, refresh token)\n- Một đối tượng end-to-end (một request happy-path)\n- Hành vi sync (webhook hoặc theo lịch, phân trang, rate limit)\n- Xử lý lỗi (retry, idempotency, đường chạy re-run)\n- Kiểm thử và edge case (dữ liệu xấu, quyền thiếu, timeout)\n\nTrướ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.\n\nTiế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.\n\nLậ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.\n\nCuố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ế.\n\n## Ước tính redesign và thay đổi UI\n\nCô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.\n\nTá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.\n\n### Scope nó như một danh sách trang\n\nTrá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.\n\nGiữ phạm vi ngắn và cụ thể:\n\n- Các trang bao gồm (ví dụ: Login, Dashboard, Settings)\n- Trạng thái bao gồm (empty, loading, error, success)\n- Những gì thay đổi (layout, component, copy, flow)\n- Style tham chiếu (một vài ghi chú: màu, typography, khoảng cách)\n- Số lần pass cho phép (ví dụ: 1 build pass + 1 polish pass)\n\nLoạ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.\n\n### Đừng bỏ qua các lần QA\n\nThay đổ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 đủ.\n\nMột phương pháp ước tính thực tế là:\n\n(số trang) x (độ sâu thay đổi) x (số lần pass)\n\nVí 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.\n\n## Bước từng bước: xây một phạm vi đã dự toán trong prompt\n\nCá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.\n\nBắ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.\n\nRồ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.\n\nChỉ 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:\n\n- Người dùng và role (ai làm gì)\n- Màn hình với hành động (người dùng bấm gì)\n- Bảng cốt lõi và trường chính (cần lưu gì)\n- Kiểm tra chấp nhận (làm sao biết nó chạy)\n- Ngoài phạm vi (những gì không được xây)\n\nCá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ã.\n\nHã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.\n\nXâ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.\n\n## Giữ prompt rẻ hơn mà không mất chất lượng\n\nHầ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.\n\nBắ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.\n\nGiữ 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.\n\nYê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.\n\nMột bộ quy tắc đơn giản:\n\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\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)\n- Giới hạn: số lần sửa cố định (ví dụ, hai lần)\n- Yêu cầu: tóm tắt ngắn những gì thay đổi để bất ngờ dễ thấy\n- Ghi lại: nguyên nhân làm lại và cập nhật template prompt của bạn\n\nDừ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.\n\nVí 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.\n\n## Sai lầm phổ biến làm ngân sách vỡ\n\nHầ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\n### Năm kẻ phá ngân sách (và nên làm gì thay thế)\n\nXây trước khi thống nhất "xong"\n\nNế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.\n\nDùng từ mơ hồ\n\n"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."\n\nNhồi nhiều tính năng vào một prompt\n\n"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.\n\nThay đổi mô hình dữ liệu muộn\n\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."\n\nBỏ kiểm thử cho đến cuối\n\nBug 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.\n\nMộ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.\n\n## Checklist nhanh trước khi bắt đầu\n\nXem 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.\n\nChạy qua các mục này và sửa mọi "không" trước khi sinh mã thêm:\n\n- 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.\n- 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.\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.\n- 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.\n- 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\nNế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).\n\nVí 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.\n\n## Ví dụ: ước tính một app nhỏ từ danh sách tính năng\n\nĐâ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.\n\nGiả 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.\n\nDanh sách tính năng cho công cụ nội bộ:\n\n| Feature | Bao gồm | Low | Typical | High |\n|---|---|---:|---:|---:|\n| Login + roles | Sign in, sign out, hai roles (Admin, User), trang bảo vệ | 1 cycle | 2 cycles | 4 cycles |\n| CRUD module 1 | "Employees" list, create/edit, validation cơ bản, tìm kiếm | 2 cycles | 3 cycles | 6 cycles |\n| CRUD module 2 | "Assets" list, create/edit, gán cho nhân viên, trường audit | 2 cycles | 4 cycles | 7 cycles |\n| Một integration | Gửi event đến service ngoài khi gán tài sản | 1 cycle | 2 cycles | 5 cycles |\n\nMột chuỗi prompt giữ checkpoint chặt:\n\n1. 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.\n2. Build module 1 chỉ: sinh Employees end-to-end, rồi dừng.\n3. Review: kiểm thử luồng, sửa lỗi, và khóa trường trước khi chuyển.\n4. Lặp cho module 2.\n5. Thêm integration cuối cùng, sau khi các luồng chính ổn định.\n\nChi 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ó.\n\nBướ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.Dự trù theo khoảng vì bạn đang trả cho số lần thử, chứ không phải một mức giá cố định cho tính năng. Chi phí tăng khi có:\n\n- phạm vi mơ hồ (cần nhiều trao đổi hơn)\n- ngữ cảnh dài (lịch sử chat + nhiều file)\n- đầu ra lớn (viết lại toàn file)\n- kiểm thử và chỉnh sửa sau bản nháp đầu tiên\n\nMột thay đổi “nhỏ” ở giao diện có thể tốn kém nếu nó thay đổi logic, dữ liệu hoặc luồng.
Tokens là các đoạn văn bản nhỏ mà mô hình đọc/viết (prompt của bạn, output của mô hình, và lịch sử chat mà mô hình cần đọc lại).\n\nCredits là đơn vị thanh toán của nền tảng bạn (thường bao gồm cả chi phí mô hình và các tác vụ nền như agent chạy, chỉnh sửa file).\n\nBuild steps là các thay đổi có ý nghĩa của dự án (thêm bảng, nối một màn hình, thêm endpoint). Một tính năng thường bao gồm nhiều bước, và mỗi bước có thể kích hoạt nhiều lần gọi mô hình.
Ước tính theo những tính năng mà người dùng sẽ gọi ("đăng nhập bằng mật khẩu", "danh sách nhân viên", "gán tài sản") thay vì “màn hình” hay “tin nhắn”. Với mỗi tính năng, chia ngân sách cho ba phần:\n\n- Build: sinh mã và nối vào app\n- Test: chạy luồng và sửa lỗi/edge case rõ rệt\n- Revise: tinh chỉnh sau khi thấy hoạt động\n\nRồi gán khoảng low/typical/high và cộng lại.
Thêm hai dòng rõ ràng:\n\n- Unknowns buffer: thường 10–20%\n- Later changes requested: một hạng mục riêng cho ý tưởng mới sau khi tính năng được chấp nhận\n\nTách “later changes” giúp bạn không đổ lỗi cho ước tính ban đầu khi phạm vi tăng theo thời gian.
Viết rõ thế nào là “hoàn thành” cho auth. Những yếu tố làm tăng chi phí nhất là:\n\n- số phương thức đăng nhập (email/mật khẩu vs magic link vs SSO)\n- số đường phân quyền/role\n- vòng đời tài khoản (invite, deactivate/delete, verify)\n- quy tắc session (hết hạn, đăng xuất)\n- đặt lại mật khẩu và khóa tài khoản\n\nNếu muốn chi phí dự đoán, mặc định 1 phương thức (email/mật khẩu) và 1–2 role.
Chi phí CRUD theo hành vi, không chỉ theo bảng. Với mỗi entity, định nghĩa:\n\n- các màn hình cần có (list/detail/create/edit + admin/audit nếu có)\n- trường, kiểu dữ liệu và quy tắc validation\n- hành vi danh sách (lọc, sắp xếp, phân trang, tìm kiếm)\n- quy tắc quyền (ai được xem/sửa row nào)\n\nCSV import/export, audit log, workflow phê duyệt hay quyền theo hàng đều nên tính như các dòng tính năng riêng.
Phân nhỏ “kết nối tới X” thành các bước có thể kiểm thử:\n\n- auth (API key/OAuth + refresh)\n- một đối tượng end-to-end trên happy path\n- hành vi sync (webhook vs theo lịch, phân trang, giới hạn tốc độ)\n- xử lý lỗi (retry, idempotency, đường chạy re-run)\n- kiểm thử dữ liệu lạ và timeout\n\nKhóa data contract (các trường chính xác) trước khi sinh mã để tránh mô hình tự tạo thêm bảng và luồng.
Lập scope UI như danh sách trang với các trạng thái:\n\n- các trang được bao gồm\n- trạng thái (loading/empty/error/success)\n- những gì thay đổi (chỉ visual hay ảnh hưởng hành vi)\n- số lần pass (ví dụ: 1 build + 1 polish)\n\nNếu redesign thay đổi validation, tải dữ liệu hoặc bước người dùng, xử lý nó như tính năng chứ không phải "chỉ UI".
Dùng cấu trúc prompt gọn:\n\n- mục tiêu + người dùng\n- màn hình và hành động (những gì người dùng nhấn)\n- bảng/trường cốt lõi (chỉ những thứ thiết yếu)\n- 2–4 kiểm tra chấp nhận cho mỗi tính năng\n- danh sách rõ ràng những gì ngoài phạm vi\n\nRồi xây theo từng phần nhỏ (một endpoint hoặc một màn hình một lần) và ước tính lại sau mỗi phần.
Dừng sau hai lần thử không thành công và thay đổi input, không chỉ thay đổi cách diễn đạt. Các sửa thông dụng:\n\n- thêm ràng buộc thiếu (role, trường chính xác, màn hình cụ thể)\n- bỏ các yêu cầu mâu thuẫn\n- cung cấp trường hợp lỗi (bạn làm gì, chuyện gì xảy ra, lẽ ra phải như thế nào)\n- yêu cầu diff nhỏ (chỉ thay đổi 1 thứ)\n\nKết thúc mỗi bước bằng yêu cầu tóm tắt ngắn các file bị thay đổi để bạn dễ phát hiện churn không mong muốn.