从 Vibe Coding 到 Agentic Engineering

AI 时代，独立开发者的核心竞争力不再是写代码的速度，而是 意图表达的精度 和 工程判断的准确度。

本文基于对 Anthropic、Google、GitHub、OpenAI 等一线 AI 团队的官方工程实践，以及 Reddit/X 社区高认可度工作流的交叉调研，梳理出一套独立开发者能力模型。

核心理念：让 AI 最大限度地自驾驶，但人类必须精确驾驭方向 — 把 AI 当成能力的放大器，在每一次交互中既获得产出，也获得认知成长。

一个时代的结束

2025 年 2 月，Andrej Karpathy 提出 “Vibe Coding” — “fully give in to the vibes, embrace exponentials, and forget that the code even exists”。这个概念迅速走红，成为 AI 编程的代名词。

一年后的 2026 年 2 月 11 日，他在 X 上亲手为这个概念写下了讣告^[1]：

“Today (1 year later), programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny. The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software.”

他给出了新的命名：Agentic Engineering — “agentic” 因为 99% 的时间不再直接写代码，而是编排 Agent 并担任监督角色；“engineering” 强调这其中有技艺、科学和专业性。Reddit r/ExperiencedDevs 的一个高赞帖更直言不讳：“Vibe coding always carried a bit of a derogatory undertone. It implied you were vibes-only, prompting and praying”^[2]。

这一转变可以用一张表概括：

为什么需要一棵新的技能树？

传统程序员技能树沿着一条线性路径展开：学语法 → 刷题 → 做项目 → 精通框架。但 AI 编码助手的出现让这条路径的投入产出比大幅下降 — 语法细节、API 用法、样板代码这些”手速型”技能正在被 AI 接管。

Anthropic 的内部数据颇具说明性：Claude Code 约 90% 的代码是由 Claude Code 自身编写的^[3]。然而 Addy Osmani 指出，使用 LLM 编程 “difficult and unintuitive”，获得好的结果需要学习全新的模式^[4]。Simon Willison 则将与 AI 协作比作”一种非常奇怪的管理形式”^[5]。Medium 上一篇高热度文章^[14]将这个趋势一语道破：“The skill that mattered was never syntax. It was deciding what should exist. AI just exposed that truth.”

这意味着另一组能力变得前所未有地重要：

独立开发者技能树
│
├── 🧠 系统设计（决定天花板）
│   ├── 技术栈选型、模块拆分、数据流设计
│   └── 架构决策是 AI 无法替代的核心
│
├── 📦 产品思维（最稀缺 — AI 无法替代）
│   ├── MVP 边界感：便宜不等于该做
│   ├── 用户体验判断力
│   └── 在 AI 交互中积累认知
│
├── 🗣️ AI 协作能力（投入产出比最高）
│   ├── Context Engineering（上下文工程）
│   ├── Spec-Driven Development（规格驱动开发）
│   ├── Rules & Boundaries（规则与边界）
│   └── 分阶段验收
│
├── 🎯 AI 模型认知（驾驭能力差异）
│   ├── 知道不同模型的能力边界
│   ├── 按任务选模型而非忠于品牌
│   └── 用多模型交叉验证发现盲区
│
├── ✅ 验收能力（质量底线）
│   ├── Auto Gate 自动化验证门禁
│   ├── 人机协同调试
│   └── 功能验收判断
│
└── 📐 技术词汇量（催化剂）
    └── 精确术语让以上所有能力的表达效率倍增

接下来逐一展开。

一、🧠 系统设计 — 决定项目天花板

AI 能写代码，但不能替人做架构决策。Willison 总结得精准：几乎所有让一个人成为”高级工程师”的能力 — 系统设计、复杂性管理、知道什么该自动化 — 恰恰是在 AI 时代产出最佳结果的能力^[5]。Osmani 也观察到 “LLMs reward existing best practices” — 良好的 Spec、测试、Code Review 在 AI 介入后非但没有被淘汰，反而变得更有力量^[4]。

技术栈选型

