超越网

前言 2023年，我第一次使用 ChatGPT 时，把它当作一个"更聪明的搜索引擎"。 2024年，我开始用 AI 辅助写代码，把它当作"编程助手"。 2025年，我尝试用 AI 自主完成任务，把它当作"初级员工"。 2026年，我终于理解：AI 不是工具，也不是员工，而是认知的外延。 这篇文章记录完整的认知转变过程，以及这个转变如何改变了我的工作方式。 一、第一阶段：搜索引擎（2023） 1.1 初始认知 AI = 更好的 Google 使用场景： - 查资料 - 写文案 - 翻译 - 总结 交互模式：一问一答 1.2 局限性 问题 表现 上下文短 每次对话都是新的开始 被动响应 只能回答，不能主动 无记忆 无法记住之前的对话 无执行能力 只能生成文本 1.3 典型工作流 用户：请帮我写一个 Python 函数，计算斐波那契数列 AI：def fibonacci(n): if n <= 1: return n return fibonacci(n-1) + fibonacci(n-2) 用户：谢谢 （对话结束） 二、第二阶段：编程助手（2024） 2.1 认知升级 AI = 编程伙伴 使用场景： - 代码生成 - 代码审查 - Bug 调试 - 技术问答 交互模式：对话 + 编辑 2.2 工具演进 工具 能力 局限 ChatGPT 代码生成 无法直接修改文件 GitHub Copilot 行内补全 上下文有限 Cursor 深度理解 仍需人工主导 2.3 典型工作流 用户：请帮我重构这个函数，提高性能 AI：分析代码 → 提出建议 → 生成重构版本 用户：看起来不错，但我担心边界情况 AI：添加测试用例 → 验证边界情况 用户：好的，我手动应用这些改动 （用户手动修改代码） 三、第三阶段：初级员工（2025） 2.1 认知升级 AI = 可以分配任务的"员工" 使用场景： - 分配任务 - 跟踪进度 - 质量审查 - 自主执行 交互模式：任务分配 + 结果验收 2.2 工具演进 工具 能力 局限 Claude Code 自主执行命令 仍需人工确认 Devin 端到端开发 不稳定、成本高 自定义 Agent 高度定制 开发成本高 2.3 典型工作流 用户：请帮我添加用户登录功能 AI： 1. 分析需求 → 提出方案 2. 创建文件 → 编写代码 3. 运行测试 → 验证功能 4. 提交 PR → 等待审查 用户：审查代码 → 提出修改意见 AI：根据意见修改 → 重新提交 用户：合并代码 （任务完成） 四、第四阶段：认知外延（2026） 4.1 认知跃迁 AI = 认知的外延 核心洞察： - AI 不是替代我的思考，而是扩展我的思考 - AI 不是执行命令的工具，而是协作的伙伴 - AI 不是外部的系统，而是我认知的一部分 4.2 关键转变 维度 旧认知 新认知 角色 工具/员工 认知伙伴 交互 命令/请求 对话/协作 目标 完成任务 扩展能力 关系 主从 平等 价值 效率提升 认知升级 4.3 典型工作流 用户 + AI 协作： 1. 问题定义 用户：我有一个问题... AI：我理解你的问题是... 从这几个角度分析... 2. 方案探索 AI：我想到三个方案... 用户：第二个方案不错，但需要考虑... AI：好的，我补充这个考虑... 3. 决策支持 AI：方案对比如下... 用户：我选择方案二，因为... AI：同意，我记录这个决策理由... 4. 执行辅助 AI：我来帮你实现... 用户：这里需要调整... AI：已调整，这是新版本... 5. 反思总结 AI：这个任务的关键学习点是... 用户：我补充我的思考... AI：已记录到知识库... 五、认知转变的影响 5.1 工作方式 变化 说明 从执行到思考 更多时间用于思考，更少时间用于执行 从单点到系统 从解决单个问题到构建系统 从被动到主动 AI 主动提出建议，而非等待指令 从孤立到连接 知识形成网络，而非孤立的点 5.2 能力边界 我的能力边界扩展： 过去： ├── 我能直接完成的工作 └── 我能指导他人完成的工作 现在： ├── 我能直接完成的工作 ├── 我能指导他人完成的工作 ├── 我能与 AI 协作完成的工作 ← 新增 └── AI 能自主完成的工作 ← 新增 5.3 时间分配 活动 2023 2026 变化 信息搜索 30% 5% ↓25% 内容创作 40% 20% ↓20% 代码编写 20% 10% ↓10% 深度思考 5% 40% ↑35% 系统构建 5% 25% ↑20% 六、关键洞察 6.1 AI 不是答案，而是思考的催化剂 旧模式： 用户提问 → AI 给答案 → 用户接受 新模式： 用户提问 → AI 提出视角 → 用户思考 → 形成新认知 6.2 协作比替代更有价值 替代思维：AI 能做什么我不能做？ 协作思维：AI 能帮我做什么，让我能做更多？ 6.3 认知外延需要"内化" 外延 ≠ 依赖 关键： - 理解 AI 的输出，而非盲目接受 - 将 AI 的洞察内化为自己的认知 - 保持批判性思维，不被 AI 主导 七、给读者的建议 7.1 认知升级路径 阶段 1：把 AI 当搜索引擎 ↓ 熟悉基本交互 阶段 2：把 AI 当助手 ↓ 学会分配任务 阶段 3：把 AI 当伙伴 ↓ 建立协作关系 阶段 4：把 AI 当认知外延 ↓ 实现能力扩展 7.2 避免的误区 误区 建议 过度依赖 保持独立思考能力 盲目接受 批判性验证 AI 的输出 忽视学习 AI 不能替代基础能力 追求替代 目标是扩展，不是替代 八、总结 从 Chat 到 Agent 的认知转变，本质上是人机关系的重新定义。 ...

