我的 AI 编程方法论

从「氛围编程」到「智能体工程」—— 一套在真实项目中打磨了半年的工作流。

2026 年 7 月 · 基于半年来与一个技术圈的朋友(v)对于 AI 编程工具深度协作讨论的实战总结

引言：为什么要写这篇文章

2026 年，AI 编程已经从「玩具」成长为「生产工具」。随着 Claude Code、Codex CLI、Cursor、CodeBuddy 等工具的成熟，越来越多的开发者让 AI 参与到日常编码中。但真正高效驾驭它们，需要的不仅是会用工具，更是一套成体系的方法论。

我在过去半年中密集地实践 AI 编程，从最初的工具选型试错，到搭建完整的工作流体系，再到提炼出可复制的方法论——这篇文章就是整个过程的系统记录。其中有我的亲身总结，也有对行业前沿实践（Addy Osmani 的 AI 编码工作流、Anthropic 的 Claude Code 最佳实践从「氛围编程」到「智能体工程」的范式转变）的消化和印证。

核心结论先放在这里：不要让大模型做决定。让它提出方案，但别让它去实施方案——先让它预测方案里的下一步，你来判断，然后再执行。

一、三个阶段的进化

我的 AI 编程实践经历了清晰的三个阶段。这不只是时间上的递进，更是技术判断力与 AI 如何找到最佳协作方式的探索。

第一阶段：选定工具（5 月）

面对OpenCode、Claude Code、Mimo Code 等眼花缭乱的选项，我的策略是：先定下来一个，用起来再说。 最终选择了 claude code 、 OpenCode。

第二阶段：搭建体系（6 月）

从单一工具扩展到多工具组合——OpenCode + Mimo + API 中转 + 9Router + MCP 生态。开始建立规则文件（CLAUDE.md）、可复用能力（Skill）、多模型路由（9Router）三层结构，形成第一个完整的工具箱。

第三阶段：方法论成熟（7 月）

提炼出「选路 → 验证 → 执行」三阶段模型，用 Git worktree 做安全网，通过 CLAUDE.md 固化工作流。到这个阶段，AI 已经不再是「助手」，而是项目工程流程中的一个可控环节。

二、核心模型：选路 → 验证 → 执行

这是我方法论中最关键的部分，也是在反复实践中沉淀下来的核心认知。

第一步：选路——但不执行

遇到复杂问题时，让 AI 分析问题并提出解决路径。但关键的一步是：不要让它直接走这条路。 先让它告诉我，它选的这条路的下一步打算做什么。我来判断这个方向对不对劲。

AI 能推测问题的根源，但根源对不对它不知道。如果它走入岔路而你又不理解，那就永远走不出来。

第二步：验证——给足判断依据

让 AI 提供判断依据和参考资料。我只需要提出关键词和方向，大模型帮我去找。很多时候 AI 找到的资料和它选的路径在它看来没有关联，但有经验的人能看出其中隐含的联系。大模型能解决我需要的判断依据，但它判断不了资料之间的真实关联——这个关联要我来做。

第三步：执行——用分支兜底

用 Git 分支做保险，让 AI 在独立分支上完整地走一遍。走到头我再综合判断结果。走错了？切回去，换个分支重新来。多试几条路，总能找到对的。

为什么这个模型有效？

数据印证： CodeRabbit 分析了 470 个真实 GitHub Pull Request，发现 AI 参与编写的代码 Bug 数量约为纯人类代码的 1.7 倍，安全漏洞高达 2.7 倍。AI 写得快，但需要比人类代码更严格的审查。这套模型本质上就是把审查前置——在代码写出来之前，先盯住它的方向。

我在工作中就深刻体会到了这一点。网上没有现成资料，AI 也处理不了「两个问题的根源究竟是否相似」——它能推测根源，但推测的对不对不知道。如果让它一条路走到黑，而你对底层不熟，那就永远走不出来。但如果你只让它帮你找资料、提供判断依据，你来决策，效率反而远高于「丢给它然后等结果」。

三、安全网：Git 不是选项，是基础设施

既然让 AI 在分支上「试错」，版本控制就是整个方法论的地基。这不是「建议」，是「必须」。

我的 Git 实践：

  • 项目从第一天就上 Git。 搞定系统架构时、加具体功能之前，就要有版本管理。不是等「稳定了」再补。
  • 用 worktree 隔离实验。 每个新功能、每个 AI 试探性的改动都独立在一个 worktree 中。方向不对，直接丢弃，不污染主线。
  • 在 CLAUDE.md 中固化提交规则。 比如「每完成一个小功能、通过一次测试，做一笔干净的提交」。让 AI 按规则执行，而不是「觉得差不多了」就提交。
  • 失败就回退，不纠结。 新功能分支开发失败了，git 一键恢复，不用手动补救，直接 resume 回主分支。

业界共识： Anthropic 官方建议「把 git commit 当作存档点，小步提交、频繁提交。大胆尝试 AI 建议的重构，一旦发现跑偏就回滚。」Addy Osmani 同样强调：「保持高频、小步的代码提交，避免一次性生成过多代码导致项目失控。」经典工程纪律在 AI 时代不仅没有过时，反而被进一步放大了价值。

