引子

应该要从 3 月说起，多年之前认识的一个创业者问我说，有没有时间兼职做一下 AI 应用研发，我当时答应了下来。昨天为了写这篇文章，我去查证聊天记录，发现他早在 24 年 9 月就在问我有没有认识的 AI Agent 研发方向的朋友，当时回复了周边没有。事后看来，我对他的印象又刷新了。

摘要

本文会先描述 2025 我使用 AI 开发的几个典型阶段。最后会做一个总结以及关于 AI 时代我的一些思考。

Vibe Coding 的各个阶段

在时间顺序上交错并行前进的。

1. VSCode + cline + deepseek

初期，就靠这 3 件套来进行低成本的 AI 开发，给我最深的印象就是写完一个 Chrome 插件，发现用了几块钱。

关于这段时间的经验总结，可以参考这个回答：有什么办法在 deepseek 的两段对话间传递信息吗？

  • 合理分配拆分任务
  • 聚焦当前对话的任务
  • 减少任务大小
  • 合理拆分文件
  • 及时总结上下文

最让我难受的就是 64K 的上下文，往往引用一个复杂的 html 就导致占用了 38k 导致根本没法修改。后来我学会了，让他单独写 js 和 html 不要总是在一个文件里面。在每次修改前我会告诉他读取什么文件，写入什么文件。最后我再来验证。

2. 从 Prompt 到 Cursor Rules

同一时期，公司里面开通了 cursor 的试用账号，大概有一个月的体验期，感到很新奇，比上面的三件套用起来丝滑了一些。这段时间就是开始疯狂的用 AI 写代码，到了有一种无脑信任的地步。后来针对一些重复/常见的迁移任务，我们也总结了不少 mdc 文件。从一开始的临时 prompt，精调 Prompt 再到最后的 Cursor rules，mdc 文件。

这段时间的经验总结，是发在公司内网 wiki 的，大概是这样的。

  • 原来的代码质量会深刻影响 AI
  • 提供良好的模板代码
  • 修正原仓库中不规范的命名
  • 编写针对性的 cursor rules 文档
  • 提供良好的本地测试环境（便于 ai 自行 go test ./… 验证）
  • AI 写的代码仍需要手动测试 + 回归验证

原来的代码如果质量比较高，AI 模仿参考起来就很顺利，否则就是一团糟。给我影响最深的是，[]int64 字段，在原来的代码里面明明为 CaseID 导致 AI 望文生义，在 SQL 中使用了 = ? 来处理，导致了 bug。当时的模型能力不强，也缺乏引导 AI 查询定义的指令（后来补充了就很好了）。现在据说 claude code 将要用 LSP 来辅助了？

3. AI 时代的 Review 代码

AI 时代，几乎都是狂飙猛进的写代码，对代码质量，代码 Review 带来一些困难。Review 的成本越来越高，所有人都在疯狂生成代码，是之前的 100% 增量，恶性循环导致，几乎没有人再愿意深入去看另外一个人的代码了。

我还一度十分抗拒同事写出来的 AI 不知所谓的代码。如果在 AI 时代之前就没有建立过 代码 Review 机制的还好说，对于代码有轻度洁癖 + 愿意 Review 代码的人来说，不仅工作量变大了，连代码质量都变差了。

逐渐的，对我来说，只要没有明显漏洞，就不再纠结代码风格/函数抽象/小函数等等了，开始放弃并加入进去。😂，在我看来，AI 代码的第一责任人还是当事人自己。

ai review

关于 ai review，公司后来提供了 ai review 的机制，效果并不如意，时间长了，几乎没有人看它评论的内容，因为他是读取 git diff 来评估的，而且模型能力也不好。

我经常在本地自我评估，在完成需求代码后，执行 /check-diff-risk 让 cursor/claude 读取一遍 diff 并结合代码库的代码给出高、中、低三种风险的报告，这个效果不错，经常能够使用”高风险”发现一些问题。借助更好的模型和更充足的代码上下文。— 这种在最后 Cursor 提供了 Find Issue，当然我没用过，我现在的足够用了。

  • 提交代码前评估风险
  • AI 代码的第一责任人还是当事人自己

4. MCP

关于 mcp 我用过的好用的 mcp 有这些

  • jenkins mcp —— 自动修复 ci 时候使用
  • gitlab mcp —— 自动提交代码，查找项目，总结周报使用
  • context7 —— 新项目，新库，新知识参考最新文档使用
  • chrome-devtools-mcp —— 最好用的工具之一，可以让 AI 执行验证
  • sentry-api-mcp —— 读取 sentry 项目，查询堆栈
  • 一些公司内部的 —— 关联任务/需求，查询日志，服务状态等等
  • mcp-atlassian —— 读取查询搜索 wiki

