一、AI辅助编程方式：Prompt、Context、Harness、Loop

AI辅助编程方式
│
├── 演化阶段（能力维度）
│   ├── 语法级补全（2020–2023）
│   ├── 语义理解与对话（2023–2025）→ 催生 Vibe Coding
│   └── 智能体架构（2026–今）    → 推动 Agentic Coding
│
├── 顶层范式（协作模式）
│   ├── Vibe Coding
│   └── Agentic Coding
│       └── 底层四个工程抓手
│           ├── Prompt Engineering
│           ├── Context Engineering
│           ├── Harness Engineering
│           └── Loop Engineering
│
└── 说明
    ├── Vibe Coding 的核心是人类即时判断和自然语言迭代，不强制使用完整工程链路。
    ├── Agentic Coding 的核心是让 AI 围绕目标自主执行，并用工具、反馈和验证闭环收敛。
    └── Prompt、Context、Harness、Loop 分别解决“怎么表达任务、给什么信息、如何约束验证、如何迭代闭环”。

---

1. 演化主线

演化阶段	时间窗口	核心能力	对应的主导范式	代表工具/标志	要点说明
语法级补全	2020–2023	预测下一行/若干行代码	尚未形成独立范式	GitHub Copilot（初代）	AI 首次进入编程领域，作为“高级自动补全”存在；开发者需提供完整上下文语义
语义理解与对话	2023–2025	自然语言 → 代码，局部需求理解	Vibe Coding 成为主流	ChatGPT 集成、Copilot Chat	工具形态从 IDE 内补全转向 agent 中心化工作流；Cursor agent 用量一年增长超 15 倍，用户重心从 Tab 补全转向 Agent
智能体架构	2026–至今	自主规划、执行、测试、迭代	Agentic Coding 成为焦点	Claude Code、Codex、Cursor	核心跃迁：AI 从“被动响应”升级为“主动执行”；能够自主规划多步任务、调用外部工具、运行测试并迭代修正

---

2. 顶层范式：Vibe Coding vs. Agentic Coding

范式	定义	主导方	交互模式
Vibe Coding	开发者通过自然语言对话与AI协作，AI生成代码，人类即时评估并持续迭代，始终在回路中	人类	对话式、步骤式
Agentic Coding	AI智能体自主理解目标、拆解任务、调用工具、执行代码、运行测试、根据反馈修正，最小化人工干预	AI智能体	目标驱动、闭环自主

2.1 Vibe Coding（氛围编码）

起源：术语由 Andrej Karpathy 于 2025 年 2 月在社交媒体上提出。

定义与特征：开发者通过自然语言对话与 AI 协作，AI 生成代码，人类即时评估并持续迭代。开发者可公开接受或忽略某些风险，而不像传统测试驱动开发那样严格要求所有验证环节。2025 年综述《A Survey of Vibe Coding with Large Language Models》将其界定为一种由开发者、项目上下文与编码 agent 共同构成的协同开发范式，归纳出迭代式对话、规划驱动、测试驱动、上下文增强等若干典型模式。

统计数据：Index.dev 2025 年分析显示，84% 的开发者正在使用 AI 编码工具，41% 的代码由 AI 部分生成。DORA 2025 报告调查近 5000 名开发者发现，90% 在工作中使用 AI 工具（同比增长 14%），超 80% 表示 AI 提升了生产力。

学术争议：低经验的 vibe coder 会生成更大体量的代码（提交数 2.15 倍、变更文件数 1.47 倍），收到 4.52 倍以上的评审意见，接受率低 31%，开启时长远 5.16 倍。这意味着项目管理者无法安全地替代经验丰富的开发者，而必须增加评审能力。

2.2 Agentic Coding（代理编码）

定义与特征：AI 智能体自主理解目标、拆解任务、调用工具、执行代码、运行测试、根据反馈修正，最小化人工干预。SonarSource 对 1100 多名软件开发者的调查显示，64% 的开发者已经开始使用 AI agent 进行开发工作（39% 试验中，25% 日常经常使用）。

使用场景分布：68% 使用 agent 创建代码文档，61% 用于自动测试生成与执行，57% 用于自动代码审查。高风险的漏洞修补仅占 28%。

采纳率：Romain Robbes 等人首次对 GitHub 上编码 agent 的大规模研究（128,018 个项目）表明，agent 采纳率已达 22.20%–28.66%。

