พรอมต์ Vibe สำหรับแอป CRUD: ชุดคัดลอก-วางฟูลสแต็ก

สิ่งที่ชุดพรอมต์นี้จะสร้าง (ภาษาเรียบง่าย)

ชุดพรอมต์นี้ออกแบบมาเพื่อสร้างแอป CRUD ที่สมบูรณ์และใช้งานได้: หน้าจอที่ผู้ใช้โต้ตอบ, API ที่จัดการคำขอ, และฐานข้อมูล PostgreSQL ที่เก็บข้อมูล นอกจากนี้ยังรวมการล็อกอินและการควบคุมบทบาท (role-based access) เพื่อให้ผู้ใช้ต่างกันเห็นและทำงานต่างกันได้

CRUD คือการกระทำพื้นฐานสี่อย่างที่แอปของคุณต้องมี:

• Create: เพิ่มระเบียนใหม่ (เช่น ลูกค้าหรืองาน)
• Read: ดูรายการและเปิดดูรายการเดียว
• Update: แก้ไขรายการที่มีอยู่
• Delete: ลบรายการ (มักมีขั้นตอนยืนยัน)

ฝั่ง frontend คุณควรได้ชุดหน้าจอที่คาดเดาได้: หน้า list, หน้า detail, ฟอร์มสร้าง, ฟอร์มแก้ไข, หน้า login และการนำทางพื้นฐาน ฝั่ง backend จะมี endpoints ที่สอดคล้องกับหน้าจอเหล่านี้ (list, get by id, create, update, delete) รองรับด้วยตาราง Postgres และการตรวจสอบความถูกต้องแบบง่ายๆ

คุณภาพของพรอมต์สำคัญกว่าการเลือกโมเดล โมเดลทำตามที่คุณระบุได้เท่านั้น หากพรอมต์ไม่ชัดเจน คุณอาจได้ชื่อฟิลด์ไม่ตรงกัน เส้นทางหายไป auth ไม่ครบ หรือ UI ไม่ตรงกับ API พรอมต์ที่รัดกุมจะทำหน้าที่เหมือนสัญญา: UI, API และฐานข้อมูลใช้ชื่อและกฎเดียวกัน

ก่อนเริ่ม ให้ตัดสินใจรายละเอียดง่ายๆ เพื่อให้การสร้างยังคงสอดคล้อง:

• เอนทิตี้หลักและ 6 ถึง 12 ฟิลด์ (ชื่อ, ประเภท, บังคับหรือไม่)
• บทบาท (ตัวอย่าง: admin, manager, viewer) และสิ่งที่แต่ละบทบาททำได้
• กฎพื้นฐาน (ใครแก้ได้, ลบแบบ soft vs hard, ฟิลด์ที่บังคับ)
• หน้าจอ “happy path” ที่คุณต้องการในวันแรก
• ข้อจำกัดใด ๆ (ฟิลด์ที่ต้องไม่ซ้ำ, ช่วงวันที่, ค่าของสถานะ)

ถ้าคุณใช้ Koder.ai การสนทนาหนึ่งครั้งนี้สามารถสร้าง UI React, API Go และสคีม่า PostgreSQL ที่เข้ากันได้โดยไม่ต้องต่อเชื่อมด้วยมือ

Worksheet เตรียมข้อมูล: รายละเอียดที่ต้องมีเล็กน้อยก่อนส่งพรอมต์

การสร้าง CRUD ที่ดีเริ่มจากการตัดสินใจเพียงเล็กน้อย จดไว้ก่อนแล้วพรอมต์จะชัดเจน หน้าจอดูถูกต้อง และ API จะตรงกับฐานข้อมูล

เริ่มจากเอนทิตี้หลักเดียว นี่คือ “สิ่ง” ที่แอปของคุณจัดการทุกวัน (Item, Customer, Appointment) เพิ่มเอนทิตี้ที่สองก็ต่อเมื่อจำเป็นจริง ๆ ในวันแรก (เช่น Item ต้องมี Category) หากเริ่มด้วยสามหรือสี่ คุณจะเสียเวลาส่วนใหญ่ในการแก้ความสัมพันธ์แทนที่จะได้แอปทำงาน

