Vibe 编码提示：用于 CRUD 应用的全栈可复制粘贴套件

Q: What’s the fastest way to get a working CRUD app from these prompts?

Start with the core entity and its 6–12 fields (name, type, required/optional, examples). Then lock roles + permissions in plain language, and ask for a short plan before any code.\n\nA good default is to generate in this order:\n\n- Global rules (stack, naming, error handling)\n- Screens + routes\n- Auth + RBAC\n- PostgreSQL schema + seed data\n- Go CRUD API

Q: Why do you say prompt quality matters more than model choice for CRUD builds?

Because it forces the model to treat UI, API, and database as a single contract . Vague prompts usually create drift:\n\n- UI uses one field name, API expects another\n- routes don’t match navigation\n- auth exists in UI but not enforced in the API\n\nA tight prompt makes names, rules, and validations match across layers.

Q: How do I choose the “main entity” and field list without overthinking it?

Pick a core entity you’ll manage every day (Customer, Task, Item). Keep it to one entity on day one unless a second entity is truly required for the workflow.\n\nA practical default:\n\n- 1 main entity + optional 1 supporting entity (like Category)\n- 6–12 fields with types and examples\n- 2–3 roles with clear CRUD permissions

Q: Why should I include field examples (not just names and types)?

Because examples guide labels, formatting, and validation . If you only say “date” or “status,” you’ll often get mismatched UI inputs (text box) versus DB types (date/enum).\n\nUse a consistent field line format:\n\n- \n\nThis helps the React form, Go validation, and PostgreSQL constraints stay aligned.

Q: What’s a simple RBAC setup that stays easy to test?

Use 2–3 roles max, mapped to the CRUD verbs list, view, create, update, delete .\n\nA solid default:\n\n- admin : full CRUD + manage users/roles\n- manager : create/read/update/list; no delete; no user management\n- viewer : read-only (list + view)\n\nThen require enforcement in both UI routes and API endpoints.

Q: How do I make sure permissions are enforced server-side, not just in the UI?

Implement and test both:\n\n- UI protection : hide nav items and block routes with a “Not allowed” page\n- API protection : return when not logged in, when logged in but not allowed\n\nA practical rule: if the UI blocks an action, the API must still reject it if called directly.

Q: What auth flow should I ask for to keep things predictable?

Default to email + password with session persistence across refresh.\n\nMinimum requirements to request:\n\n- UI: Login page, logout action, “My account” page (shows email + role)\n- API: , , \n- Security basics: hashed passwords, rate-limit login attempts, generic error text\n\nSeed a single admin user for local testing.

Q: How do I prevent route and naming drift across the UI, API, and database?

Pick one convention and enforce it everywhere:\n\n- Routes : kebab-case, consistent singular/plural\n- Components : PascalCase, one top-level page component per route\n- Fields : same names in UI form, API JSON, and DB columns\n\nIf you rename anything later, request a rename plan (search/replace + migrations) instead of letting the model improvise.

Q: What should I require for list endpoints (pagination, filtering, sorting)?

Ask the model to return the same shape from every list endpoint:\n\n- Query params: , , plus your filters\n- Response: , , , \n\nAlso require stable sorting (for example then ) so pagination doesn’t skip or duplicate items.

Q: If my generated app is “almost working” but inconsistent, how do I fix it quickly?

Use an audit prompt that compares:\n\n- UI routes vs API paths\n- Form fields vs request/response JSON\n- JSON fields vs DB columns\n- Validation rules vs DB constraints\n\nThen apply a minimal patch plan.\n\nA good rule is: don’t add features while fixing mismatches —only align names, routes, validations, and permissions.

登录开始使用

