一套面向深度 AI 使用者的能力 Benchmark

现在，越来越多的人开始说自己“在用 AI”。

有人用 AI 写文章，有人用 AI 改 PPT，有人用 AI 写代码，有人用 AI 做调研，有人用 AI 生成图片和视频，也有人用 AI 辅助项目管理、产品设计、数据分析和商业判断。

但问题在于：“用过 AI”已经不再构成差异。

在今天，一个人是否使用 AI，已经不是最重要的问题。真正重要的问题是：

他到底是一个普通 AI 工具使用者，还是一个真正 AI Native 的人？

更具体一点说：

他是否理解模型？
是否理解 AI 产品的演化？
是否具备 AI 工程化能力？
是否会评估 AI 的真实效果？
是否能把新工具、新产品、新框架快速吸收到自己的工作系统中？
是否已经在真实工作中表现出 AI 加持下的能力跃迁？
是否理解 AI 正在如何改变组织、产业、职业和世界格局？

这些问题，不能只靠感觉回答。

我之所以想建立一个 AI Native Benchmark，是因为我发现，很多和 AI 有关的探索行为，过去是凭兴趣和敏感度在做的：看到一个新模型，试一下；看到一个新产品，体验一下；看到一个创业者访谈，听一听；看到一个开源项目，收藏一下；看到一个新的 AI 工作流，尝试迁移到自己的工作里。

这些动作本身是对的，但如果没有框架，就会变成一种碎片化的追热点。

一个人可能看了很多 AI 新闻，用了很多 AI 工具，收藏了很多开源项目，也听了很多创始人访谈，但最后并没有形成系统能力。反过来，一个真正 AI Native 的人，应该能把这些前沿变化持续转化为自己的模型理解、产品判断、工程实践、工作流升级和组织影响力。

所以，这套 Benchmark 的目的，不是为了给自己贴一个“AI Native”的标签，而是为了把原本感性的 AI 探索变成一套可复盘、可比较、可持续提升的能力框架。

一、为什么普通 AI 使用能力框架已经不够了？

过去我们讨论一个人会不会用 AI，常常会问这些问题：

• 会不会写 prompt？

• 会不会让 AI 总结文章？

• 会不会让 AI 写文案？

• 会不会用 AI 生成图片？

• 会不会用 AI 辅助写代码？

• 会不会用 AI 做搜索和调研？

这些问题对于普通用户是有意义的，但对于已经深度使用 AI 的人来说，已经不够了。

因为今天很多专业用户已经不只是“会用 AI”，而是已经在用 Claude、ChatGPT、Gemini、DeepSeek、Cursor、Claude Code、Codex、Perplexity、NotebookLM、Dify、n8n、各种 Agent 框架和开源工具改造自己的工作流。

对这些人来说，真正的差距不再是“会不会问 AI”，而是：

• 是否知道不同模型的能力边界？

• 是否能根据任务选择模型，而不是永远用最强模型？

• 是否关注 AI 创业者的长篇访谈，并从中判断产品演化方向？

• 是否实际试用过同赛道 AI 产品，并能形成横向比较？

• 是否实践过 spec、TDD、eval、harness、context engineering、agent workflow？

• 是否能跑通、比较、改造开源 AI 项目？

• 是否能把新的 AI 技能沉淀成自己的 prompt、skill、SOP、模板、知识库和自动化流程？

• 是否能同时管理多个 AI Agent，让它们并行完成一个从零到一的项目？

• 是否能判断 AI 对组织结构、产业分工、大公司战略和个人职业路径的深层影响？

如果没有这些能力，一个人即使用 AI 很频繁，也可能只是一个 AI Power User，而不是真正的 AI Native。

所以，我们需要一套更高阶的 benchmark。它评估的不是“会不会用 AI”，而是：

一个人是否能把 AI 前沿变化转化为个人能力、工作系统、产品判断、工程实践、组织影响力和世界理解框架。

二、这套 AI Native Benchmark 应该分成三个层级

我认为，真正完整的 AI Native Benchmark 不应该只从个人技能角度评估。它至少应该包含三个层级：

第一层评估的是“能力结构”。

第二层评估的是“真实表现”。

第三层评估的是“宏观理解”。

这三个层级合起来，才能比较完整地回答一个问题：

一个人是否真正 AI Native？

只会使用工具，不够。

只在自己工作里提效，也不够。

只看宏观趋势但没有个人实践，也不够。

真正的 AI Native，应该同时具备三个方向：

1. 微观能力：能使用、评估、工程化和系统化 AI；

2. 工作表现：能通过 AI 实现能力边界跃迁，并影响团队；

3. 宏观理解：能理解 AI 对世界结构的改变，并反过来指导个人行动。

三、第一层：AI Native Practitioner Benchmark

面向专业用户的十个能力维度

第一层是整个体系的基础。它评估的是一个人作为 AI 深度实践者，是否具备足够完整的专业能力结构。

我把它拆成十个维度：

1. 前沿模型理解力；

2. AI 产品洞察力；

3. AI 工程化实践力；

4. Benchmark 方法论能力；

5. 开源 AI 生态实践力；

6. 个人 AI 能力栈构建力；

7. 前沿雷达能力；

8. 战略判断与品味；

9. Eval 运行能力；

10. 安全、可靠性与治理能力。

维度一：前沿模型理解力

Frontier Model Literacy

这一项评估的是：

一个人是否真正理解不同大模型的能力结构，而不是只知道模型名字。

很多人说自己了解 AI 模型，其实只是知道 GPT、Claude、Gemini、DeepSeek、Qwen、Llama 这些名字。但专业用户不能只停留在模型名称层面，而应该知道不同模型的能力边界、适用场景、成本结构、更新节奏和失败模式。

专业用户至少要理解以下内容：

这一维度的高阶标准不是：

我用过很多模型。

而是：

