研发团队AI转型的常见误区与正确坐标系

AI原生的逻辑原点是什么？

孙煜征博士 | Founder of Superlinear Academy | lizheng.ai

持续关注一线变化

长期追踪 AI coding、agentic workflow、context engineering、AI-native organization 的真实进展。

持续思考和写作

把工具现象放回技术、工程、组织和商业结构里反复推演，形成可迁移的判断框架。

持续教学和企业交流

在 Superlinear Academy、AI Builders 和企业培训中，观察不同团队真实落地时的误区、瓶颈和有效做法。

Course: maven.com/superlinear/aibuilders

AI 到底能干什么，不能干什么？

边界在哪里，责任在哪里。

为什么概念追了很多，却不一定好用？

prompt、agent、MCP、workflow，都像是答案的一部分。

怎么判断一个人的 AI 能力层次？

会工具、会写 prompt、会 harness engineering，够不够？

为什么个人效率提升，组织效率没有同步提升？

局部速度上来了，全局瓶颈还在。

为什么组织生产力提升了，也未必多赚钱？

代码更多，不等于业务机会更多。

“研发”这件事三年后还存在吗？

核心会从写代码，转向定义目标、组织上下文和验证结果。

当技术底层条件变了，技术、工程、组织、商业之间的关系要重新理解。

01 · AI 的本质

AI Native 到底改变了什么

自然语言成为人类调度算力的新界面。

02 · 技术的本质

AI 在技术上带来的是什么

加速、平权，和重新定价。

03 · 商业的本质

greatness cannot be planned

新增价值并不来自于更快的执行。

剖析清楚这三层，才能建立研发团队的正确坐标系。

误区 看起来合理 更深层问题

AI 用得越多越好 活跃率、token、工具数都上升 放进不合适的流程里，只会放大混乱

代码越快越好 PR 变多，demo 更快 代码要服务业务结果和长期可维护性

个人提效就是组织提效 每个人都感觉快了 上下游瓶颈、接口和评估没有重构

生产力提升必然赚钱 单位产出成本下降 能赚钱的需求发现仍然稀缺

学概念就是懂 AI RAG、harness、MCP 都会说 名词是动词的切片，但工作是连续的

延伸阅读 几篇背景文章，把这些问题展开得更细

AI 转型中的常见误区

AI Native 的成本结构变化

AI Native 组织如何重构

AI 时代的质量与评估

从名词到动词：回到真实工作流

Bill Gates 说，他一生见过两次让他觉得革命性的技术演示。

Bill Gates 的问题

第二次是 AI。第一次是什么？

为什么是它？

Source: Bill Gates, The Age of AI has begun

CLI 命令行

人要用机器能理解的命令表达意图。

GUI 图形界面

人通过固定按钮和菜单调度软件。

Natural Language

自然语言界面

人直接描述目标、上下文和约束，让 AI 调度算力、工具和文件。

关键变化发生在人和计算系统之间的接口层：自然语言开始成为调度算力的入口。

过去的软件

先猜共性需求，再做成固定产品

• 需求要被产品化
• 流程要被标准化
• 长尾场景经常不值得开发

AI Native 软件

围绕一次任务，临时生成工作能力

• 脚本、页面、分析、工具可以按需生成
• 软件更接近“任务的延伸”
• 长尾需求第一次变得经济

软件不再只是公司交付给用户的东西，也会变成用户为了完成工作临时生成的东西。

AI 降低的是“生产一个功能”的门槛，但抬高的是“让一个功能被别人采用”的门槛。

给自己用 意图变成功能

上下文、口径、风险和修复方式都在作者脑子里，跑起来就够了。

给别人用 功能变成托付

别人要理解、接入、验证、依赖，并知道出了问题谁负责。

重新定价 生成贬值，采用升值

当功能不再稀缺，稀缺的是上下文、信任、责任、集成和长期维护。

当“做出来”不再稀缺之后，真正值得被别人使用的，是一个更低成本的托付关系。

Source: Challen, AI 时代，给别人做东西反而更难了

传统软件交付固定成品；AI 原生软件交付让 AI 持续生成好软件的内核。

Core Kit

核心套件 不可替代的 API、数据、模型、协议和业务资产。

Guidance

引导知识 写给 AI 的规则、范式、陷阱、最佳实践和检索入口。

