最近在思考怎么衡量AI帮助开发工作提效了多少。

先说一个不太严谨但很直观的感受。以前用C++/Qt开发一个界面——功能、样式、操作逻辑都要完备，暂时不考虑数据接入——大概要花1到2天。现在有了AI，同样的事情我只需要半个小时：把界面需求、样式参考、数据接口、大致操作逻辑，甚至相关的参考代码片段一起丢给AI，它直接返回一整套h、cpp、ui文件。我编译验证一下，再跟AI来回修修补补几轮，就完事了。

算下来确实省了不少时间。但我想说的不是AI让工作效率飞升，而是怎么用AI才是务实的打开方式。

不是Vibe Coding，是结对编程

很多人看到"跟AI说几句话就出代码"，第一反应是这就是Vibe Coding——靠感觉写代码，不靠谱。

我的感受不太一样。如果一开始就让AI做整个模块的实现，那确实像Vibe，结果大概率要翻车。但我的做法是：先不让AI做整个模块，而是先做模块下的一件小事。这个时候看起来像Vibe，实际更像是和AI结对编程。

区别在哪？Vibe Coding是你把需求甩给AI，等着它给你一个完整的东西，出了问题你再救火。结对编程是你全程把控方向，AI负责具体落地，你在关键节点做验收和纠偏。

两种技术栈，两种打开方式

这里有个有意思的区别，我自己在不同场景下的用法完全不一样。

如果是从零开始做一个工具或产品，而且技术栈偏Web这种交互不那么重的，我会走完整的工程流程：先做设计（SDD），执行过程中拆分Plan、做TDD，中间穿插代码审查，前端甚至上端到端测试。代码具体怎么实现我不关心，我只关心用户操作是否对齐、数据处理从用户角度看是否正常。这种场景下，AI更像一个"执行者"，我是产品经理+架构师。

但如果是C++/Qt这类偏重交互实现的模块，我的做法就保守很多——在我原有的工作路径里，让AI来实现，但整个行动过程我全程把控。从需求拆解到接口定义，从模块边界到验收标准，都是我来定。AI负责把我的设计翻译成代码，我负责验证和纠偏。几个类似的模块都这么跑完之后，我才会去想怎么沉淀成SKILL或者Workflow，让下次再来同类需求时，讨论更少、AI漂移更少、效率更高。

为什么在熟悉的领域反而更保守？

说起来有点反直觉：我主要做C++/Qt开发，按理说在自己最熟悉的领域应该更大胆才对，但实际操作中反而偏保守。

不过仔细想想，这不是保守，是对能力边界的清醒认知。

在我非常熟悉的领域，我的验收经验、对内部框架的理解程度，比AI做所谓的"测试"要可靠得多。我知道哪里容易出坑、哪些边界条件必须覆盖、什么样的代码结构是符合项目规范的。AI写出来的东西，我扫一眼就知道靠不靠谱，改起来也快。这种情况下，让AI做执行、我做把控，效率是最高的。

反过来，如果是一个我不太熟的技术栈，我反而可能让AI更"自由发挥"——因为我自己也不知道最佳实践是什么，不如让AI先出一版，我再边学边调。

沉淀SKILL：从单次提效到可复用能力

AI开发最容易被忽略的一步，是沉淀。

很多人用AI写代码，写完就完了，下次遇到类似需求还是从头聊起，AI还是会犯同样的错，还是要来回拉扯好几轮。这其实是浪费。

我的做法是：当同类模块用AI完整闭环落地过几次之后，就把过程中积累的经验、踩过的坑、有效的提示方式、特定的代码规范，一起提炼成一个SKILL或者Workflow。下次再来同类需求，直接加载这个SKILL，AI一上来就跟我的能力对齐了——不用再反复解释项目背景、不用再纠正代码风格、不用再强调那些它总忘的边界条件。

这才是AI开发真正的复利所在。第一次用AI是省时间，第N次用AI是造能力。

别陷入工具主义的陷阱

聊到这里，必须补一个提醒：别把AI开发变成工具收藏癖。

我见过不少人，每天的主要工作不是写代码，而是折腾各种AI工具——这个模型试一下，那个插件装一下，新出的IDE插件赶紧体验，prompt技巧收藏了一大堆，真正落地的项目没几个。看起来很忙，实际上是在用"学习新工具"的快感，逃避"解决真问题"的困难。

这就是工具主义陷阱：把手段当成了目的。

怎么判断自己是不是陷进去了？有一个简单的标准：你最近一次用AI解决的真实业务问题是什么？它带来了可衡量的产出吗？如果答不上来，或者答案总是"还在试"，那大概率已经在工具主义的边缘了。

我的建议是，给自己定一条规则：每学一个新工具或新方法，必须绑定一个真实的业务场景落地。不用多，一个就行。落地之后，再判断这个工具值不值得继续投入、要不要沉淀成SKILL。没有真实场景绑定的工具学习，都是无效投入。

AI时代最稀缺的不是"会用多少工具"，而是知道该用什么工具解决什么问题。这个判断力，只能从真实项目里练出来，靠收藏工具练不出来。

最后说几句

用了这么久AI辅助开发，我最大的感受是：AI没有让软件工程的底层逻辑发生翻天覆地的变化，该做的设计、该拆的模块、该把的关，一样都少不了。变的是分工——开发者从"写代码的人"，变成了"拆需求、定方向、做验收的人"。

以前写代码是核心能力，以后架构能力、需求分析能力、任务拆分能力才是真正的护城河。这些能力，AI替不了你，反而会把它们的价值放得更大。

所以我的建议很简单：别纠结"AI会不会取代程序员"这种问题，也别沉迷于"一句话生成一个应用"的幻觉。找一个你熟悉的领域，从一个小模块开始，跟AI结对编程，跑通几个完整闭环，然后把经验沉淀下来。当然，也鼓励在不熟悉的领域先Vibe摸索——先用AI快速出一版原型，跑通基本流程，再在迭代中逐步对齐行业最佳实践。这才是AI开发真正务实的打开方式。

其它

原文在我的飞书知识库内：AI Coding的打开方式

我的AI积累笔记也包含了其它的学习知识、思考笔记、实践记录：Being的AI积累。