Auto-sync: 2026-04-22 12:02

wiki/concepts/AGENTS.md.md

@@ -0,0 +1,33 @@
+---
+title: "AGENTS.md"
+type: concept
+tags: [opencode, project-context, agent]
+sources: [如何在ubuntu上安装opencode并配置vibe-kanban]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+**AGENTS.md** 是 OpenCode 为项目自动生成的角色定义文件，位于项目根目录，包含项目结构、编码规范、约定俗成等上下文信息，帮助 AI 理解项目的整体背景。
+
+## Generation
+
+运行 `/init` 命令后，OpenCode 会自动分析项目结构并生成 `AGENTS.md`：
+
+```bash
+cd /path/to/project
+opencode
+/init
+```
+
+## Best Practices
+
+- **纳入版本控制**：OpenCode 官方建议将 AGENTS.md 提交到 Git，以获得一致的跨团队体验
+- **持续维护**：随着项目演进，定期更新 AGENTS.md 以反映最新的架构决策
+- **具体示例**：提供代码示例和模式说明，帮助 AI 生成符合项目风格的代码
+
+## Related Concepts
+
+- [[OpenCode]] — 生成和使用 AGENTS.md 的核心工具
+- [[Plan Mode]] — 利用 AGENTS.md 提供充足上下文以生成精准方案
+- [[Vibe Coding]] — AI 辅助编程的工作流理念

wiki/concepts/AI代理.md

@@ -0,0 +1,45 @@
+---
+title: "AI代理"
+type: concept
+tags: [ai, agent, automation]
+last_updated: 2026-04-22
+---
+
+## Overview
+AI代理（AI Agent）是基于AI模型的自动化任务助手，可以按模式生成代码、规划任务或回答疑问。AI代理具备自主决策和任务执行能力，是Agentic AI系统的核心组件。
+
+## Agent Modes
+### Plan（规划模式）
+- 让AI拆解步骤，形成清晰的开发路线图
+- 适用于需求分析和任务分解
+- 输出通常为Markdown格式的任务列表
+
+### Agent（执行模式）
+- AI代理执行计划任务，逐步生成代码
+- 会直接修改文件
+- 适用于完整的项目构建
+
+### Ask（咨询模式）
+- 仅返回文本答案，不改动代码
+- 安全性最高，适合学习和探索
+- 适用于问答和代码理解
+
+## Key Characteristics
+- **自主性**：能够独立完成复杂任务
+- **多模态**：支持代码生成、文档撰写、任务规划
+- **上下文感知**：理解项目整体结构和上下文
+- **可扩展**：通过MCP等协议集成外部工具
+
+## Applications
+- [[Vibe Coding]]：通过AI代理实现自然语言编程
+- [[Cursor]]：支持多代理并行操作
+- [[Claude Code]]：命令行AI代理工具
+
+## Related Concepts
+- [[Agentic AI]] — 具有自主决策能力的AI系统
+- [[MCP（Model Context Protocol）]] — AI代理的扩展协议
+- [[Plan Mode]] — 规划模式
+- [[Build Mode]] — 执行模式
+
+## Sources
+- [[cursor-2-0初学者使用指南]]

wiki/concepts/Attach容器.md

@@ -0,0 +1,35 @@
+---
+title: "Attach 容器"
+type: concept
+tags: [docker, remote-development, debugging]
+last_updated: 2026-04-22
+---
+
+## Definition
+将 IDE 直接连接到正在运行的 Docker 容器内部进行代码开发和调试的工作模式。
+
+## Mechanism
+1. 在已运行的 Docker 容器中安装 IDE Server 代理
+2. 本地 IDE UI 通过 SSH/TCP 隧道与容器内 IDE Server 通信
+3. 所有代码编辑、终端、插件均运行在容器内部
+4. 容器重启后需重新 Attach
+
+## Characteristics
+- **环境完全隔离**：直接使用容器内的 Python/Node/Go 等语言环境，无需在宿主机安装
+- **适合调试**：数据库、服务等依赖已在容器中运行
+- **适合轻量级修改**：代码变更即时生效（取决于是否使用 Bind Mount）
+- **不适合镜像重建场景**：如需重新 build Dockerfile，需退出 Attach 重建
+
+## vs 宿主机文件模式
+| 维度 | Attach 容器 | 宿主机文件 + Docker CLI |
+|------|-------------|------------------------|
+| 代码位置 | 容器内部 | 宿主机文件系统 |
+| 环境隔离 | ✅ 完全 | ⚠️ 依赖宿主机环境 |
+| 适合场景 | 调试、多语言混合 | docker-compose 编排 |
+| Git 操作 | 需 SSH Agent Forwarding | 直接使用 |
+
+## Connections
+- [[Remote-SSH]] — Attach 的实现基础
+- [[Bind Mount]] — 如需代码实时生效，可结合使用
+- [[Docker]] — 容器平台
+- [[Trae]] — 支持 Attach 容器的 IDE

wiki/concepts/BindMount.md

