Prompt Vibe cho ứng dụng CRUD: bộ copy-paste full-stack hoàn chỉnh

Những gì bộ prompt này xây dựng (ngôn ngữ dễ hiểu)

Bộ prompt này được thiết kế để sinh một ứng dụng CRUD hoàn chỉnh và hoạt động: các màn hình người dùng cần, API xử lý yêu cầu, và cơ sở dữ liệu PostgreSQL lưu trữ dữ liệu. Nó cũng bao gồm đăng nhập và truy cập theo vai trò, để người dùng khác nhau có thể nhìn thấy và làm những việc khác nhau.

CRUD chỉ là bốn hành động thường gặp mà ứng dụng cần:

• Create: thêm một bản ghi mới (như khách hàng hoặc task)
• Read: xem danh sách và mở một mục đơn lẻ
• Update: sửa một mục đã tồn tại
• Delete: xóa một mục (thường có bước xác nhận)

Ở front end, bạn nên có một tập màn hình dễ dự đoán: trang danh sách, trang chi tiết, form tạo, form chỉnh sửa, thêm trang đăng nhập và điều hướng cơ bản. Ở back end, bạn sẽ có các endpoint tương ứng với những màn hình đó (list, get by id, create, update, delete), được hỗ trợ bởi một bảng Postgres và các validation đơn giản.

Chất lượng prompt quan trọng hơn lựa chọn mô hình. Mô hình chỉ có thể làm theo những gì bạn chỉ ra. Nếu prompt mơ hồ, bạn sẽ nhận được tên trường không khớp, route thiếu, xác thực không đầy đủ, hoặc UI không khớp với API. Một prompt chặt chẽ giống như một hợp đồng: UI, API và DB cùng thống nhất trên cùng tên và quy tắc.

Trước khi bắt đầu, quyết định vài chi tiết để build ổn định:

• Thực thể chính và 6–12 trường (tên, kiểu, bắt buộc hay tùy chọn)
• Vai trò (ví dụ: admin, manager, viewer) và mỗi vai trò có thể làm gì
• Quy tắc cơ bản (ai có thể sửa, soft delete hay hard delete, trường bắt buộc)
• Những màn hình “happy path” bạn cần vào ngày đầu
• Bất kỳ ràng buộc nào (trường unique, khoảng ngày, giá trị status)

Nếu bạn dùng Koder.ai, đây có thể là một cuộc hội thoại sinh ra UI React, API Go và schema PostgreSQL khớp nhau mà không cần nối tay thủ công.

Bảng chuẩn bị: vài chi tiết bạn cần trước khi prompt

Một build CRUD tốt bắt đầu từ một bộ quyết định nhỏ. Ghi chúng ra trước để prompt rõ ràng, màn hình đúng, và API khớp database.

Bắt đầu với một thực thể cốt lõi. Đây là “đối tượng” mà ứng dụng quản lý hàng ngày (Item, Customer, Appointment). Thêm thực thể thứ hai chỉ khi thật sự cần thiết vào ngày đầu (ví dụ Item cần Category). Nếu bắt đầu với ba hoặc bốn, bạn sẽ mất thời gian nhiều để gỡ mối quan hệ thay vì có một app chạy được.

Ghi trường thực thể với kiểu và một ví dụ. Ví dụ quan trọng vì nó hướng dẫn nhãn, định dạng và validation.

• Field: type - example (ghi chú)
• name: text - "Paper towels" (bắt buộc, 2-80 ký tự)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (tùy chọn)
• status: enum - "in_stock" | "low" | "out" (mặc định in_stock)

Tiếp theo, liệt kê vai trò và quyền bằng ngôn ngữ đơn giản. Giữ cụ thể. Với nhiều app, 2–3 vai trò là đủ:

• Admin: quản lý người dùng, full CRUD trên mọi bản ghi
• Manager: CRUD trên bản ghi, không quản lý người dùng
• Viewer: chỉ đọc

Cuối cùng, tạo 5–10 bản ghi mẫu. Chúng giúp UI có nhãn thực tế, tùy chọn dropdown và giá trị mặc định hợp lý. Ví dụ (inventory): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Nếu bạn xây trên Koder.ai, dán worksheet này vào prompt đầu tiên để nền tảng giữ app nhất quán giữa các màn hình, xác thực và API PostgreSQL.

Prompt cơ bản: đặt quy tắc cho toàn bộ build

Bắt đầu với một prompt “quy tắc chung”. Nó giữ build nhất quán giữa các màn hình, API và database, và giảm back-and-forth khi bạn thêm tính năng sau.

