zhuyongxin
a74ccea5be
- DocumentChunk新增breadcrumb字段，分块时构建完整标题层级路径 - DocumentChunkService splitByHeadings维护标题层级栈算法 - VectorIndexService 将breadcrumb写入Milvus metadata - LookupKnowledgeTool日志替换为结构化摘要，替代原始MD预览 - L0返回策略：唯一匹配用正文摘要，多匹配+L1有结果仅元数据（不读文件） - 新增buildCompactSummary / buildMetadataOnlySummary方法 - 安装frontend-design skill - 创建mvp/文档目录（架构设计+会话存储方案） - 更新测试适配新逻辑
58 lines
4.2 KiB
Markdown
58 lines
4.2 KiB
Markdown
# Frontend Design — Complete Guidance
|
||
|
||
This document provides a comprehensive framework for creating visually distinctive, non-templated UI designs. Here's the full breakdown:
|
||
|
||
## Foundational Approach
|
||
|
||
Act as the design lead for a studio known for unique client identities — the client has already turned down template-like proposals. Every choice about palette, typography, and layout must be specific to the brief, including "one real aesthetic risk you can justify."
|
||
|
||
## Grounding in Subject Matter
|
||
|
||
If the brief is vague about the product or subject, pin it down yourself: name the subject, its audience, and the page's single job. Draw inspiration from "the subject's own world, its materials, instruments, artifacts, and vernacular." Use any known context about the human's preferences or past designs as hints.
|
||
|
||
## Design Principles
|
||
|
||
- **Hero as thesis**: Open with "the most characteristic thing in the subject's world" — avoid default choices like a big number with a small label and gradient accent unless truly optimal.
|
||
- **Typography**: Pair display and body faces deliberately, not from your usual repertoire. Set a clear type scale with intentional weights, widths, and spacing. "Make the type treatment itself a memorable part of the design."
|
||
- **Structure as information**: Numbering, eyebrows, dividers must encode something true about the content. Question whether numbered markers (01/02/03) actually make sense before using them — only appropriate for real sequences.
|
||
- **Motion**: Consider where animation serves the subject. "An orchestrated moment usually lands harder than scattered effects." Sometimes less is better to avoid an AI-generated feel.
|
||
- **Complexity**: Match execution to the vision — maximalist needs elaborate execution, minimal needs precision.
|
||
- **Content**: Come up with copy if the brief lacks it. Poor copy makes a design feel as templated as poor layout.
|
||
|
||
## AI-Generated Design Traps
|
||
|
||
Three common AI-default looks to watch for: (1) warm cream background (~#F4F1EA) with serif display and terracotta accent; (2) near-black with bright acid-green or vermilion; (3) broadsheet layout with hairline rules, zero border-radius, and dense columns. "All three are legitimate for some briefs, but they are defaults rather than choices." Where the brief leaves an axis free, don't spend that freedom on a default.
|
||
|
||
## Two-Pass Process
|
||
|
||
**Pass 1 — Plan**: Create a compact token system:
|
||
|
||
1. **Color**: 4–6 named hex values
|
||
2. **Type**: Characterful display face (used with restraint), complementary body face, utility face for captions/data
|
||
3. **Layout**: One-sentence prose descriptions + ASCII wireframes
|
||
4. **Signature**: The single unique element the page will be remembered by
|
||
|
||
Review the plan against the brief. If any part reads like what you'd produce for any similar page, revise it. Only then write code.
|
||
|
||
**Pass 2 — Build**: Follow the revised plan exactly. Watch for CSS selector specificity conflicts (e.g., `.section` and `.cta` fighting over padding/margins). Do most planning internally, only sharing ideas when confident.
|
||
|
||
## Restraint & Self-Critique
|
||
|
||
"Spend your boldness in one place" — let the signature element be the one memorable thing; keep everything else quiet. "Not taking a risk can be a risk itself!" Build responsively down to mobile, with visible keyboard focus and reduced motion respected. Critique as you build. Follow Chanel's advice: before finishing, remove one accessory. Jot notes about what you've tried to avoid repeating yourself.
|
||
|
||
## Writing in Design
|
||
|
||
Words exist to make the design understandable and usable — they're "design material, not decoration." Write from the end user's perspective, naming things by what people control and recognize, never by how the system is built.
|
||
|
||
- Use active voice as default
|
||
- A control should say exactly what happens: "Save changes," not "Submit"
|
||
- Maintain consistent vocabulary throughout flows (button says "Publish," toast says "Published")
|
||
- Treat errors as guidance, not mood — explain what went wrong and how to fix it
|
||
- Empty screens are invitations to act
|
||
- Keep the register conversational: "plain verbs, sentence case, no filler"
|
||
- Let each element do exactly one job — "a label labels, an example demonstrates"
|
||
|
||
## License
|
||
|
||
Apache License 2.0 — see LICENSE.txt
|