AI Coding Prompt Template for Frontend Page Development

A practical frontend development prompt template covering layout, fields, workflows, business rules, exception handling, and implementation notes, with targeted guidance for faithful UI implementation and a complete device-alarm example.

This frontend page development prompt template is organized into six sections: layout, field definitions, workflow, business rules, exception handling, and implementation notes. Mark anything uncertain in the relevant section. Most of the template comes from real development work and has been refined specifically to improve UI fidelity and implementation quality.

Template

1. Layout

• Sketch or design: 【file or link】
• Overall layout: 【describe the order of regions from top to bottom and left to right】
• Region A: 【location】; uses 【Table / Tree / Form, etc.】; contains 【fields, nodes, or content】; 【action】 is located at 【position】; displayed when 【condition】.
• Region B: 【location】; uses 【component type】; contains 【fields, nodes, or content】; 【action】 is located at 【position】; displayed when 【condition】.
• Scrolling and fixed content: 【page scrolling, region scrolling, fixed header, or fixed action column】
• Narrow-screen behavior: 【wrapping, hiding, rearranging, or local horizontal scrolling】

2. Field Definitions

• 【B / Form】Name (name): type 【string】, rendered with 【input】, required 【no】, default 【empty】, supports 【fuzzy search】.
• Table: 【column order, fixed columns, sorting, and pagination】
• Tree: 【node title, node value, parent/child fields, selection, and expansion rules】
• Form: 【field order, controls, required fields, defaults, and validation】
• Common formatting: 【date format, numeric units and precision, empty-value display, and enum source】

3. Workflow

Prerequisites: 【conditions that must be satisfied before the operation starts】

1. The user performs 【action】 in 【region】, and the system 【response and result】.
2. The user enters or selects 【field name (fieldName)】, and the system 【validation and result】.
3. After submission, 【data or status】 is updated to 【result】.
4. On completion, the page 【refreshes, closes, navigates, or retains content】.

4. Business Rules

• State transition: From 【current state】, performing 【action】 changes the state to 【resulting state】 when 【condition】 is met.
• Conditional rule: When 【condition】 is met, the system should 【behavior】, producing 【result】.
• Restriction rule: When 【restriction】 applies, 【action】 must not be performed, and the system displays 【message】.
• Other rules: 【permissions, data scope, sorting, pagination, or repeated operations】
• Region coordination: 【after an action in A, explain how B refreshes, filters, fills values, resets, appears, or hides】

5. Exception Handling

• Submission failure: When 【trigger】 occurs, display 【message】 and 【retain data, roll back, or allow retry】.
• Empty data: 【display and available actions】
• Loading failure: 【message and retry method】
• Insufficient permissions: 【display and handling】
• Data conflict: 【message and refresh behavior】
• Duplicate submission: 【disable or deduplication approach】

6. Implementation Notes

• Target route and directory: 【route, file, or directory】
• APIs and permissions: 【API, type files, and permission identifiers】
• Scope of changes: 【what may and may not be changed】
• Implementation requirements: 【components to reuse, special interactions, or performance requirements】
• Project constraints: Vue 3, TypeScript, Vite, and Ant Design Vue 4; follow the existing code structure and styling conventions.
• Verification requirements: 【workflow, exception scenarios, TypeScript, linting, and build】
• Open questions: 【write “None” if there are no open questions】

---

Example: Device Alarm Handling

1. Layout

• Sketch: Device Alarm Handling Page Sketch.jpg.
• Overall layout: A, B, and C are arranged from top to bottom; D opens from the right.
• Region A: At the top of the page, using Statistic to display the number of pending alarms.
• Region B: Below A, using Form with status and device-name fields; Search and Reset are on the right.
• Region C: Below B, using Table to display the alarm list; the View action is fixed on the right.
• Region D: On the right side of the page, using Descriptions and Form to show alarm details and handling fields; Submit and Close are at the bottom.
• Scrolling and fixed content: C has a fixed action column and supports internal scrolling; D's content area scrolls.

2. Field Definitions

• 【B / Form】Handling status (status): type string[], rendered as a multi-select, optional, defaulting to pending and handling.
• 【B / Form】Device name (deviceName): type string, rendered as an input, optional, and supports fuzzy search.
• 【C / Table】Alarm number (alarmNo): type string, shown in full and copyable.
• 【C / Table】Alarm content (alarmContent): type string, displayed on at most two lines.
• 【D / Form】Handling notes (handleRemark): type string, rendered as a textarea, required, maximum 500 characters.
• 【D / Form】Handling result (handleResult): type string, rendered as radio buttons, required, with recovered and repair_required as options.
• Common formatting: Display empty values as “--”; enums come from the API.

3. Workflow

1. The page loads pending alarms by default.
2. Click “View” in C to open D.
3. After the alarm is acknowledged, its status changes to Handling (handling).
4. Submit the handling result in D and close the alarm; its status changes to Closed (closed).

4. Business Rules

• State transitions: Pending (pending) becomes Handling (handling) after acknowledgment; submitting a result changes it to Waiting to Close (waiting_close); closing it changes it to Closed (closed).
• The same alarm can be acknowledged only once. If it is acknowledged again, abort the operation and refresh the data.
• Only the current handler may submit a handling result.
• Closed alarms are read-only.
• Region coordination: Searching in B refreshes C; viewing an item in C opens D; submitting in D refreshes A, C, and D together.

5. Exception Handling

• Query failure: Display “Failed to load alarms,” retain the filters, and allow reloading.
• Duplicate acknowledgment: Display “This alarm has already been acknowledged by another user,” abort the operation, and refresh the data.
• Submission failure: Display the API error, retain entered content, and allow retrying.
• Empty data: Provide a reset action. Insufficient permissions: Hide the list. Request in progress: Disable the Submit button.

6. Implementation Notes

• Target route and directory: /monitor/alarm and src/views/monitor/alarm.
• Reuse the existing table, permission, and request abstractions; do not modify the shared layout.
• Verify state transitions, exception scenarios, TypeScript, linting, and the build.
• Use existing features as references for API definitions; mark anything not yet implemented with TODO.
• Open questions: API definitions and permission codes.

---

Make every section precise and unambiguous.