AI

背景 Arch Linux 工作站上我同时保留了两套 Cursor：AUR 的 cursor-bin 和 官方 AppImage。不是重复安装玩，而是两条更新通道各管一件事——AUR 省心，AppImage 跟官网更快。 为什么装两份 最初用 AUR 安装 cursor-bin，日常 paru -Syu 就能升级，和系统其他包一起维护。但 AUR 版本依赖上游维护者跟进官方发布，往往比官网慢几天到一两周。想试用新功能或修 bug 时，等 AUR 更新会比较被动。 Linux 版 Cursor 也有应用内自动更新（Help → Check for Updates），但我这边用起来不太稳，偶尔报错。所以另装了一份官方 AppImage，需要新版本时从官网拉，比等 AUR 或碰运气点内置更新更可控。 两套安装共用 ~/.config/Cursor 和 ~/.cursor，配置、扩展、MCP 设置不用搬。约束是同一时刻只开一个版本——切换前先完全退出当前实例。 stable 与 latest 发布通道 Cursor 官方下载 API 用 releaseTrack 区分通道（Linux AppImage 脚本安装靠这个接口）： https://www.cursor.com/api/download?platform=linux-x64&releaseTrack=stable|latest 返回 JSON，含 downloadUrl、version 等字段。论坛里也有人确认过这个接口。 通道 定位 说明 stable 保守、生产向 官方认为足够稳、适合大多数人默认用的构建；更新节奏较慢 latest 官网最新正式版 下载 CDN 上当前最新的正式发布，通常是比 stable 更新的 patch 两者都是正式发布构建，不是每日实验版。差别在发布节奏：stable 更保守，latest 更快拿到新 patch。 ...

