2025 年某个普通的工作日，同一家公司里，同时发生了两件让我觉得需要认真记录的事。
第一件事发生在市场部。
一个实习生，刚来了三周，学的是新闻传播专业，从来没有写过一行代码。
她在做竞品分析，需要一个数据看板——把过去 30 天，公司在四个主要渠道的获客成本、转化率、用户留存，和三个主要竞品的公开数据放在一起，做成一个可以每周自动更新的对比视图。
以前，这件事的流程是：她写需求文档，提给数据团队，数据团队排期，平均等两到三周，拿到一个她看不懂结构、也没办法自己修改的 dashboard。
这次，她用自然语言描述了她的需求，用 AI 辅助写了数据获取的逻辑，三个小时后，她有了一个可用的看板。
不完美，但在用，而且她能自己改。
第二件事发生在技术部。
一个工作了八年的后端工程师，负责公司的供应链系统。
他接到了一个长期积压的任务：构建一套供应链异常监控和自动响应系统——能实时检测供应链里的异常信号（库存骤降、交货延误、价格异常），自动触发相应的响应流程（补货建议、供应商通知、采购审批流）。
以前，这个系统的复杂度，需要一个三人团队干三个月，而且因为资源不够，一直排不上。
这次，他一个人，用 Cursor 和 Agent 框架，五个工作日，构建了核心系统的第一个版本，覆盖了最关键的三类异常场景。
不是 demo，是接入了真实数据的生产版本。
两件事，同一周，同一家公司。
一个不会编程的人，做了以前需要工程师做的事。
一个工程师，做了以前需要一个团队做的事。
这不是矛盾，这不是例外，这不是这家公司特别厉害。
这是同一个力量，在同一时间，往两个方向推。
一个方向：把非技术人员能做的事情的下限，往上推。
另一个方向：把专业技术人员能做的事情的上限，往上推。
地板在升高。天花板在消失。
大多数人只看到了一半
这个"地板升高、天花板消失"的双向拉伸，在媒体报道和社交讨论里，被系统性地割裂了——
分成了两个独立的故事，分别讲给两拨不同的人听。
给大众讲的故事：地板在升高。
"AI 让人人都能写代码了！"
"不懂技术也能做数据分析了！"
"普通人的能力天花板在升高！"
这个故事是真的，但只讲了一半。
它让很多人产生了一个错误的推论："既然普通人也能用 AI 做技术工作，那技术人员是不是就不那么值钱了？"
给技术圈讲的故事：天花板在消失。
"Cursor 改变了工程师的工作方式！"
"一个人现在能干一个团队的活儿！"
"10x 工程师变成 100x 工程师了！"
这个故事也是真的，但也只讲了一半。
它让技术人员产生了另一个错误推论："我只需要让自己变得更厉害，组织结构和其他人不需要变。"
两个片面的故事，产生了两个错误的推论，导致了两类错误的决策：
第一类错误：老板觉得"反正 AI 能做很多事了，技术团队可以缩减了"——然后砍掉了技术岗位，结果发现那些能驾驭 Agentic 工具的高手，比以前更稀缺、更值钱。
第二类错误：技术团队觉得"我只需要让自己变得更强，不需要帮非技术的同事"——然后业务团队被卡在低效的工作方式里，没有人帮他们升级地板，整体组织效率没有提升。
两类错误，都来自只看了故事的一半。
统一框架
Andrej Karpathy 对这个双向拉伸，有一个精确得让人松一口气的概括：
"Vibe coding 抬高了非工程师的下限。Agentic engineering 把专业人士的天花板推到了远超旧的 10x 基准。"
一句话，把两个被媒体割裂开来的故事，统一成了同一个框架。
拆解这两个概念：
Vibe Coding：
字面意义上，是"用感觉（vibe）来编程"——不写正式代码，用自然语言描述你想要什么，让 AI 生成代码，你审核结果，不断迭代，直到达到你要的效果。
它的核心价值，是降低技术准入门槛。
以前需要懂 Python、会写 SQL、理解 API 调用逻辑才能做的事——现在只需要能清晰地描述"我想要什么"。
不会编程的产品经理，可以自己验证一个数据假设。
不会写代码的运营同学，可以自己搭一个简单的自动化流程。
不会用 SQL 的销售，可以自己查一张他需要的数据表。
这不是说他们变成了工程师。他们没有。但他们现在能做到一年前需要找工程师才能做的一部分事。
Agentic Engineering：
是指用 Agent 框架——LangGraph、CrewAI、AutoGen 等——把复杂的多步骤任务编排成自动化的 Agent 工作流，让一个工程师能够构建和管理以前需要整个团队才能完成的系统。
它的核心价值，是放大专业能力的杠杆。
一个懂得如何设计 Agent 工作流的工程师，可以构建：
- 以前需要三个工程师协作的数据管道
- 以前需要一个专职团队维护的监控系统
- 以前因为复杂度太高而无法立项的功能模块
这不是说工程师变成了神。但他们的单人产出，确实在接近以前整个团队的规模。
两个概念叠加，就是那个双向拉伸：
地板向右移——非技术人员能做的事情范围在扩大。
天花板向右移——专业人员的可能性上限在消失。
两端同时在膨胀，中间的组织，需要同时应对两端的变化。
对组织来说，这意味着两条平行赛道
如果你是一家企业的管理者，"地板升高、天花板消失"这个判断，对你意味着一个非常具体的组织策略：
你需要同时建设两条平行赛道，而不是只建一条。
赛道一：升地板
目标：让业务团队能自助解决 80% 的"需要技术支持"的需求，不再需要每次都找工程师排期。
这条赛道的核心，是给业务团队装备对的工具，同时建立必要的安全护栏，让他们能在不破坏系统的前提下，自主完成数据查询、简单自动化、文档生成类的工作。
典型工具：自然语言查询数据库的 AI 助手、低代码自动化平台、内部知识库 Agent。
典型护栏：只读权限（不能修改生产数据）、输出结果的人工确认机制、关键操作的审批流程。
管理重点：减少摩擦，确保安全，不要让复杂度把业务团队挡在门外。
赛道二：破天花板
目标：让技术团队用 Agentic 框架攻克以前"因为复杂度太高而放弃"的高价值项目，一个人做出一个团队的产出。
这条赛道的核心，是给技术团队足够的工具、时间和自主权，让他们去做那些现在因为有了 Agent 框架而变得可能的大项目。
典型工具：Cursor、LangGraph、AutoGen、Claude API、内部工具调用系统。
典型配置：减少不必要的流程审批，给更大的算力预算，允许更大的技术试验空间。
管理重点：创造空间，释放能量，不要用"每日站会"和"周报"把高手的节奏打碎。
这两条赛道，必须同时建，不能选一条。
只建赛道一而忽略赛道二：地板升高了，但天花板还在老位置。你失去了那些能做大事的高手应该做的大事。
只建赛道二而忽略赛道一：天花板消失了，但地板还在原位。业务团队被卡在低效的工作方式里，技术团队继续被低价值需求占用大量时间。
两条赛道互补，才是完整的策略。
把两条赛道混为一谈是最常见的错误
这里有两个我见过很多次的错误，值得单独说清楚。
错误一：用赛道一的工具给赛道二的人用。
场景：公司引进了一个低代码 AI 平台，希望"技术团队也用"，统一工具栈。
结果：资深工程师觉得这个工具的灵活性远远不够，无法构建他们想构建的系统，切换之后产出反而下降。
原因：低代码平台的设计目标是降低门槛，它的代价是牺牲灵活性。对于不需要灵活性的用户（业务团队），这个代价是可以接受的。对于需要灵活性的用户（技术团队），这个代价是致命的。
赛道一的工具，是为了让非专业人员能用，它的约束是设计特性，不是缺陷。把这种工具强推给专业人员，是在用约束限制那些本来能突破上限的人。
错误二：用赛道二的工具给赛道一的人用。
场景：公司希望业务团队"也学一点 LangChain"，这样他们就能自己做更复杂的 Agent 了。
结果：业务团队被复杂度挡住，学习曲线太陡，大多数人放弃，工具沦为摆设。
原因：LangGraph、AutoGen 这类 Agentic 框架，设计目标是给有工程背景的人用，它的前提是用户理解 Python、理解 API 调用、理解异步逻辑。对于有这个背景的人，这些工具是杠杆。对于没有这个背景的人，这些工具是门槛。
赛道二的工具，是为了让专业人员突破上限，它的复杂度是必要的代价。把这种工具推给非专业人员，是在用专业门槛把那些本来能升高地板的人挡在门外。
两个错误，方向相反，根源相同：
把两条赛道当成了一条，用同一套工具策略试图解决两个本质不同的问题。
六个月，两条赛道的建设路线
赛道一（升地板）：六个月路线图
第 1-2 个月：选场景，做试点
不要一开始就全面铺开。
选一个最高频、最有代表性的"业务团队需要找技术帮忙"的场景。
在大多数公司，这个场景是：数据查询（"帮我看一下这个月某个指标的数字"）。
选三到五个典型业务用户，让他们试用一个自然语言数据查询工具两周。
观察：他们能做到什么？卡在哪里？最常见的需求是什么？最常见的错误是什么？
第 3-4 个月：建护栏，定规范
基于试点的观察，建立安全护栏：
只读权限——业务用户能查数据，不能修改数据。
敏感数据过滤——某些字段（身份证号、银行卡号）不出现在查询结果里。
异常查询告警——超大量数据查询触发通知，防止误操作。
同时，制定使用规范：哪些场景可以自助，哪些仍然需要技术团队介入。
第 5-6 个月：扩覆盖，建社区
把试点场景的经验，复制到第二个、第三个场景。
建立内部"AI 自助工具"的使用社区，鼓励业务用户分享经验，互相帮助。
每个月做一次复盘：什么场景效果好？什么场景需要改进？什么新需求出现了？
赛道二（破天花板）：六个月路线图
第 1-2 个月：找"不可能项目"
问技术团队：有没有一个你们一直想做、但因为人力不够而排不上的高价值项目？
通常，这类项目有几个特点：技术上是可行的，但工作量太大；如果做成了，对业务的影响很显著；因为不是"紧急"，所以一直被优先级更高的事情挤掉。
选一个，作为 Agentic Engineering 的第一个突破点。
第 3-4 个月：给空间，给信任
把这个项目，交给一个合适的工程师，配备必要的工具和算力预算。
然后——放手。
不要用传统的项目管理节奏来管这个项目（每日站会、周报、里程碑检查）。
让工程师自主探索，两周汇报一次进展，不问"完成了多少"，问"学到了什么"。
第 5-6 个月：复盘，复制
第一个项目结束后，做一次深度复盘：
一个人 + Agent 框架，做到了什么？
和传统方式（一个团队）相比，时间差距多大？质量差距多大？
这个经验，能复制到哪些其他场景？
把这个复盘，作为向整个技术团队（乃至整个公司）展示"Agentic Engineering 的杠杆"的案例。
张力最大的组织
物理学里，弦的振动范围，取决于它的张力（Tension）。
张力，来自弦的两端被拉开的距离。
距离越大，张力越大，能量越高，振动的频率越丰富。
这就是为什么精心调音的钢琴，能发出那么多层次的声音——它的每根弦，都被拉到了恰好合适的张力。
组织也是一根弦。
两端是：地板（普通人的基础能力）和天花板（最优秀的人的能力上限）。
过去，大多数组织的地板和天花板，都在相对固定的位置。张力有限，能量有限。
现在，这两端同时在被往外推。
地板在升高：普通人因为有了 AI 工具，能做到更多。
天花板在消失：最优秀的人因为有了 Agentic Engineering，能做到以前无法想象的事情。
两端之间的距离在增大。张力在增大。能量在增大。
但这个过程不是自动发生的。
它需要有人主动去推。
地板不会自己升高，需要有人去把对的工具给到对的人，建立对的护栏，帮业务团队完成认知和工作方式的升级。
天花板不会自己消失，需要有人去识别对的项目，给对的人对的空间，让专业能力和 Agentic 工具碰撞出真实的价值。
最有能量的组织，不是人最多的组织，不是技术最强的组织，不是战略最聪明的组织。
是地板和天花板之间张力最大的组织。
每一个普通人都有 AI 加持的基础能力。
每一个最优秀的人都在做以前不可能完成的事情。
两端被拉开，弦绷紧，能量充沛。
你要做的，不是选一端。
你要把两端，同时往外推。
地板升高了。天花板消失了。
你的组织，就活在这根越绷越紧的弦上。
发表于 1 小时前
|
查看: 7|
回复: 0