这个提示集会构建什么（通俗说明）\n\n这个提示集用于生成一个完整、可运行的 CRUD 应用：包含用户使用的界面、处理请求的 API，以及存储数据的 PostgreSQL 数据库。它还包含登录和基于角色的访问控制，让不同用户看到并执行不同的操作。\n\nCRUD 即日常应用所需的四种操作：\n\n- Create：添加新记录（例如客户或任务）\n- Read：查看列表并打开单个项\n- Update：编辑已有项\n- Delete：删除项（通常带确认步骤）\n\n在前端，你应该最终得到一组可预测的页面：列表页、详情页、创建表单、编辑表单，以及登录页面和基本导航。在后端，会有与这些页面一一对应的端点（list、get by id、create、update、delete），由 Postgres 表和简单校验支撑。\n\n提示的质量比模型选择更重要。模型只能执行你明确说明的内容。如果提示含糊，你会得到不匹配的字段名、缺少的路由、不完整的认证，或与 API 不一致的 UI。一个严谨的提示就像一份契约：UI、API 和数据库都使用相同的名称和规则。\n\n在开始之前，先决定几个细节以保持构建一致：\n\n- 你的主实体以及 6 到 12 个字段（名称、类型、必填或可选）\n- 角色（例如：admin、manager、viewer）以及每个角色能做什么\n- 基本规则（谁能编辑、软删除还是硬删除、必填字段）\n- 第一天需要的“happy path”屏幕\n- 任何约束（唯一字段、日期范围、状态值）\n\n如果你使用 Koder.ai，这可以是一段对话，生成匹配的 React UI、Go API 和 PostgreSQL 模式，免去手工粘合的麻烦。\n\n## 准备工作表：开始提示前需要的少量信息\n\n一个好的 CRUD 构建从少量决策开始。先把它们写下来，这样提示会更清晰，界面看起来也正确，API 会与数据库匹配。\n\n从一个核心实体开始。这是你的应用每天要管理的“事物”（Item、Customer、Appointment）。除非第二个实体在第一天确实必需（例如 Item 需要 Category），否则不要一开始就加入第二个实体。如果一次加三四个实体，你会把时间花在理清关系上，而不是得到一个可工作的应用。\n\n把实体字段写成类型并给出示例。示例很重要，因为它会影响标签、格式和校验。\n\n- Field: type - example (notes)\n- name: text - "Paper towels" (required, 2-80 chars)\n- quantity: number - 24 (min 0)\n- reorder_date: date - 2026-02-01 (optional)\n- status: enum - "in_stock" | "low" | "out" (default in_stock)\n\n接下来，用通俗语言列出角色和权限。保持具体。对很多应用来说，2 到 3 个角色就够了：\n\n- Admin：管理用户，对所有记录有完整 CRUD 权限\n- Manager：对记录有 CRUD 权限，但不能管理用户\n- Viewer：只读\n\n最后，创建 5 到 10 条示例记录。这些示例会驱动真实的 UI 标签、下拉选项和合理的默认值。示例（库存）：“Hand soap, qty 6, reorder_date 2026-01-20, status low”。\n\n如果你在 Koder.ai 上构建，把这个工作表粘贴到你的第一个提示中，这样平台可以在屏幕、认证和 PostgreSQL 支持的 API 之间保持应用一致性。\n\n## 基础提示：为整个构建设定规则\n\n先写一条“运行规则”提示。它能在屏幕、API 和数据库之间保持一致，减少在你后续添加功能时的来回沟通。\n\n在任何代码之前要求一个简短计划。你希望模型列出屏幕和路由、表和 API 端点。同时要求它先说明假设（比如有哪些角色），并在未经你同意前不要更改这些假设。\n\n这里有一份可复制粘贴的基础提示：\n\n\nYou are building a complete full-stack CRUD app.\n\nTech targets (do not change):\n- Frontend: React web app\n- Backend: Go REST API\n- Database: PostgreSQL\n\nBefore writing any code, produce a short plan (max 25 lines) that includes:\n1) Screens + key UI components\n2) Routes/navigation\n3) Roles and permissions\n4) PostgreSQL tables (with columns and relationships)\n5) API endpoints (method + path) for auth and CRUD\n\nAssumptions:\n- If any detail is missing, make a reasonable default and list it under “Assumptions”.\n- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.\n\nRules:\n- Use simple, boring CRUD first. No “nice to have” features unless asked.\n- Include input validation, basic error messages, and loading states.\n- Use clear names that match across layers (same field names in UI, API, and DB).\n\nNon-goals (do NOT implement):\n- Payments, subscriptions, invoices\n- Complex workflows/approvals\n- Multi-tenant org hierarchy\n- Real-time chat/notifications\n\nNow ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.\n\n\n一个具体的例子：如果计划里选了 `role: admin|member`，后面就不应该再为了某个 UI 边缘情况把 `manager` 发明出来。这个提示会让模型在改动前暂停并征求你的确认，而不是随意漂移。\n\n## 可复制粘贴的提示：页面和导航\n\n好的页面来自先明确的页面映射。先用下面的提示来确定页面，再去请求数据库或 API 代码。这样可以在后续保持路由和 UI 名称的稳定，这是很多构建出错的原因。\n\n### 提示 1：页面列表与用户流程\n\ntext\nYou are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.\n\nApp concept (1 sentence): <PASTE YOUR APP CONCEPT>\nEntities (list): <ENTITY_1>, <ENTITY_2>\nRoles: <ROLE_1>, <ROLE_2> (include an Admin role)\n\nDeliverables:\n1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.\n2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.\n3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.\n4) Component naming rules: PascalCase, one top-level page component per route.\nAsk me 5 questions max only if needed.\n\n\n在它回答后，锁定这些名称。如果你之后更改路由名，API 和测试可能会不同步。\n\n### 提示 2：导航与行为良好的表单\n\ntext\nUsing the approved page list and route names, generate:\n\nA) Navigation\n- A simple top nav for desktop and a compact mobile menu.\n- Show which items appear for each role.\n- Add a clear "You do not have access" page and redirect rules.\n\nB) Page skeletons\nFor each page, create a minimal UI with:\n- A visible page title and short helper text.\n- Loading state, empty state, error state.\n- A primary button for the main action.\n\nC) Accessible forms\nFor all create/edit forms:\n- Labels tied to inputs, required markers, inline validation errors.\n- Disable submit while saving, show a spinner, prevent double submits.\n- Toast or inline success message after save.\n\nD) Consistent action names\nUse these verbs exactly: list, view, create, update, delete.\nUse these UI actions: onCreate, onUpdate, onDelete, onSearch.\n\n\n如果 UI 返回太复杂，要求它在所有页面只保留一种布局、一种表格样式和一种表单模式。\n\n## 可复制粘贴的提示：认证和角色\n\n如果你想要可预测的结果，请明确说明用户如何登录、会话时长，以及每个角色能做什么。下面的提示假定简单的邮箱 + 密码登录和基于会话的方法（便于跨屏幕测试）。\n\n先把这段粘进去以生成登录、登出和会话处理：\n\n\nImplement authentication for this app.\n\nRequirements:\n- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.\n- Use email + password login.\n- Session handling: keep the user logged in across refresh; include a clear “Log out” button.\n- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.\n- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.\n\nSecurity (keep it simple):\n- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.\n- Store passwords securely (hash + salt). Never store plain text.\n- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.\n\nDeliverables:\n- Working UI flows + backend endpoints.\n- Seed one default admin user for local testing and tell me the credentials.\n- Add clear comments explaining where to change password rules and session duration.\n\n\n现在添加角色和保护规则。保持权限少且易于测试：\n\n\nAdd role-based access control (RBAC) with these roles: admin, manager, viewer.\n\nRules:\n- admin: can create, edit, delete, and manage users/roles.\n- manager: can create and edit records, cannot delete, cannot manage users.\n- viewer: read-only.\n\nEnforcement:\n- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.\n- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.\n\nDeliverables:\n- A simple “Users” admin screen to list users and change roles.\n- A clear table (in text) mapping each route + API endpoint to required role.\n- Add automated checks or middleware so every protected endpoint enforces the rules.\n\n\n快速的手动检查可以捕获大多数错误：\n\n- 以每个角色登录，确认你能看到和做的事情与预期一致。\n- 故意尝试受限操作（如删除），确认返回 403。\n- 确认登出会清除会话并返回登录页面。\n\n如果你在 Koder.ai 上构建，把认证和 RBAC 的更改保存在一个快照中，这样权限混乱时可以清晰回滚。\n\n## 可复制粘贴的提示：PostgreSQL 模式与数据模型\n\n一个好的模式提示有两个作用：强制清晰的表关系（这样屏幕和 API 才能保持一致），并防止“差不多”的数据库（缺少索引、时间戳或角色映射）。\n\n在粘贴前，决定下列两项开关（一行一项）：\n\n- 主键类型：`uuid` 或 `bigserial`\n- 软删除：`yes`（使用 `deleted_at`）或 `no`（硬删除）\n\n先粘这个提示来锁定数据模型：\n\n\nYou are building the PostgreSQL data model for a full-stack CRUD app.\n\nDomain: <DESCRIBE YOUR APP IN 1 SENTENCE>\nCore entities: <LIST 3-6 ENTITIES>\n\nRules:\n- Use PostgreSQL.\n- Choose primary key type: <uuid|bigserial>.\n- Timestamps: every table must have created_at and updated_at.\n- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.\n- Define users, roles, and permissions storage:\n - users table (email unique, password_hash, status)\n - roles table (name unique)\n - user_roles join table (user_id, role_id) with unique(user_id, role_id)\n- For each core entity: define columns, types, required vs optional, and relationships.\n- Call out any many-to-many relationships and introduce join tables.\n- Propose indexes for common lookups (foreign keys, email, name/search fields).\n\nOutput:\n1) A short ERD description in plain English.\n2) The final table list with columns and constraints.\n3) The index list with rationale.\n\n\n然后粘这个提示以生成匹配项目的迁移或设置步骤：\n\n\nNow generate the actual database setup for this project.\n\nRequirements:\n- Provide SQL migrations (up and down) for all tables, constraints, and indexes.\n- Ensure foreign keys and on-delete behavior are explicit.\n- Include extensions you rely on (for example uuid generation), but only if needed.\n- Add a seed migration for: one admin user, one admin role, and the user_roles link.\n\nOutput:\n- migrations/ file names in order\n- contents of each up/down migration\n- brief notes on how to apply migrations in the project\n\n\n如果有任何模糊之处，额外加一句：“如果关系或字段不明确，在写 SQL 之前最多向我问 5 个问题。”\n\n## 可复制粘贴的提示：Go CRUD API（基于 Postgres）\n\n如果后端输出经常不完整，这个提示会强制基础内容：清晰的路由、校验、分页，以及每个处理器中的角色检查。\n\n按原样粘贴下面内容，然后把占位符（RESOURCE、FIELDS、ROLES）替换为你的应用细节。\n\ntext\nYou are building the backend API in Go for a Postgres-backed CRUD resource.\n\nResource\n- RESOURCE name (singular/plural): <Item/items>\n- Table: <items>\n- Primary key: <id UUID>\n- Fields (name, type, required?, rules):\n - <name TEXT required, 2..80 chars>\n - <qty INT required, min 0>\n - <status TEXT optional, one of: active, archived>\n- Ownership: <tenant_id UUID required> and <created_by UUID required>\n\nAuth and roles\n- Roles: <admin, manager, viewer>\n- Authorization rules:\n - Every endpoint must check role and tenant_id.\n - admin: full access\n - manager: create, read, update, list; cannot delete\n - viewer: read and list only\n\nAPI requirements\n1) Implement REST endpoints:\n- POST /api/items\n- GET /api/items/{id}\n- PUT /api/items/{id}\n- DELETE /api/items/{id}\n- GET /api/items\n\n2) Define request/response JSON shapes for each endpoint, including examples.\n\n3) Validation\n- Return 400 with field-level errors (clear messages) when invalid.\n- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.\n\n4) List endpoint\n- Support filtering by: <status>\n- Support sorting by: <created_at,name> with order asc/desc\n- Support pagination: page, page_size; return total, page, page_size, items.\n\n5) Data access\n- Use database/sql (or pgx) with parameterized queries only.\n- Include migrations SQL for the table and indexes (tenant_id + created_at).\n\nDeliverables\n- Go code: routes, handlers, DTOs, validation helpers, repository layer\n- SQL: migration(s)\n- Notes: any assumptions\n\n\n生成后做一次快速一致性检查：状态码与错误体匹配、列表端点返回稳定排序、每个处理器在访问数据库前都检查角色和租户归属。\n\n如果你在 Koder.ai 上构建，还要强调后端必须保持 Go，数据库必须保持 PostgreSQL，以便导出的代码符合预期栈。\n\n## 逐步：生成、运行与验证\n\n生成所有东西（UI、API、数据库）后，切换到严格验证模式。目标不是欣赏界面，而是证明完整闭环有效：UI - 认证 - 角色 - Postgres - API - UI。\n\n### 一个简单的验证流程\n\n1) 运行应用并加载首页。确认导航可用且没有占位数据。如果页面是空白，记录第一个可见错误信息（UI 吐司、控制台或服务器日志）。\n\n2) 为每个角色创建一个测试账户（Admin、Manager、Viewer）。使用每个用户登录/登出。确认应用在明显位置显示角色（个人菜单、设置或小徽章）。\n\n3) 选择一个 CRUD 页面并做完整流程：创建记录，刷新页面，然后编辑并删除。关键检查是持久化：刷新后记录应反映 Postgres 中的数据，而不是仅存在内存。\n\n4) 有意尝试被禁止的操作。以最低权限角色登录并访问管理员页面，调用受限操作（如 delete），编辑不应允许的记录。期望明确结果：要么 UI 阻止且显示信息，要么 API 返回类似 403 的错误且没有数据变更。\n\n5) 测试基本边界情况：空列表、超长名称、缺少必填字段、格式错误（email、日期）。确认应用显示有帮助的校验信息并且不崩溃。\n\n如果你在 Koder.ai 上构建，在第一次成功的端到端 CRUD 测试后创建一个快照。这给你一个在开始添加扩展前的安全回滚点。\n\n## 常见提示失败及修复方法\n\n大多数“坏掉”的构建并非无法修复，而是缺少某个约束，导致 UI、API 和数据库不同步。\n\n### 1) 你一次性请求太多\n\n当你同时要求屏幕、认证、角色、模式和每个边界情况时，应用常常不一致（路由不匹配、模型漂移、页面半成品）。\n\n修复：按层拆分工作，并强制工具在写代码前重述它将生成的内容。在 Koder.ai 中，这也有助于让多个 agent 保持一致。\n\n### 2) 角色描述含糊，导致检查缺失\n\n如果你只说“admin 和 user”，可能会在 UI 中看到角色标签，但后端没有真正的授权检查。\n\n修复：为每个资源按动作（create、read、update、delete）定义权限，并要求每个端点在服务端强制执行。\n\n### 3) 缺少字段类型导致 UI 与 DB 漂移\n\n如果你用口语描述字段（“price”、“date”、“status”），表单可能会渲染为文本输入，而 Postgres 期望数字、日期或枚举。\n\n修复：指定字段类型、可空性、默认值和约束，并要求共享的校验规则。\n\n### 4) 没有加载与错误状态，导致 UI 看起来坏了\n\n没有加载与错误状态时，请求失败看起来像页面卡住。\n\n修复：为每个页面要求加载指示、空状态和可见错误信息。\n\n### 5) 名称在构建中途变更\n\n把“Projects”改成“Workspaces”会破坏路由、处理器和表名。\n\n修复：尽早锁定术语表。如果你确实要改名，请请求重命名计划（搜索/替换 + 迁移），而不是让模型随意即兴改动。\n\n当出现问题时使用这个修复提示：\n\n`text\nAudit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.\nThen propose a minimal patch plan.\nRules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.\nOutput: a checklist of changes, then apply them.\n`\n\n如果你不断遇到不一致问题，很可能缺少一条“单一真实来源（single source of truth）”声明。加上一句：“The Postgres schema is the source of truth; UI and API must match it exactly.”\n\n## 发布前的快速检查表\n\n在投入时间美化之前，快速确认应用行为像真实产品。这是大多数全栈 CRUD 应用失败的地方：屏幕、规则和数据之间的小不一致。\n\n- Screens match the entity spec：每个屏幕（list、details、create、edit）都使用你定义的确切实体名称和字段列表。\n- Roles are unambiguous：为每个角色写一个简单的允许/拒绝表，并确认 UI 与 API 都强制相同规则。\n- API responses are consistent：选一个统一模式（状态码、错误形状、分页形状），并验证每个端点一致地遵循它。\n- Database constraints match form validation：如果数据库要求 email 唯一或 name 非空，就在提交前校验并在 API 拒绝时显示清晰信息。\n- Create/edit/delete survives a refresh：创建记录，刷新确认仍在；编辑，刷新确认；删除，刷新确认。\n\n一个具体测试：以最低权限角色登录并尝试你期望被阻止的操作（如删除）。如果成功了，先在 API 修复策略（一个地方），然后调整 UI 以匹配。\n\n## 现实例子：一个简单的库存跟踪器\n\n设想一个小型 IT 团队向员工借出笔记本、显示器和适配器。他们需要一个地方查看可用物品、谁借走了什么以及何时应归还。这是个好用例，因为它涉及角色、一些页面和真实数据库。\n\n### 填写好的准备工作表\n\n把下面的文本作为你的准备输入（按原样复制，然后修改名称）：\n\ntext\nApp name: IT Equipment Loans\nGoal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.\nRoles:\n- admin: manage inventory, approve/deny requests, edit any loan, see all\n- staff: browse inventory, create a request, see own requests/loans\n- viewer: read-only access to inventory and aggregate loan status\nCore screens:\n- Login\n- Inventory list + item detail\n- Request item (staff)\n- Admin requests queue\n- Loans list (filter: active/overdue)\nData rules:\n- An item can have 0 or 1 active loan at a time\n- Due date required for approved loans\n- Overdue if due_date < today and not returned\nSample data:\n- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)\n- Users: alice(admin), ben(staff), carla(viewer)\n\n\n### 推荐的粘贴顺序\n\n按这个顺序粘贴你的提示，以便应用保持一致：\n\n1) 基础提示（全局规则、技术栈、命名、错误处理）\n2) 页面与导航（Inventory、Requests、Loans、Admin queue）\n3) 认证与角色（admin、staff、viewer 权限）\n4) PostgreSQL 模式与种子数据（items、loans、requests、users）\n5) Go CRUD API（与规则匹配的端点和校验）\n\n一个良好结果的样子：staff 可以请求 “MBP-014”，admin 批准并填写到期日，库存列表显示此物品不可用并展示借用人姓名。\n\n如果构建接近但不对，逐项调整：收紧角色权限（viewer 不应看到编辑按钮）、重申“每个物品同时只能有一个活跃借出”的规则，或要求重命名字段以便 UI 标签和数据库列完全一致。\n\n## 下一步：安全扩展与重用提示集\n\n基础工作完成后，把后续更改当作小迭代发布。选一个功能、定义“完成”的标准，然后再提示实现它。\n\n对很多应用来说，合理的扩展顺序是：\n\n- Audit log：记录谁在何时做了什么（create、update、delete），并在仅管理员可见的页面展示。\n- File uploads：为记录附加文档或图片，把元数据存入 Postgres，并在鉴权后提供访问。\n- Simple notifications：展示应用内提醒（例如“库存不足”或“有新评论”），并提供“标记为已读”动作。\n\n当改动破坏构建时，不要一次修复所有问题。回滚，然后用更小、更具体的提示重新应用改动。如果你使用 Koder.ai，快照与回滚是实用的安全网，尤其在更改涉及 DB 模式、认证规则或共享 UI 组件时。\n\nPlanning Mode 在跨层特性（屏幕、API、数据库）时也很有用。先让模型重述计划（屏幕、API 端点、数据库变更、角色），批准该计划后再生成代码，能避免 UI 期望的字段与 API 返回的不一致，或 API 写入不存的列这类常见问题。\n\n如果你想在平台外继续开发，导出源码并在你常用的工作流中修改。把提示集保存在仓库旁作为“构建说明”，以便以后重现应用或帮助新成员上手。\n\n如果你在 Koder.ai (koder.ai) 上构建，这套提示与平台的 React + Go + PostgreSQL 默认配置相匹配，很容易在你精细化需求时使用快照安全迭代。\n\n最后，为下一个项目保存一个可重复使用的模板提示。保留稳定部分（栈、CRUD 规则、认证与角色惯例、Postgres 模式），仅替换领域名词。随着时间推移，你的提示会变成可重复的配方，而不是一次性的实验。