@@ -0,0 +1,48 @@
+---
+title: "Bind Mount"
+type: concept
+tags: [docker, storage, development]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Bind Mount
+- 绑定挂载
+- Host Volume Mount
+
+## Definition
+Docker 中将宿主机的特定目录或文件直接映射到容器内部的一种挂载方式。与命名卷（Named Volume）不同，绑定挂载使用宿主机上的绝对路径，使容器内外的文件系统保持同步，实现代码修改实时生效。
+
+## Use Cases
+- **开发环境**：代码文件频繁变更，绑定挂载实现宿主机编辑 → 容器即时生效的热重载
+- **配置文件**：将 nginx.conf、.env 等配置文件挂载进容器，方便实时调整
+- **日志收集**：将容器日志目录挂载到宿主机，实现日志持久化和集中管理
+
+## Syntax
+```yaml
+# docker-compose.yml
+services:
+  app:
+    volumes:
+      - /home/user/project/src:/app/src  # 宿主机路径:容器路径
+      - ./config:/app/config             # 相对路径（相对于 compose 文件位置）
+```
+
+## Trade-offs
+| 优点 | 缺点 |
+|------|------|
+| 代码修改实时生效 | 依赖宿主机文件系统结构 |
+| 无需数据迁移 | 权限问题（UID/GID 不匹配）|
+| 便于调试和热重载 | 生产环境不推荐使用 |
+
+## Related Concepts
+- [[Docker Volume]]：命名卷，适合生产环境的数据持久化
+- [[Remote Development]]：远程开发中使用 Bind Mount 实现代码同步
+- [[Docker Compose]]：通过 YAML 定义 Bind Mount 配置
+
+## Related Entities
+- [[Docker]]：Bind Mount 的实现平台
+- [[Trae]]：通过 Remote-SSH 连接远程服务器，编辑 Bind Mount 挂载的代码
+
+## References
+- [[Trae远程开发部署指南]] — 开发环境 docker-compose.yml 使用 Bind Mount 实现代码热重载

wiki/concepts/Build-Mode.md

@@ -0,0 +1,31 @@
+---
+title: "Build Mode"
+type: concept
+tags: [opencode, workflow, implementation]
+sources: [如何在ubuntu上安装opencode并配置vibe-kanban]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+**Build Mode**（构建模式）是 OpenCode 的双模式工作流之一。通过 Tab 键从 Plan 模式切换回来，执行实际的代码修改和文件写入。
+
+## Mechanism
+
+- 从 Plan 模式按 Tab 键切换回 Build 模式
+- AI 获得完整的文件写入权限
+- 执行 Plan 阶段生成的实现方案
+- 支持 `/undo` 撤销最近的修改，`/redo` 重做
+
+## Build Workflow
+
+1. **Plan 阶段**：描述需求，AI 生成实现方案
+2. **Review 阶段**：审阅方案，补充上下文和示例
+3. **Build 阶段**：Tab 切换，执行 `Sounds good! Go ahead and make the changes.`
+4. **Iterate 阶段**：如需调整，用 `/undo` 回退后重新 Plan
+
+## Related Concepts
+
+- [[Plan Mode]] — Build 模式的前置阶段，生成实现方案
+- [[OpenCode]] — 提供 Plan/Build 双模式的核心工具
+- [[Vibe Coding]] — AI 辅助编程的工作流理念

wiki/concepts/Claude-Code-Templates.md

@@ -0,0 +1,45 @@
+---
+title: "Claude Code Templates"
+type: concept
+tags: [claude-code, claude-skills, npx]
+---
+
+## Definition
+
+Claude Code Templates 是一个通过 npm 包 `claude-code-templates` 分发的 Claude Code 增强模板库，提供预配置的 Skills（技能）、Agents（代理）和 MCP（Model Context Protocol 工具）三大类可复用模板。
+
+## Core Properties
+
+- **分发方式**：npm 包 + npx 一键安装，无需手动复制粘贴
+- **模板来源**：社区维护，托管于 aitmpl.com
+- **安装命令**：`npx claude-code-templates@latest --skill=<path> --yes`
+- **支持平台**：Claude Code、Trae IDE
+
+## Template Categories
+
+| 分类 | 说明 | 示例路径 |
+|------|------|----------|
+| Skills | 可复用的 AI 技能单元，封装专业工作流 | `development/git-commit-helper` |
+| Agents | 预设角色和行为的专业代理模板 | `agents/<name>` |
+| MCP | 扩展 AI 工具调用能力的协议工具 | `mcps/<name>` |
+
+## Usage Pattern
+
+```bash
+# 进入项目目录
+cd your-project
+
+# 安装指定的 Skill
+npx claude-code-templates@latest --skill=development/git-commit-helper --yes
+```
+
+## Related Concepts
+
+- [[Claude Code Skills]] — Claude Code 可复用能力单元
+- [[Claude Code]] — 目标增强工具
+- [[MCP（Model Context Protocol）]] — 工具扩展协议
+
+## Aliases
+
+- claude-code-templates
+- Claude Code Templates

wiki/concepts/CodeWeaver.md