Yêu cầu một kế hoạch ngắn trước khi viết mã. Bạn muốn mô hình nêu tên màn hình và route, bảng và endpoint API. Yêu cầu nó liệt kê giả định trước (như vai trò tồn tại) và giữ những giả định đó không đổi trừ khi bạn chấp thuận thay đổi.

Đây là prompt cơ bản để copy-paste:

You are building a complete full-stack CRUD app.

Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL

Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD

Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.

Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).

Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications

Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.

Một ví dụ cụ thể: nếu kế hoạch chọn role: admin|member, nó không nên sau đó tự sinh manager để giải quyết một edge case UI. Prompt này buộc nó dừng lại và xin phê duyệt thay vì tự ý thay đổi.

Copy-paste prompts: màn hình và điều hướng

Màn hình tốt bắt đầu từ một bản đồ trang rõ ràng. Dùng các prompt bên dưới trước khi yêu cầu database hoặc API code. Điều này giữ tên route và UI ổn định sau này — nơi nhiều build sai lệch.

Prompt 1: danh sách trang và luồng người dùng

You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.

App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)

Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.

Sau khi nó trả lời, khoá tên. Nếu bạn đổi tên route sau này, API và test sẽ bị trôi.

Prompt 2: navigation và form có hành vi tốt

Using the approved page list and route names, generate:

A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.

B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.

C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.

D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.

Nếu UI quá phức tạp, yêu cầu giữ chỉ một layout, một kiểu bảng và một pattern form cho toàn bộ trang.

Copy-paste prompts: xác thực và vai trò

Nếu bạn muốn kết quả dự đoán được, hãy nêu rõ cách người dùng đăng nhập, thời gian phiên và từng vai trò có thể làm gì. Các prompt này giả định login bằng email + password và dùng session (dễ test qua các màn hình và API).

Dán đoạn sau để sinh login, logout và quản lý session:

Implement authentication for this app.

Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.

Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.

Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.

Giờ thêm vai trò và quy tắc bảo vệ. Giữ quyền nhỏ và dễ test:

Add role-based access control (RBAC) with these roles: admin, manager, viewer.

Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.

Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.

Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.

Các kiểm tra thủ công nhanh giúp bắt lỗi:

• Đăng nhập bằng mỗi vai trò và xác nhận những gì bạn có/không thể thấy.
• Thử thực hiện hành động bị hạn chế (như delete) và xác nhận nhận được 403.
• Xác nhận logout xoá session và app trở về màn hình Login.

Nếu bạn xây trên Koder.ai, giữ auth và RBAC trong một snapshot để có thể rollback dễ nếu quyền bị rối.

Copy-paste prompts: schema PostgreSQL và mô hình dữ liệu

Một prompt schema tốt làm hai việc: ép rõ quan hệ bảng (để UI và API khớp) và tránh database “gần đúng” (thiếu index, timestamps, hoặc mapping vai trò).

Trước khi dán, quyết định hai toggle sau (mỗi dòng một):

• Primary keys: uuid or bigserial
• Soft delete: yes (dùng deleted_at) or no (hard delete)

Dán prompt này để khoá mô hình dữ liệu:

You are building the PostgreSQL data model for a full-stack CRUD app.

Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>

Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
  - users table (email unique, password_hash, status)
  - roles table (name unique)
  - user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).

Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.

Rồi dán prompt này để sinh migration hoặc bước thiết lập phù hợp:

Now generate the actual database setup for this project.

Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.

Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project

Nếu có điều gì không rõ, thêm một dòng: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Copy-paste prompts: Go CRUD API (Postgres-backed)

Nếu backend trả về nửa chừng, prompt này ép các điều cơ bản: route rõ ràng, validation, phân trang, và kiểm tra vai trò ở mọi handler.

Copy-paste như dưới, rồi thay placeholder (RESOURCE, FIELDS, ROLES) bằng chi tiết app của bạn.

You are building the backend API in Go for a Postgres-backed CRUD resource.

Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
  - <name TEXT required, 2..80 chars>
  - <qty INT required, min 0>
  - <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>

Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
  - Every endpoint must check role and tenant_id.
  - admin: full access
  - manager: create, read, update, list; cannot delete
  - viewer: read and list only

API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items

2) Define request/response JSON shapes for each endpoint, including examples.

3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.

4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.

5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).

Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions

Sau khi sinh, rà soát nhanh cho nhất quán: status code khớp body lỗi, list trả ordering ổn định, và mỗi handler kiểm tra cả vai trò lẫn tenant ownership trước khi thao tác DB.

Nếu bạn dùng Koder.ai, cũng nhắc backend phải giữ bằng Go và DB là PostgreSQL để code export khớp stack mong muốn.