前言 2026年已经过半。回望过去半年，我的 AI 工作流经历了从"追逐新工具"到"构建系统"的转变。 这篇文章记录完整的演进过程，包括踩过的坑、形成的原则和未来的方向。 一、年初状态：工具焦虑 1.1 当时的困境 2026年初，我的工具栈是这样的： 早晨： ├── ChatGPT → 写邮件草稿 ├── Claude → 代码审查 ├── Midjourney → 生成配图 └── Notion AI → 整理会议纪要 下午： ├── GitHub Copilot → 写代码 ├── Perplexity → 搜索资料 └── Jasper → 写营销文案 晚上： ├── Runway → 生成视频 ├── Suno → 生成背景音乐 └── 各种新出的 AI 工具... 问题： 工具太多，切换成本高 每个工具只用了 20% 的功能 数据分散，无法形成闭环 每月订阅费用超过 ¥2000 1.2 反思 我意识到：工具本身不产生价值，工作流才产生价值。 二、年中重构：系统思维 2.1 核心原则 经过多次迭代，我形成了以下原则： 原则 说明 示例 少即是多 每个场景只选一个核心工具 代码只用 Claude Code 数据闭环 输入输出可追踪 所有对话记录存档 自动化优先 能自动的不手动 自动摘要、自动标签 本地优先 数据在自己手中 Obsidian + 本地 LLM 可迁移性 不依赖单一平台 纯 Markdown 格式 2.2 当前工作流 输入层： ├── 语音 → Whisper 转录 ├── 截图 → 多模态理解 ├── 文档 → 自动解析 └── 网页 → 自动摘要 处理层： ├── 分类 → 自动标签 ├── 摘要 → 核心要点提取 ├── 关联 → 知识图谱更新 └── 生成 → 内容创作 输出层： ├── 博客 → 自动发布 ├── 邮件 → 自动草稿 ├── 代码 → 自动审查 └── 报告 → 自动生成 三、关键决策 3.1 统一入口：Hermes Agent 我选择 Hermes Agent 作为统一入口，原因： ...

