Updated workflow

.gitea/workflows/sphinx_deploy.yml

@@ -11,80 +11,118 @@ jobs:
     runs-on: linux
     
     steps:
-      # 第一步：更新主工作树
+      # 第一步: 设置主工作树和虚拟环境
-      - name: Update main worktree
+      - name: Setup main worktree and virtual environment
         run: |
-          echo "=== Updating main worktree ==="
+          echo "=== Setting up main worktree ==="
+          
+          # 如果主目录不存在，克隆仓库
+          if [ ! -d "/home/ly0kos/work/test_env" ]; then
+            echo "Cloning repository to main worktree..."
+            git clone http://localhost:3000/yuysh/Manlink_Doc.git /home/ly0kos/work/test_env
+            cd /home/ly0kos/work/test_env
+            
+            # 创建共享虚拟环境
+            python3 -m venv .venv-shared
+            source .venv-shared/bin/activate
+            pip install --upgrade pip
+            pip install sphinx sphinx-rtd-theme
+            
+            # 记录初始依赖状态
+            if [ -f "requirements.txt" ]; then
+              pip install -r requirements.txt
+              stat -c %Y requirements.txt > .venv-shared/last_update.txt
+            fi
+          else
+            cd /home/ly0kos/work/test_env
+            git fetch --all --prune
+            git checkout master
+            git pull origin master
+          fi
+          
+          echo "✓ Main worktree ready"
+
+      # 第二步: 为PR分支创建工作树
+      - name: Create worktree for PR branch
+        run: |
+          echo "=== Creating worktree for PR branch: ${{ github.head_ref }} ==="
           cd /home/ly0kos/work/test_env
           
-          git fetch --all --prune
+          # 清理可能存在的旧工作树
-          git checkout master
+          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
-          git pull origin master
+          if [ -d "$WORKTREE_DIR" ]; then
+            echo "Removing existing worktree..."
+            git worktree remove "$WORKTREE_DIR" --force 2>/dev/null || true
+            rm -rf "$WORKTREE_DIR" 2>/dev/null || true
+          fi
           
-          echo "✓ Main worktree updated"
+          # 创建新的工作树
+          mkdir -p "/home/ly0kos/work/test_env/worktrees"
+          git fetch origin ${{ github.head_ref }}:${{ github.head_ref }} --force
+          git worktree add "/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}" ${{ github.head_ref }} --force
+          
+          echo "✓ Worktree created at: /home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
 
-      # 第二步：复用共享虚拟环境
+      # 第三步: 复用共享虚拟环境并检查依赖更新
       - name: Reuse shared virtual environment
         run: |
-          echo "=== Using shared virtual environment ==="
+          echo "=== Reusing shared virtual environment ==="
           cd /home/ly0kos/work/test_env
+          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
+          
+          # 使用主工作树的共享虚拟环境
           source .venv-shared/bin/activate
           
-          # 检查主分支的requirements.txt是否有更新
+          # 检查PR分支的requirements.txt是否有更新
-          if [ -f "requirements.txt" ]; then
+          if [ -f "$WORKTREE_DIR/requirements.txt" ]; then
-            REQ_MOD_TIME=$(stat -c %Y requirements.txt 2>/dev/null || echo 0)
+            echo "Checking for dependency updates in PR branch..."
+            REQ_MOD_TIME=$(stat -c %Y "$WORKTREE_DIR/requirements.txt" 2>/dev/null || echo 0)
             VENV_MOD_TIME=$(cat .venv-shared/last_update.txt 2>/dev/null || echo 0)
             
             if [ $REQ_MOD_TIME -gt $VENV_MOD_TIME ]; then
-              echo "Master branch requirements updated, installing new dependencies..."
+              echo "PR branch requirements updated, installing new dependencies..."
-              pip install -r requirements.txt --no-cache-dir
+              pip install -r "$WORKTREE_DIR/requirements.txt"
               echo $REQ_MOD_TIME > .venv-shared/last_update.txt
+              echo "Dependencies updated from PR branch"
+            else
+              echo "No changes in requirements, using existing packages"
             fi
           fi
+          
+          echo "python3: $(python3 --version)"
+          echo "Sphinx: $(sphinx-build --version 2>/dev/null || echo 'Not installed')"
 
-      # 第三步：从主工作树构建文档
+      # 第四步: 在工作树中构建文档
-      - name: Build documentation from master
+      - name: Build documentation in worktree
         run: |
-          echo "=== Building production documentation ==="
+          echo "=== Building documentation in worktree ==="
           cd /home/ly0kos/work/test_env
+          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
           source .venv-shared/bin/activate
           