@@ -0,0 +1,31 @@
+---
+title: "CodeWeaver"
+type: concept
+tags: []
+last_updated: 2025-12-30
+---
+
+## Definition
+
+CodeWeaver 是一个 GitHub 开源工具（tesserato/CodeWeaver），可将任意代码库编织成一个可导航的 Markdown 文档。
+
+## Key Features
+
+- **树形结构**：将整个项目组织成清晰的树形 Markdown 文件
+- **代码块嵌入**：所有代码都塞进代码块中，保持可复制性
+- **可导航性**：生成的文档支持跳转和导航
+- **AI 友好**：极大地简化了代码库的共享、文档化以及与 AI/ML 工具集成
+
+## Use Cases
+
+- **知识转移**：快速分享复杂代码库的结构
+- **AI 上下文注入**：为 AI 代理提供代码库概览
+- **文档生成**：自动生成项目文档
+
+## Related Concepts
+
+- [[Vibe Coding]]：CodeWeaver 可增强 Vibe Coding 的代码理解能力
+
+## Sources
+
+- [[vibe-coding经验收集]]

wiki/concepts/DRY原则.md

@@ -0,0 +1,28 @@
+---
+title: "DRY原则"
+type: concept
+tags: [software-engineering, coding-standards, best-practices, dry]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**DRY 原则（Don't Repeat Yourself）** 是一种软件开发原则，核心思想是：系统中的每一片知识都必须有一个单一、明确、权威的表述。避免重复代码，提炼公共逻辑，提高复用价值。
+
+## Core Principles
+
+- 消除重复代码
+- 提炼公共逻辑到可复用模块
+- 保持代码的单一事实来源
+- 通过抽象和模块化实现代码复用
+
+## Related Concepts
+
+- [[单一职责原则]] — DRY 的前提是模块有清晰的职责
+- [[模块化编程]] — DRY 的实现手段
+- [[Vibe Coding]] — AI 辅助开发中避免重复生成相似代码的指导原则
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]

wiki/concepts/Design-to-Code-Workflow.md

@@ -0,0 +1,39 @@
+---
+title: "Design-to-Code Workflow"
+type: concept
+tags: []
+last_updated: 2025-12-30
+---
+
+## Definition
+
+Design-to-Code Workflow（设计到代码工作流）是一种递进式 AI 辅助开发方法，通过从高层次的抽象描述逐步细化为可执行代码，实现人机协作的编程实践。
+
+## Core Principles
+
+### 三阶段递进
+1. **设计文档**：详细描述需求和架构
+2. **伪代码**：Service 层具体逻辑用伪代码写明
+3. **代码**：AI 根据伪代码直接生成可执行代码
+
+### 工作流程
+```
+需求文档 → 伪代码(含Service层逻辑) → AI直出代码 → 另一AI review → 跑测试用例 → AI自动commit+push
+```
+
+## Key Benefits
+
+- **减少迭代次数**：详细伪代码使 AI 一次直出成为可能
+- **质量保证**：双 AI 协作（生成+review）确保代码质量
+- **可追溯**：设计文档保留了完整的决策过程
+- **降低认知负担**：开发者无需记忆所有实现细节
+
+## Related Concepts
+
+- [[Vibe Coding]]：整体方法论背景
+- [[Multi-AI Review]]：双人编程模式
+- [[Verification-First Engineering]]：验证优先原则
+
+## Sources
+
+- [[vibe-coding经验收集]]

wiki/concepts/GDM3.md

@@ -0,0 +1,99 @@
+---
+title: "GDM3"
+type: concept
+tags: [显示管理器, GNOME, Ubuntu]
+last_updated: 2026-04-14
+---
+
+# GDM3
+
+GNOME Display Manager 3，是 Ubuntu 桌面环境默认的登录管理器，负责用户认证、会话选择和显示协议切换。
+
+## 基本信息
+- **类型**：显示管理器（Display Manager）
+- **所属项目**：GNOME
+- **配置文件**：`/etc/gdm3/custom.conf`
+- **官网**：https://wiki.gnome.org/Projects/GDM
+
+## 核心功能
+- **用户认证**：显示登录界面，验证用户凭据
+- **会话选择**：允许用户选择桌面环境（GNOME/XFCE/KDE等）
+- **显示协议**：控制使用 Wayland 或 X11
+- **会话启动**：调用用户选择的桌面环境
+
+## 与 Wayland/X11 的关系
+
+GDM3 是连接显示协议和用户会话的桥梁：
+
+```
+硬件 → Kernel → Mesa/DRI → X11/Wayland → GDM3 → GNOME Shell → 用户应用
+```
+
+### 配置显示协议
+
+编辑 `/etc/gdm3/custom.conf`：
+
+```bash
+sudo nano /etc/gdm3/custom.conf
+```
+
+| 配置 | 效果 |
+|------|------|
+| `WaylandEnable=true`（默认） | GDM 和会话都使用 Wayland |
+| `WaylandEnable=false` | 强制 GDM 和会话使用 X11 |
+
+### 完整配置示例
+
+```ini
+[daemon]
+# 取消注释以禁用 Wayland，强制使用 X11
+WaylandEnable=false
+
+# 自动登录（可选）
+AutomaticLogin=username
+AutomaticLoginEnable=True
+
+# Timed 登录（可选）
+TimedLogin=username
+TimedLoginEnable=True
+TimedLoginDelay=5
+```
+
+## 重启 GDM3 服务
+
+修改配置后需要重启 GDM：
+
+```bash
+# 方法1：重启 GDM 服务（不中断其他用户）
+sudo systemctl restart gdm3
+
+# 方法2：完全重启（会中断所有会话）
+sudo reboot
+```
+
+## 故障排查
+
+### GDM 无法启动
+```bash
+# 查看 GDM 日志
+sudo journalctl -u gdm3 -n 50
+
+# 检查 X11 日志
+cat /var/log/Xorg.0.log
+```
+
+### 切换后黑屏
+通常是显卡驱动问题，尝试：
+```bash
+# 查看当前显卡
+lspci | grep -i vga
+
+# 安装推荐驱动
+sudo ubuntu-drivers autoinstall
+```
+
+## 相关概念
+- [[Wayland]] — 默认显示协议（Ubuntu 24.04）
+- [[X11]] — 传统显示协议（通过 WaylandEnable=false 启用）
+- [[RustDesk]] — 受 GDM Wayland 配置影响的远程桌面软件
+- [[GNOME]] — 使用 GDM3 的桌面环境