我能为不同任务建立模型选择策略，并用自己的真实任务验证模型效果。

也就是说，真正高级的模型理解，不是“知道哪个模型最强”，而是知道：

• 在什么任务上哪个模型更稳；

• 在什么任务上应该牺牲一点质量换速度；

• 在什么任务上应该牺牲一点成本换可靠性；

• 在什么任务上应该引入工具调用；

• 在什么任务上不能相信模型直接输出；

• 在什么任务上需要自己做 eval。

模型理解力，是 AI Native 能力的底层。

维度二：AI 产品洞察力

AI Product Intelligence

这一项评估的是：

一个人是否能通过创始人访谈、产品体验、同赛道横评、商业模式分析和交互范式观察，理解 AI Native 产品的演化路径。

AI 产品洞察力不是简单地知道“最近有哪些 AI 工具”。真正的产品洞察力，应该建立在长期观察、深度访谈、亲自试用、横向比较和商业判断之上。

尤其是对于正在创业做 AI 产品的人，他们的长篇访谈非常值得关注。因为在访谈中，创始人往往会表达：

• 自己为什么做这个产品；

• 自己过去的经历如何影响产品判断；

• 自己认为下一代 AI 产品会如何演化；

• 当前产品为什么采用这种交互方式；

• 产品商业化路径是什么；

• 他们如何理解用户、场景、留存、分发和护城河。

这些内容的价值，不只是听故事，而是可以帮助我们形成几个判断：

1. 什么样的产品需要什么样背景的人去做；

2. 哪些创始人对用户理解更深；

3. 哪些产品只是功能包装，哪些产品代表新的范式；

4. 有经验的创业者和经验不足的创业者在产品设计上有什么差异；

5. 不同创业者对同一个 AI 方向的判断是否一致；

6. 一个产品的商业化路径是否完整；

7. 一个产品是否有长期护城河。

专业用户至少要具备以下能力：

这里还有一个很重要的行为闭环：

AI 产品试用闭环

一个真正有产品洞察力的人，不应该只停留在看新闻、看融资、看评测，而应该形成一个固定动作：

发现产品 → 制造需求 → 真实试用 → 横向比较 → 评估交互 → 判断商业逻辑 → 思考嵌入工作流 → 决定是否沉淀

例如，一个成熟大公司发布了新的 AI 产品，如果它反复被报道，或者明显达到了生产力提升级别，那么就不应该只是“知道它发布了”。更好的做法是：在自己的真实工作中制造几个小需求，把它和已有工具放在同一个任务里比较，体验其优劣，然后头脑风暴它是否可以嵌入自己的工作流程，或者围绕它构建新的工作流。

同样，对于小而美的创业公司产品，也不应该只看 demo。很多创业公司产品虽然规模小，但它们可能更激进，更接近新交互范式的前沿。

对于国内成熟厂商推出的 AI 平台，比如内容创作方向的平台，也值得关注。因为这些产品可能更贴近本土创作者和企业场景，它们的模式、交互、底层社区、模板体系、内容生产链路，都能提供非常有价值的观察。

此外，还应该关注高质量 AI 创作者。

很多 AI 产品的真正能力边界，往往不是先出现在官方发布会，而是先出现在顶级创作者手里。比如：

• 一个人快速制作游戏；

• 一个人制作 MV；

• 一个人生成短剧；

• 一个人完成 3D 资产；

• 一个人做出应用原型；

• 一个人搭建内容矩阵；

• 一个人用 AI 完成过去需要多角色协作的作品。

这些创作者的作品、博客、视频和工作流，都是观察 AI 产品真实能力的重要资料。

因此，AI 产品洞察力的高阶标准不是：

我知道很多 AI 产品。

而是：

我能通过访谈、体验、横评和商业分析，判断一个 AI 产品为什么成立、为什么不成立，以及它代表了哪种 AI Native 产品演化方向。

维度三：AI 工程化实践力

AI Engineering Practice

这一项评估的是：

一个人是否能把 AI 能力从一次性生成，变成可测试、可复用、可维护的工程流程。

AI 深度使用者和普通用户之间，一个非常重要的区别是：普通用户把 AI 当成“生成器”，高级用户把 AI 当成“工程系统的一部分”。

例如，普通用户会说：

帮我写一段代码。

高级用户会说：

我先写 spec，定义验收标准，设计测试，再让 AI coding agent 实现，然后通过测试、review、trace、diff 和回归检查结果。

这就是工程化差异。

专业用户至少要具备以下能力：

这里要特别强调一个新能力：

Agent Orchestration Bandwidth

AI Agent 调度带宽

未来效率提升的上限，很可能取决于一个人能同时管理多少个 AI Agent。

过去管理能力主要体现为管理人：分配任务、检查结果、协调资源、推动进度。

但在 AI 时代，管理对象开始从人扩展到 Agent。

一个高阶 AI 使用者，不只是能让一个 AI 帮自己写东西，而是能把一个复杂项目拆成多个子任务，让不同 agent 并行执行：

• 一个 agent 做资料调研；

• 一个 agent 做产品分析；

• 一个 agent 写代码；

• 一个 agent 做测试；

• 一个 agent 做视觉方案；

• 一个 agent 做文档；

• 一个 agent 做反向审查；

• 一个 agent 做复盘总结。

但是，多 agent 并不等于越多越好。

真正的能力不在于“同时打开多少个 agent”，而在于：

• 是否能清楚拆任务；

• 是否能给每个 agent 设定边界；

• 是否能避免上下文污染；

• 是否能统一输出格式；

• 是否能整合多个结果；

• 是否能发现不同 agent 之间的冲突；

• 是否能控制质量；

• 是否能在复杂度上升时保持主线判断。

所以，AI 工程化实践力的高阶标准不是：

我会用 Claude Code、Cursor 或 Codex 写代码。

而是：