เขียนฟิลด์ของเอนทิตี้พร้อมประเภทและตัวอย่าง ตัวอย่างมีความสำคัญเพราะช่วยกำหนดป้ายชื่อ รูปแบบ และการตรวจสอบ

• Field: type - example (หมายเหตุ)
• name: text - "Paper towels" (บังคับ, 2-80 chars)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (ไม่บังคับ)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

ต่อมา ให้ระบุบทบาทและสิทธิ์เป็นภาษาธรรมดา ควรชัดเจน สำหรับหลายแอป 2–3 บทบาทก็เพียงพอ:

• Admin: จัดการผู้ใช้, CRUD เต็มรูปแบบบนทุกระเบียน
• Manager: CRUD บนระเบียน แต่ไม่จัดการผู้ใช้
• Viewer: อ่านอย่างเดียว

สุดท้าย สร้างตัวอย่างระเบียน 5–10 รายการ ตัวอย่างเหล่านี้ช่วยให้ป้ายชื่อบน UI เมนูแบบเลื่อน และค่าเริ่มต้นมีความสมเหตุสมผล ตัวอย่าง (inventory): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

ถ้าคุณสร้างใน Koder.ai ให้วาง worksheet นี้ในพรอมต์แรก เพื่อให้แพลตฟอร์มรักษาความสอดคล้องของแอประหว่างหน้าจอ auth และ API ที่ใช้ PostgreSQL

พรอมต์พื้นฐาน: กำหนดกฎสำหรับการสร้างทั้งหมด

เริ่มด้วยพรอมต์ "กฎการทำงาน" หนึ่งชุด จะช่วยให้การสร้างคงสอดคล้องทั้งหน้าจอ API และฐานข้อมูล และลดการคุยกลับไปกลับมาเมื่อคุณเพิ่มฟีเจอร์ทีหลัง

ขอแผนสั้น ๆ ก่อนเขียนโค้ด คุณต้องการให้โมเดลตั้งชื่อหน้าจอและเส้นทาง ตาราง และ endpoints ของ API และให้ระบุสมมติฐานล่วงหน้า (เช่น บทบาทที่มี) และให้คงสมมติฐานเหล่านั้นไว้จนกว่าคุณจะอนุมัติการเปลี่ยนแปลง

นี่คือพรอมต์พื้นฐานที่คัดลอกไปใช้ได้เลย:

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.

ตัวอย่างที่ชัดเจน: หากแผนระบุ role: admin|member มันไม่ควรมาเพิ่ม manager ทีหลังเพราะต้องการแก้ปัญหา UI พรอมต์นี้บังคับให้โมเดลหยุดแล้วขออนุมัติแทนที่จะเปลี่ยนเอง

พรอมต์คัดลอก-วาง: หน้าจอและการนำทาง

หน้าจอที่ดีเริ่มจากแผนแผนผังเพจที่ชัดเจน ใช้พรอมต์ด้านล่างก่อนขอรหัสฐานข้อมูลหรือ API เพื่อให้เส้นทางและชื่อ UI คงที่ ซึ่งเป็นสาเหตุที่การสร้างหลายโปรเจ็กต์ล้มเหลว

พรอมต์ 1: รายการเพจและ flow ผู้ใช้

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.

หลังจากมันตอบ ให้ล็อกชื่อหน้าไว้ ถ้าคุณเปลี่ยนชื่อเส้นทางทีหลัง API และการทดสอบจะเบี้ยว

พรอมต์ 2: การนำทางและฟอร์มที่ใช้งานได้ดี

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.

ถ้า UI ที่ได้ซับซ้อนเกินไป ให้ขอให้เหลือเพียง layout เดียว สไตล์ตารางเดียว และรูปแบบฟอร์มเดียวในทุกหน้า

พรอมต์คัดลอก-วาง: การยืนยันตัวตนและบทบาท