企业投资：MIT Technology Review 与 SoftServe 发布的报告（300 位高级技术高管）显示，50% 的组织将 agentic AI 列为当前软件工程的顶级投资优先项，84% 表示到 2029 年将成为首要投资领域。

方法论区分：Thoughtworks 技术雷达指出，2025 年行业已从 vibe coding 的松散、基于氛围的方式，转向了系统化的上下文管理方法，但人类开发者依然至关重要。

---

工程范式	一句话概括	控制对象
Prompt Engineering	怎么问	单次任务表达与输出约束
Context Engineering	给什么信息	模型可见的信息环境
Harness Engineering	怎么约束和验证	Agent 的工具、权限、环境与检查器
Loop Engineering	怎么迭代闭环	目标 → 计划 → 执行 → 验证 → 修正的循环

---

（1）Prompt Engineering（提示词工程）

定义：设计、优化和动态生成输入提示的技术，包括角色设定、任务分解、输出格式约束、示例、边界条件等。

时间：2022–2024 年，作为 AI 辅助编程的第一代范式兴起。

核心要点：

• 提示质量直接影响输出方向、格式和可执行性
• 适合把模糊需求转成明确任务、约束和验收口径
• 实践中更依赖多轮校准，而不是一次写出“完美提示词”
• 在文档、解释、样例生成上最稳定；复杂代码仍需要上下文和验证支撑

适用场景：复杂任务拆解、格式约束、领域知识注入、需求澄清。

---

（2）Context Engineering（上下文工程）

定义：主动收集、维护并注入项目上下文的技术，包括代码库结构、依赖、API 定义、设计文档、历史决策、风格规范和当前任务状态。

时间：约 2025 年起被系统化讨论，并逐渐成为 coding agent 的核心能力。

核心要点：

• 从“优化话术”升级到“管理 AI 的信息环境”
• 支持多粒度上下文：片段、文件、模块、仓库、设计文档、运行日志
• 核心难点是在有限上下文窗口内选择最相关、最少但足够的信息
• 好的上下文能减少幻觉、重复探索和跨文件不一致

适用场景：大型项目重构、多文件协同修改、风格一致性保持、遗留系统理解。

---

（3）Harness Engineering（驾驭工程）—— Agent = LLM + Harness

定义：设计 AI 执行任务时可使用的工具、权限、沙箱、检查器和自动化验证流程，让生成结果能被真实环境约束和检验。

时间：2025 下半年–2026 年，随着可执行 coding agent 普及而成为第三代核心工程能力。

核心要点：

• 责任分离：LLM 负责推理和生成，Harness 负责工具调用、权限边界、安全管控和结果验证
• 核心信念：靠代码、linter、测试、类型检查和运行结果保证正确性，而非依赖 LLM 直觉
• 支持分级验证：快速语法检查 → 单元测试 → 集成测试 → 回归测试 → 人工验收
• Harness 的质量会直接决定 agent 是否能从“会写代码”升级为“能交付任务”

适用场景：高可靠模块、CI/CD 代码生成、回归测试保障、安全敏感变更。

---

（4）Loop Engineering（闭环工程）

定义：围绕一个目标，设计 AI 从“理解目标 → 制定计划 → 修改/生成 → 运行验证 → 读取反馈 → 修正迭代 → 达成验收”的闭环机制。它关注的不是单次回答质量，而是任务能否在多轮执行中持续收敛。

时间：2025–2026 年随着 coding agent、云端任务和可执行工具链普及而成为关键方法。它不是独立替代 Prompt、Context、Harness 的新物种，而是把三者串成可重复、可验证、可停止的工作循环。

核心要点：

• 目标锚定：先明确完成标准、验收口径和不可做事项，避免 agent 在循环中偏航
• 小步迭代：把大任务拆成可观察的短循环，每轮都有明确产物或检查结果
• 反馈驱动：反馈信号来自编译、测试、linter、运行日志、代码审查和人工意见
• 停止条件：定义何时完成、何时回滚、何时请求人工确认，避免无限自动修补
• 状态记录：保留计划、变更、失败原因和已验证结论，方便跨轮继续或审计

适用场景：复杂 Bug 修复、多文件重构、自动化测试补齐、长任务委派、需要反复验证的工程任务。