四、让 AI 像团队成员：CLAUDE.md 与 Skill 体系

把 AI 当作一个对外的 API 来调用，是初学者最容易犯的错误。在我的实践中，AI 是一个需要「入职培训」的结对程序员。

4.1 CLAUDE.md —— 你和 AI 之间的契约

CLAUDE.md（或 AGENTS.md）是从「随意丢个 prompt」到「工程化协作」的分水岭。

我的 CLAUDE.md 结构：

板块 内容 示例
项目概述 一句话说清这是什么项目 「一个基于 FastAPI 的智能客服后端服务」
不可协商的规则 硬性约束，必须执行 「必须 git，必须测试，不确定先问」
语言与风格 Linter 覆盖不到的编码规范 「TypeScript strict mode，禁止 any」
操作注意事项 环境变量、特殊的 CI 陷阱 「DATABASE_URL 必须在 .env.local 中设置」
沟通风格 语言、语气、详细程度 「中文，简洁风格，tool call 前不要废话」
原则条款 没有具体规则适用时的默认选择 「遇到性能瓶颈优先考虑缓存而非算法优化」
提交流程 什么时候提交、怎么描述 「每个独立功能一个 commit，格式: feat(xxx): 描述」

2026 年行业共识： CLAUDE.md 应控制在 250 行内（超过会导致 Agent 略读而非精读）；每条规则必须可证伪（「写好代码」不可证伪，「所有异步函数必须有超时设置」可以）；捕捉决定而非行为（「用 TypeScript strict mode，因为 2024 年 Q3 被 any 级联拖垮过」比单纯说「用 strict mode」更有价值）。多工具项目应通过 symlink 在 Claude Code、Codex 等工具之间共享同一份规则文件。

4.2 Skill —— 可复用的能力模块

Skill 是把高频、重复的操作封装成可调用的模块。我写的第一个 Skill 是 base-env-setup——一个检查和安装基础设施的工具，可以用来给新手快速配好 AI 编程环境。

Skill 的三种用法：

  • 一次写好，到处复用。 fba Skill 辅助 FastAPI 开发，前端也有专用 Skill。
  • 让经验可复制。 你摸索出的最佳实践，写成 Skill 就能直接给别人用。
  • 组合成流水线。 后端 Skill 生成 OpenAPI 文档 → 给前端 Skill 做界面 → 测试 Skill 验证。打通全栈开发。

4.3 前后端分离的 AI 开发模式

这是我在解决实际项目问题中总结出来的工程化方法：

  1. 先用 Skill 辅助写后端（FastAPI），所有功能做成 OpenAPI 接口；
  2. 让 AI 自己跑测试，确保后端接口全绿；
  3. 把 OpenAPI 文档喂给 AI，让它写前端。

额外经验：遇 bug 不要用一个模型死磕。 DeepSeek Flash 搞不定的 403 问题，换成 Mimo 2.5 十几分钟就解决了。多个模型各有所长，组合使用才有最大收益。

五、工具箱：实事求是的选择

用了半年的主要工具，以下是我的真实评价：

工具 我选它的理由
OpenCode Go token供应商 定价透明、模型灵活
Claude Code 深度推理能力最强，复杂的架构决策用它
CodeBuddy 腾讯出品，资源占用好，不是「换个壳的 VSCode」
Zed 纯 Rust 写的小型编辑器，速度惊人、占用极低，完美替代 Notepad++
9Router 多 API 源聚合路由 + Token 压缩（RTK 引擎），不止是省钱
Mimo Code 内置记忆、不用装插件就能用

重点谈 9Router：省 Token 只是表象

9Router 的 RTK Token Saver 可以通过 AST 分析自动压缩工具输出（git diff、grep、文件树、日志等），实测节省 30-40% 的输入 Token。一个 47K token 的请求压缩到 28K，上下文完全不变。其官方提供的 Caveman Mode 甚至能在输出端再省 65%。

但省钱只是表面收益。真正重要的是：上下文越干净，AI 的注意力越聚焦。 通过 AST 精准剪掉上下文里的冗余信息，本质上是给 AI 的思考留出了更清晰的信号空间。

六、分层建议：不是所有人都适合同一种方式

我的「选路验证」模型之所以有效，是因为我有足够多的底层开发和部署经验来判断 AI 的路对不对。但对于经验没那么丰富的人，路径应该不同：

入门阶段：靠时间来解决。
让 AI 在分支上走完，走完了再判断对不对。走错就回退、换个方向再来。多试几条路。这个阶段最重要的是养成分支管理和版本回退的习惯，而不是追求「一次命中」。

进阶阶段：学着判断。
给 AI 讲解你的思路它能明白，但让它自己研究就很难——这是正常的，因为你缺的是「遇到过的场景足够多」。这个差距只能靠实践填平，没有捷径。