不过现在的 mcp 大多时候用不到，只有指令里面指定的时候才需要用，所以往往开了很多 mcp 最后都关了。

我觉得目前这有一个痛点，最好根据会话/指令，来精准选择 mcp 的集合。

编写 mcp 需要注意的点：对数据的返回需要做好限制，比如 description 需要考虑做好截断。

最近有一个 mcp 和 cli 的对比讨论，我觉得比较有趣，以 gh 命令行为例，我们是不需要安装 github mcp 的，一切 github 的能力，都可以使用 gh 工具来完成，而且 AI 特别聪明，早就知道对应的用法和预期了。

而 mcp 是后来的，那么如果将来成熟/流行的 mcp 文档也被 ai 训练进去的话，是不是就直接用 cli 就好了呢？

5. Claude Command

在 kimi/deepseek/GLM 纷纷支持了 claude-code 的兼容协议之后，我在个人项目的开发上，几乎全用 claude code 了，vscode 也很少打开过了。

我制作了一系列 command 用来补充完善除了需求编码之外的开发流程。

  • /check-diff-risk —— 通过 diff 评估代码变更风险点并报告
  • /clean-code —— 结合已有代码风格，精简注释，抽取小函数
  • /commit-code —— git add 并提交代码，并创建 MR
  • /fix-ci —— 使用 jenkins mcp 查找当前分支对应的构建，并根据构建日志修复
  • /apply-mr-comments —— 读取分支对应的 MR 下面的评论，并评估评论应用修复

这几个 command 能大大提高我核心需求编码之外的效率，减少一些浏览器交互（比如打开构建，并人肉观察构建失败原因，然后输入给 cursor 修复），让 AI 自动化起来。

当然这里面整个流程，还是人在负责，也就是网上说的 Human in the loop，我变成了按按钮的那个人。

  • 提供 command 自动化流程

Gemini 也在用，而且很感谢谷歌，几个模型都一直没有花钱，Gemini 3 出来的时候有一个 waiting list 的表单，填了之后，目前 gemini 3 和 gemini 3-flash-preview 也仍然是免费的。

他几乎是我用过的里面最聪明的，疑难杂症都让他来帮忙搞定。对我来说的感觉就是一个高级智能体。我能拿它写出更中等的程序出来。

6. Spec-Driven Development

spec-kit 我在 kiro 发布的时候试用过，给我的感觉就是靠虚假的流程来保证一些安慰。人总是倾向于偷懒的，spec-kit 生成的文档，提问的问题，分解的 task，会导致用户花费很大精力在调整这些文档上面。

而且当时的 kiro 在执行失败的时候，会 mock/假装某部分通过了，给我一些不好的印象。我没有在其他地方再用过 spec-kit 了。

但是 SDD 就是一个好的思想，没有必要给自己套一层规范的壳子来加重负担。就像各种公司的复杂流程把一件简单事情变得复杂。更何况只有自己和 AI 交互。

我用 SDD 一般是这样的流程。

  • 先完整聊清楚项目/需求，将技术方案/页面设计/调用流程，聊清楚并保存到文档里面
  • 在每次开发的时候，让 AI 参考对应的文档进行迭代。

  • 对于不同的开发层次，需要让 AI 自我进行验证

    • 编译通过
    • 添加单测且通过
    • 读取数据库验证
    • chrome-devtools-mcp
    • 观察修复 CI

我认为 SDD 的文档 + 最后收尾的验证手段，才是确保 AI 好好工作的。其中文档一定要好好写好好休整，文档就是将来的源码，代码是编译后的。

AI 可验证的部分，可以看之前的回答：为何代理-Agent 的代码写得狗屁不通全是报错，AI 编程厂商还要自吹自擂完美完成任务？

不过我在 SDD 开发的时候，大多数时候分发任务的还依赖于人，也许将来可以尝试以下让更职能的 AI 来去分发任务。

7. 简单的 Agent 开发

我最喜欢的还是用 gemini + SDD 来写，使用 claude agent SDK 来制作。

对于开发者来说，只需要提供描述流程 SOP 的 system-prompt + 必要的工具封装即可，拿 claude agent sdk 胶水一下，就是一个很好用的 agent。

这部分更细节的参考：Anki 卡片 AI 生成器——我的 Claude Agent SDK 实践

  • 开发者友好，开发成本低
  • Gemini 高级智能体可以写 system-prompt

当然更深入的涉及记忆、多个工具、Agent 框架的，我还没做过，2026 涉及到再总结。

我的个人 Vibe Coding 总结

