avatar

Ebit

第一个是友链

全部文章总字数：447.8k


⣿⣿⣿⣿⣿⣿⡿⢛⠝⣠⡾⠋⠁⢀⣴⡶⣎⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⣶⣮⣭⣙⡻⠿⠋⣠⡞⠟⠃⠀⢀⡌⠻⢿⣿⣿
⣿⣿⣿⣿⣿⡿⠁⢀⣼⠟⠀⠀⣀⣽⣿⣶⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡍⢀⣴⡏⠁⠀⠀⢠⣿⣿⣷⣦⡹⣿
⣿⣿⣿⣿⣿⢣⣄⠈⠁⠀⣠⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡏⠀⠾⠏⡇⠀⡄⣠⡿⣿⣿⣿⣿⣿⣾
⣿⣿⣿⣿⣏⣿⣿⡦⢀⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡄⠀⠀⠀⠀⠐⢿⣿⡼⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⡟⣱⣿⣿⣿⣿⣿⣿⠃⣿⡿⣿⣿⣿⣿⣿⡟⠈⢿⣿⣿⣿⣿⢿⣻⣿⣿⣿⣿⡄⠀⠀⠀⠘⣮⣿⠝⢻⣿⣿⣿⣿
⣿⣿⣿⣿⣿⢏⣼⡿⣻⣿⣿⣿⣿⠃⢀⢹⡇⣿⣿⣿⣿⣿⣷⠀⡈⢻⣿⣿⣿⣎⢿⣏⢿⣿⣿⣷⡀⠀⠀⠀⠘⣿⡇⠘⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣞⡝⣴⣿⣿⣿⣿⠃⢠⣿⠸⡇⢹⣿⣿⣿⢻⣿⡀⣿⡌⢻⣿⣿⣿⡌⣿⡌⣿⣿⣿⣷⠀⠀⠀⠀⠈⠧⢠⣿⣿⣿⣿
⣿⣿⣿⣿⣿⡿⣸⣿⣿⣿⣿⠇⢀⡛⣛⣇⢇⠈⣿⣿⣿⡎⣿⠁⢛⣛⡀⢛⡿⢿⣿⡘⣧⢹⣿⣿⣿⡇⢠⣄⡀⣠⠀⠈⢻⣿⣿⣿
⣿⣿⣿⣿⣿⢡⣿⣿⣿⣿⡏⢀⡟⣸⣿⣿⡌⠀⡸⣿⣿⣷⢸⠀⢸⣿⣿⣄⠻⣿⣿⣧⢹⢸⣿⣿⣿⣿⠸⡿⢰⣿⠀⢀⠻⣿⣿⣿
⣿⣿⣿⣿⡏⣾⣿⣿⣿⣿⠀⣾⠻⠿⠿⢿⣷⡀⢣⢻⣿⣿⡆⠀⢸⣯⡻⠿⣧⡘⢿⣿⣆⠀⣿⣿⣿⣿⡇⠀⠈⠉⠀⢸⡆⢸⣿⣿
⣿⣿⣿⣿⣁⣿⣿⣿⣿⡇⠘⠁⣠⡶⠂⠀⠙⣷⡈⢧⠹⣿⣇⢠⠈⠉⣠⣤⡄⠈⠙⠿⣿⡄⣿⣿⣿⣿⡇⠰⠖⠃⠀⢸⣷⠈⣿⣿
⣿⣿⣿⣼⣿⣿⣿⣿⣿⠀⢀⣾⣿⠟⠁⠀⠀⣿⣷⡀⣅⢹⣿⠘⡇⣿⣿⡿⠆⠀⠀⠀⠈⠃⠛⣿⣿⣿⡇⠀⠀⠀⠀⣿⣿⠀⣿⣿
⣿⣿⠟⣻⠿⣿⣿⣿⡟⠀⢸⣿⣿⡄⡄⠠⡀⣿⣿⣷⣜⣷⣬⣁⣿⣿⣿⠀⠀⡀⠀⠀⣧⢸⢡⣿⣿⡟⠁⠀⠀⠀⢰⣿⣿⡆⣿⣿
⣿⣿⣤⣿⠀⣿⣿⣿⡇⠀⠀⢿⣿⣷⣼⣯⣴⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣇⠻⠯⠟⣰⡟⠀⣾⣿⣿⡇⠀⠀⠀⠀⣿⣿⣿⡇⣿⣿
⣿⣿⣿⣿⡆⢹⣏⢿⡇⢠⣖⠈⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠃⣼⣿⣿⣿⡇⠀⠀⠀⣠⣿⣿⣿⣧⣿⣿
⣿⣿⣿⣿⡱⠀⢿⡎⡡⠾⠿⢀⢻⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⣡⢰⢃⣿⣿⣿⠁⠀⣴⣾⣿⣿⣿⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣷⣀⣄⢸⣿⣿⣭⣝⡊⢻⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡏⠂⣾⣿⣿⡟⢀⡆⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⢿⣿⣿⣿⣿⣿⣿⢠⠙⢿⣿⣿⣿⣷⣬⡻⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠿⠋⡀⢸⣿⣿⢻⠇⠸⠃⠿⠿⠿⣿⣿⣿⣿⣿⣿
⢿⣿⣿⣿⣿⣿⡏⣸⠀⡇⠙⢿⣿⣿⣿⣿⣷⣍⠻⢿⣿⣿⣿⣿⣿⠿⢛⣭⡶⢋⣼⠇⣿⣿⡏⠀⠀⠀⣼⢛⣵⣾⣶⣮⡻⣿⣿⣿
⢸⣿⣿⣿⣿⣿⡇⣿⠀⠁⠀⡀⣍⠻⣿⣿⣿⣿⣧⣠⠙⠛⠋⢭⣶⡿⢟⣩⣶⣿⠟⣼⣿⠟⠀⠀⢀⣾⣵⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⡇⣿⠀⣤⡀⣷⡝⣰⣿⣿⣿⣿⣿⠏⠰⠿⠀⣨⣵⣾⣿⣿⠟⠁⣼⡿⢋⣀⣤⠀⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⡇⡿⣸⣿⣷⡟⣼⣿⣿⣿⣿⣿⡏⣠⣾⣿⡆⡸⣿⠿⣋⣵⢎⣚⣫⣴⣿⣿⡏⣼⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⡇⢠⣿⡿⢋⣾⣿⣿⣿⣿⣿⡟⢠⣿⣿⠏⡀⢧⠁⢺⣿⣿⣿⣿⡿⣻⣿⡟⣰⡿⠻⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⡇⣿⠏⠀⣿⣿⣿⣿⣿⣿⡟⠀⣼⡿⢁⢸⣧⣄⢀⡈⢿⣿⣿⣭⣾⣿⡟⣰⡿⣰⠇⣼⡄⣰⣿⣿⣿⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⠘⠁⠆⠀⣿⣿⣿⣿⣿⡟⣰⡶⣿⢡⠏⢸⣿⠋⠚⣡⡈⣿⣿⣿⣿⠟⣱⣿⣇⠉⣴⠟⢠⣿⣿⣿⣿⣿⣿⣿⣿⣿