Leverage Tools

杠杆工具集

把繁琐易错的步骤变成确定性工具，提高生成成功率。

衡量标准也变了：表达范围、意图保真、生成效率。我们正在从构建软件，走向构建软件的潜力。

Source: Yan Wang 鸭哥, 超越 DRY：AI 原生软件工程的思考 · Further reading: Garry Tan, Thin Harness Fat Skills

01 · 加速

做东西更快了

写代码、查资料、生成文档、做 demo、修小问题，单位时间产出明显上升。

02 · 平权

技能边界被打穿

原来属于少数人的代码、设计、PPT、写作能力，开始变成更通用的生产能力。

03 · 重新定价

工程价值被重新分配

当代码变便宜，真正变贵的是问题定义、上下文、验证、维护和责任。

前两个变化容易看见；第三个变化，才是工程重构的核心。

代码生成成本

问题定义成本

验证和评估成本

维护和责任成本

过去很多工程原则，是在“代码贵、修改贵、工程师贵”的假设下形成的。

工程直觉 旧前提 AI 时代的新问法

复用 代码写出来很贵，所以尽量复用 哪些东西值得沉淀为 context、rules、eval，而不是只沉淀代码？

抽象 提前设计通用结构，避免未来返工 哪些抽象可以用生成和验证替代，哪些仍必须稳定？

Review 人检查代码质量 哪些问题前置给测试、静态检查、AI reviewer 和业务验收？

速度 开发慢是主要瓶颈 开发快以后，瓶颈是不是变成需求、验证、发布和业务学习？

Source: AI Native 的成本结构变化

AI Native 是先把事情的本质讲清楚，再在新的能力边界下，重新设计完成方式。

Step 1

这件事本质要完成什么？

明确要降低的摩擦、提升的质量、控制的风险。

Step 2

AI 改变了哪些约束？

生成、搜索、执行、验证、试错成本发生了什么变化。

Step 3

因此流程应该怎么重构？

人、AI、代码、工具、数据和评估如何重新分工。

名词 prompt / agent / MCP

名词会快速过时，也很容易变成“我接入了什么”。

动词 检索、判断、生成、验证

动词才对应真实工作流：人在做什么，AI 在接管哪一步。

目标 降摩擦、提质量、控风险

动词仍然要服务目标，否则只是把流程自动化得更快。

任务本质 这件事到底要完成什么

先看任务，再决定用不用 agent、workflow、MCP 或别的东西。

一个概念如果不能改变动词，不能服务目标，不能回到任务本质，它就还只是一个名词。

Source: 从名词到动词：回到真实工作流

差距 AI User AI Builder 的技术本质

产出能否直接用 靠 prompt 反复改，最后人来收尾 Document-First + Context Curation：AI 看不到的信息等于不存在

能否稳定提质 感觉不对就重试，很难定位原因 Evaluation Design + AI Debug：区分幻觉、上下文饱和、指令歧义和能力边界

能否完整委派 一句一句遥控 AI，人被绑在旁边 Agentic Loop + Skill Writing：执行、自检、诊断、修正、再检查

能否形成团队复利 经验散落在个人聊天记录里 Context Architecture + AGENTS.md / MEMORY.md：把经验变成系统记忆

能否成为思考伙伴 AI 只是让既有流程更快 高密度 context 带来判断涌现：价值判断、历史决策和原则边界被持续注入

Source: AI User 与 AI Builder 的 5 个差距

AI 提升的是个人执行速度；组织能不能变快，取决于结构是否跟着变。

瓶颈 01

激励错配 如果仍按时间和过程考核，AI 省下来的时间很难自然转化为组织产出。

瓶颈 02

组织摩擦 会议、审批、跨团队对齐，是为执行昂贵的时代设计的；执行变便宜后，它们会吞掉速度。

重构方向 端到端负责的小团队

用 3-5 人 Pod 对产品结果负责，按 trait 组队，而不是按岗位边界切流程。

数据也呈现同一个断层：DORA 2025 中 90% 受访者已在工作中使用 AI，超过 80% 认为个人生产力提升；但 METR 在一个真实研发实验里观察到，AI allowed 条件下经验开发者反而慢了 19%。

Sources: AI Native 的组织形态：当执行成本下降，组织必须重写; Google Cloud DORA 2025; METR 2025