前言 2025年之前，我的笔记散落在 Notion、Evernote 和本地 Markdown 文件中。每次需要查找信息时，都要在多个平台间切换，效率极低。 从 2025 年开始，我全面迁移到 Obsidian，并引入了 AI 辅助工作流。两年后，这个知识库已经积累了超过 2000 篇笔记，成为我工作和学习的核心基础设施。 这篇文章记录完整的构建过程，包括工具链、工作流和最佳实践。 一、为什么选择 Obsidian 1.1 竞品对比 工具 优点 缺点 适用场景 Notion 协作强、数据库功能 依赖网络、导出困难 团队协作 Evernote 抓取能力强 封闭生态、搜索弱 资料收集 Roam Research 双向链接原生 价格高、学习曲线陡 学术写作 Obsidian 本地存储、插件丰富 需自行配置 个人知识库 1.2 核心优势 Obsidian 的核心价值： ├── 本地优先 ✅ │ ├── 数据完全掌控 │ ├── 离线可用 │ └── 长期可读（纯 Markdown） ├── 双向链接 ✅ │ ├── 自然连接笔记 │ ├── 知识图谱可视化 │ └── 发现隐性关联 ├── 插件生态 ✅ │ ├── 社区插件丰富 │ ├── 可高度定制 │ └── API 开放 └── AI 集成 ✅ ├── 本地 LLM 支持 ├── 云端 API 接入 └── 自动化工作流 二、基础配置 2.1 目录结构 vault/ ├── 00-inbox/ # 临时收集箱 ├── 01-projects/ # 项目笔记 │ ├── project-a/ │ └── project-b/ ├── 02-areas/ # 持续关注的领域 │ ├── ai-infrastructure/ │ ├── devops/ │ └── personal/ ├── 03-resources/ # 参考资料 │ ├── articles/ │ ├── books/ │ └── snippets/ ├── 04-archive/ # 归档笔记 ├── templates/ # 笔记模板 └── attachments/ # 图片、文件 2.2 核心插件 插件 用途 必装 Dataview 查询和聚合笔记 ✅ Templater 自动化模板 ✅ QuickAdd 快速捕获 ✅ Kanban 项目管理 ✅ Calendar 日记集成 ✅ Excalidraw 手绘图表 ⭐ Smart Connections AI 语义搜索 ✅ Copilot/Obsidian AI AI 辅助写作 ✅ 2.3 同步方案 方案 优点 缺点 推荐 Obsidian Sync 官方、加密 付费（$8/月） ⭐⭐⭐⭐ Git 免费、版本控制 需手动操作 ⭐⭐⭐⭐⭐ Syncthing 免费、P2P 配置稍复杂 ⭐⭐⭐⭐ iCloud 简单 仅 Apple 生态 ⭐⭐ 我的选择：Git + GitHub（免费 + 版本控制 + 多设备同步） ...

前言 2026年3月，Anthropic 发布了 Claude Code——一个运行在终端的 AI 编程助手。经过两个月的深度使用，我完成了从"好奇尝试"到"日常依赖"的转变。 这篇文章记录完整的评测过程，包括功能对比、实际工作流和适用场景分析。 一、产品定位 1.1 与竞品的区别 工具 运行方式 交互模式 核心优势 GitHub Copilot IDE 插件 行内补全 无缝集成 Cursor 独立编辑器 对话 + 编辑 深度代码理解 Claude Code 终端 CLI 对话 + 执行 自主执行任务 Codeium IDE 插件 行内补全 免费 Claude Code 的独特价值：它可以自主执行 shell 命令、修改文件、运行测试，像一个真正的编程伙伴。 1.2 核心能力 Claude Code 的能力边界： ├── 代码理解 ✅ │ ├── 读取文件 │ ├── 理解项目结构 │ └── 分析依赖关系 ├── 代码生成 ✅ │ ├── 编写新文件 │ ├── 修改现有代码 │ └── 重构代码 ├── 命令执行 ✅ │ ├── 运行 shell 命令 │ ├── 执行 git 操作 │ └── 运行测试 └── 自主决策 ⚠️ ├── 需要用户确认敏感操作 └── 复杂任务需分步执行 二、安装与配置 2.1 安装 # 通过 npm 安装 npm install -g @anthropic-ai/claude-code # 或通过 Homebrew (macOS) brew install claude-code # 配置 API Key claude config set api_key sk-ant-... 2.2 基础配置 # 交互式配置 claude config # 或编辑配置文件 ~/.claude/config.json { "model": "claude-3-5-sonnet-20241022", "temperature": 0.7, "max_tokens": 4096, "auto_approve": false, "verbose": true } 三、核心功能评测 3.1 代码理解 场景：理解一个陌生项目的架构 ...