2026-02-03T00:00:00.000Z

0. 核心哲学与目标 (Core Philosophy)

  • 核心理念：
    1. 数学前置：业务逻辑抽象（数学建模）先于代码实现。
    2. 透明化风险：不回避合规、网络、运维坑，将其作为教学内容。
    3. AI 协作：拥抱大模型辅助文档与代码，但强调人工审查（Review）。
    4. 工程闭环：从环境配置到上线维护的全流程体验。
    5. 代码整洁 (Clean Code)：代码是写给人看的，其次才是机器。
    6. 保持底熵 (Low Entropy)：主动对抗系统复杂度增长，定期重构，避免技术债堆积。
  • 最终产出：一个可访问的个人博客（静态部署 + 第三方评论），包含完整的文档、代码仓库及运维配置。
  • 周期：预计 1 周集中教学 + 后续持续维护。

1. 环境篇 (Environment)

1.1 操作系统

  • 选择：Arch Linux (物理机安装)。
  • 理由：理解系统层级，锻炼排错能力，运维基础。
  • 教学要点：
    • 手把手带安装，但要求新人理解每一步含义。
    • 风险控制：准备 LiveUSB 救援方案，防止引导损坏导致教学中断。
    • 硬件兼容：注意显卡驱动（尤其是 NVIDIA）和 Wi-Fi 驱动预处理。

1.2 桌面环境

  • 方案：Hyprland (Wayland) + Quickshell + Noctalia Shell。
  • 配置策略：
    • 提供基准配置文件（Dotfiles），注释详尽。
    • 关键配置项：
      • 显示器：monitor = eDP-1,1920x1080@60,0x0,1 (需教新人用 hyprctl monitors 修改)。
      • 键位：Super 键为核心，涵盖窗口管理、工作区、音量、截图 (grim+slurp+swappy)。
      • 剪贴板：wl-paste --watch cliphist store + wofi 调用。
    • 自定义边界：鼓励修改浏览器、编辑器快捷键，但核心窗口管理逻辑保持一致。
  • 工具链：
    • 终端：Kitty (GPU 加速) + Fish (交互式 Shell)。
    • 编辑器：VS Code 或 Zed (根据新人偏好，但需配置统一 Lint 规则)。
    • 浏览器：自选 (Chrome/Firefox)，要求自行配置 Wayland 参数 (Ozone) 以优化帧率。

1.3 网络代理 (Mihomo)

  • 必要性：保障开发资源（npm, GitHub, Docker）访问稳定性。
  • 配置：
    • 安装：yay -S mihomo。
    • 服务：systemctl --user enable --now mihomo.service。
    • 环境变量：Fish 中设置 https_proxy，注意 no_proxy 排除本地请求。
    • 合规教学：明确仅用于开发资源访问，讲解封禁风险与备用方案。

1.4 环境管理

  • Dotfiles 仓库：
    • 第一天即建立私有 Git 仓库管理配置文件。
    • 每次修改配置必须 Commit，作为 Git 教学的第一次实践。
    • Review 点：配置注释是否清晰，是否包含“陷阱说明”。

2. 规范篇 (Standards)

2.1 版本控制 (Git)

  • 入门：使用网页游戏 (如 Learn Git Branching) 快速理解概念 (1 小时内)。
  • 实战：
    • 结合真实命令教学 (add, commit, push, merge, rebase)。
    • 重点：分支管理策略 (Feature Branch)，冲突解决流程。
    • 经验传递：结合真实工作经验说明 Commit 信息规范的重要性。
  • 工具：命令行优先，可选图形化辅助。

2.2 工程结构

  • 架构：分层架构 (Layered Architecture) 起步。
    • src/types: 数学模型 (TypeScript 接口)。
    • src/components: 通用 UI 组件。
    • src/views: 页面视图。
    • src/utils: 纯工具函数 (数学逻辑)。
  • 脚手架：
    • 选型：Vite + Vue 3 + TypeScript。
    • 理由：轻量、理解构建工具本质、SFC 天然契合分层。
    • 类型共享：前后端共用 types 文件夹，确保契约一致。

2.3 代码规范 (Clean Code)

  • 语言：纯 TypeScript (不跨语言，降低复杂度)。
  • 风格：
    • 命名：变量/函数名必须表意，禁止 a, b, tmp 等无意义命名。
    • 函数：单一职责，长度控制在 50 行以内。
    • 注释：解释“为什么”而不是“做什么”。
    • 格式：强制 Prettier + ESLint，提交前自动修复。
  • 错误处理：必须包含 Loading、Error、Empty 状态。

3. 方法论篇 (Methodologies)

3.1 最小可行产品 (MVP)

  • 定义：用最成本验证核心价值的产品版本。
  • 本教学 MVP 范围：
    • 核心功能：文章列表展示、文章详情渲染、静态评论展示。
    • 排除功能：用户注册登录、后台管理系统、数据库写入、复杂搜索算法。
    • 实现策略：
      • 内容即代码 (Content as Code)：Markdown 文件即数据库。
      • 评论即服务 (Comments as Service)：Utterances 替代自建评论系统。
  • 教学目标：学会砍需求。当新人想加“暗黑模式”或“搜索”时，要求他们先问：“没有这个功能，MVP 能跑吗？”

3.2 文档与规范驱动开发 (Doc & Spec-Driven Development)

  • 核心理念：代码是文档的执行产物，规范是开发的约束边界。引入 SDD (Specification-Driven Development) 与 AI + Human-in-the-Loop (HITL) 工作流。
  • 开发流程：数学/规范模型 (SDD) -> 设计文档 -> AI 辅助生成 -> 人工审查 (HITL) -> 代码实现。

