Karpathy最近重新提出'Agentic Engineering'，强调AI编程应更注重工程约束而非仅依赖AI生成代码。
--91likeyou---
如果你现在还把 AI 编程理解成“把需求丢给模型，然后等它吐出一个能跑的页面”，那我建议你先停一下。
因为它像把一个项目交给一个很会写代码、反应很快、但不一定知道业务后果的人。它能在十分钟里给你一个登录页，也能在你没看懂的地方埋下权限漏洞、状态错乱、数据丢失和后面三个月都还不完的技术债。
Karpathy 最近重新提出 “Agentic engineering” 这个说法，我更愿意把它理解成一个行业提醒：Vibe Coding 没有死在原型阶段，但它确实不再适合作为正式软件开发的主线。AI 编程真正要进入的，不是更会写 prompt 的阶段，而是更会管控 AI 产出的阶段。
这对中国移动互联网从业者尤其重要。因为我们最熟悉的工作方式就是快：快上线、快试错、快复盘、快改版。过去几年，低代码、无代码、AI 生成页面都在满足这种快。但到了今天，问题已经不是“AI 能不能帮我做出来”，而是“做出来之后，谁负责它能不能长期跑下去”。
一、Vibe Coding 到底是什么
Vibe Coding 这个词最早由 Andrej Karpathy 在 2025 年 2 月提出。Merriam-Webster 后来把它解释成一种带有 AI 辅助、但相对“careless”的写代码方式：你告诉 AI 想要什么，让它生成代码，自己不一定理解代码为什么能跑。Collins 也把 “vibe coding” 选为 2025 年年度词汇，说明它已经不只是开发者圈里的梗，而是变成了一个大众可理解的技术现象。
说白了，Vibe Coding 的核心不是“用 AI 写代码”。用 AI 写代码可以很严谨，也可以很专业。Vibe Coding 更接近另一件事：我先不管工程细节，不管架构，不管测试，不管可维护性，我只要把想法尽快变成一个能点、能看、能演示的东西。
这并不丢人。很多产品经理、运营、设计师第一次真正感受到 AI 编程的价值，就是从这里开始的。
比如你想验证一个活动页的转化链路，过去要写需求、排期、等前端，现在你可以让 AI 先搭一个页面；你想做一个内部数据小工具，过去要找研发插空，现在你可以先做出一个粗糙版本；你想把一个脑子里的想法讲给老板或客户看，AI 能让你少在 PPT 里打转，多一点实物感。
Vibe Coding 抬高了很多非技术人的起点。这个判断我不想否认。
但问题也在这里：它让很多人误以为“能跑”就等于“能用”，“能演示”就等于“能上线”，“AI 生成”就等于“少了工程成本”。
其实不是。
二、为什么说 Vibe Coding 的主舞台正在退场
我能核到的公开材料里，Karpathy 在 2026 年 2 月的一周年回顾中表达得很清楚：一年前，LLM 能力还比较低，Vibe Coding 主要适合好玩的、一次性的项目、Demo 和探索；一年后，专业开发正在越来越多地通过 LLM agents 完成，但需要更多监督和审查。他给这个新阶段起了一个自己更喜欢的名字：agentic engineering。
注意，这里有一个很关键的变化。
过去的 Vibe Coding 是“我和 AI 聊，AI 给我代码”。新的 Agentic Engineering 是“我定义目标、边界、环境、验收标准，然后让一个或多个 AI Agent 在这些约束里工作，并把它的结果拿回来审查”。
这不是换了一个更高级的英文词，而是角色关系变了。
在 Vibe Coding 里，人很容易变成许愿的人。你说“帮我做一个会员中心”，AI 就开始写。你说“这里报错了”，AI 就继续修。你不看 diff，不跑测试，不追问为什么，只要页面亮了，就觉得差不多。
在 Agentic Engineering 里，人不能这么偷懒。你要像一个产品负责人和工程负责人一样，先把事情讲清楚：这个功能服务谁？入口在哪里？异常状态怎么处理？哪些数据不能碰？生成的代码必须通过哪些测试？上线之前谁来验收？
这背后的真正分水岭，不是 AI 从不会写代码变成会写代码。
而是 AI 写代码已经快到一种程度，人类如果不补上工程约束，风险会被放大得更快。
OpenAI 在 2025 年发布 Codex 时，也没有把它包装成“你可以不用管代码”的工具。它强调的是云端软件工程 Agent，可以在独立环境里读代码、改文件、跑测试，并提供终端日志和测试输出作为可追溯证据，同时也明确说，用户仍然需要人工审查和验证 Agent 生成的代码。
Anthropic 的 Claude Code 也是同一个方向：它不是只补几行代码，而是能读代码库、改文件、运行命令、和开发工具连接，甚至支持项目级说明文件、MCP、skills、hooks 和多 Agent 协作。
GitHub Copilot coding agent 的设计也很像一个“会干活但必须被审查的实习队友”：你把 issue 指派给它，它在后台开环境、提交 draft PR、留下 session log，但进入 CI/CD 和生产之前仍然要人审。
行业头部工具的共同方向并不是“让你更随便地写代码”，而是“让 AI 进入现有研发流程，同时留下审查、测试、权限和回滚的抓手”。
这才是 Agentic Engineering。
三、AI 不是把研发变便宜，而是把需求错误变得更快
很多产品经理对 AI 编程的第一反应是兴奋：那是不是以后我可以绕过研发，自己做 MVP？
可以，但只能做一半。
如果你的目标是验证一个想法，Vibe Coding 很好用。比如做一个投票页、一个后台查询页、一个用户分群规则的可视化草稿，它能让你用更低成本拿到反馈。
但如果你的目标是进入真实业务，比如登录、支付、会员权益、优惠券核销、订单状态、客服工单、内容审核、风控策略，那就不能只靠“能跑”判断。
移动互联网产品最麻烦的地方，不是页面长什么样，而是状态和责任链。
一个按钮背后可能连着账户体系、积分体系、库存、支付回调、消息通知、埋点、风控、客服后台和财务对账。AI 当然可以写这些代码，但它不会天然知道你们公司过去三年踩过哪些坑，不会知道某个字段为什么不能改，不会知道某个老接口虽然难看但不能动。
如果产品经理只是把一句“做一个新人礼包功能”扔给 AI，AI 可能真的会做出来。
但它做出来的，可能是一个没有库存锁、没有幂等、没有补偿机制、没有灰度开关、没有异常提示的新人礼包。页面上看，它很完整。到了生产环境，它会把问题一个个还给你。
所以我的判断是：AI 编程不会让产品经理更远离工程，反而会逼产品经理更懂工程。
不是让你变成写代码的人，而是让你变成能定义边界、识别风险、判断验收证据的人。
四、从 Vibe Coding 到 Agentic Engineering的变化
1. 从“写 prompt”变成“写任务契约”
Prompt 是一句请求，任务契约是一份责任说明。
前者可能是：“帮我做一个积分商城页面。”
后者应该包括：用户入口、页面状态、接口字段、库存扣减规则、异常提示、埋点事件、权限边界、验收用例、不能修改的文件、需要跑的测试。
这两者的差别很大。一个是在求 AI 帮忙，一个是在给 Agent 分派可验证的工作。
2. 从“看结果”变成“看过程证据”
Vibe Coding 时代，很多人只看页面能不能打开。
Agentic Engineering 时代，你要看它改了哪些文件、为什么这么改、跑了哪些测试、哪些测试没跑、有没有 lint、有没有类型错误、有没有安全风险、有没有生成新的技术债。
这听起来麻烦，但正式项目本来就麻烦。AI 只是把写代码的速度提高了，没有把工程审查这件事取消。
3. 从“一个 AI 对话”变成“多个 Agent 分工”
一个复杂功能不应该丢给一个 Agent 一口吃完。
更合理的方式是拆任务：一个 Agent 做前端页面，一个 Agent 改接口，一个 Agent 补测试，一个 Agent 写迁移文档，一个 Agent 做代码审查或安全检查。人负责拆分、排序、合并和最终判断。
这和过去产品经理拆需求、研发拆模块很像，只是执行单元多了一类“AI 同事”。
4. 从“一次性生成”变成“可沉淀资产”
很多 Vibe Coding 的代码用完就扔。它适合探索，但不适合长期维护。
Agentic Engineering 更在意沉淀：项目说明文件、接口规范、测试用例、组件模板、常用 Agent 指令、代码审查清单、上线检查表。
这些东西看起来不性感，但它们会决定下一次 AI 做得更准，还是继续像第一次一样瞎摸。
5. 从“谁都会做一点”变成“谁会验收谁更值钱”
未来真正值钱的不是“我会让 AI 写代码”，因为这件事会越来越便宜。
更值钱的是：我知道什么任务适合交给 AI，什么任务必须人来控；我知道 AI 的结果错在哪里；我知道一个功能从 Demo 到上线要补哪些工程动作；我知道什么时候该停，而不是让 AI 一直改下去。
这对产品经理、技术负责人、设计负责人、运营负责人都成立。
五、 Agentic Engineering 只是一套更严格的用 AI 做事方法
我不太喜欢把这件事讲成“下一代范式革命”。这种话太大，也容易让人误以为只要换个工具，组织能力就自动升级。
更准确地说，Agentic Engineering 是把 AI 放进工程系统里，而不是把工程系统交给 AI。
这里有几条底线。
第一，需求必须可验收。不要只写“体验更顺滑”“页面更美观”“提升转化”。你要写用户从哪里来，看到什么，点了什么，系统返回什么，失败时怎么提示。
第二，权限必须被限制。Agent 不应该想改哪里就改哪里，尤其是支付、账户、风控、数据删除、权限配置这类区域。
第三，测试必须前置。不要等 AI 写完再想怎么测。你应该先把核心验收用例列出来，让 Agent 围绕这些用例工作。
第四，代码必须有人看。哪怕 AI 生成的是一个内部小工具，也要有人看关键逻辑。研究里已经反复出现一个现实：AI 代码可以功能正确，但安全并不一定正确。2025 年一篇安全基准研究里，某些 Agent 方案在功能正确率达到 61% 的情况下，安全通过率只有 10.5%。这个数字不一定能代表所有场景，但足够提醒我们：能跑和安全是两件事。
第五，AI 产物必须能回滚。你要知道这次改动影响了哪些模块，出了问题能不能快速撤回，数据有没有补救办法。
六、一套可执行方法
如果你明天就想用 Agentic Engineering 的方式工作，我建议从四步开始。
第一步：需求
不要写一句“帮我做某功能”。至少写清楚六件事：
用户是谁；他在什么入口触发；正常路径是什么；异常路径有哪些；涉及哪些数据；这次不做什么。
“不做什么”很重要。AI 最容易热心过头，把你没让它做的东西也做了。
第二步：约束
告诉 Agent 哪些文件不能动，哪些接口不能改，使用什么组件，遵守什么命名规则，必须跑哪些命令，输出时要给哪些证据。
如果团队已经有 README、接口文档、代码规范，就不要让它散落在聊天记录里，应该放进项目级说明文件，比如 AGENTS.md、CLAUDE.md 或团队自己的 Agent 工作手册。
第三步：验收
产品经理要写的不只是 PRD，还要写验收。
比如：“新用户首次进入看到 A 状态，老用户看到 B 状态；库存为 0 时按钮置灰；接口超时时保留原页面并提示重试；埋点事件包含 user_id、入口、按钮名称和结果；至少通过 5 条核心测试用例。”
这张卡的价值是把“我感觉差不多”变成“证据够不够”。
第四步：复盘
每次用 AI 做完一个任务，不要只看有没有上线。要记录三类东西：AI 哪些地方做得准，哪些地方反复错，哪些规则应该沉淀到下次。
比如某个项目里 Agent 老是忘记跑端到端测试，那就把这条写进项目说明。某个组件库经常被误用，就补一个示例。某个接口字段容易理解错，就把字段解释写清楚。
这就是资产沉淀。
七、哪些场景适合 Vibe Coding，哪些必须升级到 Agentic Engineering
我不会说 Vibe Coding 没用了。它仍然有价值。
适合 Vibe Coding 的场景包括：个人效率小工具、一次性数据清洗脚本、内部 Demo、设计原型、活动页草稿、低风险运营工具、用来沟通想法的可点击样品。
这些场景的共同点是：失败成本低，数据不敏感，生命周期短，出了问题可以重做。
但只要进入下面这些场景，就必须升级到 Agentic Engineering：
涉及真实用户数据；涉及支付和权益；涉及权限和风控；会进入生产环境；会被长期维护；会影响核心链路；会和多个系统联动；出了问题需要定位责任。
这条边界越早画清楚，团队越不容易被 AI 的速度误导。
八、这轮变化真正重构的岗位能力
未来一两年，移动互联网团队里会出现一种很明显的分层。
第一类人，只会把需求丢给 AI，拿到结果就转发给研发或老板。这类人短期看起来效率高，但很快会暴露问题：不会拆任务，不会验收，不知道风险在哪里。
第二类人，能用 AI 快速做原型，也知道原型不能直接上线。他们会把 AI 当作验证想法的工具，能节省很多沟通成本。
第三类人，会把 AI 纳入工作流。他们能写清楚需求契约，能拆 Agent 任务，能要求测试证据，能组织代码审查，能把踩过的坑沉淀成团队规则。
我更看好第三类。
这类人未必是最会写代码的人，但一定是最懂“从想法到上线中间到底要经过什么”的人。产品经理如果能走到这里，价值不会被 AI 吃掉，反而会被放大。
因为 AI 越强，越需要有人负责判断什么值得做、边界在哪里、结果能不能交付。
九、要训练会交付的团队才是重中之重
Karpathy 提出 agentic engineering，对我最大的提醒不是“Vibe Coding 已死”这几个字，而是另一件更现实的事：
AI 编程已经从玩具区走到了生产区。生产区有生产区的规矩。
在玩具区，你可以随便试，坏了就重来。在生产区，你要考虑用户、数据、权限、成本、稳定性、合规、维护和责任。
这也是为什么我认为，移动互联网从业者接下来不要只学 prompt。Prompt 当然要会，但它只是入口。更重要的是学会写清楚需求，学会拆任务，学会看结果证据，学会让研发流程容纳 AI，学会把每一次 AI 工作留下的经验变成下次更稳的规则。
信息来源与核验说明
题图来自Unsplash，基于CC0协议
🔥 热词：#kapital visvim · #kap官网 · #kavecom · #kapri styles · #kaspars vilcans · #kappe schiphol bv · #kappavince · #kavin spacey