说明：多 Agent 协同更适合作为单独专题，而不是 AI 编程通识里的第四个通用范式。多数真实任务首先需要稳定的 Context、Harness 和 Loop；多 Agent 协作只是其中一种高级实现方式，并不具备同等普适性。

二、AI主流编程工具：Cursor、Codex、Claude Code

在2026年的AI编程工具领域，OpenAI Codex、Claude Code和Cursor已分化为三种截然不同的产品形态，它们不再是同类竞品，而是服务于不同开发场景的专属工具。直接的基准测试分数对比已无太大意义，真正的选择应基于你的主力工作台是IDE、终端还是云端任务面板。

以下将从核心形态、性能基准、成本模型和最佳场景四个维度，为你梳理这三款工具的最新实力定位。

📊 核心性能与定位对比

对比维度	Cursor	OpenAI Codex	Claude Code
产品形态	AI原生IDE（基于VS Code）	云端委派型Agent（CLI+App）	终端优先型Agent
核心基准	Terminal-Bench 2.0：61.7% SWE-bench Multilingual：73.7%	Terminal-Bench 2.0：77.3% SWE-bench Pro：56.8%	SWE-bench Verified：80.8% Terminal-Bench 2.0：65.4%
上下文窗口	较大（结合Cloud Agents）	200K tokens	100万 tokens
性能特性	编辑器集成最深，交互流畅	速度最快（1000+ tok/s），任务隔离最强	任务最彻底（但Token消耗高3-4倍）
月费成本	$20/月起（Pro）	包含在ChatGPT Plus（$20/月）中	$20/月（Pro）
最佳场景	日常主力IDE，边写边改	安全隔离的云端任务、并行处理	复杂重构、大型代码库排障

---

🔍 深度解读：数据背后的核心差异

1. 性能表现：专长不同，赛道不同

三者各自在一个关键的细分赛道上领先，没有绝对的“全能冠军”。

• Codex在终端任务上最快：它在Terminal-Bench 2.0（真实终端任务）上获得了77.3% 的最高分，推理速度高达1000+ tokens/秒，是Claude Code的5倍。如果你的任务是快速、高频的终端交互，Codex是性能首选。
• Claude Code在软件工程上最“稳”：它在SWE-bench Verified（软件工程任务）上取得了80.8% 的最高分，体现了处理复杂、真实世界代码问题的强大能力。但代价是它会消耗3-4倍于Codex的Token来追求“彻底性”。
• Cursor在“自研+集成”上进步神速：其自研的Composer 2模型在Terminal-Bench 2.0上得分61.7%，超越了Claude Opus 4.6的58.0%，并且将成本降低至后者的1/10。这说明Cursor正在快速摆脱对第三方模型的依赖。

2. 任务架构：决定工作方式的根本

三者的架构设计决定了它们适合完成什么类型的任务。

• Cursor：IDE中心主义。它的设计目标是让你的编辑器更强大，适合边写代码边和AI协作，是日常开发的“主力环境”。
• Codex：云端沙箱隔离。每个任务都运行在独立、无网络访问的云端容器中，这带来了最强的任务隔离性和安全性，非常适合处理你不信任或需要绝对保密的代码片段。
• Claude Code：终端里的Agent Teams。它支持创建多个子Agent，这些Agent可以相互通信、共享任务列表、跟踪依赖关系，协同完成一个复杂的大工程，比如同时进行代码研究、实现和测试。

3. 成本与陷阱：不止看标价

• Cursor：$20/月的固定订阅费，对于重度IDE用户是清晰的开销。
• Codex：对已有的ChatGPT Plus（$20/月）用户是“零边际成本”的增值服务，极具吸引力。
• Claude Code：$20/月的订阅费看起来不高，但要注意，如果配置不当使用API密钥，会产生额外账单。更重要的是，它“高Token消耗”的特性（3-4倍于Codex）可能会导致你更快地触及使用上限。
  本实际使用体验的反馈。

三、AI交互模式：Goal、Plan

当前更建议把 Ask / Craft / Agent 视为旧一代 IDE 或插件里的 UI 标签、历史叫法或局部能力；在 Codex、Claude Code 等新一代 coding agent 语境下，更有代表性的主干是 Goal（目标级控制） 和 Plan（过程级控制）。不同产品仍可能保留 Ask、Edit、Agent 等按钮名，但它们不再适合作为通用主分类。

1. 两种核心模式（对比）