Từng bước: sinh, chạy và kiểm chứng

Sinh mọi thứ (UI, API, DB), rồi chuyển sang chế độ verify nghiêm ngặt. Mục tiêu không phải ngắm màn hình mà là chứng minh vòng đầy đủ hoạt động: UI - auth - roles - Postgres - API - UI.

Một chạy kiểm tra đơn giản

1. Chạy app và mở trang chủ. Xác nhận điều hướng hoạt động và bạn không thấy dữ liệu placeholder. Nếu trang trắng, ghi lỗi hiển thị đầu tiên (toast UI, console, hoặc log server).

2. Tạo một tài khoản test cho mỗi vai trò (Admin, Manager, Viewer). Đăng nhập và đăng xuất với từng user. Xác nhận app hiển thị vai trò ở chỗ dễ thấy (menu profile, settings, hoặc badge nhỏ).

3. Chọn một màn hình CRUD và chạy một vòng: tạo bản ghi, refresh trang, rồi sửa và xóa nó. Kiểm tra chính là persistence: sau refresh, bản ghi phải phản ánh trong Postgres, không chỉ còn trong bộ nhớ.

4. Thử hành động bị cấm cố ý. Đăng nhập bằng vai trò thấp nhất và cố truy cập màn hình admin, gọi hành động bị hạn chế (xóa), hoặc sửa bản ghi bạn không nên. Kết quả rõ ràng: UI bị chặn với thông báo, hoặc API trả lỗi kiểu 403 mà không đổi dữ liệu.

5. Thử các edge case cơ bản: danh sách rỗng, tên rất dài, thiếu trường bắt buộc, định dạng sai (email, ngày). Xác nhận app hiển thị validation hữu ích và không bị crash.

Nếu bạn dùng Koder.ai, chụp snapshot ngay sau khi chạy end-to-end CRUD thành công đầu tiên. Nó cho điểm rollback an toàn trước khi thêm tính năng.

Những lỗi prompt thường gặp và cách sửa

Hầu hết build “bị hỏng” thực tế không hỏng—chỉ thiếu một ràng buộc để UI, API và DB đồng bộ.

1) Yêu cầu quá nhiều cùng lúc

Khi bạn yêu cầu screens, auth, roles, schema và mọi edge case một lúc, app thường không nhất quán (route không khớp, model trôi, trang nửa vời).\n\nSửa: chia theo lớp và buộc công cụ nêu lại những gì nó sẽ sinh trước khi tạo code. Trên Koder.ai, điều này cũng giúp nhiều agent đồng bộ.

2) Vai trò mơ hồ khiến checks bị thiếu

Nếu chỉ nói “admin và user”, bạn có thể nhận label trong UI nhưng không có authorization server-side.

Sửa: định nghĩa quyền theo hành động (create, read, update, delete) cho mỗi resource, và yêu cầu kiểm tra server-side ở mọi endpoint.

3) Thiếu kiểu trường gây drift UI và DB

Nếu mô tả trường bằng ngôn ngữ tự nhiên (“price”, “date”, “status”), form có thể hiện input text trong khi Postgres mong number, date hoặc enum.

Sửa: chỉ rõ kiểu trường, nullability, default, và ràng buộc; yêu cầu rules validation dùng chung.

4) Không có trạng thái loading và lỗi, UI trông bị “hỏng”

Không có loading/error thì request thất bại trông như trang treo.

Sửa: yêu cầu spinner loading, empty state, và thông báo lỗi hiển thị cho mỗi màn hình.

5) Tên đổi giữa chừng

Đổi “Projects” thành “Workspaces” giữa chừng thường phá route, handler, và tên bảng.

Sửa: khoá glossary sớm. Khi đổi tên, yêu cầu một kế hoạch đổi tên (search/replace, migrate) thay vì để mô hình làm tuỳ ý.

Dùng prompt sửa chữa này khi có gì đó lệch:

Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.
Then propose a minimal patch plan.
Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.
Output: a checklist of changes, then apply them.

Nếu cứ gặp inconsistency, có lẽ bạn thiếu câu "single source of truth". Thêm một câu: “The Postgres schema is the source of truth; UI and API must match it exactly.”

Checklist nhanh trước khi gọi là xong

Trước khi mài giũ, chạy qua kiểm tra nhanh để xác nhận app hoạt như sản phẩm thực. Đây nơi nhiều app full-stack thất bại: những mismatch nhỏ giữa màn hình, quy tắc và dữ liệu.