wiki/concepts/Multi-AI-Review.md

@@ -0,0 +1,31 @@
+---
+title: "Multi-AI Review"
+type: concept
+tags: []
+last_updated: 2025-12-30
+---
+
+## Definition
+
+Multi-AI Review（多 AI 协作审查）是一种使用多个 AI 代理进行代码开发和审查的工作模式，模拟人类的双人编程（Pair Programming）实践。
+
+## How It Works
+
+1. **主 AI**：根据需求和设计文档生成代码
+2. **Review AI**：审查生成的代码，提出改进意见
+3. **开发者**：根据 Review 意见决定是否采纳
+
+## Benefits
+
+- **质量提升**：多角度审查发现单一代码审查无法覆盖的问题
+- **效率保持**：无需等待人类审查员，实时反馈
+- **一致性**：审查标准可配置，保证评审质量稳定
+
+## Related Concepts
+
+- [[Design-to-Code Workflow]]：Multi-AI Review 是其组成部分
+- [[Vibe Coding]]：整体方法论背景
+
+## Sources
+
+- [[vibe-coding经验收集]]

wiki/concepts/Obsidian-Tasks.md

@@ -0,0 +1,25 @@
+---
+title: "Obsidian Tasks"
+type: concept
+tags: []
+sources: []
+last_updated: 2025-03-13
+---
+
+## Definition
+Obsidian Tasks 是 Obsidian 的任务管理插件，通过 Markdown 语法（`- [ ]`）创建任务，支持日期、优先级、标签、重复任务，并通过代码块查询在任意笔记中嵌入动态任务筛选视图。
+
+## Details
+- **插件来源**：Obsidian 社区插件市场
+- **任务语法**：`- [ ] 任务内容 📅 日期 🔼 优先级 #标签`
+- **查询语法**：`tasks` 代码块，支持 `not done`/`due before`/`sort by` 等筛选条件
+- **重复任务**：`⏳ every week`/`⏳ every month` 自动创建周期性新任务
+
+## Related Concepts
+- [[Task Query]]：Tasks 插件的查询语法
+- [[Recurring Task]]：周期性任务机制
+- [[Dataview]]：Obsidian 的笔记索引插件，与 Tasks 互补
+- [[Second Brain]]：个人知识管理框架，Tasks 是其中的行动层
+
+## Sources
+- [[obsidian-tasks-插件-这可能是最适合懒人的任务管理方式]]

wiki/concepts/Plan-Mode.md

@@ -0,0 +1,31 @@
+---
+title: "Plan Mode"
+type: concept
+tags: [opencode, workflow, design]
+sources: [如何在ubuntu上安装opencode并配置vibe-kanban]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+**Plan Mode**（计划模式）是 OpenCode 的双模式工作流之一。通过 Tab 键从 Build 模式切换进入，禁用写入能力，只生成实现方案和步骤分解。
+
+## Mechanism
+
+- 通过键盘 Tab 键切换到 Plan 模式
+- 界面上会显示模式指示器（通常在右下角）
+- AI 只分析、推理、输出方案，不执行任何文件修改
+- 用户可以审阅、反馈、补充细节后，再切换回 Build 模式
+
+## Use Cases
+
+- 复杂功能的需求澄清与方案评审
+- 多方案对比分析
+- 新技术栈的可行性调研
+- 与团队成员的协作沟通
+
+## Related Concepts
+
+- [[Build Mode]] — Plan 模式的反向操作，执行实际代码修改
+- [[OpenCode]] — 提供 Plan/Build 双模式的核心工具
+- [[AGENTS.md]] — 项目上下文定义，与 Plan Mode 配合提供充足背景信息

wiki/concepts/Recurring-Task.md

@@ -0,0 +1,21 @@
+---
+title: "Recurring Task"
+type: concept
+tags: []
+sources: []
+last_updated: 2025-03-13
+---
+
+## Definition
+Recurring Task（重复任务）是指周期性自动创建新实例的任务机制，使用 `⏳ every week`/`⏳ every month` 等语法在 Obsidian Tasks 插件中实现，避免手动复制粘贴更新日期的重复劳动。
+
+## Details
+- **语法**：`⏳ every week`（每周）、`⏳ every month`（每月）
+- **应用场景**：每周发布公众号文章、每月整理笔记等周期性事务
+- **优势**：彻底解放手动更新日期的重复劳动，任务完成后自动在下一个周期生成新任务实例
+
+## Related Concepts
+- [[Obsidian Tasks]]：Recurring Task 的实现插件
+
+## Sources
+- [[obsidian-tasks-插件-这可能是最适合懒人的任务管理方式]]

