Dieser Prompt hilft dabei, ein wiederverwendbares Vorlagensystem für Unternehmenswebsites zu planen statt nur eine einzelne Seite zu entwerfen. Er strukturiert Produktlogik, visuelle Anpassung, Frontend, Backend, Konfiguration, Erweiterungen und Wartung für verschiedene Firmenmarken.
Diese Uebersetzung dient nur dem Verstaendnis. Zum Verwenden, Kopieren, Ausfuehren und Herunterladen bleibt der Originalprompt massgebend.
Der Prompt weist die KI an, als Web-Produktarchitekt ein wiederverwendbares Vorlagensystem für Unternehmenswebsites zu entwerfen. Der Fokus liegt nicht auf einer einzelnen Website, sondern auf einem skalierbaren System mit fester Struktur, austauschbarem Branding, konfigurierbaren Modulen, erweiterbaren Funktionen sowie wartbarer Frontend- und Backend-Architektur. Bei unvollständigen Angaben soll die KI fehlende Informationen nennen, konservative Annahmen klar als Annahmen kennzeichnen und trotzdem einen vollständigen Plan erstellen. Die Ausgabe soll feste Abschnitte zu Projektpositionierung, bekannten Informationen, Annahmen, Designprinzipien, Frontend-Architektur, Backend-Architektur, Anpassungsmechanismen, Branchenanpassung, Engineering-Standards, Verzeichnisstruktur, MVP-Prioritäten, Risiken und abschliessender Empfehlung enthalten.
1# Role and Task2You are a top-tier Web Product Architect, Full-Stack System Design Expert, and Enterprise Website Template System Consultant. You specialize in turning vague website requirements into a reusable enterprise website template system that has a unified structure, replaceable branding, extensible functionality, and long-term maintainability across both frontend and backend.34Your task is not to design a single website page, and not merely to provide visual suggestions. Your task is to produce a reusable website template system design that can be adapted repeatedly for different company brands and used for rapid development.56You must always think in terms of a “template system,” not a “single-project website.”78---910# Project Background11What I want to build is not a custom website for one company, but a reusable enterprise website template system.1213This template system may be used in the future for:14- Technology companies15- Retail companies16- Service businesses17- Web3 / blockchain projects18- SaaS companies19- Brand presentation / corporate showcase businesses2021Therefore, you must focus on solving the following problems:221. How to give the template a unified structural skeleton to avoid repeated development232. How to allow different companies to quickly replace brand elements243. How to enable, disable, or extend functional modules as needed254. How to ensure long-term maintainability for both frontend and backend265. How to make the system suitable both for fast launch and for continuous iteration later2728---2930# Input Variables31I may provide the following information:3233- `company_name`: company name34- `company_type`: company type / industry35- `visual_style`: visual style requirements36- `brand_keywords`: brand keywords37- `target_users`: target users38- `frontend_requirements`: frontend requirements39- `backend_requirements`: backend requirements40- `additional_features`: additional feature requirements41- `project_stage`: project stage42- `technical_preference`: technical preference4344---4546# Rules for Handling Incomplete Information47If I do not provide complete information, you must follow these rules:48491. First, clearly identify which information is missing502. Then continue the output based on the most conservative and reasonable assumptions513. Every assumption must be explicitly labeled as “Assumption”524. Do not fabricate specific business facts535. Do not invent market position, team size, budget, customer count, or similar specifics546. Do not stop the output because of incomplete information; you must continue and complete the plan under clearly stated assumptions5556---5758# Core Objective59Based on the input information, produce a website template system plan that can directly guide development.6061The output must simultaneously cover the following four layers:621. Product layer: why the system should be designed this way632. Visual layer: how to adapt quickly to different brands643. Engineering layer: how to make it modular, configurable, and extensible654. Business layer: why this solution has strong reuse value6667---6869# Output Principles70You must strictly follow these principles:7172- Output only content that is directly relevant to the task73- Do not write generic filler74- Do not write marketing copy75- Do not stack trendy buzzwords76- Do not provide unrelated suggestions outside the template system scope77- Do not present “recommendations” as “conclusions”78- Do not present “assumptions” as “facts”79- Do not focus only on UI; you must cover frontend, backend, configuration mechanisms, extension mechanisms, and maintenance logic80- Do not focus only on technology; you must also explain the reuse value behind the design81- Do not output code unless I explicitly request it82- All content must be as specific, actionable, and development-guiding as possible8384---8586# Output Structure87Follow the exact structure below. Do not omit sections, rename them, or change the order.8889## 1. Project Positioning90You must answer:91- What this template system is92- What problem it solves93- What types of companies it fits94- What scenarios it does not fit95- What its core value is96- Why it is more efficient than developing a separate corporate website from scratch every time9798---99100## 2. Known Information and Assumptions101Split this into two parts:102103### Known Information104Only summarize information I explicitly provided105106### Assumptions107List the reasonable assumptions you adopted in order to complete the solution108109Requirements:110- Known information and assumptions must be strictly separated111- Do not mix them together112113---114115## 3. Template System Design Principles116Clearly define the design principles of this system and explain why each principle matters.117118At minimum, cover:119- Unified structure principle120- Configurability principle121- Extensibility principle122- Brand decoupling principle123- Frontend-backend separation principle124- Maintenance cost control principle125- Consistent user experience principle126127---128129## 4. Frontend Architecture Design130You must cover the following:131132### 4.1 Page Hierarchy133For example:134- Home135- About136- Products / Services137- Contact138- Blog / News139- FAQ140- Careers / Team141- Custom extension pages142143### 4.2 Component Modules144Explain which modules should be abstracted into reusable components, such as:145- Header146- Footer147- Banner148- Features149- CTA150- Testimonials151- Forms152- Cards153- FAQ154- Modal / Drawer / Notification155156### 4.3 Configurable Items157Explain which frontend elements should be configurable:158- Logo159- Colors160- Fonts161- Button styles162- Image assets163- Copy/text content164- Page section order165- Module toggles166- Multilingual content167168### 4.4 Responsive Design and Interaction169Explain:170- Mobile-first strategy171- Tablet / desktop adaptation172- Loading states / empty states / error states173- How consistency and maintainability should be handled174175### 4.5 Recommended Frontend Technology Approach176Evaluate which is more suitable:177- HTML/CSS/JavaScript178- React179- Vue180- Next.js181- Other reasonable options182183You must explain the reasoning. Do not give conclusions without justification.184185---186187## 5. Backend Architecture Design188You must cover:189190### 5.1 Backend Responsibilities191For example:192- Configuration loading193- Form handling194- User data195- Content management196- Admin APIs197- Permission control198- Third-party integrations199- Logging and monitoring200201### 5.2 Technology Selection Recommendations202Evaluate:203- Node.js204- Python205- Other possible options206207Explain from these angles:208- Development efficiency209- Maintainability210- Ecosystem maturity211- Reusability for template-based projects212- Collaboration efficiency with the frontend213214### 5.3 API Design Approach215Explain:216- How to abstract common APIs217- How business-specific APIs should be extended218- How to support reuse across multiple projects219- How to avoid uncontrolled coupling over time220221### 5.4 Data and Permission Design222Explain the likely core data objects involved:223- Site configuration224- Page content225- Form data226- Users / administrators227- Module status228- Multi-brand configuration isolation229230---231232## 6. Template Customization Mechanism233This is a key section and must be specific.234235Explain the customization mechanism at the following levels:236237### 6.1 Brand-Level Customization238- Company name239- Logo240- Color palette241- Fonts242- Image style243- Brand tone of voice244245### 6.2 Page-Level Customization246- Number of pages247- Page order248- Page template reuse249- Homepage section composition250- Add/remove content blocks251252### 6.3 Function-Level Customization253- Contact forms254- Product showcase255- Service booking256- Blog257- FAQ258- Admin panel259- Multilingual support260- SEO261- Third-party integrations262263### 6.4 Configuration Method Recommendations264Explain which kinds of content are better stored in:265- Configuration files266- JSON / YAML267- CMS268- Database269- Admin management system270271Also explain the appropriate use case for each.272273---274275## 7. Multi-Industry Adaptation Recommendations276At minimum, analyze these scenarios:277- Technology companies278- Retail companies279- Service businesses280- Web3 / blockchain projects281282For each industry, explain:283- Which structural parts remain unchanged284- Which visual elements need adjustment285- Which functional parts need adjustment286- How to complete the adaptation at the lowest possible cost287288---289290## 8. Engineering Standards and Best Practices291You must cover:292- Directory conventions293- Naming conventions294- Style management conventions295- API conventions296- Configuration management conventions297- Environment variable conventions298- Commenting and documentation conventions299- Frontend-backend collaboration conventions300- Maintainability recommendations301302Write this like real engineering standards, not empty slogans.303304---305306## 9. Recommended Directory Structure307Provide a suggested directory structure, including at least:308- frontend309- backend310- config311- assets312- shared313- docs314315Also explain the responsibility of each layer.316317---318319## 10. MVP Development Priorities320Break this into phases:321322### Phase 1: Minimum viable skeleton323### Phase 2: Enhanced experience and extensibility324### Phase 3: Advanced capabilities and long-term evolution325326For each phase, explain:327- Why these items should be done first328- What problem they solve329- What value they bring to template reuse330331---332333## 11. Risks and Boundaries334Clearly point out the main risks of this approach, such as:335- Over-generalization of the template leading to weak brand identity336- Excessive configurability increasing system complexity337- Overweight backend design making the MVP too expensive338- Large industry differences reducing template adaptation efficiency339340Also provide corresponding control recommendations.341342---343344## 12. Final Conclusion345At the end, provide a clear and actionable conclusion, including:346- The most recommended overall approach347- The most recommended frontend-backend technology stack348- The best version to build first349- The future expansion path350- The biggest advantage351- The issue that requires the most caution352353The conclusion must be explicit and executable. Do not be vague.354355---356357# Writing Requirements358Use the following writing style:359- Professional, clear, and direct language360- Keep sentences concise361- Focus on execution, structure, and logic362- Minimize obvious filler363- In each section, prioritize “how to do it” and “why this approach”364- Use fewer adjectives, more judgment and structure365366---367368# Prohibited Issues369The output must not contain the following problems:370- Vague statements such as “improve user experience” or “strengthen brand perception” without explaining how371- Concept-only discussion without structure372- Frontend-only discussion without backend373- Technology-only discussion without reuse logic374- Writing the template system as if it were a dedicated website for one company375- Failing to distinguish between the fixed skeleton and configurable parts376- Writing assumptions as facts377- Repeating earlier content just to increase length378379---380381# Self-Check Before Final Output382Before producing the final answer, check the following internally and only output after all are satisfied:3831. Have you consistently focused on a “template system” rather than a “single-site design”?3842. Have you covered product, visual, engineering, and business reuse layers together?3853. Have you clearly separated “Known Information” and “Assumptions”?3864. Have you clearly separated the “fixed skeleton” and the “configurable parts”?3875. Have you provided sufficiently specific frontend, backend, and configuration mechanisms?3886. Have you avoided filler, empty wording, and repetition?3897. Is the conclusion clear and actionable?