3.2.1 规范驱动开发 (SDD - Specification-Driven)

  • 定义：在编写业务逻辑前，先定义不可变的规范（Types, APIs, States）。代码必须严格遵循规范，编译错误即视为规范冲突。
  • 数学模型 (Math Model)：
    • 工具：Markdown + Mermaid + TypeScript Interfaces。
    • 内容：
      • 数据结构：定义字段类型、约束条件（如 length > 0）。
      • 状态流转：使用状态机图描述业务生命周期（如 Draft -> Published -> Archived）。
      • 交互约束：定义集合基数、互斥性等技术边界（见设计资源篇）。
    • SDD 实践：types/ 目录下的接口定义视为"单一事实来源" (Single Source of Truth)，前后端共用，禁止私自绕过类型系统。
  • 设计文档 (Design Doc)：
    • 工具：手绘草图 + Figma + 标注。
    • 内容：布局分镜、组件选型理由（受数学约束）、配色方案、动效曲线。
    • 关联：设计稿中的每个组件必须能追溯到数学模型中的数据来源。

3.2.2 AI 与人工协同 (Human-in-the-Loop)

  • 工作流定位：AI 是"初级工程师"，负责生成草案；人是"架构师/审查者"，负责决策与负责。
  • HITL 流程：
    1. Prompt 输入：人提供数学模型 + 设计文档 + 上下文约束。
    2. AI 生成：AI 产出代码草案、单元测试、文档初稿。
    3. 人工审查 (Human Review)：
      • 逻辑验证：代码是否严格遵循数学模型？
      • 安全检查：是否有潜在漏洞（XSS、硬编码密钥）？
      • 合规确认：是否符合法律法规与开源协议？
      • 熵值评估：代码是否引入了不必要的复杂度？
    4. 合并与迭代：审查通过后合并，否则退回 AI 修正并记录错误模式。
  • 禁止行为：
    • 禁止直接复制粘贴未理解的 AI 代码。
    • 禁止让 AI 决定架构选型或业务逻辑边界。
    • 禁止将敏感信息（密钥、用户数据）输入公共 AI 模型。

3.2.3 审查标准 (Review Standards)

  • 文档一致性：代码实现必须与数学模型/设计文档一致，若不一致，优先修改代码，其次才更新文档（确保文档滞后性最小化）。
  • 可解释性：新人必须能口头解释每一段 AI 生成代码的逻辑，否则视为未通过。
  • 类型安全：TypeScript 严禁使用 any，所有数据类型必须在 types/ 中有定义。
  • 测试覆盖：核心逻辑必须有测试用例，且测试用例本身也需经过 AI 生成 + 人工审查。

3.2.4 工具链支持

用途 工具 说明
规范定义 TypeScript + Zod 运行时与编译时双重类型校验
API 规范 OpenAPI / Swagger 前后端契约文档，支持 AI 读取生成代码
绘图建模 Mermaid + Excalidraw 版本可控的图表工具
AI 协作 GitHub Copilot / Cursor 嵌入编辑器的 AI 助手，需配置 Review 规则
文档站点 VitePress / Docusaurus 将文档作为网站的一部分共同维护

3.3 测试驱动与持续集成 (TDD & CI/CD)

  • 核心理念：测试不仅是找 Bug，更是可执行的需求文档。CI/CD 是自动化的信任机制，确保“底熵”状态不被破坏。
  • 工作流：红 (写失败测试) -> 绿 (写最小代码) -> 重构 (保持整洁) -> 提交 (触发 CI)。

3.3.1 测试层次金字塔 (Testing Pyramid)

层次 类型 工具 测试对象 教学目的
L1: 静态检查 Type Check vue-tsc 类型定义 (types/) 第一道防线。确保“数学模型”未被违背，编译失败即测试失败。
L2: 单元测试 Unit Test Vitest 纯函数、Composables、工具类 验证“数学逻辑”正确性（如计算公式、状态流转）。要求覆盖核心算法。
L3: 集成测试 Integration Vitest + @vue/test-utils 组件交互、API 调用 验证模块间协作（如“搜索框”是否正确触发了“数据过滤”逻辑）。
L4: 端到端测试 E2E Playwright 完整用户流程 模拟真实用户行为（如“打开首页->点击文章->查看评论”）。确保部署后流程可用。
L5: 视觉回归 Visual (可选) Playwright 截图对比 UI 渲染结果 防止样式意外变更。适合“艺术设计”环节的验收。
  • 执行策略：
    • L1/L2：本地每次保存/提交前强制运行。
    • L3：本地运行，PR 前必须通过。
    • L4：CI 流水线运行，部署前必须通过。
    • 覆盖率要求：核心逻辑 > 80%，UI 组件 > 50%（不追求 100%，避免测试熵增）。

3.3.2 持续集成/持续部署 (CI/CD)

  • 平台：GitHub Actions (CI) + Vercel (CD)。
  • 流水线设计 (Pipeline)： 
    # .github/workflows/ci.yml 简化逻辑
on: [push, pull_request]
jobs:
  quality-gates:
    steps:
      - lint:        # 代码风格检查 (ESLint)
      - type-check:  # 类型检查 (vue-tsc)
      - test-unit:   # 单元测试 (Vitest)
      - test-e2e:    # 端到端测试 (Playwright)
      - build:       # 构建验证 (pnpm build)
  deploy:
    needs: quality-gates
    steps:
      - vercel:      # 仅当上述全部通过才部署
  • 质量门禁 (Quality Gates)：
    • 禁止绕过：CI 失败禁止合并 PR，禁止强制推送部署。
    • 快速反馈：CI 流程需优化速度（缓存依赖、并行任务），确保反馈时间在 5 分钟内。
    • 失败处理：CI 失败必须立即修复，禁止“先合并再修测试”（防止技术债堆积）。