wiki/concepts/Redis缓存.md

@@ -0,0 +1,28 @@
+---
+title: "Redis缓存"
+type: concept
+tags: [software-engineering, redis, caching, performance, database]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**Redis 缓存** 是利用 Redis 作为内存数据存储来缓存热点数据，从而提升系统读性能、降低数据库压力的技术方案。
+
+## Core Principles
+
+- 作为缓存层极大提升系统「读性能」
+- 降低数据库访问压力
+- 提供计数、锁、队列、Session 等能力
+- 让系统更快、更稳定、更抗压
+
+## Related Concepts
+
+- [[微服务架构]] — Redis 常作为服务间共享缓存或分布式锁服务
+- [[消息队列]] — Redis 支持 List 结构实现轻量级队列
+- [[输入-处理-输出模型]] — Redis 作为缓存（状态存储）在系统中的角色
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]

wiki/concepts/Remote-SSH.md

@@ -0,0 +1,35 @@
+---
+title: "Remote-SSH"
+type: concept
+tags: [remote-development, ssh, ide]
+last_updated: 2026-04-22
+---
+
+## Definition
+通过 SSH 协议将本地 IDE 连接到远程服务器的开发模式。代码实际运行在远程服务器上，但编辑器和 UI 交互发生在本地机器。
+
+## Mechanism
+1. 本地 IDE 安装 Remote-SSH 插件
+2. 通过 SSH Config 定义远程服务器连接信息
+3. 连接时在远程服务器自动安装轻量级代理（VS Code Server / Trae Server）
+4. 所有文件编辑、终端、Git 操作均通过 SSH 隧道与远程服务器通信
+
+## Key Features
+- 代码不离开服务器，数据安全
+- 利用服务器算力（GPU、大内存）进行开发
+- 支持 Docker 容器 Attach 开发模式
+- 支持多终端窗口
+- SSH Agent Forwarding 可复用本地 SSH Key 访问 Git
+
+## Two Docker Development Modes
+- **Attach 容器模式**：直接进入已在运行的 Docker 容器内部编辑代码，适合调试，环境完全隔离
+- **宿主机文件 + Docker CLI 模式**：编辑 Ubuntu 宿主机上的源码目录，在终端调用 docker compose，适合编排多容器配置
+
+## Connections
+- [[Trae]] — IDE 实现
+- [[Cursor]] — 支持 Remote-SSH
+- [[SSH Config]] — 连接配置方式
+- [[SSH 免密登录]] — 前提条件
+- [[Attach 容器]] — 容器开发模式
+- [[Bind Mount]] — 开发环境代码挂载机制
+- [[Docker]] — 容器化开发环境

wiki/concepts/RemoteDevelopment.md

@@ -0,0 +1,41 @@
+---
+title: "Remote Development"
+type: concept
+tags: [development, ssh, remote-workflow]
+last_updated: 2026-04-17
+---
+
+## Aliases
+- Remote SSH
+- Remote Development
+- 远程开发
+
+## Definition
+通过 IDE 的远程连接功能，在远程服务器上进行代码开发、调试和部署，而本地机器仅作为 UI 终端。核心技术是 SSH 协议和远程插件生态（如 VS Code Remote-SSH、Trae Remote-SSH）。
+
+## Core Components
+- **SSH 免密登录**：通过 SSH Key 实现无密码认证，是远程连接的基础
+- **Remote Server**：运行代码和 Docker 服务的远程主机（Ubuntu Server 等）
+- **IDE Client**：本地安装的代码编辑器，通过 SSH 隧道连接到远程服务器
+- **VS Code Server/Trae Server**：在远程服务器上安装的代理组件，负责处理文件操作和终端会话
+
+## Workflow
+1. 配置 SSH Config 文件，在本地定义远程主机的连接别名
+2. 安装 Remote-SSH 插件
+3. 连接远程主机，IDE 自动安装远程服务器组件
+4. 打开远程文件夹，开始开发
+
+## Related Concepts
+- [[Bind Mount]]：Docker 挂载方式，与远程开发配合实现代码实时同步
+- [[Docker Compose]]：远程开发项目的运行环境定义工具
+- [[Vibe Coding]]：通过 AI 增强的远程开发工作流
+- [[Trae]]：支持 Remote-SSH 的国产 AI IDE
+- [[OpenCode]]：CLI 形态的远程 AI 编码 agent
+
+## Related Entities
+- [[Trae]]：支持 Remote-SSH 的 IDE
+- [[Ubuntu]]：常用远程开发主机操作系统
+- [[Tailscale]]：安全的公网远程访问工具
+
+## References
+- [[Trae远程开发部署指南]] — 完整的 Remote-SSH + Docker 开发配置指南

wiki/concepts/Task-Query.md