对独立开发者而言，选型的第一原则不是”最好的”，而是”AI 生态支持最好的”，根据场景的不同选择也不同，以下是一个参考：

数据流思维

系统设计的核心不是画 UML 图，而是能回答一个简单的问题：“数据从哪来？经过什么处理？最终到哪去？”

Anthropic 在 Claude Code 中实践的模式是 Just-In-Time Context Retrieval^[6]：Agent 维护轻量级标识符（文件路径、查询、链接），在运行时按需加载数据到上下文中，而非预先加载所有内容。这模拟了人类认知 — 我们不会记忆整个图书馆，而是记住索引目录，需要时再翻开具体那本书。

通用数据流模式

输入（用户意图 / 外部事件）
    ↓
上下文检索（按需加载相关文件、数据、历史）
    ↓
处理/推理（LLM 分析 + 工具调用）
    ↓
结构化输出（Schema 校验 → 类型安全对象）
    ↓
呈现层（SSE 流式推送 / API 响应 / 文件写入）

Feature-First 架构（本文推荐）

在模块组织上，Feature-First 与 AI Agent 的上下文管理天然兼容 — 改一个功能只需聚焦一个目录。Anthropic Claude Code 支持子目录级 CLAUDE.md 按需加载^[13]，使得每个 Feature 目录可以携带独立的上下文规则。需要注意的是，这是一种合理选型而非行业唯一标准：

src/
├── features/            # 按业务功能组织
│   └── [feature]/
│       ├── SPEC.md      # 业务规则文档（唯一真相源）
│       ├── actions.ts   # 入口：验证输入、权限检查、调度
│       ├── services.ts  # 纯业务逻辑
│       ├── queries.ts   # 数据库查询封装
│       ├── schemas.ts   # 类型和校验规则
│       └── components/  # UI 组件
├── lib/                 # 基础设施（DB、AI、环境变量）
└── components/          # 共享 UI 组件

二、📦 产品思维 — AI 无法替代的判断力

什么是产品思维？

产品思维不是”会画原型”或”会写 PRD”。它的本质是一种判断力 — 在无限可能中做出正确取舍的能力。具体来说，它包含三个层次：

• 问题识别：知道用户真正需要什么（而不是他们说需要什么）
• 优先级判断：在能做的一百件事中挑出最该做的三件
• 体验直觉：不需要用户反馈就能感知”这里不对”

对独立开发者而言，产品思维比团队中的 PM 更重要 — 因为你就是那个 PM。

AI 时代，产品思维发生了什么变化？

过去的共识是”ideas are cheap, execution is everything”。AI 正在让这句话翻转^[18]。

2025 年，AI 工具让写代码的速度大幅提升；但正如 dev.to 上一篇高赞文章^[19]总结的 — “2025 was about speed. 2026 is about judgment.” 当每个人都能快速实现想法时，区分赢家和输家的不再是执行速度，而是做了什么、没做什么。

这带来了三个具体变化：

1. 执行力通胀。 AI 让”实现”变得前所未有地容易。Willison 将其称为 “Dunning-Kruger on steroids” — AI 可能让人 以为 自己做出了伟大的东西，直到它在真实用户面前崩塌^[5]。
2. 功能蔓延加剧。 实现成本趋近于零后，“顺手加上”的诱惑空前强大。每个”顺手加上”都在稀释产品焦点。
3. 反馈回路变短。 AI 让从想法到可用原型的时间从几天缩短到几小时，这意味着你可以更快地验证（或推翻）假设 — 前提是你知道验证什么。

三层产品思维

第一层：知道不做什么（MVP 边界感）

AI 让每个功能的实现成本都变低了，这产生的诱惑是”既然做起来很快，不如顺手加上”。但 便宜不等于该做。许多独立开发者的项目死于功能过多而非功能不足。

实用的判断标准：

• 如果这个功能消失了，用户会不会抱怨？（不会 → 推迟）
• 这个功能是在解决已知问题还是假想问题？（假想 → 砍掉）
• 加了之后维护成本是多少？（即使 AI 写代码免费，调试和维护也不免费）