我能用 spec、test、trace、review、回归机制和多 agent 调度，把 AI coding 从一次性生成变成可靠工程流程。

维度四：Benchmark 方法论能力

Benchmark Methodology

这一项评估的是：

一个人是否理解什么是好的 benchmark，而不是只会看排行榜和跑分。

很多人判断模型和工具时，喜欢看榜单。榜单有价值，但不能完全依赖。因为不同 benchmark 测的能力不同，数据可能被污染，样本可能偏向某类任务，评分方法也可能和真实工作不一致。

专业用户至少要具备以下能力：

好的 benchmark 不是简单问几个问题，而是要回答：

• 测什么？

• 为什么测这些任务？

• 样本是否有代表性？

• 指标是否和真实目标一致？

• 评分是否可靠？

• 是否有对照组？

• 是否能复现？

• 是否能解释失败？

• 是否能指导下一步决策？

这一维度的高阶标准不是：

我知道哪个模型榜单排名第一。

而是：

我能基于自己的真实任务设计评测集，并知道评测结果的适用边界。

维度五：开源 AI 生态实践力

Open-source AI Ecosystem Practice

这一项评估的是：

一个人是否真正进入了开源 AI 生态，而不是只停留在收藏项目和转发榜单。

AI 开源生态变化非常快。Agent 框架、RAG 框架、workflow 平台、模型服务工具、eval 工具、MCP server、UI 生成项目、内容创作工具、代码生成框架，都在不断出现。

但很多人对开源项目的关注停留在：

• 收藏 GitHub；

• 看 Star 数；

• 转发项目介绍；

• 看别人评测；

• 觉得“这个项目很强”。

这还不够。

专业用户至少要具备以下能力：

这一维度很强调“实践优先”。

一个 AI Native 的学习方式，不应该是先纠结理论、先看大量介绍、先收藏很多资料，而是：

看到有价值的新工具或开源项目，先找一个最小任务跑起来。
先建立手感，再回到文档、架构、原理和评测报告中深入理解。

这种方式可以叫：

Practice-first Learning Loop

实践优先学习闭环

它包括五步：

1. 发现新项目；

2. 选择一个最小真实任务；

3. 快速跑通；

4. 和已有工具比较；

5. 判断是否忽略、观察、加入工具栈、深入学习或改造成工作流。

这一维度的高阶标准不是：

我知道很多 GitHub 项目。

而是：

我能判断一个开源 AI 项目是否值得投入，并能把它转化成自己的能力组件。

维度六：个人 AI 能力栈构建力

Personal AI Capability Stack

这一项评估的是：

一个人是否能把外部 AI 工具、模型、框架和方法，吸收到自己的个人生产系统中。

很多人用 AI 是碎片化的：今天用这个工具，明天用那个工具；今天问一个 prompt，明天重新问；今天看一个教程，过几天忘掉。

真正 AI Native 的人，不应该只是“用过很多工具”，而应该逐渐形成自己的 AI 能力栈。

这个能力栈可能包括：

专业用户至少要具备以下能力：

这部分的核心是“复利”。

普通用户每次都重新开始。

AI Native 用户会让每一次 AI 使用都成为下一次的基础。

所以，这一维度的高阶标准不是：

我用了很多 AI 工具。

而是：

我有一套持续进化的个人 AI OS，能把新能力不断吸收到自己的工作系统中。

维度七：前沿雷达能力

Frontier Radar

这一项评估的是：

一个人是否能持续感知 AI 前沿变化，并从信息噪音中提炼出真正值得投入的方向。

AI 信息流非常嘈杂。每天都有新模型、新产品、新框架、新论文、新融资、新 demo、新概念。如果没有筛选能力，人很容易陷入两种状态：

一种是过度兴奋，什么都想试。

另一种是过度麻木，看到什么都觉得只是 hype。

真正的前沿雷达能力，既不是盲目追热点，也不是保守拒绝变化，而是能判断：

• 什么只是概念；

• 什么只是 demo；

• 什么已经有真实 adoption；

• 什么可以进入自己的工作流；

• 什么值得长期学习；

• 什么应该暂时观察。

专业用户至少要具备以下能力：

这一维度也包括前面提到的“实践优先学习闭环”。

当一个成熟产品或大公司发布新的 AI 产品，并且这个产品被反复报道、明显达到生产力提升级别时，我们不应该只围观，而应该在自己的生产过程中制造几个需求，进行横向评价和比较。

比如：

• 用同一个写作任务比较不同 AI 写作工具；

• 用同一个网页原型任务比较不同 AI 设计工具；

• 用同一个代码需求比较不同 AI IDE；

• 用同一个资料整理任务比较不同 AI 笔记或搜索产品；

• 用同一个视频创作任务比较不同 AI 视频工具；

• 用同一个内容矩阵任务比较不同 AI 内容创作平台。

这样，前沿信息就不只是信息，而会变成能力。

这一维度的高阶标准不是：

我每天看很多 AI 新闻。

而是：

我能从信息洪流中识别趋势、判断优先级，并及时调整自己的能力栈。

维度八：战略判断与品味

Strategic Judgment & Taste

这一项评估的是：

一个人是否能在快速变化的 AI 技术周期里，做出稳定、有效、低后悔率的判断。

很多人有信息，但没有判断。

看到新模型就想迁移，看到新框架就想重构，看到新产品就焦虑，看到 agent demo 就觉得马上能替代复杂工作，看到开源项目 star 高就以为它一定有价值。

这说明他有前沿敏感度，但还没有战略判断力。

专业用户至少要具备以下能力：

战略判断与品味，是一种综合能力。

它既需要模型理解，也需要产品体验；既需要工程现实感，也需要商业判断；既要有前沿敏感度，也要能反 hype。

这一维度的高阶标准不是：

我知道很多前沿概念。

而是：

我能在模型、产品、工程、成本和长期价值之间做出清醒取舍。