ถ้าคุณต้องการผลลัพธ์ที่คาดเดาได้ ให้ระบุชัดเจนว่าผู้ใช้ล็อกอินอย่างไร เซสชันอยู่นานเท่าไร และแต่ละบทบาททำอะไรได้ พรอมต์ด้านล่างสมมติการล็อกอินแบบอีเมล+รหัสผ่านและวิธีการแบบ session-based (ทดสอบข้ามหน้าจอได้ง่าย)

วางพรอมต์นี้ก่อนเพื่อสร้างหน้าจอ login, logout และการจัดการเซสชัน:

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.

ต่อด้วยการเพิ่มบทบาทและกฎป้องกัน ขอให้สิทธิ์เล็กและทดสอบง่าย:

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.

การตรวจสอบแบบแมนนวลที่จับความผิดพลาดส่วนใหญ่ได้:

• ล็อกอินด้วยแต่ละบทบาทและยืนยันว่าคุณเห็น/ไม่เห็นสิ่งที่ควร
• ลองทำการกระทำที่ถูกจำกัด (เช่น ลบ) และยืนยันว่าได้ 403
• ยืนยันว่า logout ล้างเซสชันและแอปกลับไปหน้า Login

ถ้าคุณสร้างใน Koder.ai เก็บการเปลี่ยนแปลง auth และ RBAC ไว้ใน snapshot เดียวเพื่อสามารถ rollback ได้เมื่อสิทธิ์ยุ่งเหยิง

พรอมต์คัดลอก-วาง: สคีม่า PostgreSQL และโมเดลข้อมูล

พรอมต์สคีม่าที่ดีทำสองงาน: บังคับให้ความสัมพันธ์ระหว่างตารางชัดเจน (เพื่อให้หน้าจอและ API สอดคล้อง) และป้องกันฐานข้อมูลที่ “เกือบถูกต้อง” (ขาด index, timestamps หรือการ mapping บทบาท)

ก่อนวางพรอมต์ ให้ตัดสินใจสองตัวเลือกนี้ (หนึ่งบรรทัดแต่ละข้อ):

• Primary keys: uuid หรือ bigserial
• Soft delete: yes (ใช้ deleted_at) หรือ no (hard delete)

วางพรอมต์นี้เพื่อล็อกโมเดลข้อมูล:

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.

จากนั้นวางพรอมต์นี้เพื่อให้ได้ migrations หรือขั้นตอนการตั้งค่าที่ตรงกับโปรเจ็กต์:

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

ถ้ามีความไม่ชัดเจน ให้เพิ่มบรรทัดสุดท้ายว่า: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

พรอมต์คัดลอก-วาง: Go CRUD API (Postgres-backed)

ถ้า backend ที่ได้มาบ่อย ๆ ยังไม่สมบูรณ์ พรอมต์นี้จะบังคับให้มีพื้นฐานที่ชัดเจน: เส้นทางที่ชัด การตรวจสอบความถูกต้อง pagination และการตรวจสิทธิ์ในทุก handler

คัดลอกพรอมต์นี้แล้วแทนที่ตัวแปร (RESOURCE, FIELDS, ROLES) ด้วยรายละเอียดของแอปคุณ

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

หลังสร้าง ให้ตรวจสอบคร่าว ๆ ว่ามีความสอดคล้อง: โค้ดสถานะตอบกลับตรงกับโครงร่างข้อผิดพลาด, list endpoint คืนลำดับที่มั่นคง, และแต่ละ handler ตรวจทั้งบทบาทและความเป็นเจ้าของ tenant ก่อนเข้าถึง DB

ถ้าคุณใช้ Koder.ai ให้ระบุด้วยว่าหลังสร้าง backend ต้องยังเป็น Go และฐานข้อมูลต้องเป็น PostgreSQL เพื่อให้โค้ดที่ส่งออกตรงกับสแตกที่คาดไว้

ขั้นตอนทีละขั้น: สร้าง รัน และยืนยัน

สร้างทุกอย่าง (UI, API, DB) แล้วสลับไปที่โหมดตรวจสอบเข้มงวด เป้าหมายไม่ใช่ชื่นชมหน้าจอ แต่พิสูจน์ว่าวงจรเต็มทำงาน: UI - auth - roles - Postgres - API - UI

การตรวจสอบแบบเรียบง่าย