第二层：用体感发现问题（用户直觉）

AI 不会主动说”这个体验不好”，因为它不理解什么叫”好”。以下判断只能来自亲手使用产品的人：

• “等 3 分钟才出结果” → 需要流式输出
• “大部分字段都是空的” → 数据源不足
• “每次页面切换都要重新登录” → session 管理有问题
• “字体加载失败” → 外网依赖在内网不可用

产品判断是人类对 AI 最不可替代的价值。

第三层：在 AI 交互中积累认知

Osmani 的一个观察让人意外：“rather than replacing my need to know things, AIs have actually exposed me to new languages, frameworks, and techniques I might not have tried on my own”^[4]。

每次追问”为什么用 SSE 而不是 WebSocket？”、“为什么选择并行不是串行？“，收获的不仅是答案，更是一套架构直觉。几十次交互下来，产品在成长，人也在成长。AI 不仅是生产力工具，也是学习加速器。

如何在 AI 时代增强产品思维？

产品思维不是天生的，可以通过刻意练习增强：

1. “自己用一天”法则。 每次发布新功能后，强迫自己像真实用户一样完整使用一遍 — 从打开页面到完成目标。过程中不打开控制台，不看代码，纯粹体验。大多数”显而易见”的体验问题只在这个过程中才会被发现。

2. 逆向解构竞品。 找一个你钦佩的产品，问三个问题：它做了什么？它 没做 什么？它用什么方式做到了”让人觉得简单”？“没做什么”往往比”做了什么”更能揭示产品思维。

3. 用 AI 做快速原型验证。 AI 让你可以在一个下午做出三个不同方向的原型，分别给用户看。过去这需要一周。这是 AI 对产品思维的最大赋能 — 不是替代判断，而是让判断有更多数据支撑。

4. 写”一句话卖点”。 每个功能上线前，试着用一句话向非技术人员解释”这个东西为什么值得用”。如果解释不出来，很可能是在解决一个不存在的问题。

5. 追问”如果免费也没人用呢？”。 这个问题能帮你区分”技术上有趣”和”用户真正需要”。很多独立开发者的项目在本质上是 side project 而非 product — 区别就在于是否有人在你没有推销的情况下主动来用。

三、🗣️ AI 协作能力 — 从写提示词到管理上下文

Context Engineering

Anthropic 在 2025 年 9 月提出了一个关键概念演进：Prompt Engineering → Context Engineering^[6]。

“Building with language models is becoming less about finding the right words and phrases for your prompts, and more about answering the broader question of ‘what configuration of context is most likely to generate our model’s desired behavior?’”

区别的本质在于：Prompt Engineering 关注的是一条提示词的措辞，Context Engineering 关注的是整个上下文状态的动态策展 — 包括 System Prompt、工具、MCP 连接、历史消息和外部数据在内的完整配置。

随之而来的是 Context Rot 问题：上下文窗口中 token 越多，模型回忆信息的准确度越低。Anthropic 给出了三种应对策略：Compaction（总结压缩历史）、结构化笔记（定期外部化关键信息）、Sub-Agent 架构（多个 Agent 各持干净上下文，主 Agent 协调全局）^[6]。

Spec-Driven Development

“先写规格后写代码”已经成为多个独立来源的高度共识：

• GitHub Spec Kit^[7] 提出 Specify → Plan → Tasks → Implement 四阶段工作流
• Google Conductor^[8] 用持久化 Markdown 管理 Spec 和 Plan，使其成为仓库的一部分而非聊天中的临时产物
• Osmani 将其比喻为 “waterfall in 15 minutes”^[4]
• Reddit r/ClaudeAI 高赞帖^[9] 的总结更简洁：“Turns out the secret is better specs.”

Rules：六大核心领域与三级边界

GitHub 对 2,500+ 个 agent 配置文件 的大规模分析^[10]发现，最有效的配置覆盖六大领域：Commands、Testing、Project Structure、Code Style、Git Workflow 和 Boundaries。其中 三级边界系统 是最核心的发现：