3.3.3 AI 与人工协同 (AI + HITL in Testing)

  • AI 角色：测试代码生成器、边界条件建议者。
  • HITL 流程：
    1. AI 生成：根据业务代码生成测试用例草案。
    2. 人工审查：
      • 边界检查：AI 是否遗漏了极端情况（如空数组、网络超时）？
      • 逻辑验证：测试断言是否符合“数学模型”预期？
      • 脆弱性：测试是否过于依赖实现细节（易碎测试）？
    3. 维护：业务逻辑变更时，优先更新测试，再更新代码。
  • 禁止行为：
    • 禁止提交未通过本地测试的代码。
    • 禁止为了通过测试而修改业务逻辑（除非逻辑本身错误）。
    • 禁止忽略 CI 报错（“红构建”是最高优先级问题）。

3.3.4 熵控与维护 (Entropy Control)

  • 测试代码也是代码：测试文件需遵循 Clean Code 规范（命名清晰、无重复）。
  • 消除脆弱测试：若测试频繁因非逻辑原因失败（如网络波动、时序问题），必须重构测试而非忽略。
  • 定期清理：删除已失效的测试用例，避免“测试僵尸”误导新人。
  • 文档联动：测试用例失败信息应能追溯到需求文档或数学模型。

3.3.5 关键命令与配置

命令 说明
pnpm run test 运行单元测试（监听模式）
pnpm run test:e2e 运行端到端测试
pnpm run test:coverage 生成覆盖率报告
gh run watch 命令行查看 GitHub Actions 运行状态
vercel env pull 同步本地与生产环境变量，确保测试环境一致
  • 教学检查点：
    • 新人能否解释每个测试用例的目的？
    • CI 流水线是否稳定（无随机失败）？
    • 测试是否真正覆盖了“数学模型”中的核心逻辑？

3.4 保持底熵 (Low Entropy)

  • 定义：主动对抗软件系统的自然混乱倾向，防止技术债堆积。
  • 实践策略：
    1. routine规则：离开代码时，让它比你来的时候更干净（随手重构）。
    2. 依赖最小化：能不装库就不装，能用原生 API 就用原生。
    3. 状态收敛：避免全局状态污染，数据流向必须清晰。
    4. 定期重构：每个里程碑结束后，预留 20% 时间专门用于重构代码，不新增功能。
  • Review 标准：代码复杂度（Cyclomatic Complexity）不得超标，重复代码必须提取。

4. 流程篇：3D 闭环 (Design-Develop-Deploy)

4.1 Design (设计)

  • 核心目标：将数学模型（逻辑约束）翻译为视觉语言（艺术表达），确保设计既美观又符合技术边界。
  • 设计原则：
    1. 约束优先：UI 组件选型必须满足数学模型中的交互约束（如集合基数、状态互斥）。
    2. 低熵美学：避免过度设计，视觉复杂度应与信息复杂度匹配。
    3. 电影分镜：用叙事性草图描述用户旅程，而非静态页面堆砌。

4.1.1 从数学模型到设计约束 (Math to Constraints)

  • 输入：第 3.2 节产出的《数学模型文档》（含数据结构、状态机、交互约束）。
  • 转换逻辑：
    数学模型特征 设计约束推导 组件选型参考 (附录 7.3)
    集合基数 N ≤ 5 可平铺展示，无需收敛 单选框组 (Radio Group) / 标签云
    集合基数 N > 50 必须提供搜索/分页/虚拟滚动 搜索框 + 下拉 (Select) / 无限列表
    状态互斥 (XOR) 同一时刻只能激活一个 开关 (Switch) / 单选中 (Active State)
    树形拓扑 需支持层级展开/收起 树形控件 (Tree) / 手风琴 (Accordion)
    耗时操作 (>1s) 必须提供加载反馈 骨架屏 (Skeleton) / 进度条 (Progress)
  • 执行动作：在设计稿旁注中标注每个组件对应的数据字段和约束理由（如：“此处用下拉框，因为选项 N=20"）。

4.1.2 视觉探索与情绪板 (Visual Exploration)

  • 输入：设计约束 + 品牌调性（如有）。
  • 资源利用 (附录 7.1 & 7.4)：
    1. 灵感收集：浏览 Awwwards / SiteInspire，收集 3-5 个符合约束的参考案例。
    2. 情绪板 (Mood Board)：使用 Pinterest 建立看板，归类配色、排版、动效风格。
    3. 配色方案：使用 Coolors 生成配色，并用 Contrast Checker 验证可访问性（WCAG AA）。
    4. 排版系统：使用 Type Scale 计算字号比例，确保层级清晰。
  • AI 协作：让 AI 根据情绪板生成配色建议或字体组合，但人工必须验证对比度。

4.1.3 电影分镜草图 (Storyboarding)

  • 工具：纸笔 / Excalidraw / iPad。
  • 方法：
    1. 场景定义：定义用户目标（如“找到一篇关于 Arch 的文章”）。
    2. 关键帧绘制：画出关键交互节点（首页 -> 搜索 -> 列表 -> 详情 -> 评论）。
    3. 状态标注：在每个帧旁标注数学状态（如：加载中 / 空数据 / 错误 / 成功）。
    4. 动效脚本：标注转场逻辑（如“点击后卡片展开”，参考 GSAP 时间轴）。
  • 目的：在不写代码的情况下，验证用户流程是否通顺，逻辑是否闭环。

4.1.4 组件映射与规范 (Component Mapping)

  • 资源利用 (附录 7.3)：
    • 首选：Shadcn/ui 或 Radix UI（逻辑与样式分离，契合数学约束）。
    • 备选：Naive UI（Vue 生态完整，快速原型）。
  • 执行动作：
    1. 选型：根据 4.1.1 的约束，从组件库中挑选符合要求的组件。
    2. 定制：基于 4.1.2 的配色方案，修改组件 Token（颜色、圆角、间距）。
    3. 动效集成：引入 VueUse Motion 或 GSAP，为关键交互添加微动效（参考附录 7.2）。
  • 规范输出：形成《设计规范文档》，包含颜色变量、字号表、组件使用场景。

4.1.5 设计审查 (Design Review)

  • 审查清单 (附录 8)：
    • 数学一致性：组件选型是否违背了交互约束？（如 N=100 却用了单选框组）
    • 视觉层级：是否使用了统一的排版比例（Type Scale）？
    • 状态完整性：是否设计了 Loading/Error/Empty 状态？
    • 合规性：配色对比度是否达标？字体是否有授权？
  • AI + HITL：
    • AI 初审：检查对比度、标注完整性。
    • 人工终审：评估美学质量、用户体验流畅度。
  • 交付物：
    1. 手绘分镜稿（含状态标注）。
    2. 高保真设计图（Figma 或等效工具）。
    3. 设计规范文档（含配色、字体、组件映射表）。