1. รันแอปและโหลดหน้าแรก ยืนยันการนำทางทำงานและไม่มีข้อมูลสำรอง (placeholder) หากหน้าว่าง ให้จดข้อความผิดพลาดที่ปรากฏ (toast UI, console หรือ server log)

2. สร้างบัญชีทดสอบหนึ่งบัญชีต่อบทบาท (Admin, Manager, Viewer). ล็อกอินและออกกับแต่ละผู้ใช้ ยืนยันว่าแอปแสดงบทบาทในที่ที่มองเห็นได้ (เมนูโปรไฟล์ การตั้งค่า หรือ badge เล็ก ๆ)

3. เลือกหน้าจอ CRUD หนึ่งหน้าและทำวงจรเต็ม: สร้างระเบียน, รีเฟรชหน้า, แก้ไข, แล้วลบ การตรวจสอบสำคัญคือความคงทน: หลังรีเฟรช ระเบียนต้องสะท้อนใน Postgres ไม่ใช่แค่หน่วยความจำ

4. ลองกระทำที่ถูกห้ามโดยตั้งใจ ล็อกอินเป็นบทบาทที่ต่ำสุดแล้วพยายามเข้าถึงหน้าของ admin เรียกใช้งานที่ถูกจำกัด (เช่น delete) และแก้ไขระเบียนที่ไม่ควรแก้ ผลต้องชัดเจน: UI ถูกบล็อกพร้อมข้อความ หรือ API คืน 403 โดยไม่มีการเปลี่ยนแปลงข้อมูล

5. ทดสอบขอบเขตพื้นฐาน: รายการว่าง ชื่อยาวมาก ฟิลด์บังคับที่หายไป และรูปแบบไม่ถูกต้อง (อีเมล วันที่) ยืนยันว่าแอปแสดงการตรวจสอบที่เป็นประโยชน์และไม่ล่ม

ถ้าคุณใช้ Koder.ai ให้สร้าง snapshot หลังการทดสอบ CRUD สำเร็จครั้งแรก เป็นจุด rollback ปลอดภัยก่อนเพิ่มฟีเจอร์

ข้อผิดพลาดของพรอมต์ที่พบบ่อยและวิธีแก้

ส่วนใหญ่แอปที่ “พัง” ไม่ได้พังจริง แต่ขาดเงื่อนไขหนึ่งข้อที่ทำให้ UI, API และ DB สอดคล้องกัน

1) คุณขอมากเกินไปในครั้งเดียว

เมื่อขอหน้าจอ auth บทบาท สคีม่า และทุกกรณีมุมในครั้งเดียว แอปมักไม่สอดคล้อง (เส้นทางไม่ตรง, โมเดลเบี่ยง, หน้าครึ่งเสร็จ)

แก้: แยกตามเลเยอร์และบังคับให้เครื่องมือสรุปสิ่งที่จะสร้างก่อนเขียนโค้ด ใน Koder.ai จะช่วยให้ตัวแทนหลายตัวสอดคล้องกัน

2) บทบาทไม่ชัดเจน ทำให้การตรวจสอบหาย

ถ้าคุณแค่บอกว่า “admin และ user” คุณอาจได้ป้ายบทบาทใน UI แต่ไม่มีการตรวจสิทธิ์ฝั่งเซิร์ฟเวอร์

แก้: กำหนดสิทธิ์เป็นการกระทำ (create, read, update, delete) ต่อ resource และบังคับใช้งานฝั่งเซิร์ฟเวอร์บนทุก endpoint

3) ขาดการระบุประเภทฟิลด์นำไปสู่การเบี่ยงของ UI และ DB

ถ้าคุณอธิบายฟิลด์เป็นภาษาเรียบง่าย (“price”, “date”, “status”) ฟอร์มอาจเรนเดอร์เป็นข้อความ ในขณะที่ Postgres ต้องการตัวเลข วันที่ หรือ enum

แก้: ระบุประเภทฟิลด์ ความเป็น null ค่าเริ่มต้น และข้อจำกัด และบังคับให้มีกฎการตรวจสอบเดียวกัน

4) ขาด loading และ error states ทำให้ UI ดูพัง