常见问题

What’s the fastest way to get a working CRUD app from these prompts?

Start with the core entity and its 6–12 fields (name, type, required/optional, examples). Then lock roles + permissions in plain language, and ask for a short plan before any code.\n\nA good default is to generate in this order:\n\n- Global rules (stack, naming, error handling)\n- Screens + routes\n- Auth + RBAC\n- PostgreSQL schema + seed data\n- Go CRUD API

Why do you say prompt quality matters more than model choice for CRUD builds?

Because it forces the model to treat UI, API, and database as a single contract. Vague prompts usually create drift:\n\n- UI uses one field name, API expects another\n- routes don’t match navigation\n- auth exists in UI but not enforced in the API\n\nA tight prompt makes names, rules, and validations match across layers.

How do I choose the “main entity” and field list without overthinking it?

Pick a core entity you’ll manage every day (Customer, Task, Item). Keep it to one entity on day one unless a second entity is truly required for the workflow.\n\nA practical default:\n\n- 1 main entity + optional 1 supporting entity (like Category)\n- 6–12 fields with types and examples\n- 2–3 roles with clear CRUD permissions

Why should I include field examples (not just names and types)?

Because examples guide labels, formatting, and validation. If you only say “date” or “status,” you’ll often get mismatched UI inputs (text box) versus DB types (date/enum).\n\nUse a consistent field line format:\n\n- field_name: type - example (rules)\n\nThis helps the React form, Go validation, and PostgreSQL constraints stay aligned.