-          rm -rf build/
+          # 构建文档
-          sphinx-build -b html source build -v -j 4
+          cd "$WORKTREE_DIR"
-          echo "✓ Production build completed"
+          sphinx-build -b html source "$WORKTREE_DIR/build" -v -j 4
+          
+          # 复制到预览位置
+          mkdir -p /home/ly0kos/work/test_env/pr-builds/
+          rm -rf /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}
+          cp -r "$WORKTREE_DIR/build" /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}
+          
+          echo "✓ Build completed for PR branch: ${{ github.head_ref }}"
 
-      # 第四步：部署到Web服务器
+      # 第五步: 验证构建结果
-      - name: Deploy to web server
+      - name: Verify build
         run: |
-          echo "=== Deploying to production ==="
+          echo "Build output for PR ${{ github.head_ref }}:"
-          cd /home/ly0kos/work/test_env
+          ls -la /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/ | head -10
-          
+      
-          rm -rf /var/www/docs_dev/*
+      # 第六步: 复制至测试目录
-          cp -r build/* /var/www/docs_dev/
+      - name: Copy to dev folder
-          
-          echo "✓ Documentation deployed"
-
-      # 第五步：清理PR工作树
-      - name: Cleanup PR worktree
         run: |
-          echo "=== Cleaning up PR worktree ==="
+          echo "Now clear dev folder"
-          cd /home/ly0kos/work/test_env
+          rm -rf /var/www/docs/*
-          
+          echo "Copy build to dev folder"
-          WORKTREE_DIR="/home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
+          cp -r /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/* /var/www/docs/
-          if [ -d "$WORKTREE_DIR" ]; then
+          echo "✓ Documentation in Product folder now!"
-            git worktree remove "$WORKTREE_DIR" --force
+          echo "Please check http://mkb.local to See Changes"
-            echo "✓ Removed worktree for ${{ github.head_ref }}"
-          fi
-          
-          # 清理预览文件
-          PREVIEW_DIR="/home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}"
-          if [ -d "$PREVIEW_DIR" ]; then
-            rm -rf "$PREVIEW_DIR"
-            echo "✓ Removed preview for ${{ github.head_ref }}"
-          fi
-
-      # 第六步：验证部署
-      - name: Verify deployment
-        run: |
-          echo "Production deployment completed!"
-          ls -la /var/www/docs_dev/ | head -10

.gitea/workflows/sphinx_test.yml

@@ -11,7 +11,7 @@ jobs:
     runs-on: linux
 
     steps:
-      # 第一步：设置主工作树和虚拟环境
+      # 第一步: 设置主工作树和虚拟环境
       - name: Setup main worktree and virtual environment
         run: |
           echo "=== Setting up main worktree ==="
@@ -42,7 +42,7 @@ jobs:
           
           echo "✓ Main worktree ready"
 
-      # 第二步：为PR分支创建工作树
+      # 第二步: 为PR分支创建工作树
       - name: Create worktree for PR branch
         run: |
           echo "=== Creating worktree for PR branch: ${{ github.head_ref }} ==="
@@ -63,7 +63,7 @@ jobs:
           
           echo "✓ Worktree created at: /home/ly0kos/work/test_env/worktrees/${{ github.head_ref }}"
 
-      # 第三步：复用共享虚拟环境并检查依赖更新
+      # 第三步: 复用共享虚拟环境并检查依赖更新
       - name: Reuse shared virtual environment
         run: |
           echo "=== Reusing shared virtual environment ==="
@@ -92,7 +92,7 @@ jobs:
           echo "python3: $(python3 --version)"
           echo "Sphinx: $(sphinx-build --version 2>/dev/null || echo 'Not installed')"
 
-      # 第四步：在工作树中构建文档
+      # 第四步: 在工作树中构建文档
       - name: Build documentation in worktree
         run: |
           echo "=== Building documentation in worktree ==="
@@ -111,13 +111,13 @@ jobs:
           
           echo "✓ Build completed for PR branch: ${{ github.head_ref }}"
 
-      # 第五步：验证构建结果
+      # 第五步: 验证构建结果
       - name: Verify build
         run: |
           echo "Build output for PR ${{ github.head_ref }}:"
           ls -la /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/ | head -10
       
-      # 第六步：复制至测试目录
+      # 第六步: 复制至测试目录
       - name: Copy to dev folder
         run: |
           echo "Now clear dev folder"
@@ -125,4 +125,5 @@ jobs:
           echo "Copy build to dev folder"
           cp -r /home/ly0kos/work/test_env/pr-builds/${{ github.head_ref }}/* /var/www/docs_dev/
           echo "✓ Documentation in DEV folder now!"
-          echo "Please check http://mkb.local:880 to Verify Changes"
+          echo "Please check http://mkb.local:880 to Verify Changes"
+

README.md

@@ -1,97 +1,3 @@
 # MKB
 
-Manlink Knowledge Base
+Manlink Knowledge Base
----
-## About
-此仓库用于储存及生成知识库网页
-
-[点我访问正式版网页](http://mkb.local)
-
-*[若无法访问，尝试直接访问ip](http://172.18.32.40/)*
-
----
-## Getting Started
-
-### 前期准备
-1. 在[这里](http://mkb.local:3000/user/sign_up)注册账号
-2. 通知管理员将账户加入`Manlink_Doc` 仓库
-3. 确保连接`manlink_internal`网络 
-
-### 环境部署
-1. <a href = "http://mkb.local/_static/deploy/deploy.exe"> 点我下载环境 </a>
-2. 解压压缩文件后运行`deploy.bat`，并根据提示输入必要信息(仅限英文字符)
-3. 若批处理正确运行完成，则应在解压目录下生成RUNME.bat
-4. 双击RUNME.bat，应打开`vscode`环境并自动打开仓库目录
-5. 现在您可以对仓库进行`签出`、`提交`等操作
-6. 可能在提交时会提示输入用户名/密码(请输入gitea账户密码)
-
-### VSCode-Git 使用说明
-
-1. 在完成环境部署后，vscode中源代码管理功能应可用，从侧边栏中访问该功能
-   ![VSCode Git](./Readme/img/vscode_git.png)
-2. 想要对知识库页面进行编辑时，需**签出新分支**，参考下图步骤
-
-    ![](./Readme/img/vscode_checkout.png)
-    ![](./Readme/img/vscode_new_branch.png)
-
-> [!CAUTION]
-> 请不要直接对`master`分支进行修改！
->修改前请**签出**分支，修改完成后请发起***合并分支***请求
-
-3. 在进行编辑后点击这里进行推送/发布新分支
-   ![](./Readme/img/vscode_push.png)
-
-> [!NOTE]
-> 
-> 想要更加详细了解Git可以参考[这篇文档](./Readme/git.md)
-
-### 添加/修改内容
-
-1. 本知识库采用`Sphinx`作为解析、生成工具，并*推荐*主要以`Markdown`语言作为文档的原始语言格式,`reStructuredText`语言作为辅助
-2. `source`文件夹即为知识库原始文件夹，通过文件树及`index.rst`进行网页层级管理
-
-> [!IMPORTANT]  
-> 请**不要**修改`source/conf.py`其为`Sphinx`配置文件！如需修改请提交PR至管理员
-
-3. 创建文档时：
-   1. 请将图片放入`_images/`目录下，建议单独创建文件夹以保证目录整洁
-   2. 其他数据，如：实验数据、日志等，请放入`_static/`目录下，同样建议创建文件夹以保证目录整洁
-   3. 对于新创建的文档：
-      1. 如已存在对应目录，则仅需在对应目录下创建文档即可，建议保证文件名具有**通俗易懂**的可读性
-      2. 如不存在目录，则需创建目录及`index.rst`，并更新上级的`index.rst`或`index.md`，具体内容可参考已有文档，如[子目录index.rst](./source/Mars_1KS/DC/PPMU/1.0/index.rst)及[父目录index.rst](./source/Mars_1KS/index.rst)之后新建文档
-   
-> [!Note]
->
-> 对于Markdown语法，可以参考[这篇文档](./Readme/markdown.md)
-
-
-### 测试及合并请求
-
-1. 在您完成编辑后可以对您的分支发起合并请求(Pull Request)，推荐通过网页进行这一操作，其位置如下图：
-   ![PR](./Readme/img/PR.png)
-
-    > [!WARNING]  
-    > 您仅应对您编辑的分支发起合并请求
-
-2. 在创建合并请求界面，需清晰明了的创建标题及合并请求正文，如需合作，也可在指派成员一栏邀请成员进行合作
-
-    ![PR_Create](./Readme/img/PR_Create.png)
-
-3. 创建合并分支后会默认触发自动化部署，如下图所示
-    
-    ![Pr_Action](./Readme/img/Pr_Action.png)
-
-   在正常情况下，自动化部署应顺利完成(理论运行时间<5min)，运行完成后可在[http://mkb.local:880](http://mkb.local:880)查看及调试网页
-
-   >[!NOTE]
-   >此时如有问题，仍可以通过commit进行提交，提交后会触发自动化部署
-
-   >[!WARNING]
-   >服务器性能有限，且已人为将自动化部署并发数设为1，请尽可能避免在Pr后提交Commit
-
-4. 在检查完测试网页后可添加管理员作为评审人，之后须有管理员评审并在通过审核后将分支合并至主分支
-
-   ![PR_Review](./Readme/img/PR_Review.png)
-   ![PR_Review_Judge](./Readme/img/PR_Review_Judge.png)
-
-5. 最后需管理员手动合并测试网页至正式版网页   

Readme/git.md

@@ -1,171 +0,0 @@
-# Git 与 Gitea 协作开发指南
-
-## 文档说明
-
-本文档面向公司内部已配置好开发环境（VSCode、Git、Gitea）的同事，旨在规范并指导如何使用 Git 和公司内网的 Gitea 服务平台进行高效的日常代码协作。本文档不包含环境安装与部署内容。
-
-## 1. 术语表 (Glossary)
-
-| 术语/缩写 | 全称/解释 | 说明 |
-| :--- | :--- | :--- |
-| **Repository (Repo)** | 仓库 | 一个项目所有的文件和历史记录。可以理解为你的项目文件夹及其所有变更记忆。 |
-| **Local** | 本地 | 指存储在你个人电脑上的仓库。 |
-| **Remote** | 远程 | 指存储在服务器（如 Gitea）上的仓库，是团队协作的中心。 |
-| **Clone** | 克隆 | 将**远程仓库**完整下载到本地的操作。这是获取项目代码的起点。 |
-| **Commit** | 提交 | 将你的代码变更**打包并保存**到本地仓库历史记录中的操作。每次提交都需要一条说明信息。 |
-| **Push** | 推送 | 将你本地仓库的提交**上传**到远程仓库的操作，使你的工作成果对他人可见。 |
-| **Pull** | 拉取 | 将远程仓库的最新提交**下载并合并**到本地的操作，用于同步他人的工作成果。 |
-| **Fetch** | 获取 | 从远程仓库**下载**最新的变更信息到本地，但**不会自动合并**到你的工作文件中。让你可以查看他人进度，再决定是否拉取。 |
-| **Branch** | 分支 | 一条独立的开发线。主分支（如 `main`）应保持稳定，新功能应在**特性分支**上开发。 |
-| **Merge** | 合并 | 将一个分支的修改整合到另一个分支的操作（例如，将功能分支合并到主分支）。 |
-| **Pull Request (PR)** | 拉取请求 | **一个核心协作流程**。它是 Gitea 等平台的功能，用于发起代码合并请求，并进行代码评审（Code Review）、讨论和自动化检查。 |
-| **Issue** | 议题/问题 | 用于**跟踪任务、功能请求和 Bug**。每个 Issue 应有清晰的标题和描述，可以被分配、分类和讨论。 |
-| **`.gitignore`** | - | 一个特殊的配置文件，用于告诉 Git 哪些文件或目录**不需要**纳入版本控制（如日志文件、编译产物、本地配置文件等）。 |
-| **Conflict** | 冲突 | 当多个人修改了同一文件的同一区域时，Git 无法自动合并，需要**人工介入**解决的情况。 |
-| **HEAD** | - | 通常指向你当前所在的分支的最新提交，可以理解为“你当前的工作目录状态”。 |
-
----
-
-## 2. 核心工作流程
-
-### 2.1. 初始化：克隆仓库 (Clone)
-
-参与一个已有项目的第一步是获取代码。
-
-1.  打开浏览器，访问项目的 Gitea 页面。
-2.  找到并点击 **克隆** 按钮，复制提供的 URL（通常以 `http://...` 开头）。
-3.  在 VSCode 中：
-    *   按 <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> 打开命令面板。
-    *   输入 `Git: Clone` 并选择。
-    *   粘贴刚才复制的 URL，按回车。
-    *   选择本地存储项目的目录。
-4.  克隆完成后，VSCode 会提示你打开克隆的项目。
-
-### 2.2. 每日循环：获取与同步
-
-**每天开始工作前**，务必先同步远程的最新代码到本地，以避免冲突。
-
-*   **推荐操作：拉取 (Pull)**
-    *   **VSCode GUI**: 点击左侧源代码管理图标 -> 点击顶部 **...** -> 选择 **拉取 (Pull)**。
-    *   **终端命令**: `git pull origin <当前分支名>`
-
-*   **可选操作：获取 (Fetch) + 拉取**
-    *   如果你想先查看别人改了什么再决定是否合并，可以先 **获取**：
-        *   **VSCode GUI**: ... -> **获取 (Fetch)**
-        *   **终端命令**: `git fetch`
-    *   获取后，你可以在 VSCode 的左下角分支状态栏或源代码管理视图看到远程的更新提示，然后再决定拉取。
-
-### 2.3. 开发流程：基于分支的策略
-
-我们采用 **功能分支工作流**。严禁直接在 `main` 或 `develop` 等主分支上直接开发新功能。
-
-1.  **创建新分支**：
-    *   确保你当前在**主分支**上（例如 `main`），并且已经执行了 **拉取** 操作。
-    *   点击 VSCode 窗口左下角的分支名 -> 选择 **创建新分支...** -> 输入分支名 -> 回车。
-    *   **分支命名规范**：
-        *   功能：`feat/简短描述`，例如 `feat/user-auth`
-        *   Bug修复：`fix/问题描述`，例如 `fix/login-crash`
-        *   文档：`docs/更新内容`，例如 `docs/api-update`
-        *   热修复：`hotfix/紧急问题`，例如 `hotfix/prod-issue`
-
-2.  **在新分支上开发**：在此分支上完成你的编码、测试等工作。
-
-3.  **提交更改**：
-    *   在 VSCode 的“源代码管理”面板，看到所有更改的文件。
-    *   点击文件旁的 **+** 号或将文件拖到“暂存更改”区域。
-    *   在上方输入框撰写**清晰的提交信息**。
-        *   **格式建议**：`[类型] 简短描述`，例如 `[Feat] 增加微信登录功能` 或 `[Fix] 修复首页图片无法加载的问题`。
-    *   按 <kbd>Ctrl</kbd>+<kbd>Enter</kbd> (Mac: <kbd>CMD</kbd>+<kbd>Enter</kbd>) 提交到**本地仓库**。
-
-4.  **推送分支**：
-    *   首次推送新分支时，VSCode 会提示你发布（推送）分支。点击提示或点击源代码管理顶部的 **...** -> **推送**。
-    *   这将把你的本地分支和所有提交推送到 Gitea，并在远程创建同名分支。
-
-### 2.4. 协作流程：发起拉取请求 (Pull Request)
-
-完成功能开发后，需要将代码合并回主分支。
-
-1.  **推送最终代码**：确保你已将分支的所有提交都推送到 Gitea。
-2.  **在 Gitea 上创建 PR**：
-    *   浏览器打开你的项目 Gitea 页面。
-    *   通常页面上会有你刚推送分支的提示，直接点击 **创建拉取请求** 按钮。
-    *   或手动切换到 **Pull Requests** 标签页 -> **New Pull Request**。
-3.  **填写 PR 信息**：
-    *   **标题**：清晰概括 PR 内容，建议使用提交信息的格式。
-    *   **描述**：
-        *   详细说明修改内容、动机、测试方法。
-        *   **关键：关联 Issue**。在描述中输入 `#` 后会提示相关的 Issue，选择即可。使用 `Closes #15`, `Fixes #32` 等关键词，合并后可自动关闭对应 Issue。
-        *   如有界面变动，最好附上截图或屏幕录制。
-    *   选择正确的**基础分支** (如 `main`) 和**头部分支** (你的功能分支)。
-4.  **发起评审**：可以指定相关同事进行评审（Review）。
-5.  **处理评审意见**：评审者可能会在 PR 中提出评论。请根据意见在本地修改代码，然后再次**提交并推送**，新的提交会自动追加到该 PR 中。
-6.  **合并与清理**：
-    *   通过评审后，由有权限的成员在 Gitea 上操作合并。
-    *   合并后，可以在 Gitea 上**删除已合并的功能分支**（通常有选项）。
-    *   **本地清理**：切换回 `main` 分支 -> 拉取最新代码 -> 删除本地已合并的功能分支 (`git branch -d feat/your-branch`)。
-
----
-
-## 3. 常见问题与解决方案
-
-### 3.1. 推送失败：非快进式更新
-
-**现象**：`git push` 时提示 `! [rejected] error: failed to push some refs...`
-
-**原因**：在你推送之前，远程分支已经被别人更新了。
-
-**解决**：
-1.  执行 `git pull origin <你的分支名>` 拉取远程的最新代码并合并到本地。
-2.  解决可能出现的**合并冲突**（见下节）。
-3.  再次执行 `git push`。
-
-### 3.2. 合并冲突 (Conflict)
-
-**现象**：执行 `git pull` 或合并分支时，提示 `CONFLICT (content)`。
-
-**解决**：
-1.  **保持冷静**，冲突是协作的正常部分。
-2.  在 VSCode 中，冲突文件会被突出显示。打开文件，你会看到 Git 的冲突标记：
-    ```python
-    <<<<<<< HEAD
-    这是你本地修改的代码
-    =======
-    这是远程分支上的代码
-    >>>>>>> commit-hash...
-    ```
-3.  **沟通与决策**：与冲突代码的作者（可通过 Git 历史或团队沟通工具联系）讨论，决定保留哪一部分代码，或进行整合。
-4.  **手动解决**：
-    *   删除不需要的代码块。
-    *   **必须删除**所有冲突标记 (`<<<<<<<`, `=======`, `>>>>>>>`)。
-5.  **标记为已解决**：
-    *   在 VSCode 的“源代码管理”面板，解决后的文件会出现在“已暂存的更改”中。
-    *   右键点击该文件 -> **选择阶段更改**（如果未自动暂存）。
-6.  **完成合并**：
-    *   像正常提交一样，输入一个合并提交信息（如 `Merge branch 'main' into feat/xxx`）。
-    *   提交并推送。
-
----
-
-## 4. VSCode 高效技巧
-
-1.  **图形化界面**：多使用“源代码管理”视图和右键菜单，大部分操作无需命令。
-2.  **差异对比**：点击更改的文件，可直观查看代码行级别的变化（绿色新增，红色删除）。
-3.  **行内暂存**：在更改文件的代码行号旁边，点击 **+** 号可以只暂存该行的修改，而不是整个文件，用于提交精炼的更改。
-4.  **集成终端**：使用 VSCode 内置终端 (<kbd>Ctrl</kbd>+<kbd>`</kbd>) 执行 Git 命令，工作流无缝衔接。
-5.  **时间线视图**：点击单个文件，在编辑区下方可以看到该文件的**时间线**，展示所有的历史提交记录，方便追溯变更。
-
-## 5. 最佳实践总结
-
-1.  **勤提交**：小步快跑，频繁提交。每次提交只做一个明确的修改，并写好清晰的提交信息。
-2.  **勤拉取**：开始工作前、提交代码前，先 `pull` 一下，与主线保持同步。
-3.  **开分支**：任何新功能或 Bug 修复，都从新建分支开始。
-4.  **早提 PR**：功能未完全完成但希望早期评审时，可以创建 **Draft PR**（Gitea 支持）。
-5.  **看提示**：密切关注 VSCode 左下角分支状态栏的同步状态提示（如 `↑3` 代表有3个本地提交未推送，`↓2` 代表有2个远程提交未拉取）。
-6.  **用 Issues**：开发前先创建 Issue 来规划和跟踪任务，并在 PR 中关联它们。
-
-## 获取帮助
-
-*   **本地帮助**：在终端输入 `git help <命令>`，如 `git help commit`。
-
-
-祝您编码愉快，协作顺利！

Readme/markdown.md

@@ -1,184 +0,0 @@
-
-好的，没问题。这是一份为您和您的同事准备的 Markdown 使用指南，风格和受众与之前的 Git 文档保持一致。
-
----
-
-# Markdown 协作书写指南
-
-## 文档说明
-
-本文档面向公司内部所有需要使用 Markdown 语言书写文档的同事。Markdown 是一种轻量级标记语言，允许人们使用易读易写的纯文本格式编写文档，并可转换为有效的 HTML 文档。我们将在 **VSCode** 中编写，并托管在 **Gitea** 上进行版本管理与协作。
-
-## 1. 术语表 (Glossary)
-
-| 术语 | 解释 |
-| :--- | :--- |
-| **Markdown (.md)** | 一种轻量级标记语言，使用纯文本格式的语法，使其易读、易写，并可转换为结构化的 XHTML/HTML。 |
-| **语法 (Syntax)** | 一套规则体系，定义了如何通过简单的符号（如 `#`, `*`, `-` 等）来格式化文本。 |
-| **渲染 (Rendering)** | 将 Markdown 源代码解析并转换为可视化的、格式优美的文档（如 HTML、PDF）的过程。 |
-| **预览 (Preview)** | 在编写 Markdown 时实时查看其渲染后效果的功能。 |
-| **GFM (GitHub Flavored Markdown)** | GitHub（及 Gitea）对标准 Markdown 的扩展，提供了表格、任务列表等实用功能。 |
-| **扩展语法 (Extended Syntax)** | 并非所有 Markdown 处理器都支持的额外语法，如表格、脚注、定义列表等。 |
-
----
-
-## 2. 为什么使用 Markdown？
-
-*   **通用性强**：广泛用于 `README` 文件、论坛帖子、文档、博客、代码注释等。
-*   **专注于内容**：无需关心字体、颜色等样式，只需用简单的符号定义结构。
-*   **纯文本特性**：意味着：
-    *   兼容所有文本编辑器。
-    *   非常适合用 **Git** 进行版本控制，差异对比清晰明了。
-    *   永远不会因为软件换代而过时。
-*   **可转换**：轻松转换为 HTML、PDF、Word 等多种格式。
-
----
-
-## 3. 核心语法速查表
-
-这是你最常用到的 90% 的语法。
-
-### 3.1. 标题 (Headers)
-
-使用 `#` 的数量来表示标题的级别，从 1 级（最大）到 6 级（最小）。
-
-```markdown
-# 一级标题 (H1)
-## 二级标题 (H2)
-### 三级标题 (H3)
-#### 四级标题 (H4)
-##### 五级标题 (H5)
-###### 六级标题 (H6)
-```
-
-### 3.2. 强调 (Emphasis)
-
-```markdown
-*这是斜体文本* 或 _这也是斜体文本_
-**这是粗体文本** 或 __这也是粗体文本__
-***这是粗体加斜体*** 或 ___这也是粗体加斜体___
-```
-
-### 3.3. 列表 (Lists)
-
-**有序列表 (Ordered Lists)：** 使用数字加点号
-```markdown
-1. 第一项
-2. 第二项
-3. 第三项
-```
-
-**无序列表 (Unordered Lists)：** 使用 `-`, `*`, 或 `+`
-```markdown
-- 列表项
-- 另一个列表项
-  - 嵌套列表项（缩进两个空格或一个制表符）
-```
-
-**任务列表 (Task Lists - GFM 特性)：** 非常适合记录待办事项
-```markdown
-- [x] 已完成的任务
-- [ ] 未完成的任务
-```
-
-### 3.4. 链接与图片 (Links & Images)
-
-**链接：**
-```markdown
-[显示的链接文本](https://www.example.com "悬停提示文本（可选）")
-```
-
-**图片：**
-```markdown
-![图片的替代文本(alt text)](images/logo.png "悬停提示文本（可选）")
-```
-> **最佳实践**：使用 `source\_images`  文件夹来存放图片, `source\_static`来存放静态数据，并使用**相对路径**引用，这样在 Gitea 上也能正确显示。
-
-### 3.5. 代码 (Code)
-
-**行内代码 (Inline Code)：** 用反引号包裹
-```markdown
-使用 `git commit` 命令来提交更改。
-```
-
-**代码块 (Code Blocks)：** 用三个反引号包裹，并可选指定语言以实现语法高亮
-````markdown
-```python
-def hello_world():
-    print("Hello, World!")
-```
-````
-
-### 3.6. 引用 (Blockquotes)
-
-使用 `>` 符号表示引用。
-```markdown
-> 这是引用的文本。
-> 这是引用的文本。
->
-> > 这是嵌套的引用。
-```
-
-### 3.7. 表格 (Tables - GFM 特性)
-
-使用连字符 `-` 来分隔表头，管道符 `|` 来分隔列。
-```markdown
-| 左对齐 | 居中对齐 | 右对齐 |
-| :----- | :------: | -----: |
-| 单元格 |  单元格  | 单元格 |
-| 单元格 |  单元格  | 单元格 |
-```
-
----
-
-## 4. VSCode 中的高效书写
-
-VSCode 对 Markdown 提供了强大的原生支持。
-
-1.  **实时预览 (Preview)**：
-    *   打开一个 `.md` 文件。
-    *   点击编辑器右上角的 **拆分编辑器** 图标，或按 `Ctrl+K V`（按住 `Ctrl+K`，松开再按 `V`）。
-    *   右侧将打开一个实时渲染的预览窗口，与你左侧的编辑同步滚动。
-
-2.  **快捷键与自动补全**：
-    *   **加粗**：选中文本，按 `Ctrl+B`。
-    *   **斜体**：选中文本，按 `Ctrl+I`。
-    *   **代码块**：输入三个反引号 ```` ``` ```` 后按回车，VSCode 会自动补全并让你输入语言类型。
-    *   **列表**：输入 `- ` 或 `1. ` 后，按回车会自动创建下一项。
-
-3.  **目录生成 (TOC)**：
-    *   有许多扩展可以自动根据标题生成目录（如 `Markdown All in One`）。
-    *   在 Gitea 中，仓库的 `README.md` 文件会自动根据标题生成目录。
-
-4.  **代码格式化**：
-    *   安装 `Markdownlint` 等扩展，它可以帮你自动格式化 Markdown 文档并标记出不符合规范的写法。
-
----
-
-## 5. 与 Gitea/Git 的协作
-
-1.  **版本控制**：`.md` 文件是纯文本文件，非常适合用 Git 管理。每次对文档的修改（修正错别字、增加章节）都可以清晰地通过 `git diff` 看到。
-
-2.  **Gitea 渲染**：Gitea 完全支持 GFM。你推送至 Gitea 的任何 `.md` 文件都会在网页上被自动渲染成美观的文档。
-
-3.  **使用 Issues 和 PR 协作修改文档**：
-    *   发现文档错误或想贡献内容？和代码一样：
-        1.  **Fork** 或 **Clone** 仓库。
-        2.  基于 `main` 分支创建一个新分支（如 `docs/fix-typo`）。
-        3.  修改 `.md` 文件。
-        4.  提交更改，写清提交信息（如 `[Docs] 修复用户手册中的拼写错误`）。
-        5.  推送分支并发起 **Pull Request (PR)**。
-    *   其他同事可以在 PR 中对文档修改进行**评审（Review）**，提出建议。
-
----
-
-## 6. 最佳实践与规范
-
-1.  **保持简洁**：Markdown 的哲学是易读易写。不要滥用复杂格式。
-2.  **标题层级**：从 `H1` 开始，按顺序使用，不要跳级。
-3.  **中英文混排**：中英文之间加一个空格，例如：“学习 Markdown 语言” 而不是 “学习Markdown语言”。
-4.  **统一的图片管理**：在项目根目录建立 `assets` 或 `images` 文件夹，所有图片统一放入。
-5.  **行尾不要留空格**：这可能会在某些渲染器中导致意外的换行。
-6.  **善用代码块**：对于命令行操作、配置代码等，务必使用代码块，提高可读性。
-
-现在，你可以开始使用 Markdown 高效、优雅地书写所有文档了！

source/_template/Lab_Report.md

@@ -1,98 +0,0 @@
-
-# 实验报告：<在此填写实验名称>
-
-## 基本信息
-| 项目         | 内容                  |
-|--------------|-----------------------|
-| 实验日期     | `YYYY-MM-DD`          |
-| 负责人       | `沈浴阳`              |
-| 报告版本     | `V1.0`                |
-| 板卡编号     | ``              |
-
----
-## 一、实验背景
-
----
-
-## 二、实验目的
-<!-- 清晰描述实验要验证的关键问题 -->
-1. 目标1：`<验证XXX功能/性能>`
-2. 目标2：`<测试XXX极限参数>`
-3. 目标3：`<对比XXX设计方案>`
-
----
-
-## 三、实验环境
-- **硬件配置**  
-  `<被测设备型号> + 配套设备列表>`
-- **软件环境**  
-  `<测试软件及版本>`
-- **物理环境**  
-  `温度：25±2℃ | 湿度：45±5%RH`
-
----
-
-## 四、实验步骤
-### 1. 准备工作
-<!-- 分步骤描述准备过程 -->
-1) 步骤描述1：`<连接XX设备到XX接口>`
-2) 步骤描述2：`<设置XX参数为XX值>`
-   ![](./images/step2_setup.jpg) <!-- 建议图片命名：stepX_description.jpg -->
-
-### 2. 测试流程
-<!-- 按顺序记录关键操作 -->
-```mermaid
-graph LR
-A[启动设备] --> B{监测初始状态}
-B -->|正常| C[执行测试用例1]
-B -->|异常| D[记录故障现象]
-C --> E[采集数据]
-```
-
----
-
-## 五、实验结果
-### 关键数据记录
-| 测试点 | 预期值 | 实测值 | 偏差 | 单位 |
-|--------|--------|--------|------|------|
-| Vout   | 3.3    | 3.28   | -0.6% | V    |
-| I_max  | 2.0    | 2.15   | +7.5% | A    |
-
-### 波形/现象记录
-**图1：上电冲击电流波形**  
-![](./images/inrush_current_20230501.png)  
-*注释：观测到XX μs的浪涌电流*
-
-**图2：高温测试红外热像**  
-![](./images/thermal_image_test3.jpg)  
-*注释：芯片最高温度达XX℃（环境XX℃）*
-
----
-
-## 六、问题分析
-<!-- 使用故障树等结构化方法 -->
-```mermaid
-graph TD
-A[异常现象] --> B[电源模块]
-A --> C[信号干扰]
-B --> D{排查方向1}
-C --> E{排查方向2}
-```
-
----
-
-## 七、结论与建议
-✅ **实验结论**  
-1. `<验证通过/未通过的指标>`
-2. `<关键发现>`
-
-⚠️ **改进建议**  
-- [ ] 建议1：`<硬件优化方案>`
-- [ ] 建议2：`<测试方法改进>`
-
----
-
-## 附件
-1. [原始数据文件](./data/rawdata_20230501.csv)
-2. [电路原理图](./schematics/v2.0_final.pdf)
-3. [测试视频](./videos/test_recording.mp4)

source/index.md

@@ -1,32 +0,0 @@
----
-title: ManLin 硬件产品知识库
----
-
-# ManLin 硬件产品知识库
-
-```{toctree}
-:maxdepth: 1
-:caption: 目录
-
-Mars_1KS/index
-Calibration/index
-Lab_Report/index
-```
-
-## 附加文档
-
-1. [AD5522](_static/data/add_docs/AD5522.pdf)
-
-2. :::{dropdown} Power DataSheets
-
-   - [LTM4655](_static/data/add_docs/Pwr_DataSheet/ltm4655.pdf)
-   - [MIC29502](_static/data/add_docs/Pwr_DataSheet/MIC29502.pdf)
-   - [LMR51450](_static/data/add_docs/Pwr_DataSheet/LMR51450.pdf)
-   - [TPS54627](_static/data/add_docs/Pwr_DataSheet/tps54627.pdf)
-   - [TPS54821](_static/data/add_docs/Pwr_DataSheet/tps54821.pdf)
-   - [TPS563209](_static/data/add_docs/Pwr_DataSheet/tps563209.pdf)
-   - [LT3091](_static/data/add_docs/Pwr_DataSheet/lt3091.pdf)
-  
-   :::
-
-3. 

source/index.rst

@@ -0,0 +1,26 @@
+.. ManLin_KnowledgeBase documentation master file, created by
+   sphinx-quickstart on Tue Aug 12 05:35:46 2025.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+.. ManLin 硬件知识库主索引文件
+
+.. 注意：此文件使用 reStructuredText 语法，但支持包含 Markdown 文件
+
+##############################
+ManLin 硬件产品知识库
+##############################
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents:
+
+   Mars_1KS/index
+   Calibration/index
+   Lab_Report/index
+
+
+
+*Additional Docs:*
+
+1. `AD5522 <_static/data/add_docs/AD5522.pdf>`_