chore: 清理根目录冗余文件（旧文档/启动脚本/配置等）

删除: FEATURE_SUMMARY.md / QUICK_START.md / STARTUP.md INTERNAL_DEPLOYMENT_GUIDE.md / INTERNAL_DEPLOYMENT_SUMMARY.md start-server.bat / start-web.bat / .dockerignore Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 14:34:45 +08:00
parent b21899055d
commit e12d5aafbf
14 changed files with 1279 additions and 539 deletions
@@ -0,0 +1,16 @@
+# CodeGraph data files
+# These are local to each machine and should not be committed
+
+# Database
+*.db
+*.db-wal
+*.db-shm
+
+# Cache
+cache/
+
+# Logs
+*.log
+
+# Hook markers
+.dirty
@@ -1,9 +0,0 @@
-node_modules
-web/node_modules
-server/node_modules
-dist
-.git
-.env*
-.gemini
-.specify
-*.log
@@ -0,0 +1,75 @@
+name: E2E Tests
+on:
+  push:
+    branches: [main, develop]
+  pull_request:
+    branches: [main]
+  workflow_dispatch:
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    services:
+      elasticsearch:
+        image: elasticsearch:9.2.1
+        env:
+          discovery.type: single-node
+          xpack.security.enabled: false
+          ES_JAVA_OPTS: -Xms512m -Xmx512m
+        ports:
+          - 9200:9200
+      tika:
+        image: apache/tika:latest
+        ports:
+          - 9998:9998
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 22
+
+      - name: Install dependencies
+        run: npm install
+
+      - name: Build backend
+        run: cd server && npx nest build
+
+      - name: Start backend
+        run: cd server && node dist/main.js &
+        env:
+          JWT_SECRET: test-secret
+          OLLAMA_BASE_URL: http://localhost:11434
+
+      - name: Build frontend
+        run: cd web && npx vite build
+
+      - name: Install Playwright
+        run: cd web/e2e && npm install && npx playwright install chromium
+
+      - name: Serve frontend
+        run: cd web/e2e && node dev-server.js &
+        env:
+          PORT: 13001
+
+      - name: Wait for services
+        run: sleep 15
+
+      - name: Run E2E tests
+        run: cd web/e2e && npx playwright test --reporter=html
+
+      - uses: actions/upload-artifact@v4
+        if: always()
+        with:
+          name: playwright-report
+          path: web/e2e-report/
+          retention-days: 7
+
+      - uses: actions/upload-artifact@v4
+        if: failure()
+        with:
+          name: test-results
+          path: web/e2e/test-results/
+          retention-days: 14
@@ -1,29 +0,0 @@
-# 功能说明
-
-## 用户信息显示功能已完成
-
-此更新为系统添加了以下功能：
-
-1. 在侧边栏顶部显示当前登录用户的信息，包括：
-   - 用户头像和用户名
-   - 管理员标识（如果用户是管理员）
-   - 用户ID的部分显示
-
-2. 主要文件变更：
-   - 创建了 `UserInfoDisplay.tsx` 组件
-   - 更新了 `SidebarRail.tsx` 以集成用户信息显示
-   - 更新了 `App.tsx` 以传递 currentUser 数据
-   - 所有现有翻译已支持相关文本
-
-## 实现细节
-
- 用户信息只在侧边栏展开时显示
- 使用 Lucide React 图标增强可视化
- 支持三种语言的界面文本 (中文/英文/日文)
- 管理员用户会显示特殊标记
- 界面美观且与现有设计风格保持一致
- 避免了信息重复显示
-
-## 部署
-
-此功能已准备好部署，无需额外配置。
@@ -1,94 +0,0 @@
-# 内网部署指南 - Simple-KB 知识库系统
-
-## 概述
-
-本文档介绍如何在内部网络环境中部署Simple-KB知识库系统，确保所有外部依赖都被移除或替换为内部资源。
-
-## 主要修改内容
-
-### 1. 外部CDN资源移除
-
-已完成修改：
- 将 KaTeX CSS 文件从外部 CDN (https://cdn.jsdelivr.net/npm/katex@0.16.9/dist/katex.min.css) 移至本地
- `web/index.html` 已更新为引用本地 `/katex/katex.min.css`
- KaTeX CSS 文件已复制到 `web/public/katex/katex.min.css`
-
-### 2. AI模型API配置
-
-系统本身支持内部模型API配置：
- 模型配置通过 `ModelConfig` 实体管理
- 支持自定义 `baseUrl` 来指定内部模型服务
- 用户可通过UI界面配置内部模型端点
-
-## 内网部署配置步骤
-
-### 步骤1: 部署内部AI模型服务
-
-在启动Simple-KB之前，请确保已部署内部AI模型服务，如：
- 自托管的OpenAI兼容接口 (如 vLLM, Text Generation WebUI等)
- 内部大语言模型服务
- 内部嵌入模型服务
-
-### 步骤2: 配置模型端点
-
-1. 启动Simple-KB系统
-2. 登录系统后，在模型配置页面添加内部模型配置：
-   - LLM模型: 配置内部LLM服务的URL和API密钥
-   - 嵌入模型: 配置内部嵌入服务的URL和API密钥
-   - 重排序模型: 配置内部重排序服务的URL和API密钥
-
-### 步骤3: Docker配置（可选高级配置）
-
-如果需要修改Docker构建过程以使用内部注册表，请修改以下文件：
-
-#### 修改 server/Dockerfile:
-```dockerfile
-# 替换这行：
-RUN yarn config set registry https://registry.npmmirror.com && \
-# 为：
-RUN yarn config set registry http://your-internal-npm-registry && \
-```
-
-#### 修改 web/Dockerfile:
-```dockerfile
-# 替换这行：
-RUN yarn config set registry https://registry.npmmirror.com && \
-# 为：
-RUN yarn config set registry http://your-internal-npm-registry && \
-```
-
-#### 修改 libreoffice-server/Dockerfile:
-```dockerfile
-# 替换APK仓库源
-RUN echo "http://your-internal-mirror/alpine/v3.19/main" > /etc/apk/repositories && \
-    echo "http://your-internal-mirror/alpine/v3.19/community" >> /etc/apk/repositories && \
-
-# 替换pip源
-RUN pip install --no-cache-dir -r requirements.txt -i http://your-internal-pypi/
-
-# 替换npm源
-RUN npm install --registry=http://your-internal-npm-registry
-```
-
-### 步骤4: Nginx配置
-
-如果需要修改Nginx配置以适应内部环境：
-
-1. 更新 `nginx/conf.d/kb.conf` 中的SSL证书路径
-2. 根据需要修改服务器名称
-3. 确保代理路径正确指向内部服务
-
-## 验证步骤
-
-1. 确认前端界面正常加载且无外部资源错误
-2. 测试数学公式渲染功能是否正常（KaTeX功能）
-3. 配置内部模型服务并测试问答功能
-4. 确认所有API调用都在内部网络中完成
-
-## 注意事项
-
- 系统的所有核心功能现均可在内部网络中运行
- 外部CDN依赖已被完全移除
- AI模型服务需单独部署内部实例
- 在完全离线环境中，构建过程可能需要预先下载所有依赖包
- 如需完全离线部署，建议预构建镜像并部署到内部镜像仓库
@@ -1,40 +0,0 @@
-# 内网部署修改摘要 - Simple-KB 知识库系统
-
-## 修改概述
-
-已完成对Simple-KB知识库系统的修改，以支持内部网络环境部署，消除了外部依赖。
-
-## 具体修改内容
-
-### 1. 外部CDN资源移除
- **文件**: `web/index.html`
- **修改**: 将 KaTeX CSS 从外部 CDN (https://cdn.jsdelivr.net/npm/katex@0.16.9/dist/katex.min.css) 更改为本地资源 (/katex/katex.min.css)
- **文件**: `web/public/katex/katex.min.css`
- **操作**: 从 node_modules 复制 KaTeX CSS 文件到本地目录
-
-### 2. 文档更新
- **新增文件**: `INTERNAL_DEPLOYMENT_GUIDE.md`
- **内容**: 详细的内网部署指南，包括配置内部AI模型服务的方法
- **更新文件**: `README.md`
- **内容**: 添加了内网部署章节，链接到部署指南
-
-## 系统状态
-
-✅ **已完成**:
- 消除前端外部CDN依赖
- 提供内部网络部署文档
- 保持所有原有功能完整性
-
-✅ **系统已准备好在内部网络环境中部署**:
- 所有前端资源均为本地资源
- AI模型服务可通过配置指向内部服务
- 系统不再依赖外部CDN或API端点(除用户自行配置的AI模型外)
-
-## 部署说明
-
-要在内部网络中部署此系统：
-
-1. 按照 `INTERNAL_DEPLOYMENT_GUIDE.md` 的说明进行配置
-2. 部署内部AI模型服务（如适用）
-3. 配置模型端点以使用内部服务
-4. 启动系统并验证功能
@@ -1,316 +0,0 @@
-# クイックスタートガイド
-
-## 🚀 5分でクイック起動
-
-### 1. 環境設定
-
-```bash
-# プロジェクトディレクトリに移動
-cd /home/fzxs/workspaces/demo/simple-kb
-
-# 環境設定ファイルの作成
-cp server/.env.sample server/.env
-
-# 設定の編集
-vim server/.env
-```
-
-### 2. 依存関係のインストール
-
-```bash
-yarn install
-```
-
-### 3. サービスの起動
-
-```bash
-# 基本サービスの起動
-docker-compose up -d elasticsearch tika libreoffice
-
-# 開発サーバーの起動
-yarn dev
-```
-
-### 4. サービスの検証
-
-```bash
-# サービスの状態を確認
-docker-compose ps
-
-# 期待される出力:
-# NAME                COMMAND                  STATUS
-# local-es            ...                      Up
-# simple-kb-tika      ...                      Up
-# simple-kb-libreoffice ...                    Up
-```
-
-<http://localhost:5173> にアクセスして開始してください！
-
-## 📝 利用フロー
-
-### ステップ1: システムへログイン
-
-1. <http://localhost> にアクセスします。
-2. 既存のアカウントでログインするか、新しいアカウントを登録します。
-
-### ステップ2: モデルの設定
-
-1. 「モデル管理」に移動します。
-2. Vision モデルを追加します (OpenAI/Gemini をサポート)。
-3. API キーを設定します。
-4. デフォルトの Vision モデルとして設定します。
-
-### ステップ3: ドキュメントのアップロード
-
-1. 「ドキュメントのアップロード」をクリックします。
-2. PDF/Word/PPT ファイルを選択します。
-3. アップロード用モーダルウィンドウで:
-   - Embedding(埋め込み)モデルを選択します。
-   - **処理モードを選択します**:
-     - ⚡ 高速モード: テキストのみを抽出
-     - 🎯 高精度モード: 画像とテキストを混合して分析
-   - チャンク設定を調整します (任意)。
-4. 「処理開始」をクリックします。
-
-### ステップ4: 結果の確認
-
-1. バックエンドの処理が完了するまで待ちます。
-2. ファイルの状態を確認します: 「処理中」 → 「抽出完了」 → 「ベクトル化完了」
-3. チャット画面で RAG 検索をテストします。
-
-## 🔍 モード選択ガイド
-
-### 高速モードを使用する場合
-
-✅ **推奨シーン:**
-
- テキストのみのドキュメント
- コードファイル
- シンプルな Markdown
- 画像コンテンツが不要な場合
-
-**メリット:**
-
- 処理が速い (数秒)
- 追加コストがかからない
- 安定していて信頼性が高い
-
-### 高精度モードを使用する場合
-
-✅ **推奨シーン:**
-
- PDF ドキュメント (画像とテキストが混在しているもの)
- Word/PPT (グラフや表が含まれているもの)
- レイアウト情報を保持する必要がある場合
- 重要なドキュメント
-
-**メリット:**
-
- 画像コンテンツを保持
- グラフや表を認識
- ページのレイアウトを保持
- インデックスの質が高い
-
-**注意点:**
-
- API 利用料が必要 (目安: $0.01/ページ)
- 処理に時間がかかる
- Vision モデルの設定が必要
-
-## 💰 コスト管理
-
-### 利用枠(クォータ)の確認
-
-```bash
-# ユーザーのクォータを照会
-GET /api/users/:userId/quota
-
-# レスポンス例
-{
-  "monthlyCost": 15.50,
-  "maxCost": 100,
-  "remaining": 84.50,
-  "usagePercent": 15.5
-}
-```
-
-### コスト見積もり
-
-| ファイルタイプ | サイズ | ページ数 | 予想コスト | 予想時間 |
-|---------|------|------|---------|---------|
-| PDF | 10MB | ~20ページ | $0.20 | 60秒 |
-| Word | 5MB | ~10ページ | $0.10 | 30秒 |
-| PPT | 15MB | ~30ページ | $0.30 | 90秒 |
-
-### クォータの管理
-
-```sql
-- 管理者によるクォータのリセット
-UPDATE users SET monthly_cost = 0 WHERE id = 'user-uuid';
-
-- クォータ制限の調整
-UPDATE users SET max_cost = 200 WHERE id = 'user-uuid';
-```
-
-## 🐛 トラブルシューティング
-
-### 問題1: LibreOffice サービスが利用できない
-
-**症状:**
-
-```
-❌ LibreOffice 健康診断: 失敗
-```
-
-**解決策:**
-
-```bash
-docker-compose up -d libreoffice
-docker-compose logs libreoffice
-```
-
-### 問題2: ImageMagick がインストールされていない
-
-**症状:**
-
-```
-❌ convert: command not found
-```
-
-**解決策:**
-
-```bash
-# server イメージを再ビルド
-docker build -t simple-kb-server:latest ./server/
-docker-compose up -d server
-```
-
-### 問題3: クォータ不足
-
-**症状:**
-
-```
-❌ クォータ不足: 残り $5.00, 必要 $10.00
-```
-
-**解決策:**
-
- 翌月の自動リセットを待つ
- 管理者に連絡してクォータを増やす
- 高速モードで処理する
-
-### 問題4: 一時ファイルが多すぎる
-
-**症状:**
-
-```
-⚠️  100個以上の一時ファイルが見つかりました
-```
-
-**解決策:**
-
-```bash
-# 手動でクリーンアップ
-rm -rf temp/*
-
-# または .env で自動クリーンアップを設定
-TEMP_CLEANUP=true
-```
-
-## 📊 モニタリングとログ
-
-### 処理ログを確認する
-
-```bash
-# リアルタイムログ
-docker-compose logs -f server
-
-# Vision Pipeline のログをフィルタリング
-docker-compose logs -f server | grep "Vision\|高精度モード\|コスト"
-```
-
-### 主要なログの例
-
-```
-✅ 高精度モードでの処理を開始
-✅ 予想コスト: $0.15, 予想時間: 45秒
-✅ クォータチェックに合格
-✅ PDFを画像に変換: 15ページ
-✅ Vision 分析: 15/15 成功
-✅ 実際のコストを差し引きました: $0.15
-✅ 処理完了: 所要時間 42秒
-```
-
-## 🎯 ベストプラクティス
-
-### 1. ドキュメントの準備
-
- **ファイルサイズの最適化**: 大容量ファイルは分割して処理します。
- **鮮明な画像**: 高品質な画像の方が認識精度が高まります。
- **標準フォーマット**: PDF > Word > PPT の順で推奨されます。
-
-### 2. モードの選択
-
- **小規模ファイル (<10MB)**: 高精度モード
- **大規模ファイル (>50MB)**: 分割するか、高速モードを検討
- **テキストのみ**: 高速モード
- **画像・テキスト混在**: 高精度モード
-
-### 3. コスト削減
-
- **使用率の監視**: 75%で警告、90%で重大な警告を表示します。
- **定期的な整理**: 不要なドキュメントを削除します。
- **バッチ処理**: 適切なバッチサイズを使用して効率化します。
-
-### 4. パフォーマンスの最適化
-
- **チャンクサイズ**: 200-500 トークン
- **オーバーラップ率**: 10-20%
- **バッチサイズ**: 50-100
-
-## 📞 テクニカルサポート
-
-### ドキュメントの参照
-
- 詳細な実装: `docs/VISION_PIPELINE_IMPLEMENTATION.md`
- API ドキュメント: `VISION_PIPELINE_SUMMARY.md`
- テストスクリプト: `server/test-*.ts`
-
-### デバッグツール
-
-```bash
-# LibreOffice のテスト
-curl http://localhost:8100/health
-
-# Tika のテスト
-curl http://localhost:9998
-
-# Elasticsearch のテスト
-curl http://localhost:9200
-
-# コンテナの状態を確認
-docker-compose ps
-```
-
-## ✅ チェックリスト
-
-起動前のチェック項目:
-
- [ ] Docker と Docker Compose がインストールされている
- [ ] ポート 80, 3001, 8100, 9200, 9998 が他で使用されていない
- [ ] server/.env が設定されている
- [ ] Vision モデルの API キーが用意されている
- [ ] 少なくとも 4GB のメモリが使用可能
- [ ] 十分なディスク容量がある (>5GB)
-
-使用前のチェック項目:
-
- [ ] すべてのサービスの状態が Up になっている
- [ ] Vision モデルが設定されている
- [ ] Embedding(埋め込み)モデルが設定されている
- [ ] クォータが十分にある
- [ ] テスト用ファイルが用意されている
-
---
-
-**完了です！** これで Vision Pipeline システムを使用して、画像とテキストが混在したドキュメントを処理する準備が整いました！🎉
@@ -1,45 +0,0 @@
-# AuraK 启动手册
-
-## 快速启动
-
-```bash
-cd D:\AuraK
-wsl sudo service docker start
-wsl docker compose up -d
-```
-
-## 检查状态
-
-```bash
-wsl docker ps
-```
-
-## 访问地址
-
-| 服务 | 地址 |
-|------|------|
-| 前端 | http://localhost |
-| 后端API | http://localhost:3001 |
-| Elasticsearch | http://localhost:9200 |
-| Tika | http://localhost:9998 |
-| LibreOffice | http://localhost:8100 |
-
-##常用命令
-
-```bash
-# 停止服务
-wsl docker compose down
-
-# 重启服务
-wsl docker compose restart
-
-# 查看日志
-wsl docker compose logs -f server
-wsl docker compose logs -f web
-```
-
-## 注意事项
-
- 需要先启动WSL中的Docker服务：`wsl sudo service docker start`
- 再运行docker compose
- 如果WSL中缺少镜像，会自动从Docker Hub拉取
@@ -0,0 +1,709 @@
+# IDE 协作开发 — 考核题库
+
+> 对应课程：L1 课程四：IDE 协作开发
+> 题型：简答题（SHORT_ANSWER）、判断题（TRUE_FALSE）
+> 难度：STANDARD
+> 总计：50 题
+
+---
+
+## 一、GitHub Copilot — 智能代码补全（4 题）
+
+### Q1（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+看到 Copilot 给出的灰色补全建议后，按 Tab 键可以接受建议。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章
+
+---
+
+### Q2（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+看到 Copilot 给出的补全建议后，按 Esc 键可以拒绝这个建议。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章
+
+---
+
+### Q3（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+写函数开头后，Copilot 会自动逐行补全后续逻辑。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章
+
+---
+
+### Q4（注意事项/简答）
+
+小张用智能补全生成了一段代码，看起来功能正常。
+
+**问：** 在正式使用这段代码前，他应该先做什么？
+
+**答案：** 审查代码逻辑，确认没有语法错误或逻辑漏洞后再使用。AI 生成的代码需要人工审核。
+
+**依据：** GitHub Copilot 使用指南 - 红线警告
+
+---
+
+## 二、GitHub Copilot — Chat 三种模式（5 题）
+
+### Q5（简答）
+
+小张接手了一个老项目，打开 `OrderService.java` 发现有段逻辑看不太懂。他打开 Copilot Chat，想先问问这段代码是干什么的。
+
+Copilot Chat 有以下三种模式：**Ask** / **Plan** / **Agent**
+
+**问：** 小张应该选择哪种模式？
+
+**答案：** Ask（问答模式）。Ask 模式只回答问题，不修改代码。
+
+**依据：** GitHub Copilot 使用指南 - 第3章 三种对话模式
+
+---
+
+### Q6（简答）
+
+小李需要在三个文件中新增一个「批量删除用户」的功能，希望 AI 直接帮他完成代码修改。
+
+Copilot Chat 有以下三种模式：**Ask** / **Plan** / **Agent**
+
+**问：** 小李应该选择哪种模式？
+
+**答案：** Agent（智能代理模式）。Agent 模式可以自动跨文件修改代码。
+
+**依据：** GitHub Copilot 使用指南 - 第3章 三种对话模式
+
+---
+
+### Q7（简答）
+
+小赵想在项目中新增一个功能，但不知道涉及哪些文件、影响范围多大，想让 AI 先扫描整个项目给出方案。
+
+Copilot Chat 有以下三种模式：**Ask** / **Plan** / **Agent**
+
+**问：** 小赵应该选择哪种模式？
+
+**答案：** Plan（计划模式）。Plan 模式只出方案不动代码，适合先评估再动手。
+
+**依据：** GitHub Copilot 使用指南 - 第3章 三种对话模式
+
+---
+
+### Q8（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+Ask 模式下，Copilot 只会回答问题，不会修改用户的代码。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章
+
+---
+
+### Q9（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+Agent 模式下，Copilot 可以跨多个文件修改代码。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章
+
+---
+
+## 三、GitHub Copilot — CLI 使用（3 题）
+
+### Q10（简答）
+
+小刘想用 Copilot CLI 重构一个 Python 脚本，过程中要多次对话、逐步调优。
+
+Copilot CLI 有以下两种使用方式：**交互模式**（`copilot`）/ **非交互模式**（`copilot -p "指令"`）
+
+**问：** 小刘应该选择哪种方式？
+
+**答案：** 交互模式（`copilot`）。交互模式支持多轮对话，适合需要迭代的复杂任务。
+
+**依据：** GitHub Copilot 使用指南 - CLI 使用
+
+---
+
+### Q11（简答）
+
+小钱想用 Copilot CLI 快速解释一下 `git diff` 的结果，不想进入交互式对话。
+
+Copilot CLI 有以下两种使用方式：**交互模式**（`copilot`）/ **非交互模式**（`copilot -p "指令"`）
+
+**问：** 小钱应该选择哪种方式？
+
+**答案：** 非交互模式（`copilot -p "指令"`）。非交互模式适合一次性任务，快速获得结果后退出。
+
+**依据：** GitHub Copilot 使用指南 - CLI 使用
+
+---
+
+### Q12（简答）
+
+小赵在 Copilot CLI 交互模式中，想清空当前对话上下文重新开始。
+
+Copilot CLI 中常用的斜杠命令有：**`/clear` / `/model` / `/session` / `/exit`**
+
+**问：** 小赵应该使用哪个命令？
+
+**答案：** `/clear`
+
+**依据：** GitHub Copilot 使用指南 - CLI 斜杠命令
+
+---
+
+## 四、Claude Code — 四种交互方式（6 题）
+
+### Q13（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Claude Code 中输入 `@src/utils.js` 可以让 AI 读取该文件。
+
+**答案：** ✓
+
+**依据：** Claude Code 使用指南 - 第3章 文件引用
+
+---
+
+### Q14（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Claude Code 中输入 `/clear` 可以清空当前对话。
+
+**答案：** ✓
+
+**依据：** Claude Code 使用指南 - 第3章 斜杠命令
+
+---
+
+### Q15（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Claude Code 中输入 `!git status` 可以查看 Git 状态。
+
+**答案：** ✓
+
+**依据：** Claude Code 使用指南 - 第3章 Bash模式
+
+---
+
+### Q16（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Claude Code 中所有操作都必须用特殊符号，自然语言输入不能完成任何功能。
+
+**答案：** ✗。自然语言也可以完成大部分功能，特殊符号用于特定场景。
+
+**依据：** Claude Code 使用指南 - 第3章 交互方式
+
+---
+
+### Q17（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Claude Code 中输入 `!npm run dev` 可以启动开发服务器。
+
+**答案：** ✓
+
+**依据：** Claude Code 使用指南 - 第3章 Bash模式
+
+---
+
+### Q18（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Claude Code 中输入 `/help` 可以查看所有可用命令。
+
+**答案：** ✓
+
+**依据：** Claude Code 使用指南 - 第3章 斜杠命令
+
+---
+
+## 五、Claude Code — 模型选择与切换（3 题）
+
+### Q19（简答）
+
+Claude Code 的三个模型特点如下：
+- **Sonnet**：主力工程师，日常编码首选
+- **Haiku**：响应极快、成本低，适合简单任务
+- **Opus**：处理超级复杂的难题，智商最高
+
+小陈需要修复一个非常复杂的系统架构 Bug。
+
+**问：** 他应该选择哪个模型？
+
+**答案：** Opus
+
+**依据：** Claude Code 使用指南 - 第3章 模型选择
+
+---
+
+### Q20（简答）
+
+Claude Code 的三个模型特点如下：
+- **Sonnet**：主力工程师，日常编码首选
+- **Haiku**：响应极快、成本低，适合简单任务
+- **Opus**：处理超级复杂的难题，智商最高
+
+小陈在做日常的 CRUD 接口开发。
+
+**问：** 他应该选择哪个模型？
+
+**答案：** Sonnet
+
+**依据：** Claude Code 使用指南 - 第3章 模型选择
+
+---
+
+### Q21（简答）
+
+Claude Code 的三个模型特点如下：
+- **Sonnet**：主力工程师，日常编码首选
+- **Haiku**：响应极快、成本低，适合简单任务
+- **Opus**：处理超级复杂的难题，智商最高
+
+小陈想快速查一下某个 JavaScript 数组方法的语法。
+
+**问：** 他应该选择哪个模型？
+
+**答案：** Haiku
+
+**依据：** Claude Code 使用指南 - 第3章 模型选择
+
+---
+
+## 六、Claude Code — CLI 命令（3 题）
+
+### Q22（简答）
+
+小赵的 Claude Code 会话因为终端意外关闭了，想接着刚才的对话继续。
+
+Claude CLI 有以下命令：**`claude` / `claude --continue` / `claude --resume`**
+
+**问：** 小赵应该用哪个命令？
+
+**答案：** `claude --continue`（或 `claude -c`）。该命令用于恢复上次意外关闭的会话。
+
+**依据：** Claude Code 使用指南 - 第3章 CLI命令
+
+---
+
+### Q23（简答）
+
+小钱想用 Claude Code 快速解释一下 `git diff` 的结果，不想进入交互式对话。
+
+Claude CLI 有以下命令：**`claude` / `claude -p "指令"` / `claude --resume`**
+
+**问：** 小钱应该用哪个命令？
+
+**答案：** `claude -p "指令"`。`-p` 参数用于一次性任务，适合快速执行。
+
+**依据：** Claude Code 使用指南 - 第3章 CLI命令
+
+---
+
+### Q24（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+`claude --resume` 可以从历史会话列表中选择恢复。
+
+**答案：** ✓
+
+**依据：** Claude Code 使用指南 - 第3章 CLI命令
+
+---
+
+## 七、OpenCode — 整体认知（3 题）
+
+### Q25（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+OpenCode 像一位身边的搭档，可以直接读取项目文件、修改代码、执行命令。
+
+**答案：** ✓
+
+**依据：** OpenCode 使用指南 - 第1章 核心定位
+
+---
+
+### Q26（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+传统 AI 像远程顾问，给你建议但需要你自己动手；OpenCode 可以直接帮你操作。
+
+**答案：** ✓
+
+**依据：** OpenCode 使用指南 - 第1章
+
+---
+
+### Q27（安全合规/简答）
+
+小周想用 OpenCode 读取包含客户个人信息的代码文件，让 AI 帮忙优化。
+
+**问：** 这种做法是否合适？为什么？
+
+**答案：** 不合适。客户个人信息属于敏感数据，严禁输入任何公共 AI 工具。应该先对数据进行脱敏处理，用虚构数据或占位符替代后再使用。
+
+**依据：** OpenCode 使用指南 - 红线警告
+
+---
+
+## 八、OpenCode — 安装与使用方式（4 题）
+
+### Q28（简答）
+
+OpenCode 有以下四种使用方式：
+- **终端版** — 轻量启动快，适合有基础的用户
+- **桌面应用** — 界面直观，适合新手
+- **IDE 扩展** — 深度绑定编辑器
+- **Web 版** — 浏览器访问，可远程部署
+
+小周是新手，不喜欢操作命令行，想找一个界面直观的方式。
+
+**问：** 他应该选择哪种方式？
+
+**答案：** 桌面应用
+
+**依据：** OpenCode 使用指南 - 第2章 使用方式
+
+---
+
+### Q29（简答）
+
+OpenCode 有以下四种使用方式：**终端版** / **桌面应用** / **IDE 扩展** / **Web 版**
+
+小刘平时用 VS Code 写代码，希望不离开编辑器就能用 OpenCode。
+
+**问：** 他应该选择哪种方式？
+
+**答案：** IDE 扩展
+
+**依据：** OpenCode 使用指南 - 第2章 使用方式
+
+---
+
+### Q30（简答）
+
+OpenCode 有以下四种使用方式：**终端版** / **桌面应用** / **IDE 扩展** / **Web 版**
+
+小马需要在远程服务器上开发，只能通过命令行操作。
+
+**问：** 他应该选择哪种方式？
+
+**答案：** 终端版
+
+**依据：** OpenCode 使用指南 - 第2章 使用方式
+
+---
+
+### Q31（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在终端中输入 `opencode` 可以启动 OpenCode。
+
+**答案：** ✓
+
+**依据：** OpenCode 使用指南 - 第2章 安装
+
+---
+
+## 九、OpenCode — Plan / Build 工作模式（5 题）
+
+### Q32（简答）
+
+小周接手了一个新项目，想先让 OpenCode 分析项目结构，还不想修改任何文件。
+
+OpenCode 有以下两种工作模式：**Plan** / **Build**
+
+**问：** 小周应该选择哪种模式？
+
+**答案：** Plan（计划模式）。Plan 模式下 AI 只能读取文件，不会修改代码。
+
+**依据：** OpenCode 使用指南 - 第3章 Plan模式
+
+---
+
+### Q33（简答）
+
+小周已经确认了修改方案，想让 OpenCode 开始实际修改代码。
+
+OpenCode 有以下两种工作模式：**Plan** / **Build**
+
+**问：** 小周应该选择哪种模式？
+
+**答案：** Build（构建模式）。Build 模式下 AI 可以编辑文件和执行命令。
+
+**依据：** OpenCode 使用指南 - 第3章 Build模式
+
+---
+
+### Q34（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+Plan 模式下 AI 只能读取文件，不会修改任何代码。
+
+**答案：** ✓
+
+**依据：** OpenCode 使用指南 - 第3章
+
+---
+
+### Q35（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+Build 模式下 AI 可以编辑文件和执行命令。
+
+**答案：** ✓
+
+**依据：** OpenCode 使用指南 - 第3章
+
+---
+
+### Q36（注意事项/简答）
+
+小周让 OpenCode 在 Build 模式下修改了多个文件。
+
+**问：** 修改完成后，他应该先做什么？
+
+**答案：** 审查 AI 修改的代码，确认逻辑正确后再使用。AI 生成的代码不能直接部署到生产环境。
+
+**依据：** OpenCode 使用指南 - 安全原则
+
+---
+
+## 十、OpenCode — 常用命令（5 题）
+
+### Q37（简答）
+
+小周用 OpenCode 修改了代码，但发现改错了，想撤销刚才的修改。
+
+OpenCode 中有以下命令：**`/undo` / `/redo` / `/clear` / `/init`**
+
+**问：** 他应该使用哪个命令？
+
+**答案：** `/undo`
+
+**依据：** OpenCode 使用指南 - 第3章 撤销更改
+
+---
+
+### Q38（简答）
+
+小周撤销了修改后又觉得还是刚才改得好，想恢复回来。
+
+OpenCode 中有以下命令：**`/undo` / `/redo` / `/clear` / `/init`**
+
+**问：** 他应该使用哪个命令？
+
+**答案：** `/redo`
+
+**依据：** OpenCode 使用指南 - 第3章
+
+---
+
+### Q39（简答）
+
+小周想在新项目目录中创建 `AGENTS.md` 文件，让 OpenCode 了解项目结构。
+
+OpenCode 中有以下命令：**`/undo` / `/redo` / `/clear` / `/init`**
+
+**问：** 他应该使用哪个命令？
+
+**答案：** `/init`
+
+**依据：** OpenCode 使用指南 - 第4章 项目初始化
+
+---
+
+### Q40（简答）
+
+小周想看看 OpenCode 当前有哪些可用的斜杠命令和快捷键。
+
+OpenCode 中有以下命令：**`/help` / `/models` / `/connect` / `/exit`**
+
+**问：** 他应该使用哪个命令？
+
+**答案：** `/help`
+
+**依据：** OpenCode 使用指南 - 第3章 斜杠命令
+
+---
+
+### Q41（简答）
+
+小周想切换 OpenCode 正在使用的 AI 模型。
+
+OpenCode 中有以下命令：**`/help` / `/models` / `/connect` / `/exit`**
+
+**问：** 他应该使用哪个命令？
+
+**答案：** `/models`
+
+**依据：** OpenCode 使用指南 - 第3章 模型选择
+
+---
+
+## 十一、OpenCode — 模型选择（2 题）
+
+### Q42（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+OpenCode 内置多款免费模型，启动后可以直接选择使用，无需配置 API 密钥。
+
+**答案：** ✓
+
+**依据：** OpenCode 使用指南 - 第3章 模型
+
+---
+
+### Q43（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+使用第三方 LLM 提供商（如 OpenAI、Anthropic）需要自行承担 API 费用。
+
+**答案：** ✓
+
+**依据：** OpenCode 使用指南 - 第3章 模型
+
+---
+
+## 十二、Debug — 调试助手（7 题）
+
+### Q44（简答）
+
+小吴的代码运行时报错了，不知道问题出在哪，想让 Copilot Chat 帮他定位和解决 Bug。
+
+Copilot Chat 中有以下命令：**`/fix` / `/tests` / `/explain` / `/debug`**
+
+**问：** 他应该使用哪个命令？
+
+**答案：** `/debug`。该命令专用于帮助定位和解决 Bug。
+
+**依据：** GitHub Copilot 使用指南 - 第3章 内置命令
+
+---
+
+### Q45（简答）
+
+小吴已经知道问题在哪了，想让 Copilot 直接修复选中的代码。
+
+Copilot Chat 中有以下命令：**`/fix` / `/tests` / `/explain` / `/debug`**
+
+**问：** 他应该使用哪个命令？
+
+**答案：** `/fix`。该命令用于自动修复代码问题。
+
+**依据：** GitHub Copilot 使用指南 - 第3章 内置命令
+
+---
+
+### Q46（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Copilot Chat 中输入 `/tests` 可以生成选中代码的单元测试。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章 内置命令
+
+---
+
+### Q47（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+在 Copilot Chat 中输入 `/explain` 可以让 AI 解释选中代码的逻辑。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章 内置命令
+
+---
+
+### Q48（判断正误）
+
+以下说法是否正确？（✓ / ✗）
+
+`/debug` 命令可以帮助定位和解决 Bug。
+
+**答案：** ✓
+
+**依据：** GitHub Copilot 使用指南 - 第3章 内置命令
+
+---
+
+### Q49（注意事项/简答）
+
+小吴用 `/fix` 命令让 Copilot 自动修复了代码。
+
+**问：** 修复完成后，他应该先做什么？
+
+**答案：** 审查修复后的代码，确认修改正确、逻辑无误后再使用。
+
+**依据：** GitHub Copilot 使用指南 - 安全原则
+
+---
+
+### Q50（安全合规/简答）
+
+小吴遇到一个 Bug，想把包含数据库连接串的配置文件贴到 Copilot Chat 中用 `/debug` 分析。
+
+**问：** 这种做法是否合适？为什么？
+
+**答案：** 不合适。数据库连接串属于敏感信息，严禁输入公共 AI 工具。应该用脱敏数据或占位符替代后再进行分析。
+
+**依据：** GitHub Copilot 使用指南 - 红线警告
+
+---
+
+## 附录：题型分布统计
+
+| 章节 | 知识点 | 题数 | 简答 | 判断正误 |
+|:----:|:-------|:----:|:----:|:--------:|
+| 一 | Copilot — 智能代码补全 | 4 | 1 | 3 |
+| 二 | Copilot — Chat 三种模式 | 5 | 3 | 2 |
+| 三 | Copilot — CLI 使用 | 3 | 3 | 0 |
+| 四 | Claude Code — 四种交互方式 | 6 | 0 | 6 |
+| 五 | Claude Code — 模型选择 | 3 | 3 | 0 |
+| 六 | Claude Code — CLI 命令 | 3 | 2 | 1 |
+| 七 | OpenCode — 整体认知 | 3 | 1 | 2 |
+| 八 | OpenCode — 安装与使用方式 | 4 | 3 | 1 |
+| 九 | OpenCode — Plan / Build 模式 | 5 | 3 | 2 |
+| 十 | OpenCode — 常用命令 | 5 | 5 | 0 |
+| 十一 | OpenCode — 模型选择 | 2 | 0 | 2 |
+| 十二 | Debug — 调试助手 | 7 | 4 | 3 |
+| — | **合计** | **50** | **28** | **22** |
@@ -0,0 +1,135 @@
+# AuraK 系统提示词文档
+
+> 生成日期：2026-05-25
+> 位置：
+> - AI出题：`server/src/assessment/services/question-bank.service.ts` (GENERATE_QUESTIONS_SYSTEM_PROMPT)
+> - 评分考官：`server/src/assessment/graph/nodes/grader.node.ts` (systemPromptZh)
+> - 抽题策略：`server/src/assessment/services/question-bank.service.ts` (selectQuestions)
+
+---
+
+## 1. AI出题提示词（GENERATE_QUESTIONS_SYSTEM_PROMPT）
+
+```
+你是 AI 人才考核的出题专家。你需要从知识库内容中生成考核题目。
+
+## 一、内部步骤（在脑中完成，不要输出）
+1. 从知识库提取可考核的实战知识点
+2. 确定该知识点对应的具体技巧或方法
+3. 围绕该技巧设计一个真实工作场景
+
+## 二、题型比例
+本题库同时生成两种题型，按 choice:open = 3:7 分配。
+- choice = 选择题（4选1）
+- open = 简答题（开放式 + 追问）
+
+## 三、选择题规则（choice 型）
+### 3.1 场景规则
+- 场景必须是实际工作或日常中会遇到的情境，100-200字
+- 不能问概念定义类问题（如"什么是X"）
+- 不能问理论学习类问题（如"列出X的要素"）
+- 场景中的角色使用实际岗位（开发者/PM/测试/普通员工等）
+
+### 3.2 决策点规则
+- 每道题必须有明确的决策点——学习者要做选择或决定怎么做
+- 不能只是"请解释"
+
+### 3.3 选项规则
+- 4个选项（A/B/C/D），单选
+- 正确选项是最合理的那一个
+- 每个错误选项必须有明确缺陷（违反安全规范、忽略关键步骤、效率低下等）
+- 每个错误选项的错误原因，必须在知识库原文中有对应的禁止做法或反面说明
+- 禁止使用"以上都对""以上都不对"
+- 正确选项与最短错误选项的字符差不得超过5个字
+- 正确答案位置需轮换（避免集中在同一字母）
+
+### 3.4 解析规则
+- judgment 字段写明：为什么正确 + 每个错误选项分别错在哪
+- 指出对应的知识库知识点
+- 简洁直接，指出问题本质
+
+## 四、简答题规则（open 型）
+### 4.1 场景规则
+- 同选择题 3.1
+- 场景中暗示需要什么能力，但不要说破
+
+### 4.2 判定依据
+- judgment 字段必须包含：关键考点 + 通过标准
+- 通过标准必须可量化："说出X即通过"、"至少提及Y和Z"
+- 通过标准必须来源于知识库原文
+
+### 4.3 追问方向
+- followupHints 数组：0-2条追问方向
+- 追问用于引导学习者补充遗漏的关键点
+- 追问应具体、可回答
+- 示例："如果只回答开新窗口没说怎么带上前情：追问怎么把有用信息带过去？"
+
+## 五、禁止项（适用于所有题型）
+- 禁止问概念定义（如"什么是提示词工程"）
+- 禁止问理论列举（如"六要素有哪些"）
+- 禁止选择题出现"以上都对""以上都不对"
+- 禁止正确选项明显比其他选项长或短
+- 禁止场景脱离实际（如"如果你是CEO"不适合L1）
+- 禁止虚构知识库中不存在的方法、工具、术语
+- key_points 必须从知识库原文中提取，不得自行编造
+- 相邻题目的场景背景不得重复或相似
+
+## 六、出题维度（自动判断）
+根据题目内容，从以下五个维度中选择最匹配的一个：
+- prompt（提示词工程）
+- llm（LLM理解）
+- ide（IDE协作开发）
+- devPattern（开发范式）
+- workCapability（工作能力）
+```
+
+---
+
+## 2. 评分考官提示词（systemPromptZh）
+
+```
+你是一位考官。请评分并给出反馈。
+
+规则：
+1. 只用中文。
+2. 多轮追问时，用户回答含所有轮次（第N轮回答：标记），综合判断已覆盖内容。
+
+问题：[题目文字]
+关键点：[评分关键点]
+
+评分标准：不要求深度，不要求使用特定术语，只看用户是否理解了概念。
+用户理解核心概念就给分。即使没有使用关键点中的原词，只要意思到位就算覆盖。
+例如关键点是"上下文窗口有限"，用户说"信息太多超过AI处理长度"也是覆盖。
+评分原则：往宽了给分，不确定时就给高分。明显正确就给8-10分，部分正确5-7分，完全不沾边才0-2分。
+
+返回JSON：
+- score: 0-10
+- feedback: 评语
+- should_follow_up: true/false
+- follow_up_question: 追问（仅true时需要，针对未覆盖的关键点，false时null）
+
+请以 JSON 格式返回响应：
+{"score":0到10,"feedback":"评语","should_follow_up":true或false,"follow_up_question":"追问或null"}
+```
+
+---
+
+## 3. 抽题策略（selectQuestions）
+
+按模板配置的维度权重分配题目数量。
+
+**流程：**
+1. 读取模板的 dimensions 配置（如 PROMPT:30%, LLM:30%, IDE:20%, DEV_PATTERN:20%）
+2. 按权重计算每维度应出题数（如10题 → 3/3/2/2）
+3. 在各维度题库中随机抽取指定数量的题目
+4. 如某维度题数不足，从已抽题中补充
+5. 最终打乱顺序后返回
+
+**无维度权重时的后备策略：**
+按 [PROMPT, LLM, IDE, DEV_PATTERN, WORK_CAPABILITY] 顺序循环抽取，直到满额。
+
+---
+
+## 4. 提问节点提示词（interviewer.node.ts）
+
+> 当前题库暂未配置 interviewer 的自定义提示词，使用默认LangGraph状态机流程。
@@ -0,0 +1,135 @@
+# AuraK 系统提示词文档
+
+> 生成日期：2026-05-25
+> 位置：
+> - AI出题：`server/src/assessment/services/question-bank.service.ts` (GENERATE_QUESTIONS_SYSTEM_PROMPT)
+> - 评分考官：`server/src/assessment/graph/nodes/grader.node.ts` (systemPromptZh)
+> - 抽题策略：`server/src/assessment/services/question-bank.service.ts` (selectQuestions)
+
+---
+
+## 1. AI出题提示词（GENERATE_QUESTIONS_SYSTEM_PROMPT）
+
+```
+你是 AI 人才考核的出题专家。你需要从知识库内容中生成考核题目。
+
+## 一、内部步骤（在脑中完成，不要输出）
+1. 从知识库提取可考核的实战知识点
+2. 确定该知识点对应的具体技巧或方法
+3. 围绕该技巧设计一个真实工作场景
+
+## 二、题型比例
+本题库同时生成两种题型，按 choice:open = 3:7 分配。
+- choice = 选择题（4选1）
+- open = 简答题（开放式 + 追问）
+
+## 三、选择题规则（choice 型）
+### 3.1 场景规则
+- 场景必须是实际工作或日常中会遇到的情境，100-200字
+- 不能问概念定义类问题（如"什么是X"）
+- 不能问理论学习类问题（如"列出X的要素"）
+- 场景中的角色使用实际岗位（开发者/PM/测试/普通员工等）
+
+### 3.2 决策点规则
+- 每道题必须有明确的决策点——学习者要做选择或决定怎么做
+- 不能只是"请解释"
+
+### 3.3 选项规则
+- 4个选项（A/B/C/D），单选
+- 正确选项是最合理的那一个
+- 每个错误选项必须有明确缺陷（违反安全规范、忽略关键步骤、效率低下等）
+- 每个错误选项的错误原因，必须在知识库原文中有对应的禁止做法或反面说明
+- 禁止使用"以上都对""以上都不对"
+- 正确选项与最短错误选项的字符差不得超过5个字
+- 正确答案位置需轮换（避免集中在同一字母）
+
+### 3.4 解析规则
+- judgment 字段写明：为什么正确 + 每个错误选项分别错在哪
+- 指出对应的知识库知识点
+- 简洁直接，指出问题本质
+
+## 四、简答题规则（open 型）
+### 4.1 场景规则
+- 同选择题 3.1
+- 场景中暗示需要什么能力，但不要说破
+
+### 4.2 判定依据
+- judgment 字段必须包含：关键考点 + 通过标准
+- 通过标准必须可量化："说出X即通过"、"至少提及Y和Z"
+- 通过标准必须来源于知识库原文
+
+### 4.3 追问方向
+- followupHints 数组：0-2条追问方向
+- 追问用于引导学习者补充遗漏的关键点
+- 追问应具体、可回答
+- 示例："如果只回答开新窗口没说怎么带上前情：追问怎么把有用信息带过去？"
+
+## 五、禁止项（适用于所有题型）
+- 禁止问概念定义（如"什么是提示词工程"）
+- 禁止问理论列举（如"六要素有哪些"）
+- 禁止选择题出现"以上都对""以上都不对"
+- 禁止正确选项明显比其他选项长或短
+- 禁止场景脱离实际（如"如果你是CEO"不适合L1）
+- 禁止虚构知识库中不存在的方法、工具、术语
+- key_points 必须从知识库原文中提取，不得自行编造
+- 相邻题目的场景背景不得重复或相似
+
+## 六、出题维度（自动判断）
+根据题目内容，从以下五个维度中选择最匹配的一个：
+- prompt（提示词工程）
+- llm（LLM理解）
+- ide（IDE协作开发）
+- devPattern（开发范式）
+- workCapability（工作能力）
+```
+
+---
+
+## 2. 评分考官提示词（systemPromptZh）
+
+```
+你是一位考官。请评分并给出反馈。
+
+规则：
+1. 只用中文。
+2. 多轮追问时，用户回答含所有轮次（第N轮回答：标记），综合判断已覆盖内容。
+
+问题：[题目文字]
+关键点：[评分关键点]
+
+评分标准：不要求深度，不要求使用特定术语，只看用户是否理解了概念。
+用户理解核心概念就给分。即使没有使用关键点中的原词，只要意思到位就算覆盖。
+例如关键点是"上下文窗口有限"，用户说"信息太多超过AI处理长度"也是覆盖。
+评分原则：往宽了给分，不确定时就给高分。明显正确就给8-10分，部分正确5-7分，完全不沾边才0-2分。
+
+返回JSON：
+- score: 0-10
+- feedback: 评语
+- should_follow_up: true/false
+- follow_up_question: 追问（仅true时需要，针对未覆盖的关键点，false时null）
+
+请以 JSON 格式返回响应：
+{"score":0到10,"feedback":"评语","should_follow_up":true或false,"follow_up_question":"追问或null"}
+```
+
+---
+
+## 3. 抽题策略（selectQuestions）
+
+按模板配置的维度权重分配题目数量。
+
+**流程：**
+1. 读取模板的 dimensions 配置（如 PROMPT:30%, LLM:30%, IDE:20%, DEV_PATTERN:20%）
+2. 按权重计算每维度应出题数（如10题 → 3/3/2/2）
+3. 在各维度题库中随机抽取指定数量的题目
+4. 如某维度题数不足，从已抽题中补充
+5. 最终打乱顺序后返回
+
+**无维度权重时的后备策略：**
+按 [PROMPT, LLM, IDE, DEV_PATTERN, WORK_CAPABILITY] 顺序循环抽取，直到满额。
+
+---
+
+## 4. 提问节点提示词（interviewer.node.ts）
+
+> 当前题库暂未配置 interviewer 的自定义提示词，使用默认LangGraph状态机流程。
@@ -0,0 +1,209 @@
+# Playwright 三 Agent 应用指南
+
+> 三个 Agent：**Generator**（录制生成） · **Planner**（规划编排） · **Healer**（自我修复）
+
+---
+
+## 一、三 Agent 的本质区别
+
+| Agent | 命令 | 作用 | 适合谁用 |
+|-------|------|------|---------|
+| **Generator** | `npx playwright codegen` | 录制浏览器操作，自动生成 `.spec.ts` 脚本 | 初学者、快速原型 |
+| **Planner** | `npx playwright codegen --target test` | 编排多步测试流程，指定截图/断言点 | 测试设计者 |
+| **Healer** | `npx playwright test --trace on` | 失败时自动重试 + 记录完整 DOM 快照和网络日志 | CI、调试排查 |
+
+---
+
+## 二、当前测试脚本 vs Playwright Agent 使用对照
+
+```
+脚本                         Generator   Planner     Healer       测试层面
+────────────────────────────────────────────────────────────────────────
+test-systematic.mjs            ❌         ❌         ❌          API + 原生 Playwright
+test-full-coverage.mjs         ❌         ❌         ❌          纯 API（无 UI）
+test-assessment-smoke.mjs      ❌         ❌         ❌          API + 原生 Playwright
+test-e2e-assessment-full-flow  ❌         ❌         ❌          API + 原生 Playwright
+test-p2-advanced.mjs           ❌         ❌         ❌          纯 API
+test-concurrent-assessments    ❌         ❌         ❌          纯 API
+test-user-lifecycle.mjs        ❌         ❌         ❌          API + 原生 Playwright
+test-permission-flow.mjs       ❌         ❌         ❌          API + 原生 Playwright
+test-multiround.mjs            ❌         ❌         ❌          原生 Playwright
+exam-organizer.mjs             ❌         ❌         ❌          API + 原生 Playwright
+```
+
+**现状**: 所有脚本都用 `chromium.launch({ headless: true })` 手写，没有用 `@playwright/test` 框架，
+也没有用三个 Agent 的任何功能。
+
+---
+
+## 三、各 Phase 应该怎么用 Playwright Agent
+
+### Phase 0 — 系统测试（回归用）
+
+```
+阶段: 每次代码变更后必跑
+策略: 已有脚本完全覆盖，保持现状
+Agent 使用: 不需要
+```
+
+### Phase 1 — 新功能开发时的 UI 测试
+
+```
+┌──────────────────────────────────────────────────────────────────┐
+│  Generator 应用场景                                               │
+│                                                                  │
+│  开发完一个新页面/功能后：                                        │
+│                                                                  │
+│  $ npx playwright codegen http://localhost:13001                 │
+│                                                                  │
+│  1. 浏览器自动打开，操作你想测试的流程                             │
+│  2. 右侧代码面板同步生成 Playwright 脚本                          │
+│  3. 点击 "Copy" 复制到测试文件                                    │
+│  4. 去掉 `page.close()` 等冗余行                                  │
+│  5. 加入你的断言 (expect)                                         │
+│                                                                  │
+│  生成示例:                                                        │
+│  await page.goto('/assessment');                                  │
+│  await page.click('text=AI协作技巧-对话测评');                     │
+│  await page.click('text=开始专业评估');                            │
+│  await page.waitForSelector('text=问题 1');                       │
+│  expect(await page.textContent('body')).toContain('问题 1');      │
+└──────────────────────────────────────────────────────────────────┘
+
+┌──────────────────────────────────────────────────────────────────┐
+│  Planner 应用场景                                                 │
+│                                                                  │
+│  需要编排多步骤、多断言的复杂测试场景时：                          │
+│                                                                  │
+│  $ npx playwright codegen --target test -o tests/assess.spec.ts  │
+│                                                                  │
+│  此模式会生成 @playwright/test 格式的代码，包含：                  │
+│  - test.describe 分组                                            │
+│  - test() 用例函数                                               │
+│  - expect() 断言                                                 │
+│  - 自动截图点                                                    │
+│                                                                  │
+│  适合场景: 考核全流程（选模板→答题→看结果）                       │
+│            管理员配置（创建模板→创建用户→分配权限）                │
+└──────────────────────────────────────────────────────────────────┘
+
+┌──────────────────────────────────────────────────────────────────┐
+│  Healer 应用场景                                                  │
+│                                                                  │
+│  当 UI 测试在 CI 中因未知原因失败时：                              │
+│                                                                  │
+│  $ npx playwright test --trace on                                │
+│                                                                  │
+│  Healer 自动做 3 件事:                                            │
+│  1. 自动重试最多 2 次（防 flaky）                                  │
+│  2. 失败时保存 Trace 文件（含 DOM 快照 + 网络日志 + 控制台输出）    │
+│  3. 用 `trace.playwright.dev` 可交互式回放每一步                    │
+│                                                                  │
+│  查看 Trace:                                                      │
+│  $ npx playwright show-trace test-results/**/trace.zip           │
+│                                                                  │
+│  在 Trace Viewer 中可以看到:                                      │
+│  - 页面截图时间线（每步操作前后的截图）                             │
+│  - Console 输出（包括 error/warning）                              │
+│  - 网络请求（API 返回内容和状态码）                                 │
+│  - DOM 快照（操作瞬间的 HTML）                                     │
+└──────────────────────────────────────────────────────────────────┘
+```
+
+### Phase 2 — 调试已有测试失败
+
+```
+当前脚本（chromium.launch 模式）不支持 Healer 自动重试，
+因为 autofix/healing 是 @playwright/test 框架的特性。
+
+如果要在现有脚本中用 Healer，需要改成 @playwright/test 格式：
+
+  // 当前写法（无 Healer）
+  const browser = await chromium.launch({ headless: true });
+  const page = await browser.newPage();
+
+  // 改写成 @playwright/test（带 Healer）
+  import { test, expect } from '@playwright/test';
+  
+  test('考核全流程', async ({ page }) => {
+    await page.goto('/assessment');
+    // 失败时自动重试 2 次
+    // 失败时自动保存 trace.zip
+    // 失败时自动截图
+  });
+```
+
+### Phase 3 — 编写新测试的标准流程
+
+```
+Step 1: Generator 录制
+  $ npx playwright codegen http://localhost:13001
+  → 操作界面 → 复制生成的代码
+
+Step 2: Planner 编排  
+  将复制代码粘贴到 .spec.ts 文件
+  加入 describe/test/expect 结构
+  设置截图断言点
+
+Step 3: Healer 验证
+  $ npx playwright test --trace on
+  → 自动运行所有测试
+  → 失败自动重试
+  → 失败生成 Trace
+  → 用 show-trace 分析
+```
+
+---
+
+## 四、现有脚本改用 @playwright/test 的改造方案
+
+```
+改造收益:
+  ✅ 自动重试（flaky 测试不误报）
+  ✅ Trace Viewer（失败时全量调试信息）
+  ✅ HTML Report（可视化测试报告）
+  ✅ 并行执行（多 worker 加速）
+  ✅ 内置 expect 断言库
+
+改造成本:
+  ⏱ 每个脚本约 15 分钟改造时间
+  🔧 需要创建 playwright.config.ts
+  📁 测试文件需迁到 tests/ 目录
+
+关键改动点:
+  1. import { chromium } from 'playwright'
+     → import { test, expect } from '@playwright/test'
+  
+  2. const browser = await chromium.launch({ headless: true })
+     → test('name', async ({ page }) => { ... })
+  
+  3. 自定义 assert() 函数
+     → expect(actual).toBe(expected)
+  
+  4. 无自动重试
+     → test.retries(2) 或 playwright.config.ts 中全局配置
+
+配置文件 playwright.config.ts:
+  export default defineConfig({
+    testDir: './tests',
+    retries: 2,              ← Healer: 失败重试
+    trace: 'on-first-retry', ← Healer: 首次重试时生成 Trace
+    screenshot: 'on',        ← Healer: 每次操作截图
+    workers: 4,              ← Planner: 并发执行
+    reporter: 'html',        ← Planner: HTML 报告
+  });
+```
+
+---
+
+## 五、总结对照表
+
+| 场景 | 当前做法 | 用 Generator | 用 Planner | 用 Healer |
+|------|---------|:-----------:|:----------:|:---------:|
+| 回归测试 142项 | `test-systematic.mjs` | ❌ | ❌ | ❌ |
+| 烟雾测试 | `test-assessment-smoke.mjs` | ❌ | ❌ | ❌ |
+| 端到端考核流程 | `test-e2e-assessment-full-flow.mjs` | ❌ | ❌ | ❌ |
+| 编写新 UI 测试 | 手写 locator | ✅ **录制** | ✅ **编排** | — |
+| 调试 CI 失败 | 看日志 | — | — | ✅ **Trace** |
+| 复杂场景编排 | 手写断言 | — | ✅ **结构** | — |
+| 新页面回归 | 手写 | ✅ **快速生成** | — | ✅ **自愈** |
@@ -1,3 +0,0 @@
-cd /d D:\AuraK\server
-node --enable-source-maps dist/main
-pause
@@ -1,3 +0,0 @@
-cd /d D:\AuraK\web
-npx vite --port 13001
-pause