@@ -0,0 +1,28 @@
+---
+title: "Task Query"
+type: concept
+tags: []
+sources: []
+last_updated: 2025-03-13
+---
+
+## Definition
+Task Query（任务查询）是 Obsidian Tasks 插件的核心功能，通过 `tasks` 代码块定义筛选条件（`not done`/`due before tomorrow`/`sort by priority` 等），在笔记任意位置嵌入动态任务列表。
+
+## Details
+- **语法示例**：
+  ````
+  ```tasks
+  not done
+  due before tomorrow
+  sort by priority
+  ```
+  ````
+- **特点**：比 Notion 数据库更灵活，可嵌入任意笔记的上下文中，实现「在笔记的上下文里直接看到当前最重要的任务」
+- **常用条件**：`not done`/`done`/`due on <date>`/`due before <date>`/`due after <date>`/`sort by created/sort by priority/sort by date`
+
+## Related Concepts
+- [[Obsidian Tasks]]：Task Query 的宿主插件
+
+## Sources
+- [[obsidian-tasks-插件-这可能是最适合懒人的任务管理方式]]

wiki/concepts/Vibe-Coding.md

@@ -0,0 +1,36 @@
+---
+title: "Vibe Coding"
+type: concept
+tags: [ai, workflow, productivity, coding]
+sources: [如何在ubuntu上安装opencode并配置vibe-kanban, vibe-coding经验收集, 开发经验与项目规范整理文档]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+**Vibe Coding**（氛围编程）是一种使用 AI 辅助编程的工作流理念。开发者通过自然语言描述需求，AI 代理负责代码实现、分析、重构等具体工作。
+
+## Core Principles
+
+- **自然语言驱动**：用日常语言与 AI 沟通，像对待初级开发者一样描述需求
+- **充足上下文**：提供背景信息、示例代码、设计参考（图片/截图）
+- **双模式迭代**：Plan 模式生成方案 → Review 反馈 → Build 模式执行
+- **持续反馈**：对 AI 的输出及时纠正和引导，形成快速迭代
+
+## Related Tools
+
+- [[OpenCode]] — 开源终端 AI 编程代理，支持 Plan/Build 模式
+- [[Claude Code]] — Anthropic CLI agent，竞品
+- [[Cursor]] — AI 代码编辑器
+- [[Gemini CLI]] — Google Gemini 命令行工具
+- [[Vibe-Kanban]] — 与 OpenCode 配合的看板式任务管理
+
+## Related Concepts
+
+- [[Plan Mode]] — Vibe Coding 工作流中的计划阶段
+- [[Build Mode]] — Vibe Coding 工作流中的构建阶段
+- [[AGENTS.md]] — 为 Vibe Coding 项目提供上下文的角色定义文件
+- [[Agent Personality Design]] — AI Agent 角色与个性设计方法
+- [[Design-to-Code Workflow]] — 设计文档→伪代码→代码的递进式开发流程
+- [[Multi-AI Review]] — 多 AI 协作审查，双人编程模式
+- [[CodeWeaver]] — 代码库转可导航 Markdown 文档工具

wiki/concepts/Wayland.md

@@ -0,0 +1,53 @@
+---
+title: "Wayland"
+type: concept
+tags: [显示协议, Linux, 安全]
+last_updated: 2026-04-14
+---
+
+# Wayland
+
+Linux 新一代显示协议和窗口系统，Ubuntu 24.04 默认使用，旨在替代传统的 X11。
+
+## 基本信息
+- **类型**：显示协议 / 窗口合成器
+- **首个稳定版**：2016年
+- **官网**：https://wayland.freedesktop.org
+
+## 与 X11 的对比
+
+| 特性 | Wayland | X11 |
+|------|---------|-----|
+| 架构 | 客户端直接与合成器通信 | 客户端通过 X Server 通信 |
+| 安全性 | 沙箱隔离，应用间相互隔离 | 应用间共享内存，可互相截屏 |
+| 性能 | 合成器直接渲染，减少拷贝 | 多次拷贝，延迟较高 |
+| 兼容性 | 较新，部分旧应用可能不兼容 | 成熟稳定，兼容性好 |
+| 远程桌面 | 支持但复杂（PipeWire/RDP） | 原生支持 VNC/xrdp |
+| 驱动支持 | 依赖现代图形驱动 | 广泛支持 |
+
+## 安全设计原则
+Wayland 基于安全优先设计：
+- 每个窗口独立合成，应用间无法直接访问其他窗口内容
+- 屏幕录制/截屏需要用户显式授权（通过 PipeWire）
+- 外部程序无法在未授权状态下获取屏幕控制权
+
+## 与远程桌面的冲突
+Wayland 的安全设计导致以下问题：
+- **RustDesk** 等远程桌面软件无法在 Login Screen（未登录状态）获取屏幕控制权
+- VNC 传统方式无法直接工作
+- 需要额外配置（如 PipeWire + xdg-desktop-portal）才能实现屏幕共享
+
+## Ubuntu 24.04 默认启用
+Ubuntu 24.04 LTS 将 Wayland 作为默认显示协议，但仍可通过配置回退到 X11：
+
+```bash
+# 编辑 GDM 配置
+sudo nano /etc/gdm3/custom.conf
+# 注释掉 WaylandEnable=false 以启用 Wayland（默认已启用）
+# 取消注释 WaylandEnable=false 以强制使用 X11
+```
+
+## 相关概念
+- [[X11]] — 传统显示协议（Wayland 的前身）
+- [[GDM3]] — GNOME Display Manager，控制 Wayland/X11 切换
+- [[RustDesk]] — 受 Wayland 安全限制影响的远程桌面软件

wiki/concepts/X11.md