前言 2025年之前，我的本地开发环境一直是 Docker Compose。直到一次生产环境的配置差异导致严重故障，我才意识到本地环境需要更接近生产。 这篇文章记录完整的 Kubernetes 本地开发环境搭建过程，包括工具选择、配置优化和开发工作流。 一、为什么需要本地 K8s 1.1 痛点分析 场景 Docker Compose Kubernetes ConfigMap 测试 ❌ 不支持 ✅ 原生支持 Service 发现 ⚠️ 手动配置 ✅ 自动发现 Ingress 路由 ❌ 不支持 ✅ 原生支持 HPA 自动扩缩容 ❌ 不支持 ✅ 原生支持 生产一致性 ⚠️ 较低 ✅ 高 1.2 核心价值 “本地即生产”：在本地就能验证生产环境的配置和行为，减少部署时的意外。 二、工具选择 2.1 主流方案对比 工具 优点 缺点 适用场景 Minikube 功能完整、插件丰富 启动慢、资源占用高 学习/测试 Kind 快速启动、Docker后端 多集群管理弱 开发/CI K3s 轻量、生产级 配置稍复杂 边缘/开发 Docker Desktop K8s 一键启用、集成好 资源占用高、Mac/Win独占 快速上手 Rancher Desktop 跨平台、可选容器运行时 较新、社区较小 跨平台开发 2.2 我的选择：Kind 经过对比测试，我选择 Kind (Kubernetes in Docker) 作为本地开发环境： ...

前言 2025年，我经历过三次因为环境不一致导致的线上故障。每次排查都花费数小时，最终发现是开发环境和生产环境的配置差异造成的。 从那时起，我开始系统性地重构多环境管理方案。这篇文章记录完整的实践过程，包括目录结构、配置管理和部署流程。 一、问题根源 1.1 常见痛点 问题 现象 影响 配置硬编码 环境变量写死在 docker-compose.yml 切换环境需修改文件 镜像版本混乱 开发用 latest，生产用具体版本 行为不一致 依赖管理缺失 数据库迁移脚本未版本化 数据不一致 密钥管理不当 敏感信息明文存储 安全风险 1.2 根本原因 环境隔离不彻底：开发、测试、生产共用同一份配置模板，仅靠注释区分。 二、目录结构设计 2.1 推荐结构 project/ ├── docker-compose.yml # 基础配置（公共部分） ├── docker-compose.override.yml # 本地开发覆盖 ├── environments/ │ ├── dev/ │ │ ├── docker-compose.dev.yml │ │ └── .env.dev │ ├── staging/ │ │ ├── docker-compose.staging.yml │ │ └── .env.staging │ └── prod/ │ ├── docker-compose.prod.yml │ └── .env.prod ├── scripts/ │ ├── deploy.sh │ └── rollback.sh └── .gitignore 2.2 基础配置（docker-compose.yml） version: "3.8" services: app: image: ${APP_IMAGE:-myapp:latest} restart: unless-stopped environment: - NODE_ENV=${NODE_ENV:-development} - LOG_LEVEL=${LOG_LEVEL:-info} depends_on: - db - redis db: image: postgres:${POSTGRES_VERSION:-16} volumes: - db_data:/var/lib/postgresql/data environment: - POSTGRES_DB=${POSTGRES_DB:-app} - POSTGRES_USER=${POSTGRES_USER:-app} - POSTGRES_PASSWORD_FILE=/run/secrets/db_password redis: image: redis:${REDIS_VERSION:-7-alpine} command: redis-server --maxmemory 256mb volumes: db_data: 2.3 生产环境覆盖（environments/prod/docker-compose.prod.yml） version: "3.8" services: app: image: myapp:${APP_VERSION:-1.0.0} deploy: resources: limits: cpus: "2" memory: 2G reservations: memory: 512M healthcheck: test: ["CMD", "curl", "-f", "http://localhost:3000/health"] interval: 30s timeout: 10s retries: 3 secrets: - db_password networks: - frontend - backend db: deploy: resources: limits: memory: 4G volumes: - db_data:/var/lib/postgresql/data - ./backups:/backups secrets: db_password: external: true networks: frontend: driver: bridge backend: internal: true 三、环境变量管理 3.1 .env 文件规范 # .env.prod # 应用配置 APP_VERSION=1.0.0 NODE_ENV=production LOG_LEVEL=warn # 数据库 POSTGRES_VERSION=16 POSTGRES_DB=app_prod POSTGRES_USER=app # Redis REDIS_VERSION=7-alpine # 镜像仓库 REGISTRY_URL=registry.example.com 3.2 密钥管理 不要将密钥存入 .env 文件！ ...