4.1.6 熵控提示 (Entropy Control)

  • 避免过度设计：若数学模型简单（如博客文章），不要强行套用复杂动效（如 WebGL 背景）。
  • 避免重复造轮子：优先使用成熟组件库（Shadcn），除非现有组件无法满足数学约束。
  • 文档同步：设计变更后，必须反向检查数学模型是否需要调整（双向验证）。

4.2 Develop (开发)

  • 栈：Vue 3 + Vite + TS。
  • 优先级：读 > 写。先跑通内容渲染，再考虑交互。
  • 功能：本地 Markdown 写作，Git 提交触发构建；评论用 Utterances (GitHub Issues)。

4.3 工程结构 (Engineering Structure)

架构原则

  • 分层架构 (Layered Architecture) 起步，后期可过渡领域架构。
  • 核心思想：逻辑与视图分离，数据与样式解耦，保持底熵。
  • 技术选型：Vite + Vue 3 + TypeScript (本教学方案默认)。
  • 可行性说明：React 同样可行，且是业界主流。选择 Vue 是基于教学目标与项目类型的权衡，而非技术优劣的绝对判断。

多维度对比分析 (Vue 3 vs. React)

维度 Vue 3 (SFC) React (JSX + Hooks) 分析与权衡
开发体验 模板语法，HTML/CSS/JS 物理分离，心智模型清晰。 JSX 语法，"All in JS"，逻辑与视图混合编写，灵活性极高。 React 要求更强的 JS 函数式编程能力；Vue 对新人更友好，降低认知负荷。
逻辑与 UI 物理分离 (<script> vs <template>)。优点是边界清晰，缺点是可能割裂关联逻辑。 逻辑共置 (Logic co-location)。Hook 与 UI 写在一起，优点是封装性强，修改时不易遗漏。 React 的"关注点分离"是逻辑层面的，Vue 是文件层面的。React 更适合复杂交互组件，Vue 更适合内容展示型页面。
样式管理 原生支持 (<style scoped>)，简单直接。 生态多样 (CSS Modules, Tailwind, CSS-in-JS)。需自行选型，灵活但易增加熵。 React 的 CSS 分离方案更成熟（如 Tailwind），但选型决策成本高。Vue 默认方案足够教学使用。
维护性 结构固定，新人代码风格差异小，易读。 风格自由，依赖团队规范。若规范不严，易出现"组件臃肿"。 教学场景下，Vue 的 Opinionated 特性有助于强制 Clean Code，减少风格争执。
可拓展性 官方全家桶 (Router/Pinia)，路径明确。 社区生态 (Next.js/Remix/Zustand)，选择多，适合定制架构。 大型复杂应用 React 生态更丰富；中小型项目 Vue 开发效率更高。
性能表现 编译时优化 为主，默认性能好，新人不易写崩。 运行时优化 为主，需手动优化 (memo/useCallback)，上限高下限低。 本教学项目为博客，性能瓶颈不在框架，Vue 的默认优化更省力。
业务场景 内容展示型 (官网、博客、电商前台)。 交互复杂型 (SaaS、Dashboard、在线协作工具)。 博客属于内容展示，Vue 性价比更高。若未来做复杂 SaaS，React 更合适。

典型工程结构对比

Vue 3 结构 (物理分离)

src/
├── components/
│   ├── PostCard.vue      # 模板、逻辑、样式在同一文件
│   └── PostCard.css      # 或写在 <style> 标签内
├── composables/
│   └── usePost.ts        # 纯逻辑提取

好处：新人一眼看出哪里是结构，哪里是逻辑，契合"数学 + 艺术"分步教学。 坏处：复杂组件可能导致文件过长，需手动提取 Composables。

React 结构 (逻辑共置 + 样式分离)

src/
├── components/
│   ├── PostCard.tsx      # 逻辑 (Hooks) 与 视图 (JSX) 混合
│   ├── PostCard.module.css # 样式独立文件
│   └── usePost.ts        # 逻辑提取 (Hooks)

好处：组件封装性极强，修改功能时只需关注一个组件文件夹，逻辑不易泄露到外部。 坏处：JSX 中混合逻辑判断，新人易写出"逻辑污染视图"的代码，增加 熵值。

如何选择 (Decision Framework)

场景 推荐选型 理由
新人教学 / 快速原型 Vue 3 降低认知负荷，强制结构规范，减少决策熵增。
复杂交互 / SaaS 应用 React 灵活性高，生态丰富，逻辑共置利于复杂状态管理。
跨平台需求 (Mobile) React React Native 生态成熟，代码复用率高。
内容驱动 / SEO 敏感 两者皆可 Vue (Nuxt) 与 React (Next) 均有成熟 SSR 方案。
团队 JS 能力强 React 能驾驭 JSX 灵活性，享受函数式编程红利。
团队背景多元 Vue 3 模板语法对后端/设计背景成员更友好。

本教学方案决策理由

  1. 契合核心理念：Vue 的 <script> / <template> 物理分离，天然契合 "数学建模 (Logic)" + "艺术设计 (View)" 的双轨教学流程。
  2. 控制熵增：新人易在 React 的 JSX 中过度混合逻辑，导致代码混乱。Vue 的结构性约束有助于养成 Clean Code 习惯。
  3. 项目匹配：博客属于内容展示型，Vue 的开发效率优势大于 React 的灵活性优势。
  4. 可行性保留：学员掌握 Vue 后，因 TS 和组件化思想通用，转学 React 成本极低。教学中会说明 React 的实现思路，确保视野不局限。

4.3 Deploy (部署)

  • 核心目标：将代码转化为可访问的服务，同时理解基础设施即代码 (IaC) 与 运维合规 的边界。
  • 部署策略：渐进式部署。MVP 阶段追求速度（Vercel），维护阶段追求控制与学习（VPS）。

4.3.1 方案对比：Serverless (Vercel) vs. VPS (自托管)