同一个模型，拿到不同质量的 context，表现会像两个不同的系统。

01 · Context Org Chart

先看 context 散在哪里

哪些在文档、会议、IM、代码、项目系统、人脑里；谁负责产生和维护。

02 · Context Architecture

再设计流转和加载

工作记忆、项目记忆、组织记忆分层管理，让 AI 渐进式加载，不多不少。

03 · Context Toolchain

最后变成可运行资产

Git、知识库、MCP、AGENTS.md、MEMORY.md，把经验沉淀成可迁移基础设施。

真正的组织复利，不是每个人都学会一个 prompt，而是资深人员脑中的判断标准能被 AI 持续读取、执行和更新。

Source: 你团队的 AI 效果不好，问题不在模型，在 Context

因为企业最后赚的不是“代码”，而是被市场愿意付费的业务结果。

代码是供给侧能力

AI 让供给更便宜、更快。

需求是市场侧约束

能赚钱的问题不会因为代码变便宜而自动出现。

商业是匹配问题

真正难的是找到值得做、做得对、能分发、能收费的需求。

常见反应 等商业模式清楚了再学

这听起来稳健，但会错过形成手感、发现需求、积累判断的窗口。

更有效反应

先习惯新生产力，再高频探索需求

很多机会只有在你会使用新能力之后，才会被你看见。

Steve Jobs 在 Stanford 演讲里提醒：往前看时很难把点连起来，很多意义只能回头看才显现。

Source: Stanford Report · Steve Jobs 2005 Commencement address

《Why Greatness Cannot Be Planned》的提醒

在复杂创新里，直接优化远大目标经常会被目标误导；更有效的路径往往来自 stepping stones、novelty 和 open-ended exploration。

Kenneth O. Stanley & Joel Lehman, Why Greatness Cannot Be Planned: The Myth of the Objective

放到 AI 研发转型里

• 先在真实工作里持续试新的完成方式
• 用实际反馈校正机会判断
• 用低成本试错，撞到过去不可见的需求
• 把探索过程中的判断沉淀成组织资产

案例提示：Google、Instagram、微信；ChatGPT、Claude Code，等等。

松弛感是一种管理能力：给探索留出空间，同时保留反馈和边界。

真实问题 从业务和研发卡点出发

小步试错 先从小场景开始

明确验收 定义什么叫做有用

快速反馈 真实用户和真实流程

复盘失败 缺 context、eval 还是需求

沉淀资产 rules、workflow、案例库

组合扩散 从点状经验到团队能力

问题 短答案 结构解释

AI 能干什么 调度算力、工具、上下文，生成和执行任务 它是新的 interface，不是普通工具

人怎么转型 从执行者变成定义目标、组织上下文、验证结果的人 代码便宜后，判断变贵

人才怎么分层 从工具使用者到系统设计者 看他能否构建可验证、可复用、可治理的工作流

概念为什么不好用 因为缺少任务本质和验证闭环 方法必须服务 workflow redesign

为什么组织没提升 局部提效没有穿透全局瓶颈 组织效率来自流程重构

为什么没多赚钱 生产能力不是商业机会本身 赚钱来自需求发现和市场匹配

解决技术问题

要理解技术本质，以及技术改变了哪些成本结构。

解决个人绩效问题

要理解人的价值从执行速度，转向目标、判断、验证和责任。

解决组织绩效问题

要理解工程、流程、激励和商业结果之间的关系。

知识之上的知识，是看见知识背后的结构。

回到本质 这件事到底要完成什么

识别变化 AI 改变了哪些约束

重构流程 人和 AI 怎么重新分工

设计验证 怎么知道结果是对的

连接业务 是否创造真实价值

沉淀资产 下次能否复用

持续探索 从经验到飞轮

方法之上的方法，是用同一套结构不断生成新方法。

几个长期误解会在这套结构里被重新校准：技术要放回业务里看，代码要放回结果里看，提效要放回组织里看。

它能在技术、工程、组织和商业之间，建立一套稳定的判断坐标系。

这里持续沉淀真实文章、真实项目、真实失败和真实迭代。

AI 转型很难靠一次分享完成；更重要的是进入一个持续交流的环境，和真正动手做的人一起校准判断。

superlinear.academy