前言 2026年，本地LLM部署已经成为AI基础设施的标配。我在同一台服务器上同时部署了Ollama和vLLM，运行了为期两周的对比测试。 这篇文章记录完整的评测过程，包括性能、易用性、资源占用和适用场景。 一、测试环境 1.1 硬件配置 组件 规格 CPU AMD EPYC 7763 (64核) GPU NVIDIA A100 80GB × 2 内存 512GB DDR4 存储 2TB NVMe SSD 系统 Ubuntu 24.04 LTS 1.2 测试模型 模型 参数量 量化版本 Llama 3.1 8B Q4_K_M Llama 3.1 70B Q4_K_M Qwen 2.5 72B Q4_K_M 1.3 测试工具 llm-bench: 自定义基准测试脚本 prometheus + grafana: 实时监控 locust: 并发压力测试 二、性能对比 2.1 单请求延迟 模型 Ollama (TTFT) vLLM (TTFT) 优势 Llama 3.1 8B 1.2s 0.8s vLLM ↓33% Llama 3.1 70B 8.5s 5.2s vLLM ↓39% Qwen 2.5 72B 9.1s 5.8s vLLM ↓36% TTFT = Time To First Token（首字延迟） ...

前言 2026年Q1，我的AI Agent系统经历了三次重大架构迭代。最初是单一模型驱动，后来发现成本失控和响应不稳定，最终演变成现在的多模型智能路由架构。 这篇文章记录完整的架构演进过程，以及为什么"智能路由"比"固定模型"更适合生产环境。 一、架构演进历程 1.1 第一阶段：单一模型（2025年Q1-Q2） 最初的设计非常简单：所有任务都路由到同一个模型。 用户请求 → 单一模型 → 响应 问题暴露： 成本不可控：简单任务占用高能力模型资源 限流风险：供应商API限流时全系统阻塞 响应延迟：高峰期排队严重 1.2 第二阶段：静态路由（2025年Q3-Q4） 根据任务类型手动配置路由规则： 代码任务 → Model A 文本任务 → Model B 多模态 → Model C 改进：成本降低约20%，但路由规则僵化，无法适应新场景。 1.3 第三阶段：智能路由（2026年Q1至今） 基于任务复杂度、成本、响应时间的动态路由： 用户请求 → 路由引擎 → 最优模型 → 响应 ↓ 降级策略（失败时自动切换） 二、路由引擎设计 2.1 任务分类器 使用轻量级分类器判断任务类型和复杂度： 维度 判断标准 权重 任务类型 代码/文本/多模态/数学 40% 复杂度 简单/中等/复杂 30% 时效性 实时/准实时/异步 20% 成本敏感 是/否 10% 2.2 模型能力矩阵 模型 代码 文本 多模态 数学 成本/千token GLM Coding Lite ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐ ⭐⭐ ¥0.5 DeepSeek-V3 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐ ⭐⭐⭐⭐⭐ ¥1.0 SenseNova 6.7 ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐ ¥2.0 Claude 3.5 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐ ¥5.0 2.3 路由决策逻辑 def route_task(task): # 1. 分类任务 task_type = classify(task) complexity = assess_complexity(task) # 2. 根据类型选择候选模型 candidates = get_candidates(task_type) # 3. 根据复杂度过滤 if complexity == "简单": candidates = filter_by_cost(candidates) elif complexity == "复杂": candidates = filter_by_capability(candidates, min_rating=4) # 4. 健康检查 candidates = [m for m in candidates if is_healthy(m)] # 5. 选择最优 return select_optimal(candidates, task) 三、降级与容错 3.1 三级降级策略 级别 触发条件 降级行为 L1 单个模型超时 切换同类型备选模型 L2 同类型全部失败 降级到低成本模型 L3 所有模型不可用 返回缓存结果或排队 3.2 熔断机制 circuit_breaker: failure_threshold: 5 # 连续失败5次触发熔断 reset_timeout: 60s # 60秒后尝试恢复 half_open_requests: 3 # 半开状态测试请求数 3.3 监控指标 成功率：目标 > 99.5% 平均响应时间：目标 < 2s 成本/请求：目标 < ¥0.05 降级频率：目标 < 1%/天 四、成本优化效果 指标 单一模型 智能路由 优化幅度 月均成本 ¥3,200 ¥1,850 ↓42% 平均响应时间 3.2s 1.8s ↓44% 限流事件 12次/月 0次/月 ↓100% 任务成功率 94% 99.7% ↑6% 五、实现细节 5.1 统一API接口 # config.yaml routing: providers: - name: glm-coding weight: 30 timeout: 10s - name: deepseek weight: 25 timeout: 15s - name: sensenova weight: 25 timeout: 20s - name: claude weight: 20 timeout: 30s fallback_order: - glm-coding - deepseek - sensenova - claude 5.2 健康检查 # 每30秒检查一次 curl -s "http://model-api/health" | jq '.status' 5.3 日志与追踪 所有请求记录到日志系统，支持按以下维度分析： ...