维度 Vercel / Serverless (当前 MVP 方案) VPS / Self-Hosted (进阶运维方案)
控制权 低。黑盒环境，无法自定义系统层配置。 高。Root 权限，可安装任意软件 (DB, Cache, Daemon)。
运维成本 零。自动 HTTPS、CDN、扩容。 高。需手动配置 Nginx、SSL、备份、安全加固。
学习价值 低。侧重前端交付流程。 高。契合 Arch Linux 教学，锻炼 Linux/Network 能力。
成本结构 用量付费。流量激增时费用不可控。 固定付费。按月付费，流量通常不限或配额高。
合规性 中。海外节点需代理，国内访问不稳定。 灵活。可选海外 VPS+CF 代理，或国内 VPS+ 备案。
锁定风险 高。深度绑定 Vercel 生态 (Functions, Edge)。 低。标准 Docker/Nginx 配置，随时迁移。
适用场景 快速原型、静态博客、前端主导项目。 复杂后端、长期运营项目、运维技能训练。

4.3.2 为什么引入 VPS 方案 (教学价值)

  1. 闭环 Arch 技能：新人刚学过 Arch 安装与配置，VPS 是实践 systemd、Nginx、Docker 的最佳场景。
  2. 理解网络全貌：在 VPS 上配置反向代理、SSL 证书、防火墙，能深入理解 HTTP/TCP 流程，而非仅依赖平台抽象。
  3. 数据主权：数据库和文件完全自控，便于教学“备份与恢复”、“数据安全”等后日谈内容。
  4. 成本意识：让新人理解服务器资源是有限的，需优化代码以减少 CPU/内存占用（契合低熵原则）。

4.3.3 如何选择 (Decision Framework)

决策因素 选择 Vercel 选择 VPS
项目阶段 MVP 验证期 (第 1 周) 稳定运营期 (第 2 周及以后)
技术栈 纯静态 / Serverless 函数 需要长驻进程 (WebSocket, Cron, DB)
教学目标 快速上线，建立信心 深入运维，理解基础设施
合规需求 个人学习，无备案 正式运营，需备案或接受代理风险
预算 免费额度内 每月 $5-$10 固定预算

4.3.4 教学实施路径 (Hybrid Approach)

  • 阶段一：Vercel 快速上线 (MVP)
    • 目的：当天可见成果，验证内容流程。
    • 操作：Git 推送自动部署，配置 Cloudflare 代理域名。
    • 重点：理解 CI/CD 流水线，域名 DNS 解析。
  • 阶段二：VPS 迁移实践 (Ops)
    • 目的：学习 Linux 服务管理，掌握自主控制权。
    • 操作：
      1. 购买：选择海外 VPS (避免备案复杂性，配合 Cloudflare)。
      2. 环境：安装 Docker + Docker Compose (标准化环境)。
      3. 服务：部署 Nginx (反向代理) + Caddy (自动 HTTPS) 或 Coolify (自托管 Vercel 替代)。
      4. 同步：配置 GitHub Actions 自动构建并推送镜像到 VPS。
    • 重点：SSH 密钥管理、防火墙配置 (ufw)、日志查看 (journalctl)。

4.3.5 合规与网络 (Compliance & Network)

  • 国内访问政策：
    • Vercel 直连：不稳定，常被干扰。
    • Cloudflare 代理：隐藏源 IP，加速国内访问，但需注意内容合规（不得涉及敏感内容）。
    • 国内 VPS：必须 ICP 备案，流程漫长，但访问最稳定。教学阶段不建议，以免阻塞进度。
  • 教学底线：
    • 明确告知新人：代理仅用于技术学习，正式商用必须合规备案。
    • 内容审查：部署前检查开源协议、图片版权、文字内容合法性。

4.3.6 关键命令与工具 (VPS 篇)

命令/工具 说明
ssh user@vps-ip 远程登录，配置密钥免密登录
docker compose up -d 容器化部署，保证环境一致性
nginx -t && systemctl reload nginx 配置检查与重载，避免服务中断
certbot --nginx 免费 SSL 证书申请与自动续期
ufw allow 80,443,22 防火墙配置，仅开放必要端口
coolify 自托管 PaaS 平台，降低 VPS 管理难度 (可选)

4.3.7 熵控提示 (Entropy Control)

  • 避免过度运维：教学阶段不要手动配置复杂的高可用集群，单机 Docker 足够。
  • 自动化优先：所有 VPS 配置应脚本化 (Ansible 或 Shell)，禁止手动登录后随意修改配置。
  • 备份策略：必须配置数据库和配置文件的定时备份（如每天凌晨备份到 S3 对象存储）。

5. 维护篇：后日谈 (Maintenance)

  • 核心目标：理解软件上线只是开始，持续迭代与运维监控才是工程常态。培养"所有权意识"——代码上线后仍需负责。
  • 维护周期：上线后第 1 天、第 7 天、第 30 天分别进行不同深度的检查与优化。

5.1 远程运维基础 (SSH & Remote Access)

  • 教学定位：前置技能储备。当前 MVP 使用 Vercel 无需 SSH，但为后续 VPS 迁移和全栈能力做准备。
  • 核心概念：
    • 密钥认证：禁止密码登录，使用 ssh-keygen 生成 Ed25519 密钥对。
    • 配置管理：~/.ssh/config 统一管理多服务器连接信息。
    • 安全传输：理解 SSH 隧道、端口转发、SCP 文件传输。
命令 说明 教学要点
ssh-keygen -t ed25519 -C "email@example.com" 生成密钥对 解释公钥/私钥区别，私钥永不外传
ssh-copy-id user@host 复制公钥到服务器 实现免密登录，理解认证流程
ssh -v user@host 详细模式调试连接 学会排查连接失败原因
scp file.txt user@host:/path 安全文件传输 理解加密传输与 FTP 的区别
ssh -L 8080:localhost:3000 user@host 端口转发 本地访问远程服务，调试利器
ssh -N -f user@host 后台隧道 保持连接但不执行命令

  • 安全最佳实践：

    1. 密钥权限：chmod 600 ~/.ssh/id_ed25519，权限错误会导致 SSH 拒绝使用。
    2. 禁用 Root：VPS 上禁止 Root 直接登录，创建普通用户 + sudo。
    3. 失败保护：配置 Fail2Ban 防止暴力破解。
    4. 密钥备份：私钥需加密备份到安全位置（非 Git 仓库）。

  • 与 Dotfiles 结合：

    • 将 ~/.ssh/config 纳入 Dotfiles 仓库管理（排除私钥）。
    • 使用 Git 钩子检查私钥是否意外提交（.gitignore 强制规则）。