精确描述与分阶段验收

需求描述的精确度直接决定首次修复成功率。对比 “页面有 bug” 和 “表格展开后表头显示但没有数据行” — 后者能让 AI 直奔问题核心。格式是 What → Why → Expected。

而分阶段验收的核心原则是：不要一次性让 AI 生成大量代码。Osmani 引用的一位开发者的教训是，一口气生成的结果”像 10 个互相不沟通的开发者写的”^[4]。正确的节奏是：跑通最小结构 → 接入核心逻辑 → 修复边界情况 → 体验优化 → 部署上线，每一步确认后再进入下一步。

Claude Code 的辅助模式

Anthropic 官方 Best Practices^[13] 中有几个值得特别关注的模式：Skills（按需加载领域知识，避免 CLAUDE.md 臃肿）、Hooks（确定性自动动作，比建议性指令更可靠）、Checkpoint/Rewind（每个 Agent 动作创建检查点，可精确回滚）。

最有趣的是 Interview 模式 — 让 AI 先采访你再写 Spec：

“I want to build [brief description]. Interview me in detail. Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don’t ask obvious questions, dig into the hard parts I might not have considered.”

这比直接写 Spec 能覆盖更多你没想到的边界情况。

四、🎯 AI 模型认知 — 驾驭能力不一的 AI

为什么这很重要？

Pragmatic Engineer 指出：“Choosing the right model for the job is surprisingly challenging”^[15]。Osmani 在 Beyond Vibe Coding 中用整章讨论模型选择^[16]，并将 AI 的 70% 问题定义为：AI 能快速完成 70% 的模式化部分，但剩余 30% 需要人类判断 — 而不同模型的 70/30 分界线位置不同。

模型能力矩阵（截至 2026 年 2 月）

不同模型有不同的甜区，不要忠于一个品牌，要忠于任务：

按任务选模型的经验法则：

快速原型 / UI         → Gemini 3.0 Flash / Sonnet 4.6（速度优先）
复杂推理 / 深度 Debug  → Opus 4.6 / GPT-5.3（深度优先）
大型代码库分析         → Gemini 3.1 Pro（超长上下文）
批量迁移 / 重复任务    → 便宜模型 + 严格 Schema（成本优先）
代码审查              → 用与写代码不同的模型（视角差异）

探索 AI 能力边界

找到自己的思维盲区

人类的思维盲区往往比 AI 的能力局限更危险。三种实用方法：

1. “假设挑战”法 — 完成需求描述后追问 AI：“我的描述中有哪些隐含假设？哪些边界情况我没有提到？”
2. 多角色审视 — 让 AI 分别以”用户”、“运维工程师”、“安全审计员”的角色审视你的方案。
3. “如果 X 失败了”法 — 对系统中每个关键环节问：“如果这一步失败了会怎样？“

五、✅ 验收能力 — Auto Gate

Willison 将 AI 描述为 “over-confident and prone to mistakes”^[5]，Osmani 由此提出了一条个人原则：“Never commit code you can’t explain”^[4]。

更关键的是 AI Agent 的 “致命三角”：速度（比人类审查速度快）+ 非确定性（相同输入不同输出）+ 成本压力（诱导跳过验证）。验收机制必须同时应对这三者。

Auto Gate（自动验证门禁） 是多方共识的 #1 最佳实践 — Anthropic 官方 Best Practices 将 “Give Claude a way to verify its work” 排在所有建议的第一位^[13]。具体做法是在 Rules 中规定 AI 在完成每个功能后 必须主动运行 全套检查：

pnpm check                    # Lint + Format
pnpm typecheck                # TypeScript 类型检查
pnpm test                     # 运行单元测试
pnpm build                    # 确认构建通过

Osmani 描述的理想循环是：“AI writes code → automated tools catch issues → AI fixes them → repeat, with you overseeing the high-level direction”^[4]。Willison 从另一个角度验证了这一模式：拥有强大测试套件的项目能让 Agent “飞速”完成任务；没有测试，Agent 会”自信地假设一切正常”直到出问题^[5]。OpenAI 的 Codex 在架构层面也内置了类似机制^[11]。