@@ -0,0 +1,65 @@
+---
+title: "X11"
+type: concept
+tags: [显示协议, Linux, 远程桌面]
+last_updated: 2026-04-14
+---
+
+# X11
+
+传统的 Linux 显示协议和窗口系统，也称为 X Window System 或 X.org，是 Linux 桌面环境数十年的标准显示架构。
+
+## 基本信息
+- **类型**：显示协议 / 窗口系统
+- **首个版本**：1984年（MIT）
+- **当前版本**：X11R7.x / X.org Server
+- **官网**：https://www.x.org
+
+## 架构特点
+```
+应用程序 → X Client Library → X Server → 显示硬件
+                         ↑
+                    网络连接（可远程）
+```
+
+- **X Server**：运行在用户本地，接收客户端请求并管理屏幕/键盘/鼠标
+- **X Client**：应用程序本身，通过 X Protocol 与 Server 通信
+- **网络透明**：X 协议基于网络，应用程序可在远程机器运行而本地显示
+
+## 优势
+- **广泛兼容**：几乎所有 Linux 应用都支持
+- **远程桌面友好**：原生支持 VNC/xrdp/SPICE 等远程协议
+- **权限开放**：应用可访问屏幕内容，便于截图、录屏、远程控制
+- **成熟稳定**：40年历史，bug少，文档丰富
+
+## 劣势
+- **安全性低**：应用间共享内存，可互相截屏或注入输入
+- **性能较低**：多次内存拷贝，延迟较高
+- **架构老旧**：设计于80年代，不适合现代图形需求
+
+## 在 Ubuntu 24.04 中的配置
+Ubuntu 24.04 默认使用 Wayland，但可通过 GDM3 强制启用 X11：
+
+```bash
+# 编辑配置文件
+sudo nano /etc/gdm3/custom.conf
+
+# 找到并修改
+[daemon]
+WaylandEnable=false  # 取消注释
+
+# 重启 GDM
+sudo systemctl restart gdm3
+```
+
+## 远程桌面场景
+X11 在以下远程桌面场景优于 Wayland：
+- **RustDesk**：需要 X11 才能在 Login Screen 交互
+- **VNC**：原生支持
+- **xrdp**：标准方案
+- **xdotool/xte**：自动化输入工具
+
+## 相关概念
+- [[Wayland]] — 新一代显示协议（X11 的替代者）
+- [[GDM3]] — GNOME Display Manager，控制 X11/Wayland 切换
+- [[RustDesk]] — 依赖 X11 的远程桌面软件

wiki/concepts/单一职责原则.md

@@ -0,0 +1,28 @@
+---
+title: "单一职责原则"
+type: concept
+tags: [software-engineering, solid, coding-standards, design-principle]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**单一职责原则（Single Responsibility Principle, SRP）** 是 SOLID 面向对象设计原则之一，核心思想是：每个模块、类、函数应该只负责一件事，只有一个引起它变化的原因。
+
+## Core Principles
+
+- 每个文件只负责一个功能
+- 每个类只负责一个领域
+- 每个函数只处理一个任务
+- 当需求变化时，只有某一个原因会导致该模块修改
+
+## Related Concepts
+
+- [[DRY原则]] — 避免重复代码，与单一职责互补
+- [[模块化编程]] — 单一职责的具体实现方式
+- [[输入-处理-输出模型]] — 系统行为的划分框架
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]

wiki/concepts/并发编程.md

@@ -0,0 +1,36 @@
+---
+title: "并发编程"
+type: concept
+tags: [software-engineering, concurrency, multi-threading, async]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**并发编程** 是指程序中多个执行流同时存在的编程范式，需要处理共享资源、数据竞争、锁机制等问题。
+
+## Core Principles
+
+- 清晰区分共享资源
+- 避免数据竞争（Race Condition）
+- 必要时加锁或使用线程安全结构
+- 区分「并发处理」和「异步处理」的差异
+
+## Concurrency vs Async
+
+| 维度 | 并发（Concurrency） | 异步（Async） |
+|------|---------------------|--------------|
+| 目标 | 同时执行多个任务 | 不阻塞等待 I/O |
+| 实现 | 多线程、多进程 | 事件循环、回调、Promise |
+| 问题 | 数据竞争、死锁 | 回调地狱、状态管理 |
+
+## Related Concepts
+
+- [[单一职责原则]] — 线程安全的函数应保持单一职责
+- [[输入-处理-输出模型]] — 并发环境下的数据流管理
+- [[消息队列]] — 替代直接共享资源的并发安全方案
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]

wiki/concepts/微服务架构.md

@@ -0,0 +1,30 @@
+---
+title: "微服务架构"
+type: concept
+tags: [software-engineering, architecture, microservices, distributed-systems]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**微服务架构（Microservices Architecture）** 是一种将单体应用拆分为多个小型、独立服务的设计模式。每个服务运行在独立进程中，围绕业务能力组织，通过轻量级协议（HTTP、RPC、MQ）通信。
+
+## Core Principles
+
+- 独立开发：每个服务可由独立团队开发
+- 独立部署：服务可独立发布，不影响其他服务
+- 独立扩容：根据负载单独扩展对应服务
+- 业务边界清晰：每个服务处理一个业务领域（Bounded Context）
+- 服务间通过 API 通信：HTTP、RPC、消息队列等
+
+## Related Concepts
+
+- [[模块化编程]] — 微服务是模块化思想在系统级别的延伸
+- [[消息队列]] — 微服务间异步通信的常用手段
+- [[Redis缓存]] — 微服务架构中常用的缓存层
+- [[Docker]] — 微服务容器化部署的基础设施
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]