5.2 需求变更与迭代 (Change Management)

  • 实战场景：上线后立即追加需求，测试代码可扩展性。
  • 典型任务：
    1. 主题切换：增加暗黑模式，测试 CSS 变量架构是否合理。
    2. 评论 Fallback：Utterances 加载失败时显示友好提示，测试错误边界处理。
    3. 性能优化：Lighthouse 分数低于 90 时，分析瓶颈并优化（图片压缩、代码分割）。
  • 流程要求：
    • 必须开新分支 (feat/dark-mode)，禁止直接修改主分支。
    • 必须更新数学模型文档（若数据结构变更）。
    • 必须通过 CI 流水线测试。

5.3 监控与日志 (Monitoring & Logging)

  • 前端监控：
    • 错误追踪：配置 Sentry 或类似工具，捕获运行时错误。
    • 性能指标：使用 Vercel Analytics 或 Google Analytics 追踪核心 Web 指标。
  • 后端/系统日志（VPS 场景）：
    • journalctl -u mihomo：查看服务日志。
    • nginx/error.log：分析 HTTP 错误。
    • docker logs <container>：容器化应用日志。
  • 告警策略：
    • 定义什么是"需要立即处理"的错误（如 500 错误、数据库连接失败）。
    • 定义什么是"可延后处理"的警告（如性能下降、非核心功能失败）。

5.4 熵减操作 (Entropy Reduction)

  • 定期重构：每里程碑结束后，预留 20% 时间专门重构，不新增功能。
  • 依赖更新：
    • pnpm update：更新依赖包，检查 Breaking Changes。
    • npm audit：安全漏洞扫描，修复高危漏洞。
  • 代码清理：
    • 删除无用代码（git diff 对比上线前后）。
    • 删除已失效的测试用例。
    • 更新过时的文档注释。
  • 技术债登记：建立 TECH_DEBT.md，记录已知问题与重构计划，避免遗忘。

5.5 备份与恢复 (Backup & Recovery)

  • 数据备份：
    • 配置文件：Dotfiles 仓库即备份。
    • 数据库：VPS 场景下，定时导出 SQL 到对象存储（S3/OSS）。
    • 静态资源：图片/文件同步到备份存储。
  • 恢复演练：
    • 每学期至少进行一次"灾难恢复"练习：假设服务器丢失，能否从备份重建？
    • 记录恢复时间目标 (RTO) 与恢复点目标 (RPO)。

5.6 合规与审计 (Compliance & Audit)

  • 内容审查：
    • 定期检查网站内容是否符合目标地区法规。
    • 检查第三方资源（字体、图标）的开源协议是否变更。
  • 安全审计：
    • 检查 SSH 登录日志 (/var/log/auth.log)，识别异常访问。
    • 更新 SSL 证书（certbot renew 自动续期验证）。
  • 开源协议：
    • 确认项目使用的依赖库协议是否与项目协议兼容。
    • 更新 LICENSE 文件中的年份与作者信息。

5.7 教学检查点 (Instructor Checkpoints)

时间点 检查内容 交付物
上线后 24 小时 网站可访问性、基础功能验证 访问测试报告
上线后 7 天 第一次需求变更完成、CI 流水线稳定 新功能 PR + 测试报告
上线后 30 天 性能优化、依赖更新、技术债清理 重构报告 + Lighthouse 分数
学期末 灾难恢复演练、完整文档归档 备份恢复记录 + 最终文档

5.8 熵控提示 (Entropy Control)

  • 避免过度监控：教学阶段不需要复杂的 APM 系统，基础日志 + 错误追踪足够。
  • 避免盲目更新：依赖更新前先阅读 Changelog，避免引入 Breaking Changes。
  • 文档同步：每次代码变更后，检查文档是否需要更新（防止文档滞后）。
  • 权限最小化：SSH 密钥、API 密钥等敏感信息，遵循最小权限原则分配。

5.9 质量审计工具：Lighthouse

  • 定位：自动化网页质量审计工具，作为**“低熵”与“合规”**的量化标尺。
  • 归属：维护篇 (Maintenance) / 部署篇 (Deploy) 的质量门禁。

5.9.1 是什么 (What)

  • 定义：Google 开源的自动化测试工具，用于审计网页的性能、可访问性、SEO、最佳实践。
  • 输出：0-100 分数报告 + 具体优化建议（如“图片未压缩”、“未使用的 CSS"）。
  • 核心指标 (Core Web Vitals)：
    指标 含义 教学目标
    LCP (最大内容绘制) 加载速度感知 优化首屏资源加载策略
    FID/INP (交互延迟) 响应速度感知 减少主线程阻塞，优化 JS 执行
    CLS (累积布局偏移) 视觉稳定性 避免图片/广告加载导致的页面跳动

5.9.2 为什么 (Why)

  1. 量化“低熵”：性能回归是熵增的表现。Lighthouse 分数下降意味着代码复杂度或资源负载增加，需触发重构。
  2. 合规性检查：Accessibility (可访问性) 分数直接对应“合规篇”中的 WCAG 标准，避免法律风险。
  3. 用户体验底线：分数低于 90 意味着部分用户（低配设备/弱网）体验受损，违背 MVP 价值。
  4. SEO 基础：搜索引擎排名依赖性能指标，影响博客的可发现性。

5.9.3 如何用 (How)

1. 本地开发阶段 (CLI)

  • 安装：pnpm add -D lighthouse
  • 运行： 
    npx lighthouse http://localhost:5173 --output=html --output-path=./report.html
  • 教学要点：
    • 不要盲目追求 100 分，关注红项（Failed Audits）。
    • 学会阅读"Opportunities"建议，理解每项优化背后的原理（如“预加载关键资源”）。

2. 持续集成阶段 (CI/CD)

  • 工具：@lhci/cli (Lighthouse CI)。
  • 配置 (.lighthouserc.yml)： 
    ci:
  assert:
    - preset: "lighthouse:no-pwa" # 非 PWA 项目忽略 PWA 检查
    - assertions:
        categories:performance: ["error", {"minScore": 0.9}]
        categories:accessibility: ["error", {"minScore": 0.9}]
  upload:
    target: temporary-public-storage # 或自建服务器
  • 门禁策略：
    • 性能预算 (Performance Budget)：若分数低于阈值，CI 失败，禁止合并。
    • 回归检测：若分数比上一次提交下降超过 5%，触发警告。