หากไม่มีสถานะการโหลดและข้อผิดพลาด คำขอที่ล้มเหลวจะดูเหมือนหน้าค้าง

แก้: ขอ spinner, empty states, และข้อความข้อผิดพลาดที่เห็นได้ชัดบนแต่ละหน้า

5) การเปลี่ยนชื่อกลางการสร้าง

การเปลี่ยนชื่อ “Projects” เป็น “Workspaces” กลางทางมักทำให้เส้นทาง handler และชื่อตารางพัง

แก้: สร้าง glossary ตั้งแต่ต้น เมื่อเปลี่ยนชื่อให้ขอแผนการเปลี่ยนชื่อ (search, replace, migrate) แทนให้โมเดลประดิษฐ์เอง

ใช้พรอมต์ซ่อมนี้เมื่อสิ่งต่าง ๆ เบี้ยว:

text 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. text

ถ้ายังเจอความไม่สอดคล้องบ่อย ๆ คุณอาจขาดประโยค “single source of truth” เพิ่มหนึ่งบรรทัด: “The Postgres schema is the source of truth; UI and API must match it exactly.”

เช็คลิสต์ด่วนก่อนจะถือว่าเสร็จ

ก่อนขัดเกลา ให้ตรวจสอบอย่างรวดเร็วว่าแอปทำงานเหมือนผลิตภัณฑ์จริง นี่คือที่แอป CRUD ส่วนใหญ่ล้มเหลว: ความไม่ตรงเล็ก ๆ ระหว่างหน้าจอ กฎ และข้อมูล

• Screens match the entity spec: ทุกหน้าจอ (list, details, create, edit) ใช้ชื่อเอนทิตี้และรายการฟิลด์ที่คุณกำหนด
• Roles are unambiguous: เขียนตาราง allow/deny ง่าย ๆ ต่อบทบาทและยืนยันว่า UI และ API บังคับใช้เหมือนกัน
• API responses are consistent: เลือกรูปแบบเดียวสำหรับ status codes, error shape, pagination และยืนยันทุก endpoint ตาม
• Database constraints match form validation: ถ้า DB ต้อง unique email หรือ non-null name ให้ตรวจสอบก่อนส่งและแสดงข้อความชัดเมื่อ API ปฏิเสธ
• Create/edit/delete survives a refresh: สร้างระเบียน รีเฟรช ยืนยันมันยังอยู่; แก้ไข รีเฟรช ยืนยัน; ลบ รีเฟรช ยืนยัน

ทดสอบจริง: ล็อกอินเป็นบทบาทที่สิทธิ์ต่ำสุดและลองกระทำที่คาดว่าจะถูกบล็อก (เช่น ลบ) หากสำเร็จ ให้แก้ policy ฝั่ง API ก่อน แล้วปรับ UI ให้ตรง

ตัวอย่างที่สมจริง: ระบบติดตามอุปกรณ์ IT แบบง่าย

นึกถึงทีมไอทีที่ยืม MacBook, จอมอนิเตอร์ และอะแดปเตอร์ให้พนักงาน พวกเขาต้องการที่เดียวที่เห็นว่าสินค้าอะไรพร้อม ใครยืม และคืนเมื่อไร กรณีนี้ทดสอบดีเพราะบังคับบทบาท หน้าจอไม่กี่หน้า และฐานข้อมูลจริง

Worksheet ที่กรอกตัวอย่างแล้ว

ใช้สิ่งนี้เป็น input สำหรับขั้นตอนเตรียม (คัดลอกแล้วแก้ชื่อได้ตามต้องการ):

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)

ลำดับการวางพรอมต์

วางพรอมต์ตามลำดับนี้เพื่อให้แอปคงสอดคล้อง:

1. พรอมต์พื้นฐาน (กฎรวม, สแตก, ชื่อ, การจัดการข้อผิดพลาด)
2. หน้าจอและการนำทาง (Inventory, Requests, Loans, Admin queue)
3. การยืนยันตัวตนและบทบาท (admin, staff, viewer)
4. สคีม่า PostgreSQL และข้อมูล seed (items, loans, requests, users)
5. Go CRUD API (endpoints และ validation ที่ตรงกับกฎ)