wiki/concepts/模块化编程.md

@@ -0,0 +1,28 @@
+---
+title: "模块化编程"
+type: concept
+tags: [software-engineering, architecture, modular-design, code-organization]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**模块化编程** 是一种将程序划分为独立、可复用模块的软件开发方法。每个模块有明确的职责边界，通过定义良好的接口与其他模块交互。
+
+## Core Principles
+
+- 高内聚：模块内部元素紧密相关
+- 低耦合：模块之间依赖最小化
+- 清晰接口：模块通过公共接口通信
+- 独立部署：模块可独立开发、测试和部署
+
+## Related Concepts
+
+- [[单一职责原则]] — 模块化的设计基础
+- [[DRY原则]] — 模块化的目标之一是提高复用
+- [[微服务架构]] — 模块化的架构级别应用
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]

wiki/concepts/消息队列.md

@@ -0,0 +1,28 @@
+---
+title: "消息队列"
+type: concept
+tags: [software-engineering, architecture, message-queue, async, distributed-systems]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**消息队列（Message Queue）** 是一种用于服务之间异步通信的中间件。生产者将消息发送到队列，消费者异步从队列中取出并处理，实现服务间的松耦合。
+
+## Core Principles
+
+- **解耦**：生产者和消费者无需同时在线，直接依赖接口
+- **削峰填谷**：在高负载时缓存消息，平滑处理压力
+- **异步任务处理**：非实时任务可放入队列异步处理
+- **提高系统稳定性与吞吐**：通过异步处理提升系统整体吞吐量
+
+## Related Concepts
+
+- [[微服务架构]] — 消息队列是微服务间通信的重要方式
+- [[Redis缓存]] — Redis 也可实现轻量级消息队列
+- [[输入-处理-输出模型]] — 消息队列在「处理」环节的异步化作用
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]

wiki/concepts/版本控制.md

@@ -0,0 +1,44 @@
+---
+title: "版本控制"
+type: concept
+tags: [git, version-control, development]
+last_updated: 2026-04-22
+---
+
+## Overview
+版本控制（Version Control）是记录项目代码历史版本变化的系统，支持代码回滚和团队协同。Git是当前最主流的分布式版本控制系统。
+
+## Key Benefits
+- **历史追踪**：记录每次代码变更的完整历史
+- **回滚能力**：轻松恢复到任意历史版本
+- **分支管理**：支持并行开发和功能隔离
+- **团队协作**：多人协同开发，合并代码变更
+- **变更审查**：通过Diff功能对比不同版本差异
+
+## Core Concepts
+- **Repository（仓库）**：存储代码和历史记录的仓库
+- **Commit（提交）**：保存代码变更的基本单位
+- **Branch（分支）**：独立的开发线
+- **Merge（合并）**：将分支变更合并到主分支
+- **Diff（差异对比）**：查看代码改动的内容
+- **Revert（回滚）**：撤销错误的提交
+
+## Best Practices
+1. **频繁提交**：小步提交，便于追踪和回滚
+2. **清晰提交信息**：描述变更内容，便于理解
+3. **Code Review**：在合并前进行代码审查
+4. **分支策略**：如Git Flow，适合团队协作
+5. **保护主分支**：避免直接提交到main/master
+
+## Integration with AI Tools
+- AI生成的代码会自动写入文件，需通过Diff审查后再保存
+- AI可辅助初始化Git仓库和提交代码
+- 结合版本控制可有效管理AI生成的代码变更
+
+## Tools
+- [[Git]] — 分布式版本控制系统
+- [[GitHub]] — 基于Git的代码托管平台
+- [[Gitea]] — 自托管Git服务
+
+## Sources
+- [[cursor-2-0初学者使用指南]]

wiki/concepts/输入-处理-输出模型.md

@@ -0,0 +1,35 @@
+---
+title: "输入-处理-输出模型"
+type: concept
+tags: [software-engineering, architecture, design-pattern, system-design]
+sources: [开发经验与项目规范整理文档]
+last_updated: 2025-12-30
+---
+
+## Definition
+
+**输入-处理-输出模型** 是一种系统行为划分框架，将系统行为分为四个明确的概念：消费端、生产端、状态（变量）、变换（函数）。
+
+## Core Principles
+
+| 概念 | 说明 |
+|------|------|
+| 消费端 | 接收外部数据或依赖输入的地方 |
+| 生产端 | 生成数据、输出结果的地方 |
+| 状态（变量） | 存储当前系统信息的变量 |
+| 变换（函数） | 处理状态、改变数据的逻辑 |
+
+- 明确区分「输入 → 处理 → 输出」，并独立管理每个环节
+- 消费端负责接收和验证输入
+- 变换负责业务逻辑处理
+- 生产端负责格式化输出
+
+## Related Concepts
+
+- [[单一职责原则]] — 模型的每个环节承担单一职责
+- [[微服务架构]] — 服务间通过 API 传递输入输出
+- [[消息队列]] — 生产端与消费端的异步解耦机制
+
+## Source Reference
+
+来源：[[开发经验与项目规范整理文档]]