维度九：Eval 运行能力

Eval Operation Capability

这一项评估的是：

一个人是否能在真实工作中持续评估 AI 效果，而不是凭体感判断“好不好用”。

AI 使用者很容易说：

• 我觉得这个模型更聪明；

• 我觉得这个工具更好用；

• 我感觉这个 agent 不稳定；

• 我感觉这个 prompt 有用。

但“感觉”不够。专业用户需要把感觉转化为 eval。

Eval 能力不只是学术评测，也可以非常贴近日常工作。比如：

• 这个模型写文章，人工修改量减少了吗？

• 这个工具生成设计图，采用率提高了吗？

• 这个 agent 写代码，测试通过率是多少？

• 这个 workflow 做调研，事实错误率是多少？

• 这个 prompt 生成方案，能不能稳定复现高质量输出？

• 模型更新后，原来的工作流有没有退化？

专业用户至少要具备以下能力：

这里要区分“Benchmark 方法论能力”和“Eval 运行能力”。

Benchmark 方法论能力回答的是：

我是否知道如何设计一个评测框架？

Eval 运行能力回答的是：

我是否真的在自己的工作中持续运行评测？

前者偏方法论，后者偏实践。

这一维度的高阶标准不是：

我觉得这个模型更好用。

而是：

我能用真实任务数据证明它哪里更好、哪里更差，以及是否值得进入我的工作流。

维度十：安全、可靠性与治理能力

Security, Reliability & Governance

这一项评估的是：

一个人是否理解 AI agent 和自动化工具在真实环境中的权限、数据、误操作和治理风险。

越高级的 AI 用户，越容易让 AI 接触更多东西：

• 代码仓库；

• 公司资料；

• 客户信息；

• 浏览器；

• 文件系统；

• API key；

• 自动化脚本；

• 部署环境；

• 数据库；

• 生产系统。

这时候，AI 不再只是聊天工具，而变成了能读写、执行、调用、修改、提交的半自动系统。

能力越强，风险越高。

专业用户至少要具备以下能力：

这里有一个很重要的判断：

不是所有事情都应该交给模型自觉遵守。

有些规则可以写进 prompt。

但有些规则必须通过系统强制保证，比如：

• 不允许删除某些目录；

• 不允许访问某些文件；

• 不允许执行危险命令；

• 不允许提交未经 review 的代码；

• 不允许读取密钥；

• 不允许自动触发生产环境部署。

这一维度的高阶标准不是：

我敢让 AI 自动执行更多事情。

而是：

我能在扩大 AI 自动化能力的同时，控制权限边界、失败损失和系统风险。

四、第二层：AI-Augmented Super Individual Benchmark

AI 加持下的超级个体表现

第一层评估的是能力结构，但能力结构还不等于真实表现。

一个人可能很懂模型、产品、工程、开源和 eval，但这些能力是否真的改变了他的工作方式？是否真的带来了产出跃迁？是否真的影响了团队？

这就需要第二层 benchmark。

第二层评估的是：

AI 是否已经把一个人变成了 AI 加持下的超级个体？

我认为，超级个体有四个结构性特征：

1. AI First 工作动线；

2. 能力边界的量级跃迁；

3. 主动边界探索；

4. 影响力溢出。

这四个特征缺一不可。

S1. AI First 工作动线

核心问题是：

AI 是否已经成为你工作的默认起点？

普通 AI 使用者的工作方式是：

我照常工作，遇到困难时问一下 AI。

超级个体的工作方式是：

我先让 AI 跑一版，然后在 AI 的产出上做判断、修正、重构和推进。

这两种方式看似差别不大，但实际上决定了 AI 杠杆能放大到什么程度。

如果 AI 只是补救工具，那么它只会在局部提效。

如果 AI 是默认起点，那么它会进入整个工作动线。

AI First 不等于盲目信任 AI。恰恰相反，它意味着：

• 先让 AI 生成初始方案；

• 人再做判断；

• 再让 AI 扩展；

• 人再筛选；

• 再让 AI 执行；

• 人再校验；

• 最后形成产出。

AI First 的关键不是“AI 做主”，而是“AI 先跑，人做判断”。

评估点包括：

• 是否在任务开始阶段就调用 AI；

• 是否用 AI 先生成资料、结构、方案、初稿、原型；

• 是否在 AI 产物上做二次判断；

• 是否把 AI 作为默认动线，而不是临时补救工具；

• 是否形成“AI first, human judgment second”的节奏。

S2. 能力边界的量级跃迁

核心问题是：

AI 是否让你的能力边界发生了量级变化？

这里有两个方向。

第一个方向是“量的跃迁”。

过去一个人一天只能完成一篇文章，现在能完成十篇初稿；过去一周才能整理完一份资料，现在一天完成；过去一个月才能做完一个原型，现在一个周末做完。

第二个方向是“域的跃迁”。

过去一个任务需要产品、设计、研发、运营、数据、内容多个角色接力，现在一个人借助 AI 可以把一件事从想法推进到初步交付。

这不是简单的“效率提升 30%”，而是能力边界的改变。

普通 AI 使用者是：

我写得更快了。

超级个体是：

我能做过去做不了的事情。

例如：

• 非技术人员可以做网页原型；

• 内容人员可以做数据分析；

• 产品人员可以写 demo；

• 设计人员可以快速做多风格方案；

• 项目管理人员可以自动整理会议、风险和进度；

• 一个人可以完成过去一个小团队才能完成的初步探索。

当然，这不意味着专业分工完全消失。高质量交付仍然需要专业能力。但 AI 会显著降低跨域探索的门槛。

评估点包括：

• 产出数量是否显著增加；

• 产出速度是否显著提升；

• 是否能承担过去做不了的任务；

• 是否能跨越多个角色边界；

• 是否能独立完成从想法到初步交付的闭环。

S3. 主动边界探索

