推文

@kafkaup · 2026-10-16 06:29

最近特别多人在说一个词叫 AI native，但我发现这个词已经开始有了被滥用的趋势。什么产品都说自己是 AI native，什么样的工作方式也都会称自己为 AI native。 那么 AI native 到底是什么意思？它的 native 到底体现在哪里？ 其实可以先从 native 这个词本身来理解。native 最核心的意思就是原生在一个环境里。比如大家以前讲 cloud native，不是把一个软件搬到云上，而是从一开始这个系统就是根据云环境来设计的。所以 AI native 也是一样，它代表的是当 AI 已经成为默认的基础能力之后，你的产品、工作流，甚至你处理问题的方式都会发生一些根源性的变化。 最直观的变化就是遇到问题时的第一反应：会从“我怎么做”变成“这件事 AI 可以帮我怎么做，AI 可以承担哪些部分”。这听起来只是多用了一个 AI 工具，其实是背后整个思维方式在发生变化。 比如以前接到一个调研任务，你可能会自己搜资料、看网页、做笔记、做整理。但当你的工作方式越来越接近 AI native，你的脑子里首先出现的链路是： • 我的目标是什么？我需要得到什么样的结论？ • 哪些资料 AI 可以帮我检索？ • 哪些信息可以让 AI 进行批量的整理？ • 哪些判断必须由我自己做？ • 中间结果应该怎么保存，才能让下一步 AI 顺利接手？ • 最后我又怎么验证它有没有搞错？ 你会发现 AI 已经不是一个工具，它开始被默认镶嵌进整个 workflow 里。 所以在这里我自己会区分一下 AI first 和 AI native：AI first 更像是遇到问题先想一下能不能用 AI 工具；AI native 则更往前一步，你的整个工作方式已经默认 AI 会参与进来。 这时候一个很有意思的变化是，你会越来越在意信息是不是“AI 友好”。比如以前我们写东西考虑的是人的观感，人看起来舒不舒服；但现在你可能会开始习惯用 Markdown，因为标题、层级、列表都很清晰，人可以看，AI 也容易继续处理。再往后就是 JSON、Schema 这种结构化的数据，因为你开始要求信息不只是看得懂，还能稳定地传递给下一个系统消费。再往下是 API、CLI、MCP 这些接口，AI 就不只是理解信息，而是真正可以调用外部的能力去完成任务。 所以从某种角度而言，AI native 的重要特征就是人机协作的摩擦力会越来越低：自然语言负责表达意图，Markdown 负责共同阅读，结构化数据负责稳定传递，接口负责 AI 的真正执行。你会越来越习惯把自己的工作环境整理成一个 AI 可以理解、可以操作、可以接手的环境。 这也是为什么这两年大家越来越频繁地讲 context。以前我们用 chatbot，经常是复制一段资料进去，问一个问题，再把结果复制出来，每次工作都在人工搬 context。但如果你越来越 AI native，你会开始希望 AI 本身就在你的工作环境里。它需要知道你的项目文件夹里有什么，知道你做过的决定、团队规则、skill、memory、历史文档，甚至知道历史任务状态和当前任务进行到哪一步。所以后来大家一直在讲 context engineering，我觉得背后的需求其实很朴素，那就是怎么让 AI 不需要每次都重新认识我们的工作。 再继续往下，人的角色也会随之改变。未来人的工作会从“我自己执行”变成“我定义目标和约束，AI 执行一段，我验收或者纠偏，然后 AI 继续执行”。人的价值会集中在问题定义、判断、取舍和验收上。所以 evals、trace、version、fallback 还有 human review 这些东西，其实也都是 AI native 工作的一部分。如果 AI 自己执行了十步，但你完全不知道中间发生了什么，那这个 workflow 其实还不够成熟。 所以我现在理解的 AI native，大概是一种这样的状态：AI 默认成为参与者，所以我们开始重新设计自己处理问题的方式、信息组织方式、工作流、工具接口，还有验收机制。 到最后真正的变化，不再是你的 AI 工具使用时长或者是你的 token 消耗，而是你已经很少会把一件任务想成“我自己一个人怎么从头做到尾”。你会自然地想：这件事情怎么拆？人负责判断什么？AI 负责执行什么？我们之间的信息怎么传递？最后怎么进行验收？ 这种思维方式真正形成以后，才算真正开始进入 AI native 的工作状态。

曝光 355 · 评论 2 · 点赞 2 · 书签 1 · 曝光/时 157.6186191355063