ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Auto-sync: 2026-04-27 04:02

Browse Source
This commit is contained in:
weishen
2026-04-27 04:02:52 +08:00
parent 23bef113dd
commit 1642757cd0
16 changed files with 845 additions and 649 deletions
Download Patch File Download Diff File Expand all files Collapse all files

103
wiki/sources/cursor-2-0初学者使用指南.md
View File

@@ -1,52 +1,51 @@
---
title: "Cursor 2.0初学者使用指南"
type: source
tags: [ai, cursor, ide, mcp]
date: 2026-04-22
---
## Source File
- [[Vibe Coding/Cursor 2.0初学者使用指南.md]]
## Summary（用中文描述）
- 核心主题：Cursor 2.0 AI代码编辑器的系统化入门教程
- 问题域：AI辅助编程工具的使用方法与工作流程
- 方法/机制：通过视频演示展示安装、配置、AI代理操作、代码审查、版本控制、MCP扩展等全流程
- 结论/价值：帮助初学者从零掌握AI代码编辑器，建立"需求明确→规划→生成→审查→版本控制"的完整开发闭环
## Key Claims（用中文描述）
- Cursor 2.0基于VS Code构建，集成AI模型辅助代码生成，初学者可免费使用
- Composer是Cursor自研AI模型，生成速度比同类模型快4倍
- AI代理支持Plan（规划）、Agent（执行）、Ask（咨询）三种工作模式，Ask模式仅返回文本不修改文件
- 多代理功能可并行运行不同任务，互不干扰上下文
- MCP（Model Context Protocol）协议可将外部工具和服务集成到AI代理，扩展功能范围
- AI生成代码即写入文件，需通过Diff功能审查后再确认保存
- 结合Git版本控制可有效管理和回滚AI生成的代码变更
## Key Quotes
> "Cursor是基于VS Code的AI代码编辑器，可免费使用，支持付费升级以获取更多生成额度。" — Cursor基础介绍
> "新增了自有AI模型Composer，强调其速度优势（比类似模型快4倍）。" — Composer模型特性
> "Agent模式会修改代码，Ask模式仅提供文本答案，不会改动代码，需根据需求选择。" — 代理模式安全提示
> "代码改动一旦生成即写入文件，未点击撤销按钮前持续保留，需确保先测试代码再确认保存。" — Diff审查机制
> "MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。" — MCP扩展能力
## Key Concepts
- [[AI代理]]：基于AI模型的自动化任务助手，可以按模式生成代码、规划任务或回答疑问
- [[MCP（Model Context Protocol）]]：将外部工具和服务集成到AI代理的协议平台
- [[Diff文件]]：显示代码改动对比的视图，帮助开发者快速审查AI修改的内容
- [[版本控制]]：记录项目代码的历史版本变化，支持代码回滚和团队协同（Git）
- [[多代理并行]]：多个AI代理同时运行不同任务，互不干扰上下文的开发模式
## Key Entities
- [[Cursor]]：基于VS Code的AI增强代码编辑器，支持AI模型辅助代码生成及多任务代理操作
- [[Composer]]：Cursor自研AI模型，主打生成速度比同类模型快4倍
## Connections
- [[Cursor]] ← built_on ← [[VS Code]]
- [[Cursor]] ← uses ← [[Composer]]
- [[Cursor]] ← supports ← [[MCP（Model Context Protocol）]]
- [[MCP（Model Context Protocol）]] ← integrates ← [[AI代理]]
- [[Vibe Coding]] ← demonstrates ← [[Cursor]]
## Contradictions
- 无已知冲突内容
---
title: "Cursor 2.0初学者使用指南"
type: source
tags: [ai, cursor, ide, mcp]
date: 2026-04-22
---
## Source File
- [[Vibe Coding/Cursor 2.0初学者使用指南]]
## Summary（用中文描述）
- 核心主题：Cursor 2.0 AI代码编辑器的初学者完整使用教程，涵盖安装、界面、多代理操作、代码生成、审查与版本控制流程。
- 问题域：AI辅助编程工具的入门学习，聚焦于如何高效使用Cursor的AI代理功能进行项目开发。
- 方法/机制：通过Plan模式规划任务 → Agent模式执行代码生成 → Diff审查改动 → Git版本控制回滚的完整工作流。
- 结论/价值：Cursor 2.0为开发者提供了一条从想法到实现的AI智能化路径，是现代AI辅助编程的重要工具。
## Key Claims（用中文描述）
- Cursor基于VS Code构建，可免费使用，支持付费升级获取更多生成额度。
- Cursor新增自有AI模型Composer，强调其速度优势（比同类模型快4倍）。
- 多代理功能可以同时运行不同任务，互不干扰，提升代码生成效率。
- AI代理支持三种模式：Plan（规划）、Agent（执行，会修改文件）、Ask（咨询，不改代码）。
- 代码生成后进入待审查状态，可使用Diff功能逐个审查或整体接收改动。
- MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。
- 可设定项目规则（如强制为函数生成文档注释），实现代码规范自动化。
## Key Quotes
> "Cursor是基于VS Code的AI代码编辑器，可免费使用，支持付费升级以获取更多生成额度。" — Cursor基本特性介绍
> "启动构建任务时生成新代理，执行计划步骤。多代理功能可以同时运行不同任务，互不干扰。" — 多代理并行操作
> "生成代码后进入待审查状态，可使用Diff功能查看具体改动，支持文件逐个审查或整体接收。" — 代码审查流程
> "MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。" — MCP扩展能力
## Key Concepts
- [[多代理并行]]：可同时运行不同AI代理任务，互不干扰，适合多线程项目开发。
- [[Diff审查]]：通过Diff视图查看AI生成的代码改动，逐个文件或整体接收变更。
- [[项目规则]]：自定义项目规则文件（如强制生成文档注释），实现代码规范自动化。
- [[MCP服务器]]：Model Context Protocol，支持将外部API和工具集成到AI代理。
## Key Entities
- [[Cursor]]：基于VS Code的AI增强代码编辑器，支持多代理并行操作和Composer自研模型。
- [[VS Code]]：Cursor构建的基础编辑器，Cursor继承其完整功能。
- [[Composer]]：Cursor自研AI模型，主打生成速度优势（比同类快4倍）。
## Connections
- [[Cursor]] ← extends ← [[VS Code]]
- [[Cursor]] ← uses ← [[Composer]]
- [[Cursor]] ← supports ← [[MCP（Model Context Protocol）]]
- [[Cursor]] ← enables ← [[Vibe Coding]]
- [[Cursor]] ← similar_to ← [[Claude Code]]
## Contradictions
- 无已知冲突。本文档聚焦Cursor入门操作，与 [[MCP在Cursor中的集成与应用详解]] 互补（后者侧重MCP集成深度应用）。

114
wiki/sources/trae远程开发部署指南.md
View File