背景 给 AI 编程助手写「项目级说明」，目前尚无统一行业标准——没有 RFC，也没有各家都认的固定文件名。2024 到 2026 年间的常见做法是：在仓库里放 markdown，让 agent 改代码前先读约束。 真正稳定的实践，往往不在某个目录名上，而在三件事： 入口清晰 — agent 知道先读哪个文件 约束可执行 — 语言、目录、测试命令等，少写空泛原则 规模匹配 — 小 demo 不必拆十几份 doc 常见组织方式 方式 典型路径 优点 缺点 根目录入口 AGENTS.md、CLAUDE.md 易发现，多工具能扫到 规则一多文件会很长 .ai/ 目录 .ai/instructions.md 可拆分，根目录干净 部分工具不会自动索引子目录 Cursor 专用 .cursor/rules/*.mdc 与 Cursor IDE 深度集成 绑定 Cursor，换工具需迁移 Copilot 专用 .github/copilot-instructions.md VS Code / Copilot 原生支持 绑定 GitHub Copilot 生态 与人类文档合并 CONTRIBUTING.md 内 AI 段 贡献指南一处维护 AI 规则与人工流程易混杂 没有「唯一正确」的目录名。.ai/ 是合理选项之一，不是法定标准。 ...

什么是 Spec-Driven Development Spec-Driven Development（SDD，规格驱动开发） 是一种 AI 辅助开发方法论：开发者在让 AI 写代码之前，先把需求、边界和验收标准写成结构化的规格说明（Spec），AI 再依据 Spec 生成、修改或引导实现。 Spec 可以是自然语言文档，也可以带接口签名、数据模型、约束条件等结构化片段。核心不是格式，而是 先定义「完成」长什么样，再让 AI 动手。 典型 Spec 会回答： 要做什么、不做什么 输入输出与接口契约 边界条件与错误处理 验收标准（怎样算通过） SDD 与 Vibe Coding 的关系 SDD 和 Vibe Coding 关联很强，但方向相反——它们描述的是同一条 AI 协作光谱的两端。 维度 Vibe Coding SDD 输入方式 口语化、即兴描述 结构化 Spec 意图传递 让 AI 猜 显式定义边界 可追溯性 低，依赖对话历史 高，Spec 可版本管理 适合场景 原型、探索、一次性脚本 功能迭代、协作、长期维护 出错模式 方向对但细节偏、隐性假设 前期写 Spec 有成本 Vibe Coding 指用自然、随意的语言驱动 AI 写代码，强调「跟着感觉走」——描述大概想要什么，让模型自行补全细节。Andrej Karpathy 在 2025 年推广了这个说法。它上手快，适合快速验证想法。 ...

调试：先问"为什么"，再改 prompt 当模型做了意外的事情，不要急着修改 prompt。 正确的第一步是直接问模型：“你为什么这么做？” 模型通常能给出有价值的答案，比如： “系统提示里有一处让我困惑的地方” “我把验证委托给了一个 sub agent，但它没有完成，而我没有检查它的工作” 找到根本原因，才能针对性地修复。盲目调整 prompt 往往治标不治本，甚至引入新的问题。 调试流程建议： 复现问题，记录模型的异常行为 询问模型：“你为什么这样做？“或"你是怎么理解我的指令的？” 根据模型的解释，定位根本原因：是 prompt 歧义、sub agent 失败、工具返回异常，还是上下文丢失？ 针对根本原因做定向修复，而不是猜测性地修改 prompt

AI Agent AI Agent（人工智能代理）是一个能够感知环境、自主决策并采取行动以完成目标的软件系统。 与普通程序不同，AI Agent 的核心特征是自主性：它不只是被动地响应单次输入，而是能够： 制定多步骤计划 调用外部工具（搜索、代码执行、API 调用等） 根据执行结果动态调整策略 持续循环直到目标完成 AI Agent 的定义 从学术角度，Agent 的经典定义来自 Russell & Norvig（《人工智能：一种现代方法》）： Agent 是任何能够通过传感器感知环境、并通过执行器对环境采取行动的事物。 在 LLM 时代，AI Agent 的定义更具体： AI Agent 是以大语言模型为核心推理引擎，能够自主规划任务、调用工具、与外部系统交互，并通过反馈循环完成复杂目标的自治系统。 Agent 的四个核心要素 要素 说明 感知（Perception） 接收输入：多模态用户指令、工具返回结果、系统状态、历史记忆 规划（Planning） 将目标分解为可执行的子任务序列 行动（Action） 调用工具、执行代码、调用 API、操作文件等 记忆（Memory） 短期记忆（上下文窗口）+ 长期记忆（向量数据库等） 感知的来源 感知不只是用户输入那一句话，Agent 每次推理前收到的完整上下文都属于"感知"： 来源 说明 多模态输入 用户的文本指令（最常见）、图片、音频、视频等 工具返回结果 搜索结果、API 响应、代码执行输出、数据库查询结果 系统状态 文件内容、环境变量、当前任务进度 历史记忆 短期记忆（上下文窗口中的对话历史）+ 长期记忆（从向量数据库检索） 这四类来源最终都会被拼装进 LLM 的上下文窗口，LLM 基于这个完整上下文做出下一步决策。因此，感知本质上是构建 LLM 输入上下文的过程。 上下文窗口：感知的硬性约束 能放入上下文的信息量取决于模型的上下文窗口大小（以 token 计）： ...

MCP 是什么 MCP（Model Context Protocol，模型上下文协议）是一个开源标准协议，用于将 AI 应用与外部系统连接起来。 可以把 MCP 理解为 AI 应用的 USB-C 接口。就像 USB-C 为电子设备提供了标准化的连接方式，MCP 为 AI 应用与外部系统的连接提供了统一标准。 有了 MCP，Claude、ChatGPT 等 AI 应用可以连接到： 数据源：本地文件、数据库 工具：搜索引擎、计算器、代码执行环境 工作流：自定义 prompt 模板、业务系统 MCP 解决了什么问题 问题背景 在 MCP 出现之前，每个 AI 应用如果想连接外部工具或数据源，都需要为每种组合单独开发集成代码。这导致： 重复开发：A 工具想接 GitHub，B 工具也想接 GitHub，各自写一套 维护成本高：N 个 AI 应用 × M 个外部工具 = N×M 个集成要维护 互不兼容：为 Claude 写的插件不能直接用在 ChatGPT 上 MCP 的解决方案 MCP 引入了统一的 Client-Server 架构： MCP Server：外部工具/数据源的提供方，按照 MCP 协议暴露能力 MCP Client：AI 应用（如 Claude、VS Code Copilot），按照协议调用 Server 这样只需要： ...

Hand Off 是什么 VS Code Copilot Chat 在 Agent 模式下提供 “Hand off a session to another agent” 功能，将当前对话的完整上下文移交给另一个 agent 继续处理。 移交时，接收方 agent 会获得： 完整的对话历史记录 已收集的文件上下文 前一个 agent 的中间结论和工具输出 接收方 agent 可以直接从当前状态继续，而不需要从头重建上下文。 与普通切换 Agent 的区别 普通切换 Hand off 上下文 丢失，重新开始 完整传递 用途 新任务 同一任务的延续 历史记录 不带过去 带上全部历史 为什么要切换 Agent，而不是在主 Agent 里继续？ Fan-out 并行（最核心的理由） 主 agent 收集完上下文后，同时把同一份上下文发给多个子 agent 做不同的事： 主 agent 分析完代码库 ├── 子 agent A → 写单元测试 ├── 子 agent B → 写文档 └── 子 agent C → 做安全审查 主 agent 是单线程的，无法并行处理多个子任务。Fan-out 到多个子 agent 是最强的切换理由。 ...

什么是 CrewAI CrewAI 是一个开源的 Python 框架，专门用于构建和管理多智能体（Multi-Agent）系统。它允许开发者创建一个由多个 AI 智能体组成的"团队"（Crew），这些智能体可以协同工作，共同完成复杂的任务。 核心概念 Agent（智能体） Agent 是 CrewAI 中的基本执行单元，代表一个具有特定角色和能力的 AI 助手。每个 Agent 具有： Role（角色）：定义 Agent 的身份和职责 Goal（目标）：Agent 要达成的目标 Backstory（背景故事）：为 Agent 提供上下文和个性 Tools（工具）：Agent 可以使用的工具集合 from crewai import Agent researcher = Agent( role='研究员', goal='收集和分析相关信息', backstory='你是一位经验丰富的研究专家，擅长从各种来源收集准确信息', tools=[search_tool, scrape_tool], verbose=True ) Task（任务） Task 定义了需要完成的具体工作，包括： Description（描述）：任务的详细说明 Agent：负责执行该任务的智能体 Expected Output（期望输出）：任务完成后的预期结果 from crewai import Task research_task = Task( description='研究 AI 领域的最新发展趋势', agent=researcher, expected_output='一份包含最新 AI 趋势的详细报告' ) Crew（团队） Crew 是多个 Agent 和 Task 的组合，负责协调整个工作流程： from crewai import Crew, Process crew = Crew( agents=[researcher, writer, reviewer], tasks=[research_task, write_task, review_task], process=Process.sequential # 顺序执行 ) result = crew.kickoff() 执行流程 CrewAI 支持两种执行流程： ...

Ollama 简介 Ollama 是一个开源的本地大语言模型运行工具，可以让你在本地轻松运行 Llama 2、Mistral、Qwen 等多种开源大语言模型。 安装 Ollama Linux 安装 # 使用官方安装脚本 curl -fsSL https://ollama.com/install.sh | sh 安装记录 (2025-11-14)： 安装版本：v0.12.11 安装位置：/usr/local/bin/ollama 服务配置：已创建 systemd 服务 ollama.service 默认监听：127.0.0.1:11434 GPU 支持：检测到 AMD GPU，安装了 ROCm 支持 用户组：创建了 ollama 用户，并加入 render 和 video 组 自动启动：服务已启用并自动运行 手动安装 # 下载二进制文件 curl -L https://ollama.com/download/ollama-linux-amd64 -o ollama chmod +x ollama sudo mv ollama /usr/local/bin/ 验证安装 # 检查版本 ollama --version # 输出: ollama version is 0.12.11 # 检查服务状态 systemctl status ollama # 测试 API 是否可用 curl http://127.0.0.1:11434/api/version # 输出: {"version":"0.12.11"} 基本使用 启动 Ollama 服务 # 启动服务 ollama serve 拉取模型 # 拉取 Llama 2 模型（7B 参数版本） ollama pull llama2 # 拉取 Mistral 模型 ollama pull mistral # 拉取 Qwen 模型 ollama pull qwen # 拉取 Phi 模型（推荐入门） ollama pull phi 本地已安装模型 (2025-11-14)： ...

AI AI IDE Microsoft Copilot Cursor Windsurf augment code AI 编程 之前有一种想法，有些小的修改， 比如只有几行代码的修改不需要用 AI, 因为构思提示词的时间往往比直接写代码的时间要长，但是最近这种想法有了一丝松动，AI 写代码出的问题更少一些， 手工改代码很有可能一不小心拷错了，或者敲错字符，AI写码不会有这些小问题，另外 AI 去改的时候会发现一些本来我认为不需要修改的逻辑分支，如果手动修改的话，这些分支只能是等到测试阶段才被发现。