核心问题是：

你是否主动寻找 AI 能力的边界，而不是等待组织安排？

超级个体往往有非常强的主动性。

他们不会等公司培训，也不会等领导布置。他们看到新工具、新模型、新产品、新开源项目，会主动试、主动跑、主动比较、主动迁移到自己的工作中。

他们的行为模式是：

• 看到新模型，先找任务测；

• 看到新工具，先跑一个真实需求；

• 看到新开源项目，先复现；

• 看到新工作流，先试着改造自己的流程；

• 看到别人用 AI 做出高质量作品，会反推工具链和方法。

这就是边界探索。

评估点包括：

• 是否主动试用新模型、新产品、新工具；

• 是否主动把 AI 嵌入工作任务；

• 是否主动构造测试需求；

• 是否主动跨越自己的专业边界；

• 是否主动总结经验并形成方法论。

超级个体不是被动接受 AI 工具的人，而是主动探索 AI 能力边界的人。

S4. 影响力溢出

核心问题是：

你的 AI 使用是否只让你自己变快，还是让身边的人和团队也变快？

这是区分“高效个体”和“超级个体”的关键阈值。

高效个体是：

自己效率很高，但组织没有变化。

超级个体是：

自己的 AI 使用方式会被同事模仿，被团队采纳，被流程吸收，最终改变组织的工作方式。

影响力溢出可以有很多形式：

• 你把一个 AI 工作流演示给同事；

• 你沉淀了一个团队可用的 prompt 模板；

• 你整理了一份 AI 工具使用 SOP；

• 你帮助同事用 AI 完成具体任务；

• 你推动团队建立 AI 资料库、模板库、案例库；

• 你让领导意识到某个流程可以被 AI 改造；

• 你让团队开始重新思考分工方式。

影响力溢出不一定来自职位权力。很多时候，它来自一个人的示范效应。

当一个同事看到你用 AI 一个晚上做出了他们过去一个月才能完成的初稿，当一个管理者发现团队里用 AI 最好的人不一定是技术背景最强的那个，变革的种子就已经播下了。

评估点包括：

• 是否向同事展示过 AI 工作流；

• 是否帮助别人上手 AI；

• 是否沉淀过可复用模板给团队；

• 是否把个人方法转成团队 SOP；

• 是否影响团队对 AI 的认知和使用方式。

AI 超级个体的临界点，不是自己产出翻倍，而是自己的 AI 使用方式开始外溢，成为团队的新标准。

五、第三层：AI Macro Sensemaking Benchmark

AI 宏观趋势理解力评估

一个人想成为真正 AI Native，不能只对自己的工具和工作流敏感，也要对宏观形势敏感。

因为 AI 不是一个普通效率工具。它正在影响：

• 模型公司竞争；

• 算力和能源格局；

• 大公司组织架构；

• 创业公司机会；

• 行业价值链；

• 劳动力市场；

• 职业能力结构；

• 国家竞争；

• 政策监管；

• 资本流向。

如果一个人只知道自己手里的工具，但不理解 AI 正在如何改变世界，那么他的判断会缺少系统性。

所以需要第三层 benchmark：

一个人是否具备 AI 时代的宏观系统感？

我把它拆成八个维度。

M1. 模型与算力格局理解

核心问题是：

你是否理解 AI 能力增长背后的模型、算力、数据和能源基础？

评估内容包括：

• 大模型能力如何演进；

• 算力、芯片、数据中心、能源为什么重要；

• 闭源模型和开源模型的竞争格局；

• 模型能力提升如何周期性打开应用机会；

• 推理成本下降对 AI 产品有什么影响；

• 多模态、长上下文、工具调用、agent 能力增强会改变哪些场景。

核心判断是：

不懂模型和算力格局，就很难理解 AI 产业变化的底层动力。

M2. 大公司 AI 战略理解

核心问题是：

你是否理解大公司为什么这样布局 AI？

大公司不是随机发布 AI 产品。它们的 AI 战略往往和原有业务强相关。

例如：

• 搜索公司会关注 AI 搜索和答案入口；

• 办公软件公司会关注 AI 办公和企业工作流；

• 云厂商会关注模型服务、算力、开发者平台；

• 内容平台会关注 AI 内容生产、分发和广告；

• 手机厂商会关注端侧 AI 和系统级入口；

• 芯片公司会关注算力基础设施；

• 电商公司会关注导购、客服、广告、供应链和商家工具。

评估内容包括：

• 是否理解 OpenAI、Google、Anthropic、Meta、Microsoft、Amazon、Apple、NVIDIA、字节、阿里、腾讯、百度等公司的 AI 战略差异；

• 是否理解大公司如何用 AI 重构搜索、办公、云、广告、内容、开发者生态；

• 是否理解大公司什么时候做平台，什么时候做应用，什么时候做基础设施；

• 是否能判断某个大公司产品是否可能改变行业默认工作流。

核心判断是：

AI 宏观敏感度不是只看新产品发布，而是理解大公司为什么这样布局。

M3. 产业结构变化理解

核心问题是：

你是否理解 AI 正在如何重排产业价值链？

AI 不只是提高单个岗位效率，它会改变行业结构。

评估内容包括：

• 哪些行业会先被 AI 改造；

• 哪些岗位会被增强、重组或替代；

• 哪些公司会因为 AI 获得新杠杆；

• 哪些中间环节会被压缩；

• 哪些传统服务会被软件化、自动化、agent 化；

• 哪些过去依赖人力堆叠的业务会被小团队重做；

• 哪些行业会出现新的垂直 AI agent。

核心判断是：

AI 不是单个工具升级，而是产业价值链重排。

M4. 组织结构变化理解

核心问题是：

你是否理解 AI 会如何改变组织分工和管理方式？

AI 会让组织发生几个变化：

1. 小团队能做更多事；

2. 一个人能跨越更多角色；