What’s a simple RBAC setup that stays easy to test?

Use 2–3 roles max, mapped to the CRUD verbs list, view, create, update, delete.\n\nA solid default:\n\n- admin: full CRUD + manage users/roles\n- manager: create/read/update/list; no delete; no user management\n- viewer: read-only (list + view)\n\nThen require enforcement in both UI routes and API endpoints.

How do I make sure permissions are enforced server-side, not just in the UI?

Implement and test both:\n\n- UI protection: hide nav items and block routes with a “Not allowed” page\n- API protection: return 401 when not logged in, 403 when logged in but not allowed\n\nA practical rule: if the UI blocks an action, the API must still reject it if called directly.

What auth flow should I ask for to keep things predictable?

Default to email + password with session persistence across refresh.\n\nMinimum requirements to request:\n\n- UI: Login page, logout action, “My account” page (shows email + role)\n- API: POST /auth/login, POST /auth/logout, GET /auth/me\n- Security basics: hashed passwords, rate-limit login attempts, generic error text\n\nSeed a single admin user for local testing.

How do I prevent route and naming drift across the UI, API, and database?

Pick one convention and enforce it everywhere:\n\n- Routes: kebab-case, consistent singular/plural\n- Components: PascalCase, one top-level page component per route\n- Fields: same names in UI form, API JSON, and DB columns\n\nIf you rename anything later, request a rename plan (search/replace + migrations) instead of letting the model improvise.

What should I require for list endpoints (pagination, filtering, sorting)?

Ask the model to return the same shape from every list endpoint:\n\n- Query params: page, page_size, plus your filters\n- Response: total, page, page_size, items\n\nAlso require stable sorting (for example then ) so pagination doesn’t skip or duplicate items.

If my generated app is “almost working” but inconsistent, how do I fix it quickly?

Use an audit prompt that compares:\n\n- UI routes vs API paths\n- Form fields vs request/response JSON\n- JSON fields vs DB columns\n- Validation rules vs DB constraints\n\nThen apply a minimal patch plan.\n\nA good rule is: don’t add features while fixing mismatches—only align names, routes, validations, and permissions.

created_at

id

Vibe 编码提示：用于 CRUD 应用的全栈可复制粘贴套件 | Koder.ai