3. 维护阶段 (定期审计)

  • 频率：每次大版本更新前 + 每月一次定期检查。
  • 对比：保存历史报告，对比趋势图，识别性能缓慢衰退（熵增）。

5.9.4 教学审查点 (Review Checklist)

  • 真实性：是否在生产环境构建 (pnpm build) 后测试，而非开发环境？
  • 网络模拟：是否理解 Lighthouse 默认模拟"Slow 4G"，本地快不代表用户快。
  • 可访问性：是否修复了所有"Critical"级别的无障碍错误（如图片缺 alt 标签）？
  • 优化合理性：是否为了提分而过度优化（如移除必要的第三方脚本）？需权衡业务价值。

5.9.5 常见陷阱与熵控

  • 陷阱 1：本地满分，线上不及格。
    • 原因：本地无网络延迟，CDN 未生效。
    • 对策：CI 阶段必须在部署后的真实 URL 上运行。
  • 陷阱 2：过度优化导致代码复杂度上升。
    • 原因：为了减少 0.1 秒 LCP 而引入复杂的预加载逻辑。
    • 对策：遵循80/20 法则，优先解决影响最大的前 3 个问题。
  • 陷阱 3：忽略无障碍 (Accessibility)。
    • 原因：认为“我能看见就行”。
    • 对策：强制 Accessibility 分数纳入 CI 门禁，培养包容性设计意识。

5.9.6 关键命令

命令 说明
npx lighthouse <url> --view 运行并直接在浏览器打开报告
npx lhci autorun 在 CI 环境中自动运行审计
npx lighthouse --list-trace-categories 查看可追踪的性能类别（进阶）
chrome://inspect 远程调试部署后的页面性能（配合 VPS）

6. 附录：关键命令清单 (Command Cheat Sheet)

6.1 系统与环境

命令 说明
pacstrap -K /mnt base linux linux-firmware 系统安装，强调密钥验证
arch-chroot /mnt 救援模式入口
hyprctl monitors 获取显示器参数
systemctl --user enable --now mihomo.service 启动用户级代理服务
export https_proxy=http://127.0.0.1:7890 设置终端代理 (写入 fish config)

6.2 工程与开发

命令 说明
git init -b main 初始化仓库，规范分支名
pnpm create vite@latest blog --template vue-ts 创建脚手架
pnpm run type-check 强制类型检查
pnpm run test --coverage 运行测试并查看覆盖率
pnpm run lint --fix 自动修复代码风格

6.3 部署与合规

命令/操作 说明
vercel --prod 生产环境部署
curl -I https://your-domain.com 检查响应头与 CDN 状态
ping -c 4 your-domain.com 对比国内外解析 IP
git revert <commit-hash> 安全回滚错误提交

6.4 教学辅助

工具 说明
Learn Git Branching Git 入门游戏
Mermaid Live Editor 数学建模绘图
Lighthouse 性能与合规审计

7. 设计资源参考 (Design Resources)

7.1 设计灵感平台

  • Awwwards：学习"获奖级"设计的交互细节。
  • Dribbble：关注组件级设计，区分"概念稿"与"可落地设计"。
  • SiteInspire：按风格/类型筛选，适合快速找参考。
  • Land-book：学习首页布局和信息层级设计。

7.2 动效库与展示

  • GSAP：学习时间轴、缓动、滚动触发动画。
  • VueUse Motion：与本项目技术栈匹配，优先学习。
  • Lottie：学习设计师与开发的动效协作流程。

7.3 UI 组件库参考

  • Shadcn/ui：推荐，代码可复制，理解组件本质。
  • Radix UI：学习"逻辑与样式分离"的最佳实践。
  • Naive UI：Vue 生态完整，可直接参考。

7.4 配色与排版

  • Coolors：配色方案生成。
  • Type Scale：理解排版中的"数学建模"。
  • Contrast Checker：合规必查，确保可访问性达标。

8. 设计 Review 检查清单 (Design Review Checklist)

8.1 视觉层面

  • 配色是否符合对比度标准 (WCAG AA 以上)
  • 字体层级是否清晰 (H1/H2/H3/Body 区分)
  • 间距是否使用统一的比例系统 (如 4/8 网格)

8.2 交互层面

  • 所有可点击元素是否有 hover/active 状态
  • 加载状态是否有明确的视觉反馈
  • 动效是否有明确的目的 (引导/反馈/过渡)，而非装饰

8.3 技术可行性

  • 设计是否受"数学模型"约束 (如集合基数决定组件选型)
  • 动效是否考虑性能影响 (GPU 加速/减少重绘)
  • 是否有暗黑模式的配色方案预留

8.4 合规层面

  • 字体是否有商用授权
  • 颜色是否符合可访问性标准
  • 内容是否符合目标地区法规

9. 设计作业建议 (Design Assignments)

阶段 作业内容 参考资源 交付物
第 1 天 收集 5 个喜欢的博客设计 Awwwards + SiteInspire Pinterest 情绪板
第 2 天 手绘博客首页分镜稿 Land-book + Dribbble 纸质草图 + 标注
第 3 天 确定配色和字体方案 Coolors + Google Fonts 色卡 + 字号比例表
第 4 天 完成高保真设计稿 Figma + Shadcn 参考 Figma 文件/图片
第 5 天 Design Review 修改 检查清单 最终设计文档

10. 教学执行建议 (Instructor Notes)

  1. Just-in-Time 原则：不要试图在第一天前把所有材料准备好。文档也是迭代出来的。
  2. 破坏式教学：故意制造配置错误或 Git 冲突，让他们学会排查和恢复。
  3. 审查重于编写：Code Review 的时间应占开发时间的 30% 以上。重点审查“是否符合数学模型”、“是否增加了熵”、“是否整洁”。
  4. AI 使用规范：允许用 AI 生成代码，但必须能逐行解释。禁止直接复制粘贴未理解的代码。
  5. 合规边界：明确告知开发工具网络策略 ≠ 网站内容合规策略，风险需隔离。

文档版本：v1.0 | 最后更新：2024 | 适用对象：全栈新人

版权所有 © 2026Ebit  |  内容仅供学习与交流  |  Powered by Next.js & TailwindCSS