3. 管理对象从人扩展到 agent；

4. 组织需要新的 AI workflow owner；

5. 团队需要 eval、数据、权限、安全、流程等新能力；

6. 中层管理者的价值会从“分配任务”转向“设计 AI 工作系统”。

评估内容包括：

• AI 会如何改变团队规模；

• 为什么小团队可以完成过去大团队的工作；

• 为什么管理对象会从人扩展到 agent；

• 为什么未来组织需要 AI workflow owner、eval owner、agent operator 等角色；

• 为什么中层管理者需要从任务分配者变成 AI 工作系统设计者。

核心判断是：

AI 改变的不只是个人效率，而是组织的分工结构和管理方式。

M5. 劳动力与职业变化理解

核心问题是：

你是否理解 AI 会如何改变职业竞争？

AI 对职业的影响不是简单的“替代”或“不替代”。

更准确地说，它会改变不同人的杠杆率。

未来可能不是简单的“AI 替代人”，而是：

会用 AI 的人，带着 AI 工作系统，替代不会用 AI 的人的一部分工作方式。

评估内容包括：

• AI 对知识工作者的影响；

• 非技术人员如何通过 AI 跨越专业边界；

• 技术人员如何从写代码转向定义问题、设计系统和管理 agent；

• 哪些能力会升值，哪些能力会贬值；

• 为什么未来职业竞争可能变成“AI 杠杆率竞争”；

• 为什么沟通、判断、审美、问题定义、系统设计和组织影响力会更重要。

核心判断是：

未来不是简单的“AI 替代人”，而是“AI 改变不同人的能力边界”。

M6. 资本与商业模式理解

核心问题是：

你是否理解 AI 产品和 AI 公司背后的商业逻辑？

很多 AI 产品看起来很酷，但未必商业上成立。

评估内容包括：

• AI 投资为什么集中在模型、infra、应用、agent、垂直行业；

• 为什么很多 AI 应用收入高但毛利压力大；

• token 成本、推理成本、算力成本如何影响商业模式；

• 哪些 AI 产品有可能形成平台，哪些只是功能；

• AI 创业公司的增长、留存、付费和护城河问题；

• 为什么有些产品适合订阅，有些适合 API，有些适合企业服务，有些适合平台抽成。

核心判断是：

看懂 AI 产品，不能只看功能，还要看成本结构、分发路径和商业化闭环。

M7. 政策、治理与地缘竞争理解

核心问题是：

你是否理解 AI 不只是技术问题，也是治理问题和地缘竞争问题？

AI 发展涉及：

• 数据安全；

• 模型安全；

• 版权；

• 隐私；

• 就业冲击；

• 算力出口管制；

• 开源与闭源策略；

• 国家科技竞争；

• 企业合规；

• 内容治理。

评估内容包括：

• AI 监管、数据安全、模型安全、版权、隐私、就业冲击；

• 中美欧 AI 发展路径差异；

• 模型开源与闭源背后的政策和战略含义；

• AI 如何成为国家竞争、产业政策和科技治理的一部分。

核心判断是：

AI 不是纯技术浪潮，它同时是经济问题、治理问题和地缘竞争问题。

M8. 宏观到个人的转译能力

这是最关键的一维。

核心问题是：

你能不能把宏观趋势转化为自己的行动路线？

宏观理解如果不能转译到个人行动，就容易变成空谈。

真正有用的宏观敏感度，应该能回答：

• 哪些趋势会影响我的行业？

• 哪些能力我应该提前补？

• 哪些工具我应该试用？

• 哪些岗位会发生变化？

• 我所在组织应该如何引入 AI？

• 我个人应该如何调整学习方向？

• 我应该在哪些工作流里优先引入 AI？

• 我应该如何从个人提效走向团队影响？

核心判断是：

真正有用的宏观理解，不是知道很多趋势，而是能把趋势翻译成自己的行动路线。

六、不同岗位应该如何切入这套 Benchmark？

这套框架如果只用于自我评估，价值还不够。更重要的是，它可以帮助不同岗位的人找到适合自己的 AI Native 进阶路径。

不同岗位不应该从同一个维度开始。

设计人员、产品人员、项目管理人员、中层领导，他们的原有能力结构不同，工作场景不同，最适合切入的维度也不同。

1. 设计类人员如何切入？

设计类人员最适合从这几个维度开始：

1. D2 AI 产品洞察力；

2. D6 个人 AI 能力栈构建力；

3. D7 前沿雷达能力；

4. D9 Eval 运行能力；

5. S1 AI First 工作动线。

设计类人员的优势在于：

• 对视觉质量敏感；

• 对交互体验敏感；

• 对风格、审美、用户感知有判断；

• 能快速感知一个 AI 创作工具的好坏；

• 容易从作品质量反推工具链价值。

所以设计类人员不一定要先学复杂工程，而应该先建立：

AI 创作产品体验力 + 审美 eval 能力 + 个人创作工作流。

具体行动建议：

第一，横向体验创作类 AI 工具

可以围绕以下任务做横评：

• 生成海报；

• 生成 PPT；

• 生成网页视觉；

• 生成产品渲染图；

• 生成电商主图；

• 生成品牌 KV；

• 生成短视频分镜；

• 生成 3D 资产；

• 生成 UI 原型；

• 生成社媒内容模板。

每个任务都用几个工具做同题测试，然后比较：

• 输出质量；

• 可控性；

• 风格稳定性；

• 修改便利性；

• 商用可用性；

• 与现有工作流的衔接程度；

• 是否适合沉淀成模板。

第二，关注高质量 AI 创作者

设计人员要多观察那些真正用 AI 做出高质量作品的人，而不只是看工具介绍。

观察重点包括：

• 他们用了哪些工具；

• 工具之间如何衔接；

• 前期提示词如何写；

• 中间如何筛选；

• 后期如何修图；

• 如何控制风格一致性；