关于如何做好 Vibe Coding 的我的个人见解

  • 想明白说清楚自己要什么

    • prompt 是基础能力
    • prompt 避免互相有冲突
    • prompt 的自我迭代

  • 文档驱动开发（SDD）好用多用

    • 项目初始化文档
    • 各个层级都要有文档
    • 现在的文档就是将来的源代码
    • 把写代码的时间转移到文档上面来（复杂度没有消失只是转移）

  • 雇佣更聪明的人/扩展个人的能力边界

    • 使用 Gemini 10 分钟，比折腾 GLM 3 个小时划算
    • 多使用更专业细分领域的 AI
    • 减少关注细节代码

  • 给 AI 提供更多的信息

    • mcp / 日志 / 数据库

  • 强调可验证的手段，用最终效果交付

    • 编译通过/检查通过
    • 补充单元测试并验证通过
    • chrome-devtools-mcp 验证通过
    • 读取 sqlite 等数据库
    • 完好的本地测试环境

  • 基础代码质量依然很重要

    • 合理的架构拆分
    • 合理的命名
    • 可扩展的设计
    • 更成熟/良好的框架/更少技术债务的代码，AI 提效更快

  • 跟紧潮流保持学习

    • 安装开源的 agent/command/skills
    • 关注 X 上的新技术/新方案
    • 听听播客怎么说

我的一些思考/总结

两种模式：AI Coding 和 Vibe Coding

我看到有人将严肃的 AI 编程（专业程序员提效）和 Vibe coding（非专业程序员扩展边界/能力）做了区分。

我个人认为这两个不是泾渭分明的，现有的专业程序的提效，只是在过往的知识上，能更快做出判断评估 AI 生成的代码是否满足需求，但是实际上这两种方式，都只需要用最终可验证的交付来评估即可。

诚然，现有的 vibe coding 的评估者对相对不熟悉的部分生成的代码，是没有代码质量要求的。比如我是后端，在开发网站的时候，只要效果看起来一样，就根本不关系对应的 js/css 代码。

我觉得在未来，AI 足够聪明的时候，是没有人关注中间的代码产物的，两种路径的人都只会看最终效果。

更高的人员要求

工程师向产品方向进化，产品向开发方向进化。个人能力边界会在扩展，那我真的做好了吗？

我的审美的短板需要怎么练习呢？用更好的 AI 替代？

我的思考：个人可以利用 AI 来弥补/练习自己的短板，从模仿 AI 上面来学习新的知识。

AI 时代的人和人协作问题

人和人的沟通在变少，现在我几乎不依赖另外一个人 Review 代码，而是让 AI 来 Review，提交前自我评估。

现在我也很少跟人聊方案了，而是我和 AI 聊方案，聊完之后再写文档 + 代码，不会和同事深入沟通了。

同样的，我的同事也是如此。那么在团队层面，这种是好事吗？效率高了，但是会不会两个人的 AI 风格不一致？冲突了？

我的思考是：还是依赖文档，这种新时代的源代码，需要在协作过程中使用起来。能在 RFC 阶段沟通好的，就不要在 Review 代码时候来沟通了。

不论是之前还是之后，风格越一致的团队，人和人之间的沟通成本越低。即便 AI 让人的沟通在减少，那么必要团队开发规范，AI 流程规范一致，可能协作会更好一点。

代码黑盒化

代码逐渐黑盒化，特别是用 claude code 的时候，描述完需求，验证完结果，可能很难有机会再去仔细查看代码 diff，就连代码评估，也交给了 ai，对开发者逐渐变得不透明。

之前我能记住 xx 需求，在哪个目录下面的哪个文件，大概有什么函数名实现的这个逻辑，现在只能记得 AI 对话，当时我描述的 prompt 了。（记忆叠加了视觉信号）

我想，这对于产品来说，其实根本不是事情。对于开发者来说，拥抱变化，只要没有明显漏洞（让 AI 评估），可以逐渐放弃一些执念。毕竟调用库的时候，也很少去看库的实现，看的都是文档。对于新增的 AI 代码来说，看文档就足够了。

我需要一个 MCP 吗？

我觉得需要的时候，制作一个就行了。而且实现起来也不难。

现在 claude for chrome 也有了，可能很多内部网站类型的 api 也没有必要再封装为 mcp 了。

人和 AI 的协作，模仿人类社会

现阶段，我觉得用好 AI 可能还是要模仿人类社会的组织模式。比如做好一个 AI 的 leader

  • 向多个助理分派任务
  • 关注交付结果
  • 减少关注任务细节
  • 整合多个任务结果
  • 异步/多线程的能力

这里面我最喜欢讨论的，还是 async，会点外卖就是 async，async 就是说完指令去做下一个的事情。

我想未来会写一篇文章，async 应该是人的基础能力。

结语

目前对我来说，vibe coding 的体验还差比较大的一块儿，我还不习惯从 v0 / blot.new 上面创建初始化的项目。

我还没有用过 skills 这可以是后续注重加强的部分 🤔