很多人可以依靠时间来解决选路问题。但是必须注意分支和版本管理，可以方便地回退到主分支。多走一些，总能找到对的那条。

七、从「氛围编程」到「智能体工程」

2025 年，Andrej Karpathy 提出的「氛围编程」（Vibe Coding）——描述需求、AI 生成代码、看着跑起来就接受——被评为 Collins 年度词汇。

但 2026 年，严肃的生产团队已经完成了理性回归。业界的共识是：用 AI 生成代码没问题，但接受不经审查的 AI 代码就是问题。

2026 年初，Karpathy 提出了新的概念：「智能体工程」（Agentic Engineering）——AI 智能体在结构化的人类监督下进行计划 → 执行 → 验证（PEV 循环）。这不是对氛围编程的否定，而是对它的工程化升级。

我自己的「选路 → 验证 → 执行」模型和 PEV 循环本质上一致，但更偏微观：

  • PEV 的「计划」 是宏观的、项目级的架构规划；
  • 我的「选路」 是微观的、针对具体技术问题的路径决策；
  • PEV 的「验证」 靠测试和 CI/CD 自动化门禁；
  • 我的「验证」 在自动化之上加了一层人的判断——AI 找到的资料和它选的路之间到底有没有真实的因果关联。

行业数据： Stripe 的 Minions 每周产出 1,000+ 个合并的 PR，TELUS 通过 13,000 个 AI 方案节省了 50 万 + 小时，乐天在 7 小时内 完成 1,250 万行代码库的 vLLM 迁移（准确率 99.9%）。这些案例不是靠随意丢 prompt 达到的——背后是严格的工程流程和多层质量门禁。

八、阅读源码：AI 时代反而更要读

很多人以为有了 AI 就不用读源码了。我的经验恰恰相反：正因为有了 AI，读懂源码的门槛降低了，而读懂源码带给你的判断力变得更加稀缺。

我读过 Dify 的完整源码来理解工作流引擎，读过 PicoClaw 来搞懂智能体的核心逻辑。PicoClaw 的代码很小很清晰，是理解智能体原理的最佳教材。

为什么要读源码？ 因为当你能从底层理解一个智能体是怎么运作的，你在和 AI 协作时就不会被它「带偏」——你能看穿它每一步背后的逻辑，更快判断它走的对不对。这正是「验证」环节的核心能力来源。

没有 AI 编程之前，想参与社区项目必须自己读懂代码、理清逻辑，搞 PR 全靠技术。现在让大模型去读就行了。但你还是需要有能力判断它有没有读懂、有没有遗漏关键细节。

九、十条原则

  1. AI 选路，我来裁决。 让 AI 提出路径但不要立刻执行，先让它预测下一步，你来判断对不对。

  2. AI 找资料，我来判断关联。 你给出关键词和方向，AI 去搜索。AI 发现不了的材料之间的深层关联，你来补上。

  3. Git 是安全网，不是选项。 任何项目从第一天就上 Git。worktree 隔离实验，commit 做存档点，方向不对果断回退。

  4. 写好规则文件，让 AI 像团队成员。 CLAUDE.md 是你和 AI 之间的契约。规则可证伪、可执行、可 review。

  5. 不要迷信一个模型。 Claude Code 做推理，DeepSeek 做高产实现。多模型组合，各取所长。

  6. Token 不是免费的，上下文干净更重要。 通过 AST 压缩控制上下文质量。信号越干净，AI 的输出越靠谱。

  7. 前后端分拆，Skill 助攻。 后端 FastAPI → OpenAPI 文档 → 前端 Skill。遇 bug 不硬磕，换模型、分步骤。

  8. 读源码，理解智能体底层。 Dify、PicoClaw、claude code——理解底层逻辑才能真正判断 AI 的路径。

  9. 经典工程纪律没有过时。 先设计再编码、写测试、用版本控制、守住标准——AI 时代反而更重要了。

  10. 持续迭代，永不定稿。 这套方法论本身也在不断进化。每次遇到新工具、新场景、新问题，就回来修正它。

写在最后

AI 编程不是「AI 替你写代码」，而是「你和 AI 一起写代码——你负责方向和判断，AI 负责执行和搜索」。这种模式的本质是一个放大器：它放大的是你已有的技术判断力和工程习惯，而不是代替它们。

正如谷歌工程负责人 Addy Osmani 所说：

「经典的软件工程纪律，不但没有过时，在 AI 时代反而更重要。」

AI 不会取代懂工程、会判断、有方法论的程序员。它取代的，是那些把代码当流水线、把技术当套路的执行者。

这篇文章不是终点。工具在进化，我的实践也在深入。如果你也在 AI 编程这条路上探索，欢迎一起讨论和完善这套方法。

本文基于 2026 年 7 月前的实际开发经验撰写

参考来源：Anthropic Claude Code Best Practices · NxCode Agentic Engineering · Addy Osmani AI Coding Workflow 2026 · 9Router Technical Docs · CLAUDE.md Best Practices 2026 · Deutsche Telekom “Beyond Vibe Coding”