前言 2026 年 5 月，DeepSeek 发布了 V4-Pro 预览版，宣称具备"世界顶级推理性能"。与此同时，Anthropic 的 Claude Opus 4.7 已在官网和定价页面确认存在。 这两个模型代表了当前 AI 推理能力的两个极端：一个是国产模型的巅峰之作，一个是国际巨头的旗舰产品。 核心问题：DeepSeek-V4-Pro 能否在推理能力上真正挑战 Claude Opus 4.7？ 一、模型背景 1.1 DeepSeek-V4-Pro 项目 信息 发布状态 ✅ 预览版已发布 官方描述 “世界顶级推理性能，Agent 能力大幅提高” 上线渠道 网页端、APP、API 所属公司 DeepSeek（中国） 关键信息： DeepSeek-V4 预览版已上线，Pro 版本作为旗舰型号 官方强调"推理性能"和"Agent 能力"两大升级点 已在 API 文档中确认 deepseek-v4-pro 模型存在 1.2 Claude Opus 4.7 项目 信息 发布状态 ✅ 已确认存在 所属公司 Anthropic（美国） 版本序列 Opus 4 → 4.1 → 4.5 → 4.6 → 4.7 定位 Anthropic 旗舰推理模型 关键信息： ...

前言 2026年5月，我制定了一套AI协作的"元规则体系"。其中最核心的一条是：每次AI对话结束后必须产生至少一项技能更新。 这不是一个随意的要求，而是基于一个深刻的观察：AI的"记忆"不是对话记录，而是技能库。 一、问题：AI为什么会"忘记" 1.1 对话记录的局限性 很多人认为AI的"记忆"是对话历史。但实际情况是： 对话记录会被截断：上下文窗口有限，旧对话会被挤出 对话记录不可检索：除非使用专门的记忆工具，否则无法快速定位 对话记录是线性的：无法结构化存储，难以复用 1.2 技能的本质 技能不是"任务复述"，而是可复用的方法论： 技能 = 触发条件 + 执行步骤 + 注意事项 + 验证标准 示例：git-credential-persistence 技能 - 触发条件：需要在Docker容器中使用SSH密钥 - 执行步骤：宿主机生成密钥 → 设置权限 → 挂载到容器 → 验证连接 - 注意事项：密钥必须在宿主机生成，容器内生成的密钥重启后丢失 - 验证标准：容器重启后SSH连接正常 二、为什么每次对话后必须更新技能 2.1 技能是AI的"长期记忆" 存储方式 持久性 可检索性 可复用性 对话记录 ❌ 有限窗口 ❌ 线性搜索 ❌ 难以提取 记忆工具 ⚠️ 结构化但稀疏 ✅ 可搜索 ⚠️ 需要手动提取 技能库 ✅ 持久存储 ✅ 按名称检索 ✅ 直接加载 结论：技能库是AI最有效的长期记忆方式。 2.2 “不更新即错失学习机会” 每次对话都是一次学习机会： 新的问题 → 可能产生新的技能 新的解决方案 → 可能优化现有技能 新的错误 → 可能发现技能的漏洞 新的约束 → 可能更新技能的边界条件 如果每次对话后不更新技能，就等于放弃了这次学习机会。 ...