• 如何从 AI 随机生成中提取可用结果；

• 如何把 AI 输出变成商业可交付作品。

第三，建立自己的设计 AI 能力栈

例如：

• 风格提示词库；

• 品牌视觉参考库；

• 产品图处理流程；

• PPT 生成流程；

• 社媒图片模板；

• Midjourney / 即梦 / Runway / Kling / 可灵 / Figma AI 等工具组合；

• 常用审美检查清单；

• AI 输出后期处理 SOP。

第四，训练“审美 eval 能力”

设计人员使用 AI 的关键不是“让 AI 生成”，而是“知道哪些结果能用，哪些不能用”。

可以建立自己的评价维度：

• 构图；

• 色彩；

• 质感；

• 字体；

• 信息层级；

• 商业可用性；

• 品牌一致性；

• 视觉冲击力；

• 用户理解成本；

• 是否需要后期重做。

设计类人员的 AI Native 路径，不是先成为工程师，而是先成为：

能用 AI 放大审美判断、创作速度和视觉探索能力的人。

2. 产品类人员如何切入？

产品类人员最适合从这几个维度开始：

1. D2 AI 产品洞察力；

2. D4 Benchmark 方法论能力；

3. D8 战略判断与品味；

4. D9 Eval 运行能力；

5. M2 大公司 AI 战略理解；

6. M6 资本与商业模式理解。

产品人员的优势在于：

• 理解用户；

• 理解场景；

• 理解需求；

• 理解商业模式；

• 理解产品形态；

• 能判断一个 AI 功能是否真的嵌入工作流。

产品人员最应该训练的是：

AI 产品范式判断力 + 商业闭环判断力 + 用户工作流理解力。

具体行动建议：

第一，建立 AI 产品库

产品库不应该只是工具清单，而应该包含：

• 产品名称；

• 所属赛道；

• 目标用户；

• 核心场景；

• 交互形态；

• 使用路径；

• 付费模式；

• 留存机制；

• 成本结构；

• 竞品；

• 创始人背景；

• 融资情况；

• 代表性用户评价；

• 自己的体验结论。

第二，长期整理 AI 创业者访谈

尤其关注：

• 创始人为什么做这个产品；

• 过去经历如何影响现在产品；

• 他怎么看下一代 AI 产品；

• 他怎么看 agent、workflow、AI OS、vertical AI；

• 他怎么看商业化；

• 他怎么看用户留存；

• 他怎么看竞争对手；

• 他怎么看模型公司和应用公司的关系。

产品人员可以通过这些访谈判断：

• 哪些创始人真的理解用户；

• 哪些创始人只是理解技术；

• 哪些产品有深场景；

• 哪些产品只是套壳；

• 哪些方向可能长期成立。

第三，做同赛道横评

例如：

• AI 搜索产品横评；

• AI 写作产品横评；

• AI PPT 产品横评；

• AI 视频生成产品横评；

• AI 编程工具横评；

• AI 设计工具横评；

• AI 内容创作平台横评；

• AI agent 平台横评。

横评不能只比较功能，而要比较：

• 谁更快进入核心场景；

• 谁的 onboarding 更好；

• 谁的输出质量更稳定；

• 谁的修改链路更顺；

• 谁能嵌入工作流；

• 谁有更强留存；

• 谁有更清晰商业化路径。

第四，训练产品判断句

比如：

• 这是功能，不是产品；

• 这是工具，不是平台；

• 这是 demo，不是工作流；

• 这是效率提升，不是范式变化；

• 这是模型能力红利，不是产品护城河；

• 这是分发优势，不是体验优势；

• 这是短期热度，不是长期机会。

产品类人员的 AI Native 路径，是从“体验工具”升级到：

理解 AI 产品如何改变用户工作流、商业模式和产品范式。

3. 项目管理人员如何切入？

项目管理人员最适合从这几个维度开始：

1. D6 个人 AI 能力栈构建力；

2. D3 AI 工程化实践力；

3. D9 Eval 运行能力；

4. D10 安全、可靠性与治理能力；

5. S4 影响力溢出。

项目管理人员不一定要从模型原理切入，而应该从“AI 改造项目流程”切入。

项目管理工作中有大量适合 AI 介入的环节：

• 会议纪要；

• 任务拆解；

• 进度追踪；

• 风险识别；

• 跨部门沟通；

• 项目复盘；

• SOP 整理；

• 汇报材料；

• 问题清单；

• 决策备忘；

• 需求澄清；

• 资源协调。

具体行动建议：

第一，用 AI 做项目信息整理

例如：

• 把会议录音整理成纪要；

• 把聊天记录整理成任务清单；

• 把多方反馈整理成冲突点；

• 把项目资料整理成背景文档；

• 把项目进展整理成周报；

• 把风险点整理成预警清单。

第二，用 AI 做任务拆解和进度管理

可以让 AI 辅助：

• 拆里程碑；

• 拆任务；

• 定义负责人；

• 识别依赖关系；

• 生成甘特图草案；

• 生成检查清单；

• 提醒遗漏事项；

• 生成复盘结构。

第三，把项目管理流程模板化

项目管理人员最应该沉淀：

• 项目启动模板；

• 需求澄清模板；

• 会议纪要模板；

• 周报模板；

• 风险清单模板；

• 复盘模板；

• 跨部门沟通模板；

• 决策记录模板。

这些模板都可以变成 AI prompt 或 skill。

第四，推动团队使用 AI

项目管理人员的价值不只是自己提效，更是让团队协作更顺。

可以做：

• 给团队演示 AI 会议纪要流程；

• 给同事提供项目模板；

• 帮团队建立共享知识库；

• 用 AI 统一不同部门的信息口径；

• 推动项目复盘标准化；

• 建立 AI 辅助项目管理 SOP。

项目管理人员的 AI Native 路径，是从“个人助理型使用”升级到：