模式	核心准则	控制对象	AI 的权限	你的角色	最佳应用场景
Goal	先定目标，再围绕完成/阻塞持续推进	任务生命周期	可跨多轮推进，围绕目标收敛；完成或真正阻塞时结束	目标设定者、边界设定者、最终验收者	长任务委派、跨轮跟进、持续分析、自动化监控、需要明确完成标准的工作
Plan	先拆步骤，再按计划执行和更新	本轮执行过程	先分析、列步骤、暴露风险；执行时按阶段推进并更新状态	审核者、校准者、协作者	复杂功能开发、架构设计、多文件重构、风险较高的批量修改

Goal 更像“任务级约束/追踪”，不一定是界面按钮；Plan 更像“过程级控制/协作方式”。默认直接对话或直接执行仍然存在，但它只是小任务的默认路径，不必再单列成一种通用范式。

---

2. Goal 模式（目标级控制）

核心理念
Goal 模式不是让 AI 立刻做某一步，而是给它一个可验收的最终目标。AI 围绕这个目标持续规划、执行、验证和汇报，直到目标达成，或者连续遇到无法自行突破的阻塞。

关键元素：

• 目标：最终要完成什么，而不是只描述下一步动作
• 完成标准：什么证据可以证明任务完成，例如测试通过、文件更新、报告生成、数据同步完成
• 边界条件：哪些文件不能动、哪些行为需要确认、哪些风险不能接受
• 预算与节奏：是否限制时间、token、轮次、费用或执行频率
• 阻塞判定：什么时候应停止尝试并请求人工输入

典型工作流
设定目标 → AI 拆解任务 → 执行与验证 → 记录进展 → 继续下一轮或报告完成/阻塞 → 人工验收

适用场景：长周期任务、需要跨轮保持状态的任务、自动化监控、复杂资料整理、端到端工程交付。

---

3. Plan 模式（过程级控制）

核心理念
Plan 模式是在“理解需求”和“动手修改”之间插入规划层。AI 先把任务拆成可审阅的步骤，说明依赖、风险和验证方法，再逐步执行。它的价值是让复杂任务变得可见、可控、可中途纠偏。

关键元素：

• 步骤拆解：把大任务拆成有顺序、有依赖的阶段
• 风险暴露：提前说明不确定点、可能破坏的地方和需要确认的边界
• 状态更新：执行后持续更新已完成、进行中、待处理事项
• 验证安排：明确用什么命令、测试、检查或人工验收来证明结果正确
• 可中断性：用户可以在计划阶段调整方向，避免 AI 直接大范围改动

典型工作流
提出需求 → AI 生成计划 → 你审核/修改计划 → AI 按计划执行 → 每完成一段更新状态 → 最终验证和总结

适用场景：架构调整、多文件修改、迁移升级、复杂 Bug 排查、会影响现有行为的变更。

---

4. Goal 与 Plan 的关系

Goal：定义“要到哪里、什么算完成”
  ↓
Plan：定义“怎么走、先做什么、如何验证”
  ↓
Loop：执行 → 反馈 → 修正 → 再验证

• Goal 可以包含多个 Plan：一个长期目标可能分多轮、多阶段推进，每一轮都有自己的计划
• Plan 可以单独使用：一次复杂但短周期的任务，只需要先规划再执行，不一定需要长期 Goal
• Goal 管结果，Plan 管过程：Goal 防止方向漂移，Plan 降低执行失控
• Loop 连接二者：没有反馈和验证，Goal 会变成口号，Plan 会变成清单

---

5. 旧四分法为何降级为历史/产品 UI

旧模式	现在更适合怎么理解
Ask	普通问答或只读分析能力，仍常见，但不是独立工程范式
Craft / Edit	IDE 局部编辑动作，适合框选修改、单文件快速生成，已被更强的 agent/edit 流程吸收
Agent	已经成为底层产品形态或能力底座，不再适合作为与 Plan、Goal 并列的“模式”

实用选择：

• 小问题、概念解释、单点改文：直接对话即可
• 多文件、有风险、需要先想清楚：用 Plan
• 长任务、跨轮跟进、需要明确完成/阻塞状态：用 Goal
• 高可靠工程任务：Goal + Plan + Harness + Loop 一起用

其他

岗位细分：AI 原生工程师、AI 应用工程师

这两者的核心区别在于：一个更偏向模型本身或系统底层（AI原生），一个更偏向利用模型解决具体业务问题（AI应用）。