@@ -1,57 +1,57 @@
---
title: "Trae远程开发部署指南"
type: source
tags: [remote-ssh, trae, ubuntu]
date: 2026-04-22
---
## Source File
- [[Vibe Coding/Trae远程开发部署指南]]
## Summary（用中文描述）
- 核心主题：使用 Trae IDE 通过 SSH 远程连接 Ubuntu 服务器进行 Docker 容器化项目的开发工作流配置
- 问题域：远程开发环境搭建、Docker 与 IDE 集成、内网穿透访问
- 方法/机制：SSH 免密登录 → Trae Remote-SSH 连接 → Docker 容器 Attach 或宿主机文件编辑 → Tailscale/FRP 公网访问
- 结论/价值：提供一套完整的"本地 UI + 远程服务器开发"解决方案，支持 Attach 容器调试和 docker-compose 编排两种模式
## Key Claims（用中文描述）
- Trae 原生支持 VS Code 插件生态，通过 Remote-SSH 插件可远程连接 Ubuntu 服务器
- 开发模式 A（Attach 容器）：适合调试，环境完全隔离，直接使用容器内语言环境
- 开发模式 B（宿主机文件 + Docker CLI）：适合编排 docker-compose.yml 和管理多容器配置
- 用户必须加入 docker 用户组才能让 Trae 的 Docker 插件正常工作
- 文件权限（UID/GID）问题会导致 Volume 挂载生成的 Build 文件归属 root，宿主机无法操作
## Key Quotes
> "开发环境的核心在于 Bind Mount（绑定挂载），实现代码修改实时生效" — 解释开发环境 docker-compose.yml 的设计原则
> "SSH 登录服务器执行：sudo usermod -aG docker $USER，必须注销并重新登录" — Docker 用户组配置关键步骤
> "不要直接暴露 SSH 端口，建议安装 Tailscale 或 Cloudflare Tunnel" — 内网穿透安全建议
## Key Concepts
- [[Remote-SSH]]：通过 SSH 协议将本地 IDE 连接到远程服务器，代码运行在服务器端但 UI 在本地
- [[Bind Mount]]：Docker Volume 挂载方式，将宿主机目录映射到容器内，实现代码修改实时生效
- [[Attach 容器]]：将 IDE 直接连接到正在运行的 Docker 容器内部进行开发调试的模式
- [[Docker 用户组]]：将用户加入 docker 组使其无需 sudo 即可运行 docker 命令
- [[SSH Config]]：SSH 客户端配置文件（~/.ssh/config），定义 Host 别名和连接参数
- [[SSH 免密登录]]：通过 ssh-copy-id 公钥分发实现无密码 SSH 连接
- [[Docker Compose 开发模式]]：使用 docker-compose.yml 编排开发环境，通过 volumes 实现源码挂载
## Key Entities
- [[Trae]]：国产 AI IDE，基于 VS Code，支持 Remote-SSH 远程开发，与 Cursor 功能类似
- [[Ubuntu 2]]：开发服务器（192.168.3.45），存放源码，运行带 Bind Mount 的开发容器
- [[Ubuntu 1]]：生产服务器（192.168.3.47），运行生产容器，通过 Docker 卷持久化数据
- [[ThinkBook]]：本地笔记本，作为 Trae UI 端连接远程服务器
- [[Tailscale]]：零配置 VPN 工具，可替代 FRP 提供安全的公网 SSH 访问
- [[Docker]]：容器化平台，远程开发的核心载体
## Connections
- [[Trae]] ← remote-ssh ← [[Ubuntu 2]]
- [[Docker]] ← hosts ← [[Ubuntu 2]]
- [[Docker Compose]] ← manages containers on ← [[Ubuntu 2]]
- [[Remote-SSH]] ← 公网穿透方案 ← [[Tailscale]] / [[frp]]
- [[Ubuntu 2]] ← 公网访问 ← [[frp]] (ubuntu2-ext: ubuntu2.ishenwei.online:60024)
## Contradictions
- 无已知冲突内容
---
title: "Trae远程开发部署指南"
type: source
tags: [remote-ssh, trae, ubuntu]
date: 2026-04-26
---
## Source File
- [[Vibe Coding/Trae远程开发部署指南]]
## Summary（用中文描述）
- 核心主题：使用 Trae IDE 通过 SSH 远程连接 Ubuntu 服务器进行 Docker 容器化项目的开发工作流配置
- 问题域：远程开发环境搭建、Docker 与 IDE 集成、内网穿透访问
- 方法/机制：SSH 免密登录 → Trae Remote-SSH 连接 → Docker 容器 Attach 或宿主机文件编辑 → Tailscale/FRP 公网访问
- 结论/价值：提供一套完整的"本地 UI + 远程服务器开发"解决方案，支持 Attach 容器调试和 docker-compose 编排两种模式
## Key Claims（用中文描述）
- Trae 原生支持 VS Code 插件生态，通过 Remote-SSH 插件可远程连接 Ubuntu 服务器
- 开发模式 A（Attach 容器）：适合调试，环境完全隔离，直接使用容器内语言环境
- 开发模式 B（宿主机文件 + Docker CLI）：适合编排 docker-compose.yml 和管理多容器配置
- 用户必须加入 docker 用户组才能让 Trae 的 Docker 插件正常工作
- 文件权限（UID/GID）问题会导致 Volume 挂载生成的 Build 文件归属 root，宿主机无法操作
## Key Quotes
> "开发环境的核心在于 Bind Mount（绑定挂载），实现代码修改实时生效" — 解释开发环境 docker-compose.yml 的设计原则
> "SSH 登录服务器执行：sudo usermod -aG docker $USER，必须注销并重新登录" — Docker 用户组配置关键步骤
> "不要直接暴露 SSH 端口，建议安装 Tailscale 或 Cloudflare Tunnel" — 内网穿透安全建议
## Key Concepts
- [[Remote-SSH]]：通过 SSH 协议将本地 IDE 连接到远程服务器，代码运行在服务器端但 UI 在本地
- [[Bind Mount]]：Docker Volume 挂载方式，将宿主机目录映射到容器内，实现代码修改实时生效
- [[Attach 容器]]：将 IDE 直接连接到正在运行的 Docker 容器内部进行开发调试的模式
- [[Docker 用户组]]：将用户加入 docker 组使其无需 sudo 即可运行 docker 命令
- [[SSH Config]]：SSH 客户端配置文件（~/.ssh/config），定义 Host 别名和连接参数
- [[SSH 免密登录]]：通过 ssh-copy-id 公钥分发实现无密码 SSH 连接
- [[Docker Compose 开发模式]]：使用 docker-compose.yml 编排开发环境，通过 volumes 实现源码挂载
## Key Entities
- [[Trae]]：国产 AI IDE，基于 VS Code，支持 Remote-SSH 远程开发，与 Cursor 功能类似
- [[Ubuntu 2]]：开发服务器（192.168.3.45），存放源码，运行带 Bind Mount 的开发容器
- [[Ubuntu 1]]：生产服务器（192.168.3.47），运行生产容器，通过 Docker 卷持久化数据
- [[ThinkBook]]：本地笔记本，作为 Trae UI 端连接远程服务器
- [[Tailscale]]：零配置 VPN 工具，可替代 FRP 提供安全的公网 SSH 访问
- [[Docker]]：容器化平台，远程开发的核心载体
## Connections
- [[Trae]] ← remote-ssh ← [[Ubuntu 2]]
- [[Docker]] ← hosts ← [[Ubuntu 2]]
- [[Docker Compose]] ← manages containers on ← [[Ubuntu 2]]
- [[Remote-SSH]] ← 公网穿透方案 ← [[Tailscale]] / [[frp]]
- [[Ubuntu 2]] ← 公网访问 ← [[frp]] (ubuntu2-ext: ubuntu2.ishenwei.online:60024)
## Contradictions
- 无已知冲突内容

113
wiki/sources/vibe-coding经验收集.md
View File

