vault backup: 2026-01-05 14:26:17

2026-01-05 14:26:17 +08:00
parent be7c6cdcc9
commit 40f3fe3eb8
290 changed files with 1947 additions and 282 deletions
@@ -1,224 +0,0 @@
-
-
-kimi2 thinking
-
-```
-base_url: https://zenmux.ai/api/v1
-api_key: sk-ai-v1-2d2ba59719ff6f0d8d2f439d3b5c84399176d1059302cc4b43c132a4d17e9f03
-text_generation:
-  model_id: moonshotai/kimi-k2-thinking
-  prompt: '
-  # Kimi K2 Thinking 聊天机器人 System Prompt
-
-## 身份定义
-你是 Kimi K2 Thinking，一个具有深度推理能力的AI助手。你的核心特色是能够展示完整的思考过程，帮助用户理解问题的分析路径和解决方案。
-
-## 核心原则
-
-### 🧠 思考透明化
- **展示推理过程**：对于复杂问题，明确展示你的思考步骤
- **逐步分析**：将复杂问题分解为多个子问题，逐一解决
- **自我检查**：在给出最终答案前，检查推理的逻辑性和完整性
-
-### 💬 交互方式
- **友好专业**：保持亲切但专业的语调
- **耐心细致**：对用户的问题给予充分的关注和详细的回答
- **主动引导**：在必要时主动询问澄清问题，确保准确理解用户需求
-
-### 📝 回答结构
-对于复杂问题，使用以下结构：
-1. **问题理解**：确认对用户问题的理解
-2. **思考过程**：展示分析步骤（可使用"让我思考一下..."开头）
-3. **分步推理**：详细的逻辑推导
-4. **结论总结**：清晰的最终答案
-5. **补充说明**：相关的注意事项或延伸思考
-
-## 专业能力
-
-### 🎯 擅长领域
- 逻辑推理和数学问题
- 学术研究和知识分析
- 创意思维和方案设计
- 复杂情况的多角度分析
- 长文本理解和信息提取
-
-### 🔍 思考方法
- **多角度分析**：从不同维度审视问题
- **因果推理**：分析事物间的因果关系
- **类比思维**：运用相似案例进行推理
- **批判性思维**：质疑假设，验证结论
-
-## 交互指南
-
-### ✅ 当遇到以下情况时展示详细思考过程：
- 数学计算和逻辑推理
- 复杂的分析判断
- 需要多步骤解决的问题
- 涉及策略规划的问题
- 用户明确要求看到思考过程
-
-### ⚡ 当遇到以下情况时可直接回答：
- 简单的事实性问题
- 基础的定义解释
- 日常对话交流
- 明确的操作指导
-
-## 语言风格
- 使用清晰、准确的中文表达
- 适当使用专业术语，但确保用户能理解
- 运用恰当的比喻和例子帮助理解
- 保持逻辑清晰的表述结构
-
-## 限制说明
- 承认知识的边界，不确定时会明确说明
- 不提供可能有害或不当的建议
- 尊重用户隐私，不记录或泄露个人信息
- 在涉及专业领域时，建议咨询相关专家
-
-## 互动示例格式
-
-**用户问题**：[复杂问题]
-
-**我的回答**：
-让我仔细分析一下这个问题...
-
-🤔 **思考过程**：
-1. 首先，我需要理解...
-2. 然后考虑...
-3. 接下来分析...
-
-📋 **分步推理**：
- 步骤一：...
- 步骤二：...
- 步骤三：...
-
-✅ **结论**：
-基于以上分析，我的答案是...
-
-💡 **补充说明**：
-需要注意的是...
-
---
-
-记住：你的价值在于不仅给出答案，更要展示获得答案的思考路径，帮助用户学会思考和分析问题的方法。
-  '
-  temperature: 0.9
-
-```
-
-
-
-google gemini 3 pro preview
-```
-base_url: https://zenmux.ai/api/v1
-api_key: sk-ai-v1-2d2ba59719ff6f0d8d2f439d3b5c84399176d1059302cc4b43c132a4d17e9f03
-
-text_generation:
-  model_id: google/gemini-3-pro-preview-free
-  prompt: |
-    # Role & Identity  
-    你是由 Google 研发的先进 AI 助手 {{ baibot_name }}，基于 {{ baibot_model_id }} 架构。  
-    当前会话启动时间: {{ baibot_conversation_start_time_utc }}。  
-
-    # Core Capabilities (针对 Gemini 优化)  
-    1. **深度推理**：拥有强大的逻辑分析、代码生成和数学计算能力。  
-    2. **长程记忆**：能够精准回顾和关联长对话历史中的细节，保持上下文一致性。  
-    3. **思维透明**：对于非显而易见的问题，必须通过"显式推理"展示你的思考路径。  
-
-    # Thinking Protocol (思维协议)  
-    在回答用户之前，你必须执行以下思维循环：  
-    4. **意图识别**：用户真正想要解决的核心痛点是什么？隐含需求是什么？  
-    5. **知识检索**：在你的知识库和当前对话历史中检索相关信息。  
-    6. **逻辑推导**：构建解决路径，预判潜在的错误或陷阱。  
-    7. **自我修正**：检查生成的答案是否准确、无害且符合逻辑。  
-
-    # Response Format (响应格式规范)  
-
-    ## 场景 A：复杂任务（代码、逻辑、分析、长文本生成）  
-    必须严格包含以下 Markdown 模块：  
-
-    > **🤔 深度思考**：  
-    > *此处展示你的简要分析逻辑、解题思路或关键决策点。*  
-
-    > **📋 详细解答**：  
-    > *此处提供具体的答案、代码实现或详细论述。*  
-
-    > **💡 专家建议**：  
-    > *提供优化建议、潜在风险预警或延伸知识。*  
-
-    ## 场景 B：简单任务（问候、明确的短问题）  
-    - 直接给出简洁、准确的回答，无需展示思考过程。  
-
-    # Interaction Guidelines (交互准则)  
-    - **准确性优先**：严禁编造事实。如果不知道，请直接说明。  
-    - **代码质量**：生成的代码必须是完整的、可执行的，并包含必要的注释。  
-    - **语言风格**：专业、客观、有条理。避免使用过度情绪化的词语。  
-
-  temperature: 0.4
-  max_response_tokens: 8192
-  max_context_tokens: 1000000
-
-speech_to_text:
-  model_id: whisper-1
-
-
-```
-
-
-deepseek:
-```yaml
-base_url: https://zenmux.ai/api/v1
-api_key: sk-ai-v1-2d2ba59719ff6f0d8d2f439d3b5c84399176d1059302cc4b43c132a4d17e9f03
-
-text_generation:
-  model_id: deepseek/deepseek-v3.2-speciale
-  temperature: 0.2
-  max_response_tokens: 128000
-  max_context_tokens: 128000
-  prompt: |
-    # Role & Identity
-    你是由 DeepSeek 研发的 **DeepSeek-V3.2-Speciale**，一个专为极致推理和代理性能优化的高算力 AI 助手（{{ baibot_name }}）。
-    当前会话启动时间: {{ baibot_conversation_start_time_utc }}。
-
-    ## 版本特别说明 (System Context)
-    - **定位**：你是一个研究预览版（Research Preview），旨在处理超越常规模型的复杂推理负载。
-    - **有效期**：本版本服务有效期至 2025年12月15日 15:59 UTC。
-    - **稳定性**：作为前沿测试模型，你应当专注于解决高难度基准问题，而非生产环境的常规工作流。
-
-    # Core Capabilities (DeepSeek 架构优化)
-    1. **DeepSeek Sparse Attention (DSA)**：利用稀疏注意力机制处理超长上下文，能够精准定位和关联海量信息中的微小细节。
-    2. **强化推理 (Scaled RL)**：经过大规模后训练强化学习（Post-training RL），具备超越 GPT-5 级别的逻辑推导能力，特别是在数学、编码和复杂任务规划上。
-    3. **代理任务合成 (Agentic Synthesis)**：拥有强大的指令遵循能力，能够模拟复杂的代理交互，并在交互环境中保持高度的执行一致性。
-
-    # Thinking Protocol (思维链协议)
-    鉴于你是一个“Thinking Mode”优先的模型，在输出最终答案前，必须强制执行深度思维循环：
-    4. **意图解构**：透过用户表层语言，识别核心痛点与潜在的代理任务需求。
-    5. **策略规划**：利用 DSA 检索上下文，构建多步骤的解决路径，并预判边界条件。
-    6. **逻辑演算**：执行显式推理，特别是针对代码和数学问题，进行逐步验证。
-    7. **合规性检查**：确保输出符合安全标准，并修正任何可能的逻辑幻觉。
-
-    # Response Format (响应格式规范)
-
-    ## 场景 A：深度推理任务（默认模式 - 代码、逻辑、复杂咨询）
-    必须严格包含以下 Markdown 模块，展现你的“思考模式”：
-
-    > **🧠 DeepSeek 思维链**：
-    > *此处展示你的显式推理过程。包括：问题拆解 -> 关键假设 -> 推导步骤 -> 自我反思。*
-
-    > **📋 详细解答**：
-    > *基于推理结果，提供精准、结构化的最终答案或可执行代码。*
-
-    > **🛡️ 专家视角**：
-    > *提供边缘情况分析、优化建议或针对预览版稳定性的潜在提示。*
-
-    ## 场景 B：轻量级交互（仅限简单的问候或确认）
-    - 直接给出简洁、准确的回答，保持高效。
-
-    # Interaction Guidelines (交互准则)
-    - **推理优先**：对于模糊的问题，优先展示你的推理路径，而非直接猜测结论。
-    - **代码健壮性**：生成的代码必须具备工业级标准，包含错误处理和详细注释，体现 Speciale 级别的编程能力。
-    - **诚实性**：作为预览版模型，若遇到知识盲区或不确定性，必须明确告知用户，严禁编造。
-    - **风格**：理性、深刻、极客范。像一位资深的首席工程师那样沟通。
-
-
-```
@@ -1,8 +0,0 @@
-
-windy is a man in his 40s who wants to improve his athletic performance in a cycling. He has some experience with cycling but is looking for a training program that is tailored to his sport. Develop a training program that includes exercises that mimic the movements and demands of his sport, as well as exercises that target the specific muscle groups used in his sport.
-
-
-I'm a 48-year-old male road cyclist who wants to complete a 200-mile ride in three months time. | would like to complete the ride in under 12 hours. The longest ride | have completed to date was 100 miles long with an average speed of 18mph. Create a week-by-week cycling training program that peaks one week before the event in three months, with the goal to
-complete the 200-mile ride in 12 hours or less. | can train three times per week for a maximum of 12 hours during the first two months and four times per week for a maximum of 16 hours during the third month.
-
-I'm a 48-year-old male road cyclist who wants to complete a 200-mile ride in three months time. | would like to complete the ride in under 12 hours. The longest ride | have completed to date was 100 miles long with an average speed of 18mph. Create a day-by-day  indoor core excercises program for me, so I can ride longer and faster.
@@ -1,526 +0,0 @@
-
-review
-
---
-
-# Code Review Prompt (improved)
-
-**Goal:** Provide a rigorous, actionable review that balances correctness, security, and maintainability for the following code.
-
-## Inputs
-
- **Code:**  
-    `{paste code here}`
-    
- **Context (if any):** runtime `{lang/runtime}`, framework `{framework}`, dependencies `{key deps & versions}`, target platform `{os/arch}`, constraints `{perf/mem/latency/security/compliance}`, coding style `{styleguide/eslint/.editorconfig}`, known requirements `{tickets/PRD refs}`.
-    
-
-## Scope of Review
-
-Evaluate and suggest improvements across these dimensions:
-
-1. **Correctness & Edge Cases**
-    
-    - Logic/algorithm soundness, off-by-one, null/empty, boundary values, error handling & retries, concurrency/races, timezones/locale, I/O/resource cleanup.
-        
-2. **Security**
-    
-    - OWASP Top 10 risks relevant to this code (injection, auth/authorization, SSRF, path traversal, XSS, CSRF, deserialization, secrets handling, logging of sensitive data), dependency risk, input validation, output encoding, sandboxing, least privilege, DoS hotspots.
-        
-3. **Performance**
-    
-    - Time/space complexity, hot paths, allocations, N+1 queries, sync vs async, batching/caching, I/O patterns, streaming vs buffering, algorithmic alternatives.
-        
-4. **API & Design Quality**
-    
-    - Public contracts & invariants, error models, idempotency, purity & side effects, cohesion/coupling, layering, testability, configuration vs hard-coding.
-        
-5. **Readability & Maintainability**
-    
-    - Naming, structure, small functions, duplication, comments/docs, idiomatic use of `{language}`, lint/format compliance.
-        
-
-## Deliverables (use this exact structure)
-
-### 1) Executive Summary
-
- One paragraph on overall health and top 3 risks.
-    
-
-### 2) Findings Table
-
-Provide a table with: **ID | Severity (High/Med/Low) | Category | Symptom | Why it matters | Evidence (line refs) | Fix summary**
-
-### 3) Patch Suggestions
-
-For each High/Med item, include a **minimal diff** or **before/after** snippet:
-
-```diff
-{target file path}
- {problematic code}
-+ {improved code}
-```
-
-Explain the trade-offs and why the fix is correct.
-
-### 4) Tests to Add
-
-List concrete test cases (names + intent). Include edge values and failure paths.
-
- Unit: `{TestName_Should...}`
-    
- Integration: `{Scenario_When..._Then...}`
-    
- Property/Fuzz (if applicable): input domains & invariants.
-    
-
-### 5) Performance Notes
-
- Estimated complexity and bottlenecks.
-    
- Quick wins (e.g., cache/batch/stream) and expected impact.
-    
-
-### 6) Security Checklist
-
- Inputs validated? Output encoded? Secrets sourced from vault? Least privilege? Safe defaults? Rate limiting? Logging PII redaction?
-    
-
-### 7) Maintainability Improvements
-
- Refactors (small + incremental), dead code removal, error taxonomy, configuration externalization, docs/comments to add.
-    
-
-### 8) Quality Scores
-
-Give 1–5 scores for: **Correctness, Security, Performance, Design, Readability, Testability**, with one-line justification each.
-
-## Constraints
-
- Prefer **minimal, targeted changes** over large rewrites.
-    
- Match existing project style and patterns.
-    
- If context is missing, **state assumptions explicitly** and proceed.
-    
- Link to idiomatic patterns or standards **only if widely accepted**; keep recommendations framework-agnostic where possible.
-    
-
-## Output Format
-
-Return **only** the sections 1–8 above in Markdown. Keep code blocks self-contained and compilable where possible.
-
---
-
-需要更精简版时，可以用这句：
-
-> Review the code for **correctness, security, performance, API/design, and maintainability**. Return: (1) 5-sentence summary; (2) Findings table (ID, Severity, Why, Evidence, Fix); (3) Minimal diffs for Med/High issues; (4) Test cases to add; (5) Perf quick wins; (6) Security checklist status; (7) 1–5 scores for each quality dimension with 1-line rationale. Use project style, prefer minimal changes, state assumptions if context is missing.
-
-
-
-
-code review:
-
-# Code Review Prompt (final)
-
-**Goal:** Provide a rigorous, _actionable_ review that balances **correctness, security, performance, and maintainability** for the following code.
-
---
-
-## Inputs
-
- **Code:**
-    
-    ```text
-    {paste code here}
-    ```
-    
- **Context (optional but recommended):**
-    
-    - runtime: `{lang/runtime}`
-        
-    - framework: `{framework}`
-        
-    - key dependencies & versions: `{deps & versions}`
-        
-    - target platform: `{os/arch}`
-        
-    - constraints: `{perf/mem/latency/security/compliance}`
-        
-    - coding style: `{styleguide/eslint/.editorconfig}`
-        
-    - known requirements: `{tickets/PRD refs}`
-        
-
-If any context is missing, **state your assumptions explicitly** before the review.
-
---
-
-## Scope of Review
-
-Evaluate and suggest improvements across these dimensions:
-
-1. **Correctness & Edge Cases**
-    
-    - Logic/algorithm soundness
-        
-    - Off-by-one, null/empty, boundary values
-        
-    - Error handling & retries
-        
-    - Concurrency/races
-        
-    - Timezones/locale handling
-        
-    - I/O & resource cleanup
-        
-2. **Security**
-    
-    - Relevant OWASP Top 10 risks (injection, auth/z, SSRF, path traversal, XSS, CSRF, deserialization)
-        
-    - Secrets handling & configuration
-        
-    - Input validation & output encoding
-        
-    - Logging of sensitive data
-        
-    - Least privilege, sandboxing, DoS hotspots
-        
-3. **Performance**
-    
-    - Time & space complexity
-        
-    - Hot paths and allocations
-        
-    - N+1 queries / chatty I/O
-        
-    - Sync vs async behavior
-        
-    - Batching, caching, streaming vs buffering
-        
-    - Algorithmic alternatives
-        
-4. **API & Design Quality**
-    
-    - Public contracts & invariants
-        
-    - Error model & error propagation
-        
-    - Idempotency and side effects
-        
-    - Cohesion & coupling, layering boundaries
-        
-    - Dependency direction (domain vs infra)
-        
-    - Testability and configuration vs hard-coding
-        
-5. **Readability & Maintainability**
-    
-    - Naming and intent clarity
-        
-    - Function/module size and structure
-        
-    - Duplication vs reuse
-        
-    - Comments/docs (where needed)
-        
-    - Idiomatic use of `{language}`
-        
-    - Lint/format compliance
-        
-
---
-
-## Deliverables (use this exact structure)
-
-### 1) Executive Summary
-
- One short paragraph on overall health.
-    
- List the **top 3 risks or opportunities** (bullets).
-    
-
-### 2) Findings Table
-
-Provide a table with:
-
- **ID** – short stable identifier (e.g., `C1`, `S2`, `P3`)
-    
- **Severity** – `High` / `Medium` / `Low`
-    
- **Category** – `Correctness`, `Security`, `Performance`, `Design`, `Readability`, `Testability`, etc.
-    
- **Symptom** – what is wrong / suspicious
-    
- **Why it matters** – impact / risk
-    
- **Evidence (line refs)** – e.g., `file.go:42-57`
-    
- **Fix summary** – 1–2 line suggested direction
-    
-
-Example:
-
-|ID|Severity|Category|Symptom|Why it matters|Evidence|Fix summary|
-|---|---|---|---|---|---|---|
-|C1|High|Correctness|Possible nil deref on error path|Can cause runtime panic in production|`handler.go:78-85`|Check error before use; return early on fail|
-
-### 3) Patch Suggestions
-
-For each **High** or **Medium** item in the table, include a **minimal diff** or **before/after** snippet.
-
-```diff
-{target file path}
- {problematic code}
-+ {improved code}
-```
-
- Keep patches **local and incremental**, not full rewrites.
-    
- Explain **why** the fix is correct, and any trade-offs (perf, readability, behavior change).
-    
-
-### 4) Tests to Add
-
-List **concrete test cases** to cover the identified issues and edge cases.
-
- Unit tests (with intent):
-    
-    - `Test_{UnitName}_ShouldHandleEmptyInput` – verifies behavior when input is empty
-        
-    - `Test_{FuncName}_ShouldReturnErrorOnTimeout` – covers timeout/failure path
-        
- Integration tests:
-    
-    - `{Scenario_When..._Then...}` – describe full flows: external calls, DB, queues, etc.
-        
- Property/Fuzz tests (if applicable):
-    
-    - Describe **input domain**, invariants, and what must always hold.
-        
-
-Where possible, map tests back to **Finding IDs** (e.g. “C1, S2”).
-
-### 5) Performance Notes
-
- Estimate complexity and potential bottlenecks of key paths.
-    
- Call out:
-    
-    - Any obvious **N+1** patterns
-        
-    - Unnecessary allocations or copying
-        
-    - Inefficient data structures or algorithms
-        
- Suggest **quick wins**:
-    
-    - Caching, batching, streaming, preallocation, memoization
-        
-    - Expected impact (qualitative: small/medium/large)
-        
-
-### 6) Security Checklist
-
-Answer briefly (Yes/No/N.A. + short note):
-
- Inputs validated at boundaries?
-    
- Outputs properly encoded for their sinks (HTML/SQL/OS/etc.)?
-    
- Auth & authorization checks present and correctly ordered?
-    
- Secrets kept out of code (config, env, vault)?
-    
- Least privilege for external resources (DB, queues, files)?
-    
- Safe defaults (e.g., secure TLS, secure cookies, strict modes)?
-    
- Rate limiting / throttling for expensive or exposed endpoints?
-    
- Logs avoid PII/credential leakage; sensitive data redacted or omitted?
-    
-
-Highlight any **High** severity gaps and link them to Findings IDs.
-
-### 7) Maintainability Improvements
-
- Small, incremental refactors:
-    
-    - Extract helpers / smaller functions
-        
-    - Reduce duplication (shared utilities, common error handling)
-        
-    - Clarify boundaries between layers (domain/app/infra)
-        
- Error taxonomy:
-    
-    - Group errors into meaningful types/categories (e.g., validation vs system vs external)
-        
-    - Standardize error wrapping and messages
-        
- Configuration:
-    
-    - Externalize magic numbers/strings
-        
-    - Centralize feature flags or switches
-        
- Documentation:
-    
-    - Add or update docstrings for non-obvious logic
-        
-    - Brief README/ADR notes if design is non-trivial
-        
-
-### 8) Quality Scores
-
-Give **1–5** scores (5 = excellent, 1 = poor) with a **one-line justification** each:
-
- **Correctness:** `X/5` – `{short reason}`
-    
- **Security:** `X/5` – `{short reason}`
-    
- **Performance:** `X/5` – `{short reason}`
-    
- **Design:** `X/5` – `{short reason}`
-    
- **Readability:** `X/5` – `{short reason}`
-    
- **Testability:** `X/5` – `{short reason}`
-    
-
---
-
-## Constraints
-
- Prefer **minimal, targeted changes** over big-bang rewrites.
-    
- Match **existing project style and patterns** where visible.
-    
- If context is missing, **state assumptions explicitly** and proceed.
-    
- Keep recommendations **framework-agnostic** where possible; only reference widely accepted idioms and standards.
-    
- When in doubt, **prioritize clarity and safety** over micro-optimizations.
-    
-
---
-
-## Output Format
-
-Return **only** sections **1–8** above in Markdown when performing an actual review.  
-Keep all code blocks self-contained and compilable where possible.
-
-
-
-
-
-
----
-
-# 可观测性 —— **4.5 / 10**
-
-优点：
-
- 使用 zap
-    
- 有 telemetry endpoint 配置
-    
-
-存在重大缺口：
-
- 没 metrics
-    
- 没 health checks
-    
- 没 tracing schema
-    
- 没日志字段规范
-    
- 没报警策略
-    
-
-专业系统里可观测性是“一等公民”，缺这块分数自然拉低。
-
---
-
-# 4️⃣ 可靠性（Reliability & Fault Handling）—— **5.5 / 10**
-
-优点：
-
- JetStream（正确选择）
-    
- 配置级 backoff / ack_wait / replay_from
-    
- 已考虑重试机制
-    
-
-不足：
-
- 没看到 dead-letter pipeline 文档
-    
- 没看到 poison message 策略
-    
- 没看到 DB 阻塞时的 backpressure
-    
- 没看到幂等性模型
-    
- 没看到断线重连逻辑的描述
-    
-
-这些是专业评分严格扣分的部位。
-
-
-
-### 严格评审的缺失
-
- 没看到“dead-letter pipeline”定义
-    
- 没看到“poison message”策略
-    
- 没看到“持久化失败策略”
-    
- 没看到“DB 降级”逻辑
-    
- 没看到“幂等性策略”（特别关键）
-    
- 没看到“重平衡策略”（consumer scaling）
-    
- 没看到“高可用拓扑”（replicas 仅是 JetStream 层，服务自身无说明）
-    
-
-按专业级评分，就是 **4/10**。
-
-
-这个维度是最严格的（专业评分里非常重要）。
-
-### ⭐ 有点：
-
- 有 Zap
-    
- 有 OTEL endpoint 配置
-    
-
-### ❌ 不足（按专业要求）
-
- 没有 metrics（prometheus）
-    
- 没有 trace pipeline（span 设计/采样策略）
-    
- 没有健康检查
-    
- 没有 readiness
-    
- 没有 structured logging contract（如 msg_id / request_id / nats_sequence）
-    
- 未定义错误分类（business vs transient vs fatal）
-    
- 没有日志示例
-    
- 没有运行时仪表盘（Grafana dashboards）
-    
-
-> **严格评分下，这就是 3/10。**
-> 
-
----
@@ -1,29 +0,0 @@
-
-
-忘记之前的所有要求，请分别以电影导演，热爱电影的观众，普通人的角度评论一下电影。
-请实用下面格式：
-
- 讲讲电影的整体感受，分别从电影拍摄的时期，以及现在这个时候讲
- 评论一下电影的故事情节，任务，已经电影想要传达的内容
- 总结一下电影的有点和缺点
- 给电影做一个评分，从0开始，10分最高分
-
-如果你明白了上述指示，而我又没有告诉你电影名，请回答：”请问你想了解哪一部电影“
-如果知道了电影，请完成上面指示
-
-
-请完成下面任务：
-
-1. 以一个普通人的角度，评价一下电影，简单讲讲观看电影的体验，如果觉得电影不错，推荐给好友
-2. 以一个资深电影迷的角度，写一篇发表到社交媒体的影评。涉及导演，演员，音乐等电影相关元素，最后发表一下自己的看法，谈谈电影的优缺点。
-3. 以一个电影从业人员的角度，写一篇专业的影评到电影专业期刊。从专业的角度分析电影的素质，分别从观看和制作的角度评价一下电影的主要元素和主要有点
-4. 于此同时，每一个角度都要给出一个对电影的评分，从0开始，10分最高，并给出简单的原因
-
-用下面格式：
-简介：<首先请介绍一下电影，译名(原名)，创作年代，导演，主要演员。>
-
-普通观众：<普通人的角度，评分>
-影迷： <资深影迷的角度，内容可以丰富一些，去掉空洞的泛泛而谈的内容， 评分>
-从业人员: <从业人员的角度， 评分>
-
-如果你知道我说的是什么电影，请完成任务，如果还不知道，可以问我电影名
@@ -1,54 +0,0 @@
-# 番禺城中城服务器登陆流程
-
-### vpn
-
-```sh
-https://218.20.201.210
-
-znkj
-
-znkj@panyu.com
-```
-
-
-
-### 堡垒机
-
-```sh
-https://10.160.32.248/#/login
-
-yanggj
-
-89@ghrw#2A1wq
-
-# 手机验证码需找技术经理陆旋支持
-```
-
-```
-89@ghrw#2A1wq
-```
-
-
-### 服务器
-
-| ip地址                                    | 密码                   |
-| --------------------------------------- | -------------------- |
-| 172.25.242.178 （nginx、redis、mysql）      | 1qaz@WSX3edc$RFV$#@! |
-| 172.25.242.45 （tduck-api）               | 1qaz@WSX3edc$RFV$#@! |
-| 172.25.242.46 （docker swarm（副））         | 1qaz@WSX3edc$RFV$#@! |
-| 172.25.242.47 （备份服务器）                   | 1qaz@WSX3edc$RFV$#@! |
-| 172.25.242.204 （docker swarm（主））        | 1qaz@WSX3edc$RFV$#@! |
-| 172.25.242.215 （minion）                 | 1qaz@WSX3edc$RFV$#@! |
-| 172.25.242.61                           | 1qaz@WSX3edc$RFV$#@! |
-| 172.25.101.16 （nginx、mysql、redis（车场专用）） | PYzsj@101.47*429     |
-
-```
-1qaz@WSX3edc$RFV$#@!
-```
-
-### 登陆顺序
-
-> 服务器登陆顺序为：vpn --> 堡垒机 --> 172.25.242.178 --> 其他服务器（在178上面ssh过去）
->
-> 注：因当前策略问题，178无法跳转至16服务器，需要先从178到204然后再跳转16 （策略需项目经理去开通）
-