维度	AI原生工程师	AI应用工程师
关注点	模型能力、效率、可控性	业务逻辑、用户体验、快速落地
是否训练/微调模型	经常（甚至从头训练）	很少（最多做轻量微调）
主要工具	PyTorch, CUDA, 分布式训练框架	LangChain, API, 向量数据库, Prompt工具
典型问题	训练loss不降、显存OOM、推理慢	模型输出格式错误、幻觉、成本控制
对AI原理的深度要求	深（需要理解反向传播、注意力机制）	中等（理解能力边界和接口即可）
典型公司角色	AI Infra团队、模型团队	产品开发团队、创新业务团队

1. AI 原生工程师

• 核心关注：AI 模型本身、AI 基础设施、AI 系统的设计与开发。强调“以AI为核心构建系统”，而不是在现有系统上“加一点AI”。
• 典型任务：
  • 设计、训练、微调大语言模型（LLM）或其他深度学习模型。
  • 开发推理引擎（如 vLLM, TensorRT-LLM）、模型 serving 平台。
  • 构建 AI Agent 框架、RAG（检索增强生成）系统的核心组件。
  • 优化 GPU 利用率、分布式训练、模型压缩量化。
  • 研究并实现新的模型架构（如 Transformer 变体）或训练方法。
• 所需技能：
  • 扎实的深度学习理论（PyTorch/TensorFlow/JAX）。
  • 精通 Python/C++ 和 CUDA 编程（通常）。
  • 熟悉分布式系统、高性能计算。
  • 了解模型架构细节（注意力机制、MoE、LoRA 等）。
  • 能处理训练不稳定、收敛问题等“AI特有”的工程挑战。
• 类比：造发动机 / 设计芯片的人。他们制造AI的“引擎”。
• 产出：基础模型、推理框架、Agent开发平台、AI开发工具链。

2. AI 应用工程师

• 核心关注：利用现成的AI模型（API或开源模型）快速构建面向用户的产品功能。解决“如何让AI完成某个业务任务”。
• 典型任务：
  • 调用 OpenAI / Anthropic / 本地开源模型 API，构建聊天机器人、内容生成工具、代码助手等。
  • 设计 Prompt（提示工程），通过上下文学习让模型输出符合业务格式。
  • 构建 RAG 应用：连接向量数据库（如 Pinecone, Milvus），实现文档问答。
  • 编排多步骤的 AI 工作流（使用 LangChain, LlamaIndex, Dify 等）。
  • 对模型输出进行校验、后处理、安全过滤。
  • 评估不同模型在特定任务上的效果，做模型路由。
• 所需技能：
  • 熟悉常见 LLM API 和开源模型的能力边界。
  • 擅长 Prompt Engineering、Chain-of-Thought 等技巧。
  • 基本的编程能力（Python/TypeScript），能连接数据源和前端/后端系统。
  • 了解 Embedding、向量检索的基本原理。
  • 具备产品思维：知道如何评估AI的输出质量，何时需要人工介入。
• 类比：使用发动机来造汽车 / 飞机的人。他们不造引擎，但精通如何把引擎装到合适的载体上，让载体跑起来解决运输问题。
• 产出：AI聊天客服、企业知识库问答、自动化报告生成器、AI绘画工作流等终端功能。

产品形态：基础大模型、对话式AI、AI Agent

类别	子类	核心定位	核心类比	自主性	工具调用方式	典型代表
基础大模型（Foundation Models）	文本大模型（Large Language Model，LLM）	智能能力本身（文本）	引擎	无	不能调用工具	国际：GPT-5.4、Claude Opus 4.6、Grok 4.20、Llama 4、Mistral Large 3 国产：DeepSeek-V3/R1、通义千问Qwen 3.5、GLM-5、Kimi K2.5、文心一言5.0、MiniMax M2.5、腾讯混元
	多模态大模型（Large Multimodal Model，LMM）	智能能力本身（图文/音/视频）	引擎	无	不能调用工具	国际：Gemini 2.5/3.1、GPT-5 with vision、Claude 4 Vision、Llama 4 MultiModal、Sora、Veo、Runway Gen-4、Stable Diffusion 4.0 国产：通义万相、文心多模态、GLM-4V、智谱清影、可灵Kling 3.0、海艺AI、即梦Seedance 2.0