• Màn hình khớp spec thực thể: mọi màn hình (list, details, create, edit) dùng đúng tên thực thể và danh sách trường bạn đã định nghĩa.
• Vai trò rõ ràng: viết bảng allow/deny đơn giản cho mỗi vai trò và xác nhận UI và API cùng áp dụng.
• API trả về nhất quán: chọn một pattern (status codes, shape lỗi, shape phân trang) và xác nhận mọi endpoint tuân theo.
• Ràng buộc DB khớp validation form: nếu DB yêu cầu email unique hay name non-null, validate trước submit và hiện thông báo rõ khi API từ chối.
• Create/edit/delete tồn sau refresh: tạo bản ghi, refresh, xác nhận còn đó; sửa, refresh, xác nhận; xóa, refresh, xác nhận.

Một test cụ thể: đăng nhập bằng vai trò có quyền thấp nhất và thử hành động bạn nghĩ sẽ bị chặn (ví dụ delete). Nếu thành công, sửa policy ở một chỗ duy nhất (API) trước, rồi điều chỉnh UI cho khớp.

Ví dụ thực tế: tracker inventory đơn giản

Hình dung một đội IT nhỏ cho mượn laptop, màn hình và adapter cho nhân viên. Họ cần một nơi để xem có gì sẵn, ai đang mượn gì, và khi nào phải trả. Đây là test hay vì ép vai trò, vài màn hình, và database thực.

Worksheet đã điền mẫu

Dùng input này làm ví dụ để copy vào bước chuẩn bị (copy và chỉnh nếu cần):

App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)

Thứ tự dán prompt

Dán prompt theo thứ tự này để app ổn định:

1. Base prompt (quy tắc toàn cục, stack, đặt tên, xử lý lỗi)
2. Màn hình và điều hướng (Inventory, Requests, Loans, Admin queue)
3. Xác thực và vai trò (admin, staff, viewer)
4. Schema PostgreSQL và dữ liệu seed (items, loans, requests, users)
5. API CRUD Go (endpoint và validation khớp quy tắc)

Kết quả tốt trông như: staff có thể request “MBP-014”, admin phê duyệt với due date, và danh sách inventory hiển thị item không sẵn với tên người mượn.

Nếu build gần đúng nhưng chưa chuẩn, chỉnh từng thứ một: siết quyền vai trò (viewer không bao giờ thấy nút edit), nhắc lại quy tắc “chỉ 1 active loan mỗi item”, hoặc yêu cầu đổi tên trường để label UI và cột DB khớp.

Bước tiếp theo: mở rộng an toàn và tái sử dụng bộ prompt

Khi cơ bản hoạt động, coi thay đổi tiếp theo như các bản release nhỏ. Chọn một tính năng, định nghĩa thế nào là “done”, rồi prompt cho nó.

Thứ tự hợp lý cho nhiều app:

• Audit log: ghi ai thay đổi gì và khi nào (create, update, delete), hiển thị ở màn admin-only.
• File upload: đính kèm tài liệu hoặc ảnh vào bản ghi, lưu metadata trong Postgres và giữ quyền truy cập qua auth.
• Thông báo đơn giản: hiện alert trong app (ví dụ “low stock” hoặc “new comment”), với hành động “mark as read”.

Khi một thay đổi phá build, đừng sửa mọi thứ cùng lúc. Roll back, rồi áp lại thay đổi bằng prompt nhỏ hơn, cụ thể hơn. Nếu dùng Koder.ai, snapshot và rollback là mạng an toàn trước các thay đổi ảnh hưởng schema DB, auth, hay component dùng chung.

Chế độ Planning Mode cũng hữu ích khi tính năng ảnh hưởng nhiều lớp. Yêu cầu nó nêu lại kế hoạch trước (màn hình, endpoint API, thay đổi DB, vai trò), rồi phê duyệt kế hoạch đó trước khi sinh mã. Điều này ngăn mismatch phổ biến nơi UI mong trường API không trả, hoặc API ghi vào cột không tồn tại.

Nếu muốn tiếp bên ngoài nền tảng, xuất source code và chỉnh theo workflow thường. Giữ bộ prompt cùng repo như “hướng dẫn xây” để tái tạo app sau này hoặc onboarding người mới.

Nếu bạn đang xây trên Koder.ai (koder.ai), bộ prompt này phù hợp với mặc định React + Go + PostgreSQL của nền tảng, và dễ lặp an toàn bằng snapshot khi bạn hoàn thiện yêu cầu.

Cuối cùng, lưu một prompt template tái sử dụng cho dự án sau. Giữ phần ổn định (stack, quy tắc CRUD, convention auth và vai trò, mẫu Postgres) và chỉ thay danh từ domain. Theo thời gian, prompt của bạn trở thành một công thức lặp lại thay vì thử nghiệm một lần.