@@ -1,56 +1,57 @@
---
title: "Vibe Coding 经验收集"
type: source
tags: []
date: 2025-12-30
---
## Source File
- [[Vibe Coding/vibe coding经验收集.md]]
## Summary（用中文描述）
- 核心主题：Vibe Coding 实战经验与最佳实践的精选合集
- 问题域：AI 辅助编程的工作流优化、代码质量保证、团队协作模式
- 方法/机制：设计文档→伪代码→代码的递进式开发、多 AI 协作验证、文件注释标准化、代码可导航化
- 结论/价值：Vibe Coding 已从单纯提示词工程演变为系统性工程实践，强调验证而非理解、文档优于记忆
## Key Claims（用中文描述）
- **递进式开发工作流**：设计文档写细（含伪代码）→ AI 直出代码 → 另一 AI review → 跑测试用例 → AI 自动 commit+push，可一遍直出
- **System Prompt 优化效果**：针对 Gemini 3 Pro 的系统 prompt 优化可使多代理基准测试性能提升约 5%
- **点线体迭代方法**：逐级迭代（点→线→体），先用单个基础任务打磨，再基于此批量执行
- **文件头注释规范**：一段话描述代码作用、上下游链路，降低认知负载，参考 Claude skill 格式
- **代码验证优先**：未来软件工程核心不是"看懂代码"而是"验证代码按正确逻辑运行"，依赖自动化测试、静态分析、形式化验证
- **激励式提示词**：如"如果第一次就做得好，我会打赏100美元"可提升生成效果
- **CodeWeaver 工具**：将代码库编织成可导航的 Markdown 文档，简化 AI/ML 工具集成
## Key Quotes
> "我是把设计文档写得很细，包括service层的具体逻辑都用伪代码写了，然后交给AI，一遍直出，再用另一个AI review一遍，根据review意见修改一下，跑一下测试用例，让AI自己生成commit后push" — 需求→伪代码→代码递进工作流
> "代码最终会被转换成机器码执行，高级语言只是一层方便人类理解的抽象，重要的是验证程序的执行逻辑" — 代码验证哲学
> "请你根据我的要求，用 Three.js 创建一个实时交互的3D粒子系统，如果你第一次就做得好，我将会打赏你100美元的小费" — 激励式提示词示例
## Key Concepts
- [[Vibe Coding]]：使用 AI 辅助编程的实践方法论，强调人机协作而非纯自动生成
- [[Design-to-Code Workflow]]：设计文档→伪代码→代码的递进式开发流程
- [[Multi-AI Review]]：多 AI 协作验证，一个生成一个 review 的双人编程模式
- [[Code Documentation]]：文件头注释规范，降低 AI 和人类认知负载
- [[CodeWeaver]]：将代码库转换为可导航 Markdown 文档的工具
- [[Verification-First Engineering]]：验证优先于理解，强调自动化测试和形式化验证
- [[Iterative Scaling]]：点→线→体的逐级迭代，从单任务打磨到批量执行
## Key Entities
- [[CodeWeaver]]：GitHub 开源项目，将代码库编织成可导航 Markdown 文档的工具
## Connections
- [[Vibe Coding]] ← extends ← [[Agentic AI]]
- [[Design-to-Code Workflow]] ← refines ← [[Vibe Coding]]
- [[Multi-AI Review]] ← part_of ← [[Design-to-Code Workflow]]
- [[CodeWeaver]] ← enables ← [[Vibe Coding]]
## Contradictions
- 与传统软件工程方法冲突：
- 冲突点：传统方法强调"先理解代码再修改"，Vibe Coding 强调"验证而非理解"
- 当前观点：通过自动化测试和验证确保行为正确，降低人类理解代码的必要性
- 对方观点：人类开发者必须理解代码才能安全地进行修改和重构
```
---
title: "Vibe Coding 经验收集"
type: source
tags: []
date: 2025-12-30
---
## Source File
- [[Vibe Coding/vibe coding经验收集.md]]
## Summary（用中文描述）
- 核心主题：Vibe Coding 实战经验与最佳实践的精选合集
- 问题域：AI 辅助编程的工作流优化、代码质量保证、多 AI 协作模式、文档与导航化工具
- 方法/机制：设计文档→伪代码→代码的递进式开发、多 AI 协作验证、文件注释标准化、代码可导航化
- 结论/价值：Vibe Coding 已从单纯提示词工程演变为系统性工程实践，强调验证而非理解、文档优于记忆
## Key Claims（用中文描述）
- **递进式开发工作流**：设计文档写细（含伪代码）→ AI 直出代码 → 另一 AI review → 跑测试用例 → AI 自动 commit+push，可一遍直出
- **System Prompt 优化效果**：针对 Gemini 3 Pro 的系统 prompt 优化可使多代理基准测试性能提升约 5%
- **点线体迭代方法**：逐级迭代（点→线→体），先用单个基础任务打磨，再基于此批量执行
- **文件头注释规范**：一段话描述代码作用、上下游链路，降低认知负载，参考 Claude skill 格式
- **代码验证优先**：未来软件工程核心不是"看懂代码"而是"验证代码按正确逻辑运行"，依赖自动化测试、静态分析、形式化验证
- **激励式提示词**：如"如果第一次就做得好，我会打赏100美元"可提升生成效果
- **CodeWeaver 工具**：将代码库编织成可导航的 Markdown 文档，简化 AI/ML 工具集成
## Key Quotes
> "我是把设计文档写得很细，包括service层的具体逻辑都用伪代码写了，然后交给AI，一遍直出，再用另一个AI review一遍，根据review意见修改一下，跑一下测试用例，让AI自己生成commit后push" — 需求→伪代码→代码递进工作流
> "代码最终会被转换成机器码执行，高级语言只是一层方便人类理解的抽象，重要的是验证程序的执行逻辑" — 代码验证哲学
> "请你根据我的要求，用 Three.js 创建一个实时交互的3D粒子系统，如果你第一次就做得好，我将会打赏你100美元的小费" — 激励式提示词示例
> "CodeWeaver 将你的代码库编织成一个可导航的 Markdown 文档……所有代码都给你塞进代码块里，极大地简化了代码库的共享、文档化以及与 AI/ML 工具集成" — CodeWeaver 工具价值
## Key Concepts
- [[Vibe Coding]]：使用 AI 辅助编程的实践方法论，强调人机协作而非纯自动生成
- [[Design-to-Code Workflow]]：设计文档→伪代码→代码的递进式开发流程
- [[Multi-AI Review]]：多 AI 协作验证，一个生成一个 review 的双人编程模式
- [[Code Documentation]]：文件头注释规范，降低 AI 和人类认知负载
- [[Verification-First Engineering]]：验证优先于理解，强调自动化测试和形式化验证
- [[Iterative Scaling]]：点→线→体的逐级迭代，从单任务打磨到批量执行
- [[CodeWeaver]]：将代码库转换为可导航 Markdown 文档的工具
## Key Entities
- [[CodeWeaver]]：GitHub 开源项目，将代码库编织成可导航 Markdown 文档的工具
## Connections
- [[Vibe Coding]] ← extends ← [[Agentic AI]]
- [[Design-to-Code Workflow]] ← refines ← [[Vibe Coding]]
- [[Multi-AI Review]] ← part_of ← [[Design-to-Code Workflow]]
- [[CodeWeaver]] ← enables ← [[Vibe Coding]]
## Contradictions
- 与传统软件工程方法冲突：
- 冲突点：传统方法强调"先理解代码再修改"，Vibe Coding 强调"验证而非理解"
- 当前观点：通过自动化测试和验证确保行为正确，降低人类理解代码的必要性
- 对方观点：人类开发者必须理解代码才能安全地进行修改和重构

100
wiki/sources/vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南.md
View File

@@ -1,50 +1,50 @@
---
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
type: source
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
date: 2026-04-17
---
## Source File
- [[Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南]]
## Summary（用中文描述）
- 核心主题：在 Ubuntu Server 上非 root 用户（shenwei）安装 Node 20、Vibe-Kanban、OpenCode，并通过 pm2 进程管理，实现 AI 辅助编程工作流
- 问题域：Ubuntu Server 环境下的 AI Coding Agent 部署与长期运维
- 方法/机制：使用 nvm 管理 Node 版本、npm/npx 安装工具、pm2 管理进程生命周期、权限配置确保非 root 用户正常运行
- 结论/价值：完整记录了从零开始在 Ubuntu Server 上搭建 Vibe Coding 环境的全流程，含验证步骤和故障排查要点
## Key Claims（用中文描述）
- 使用 nvm 安装 Node 20 可确保版本兼容性和环境隔离
- pm2 能可靠管理 Vibe-Kanban 和 OpenCode Executor 进程并支持开机自启
- 权限配置（/var/tmp/vibe-kanban 和 ~/.vibe-kanban 归属 shenwei）是避免 I/O error 的关键
- 不应以 root 用户启动 OpenCode serve，避免权限问题
- Vibe-Kanban 会自动 spawn OpenCode executor（随机端口），无需手动固定端口
## Key Quotes
> "不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor" — 核心安全与架构原则
> "遇到 I/O error 时，通常是 executor 没启动或端口被占用" — 常见故障排查方向
> "pm2 只管理 vibe-kanban，executor 随进程一起管理" — 进程管理边界定义
## Key Concepts
- [[Vibe Coding]]：使用自然语言与 AI 编程工具协作的开发方式，Vibe-Kanban + OpenCode 是其代表性工具栈
- [[nvm]]（Node Version Manager）：Node.js 版本管理工具，通过 $NVM_DIR/$HOME/.nvm 安装，支持多版本共存和快速切换
- [[pm2]]：Node.js 进程管理器，支持进程守护、负载均衡、日志管理和开机自启（systemd）
- [[Node 20]]：LTS 版 Node.js，Vibe-Kanban 和 OpenCode 的推荐运行时版本
## Key Entities
- [[Vibe-Kanban]]：AI 编程辅助工具，提供看板界面与 OpenCode executor 集成，通过 npx vibe-kanban 启动
- [[OpenCode]]：开源 AI Coding CLI agent，与 Vibe-Kanban 配合使用，npm install -g opencode-ai 安装
- [[shenwei]]：文档作者，非 root 普通用户，用于在 Ubuntu Server 上运行 Vibe-Kanban 和 OpenCode
## Connections
- [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] ← extends ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
- [[Vibe Coding 经验收集]] ← related_to ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
- [[OpenCode]] ← depends_on ← [[Node 20]]
- [[Vibe-Kanban]] ← depends_on ← [[OpenCode]]
## Contradictions
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
- 冲突点：两篇文档都介绍 Ubuntu 上安装 OpenCode 和 Vibe-Kanban
- 当前观点：本篇更详细，覆盖完整 6 步流程、pm2 进程管理、权限配置和验证步骤
- 对方观点：前篇侧重基础安装步骤
---
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
type: source
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
date: 2026-04-17
---
## Source File
- [[Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南]]
## Summary（用中文描述）
- 核心主题：在 Ubuntu Server 上非 root 用户（shenwei）安装 Node 20、Vibe-Kanban、OpenCode，并通过 pm2 进程管理，实现 AI 辅助编程工作流
- 问题域：Ubuntu Server 环境下的 AI Coding Agent 部署与长期运维
- 方法/机制：使用 nvm 管理 Node 版本、npm/npx 安装工具、pm2 管理进程生命周期、权限配置确保非 root 用户正常运行
- 结论/价值：完整记录了从零开始在 Ubuntu Server 上搭建 Vibe Coding 环境的全流程，含验证步骤和故障排查要点
## Key Claims（用中文描述）
- 使用 nvm 安装 Node 20 可确保版本兼容性和环境隔离
- pm2 能可靠管理 Vibe-Kanban 和 OpenCode Executor 进程并支持开机自启
- 权限配置（/var/tmp/vibe-kanban 和 ~/.vibe-kanban 归属 shenwei）是避免 I/O error 的关键
- 不应以 root 用户启动 OpenCode serve，避免权限问题
- Vibe-Kanban 会自动 spawn OpenCode executor（随机端口），无需手动固定端口
## Key Quotes
> "不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor" — 核心安全与架构原则
> "遇到 I/O error 时，通常是 executor 没启动或端口被占用" — 常见故障排查方向
> "pm2 只管理 vibe-kanban，executor 随进程一起管理" — 进程管理边界定义
## Key Concepts
- [[Vibe Coding]]：使用自然语言与 AI 编程工具协作的开发方式，Vibe-Kanban + OpenCode 是其代表性工具栈
- [[nvm]]（Node Version Manager）：Node.js 版本管理工具，通过 $NVM_DIR/$HOME/.nvm 安装，支持多版本共存和快速切换
- [[pm2]]：Node.js 进程管理器，支持进程守护、负载均衡、日志管理和开机自启（systemd）
- [[Node 20]]：LTS 版 Node.js，Vibe-Kanban 和 OpenCode 的推荐运行时版本
## Key Entities
- [[Vibe-Kanban]]：AI 编程辅助工具，提供看板界面与 OpenCode executor 集成，通过 npx vibe-kanban 启动
- [[OpenCode]]：开源 AI Coding CLI agent，与 Vibe-Kanban 配合使用，npm install -g opencode-ai 安装
- [[shenwei]]：文档作者，非 root 普通用户，用于在 Ubuntu Server 上运行 Vibe-Kanban 和 OpenCode
## Connections
- [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] ← extends ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
- [[Vibe Coding 经验收集]] ← related_to ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
- [[OpenCode]] ← depends_on ← [[Node 20]]
- [[Vibe-Kanban]] ← depends_on ← [[OpenCode]]
## Contradictions
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
- 冲突点：两篇文档都介绍 Ubuntu 上安装 OpenCode 和 Vibe-Kanban
- 当前观点：本篇更详细，覆盖完整 6 步流程、pm2 进程管理、权限配置和验证步骤
- 对方观点：前篇侧重基础安装步骤

98
wiki/sources/在ubuntu上安装vibe-kanban.md
View File

@@ -1,47 +1,51 @@
---
title: "在Ubuntu上安装Vibe-Kanban"
type: source
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
sources: []
last_updated: 2026-04-22
---
## Source File
- [[Vibe Coding/在Ubuntu上安装Vibe-Kanban.md]]
## Summary（用中文描述）
- 核心主题：Vibe-Kanban 在 Ubuntu 服务器上的安装、配置与 PM2 进程管理
- 问题域：AI 编程 agent 的任务管理与自动化工作流
- 方法/机制：通过 npx 快速启动 + PM2 守护进程实现后台常驻，支持自定义 HOST/PORT 环境变量，Git worktree 隔离任务环境
- 结论/价值：提供一套完整的 Ubuntu Server 部署 Vibe-Kanban 生产级方案，突破浏览器限制实现远程访问
## Key Claims（用中文描述）
- Vibe-Kanban 默认以随机端口启动并自动打开浏览器，适合本地桌面使用
- 通过 `HOST=0.0.0.0 PORT=9999` 环境变量可固定端口并允许外部访问
- PM2 守护进程可实现进程常驻、自动重启和开机自启，适合服务器长期运行
- 每个任务运行在独立的 git worktree 中，防止多个 agent 相互干扰
- Vibe-Kanban 默认以 `--dangerously-skip-permissions` 模式运行，agent 可自主执行系统级操作
## Key Quotes
> "Vibe Kanban runs AI agents with —dangerously-skip-permissions/—yolo flags by default so they can work autonomously without constant approval prompts." — 安全机制说明
> "Each task runs in an isolated git worktree, preventing agents from interfering with each other." — 隔离机制说明
> "pm2 start \"HOST=0.0.0.0 PORT=9999 npx vibe-kanban\" --name vibe-kanban" — Ubuntu Server 生产部署命令
## Key Concepts
- [[Vibe Coding]]：通过自然语言与 AI coding agent 交互进行编程的工作方式
- [[Vibe-Kanban]]：AI agent 任务看板工具，基于 git worktree 隔离每个任务
- [[PM2]]：Node.js 进程管理器，提供进程守护、自动重启和开机自启功能
- [[Git Worktree]]：Git 多工作目录功能，Vibe-Kanban 用其实现任务隔离
## Key Entities
- [[BloopAI]]：Vibe-Kanban 的开发公司，项目托管于 github.com/BloopAI/vibe-kanban
## Connections
- [[Vibe Coding]] ← 应用场景 ← [[在Ubuntu上安装Vibe-Kanban]]
- [[PM2]] ← 进程管理 ← [[在Ubuntu上安装Vibe-Kanban]]
- [[OpenCode]] ← 互补工具 ← [[Vibe-Kanban]]（同为 supported coding agent）
## Contradictions
- 无明显冲突内容
---
title: "在Ubuntu上安装Vibe-Kanban"
type: source
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
date: 2026-06-04
---
## Source File
- [[Vibe Coding/在Ubuntu上安装Vibe-Kanban.md]]
## Summary（用中文描述）
- 核心主题：在 Ubuntu Server 上安装和配置 Vibe-Kanban AI 任务管理工具
- 问题域：AI 辅助编程工作流、任务管理工具的服务器端部署
- 方法/机制：通过 npx 直接运行 Vibe-Kanban，使用 PM2 进程管理器实现后台运行和开机自启
- 结论/价值：提供完整的 Vibe-Kanban 安装指南，包括可选的 GitHub CLI 和 MCP 集成
## Key Claims（用中文描述）
- Vibe Kanban 默认以 `--dangerously-skip-permissions/--yolo` 标志运行 AI 代理，允许自主操作无需持续审批
- 每个任务在隔离的 git worktree 中运行，防止代理之间相互干扰
- 使用 `PORT=8080 npx vibe-kanban` 可指定固定端口
- PM2 可以实现进程自动重启和开机自启，通过 `pm2 startup` 配置
- 使用 `HOST=0.0.0.0 PORT=9999 npx vibe-kanban` 可实现局域网访问
## Key Quotes
> "Vibe Kanban runs AI agents with —dangerously-skip-permissions/—yolo flags by default so they can work autonomously without constant approval prompts." — 安全机制说明
> "Each task runs in an isolated git worktree, preventing agents from interfering with each other." — 隔离机制说明
> "Vibe Kanban uses the GitHub CLI for creating pull requests. Ensure gh is installed and authenticated on your system." — GitHub 集成依赖
## Key Concepts
- [[PM2]]：Node.js 进程管理器，提供进程守护、自动重启和开机自启功能
- [[npx]]：Node.js 包执行工具，无需全局安装即可运行包
- [[Vibe Coding]]：AI 辅助编程范式，通过自然语言描述让 AI 代理完成编码任务
- [[MCP Server]]：Model Context Protocol 服务器，用于标准化 AI 代理与外部工具的集成
## Key Entities
- [[Vibe-Kanban]]：BloopAI 出品的 AI 任务管理看板工具，支持多种编码代理
- [[BloopAI]]：开发 Vibe-Kanban 的 AI 代码工具公司
- [[Node.js]]：Vibe-Kanban 运行所需的 JavaScript 运行时环境
- [[GitHub CLI]]：用于创建 Pull Request 的命令行工具，Vibe-Kanban 可选集成
## Connections
- [[Vibe-Kanban]] ← depends_on ← [[Node.js]]
- [[Vibe-Kanban]] ← extends ← [[GitHub CLI]]
- [[Vibe-Kanban]] ← optional_integration ← [[MCP Server]]
- [[PM2]] ← manages ← [[Vibe-Kanban]]
## Contradictions
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
- 冲突点：两者都介绍 Vibe-Kanban 安装，但侧重点不同
- 当前观点：本文档侧重官方标准安装流程和 PM2 进程管理
- 对方观点：[[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 侧重 OpenCode 集成配置

120
wiki/sources/在ubuntu上通过vps-内网反向代理实现域名访问内网穿透.md
View File

@@ -1,58 +1,62 @@
---
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
type: source
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
date: 2026-04-14
---
## Source File
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
## Summary（用中文描述）
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission 等）如何通过自定义域名从公网安全访问
- 方法/机制：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps（frp 服务端）和 Caddy → 内网主机运行 frpc（frp 客户端）将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS
- 结论/价值：完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程，并提供了 7 步系统化故障排查指南
## Key Claims（用中文描述）
- frp 内网穿透工具包含 frps（服务端）和 frpc（客户端），通过 TCP 反向隧道将内网端口暴露到公网 VPS
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
## Key Quotes
> "思路：Cloudflare DNS 指向 公网上的一台VPS，VPS 上运行 Caddy；内网主机通过 frp 将服务暴露到 VPS（本地 127.0.0.1 或某个端口），VPS 反向代理到该端口。" — 整体方案架构描述
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
> "⚠️ **重点提醒（安全性）**：SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
## Key Concepts
- [[内网穿透]]：通过公网服务器中转，使 NAT/防火墙后的内网服务可被外部访问的技术，本方案使用 frp 反向隧道实现
- [[反向代理]]：Caddy 作为反向代理，将公网 HTTPS 请求转发到本地 frp 映射端口，提供统一的 HTTPS 入口
- [[TCP隧道]]：frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道，支持非 HTTP 协议（如 SSH、MySQL）
- [[自动HTTPS]]：Caddy 内置 Let's Encrypt 证书自动申请和续期，无需手动管理 SSL 证书
- [[DNS A记录]]：Cloudflare DNS 配置，将子域名（如 nas.ishenwei.online）指向 VPS 公网 IP
## Key Entities
- [[RackNerd VPS]]：VPS 提供商（192.227.222.142），托管 frps 服务端和 Caddy 反向代理，作为内网穿透的公网中转站
- [[Synology NAS DS718]]：内网 NAS 设备（192.168.3.17），运行 frpc 客户端，通过 frp 暴露 NAS 服务（5000端口 → VPS 15000）
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问
- [[Cloudflare]]：域名 DNS 托管服务商，通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
## Connections
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（本文是该概览中内网穿透架构的详细展开）
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（FRP 安装是该方案的前置步骤）
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Mac Mini FRP 客户端配置参考）
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Ubuntu Server 24.04 是本方案的目标操作系统）
## Contradictions
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点：
- 冲突点：监控方案中是否包含完整的公网访问配置
- 当前观点：本文提供完整公网域名访问方案，包含 HTTPS 和 SSH 穿透的详细配置
- 对方观点：监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置，未展开公网访问细节
- 建议：在监控方案中补充指向本文内网穿透配置的外链，实现监控方案 + 公网访问的完整闭环
---
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
type: source
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
date: 2026-05-28
---
## Source File
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
## Summary（用中文描述）
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission、SSH 等）如何通过自定义域名从公网安全访问
- 方法/机制：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps（frp 服务端）和 Caddy → 内网主机运行 frpc（frp 客户端）将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS
- 结论/价值：完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程，并提供了 7 步系统化故障排查指南
## Key Claims（用中文描述）
- frp 内网穿透工具包含 frps（服务端）和 frpc（客户端），通过 TCP 反向隧道将内网端口暴露到公网 VPS，支持 NAT 穿透和自动重连
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现（`type = tcp`，`remote_port = 60022`）
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
- frp 连接失败的主要原因包括：端口被占用/token 不一致/防火墙拦截/Caddy 误 proxy TCP 端口
- 通过 `ssh -p 60022 user@ubuntu1.ishenwei.online` 可从公网 SSH 到内网 Ubuntu（需 DNS A 记录 + frpc 配置）
## Key Quotes
> "思路：Cloudflare DNS 指向公网上的一台VPS，VPS 上运行 Caddy；内网主机通过 frp 将服务暴露到 VPS（本地 127.0.0.1 或某个端口），VPS 反向代理到该端口。" — 整体方案架构描述
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
> "⚠️ **重点提醒（安全性）**：SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
> "很多人遇到的问题是：他们编辑了 `/opt/frp/frps.ini`，但 systemd service 其实加载另一个路径，例如 `/etc/frp/frps.ini`。" — frps 配置加载路径的常见陷阱
## Key Concepts
- [[内网穿透]]：通过公网服务器中转，使 NAT/防火墙后的内网服务可被外部访问的技术，本方案使用 frp 反向隧道实现
- [[反向代理]]：Caddy 作为反向代理，将公网 HTTPS 请求转发到本地 frp 映射端口，提供统一的 HTTPS 入口
- [[TCP隧道]]：frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道，支持非 HTTP 协议（如 SSH、MySQL）
- [[自动HTTPS]]：Caddy 内置 Let's Encrypt 证书自动申请和续期，无需手动管理 SSL 证书
- [[DNS A记录]]：Cloudflare DNS 配置，将子域名（如 nas.ishenwei.online）指向 VPS 公网 IP
## Key Entities
- [[RackNerd VPS]]：VPS 提供商（192.227.222.142），托管 frps 服务端和 Caddy 反向代理，作为内网穿透的公网中转站
- [[Synology NAS DS718]]：内网 NAS 设备（192.168.3.17），运行 frpc 客户端，通过 frp 暴露 NAS 服务（5000端口 → VPS 15000）、Navidrome、Calibre、WebDAV、Miniflux、Zipline、MySQL、SSH 等多个服务
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0；通过 token 认证确保连接安全
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问；支持 `caddy validate` 命令验证配置语法
- [[Cloudflare]]：域名 DNS 托管服务商，通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
## Connections
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（本文是该概览中内网穿透架构的详细展开）
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（FRP 安装是该方案的前置步骤）
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Mac Mini FRP 客户端配置参考）
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Ubuntu Server 24.04 是本方案的目标操作系统）
## Contradictions
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点：
- 冲突点：监控方案中是否包含完整的公网访问配置
- 当前观点：本文提供完整公网域名访问方案，包含 HTTPS 和 SSH 穿透的详细配置
- 对方观点：监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置，未展开公网访问细节
- 建议：在监控方案中补充指向本文内网穿透配置的外链，实现监控方案 + 公网访问的完整闭环

84
wiki/sources/如何传输docker-images-并且在另一个docker安装.md
View File

@@ -1,40 +1,44 @@
---
title: "如何传输Docker images 并且在另一个Docker安装"
type: source
tags: []
sources: []
last_updated: 2026-04-22
---
## Source File
- [[Home Office/如何传输Docker images 并且在另一个Docker安装]]
## Summary（用中文描述）
- 核心主题：Docker 镜像在多台机器之间的离线传输方法
- 问题域：内网环境或无 Registry 情况下的镜像迁移
- 方法/机制：三种方案——`docker save/load`（tar 包）、镜像仓库推送拉取、`ctr` 直接复制
- 结论/价值：提供了完整的离线迁移工具链，适合家庭服务器集群或隔离网络环境
## Key Claims（用中文描述）
- `docker save` 可将镜像导出为 tar 文件，`docker load` 可在目标机器导入，无需镜像仓库中介
- `docker push/pull` 适合有镜像仓库（如 Docker Hub、私有 Harbor）的场景
- `ctr -n k8s.io images import` 可直接导入镜像包，绕过 Docker 工具链
- 多架构镜像需注意 `--platform` 参数指定平台，避免在不同架构机器间混用
## Key Quotes
> "把镜像 save 成 tar 包后拷贝到新机器再 load 进去" — 最通用的离线迁移方案，适用于无网络的隔离环境
## Key Concepts
- [[Docker-Image]]：容器镜像，Docker 应用打包的标准格式
- [[Docker-Save]]：将镜像导出为 tar 归档文件
- [[Docker-Load]]：从 tar 文件加载镜像到本地 Docker 引擎
- [[Docker Registry]]：镜像仓库，用于存储和分发镜像（Docker Hub / Harbor / 私有 Registry）
## Key Entities
- [[Docker]]：容器化平台，本文档的操作环境
## Connections
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← extends ← [[如何传输Docker images 并且在另一个Docker安装]]
## Contradictions
- （无已知冲突）
---
title: "如何传输Docker images 并且在另一个Docker安装"
type: source
tags: []
sources: []
last_updated: 2026-05-30
---
## Source File
- [[Home Office/如何传输Docker images 并且在另一个Docker安装]]
## Summary（用中文描述）
- 核心主题：Docker 镜像在两台 Docker 环境之间的离线传输方法
- 问题域：无镜像仓库的内网环境或离线场景下的镜像迁移
- 方法/机制：`docker save` 导出为 tar → 上传目标机器 → `docker load` 导入
- 结论/价值：提供了无需镜像仓库的离线迁移标准流程，适用于家庭 NAS 与工作设备之间的镜像同步
## Key Claims（用中文描述）
- `docker pull` 从远程仓库拉取镜像到本地 Docker 环境
- `docker save -o <output.tar> <image>` 将镜像导出为 tar 归档文件，可离线拷贝
- `docker load < <input.tar` 在目标机器从 tar 文件加载镜像，无需网络连接
- 上传 tar 包到目标机器后，可在 Container Manager 等 Web UI 中直接看到已导入的镜像
## Key Quotes
> "cd 到 xiaoya.tar 存放的路径之后运行以下命令 docker load < xiaoya.tar" — 在 Synology NAS 上通过 SSH 执行镜像导入
> "再进入 NAS 的 Container Manager 界面后在 image 里就可以看到 xiaoya/alist 这个 image 了" — 验证镜像导入成功的方式
## Key Concepts
- [[Docker-Image]]：容器镜像，Docker 应用打包的标准格式
- [[Docker-Save]]：`docker save` 命令将镜像导出为 tar 归档文件
- [[Docker-Load]]：`docker load` 命令从 tar 文件加载镜像到本地 Docker 引擎
- [[Docker-Registry]]：镜像仓库（本文未使用，但提及作为替代方案）
## Key Entities
- [[Docker]]：容器化平台，本文的操作基础环境
- [[Synology-NAS]]：群晖 NAS，运行 Docker（Container Manager），本文镜像迁移的目标端
- [[Alist]]：开源网盘聚合工具（xiaoyaliu/alist），本文操作的示例镜像
## Connections
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← extends ← [[如何传输Docker images 并且在另一个Docker安装]]
- [[在Synology NAS上安装CloudDrive2]] ← related_to ← [[如何传输Docker images 并且在另一个Docker安装]]（同为 Synology NAS Docker 操作场景）
## Contradictions
- （无已知冲突）

108
wiki/sources/如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹.md
View File

@@ -1,59 +1,49 @@
---
title: "如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹"
type: source
tags: [nas, nfs, synology, ubuntu]
date: 2025-12-29
---
## Source File
- [[raw/Home Office/如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹.md]]
## Summary (用中文描述)
- 核心主题：在 Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹，实现服务器到 NAS 的自动化备份存储
- 问题域：Samba 挂载丢失 Linux 文件权限信息导致 Docker 卷恢复失败；NFS 相比 Samba 完美保留文件所有权、性能更强
- 方法/机制：
1. Synology NAS DSM 控制面板 → 共享文件夹 → NFS 权限配置（关键：Squash 设为"映射所有用户为 admin"）
2. Ubuntu 安装 nfs-common，mount -t nfs 挂载
3. /etc/fstab 写入永久挂载配置（关键参数：_netdev、timeo=900、retrans=5）
4. sudo mount -a 测试后再重启
5. 备份脚本前加挂载点检查防止数据写入本地磁盘
6. systemctl enable remote-fs.target 解决 nfs-common 启动慢问题
- 结论/价值：NFS 是 Linux 服务器备份到 NAS 的最佳方案，配合 rsync + Cron 实现全自动化备份
## Key Claims (用中文描述)
- **NFS 相比 Samba 的核心优势**：NFS 原生保留 Linux 文件所有权信息，避免 Docker 卷恢复时的权限报错
- **Synology NFS Squash 关键配置**：必须选择"映射所有用户为 admin"，否则 Ubuntu 端 root 发起的备份请求会在 NAS 端遭遇权限校验失败
- **fstab _netdev 参数的作用**：告知系统这是网络设备，等网络服务完全启动后再尝试挂载，防止开机卡死
- **永远不要直接重启测试**：/etc/fstab 写错会导致系统无法正常启动，必须先用 sudo mount -a 验证
## Key Quotes
> "NFS 会完美保留文件所有权信息，Samba 则会丢失 Linux 的文件所有权，导致恢复 Docker 卷时权限报错。" — NFS 相比 Samba 的优势说明
> "_netdev: **关键参数**。告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — fstab 参数解析
> "千万不要直接重启！如果 `/etc/fstab` 写错了，系统可能无法正常启动。" — 配置验证警告
> "如果在执行了上述操作后重启依然不生效，通常是因为 Ubuntu 的 `nfs-common` 服务启动慢于 `mount -a` 的执行。" — nfs-common 启动时序问题
## Key Concepts
- [[NFS]]：Network File System，Linux/Unix 系统的网络文件系统协议，Ubuntu 备份到 NAS 的推荐协议
- [[永久挂载]]：通过 /etc/fstab 配置实现开机自动挂载，配合 _netdev 参数确保网络设备就绪后再挂载
- [[挂载点检查]]：备份脚本执行前的安全验证，使用 mountpoint -q 命令检查挂载点有效性
- [[NFS网络备份]]：通过 NFS 协议将备份数据存储到网络存储设备（与本文 Ubuntu rsync 备份场景互补）
## Key Entities
- [[Synology NAS DS718]]：群晖 NAS 设备（192.168.3.17），通过 DSM 控制面板配置 NFS 权限，作为 Ubuntu Server 的备份存储目标
- [[Ubuntu Server]]：Linux 服务器发行版，运行 rsync 备份脚本，将数据写入 NAS 的 NFS 挂载点
- [[rsync]]：增量文件同步工具，与 NFS 永久挂载配合实现 Ubuntu Server 到 NAS 的自动化日常备份
## Connections
- [[Ubuntu Server]] ← runs ← [[rsync]] (备份工具)
- [[rsync]] ← writes to ← [[永久挂载]] (NFS 挂载点 /mnt/nas_backup)
- [[永久挂载]] ← depends on ← [[NFS]] (NFS 协议)
- [[Synology NAS DS718]] ← serves ← [[NFS]] (NFS 服务端)
- [[挂载点检查]] ← guards ← [[rsync]] (备份安全前置检查)
- [[Cron定时任务]] ← schedules ← [[rsync]] (定时触发备份)
- [[NFS网络备份]] ← uses ← [[NFS]] (两者同属 NFS 存储应用场景)
## Contradictions
- 无冲突
---
title: "如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹"
type: source
tags: [nas, nfs, synology, ubuntu]
date: 2025-12-29
---
## Source File
- [[Home Office/如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹.md]]
## Summary（用中文描述）
- 核心主题：通过 NFS 协议将 Synology NAS 的共享文件夹挂载到 Ubuntu Server，实现永久性网络存储挂载
- 问题域：Ubuntu 服务器与 Synology NAS 之间的网络存储集成，适用于备份场景
- 方法/机制：
- Synology DSM 控制面板配置 NFS 权限（IP白名单、Squash 映射为 admin、_netdev 参数）
- Ubuntu 端安装 `nfs-common`，使用 `mount -t nfs` 临时挂载
- 通过 `/etc/fstab` 配置永久挂载，含 `timeo=900`、`retrans=5`、`_netdev` 等参数
- rsync 脚本中加入挂载点检测保护，防止 NAS 掉线时数据写入本地
- 结论/价值：相比 Samba，NFS 能保留 Linux 文件权限（uid/gid），避免 Docker 卷恢复时的权限报错，是 Linux 服务器挂载 NAS 的标准方案
## Key Claims（用中文描述）
- Synology NAS 的 Squash 设置"映射所有用户为 admin"，可将 Ubuntu 端 root 请求在 NAS 端以 admin 身份执行，绕过 Linux 权限校验
- `/etc/fstab` 中的 `_netdev` 参数可防止开机时网络未就绪导致系统挂起
- NFS 相比 Samba 在处理 Docker 配置文件（大量小文件）时性能更强
- rsync 脚本中加入挂载点检查，可在 NAS 掉线时主动终止备份，防止数据写入本地目录
## Key Quotes
> "NFS 能完美保留（Linux 文件所有权信息），而 Samba 会丢失，导致恢复 Docker 卷时权限报错" — NFS 相对 Samba 的核心优势说明
> "_netdev：告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死" — fstab 中 _netdev 参数的关键作用
> "如果 `sudo mount -a` 没有报错，且 `df` 能看到 NAS 空间，那么以后重启服务器，挂载都会自动生效" — 永久挂载验证方法
## Key Concepts
- [[NFS]]：Network File System，Linux/Unix 标准的网络文件系统协议，支持保留原始 uid/gid 权限
- [[/etc/fstab]]：Linux 文件系统表，用于配置开机自动挂载；`_netdev` 参数确保网络设备就绪后再挂载
- [[rsync]]：增量备份工具，可配合 NFS 挂载点实现服务器到 NAS 的自动化备份
- [[Squash]]：NFS 权限设置中的用户映射选项，"映射所有用户为 admin" 可简化跨平台权限问题
## Key Entities
- [[Synology NAS]]：群晖网络附加存储设备，提供 DSM 管理界面和 NFS 共享服务；本文示例 IP：192.168.3.17，挂载路径：/volume2/backup
- [[Ubuntu Server]]：Linux 服务器操作系统，本文版本为 Ubuntu 24.04；示例 IP：192.168.3.47，挂载点：/mnt/nas_backup
## Connections
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← depends_on ← [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]]（rsync 备份依赖 NFS 挂载的 NAS 存储）
- [[群晖NAS科学上网方法]] ← related ← [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]]（同为 Synology NAS 相关配置文档）
## Contradictions
- 无已知冲突

157
wiki/sources/家庭网络环境概览_2026-04-03.md
View File

@@ -1,101 +1,56 @@
---
title: "家庭网络环境概览"
type: source
tags: [home-office, nas, synology, ubuntu, vps]
date: 2026-04-03
---
## Source File
- [[raw/Home Office/家庭网络环境概览_2026-04-03.md]]
## Summary (用中文描述)
- **核心主题**：星曜家庭网络基础设施的完整架构图谱，涵盖5大节点（1个公网VPS + 1个Mac Mini + 1个Synology NAS + 2个Ubuntu Server），近50个Docker应用服务的部署现状、端口映射与公网访问方案。
- **问题域**：如何将分散在多个物理位置和内网的服务，通过FRP内网穿透 + Caddy反向代理 + Cloudflare DNS，实现统一的HTTPS公网访问？
- **方法/机制**：
- **FRP**（frps/frpc）：在内网各节点部署frpc客户端，公网VPS运行frps服务端，通过TCP隧道将内网端口映射到公网；
- **Caddy**：在公网VPS上运行，自动申请Let's Encrypt证书，根据域名将请求反向代理到对应的FRP映射端口；
- **Cloudflare**：托管 ishenwei.online 域名的DNS解析，将子域名A记录指向VPS公网IP；
- **Docker Compose**：各节点上的服务通过Docker Compose管理，独立部署、版本隔离。
- **结论/价值**：该架构实现了"零静态IP依赖"的公网访问方案，所有内网服务均可通过 *.ishenwei.online 子域名从公网访问，同时保持了内网服务的隐私性和低带宽成本。
## Key Claims (用中文描述)
- VPS（192.227.222.142）通过FRP Server（端口7000）+ Caddy Web服务器，为全网内网服务提供统一的HTTPS公网入口。
- Mac Mini M4（192.168.3.189）作为主控节点，运行OpenClaw AI助手框架、vaultwarden密码管理器及STQ项目管理系统。
- Synology NAS DS718（192.168.3.17）托管了媒体服务（Jellyfin/Navidrome）、监控栈（Prometheus/Alertmanager/node_exporter）、密码管理（vaultwarden）、云盘挂载（CloudDrive2）等核心应用。
- Ubuntu Server 1（192.168.3.47）承担监控可视化（Grafana/Superset）、个人导航（Homarr）、BT下载（Transmission）等面向公网的服务。
- Ubuntu Server 2（192.168.3.45）运行n8n工作流自动化、Gitea自建Git服务及TikTok项目管理系统（DEV环境）。
- 科学上网代理（SOCKS5: 10808）在Mac mini、ubuntu1、ubuntu2上均正常，仅NAS（端口20170）仅本机监听。
## Key Quotes
> "Caddy — 现代化 Web 服务器，自带 HTTPS 自动化证书申请，常作为前置反向代理处理业务流量。" — 域名映射表说明
> "FRP Server — 高性能内网穿透服务端（frps），负责将内网 NAS 或本地开发环境的服务暴露至公网访问。端口 7000" — VPS应用说明
> "n8n 已迁移至 Ubuntu2，Mac Mini 不再暴露 n8n 端口" — Mac Mini FRP配置说明
## Key Concepts
- [[内网穿透]]：通过FRP反向隧道将内网服务暴露至公网访问的完整方案，包含frps（服务端）和frpc（客户端）两个组件。
- [[反向代理]]：通过Caddy根据域名将公网HTTPS请求反向代理到内网FRP映射端口的机制。
- [[HTTPS自动化证书]]：Caddy自动申请和管理Let's Encrypt SSL证书的机制。
- [[Docker Compose]]：各节点服务通过YAML文件声明式定义和管理的多容器编排工具。
- [[时序数据库]]：Prometheus作为监控数据的时序数据库，用于采集和存储node_exporter/cAdvisor/blackbox_exporter的指标。
- [[告警管理]]：Alertmanager处理Prometheus告警的分组、抑制、静默和多通道路由。
- [[SOCKS5代理]]：本地科学上网代理协议，监听127.0.0.1:10808。
- [[DNS托管]]：Cloudflare免费提供域名DNS解析服务，含CDN和SSL。
## Key Entities
- [[RackNerd]]：VPS提供商，托管公网VPS1（192.227.222.142），提供frps和Caddy服务。
- [[Mac Mini M4]]：Apple Silicon Mac Mini作为家庭服务器主控节点（192.168.3.189），运行OpenClaw、vaultwarden、STQ项目等应用。
- [[Synology NAS DS718]]：群晖NAS设备（192.168.3.17），运行DSM管理界面及Calibre/MinIO/Zipline/Navidrome/Jellyfin等Docker应用。
- [[Ubuntu Server]]：两个内网Ubuntu服务器节点（Ubuntu1: 192.168.3.47, Ubuntu2: 192.168.3.45），承担监控/导航/下载/工作流/Git等服务。
- [[Caddy]]：公网VPS上的自动HTTPS反向代理服务器，绑定*.ishenwei.online域名。
- [[frp]]：内网穿透工具（frps/frpc v0.65.0），实现内网端口到公网端口的TCP隧道映射。
- [[Prometheus]]：时序数据库监控系统，在NAS和Ubuntu1上运行，采集node_exporter/cAdvisor/blackbox_exporter指标。
- [[Grafana]]：监控可视化平台（Ubuntu1:13000），通过Dashboard ID导入官方模板。
- [[vaultwarden]]：轻量级Bitwarden密码管理器服务端，在Mac Mini和NAS上均有部署。
- [[Jellyfin]]：开源媒体服务器，在NAS上运行（端口8096），公网通过FRP+Caddy访问。
- [[Navidrome]]：开源音乐流媒体服务器，Subsonic API兼容，在NAS上运行（端口4533）。
- [[Transmission]]：BT下载客户端，在Ubuntu1上运行（端口9091），公网通过FRP+Caddy访问。
- [[n8n]]：工作流自动化平台，已从Mac Mini迁移至Ubuntu2（端口5678），公网通过FRP+Caddy访问。
- [[Portainer]]：Docker容器可视化管理界面，在NAS、Ubuntu1、Ubuntu2上均有部署。
- [[Homarr]]：个人导航页面/仪表板，在Ubuntu1上运行（端口7575），公网通过FRP+Caddy访问。
- [[Apache Superset]]：开源BI平台，在Ubuntu1上运行（端口8777），公网通过FRP+Caddy访问。
- [[Zipline]]：自托管图床应用，在NAS上运行（端口3333），后端为PostgreSQL。
- [[MinIO]]：S3兼容对象存储，在NAS上运行（端口9001），作为Zipline的存储后端。
- [[Cloudflare]]：DNS托管服务商，免费提供CDN和SSL证书，托管ishenwei.online域名。
- [[OpenClaw]]：AI助手框架，在Mac Mini上运行（端口8080），星曜的主要运行环境。
- [[Calibre]]：电子书库管理工具，在NAS上运行（端口8083），公网通过FRP+Caddy访问。
- [[v2rayA]]：V2Ray图形化代理客户端，在NAS上运行（端口2017），SOCKS5仅本机监听。
- [[CloudDrive2]]：多云盘挂载工具，在NAS上运行（端口19798），支持阿里云盘等。
- [[Alertmanager]]：Prometheus告警分发组件，在NAS和Ubuntu1上运行（端口9093）。
- [[node_exporter]]：Prometheus官方主机指标采集器，以host network模式运行。
- [[cAdvisor]]：Google开源容器资源监控工具，挂载Docker socket采集容器级指标。
- [[blackbox_exporter]]：Prometheus官方黑盒探测exporter，支持HTTP/TCP/ICMP/DNS/TLS探测。
- [[nginx-proxy-manager]]：反向代理管理工具，在Ubuntu1上运行（端口81）。
- [[Gitea]]：自建Git服务，在Ubuntu2上运行（端口3000）。
- [[Draw.io]]：在线图表编辑器，在Ubuntu2上运行（端口8085），公网通过FRP+Caddy访问。
- [[it-tools]]：开源开发者工具集合，在Ubuntu1和Ubuntu2上运行（端口8999），提供URL编解码、UUID生成、哈希计算等100+工具。
## Connections
- [[Caddy]] ← 反向代理 ← [[frp]]（Caddy将HTTPS请求代理到FRP映射端口）
- [[Cloudflare]] ← DNS托管 ← [[Caddy]]（DNS A记录指向VPS公网IP）
- [[Prometheus]] ← 指标采集 ← [[node_exporter]] + [[cAdvisor]] + [[blackbox_exporter]]
- [[Grafana]] ← 数据源 ← [[Prometheus]]（Grafana消费Prometheus指标）
- [[Alertmanager]] ← 告警路由 ← [[Prometheus]]（Prometheus触发告警后发送至Alertmanager）
- [[Zipline]] ← 存储后端 ← [[MinIO]]（Zipline使用MinIO存储图片）
- [[Zipline]] ← 数据库 ← [[PostgreSQL]]（NAS上zipline_postgres容器）
- [[Jellyfin]] ← 下载来源 ← [[Transmission]]（下载→整理→播放工作流）
- [[Navidrome]] ← 同 ← [[Jellyfin]]（均为媒体服务，下载→播放工作流）
- [[OpenClaw]] ← 运行平台 ← [[Mac Mini M4]]（OpenClaw的主要运行环境）
- [[n8n]] ← 数据存储 ← [[PostgreSQL]]（Ubuntu2上n8n_postgres容器）
- [[Cloudflare]] ← DNS ← [[RackNerd]]（VPS IP: 192.227.222.142）
- [[frp]] ← 客户端节点 ← [[Mac Mini M4]] + [[Synology NAS DS718]] + [[Ubuntu Server 1]] + [[Ubuntu Server 2]]（4个frpc客户端）
- [[frp]] ← 服务端 ← [[RackNerd]]（VPS运行frps服务端）
- [[Docker Compose]] ← 部署载体 ← [[Prometheus]] + [[Grafana]] + [[Jellyfin]] + [[Navidrome]] + [[n8n]] + [[Zipline]] + [[MinIO]] + [[v2rayA]] + [[vaultwarden]] + [[Portainer]] + [[Homarr]] + [[Apache Superset]] + [[Gitea]] + [[it-tools]]（所有Docker应用均通过Docker Compose部署）
## Contradictions
- 与 [[ubuntu-server科学上网]] 冲突：
- **冲突点**：NAS上v2rayA的SOCKS5代理（端口20170）状态为"仅本机监听"，而ubuntu-server科学上网方案强调Docker Daemon也需要代理配置。
- **当前观点**：v2rayA在NAS上运行但仅本机监听，Docker pull仍可能受限。
- **对方观点**：Ubuntu Server可通过ProxyChains/Docker Daemon Proxy显式配置代理，覆盖终端和Docker Daemon两层。
- **Resolution**：v2rayA仅覆盖NAS本身，NAS上Docker pull可能还需配置Docker Daemon Proxy（参考[[群晖NAS科学上网]]方案）。
---
title: "家庭网络环境概览"
type: source
tags: [home-office, nas, synology, ubuntu, vps, home-lab]
date: 2026-04-03
---
## Source File
- [[Home Office/家庭网络环境概览_2026-04-03.md]]
## Summary（用中文描述）
- 核心主题：个人家庭网络的完整基础设施架构文档，记录了从公网VPS到内网各服务器的完整拓扑、应用部署和域名映射
- 问题域：家庭服务器集群的规划、部署与公网访问方案；多设备、多服务的管理与监控
- 方法/机制：通过 FRP 内网穿透 + Caddy 反向代理实现公网访问；使用 Docker 容器化部署各类服务；Cloudflare DNS 托管
- 结论/价值：构建了一套完整的自托管服务生态，覆盖开发、媒体、监控、自动化等多个场景
## Key Claims（用中文描述）
- FRP（Fast Reverse Proxy）通过公网VPS中转，实现了内网设备的无公网IP公网访问
- Caddy 作为前置反向代理，通过 *.ishenwei.online 子域名自动申请 HTTPS 证书
- Synology NAS DS718 是家庭媒体中心，运行 Jellyfin、Navidrome、Calibre-web 等多媒体服务
- Ubuntu1 运行 Grafana + Prometheus 监控栈，收集所有服务器的指标数据
- Ubuntu2 承载 n8n 工作流自动化平台和 Gitea 自建 Git 服务
- Mac Mini M4 作为主控节点，运行 OpenClaw AI 助手框架及 STQ 项目管理系统
## Key Quotes
> "Caddy — 现代化 Web 服务器，自带 HTTPS 自动化证书申请，常作为前置反向代理处理业务流量" — 文档中定义
> "FRP Server — 高性能内网穿透服务端（frps），负责将内网 NAS 或本地开发环境的服务暴露至公网访问" — 文档中定义
> "域名 DNS 托管于 Cloudflare，提供免费 CDN 与 SSL 证书" — 基础设施说明
## Key Concepts
- [[FRP 内网穿透]]：通过 Fast Reverse Proxy 在公网VPS和内网设备之间建立反向隧道，实现内网服务公网访问
- [[Caddy 反向代理]]：现代化 Web 服务器，自动管理 HTTPS 证书，通过子域名路由内网服务
- [[Docker 容器化]]：所有应用服务均以 Docker 方式部署，便于管理和迁移
- [[Home Lab]]：个人自托管服务器集群，包含媒体、监控、开发、自动化等多种服务
- [[Prometheus 监控]]：使用 Prometheus + Grafana + Node Exporter + cAdvisor 构建完整监控体系
## Key Entities
- [[RackNerd VPS]]：公网服务器（IP: 192.227.222.142），运行 Caddy 和 FRP Server，是内网穿透的核心节点
- [[Mac Mini M4]]：家庭主控节点（内网IP: 192.168.3.189），运行 OpenClaw AI助手、vaultwarden、STQ项目管理系统
- [[Synology NAS DS718]]：家庭媒体中心（内网IP: 192.168.3.17），运行 Jellyfin、Navidrome、Calibre等多媒体服务
- [[Ubuntu1]]：监控与开发服务器（内网IP: 192.168.3.47），运行 Grafana、Superset、Homarr导航面板
- [[Ubuntu2]]：自动化与代码服务器（内网IP: 192.168.3.45），运行 n8n 工作流自动化、Gitea 自建Git服务
- [[Cloudflare]]：提供免费DNS托管、CDN加速和SSL证书
## Connections
- [[RackNerd VPS]] ← provides_public_ip ← [[Home Lab]]
- [[Mac Mini M4]] ← hosts ← [[OpenClaw]]
- [[Synology NAS DS718]] ← hosts ← [[Jellyfin]]
- [[Synology NAS DS718]] ← hosts ← [[Navidrome]]
- [[Ubuntu1]] ← hosts ← [[Grafana]]
- [[Ubuntu2]] ← hosts ← [[n8n 工作流自动化]]
- [[Home Lab]] ← uses ← [[FRP 内网穿透]]
- [[Home Lab]] ← uses ← [[Caddy 反向代理]]
## Contradictions
- 与其他文档暂无已知冲突

132
wiki/sources/开发经验与项目规范整理文档.md
View File

@@ -1,62 +1,70 @@
---
title: "开发经验与项目规范整理文档"
type: source
tags: [vibe-coding, software-engineering, best-practices, coding-standards]
sources: []
last_updated: 2025-12-30
---
## Source File
- [[Vibe Coding/开发经验与项目规范整理文档]]
## Summary（用中文描述）
- 核心主题：Vibe Coding 环境下的开发经验与项目规范最佳实践，涵盖编码规范、系统架构原则、程序设计思想及基础设施（微服务、Redis、消息队列）
- 问题域：如何建立可持续维护的 AI 辅助开发项目；如何制定团队编码规范；如何通过规范提升 AI 生成的代码质量
- 方法/机制：
- 变量名维护方案（统一变量索引文件）
- 文件结构与命名规范（小写英文 + 下划线/小驼峰）
- 编码规范（单一职责、DRY、模块化）
- 系统架构原则（先梳理架构、小步迭代）
- 程序设计核心思想（从问题出发、清晰命名、测试优先）
- 微服务拆分原则（独立开发/部署/扩容）
- Redis 缓存策略（提升读性能、降低 DB 压力）
- 消息队列异步通信（解耦、削峰、异步任务）
- 结论/价值：为 AI 辅助开发项目提供系统化规范框架，强调从问题出发而非代码出发，提升代码可维护性和团队协作效率
## Key Claims（用中文描述）
- 统一变量索引文件能降低命名冲突和语义不清晰带来的风险
- 编码规范中的「消费端 → 生产端 → 状态 → 变换」模型能清晰划分系统行为边界
- 系统开发应遵循「先理解需求 → 保持简单 → 测试驱动 → 小步迭代」的严谨流程
- 编程第一步永远是「你要解决什么问题」，而非直接写代码
- 注释解释「为什么」，而非「怎么做」
## Key Quotes
> "编程的第一步永远是：你要解决什么问题？" — 从问题出发而非代码
> "你写的代码是给别人理解的，不是来炫技的。" — 代码可读性优先
> "注释解释'为什么'，不是'怎么做'。" — 合理注释原则
> "未测试的代码迟早会出问题。" — 测试优先
## Key Concepts
- [[单一职责原则]]：每个文件、类、函数应只负责一件事
- [[DRY原则]]：Don't Repeat Yourself，避免重复代码，提炼公共逻辑
- [[模块化编程]]：将系统分解为独立模块，提高复用价值
- [[微服务架构]]：将系统拆解为独立开发、部署、扩容的服务
- [[Redis缓存]]：作为缓存提升系统读性能，降低数据库压力
- [[消息队列]]：用于服务之间的异步通信，实现解耦和削峰填谷
- [[输入-处理-输出模型]]：明确区分消费端（接收数据）、生产端（生成数据）、状态（存储信息）、变换（处理逻辑）
- [[并发编程]]：区分共享资源、数据竞争、锁机制与异步处理的差异
## Key Entities
- 无特定实体提及，本文档为方法论文档
## Connections
- [[Vibe Coding]] ← 相关领域 ← 本文：提供 AI 辅助开发的项目规范框架
- [[单一职责原则]] ← 编码规范核心 ← [[DRY原则]] ← 模块化基础
- [[微服务架构]] ← 服务拆分原则 ← [[Redis缓存]] ← 性能优化手段
- [[消息队列]] ← 异步通信基础设施 ← 微服务间通信机制
## Contradictions
- 与传统软件开发方法冲突：
- 冲突点：传统强调"先理解代码再修改"，本文强调"从问题出发而非代码出发"
- 当前观点：Vibe Coding 环境下，AI 生成代码量大，应先明确问题再让 AI 生成，而非逐步理解 AI 生成的代码
- 对方观点：传统软件工程强调对代码的深度理解是维护和修改的前提
---
title: "开发经验与项目规范整理文档"
type: source
tags: [vibe-coding, software-engineering, best-practices, coding-standards, microservices, redis, message-queue]
sources: []
last_updated: 2025-12-30
---
## Source File
- [[Vibe Coding/开发经验与项目规范整理文档]]
## Summary（用中文描述）
- 核心主题：Vibe Coding 环境下的开发经验与项目规范最佳实践，涵盖编码规范、系统架构原则、程序设计思想及基础设施（微服务、Redis、消息队列）
- 问题域：如何建立可持续维护的 AI 辅助开发项目；如何制定团队编码规范；如何通过规范提升 AI 生成的代码质量
- 方法/机制：
- 变量名维护方案（统一变量索引文件，格式：变量名 | 变量注释 | 出现位置 | 出现频率）
- 文件结构与命名规范（子文件夹含 agents + claude.md；文件命名小写英文 + 下划线/小驼峰）
- 编码规范（单一职责、DRY、模块化；消费端/生产端/状态/变换模型）
- 并发编程规范（共享资源、数据竞争、锁机制、并发 vs 异步区分）
- 系统架构原则（先梳理架构 → 理解需求 → 保持简单 → 自动化测试 → 小步迭代）
- 程序设计核心思想（从问题出发、清晰命名、单一职责、可读性优先、合理注释、测试优先）
- 微服务拆分原则（独立开发/部署/扩容，服务间通过 API 通信）
- Redis 缓存策略（提升读性能、降低 DB 压力、提供计数/锁/队列/Session 能力）
- 消息队列异步通信（解耦、削峰填谷、异步任务处理）
- 结论/价值：为 AI 辅助开发项目提供系统化规范框架，强调从问题出发而非代码出发，提升代码可维护性和团队协作效率
## Key Claims（用中文描述）
- 统一变量索引文件能降低命名冲突和语义不清晰带来的风险，实现 AI 与团队全局命名一致性管理
- 编码规范中的「消费端 → 生产端 → 状态 → 变换」模型能清晰划分系统行为边界，明确输入→处理→输出各环节
- 系统开发应遵循「先理解需求 → 保持架构与代码简单 → 写可维护的自动化测试 → 小步迭代，不做大爆炸开发」的严谨流程
- 编程第一步永远是「你要解决什么问题」，复杂问题拆解为可独立完成的小单元，减少复杂度、魔法代码、晦涩技巧
- 注释解释「为什么」，而非「怎么做」；代码可读性优先，写的代码是给别人理解的，不是来炫技的
- 未测试的代码迟早会出问题，调试是程序员核心技能，永远不要把代码只放本地
- 微服务将系统拆解为多个独立开发、独立部署、独立扩容的服务，服务间通过 API 通信（HTTP、RPC、MQ 等）
- Redis 通过缓存提升系统读性能、降低数据库压力，并提供计数、锁、队列、Session 等扩展能力
- 消息队列实现服务间的异步通信，带来解耦、削峰填谷、异步任务处理等系统稳定性与吞吐收益
## Key Quotes
> "编程的第一步永远是：你要解决什么问题？" — 从问题出发而非代码
> "你写的代码是给别人理解的，不是来炫技的。" — 代码可读性优先
> "注释解释'为什么'，不是'怎么做'。" — 合理注释原则
> "未测试的代码迟早会出问题。" — 测试优先
> "永远不要把代码只放本地。" — 调试是必修课
## Key Concepts
- [[单一职责原则]]：每个文件、类、函数应只负责一件事，提炼公共逻辑，避免重复代码（DRY）
- [[DRY原则]]：Don't Repeat Yourself，避免重复代码，提高复用价值
- [[模块化编程]]：将系统分解为独立模块，提高复用价值，函数化、类化、模块化
- [[输入-处理-输出模型]]：明确区分消费端（接收外部数据）、生产端（生成数据/输出结果）、状态（存储当前系统信息）、变换（处理状态/改变数据的逻辑）
- [[并发编程]]：区分共享资源、数据竞争、必要时加锁或使用线程安全结构，区分"并发处理"和"异步处理"的差异
- [[微服务架构]]：将系统拆解为独立开发、部署、扩容的服务，服务间通过 API 通信
- [[Redis缓存]]：作为缓存提升系统读性能，降低数据库压力，提供计数/锁/队列/Session 能力
- [[消息队列]]：用于服务之间的异步通信，实现解耦、削峰填谷、异步任务处理
- [[系统架构梳理]]：模块划分、输入输出、数据流向、服务边界、技术栈、依赖关系在写代码前先明确
## Key Entities
- 无特定商业实体提及，本文档为方法论文档，涵盖软件工程通用规范框架
## Connections
- [[Vibe Coding]] ← 相关领域 ← 本文：提供 AI 辅助开发的项目规范框架
- [[单一职责原则]] ← 编码规范核心 ← [[DRY原则]] ← 模块化基础
- [[微服务架构]] ← 服务拆分原则 ← [[Redis缓存]] ← 性能优化手段
- [[消息队列]] ← 异步通信基础设施 ← 微服务间通信机制
- [[输入-处理-输出模型]] ← 系统行为划分 ← [[系统架构梳理]] ← 开发前置工作
## Contradictions
- 与传统软件开发方法冲突：
- 冲突点：传统强调"先理解代码再修改"，本文强调"从问题出发而非代码出发"
- 当前观点：Vibe Coding 环境下，AI 生成代码量大，应先明确问题再让 AI 生成，而非逐步理解 AI 生成的代码
- 对方观点：传统软件工程强调对代码的深度理解是维护和修改的前提

135
wiki/sources/用docker安装apache-superset.md
View File

@@ -1,49 +1,86 @@
---
title: "用Docker安装Apache Superset"
type: source
tags: [apache, bi, docker, mysql, superset]
date: 2026-04-14
---
## Source File
- [[raw/Home Office/用Docker安装Apache Superset.md]]
## Summary (用中文描述)
- 核心主题：通过 Docker 快速部署 Apache Superset 开源 BI 平台，包含镜像拉取、容器启动、管理员账户创建、数据库迁移、示例数据加载等完整 6 步初始化流程
- 问题域：Home Server 场景下自托管 BI 可视化平台的 Docker 容器化部署
- 方法/机制：使用 Docker Hub 官方镜像 `apache/superset:GHA-19524015706`（GHA 构建版本），通过 `docker pull` + `docker run` + `docker exec` 初始化三步骤完成部署，端口映射 8777:8088，数据库使用内置 SQLite
- 结论/价值：提供一套可快速落地的自托管 BI 平台部署方案，适合家庭服务器场景的轻量级数据可视化
## Key Claims (用中文描述)
- Apache Superset 通过 Docker 容器化部署可实现一键启动，是 Home Server 场景下的轻量级 BI 可视化方案
- 通过 `superset fab create-admin` 命令行交互式创建首个管理员账户（用户名/邮箱/密码）
- 通过 `superset db upgrade` 执行数据库迁移，确保 Superset 元数据存储就绪
- 通过 `superset load_examples` 加载示例数据集，新用户可快速熟悉 BI 平台功能
- 通过 `superset init` 完成初始化，使平台进入可用状态
## Key Quotes
> "docker run -d -p 8777:8088 -e \"SUPERSET_SECRET_KEY=*** --name superset apache/superset:GHA-19524015706"
> — 容器启动命令，8777 映射到容器内 8088，设置了安全密钥环境变量
> "docker exec -it superset superset fab create-admin --username admin --firstname Superset --lastname Admin --email admin@superset.com --password admin"
> — 管理员账户创建命令，通过 flask-appbuilder (fab) CLI 创建首个 admin 用户
## Key Concepts
- [[BI平台]]：Business Intelligence 平台，提供数据可视化、仪表盘构建、SQL 查询等功能
- [[Docker容器化部署]]：通过 Docker 镜像封装应用依赖，实现环境一致性和快速部署
- [[Flask-AppBuilder]]：Superset 的 Web 框架，基于 Flask 的认证和权限管理组件
- [[数据库迁移]]：通过 `db upgrade` 命令初始化或升级 Superset 元数据数据库
## Key Entities
- [[Apache Superset]]：Apache 软件基金会旗下的开源 BI 平台，支持多样化图表和仪表盘构建
- [[Docker]]：容器化平台，Superset 的部署底座
- [[MySQL]]：Superset 支持的外部数据库后端（标签提及），默认使用 SQLite
## Connections
- [[Apache Superset]] ← deployed_by ← [[Docker]]
- [[Home Server Automation]] ← part_of ← [[家庭网络环境概览]]
- [[Apache Superset]] ← use_case ← [[数据可视化]]
- [[Portainer]] ← alternative_admin_ui ← [[Docker]]
## Contradictions
- 无冲突
---
title: "用Docker安装Apache Superset"
type: source
tags: [apache, bi, docker, mysql, superset]
date: 2026-04-14
---
## Source File
- [[raw/Home Office/用Docker安装Apache Superset.md]]
## Summary（用中文描述）
- **核心主题**：通过 Docker 容器快速部署 Apache Superset BI 平台
- **问题域**：数据可视化与 BI 工具的本地化安装
- **方法/机制**：使用 Docker Hub 官方镜像 `apache/superset`，通过 docker exec 进入容器执行初始化命令
- **结论/价值**：提供一套标准化、可复现的 Superset 部署流程，适合开发测试环境快速搭建
## Key Claims（用中文描述）
- Docker 容器化部署可将 Superset 安装时间压缩至分钟级别
- 通过 `superset fab create-admin` 命令创建管理员账户是初始化第一步
- `superset db upgrade` 确保数据库 Schema 与当前版本同步
- `superset load_examples` 加载示例数据集，便于新用户快速上手
- `superset init` 完成权限和缓存的初始化
## Key Quotes
> `docker pull apache/superset:GHA-19524015706` — 拉取 GitHub Actions 构建版本的 Apache Superset 官方镜像
>
> `docker run -d -p 8777:8088 -e "SUPERSET_SECRET_KEY=*** --name superset apache/superset:GHA-19524015706` — 容器启动命令，将宿主机的 8777 端口映射到容器的 8088 端口（Superset 默认 Web UI 端口），设置 SECRET_KEY 环境变量
>
> `docker exec -it superset superset fab create-admin --username admin --firstname Superset --lastname Admin --email admin@superset.com --password admin` — 管理员账户创建命令，用于首次登录系统
## Key Concepts
- [[Docker]]：容器化平台，Superset 的部署底座
- [[Docker-Image]]：`apache/superset` 官方镜像
- [[容器初始化]]：docker exec 进入运行中的容器执行初始化命令的流程
- [[BI平台]]：Business Intelligence 平台，Superset 属于开源 BI 工具
- [[数据可视化]]：将数据库数据转化为图表/仪表盘的技术
## Key Entities
- [[Apache Superset]]：开源 BI 和数据探索平台，由 Apache 软件基金会维护，支持 SQL 查询、可视化仪表盘和数据源连接
- [[MySQL]]：关系型数据库，在 Superset 中作为可选元数据存储（默认使用 SQLite）
- [[Docker Hub]]：官方镜像仓库，`apache/superset` 的托管位置
## Connections
- [[Docker]] ← uses ← [[Apache Superset]]
- [[MySQL]] ← stores ← [[Apache Superset 元数据]]
- [[Docker]] ← extends ← [[Docker Compose]]（生产环境推荐多容器协同）
- [[Apache Superset]] ← depends_on ← [[Flask]]（Web 框架）
- [[Apache Superset]] ← depends_on ← [[SQLAlchemy]]（数据库 ORM）
## Contradictions
- 与 [[install-apache-superset-in-docker]] 无冲突：
- 两篇文档内容高度一致，均使用 `docker run` 单容器模式 + GHA 构建版本镜像，适合快速尝鲜
- 与 [[用docker安装portainer]] 同属 Home Office Docker 部署系列，可作为参考对照
## 安装步骤速查
```bash
# 1. 拉取镜像
docker pull apache/superset:GHA-19524015706
# 2. 运行容器
docker run -d -p 8777:8088 \
-e "SUPERSET_SECRET_KEY=***" \
--name superset \
apache/superset:GHA-19524015706
# 3. 创建管理员账户
docker exec -it superset superset fab create-admin \
--username admin \
--firstname Superset \
--lastname Admin \
--email admin@superset.com \
--password admin
# 4. 数据库迁移
docker exec -it superset superset db upgrade
# 5. 加载示例数据
docker exec -it superset superset load_examples
# 6. 初始化
docker exec -it superset superset init
```
访问地址：`http://localhost:8777`
默认凭据：`admin / admin`