对话式AI（Conversational AI，CoAI）	—	智能能力的对话封装	整车	低（回合对话）	用户主动触发，单步	国际：ChatGPT、Claude.ai、Gemini、Perplexity、Microsoft Copilot、Grok 国产：豆包、Kimi、DeepSeek Chat、文心一言、通义千问
AI 智能体 (AI Agent)	—	智能能力的自主执行体	自动驾驶车队	高（自主规划、多步闭环）	自动拆解任务、多工具链式调用	国际：Cursor、Claude Code、OpenAI Codex、Devin、GitHub Copilot Agent、Windsurf、Google Antigravity 国产：豆包Agent、文心快码、通义灵码、智谱AutoGLM

基础大模型（底层智能）
    ↓ 封装
对话式AI（对话交互界面）
    ↓ 增强自主性
AI Agent（自主执行体）
# AI Agent通常内部包含一个或多个大模型，也可能以对话式AI作为前端入口，但其核心是**执行闭环**而非问答。

响应模式：非流式请求 vs. 流式请求

核心区别在于数据返回的方式和时机。

维度	非流式请求 (Non-Streaming)	流式请求 (Streaming)
响应方式	一次性返回完整结果	逐字/逐块返回生成内容
用户感知	等待后一次性呈现	实时看到生成过程（打字机效果）
首字延迟	较高（需等待完整生成）	极低（首块内容快速返回）
适用场景	短内容、简单问答、批量处理	长文本、实时对话、ChatGPT式交互
技术实现	单次 HTTP 请求+响应	SSE（Server-Sent Events）或 WebSocket
中断能力	不支持（一旦开始必须等待完成）	支持（可随时关闭连接停止生成）
代表产品	批量 API 调用、离线任务	ChatGPT、Claude 网页版、DeepSeek Chat

【非流式】
用户 ──请求──▶ 服务器（生成中...生成完成）──完整结果──▶ 用户
        等待时间 = 完整生成时间

【流式】
用户 ──请求──▶ 服务器 ──第一块──▶ 用户（看到开头）
                ──第二块──▶ 用户（继续）
                ──第三块──▶ 用户（继续）
                ──完成────▶ 用户
         首字延迟极低，边生成边显示
         
################################################
# 非流式
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "讲个故事"}],
    stream=False  # 非流式
)
print(response.choices[0].message.content)  # 一次性输出完整故事


# 流式
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "讲个故事"}],
    stream=True  # 流式
)
for chunk in response:
    print(chunk.choices[0].delta.content, end="")  # 逐字输出
################################################

会议纪要AI工具 —— 实时录音转文字，自动生成会议纪要

工具	类型	核心功能	支持平台	免费额度	付费起价
Otter.ai	国际/实时转录	实时转录、自动摘要、发言人识别	Zoom、Meet、Teams、Webex	300分钟/月	$16.99/月
Fireflies.ai	国际/实时转录	转录、摘要、动作项提取、知识库搜索	全平台+API	无限（功能受限）	$19/月
Fathom	国际/会议机器人	一键录制、高亮标记、CRM集成	Zoom、Meet、Teams	完全免费	—
Read.ai	国际/会议机器人	健康度分析、情绪识别、参与度追踪	Zoom、Teams、Meet	基础免费	$15/月
Tactiq	国际/实时转录	实时字幕、一键生成纪要、导出Docs	Meet、Zoom、Teams	10次/月	$8/月
Avoma	国际/会议机器人	全周期管理（会前→会中→会后）	全平台	30天试用	$30/月
Sembly	国际/会议机器人	任务追踪、风险识别、合规审计	全平台	10次/月	$15/月
通义听悟	国产/实时转录	实时转录、章节速览、PPT提取、中英混合	网页/App	10小时/天	基础免费
讯飞听见	国产/实时转录	ASR转录、多语翻译、发言人分离	网页/App	分钟计费	按分钟
腾讯会议AI助手	国产/原生集成	自动总结、待办提取	腾讯会议	企业版包含	企业版
飞书妙记	国产/原生集成	转录、翻译、智能章节、任务联动	飞书	付费版包含	飞书付费版
华为云会议智能纪要	国产/原生集成	自动区分发言人、实时字幕	华为会议	企业版包含	企业版

---

需求	首选
个人免费（国际会议）	Fathom
个人免费（中文会议）	通义听悟
功能全面团队使用	Fireflies.ai
飞书/腾讯会议用户	原生AI助手