AI 项目协同能力 + 流程自动化能力 + 团队提效能力。

4. 中层领导如何切入？

中层领导最适合从这几个维度开始：

1. M3 产业结构变化理解；

2. M4 组织结构变化理解；

3. M5 劳动力与职业变化理解；

4. D8 战略判断与品味；

5. D10 安全、可靠性与治理能力；

6. S4 影响力溢出。

中层领导不一定要成为团队里最会写 prompt 的人，但必须成为：

AI 工作方式的组织设计者。

因为中层领导面对的问题不是单点提效，而是：

• 哪些工作流应该被 AI 改造？

• 哪些岗位需要重新定义？

• 哪些任务可以自动化？

• 哪些员工应该先培养？

• 哪些流程需要加安全边界？

• 如何把个体经验变成团队标准？

• 如何让 AI 不只是个人炫技，而是组织能力？

具体行动建议：

第一，识别团队中的高价值 AI 改造场景

不是所有工作都适合立即 AI 化。中层领导应该优先找：

• 高频重复；

• 信息整理量大；

• 文档产出多；

• 跨部门协作复杂；

• 标准化程度高；

• 人工耗时明显；

• 结果可检查；

• 风险可控的任务。

第二，找到团队里的 AI 先行者

很多组织里的 AI 变革，不一定从技术部门开始，而是从某个特别主动的人开始。

中层领导应该识别这些人：

• 谁主动试工具；

• 谁已经形成工作流；

• 谁愿意分享；

• 谁能带动别人；

• 谁能把个人经验整理成团队模板。

然后让他们成为内部 AI 种子用户。

第三，建立团队 AI 使用规范

包括：

• 哪些资料可以给 AI；

• 哪些资料不能给 AI；

• 哪些任务可以自动化；

• 哪些任务必须人工 review；

• 哪些输出需要标注 AI 辅助；

• 哪些操作必须留痕；

• 哪些流程需要审批；

• 出错后如何回滚。

第四，把个体提效变成组织能力

中层领导最重要的是把个人经验制度化。

例如：

• 建立团队 prompt 库；

• 建立项目 SOP；

• 建立 AI 工具清单；

• 建立案例库；

• 建立培训机制；

• 建立复盘机制；

• 建立安全边界；

• 建立 eval 标准。

中层领导的 AI Native 路径，是从“自己会用 AI”升级到：

设计团队 AI 工作系统，让组织整体获得 AI 杠杆。

七、这套 Benchmark 应该如何使用？

这套 Benchmark 可以有三个用途。

1. 自我校准

一个人可以定期用这套框架检查自己：

• 我现在强在哪些维度？

• 我弱在哪些维度？

• 我只是用 AI 多，还是已经系统化？

• 我是否真正形成了个人 AI 能力栈？

• 我是否有 eval 能力？

• 我是否具备安全治理意识？

• 我是否只关注工具，忽略了宏观变化？

• 我是否只让自己变快，没有影响团队？

它可以帮助人从“凭感觉进步”变成“按结构进步”。

2. 行动指导

这套框架也可以作为行动路线图。

例如：

如果你模型理解力低，就去建立模型选择矩阵。

如果你产品洞察力低，就去整理 AI 产品库和创始人访谈库。

如果你工程化实践低，就去学习 spec、TDD、Claude Code、Cursor、eval、harness。

如果你开源实践低，就每周跑通一个小项目。

如果你能力栈构建低，就开始沉淀 prompt、SOP、skill、自动化流程。

如果你宏观敏感度低，就定期整理 AI 对行业、组织、职业的影响。

3. 影响他人

这套框架还可以用来帮助身边的人进入 AI Native 状态。

因为很多人不是不愿意用 AI，而是不知道怎么开始。

如果直接告诉一个非技术人员“你要学 agent、eval、MCP、TDD”，他可能会被吓退。

但如果告诉设计人员：

你先从 AI 创作工具横评、审美 eval、作品工作流观察开始。

告诉产品人员：

你先从 AI 产品库、创始人访谈、同赛道横评开始。

告诉项目管理人员：

你先从会议纪要、任务拆解、风险清单、项目 SOP 开始。

告诉中层领导：

你先从团队 AI 场景识别、种子用户、流程规范和影响力扩散开始。

这样，每个人都有自己的入口。

这也是 benchmark 的真正价值：它不是一个分数工具，而是一个进阶地图。

八、真正的 AI Native 是什么？

最后，我想重新定义 AI Native。

AI Native 不是会用很多 AI 工具。

也不是会写 prompt。

也不是经常看 AI 新闻。

也不是一有新模型就试用。

这些都只是表层。

真正的 AI Native，是一种系统迁移能力。

它意味着一个人完成了三次迁移：

第一，从工具使用迁移到能力系统

不是零散使用工具，而是形成自己的 AI 能力栈。

第二，从个人提效迁移到工作流重构

不是让原来的工作快一点，而是重新设计任务、流程、协作和交付方式。

第三，从局部敏感迁移到系统理解

不是只看新产品、新模型、新 demo，而是理解 AI 对产业、组织、职业和世界格局的长期影响。

所以，这套 benchmark 最终要回答的不是：

你会不会用 AI？

而是：

你是否能持续把 AI 前沿变化转化为个人能力、工作系统、组织影响力和世界理解框架？

如果一个人能做到这一点，他才不是普通 AI 工具用户，也不只是 AI Power User，而是真正意义上的 AI Native Practitioner。

更进一步，如果他不仅自己变强，还能让团队变快，让组织改变，让身边的人开始进入 AI First 的工作方式，那么他就开始接近 AI 加持下的超级个体。

真正的 AI Native，不是工具使用者，而是 AI 能力的系统整合者。

真正的超级个体，也不是单纯高效的人，而是能够把 AI 变成个人杠杆、团队杠杆和组织杠杆的人。