要点是 中间检查 — 每完成一个独立功能单元就跑一次 Auto Gate，而不是全部做完再检查。错误在发生的那一刻就被发现，修复成本最低。失败超过 3 轮，自动升级为人工介入。

即便有 Auto Gate，人类仍然需要能看懂关键错误。一个实用的”30 秒法则”：找到 error 关键词，复制前后 5 行，花 30 秒猜是哪类问题（类型？网络？配置？空值？），然后带上方向判断交给 AI。人类给出方向，AI 给出方案 — 这就是 Karpathy 所说的 “acting as oversight” 的日常体现。

六、📐 技术词汇量 — 催化剂

说 “用 SSE 实现流式推送” 比说 “让数据一点一点传过来” 精确 10 倍。技术词汇量不是一项独立能力，而是让以上所有能力的沟通效率倍增的催化剂。

AI 核心概念：LLM / Context Engineering / Structured Output / Tool Calling / RAG / Agent / Sub-Agent / MCP / SSE / Token / Embedding / Context Rot / Compaction

基础设施概念：PostgreSQL / Redis / ORM / CDN / Edge Runtime / Serverless / Docker / CI/CD / MCP Server

不需要精通每一个概念，但需要 知道它们的存在 — 这样当 AI 提及或推荐时，你能判断它是否合理。

多 Agent 并行：前沿实践

2026 年的最新趋势是多个 Agent 同时工作：

Willison 将其描述为 “surprisingly effective, if mentally exhausting”^[5]。建议从 2-3 个 Agent 开始，确保任务真正独立。

总结

AI 时代独立开发者的核心竞争力不是写代码，而是六项能力的叠加： 知道怎么拆（系统设计）× 知道该不该做（产品思维）× 能让 AI 准确执行（协作能力）× 能驾驭不同的 AI（模型认知）× 能验证结果对不对（验收能力）× 能精确表达（技术词汇量）。

正如 Karpathy 所说，这不再是 Vibe Coding，而是 Agentic Engineering — 有技艺、有科学、有专业性的编排工作。

AI 不是替代品，是放大器。 放大的不只是产出，更是每一次交互中获得的认知增长。

参考资料

1. Andrej Karpathy, X post on Agentic Engineering, Feb 11, 2026; TheNewStack, Vibe coding is passé
2. Reddit r/accelerate, “I think we’ve quietly moved past vibe coding”
3. Anthropic, Best Practices for Claude Code — “Claude Code 约 90% 的代码由 Claude Code 自身编写”
4. Addy Osmani, My LLM coding workflow going into 2026
5. Simon Willison, Vibe Engineering
6. Anthropic Engineering, Effective context engineering for AI agents, Sep 2025
7. GitHub Blog, Spec-driven development with AI
8. Google Developers Blog, Conductor: Introducing context-driven development for Gemini CLI
9. Reddit r/ClaudeAI, Took me months to get consistent results from Claude Code
10. GitHub Blog, How to write a great agents.md — 2,500+ agent files analysis
11. OpenAI, Introducing the Codex App; Multi-agents
12. Addy Osmani, How to write a good spec for AI agents
13. Anthropic, Best Practices for Claude Code — Skills, Hooks, Checkpoints, Interview 模式
14. Neural Minimalist, 6 Skills That Matter More Than Coding in the AI Era, Jan 2026
15. Pragmatic Engineer, Vibe Coding as a software engineer, Jun 2025
16. Addy Osmani, Beyond Vibe Coding, O’Reilly 2025 — “The 70% Problem”; Model selection guide
17. Anthropic, Introducing Claude Opus 4.6 — Agentic 编码持续领先
18. Anul Agarwal, Why execution no longer matters in 2026, but ideas do!, Dec 2025
19. Rajon Dey, Developers: 2025 Was About Speed. 2026 Is About Judgment, Feb 2026