ผลลัพธ์ที่ดีคือ: staff ขอ “MBP-014” ได้, admin อนุมัติโดยกำหนด due date, และรายการ inventory แสดงว่าไม่พร้อมใช้งานพร้อมชื่อผู้ยืม

ถ้าการสร้างใกล้จะถูกแต่ยังไม่ใช่ ให้ปรับทีละอย่าง: เคลียร์สิทธิ์บทบาท (viewer ไม่ควรเห็นปุ่มแก้ไข), ยืนยันกฎ “หนึ่งสินค้าต่อหนึ่งการยืมที่ active”, หรือขอเปลี่ยนชื่อฟิลด์เพื่อให้ป้าย UI และคอลัมน์ DB ตรงกัน

ขั้นตอนต่อไป: ขยายอย่างปลอดภัยและนำชุดพรอมต์กลับมาใช้ใหม่

เมื่อพื้นฐานทำงาน ให้ปฏิบัติการเปลี่ยนแปลงเหมือนวงจรการปล่อยเล็ก ๆ เลือกฟีเจอร์หนึ่ง นิยามคำว่า “เสร็จ” แล้วส่งพรอมต์สำหรับฟีเจอร์นั้น

ลำดับที่สมเหตุสมผลสำหรับหลายแอป:

• Audit log: บันทึกว่าใครเปลี่ยนอะไรและเมื่อไหร่ (create, update, delete) และแสดงเฉพาะหน้า admin
• File uploads: แนบเอกสารหรือรูปกับระเบียน เก็บ metadata ใน Postgres และควบคุมการเข้าถึงด้วย auth
• Simple notifications: แจ้งเตือนในแอป (เช่น “stock ต่ำ” หรือ “มีคอมเมนต์ใหม่”) พร้อมปุ่ม “mark as read”

เมื่อการเปลี่ยนแปลงทำให้ระบบพัง อย่าพยายามแก้หลายจุดพร้อมกัน ย้อนกลับแล้วนำการเปลี่ยนแปลงขึ้นใหม่ทีละน้อย ใน Koder.ai snapshots และ rollback เป็นเครืองมือที่ปลอดภัย โดยเฉพาะก่อนเปลี่ยนสคีม่า DB, กฎ auth หรือคอมโพเนนต์ที่ใช้ร่วมกัน

โหมด Planning ยังช่วยเมื่อฟีเจอร์ข้ามหลายเลเยอร์ ขอให้โมเดลสรุปแผนก่อน (หน้าจอ, endpoints, การเปลี่ยนแปลง DB, บทบาท) แล้วอนุมัติแผนนั้นก่อนสร้างโค้ด จะป้องกันการไม่ตรงกันที่มักเกิดเมื่อ UI คาดฟิลด์ที่ API ไม่ส่ง หรือ API เขียนคอลัมน์ที่ไม่มีอยู่

ถ้าคุณทำงานนอกแพลตฟอร์ม ให้ส่งออกรหัสต้นฉบับแล้วทำงานต่อใน workflow ปกติ เก็บชุดพรอมต์ไว้ด้วยใน repo เป็น “คำสั่งสร้าง” เพื่อสร้างแอปซ้ำหรือช่วยคนใหม่เข้าทีม

ถ้าคุณสร้างบน Koder.ai (koder.ai) ชุดพรอมต์นี้สอดคล้องกับค่าเริ่มต้น React + Go + PostgreSQL ของแพลตฟอร์ม และสะดวกในการทำ iterating โดยใช้ snapshots ขณะที่คุณปรับความต้องการ

สุดท้าย บันทึกพรอมต์แม่แบบที่นำกลับมาใช้ใหม่ได้ เก็บส่วนที่คงที่ (stack, กฎ CRUD, ข้อกำหนด auth/roles, รูปแบบ PostgreSQL) และเปลี่ยนเฉพาะคำนามโดเมน เมื่อเวลาผ่านไปพรอมต์ของคุณจะกลายเป็นสูตรที่ใช้ซ้ำได้ แทนที่จะเป็นการทดลองครั้งเดียว