 这两年被人说得越来越玄，好像一句话丢过去，一个系统就自己长出来了。我一般要先纠正一下，我自己用的定义很朴素，Vibe Coding 就是基本不去接触、也不主动修改代码的编程方式。这句话的重点其实在后半截，不在“不写代码”，而在需求描述得足够清楚。所以效率高不高，基本不取决于你换了哪个工具。

最贵的浪费不是 AI 写错，是我们想到一点做一点。查看团队成员的 AI 编程对话日志时，我看到不少这样的现象：某个按钮加个校验，来一次对话；把某个控件位置调整一下，又来一次对话；增加一个字段，来一次对话；等字段加完了再实现字段功能，又得来一次对话。每一次 AI 执行就要花五到十分钟，执行完还得跑单元测试，这段等待时间里你也没法好好利用，只能干等着。

头一个习惯也简单，就是先把需求和业务想清楚，别在自己都没想明白之前，就贸然驱动 AI 开始写代码。否则你会和 AI 之间产生大量往复、来回迭代和修改，所有时间都耗费在反反复复的调整上。这里有个判断要立住，AI 可以辅助你梳理需求，但无法替你“想”需求，需求的主控权一定要牢牢把握在自己手里，这个顺序颠倒过来，后面全是返工。

需求探索这件事，最好也别靠一次对话撞出来，而是分阶段跑。我开源项目里那个“AI 需求探索”的提示词，就是按传统的面向对象分析设计和

思路，拆成八到九个阶段分步骤帮你探索。跑完之后，一个需求涉及的业务流程、场景、核心业务域、业务对象、业务规则、业务能力与行为，包括组织、权限、角色，基本都能梳理清楚，然后落成一份完整的软件需求规格说明书。

第二个习惯，驱动 AI 编程时先要一份完整的需求加设计方案，别一上来就写代码。我会要求 AI 先输出一份需求加设计方案的综合文档，里面既包含核心需求，也包含数据库设计、接口设计、组件划分、技术框架和开发语言选型。稍微复杂一点的内容，一定要分阶段、分步骤，先确认方案，再动手实现，这份方案越完整，后面静默开发才越跑得动。

方案确认无误之后，就可以启动静默式开发。你甚至可以在白天整理需求和方案，晚上把所有事情交给 AI，如果再加上常说的循环工程，AI 自己跑个三四个小时就能把全部代码输出出来。这是我们以前人与人团队协同的惯用模式，但在 AI 时代一定要改。过去人之所以要开发一步再想下一步，是因为人的认知能力有限，往往要把当前功能做出来才能想清楚后续怎么做。

往深一层说，开发者的核心产出也变了。有句话说得好，

，提示词就是新代码。再往下推，开发者未来要交付的可能不再是 .java 或者 .py 文件，而是结构化的 .md 文档。不管是需求规格、系统设计还是详细的功能规约，这些用 Markdown 精心写出来的文档正在成为新的源代码，因为 AI 理解和执行开发任务的基础，正是这些精确、无歧义的结构化指令。

AI 编程的第一步，多半就是拿 Markdown 结构化地写文档，可程序员天生不愿意写文档，总想到哪里写到哪里，这个习惯不适合快速转到 AI 编程上来。我自己做一个小系统，一开始也不生成代码，先建一个 DesignDoc 子目录写文档，至少包括总体系统介绍与技术架构选型、数据库和对象设计、UI 与界面规范约束，以及各个功能点设计，功能点可以拆成多个 md 文件分开放。

之所以要费这个劲做结构化，是因为提示词本身就是需求，它没被结构化、工程化地管理，不利于后面多轮迭代变更和优化。而且软件复杂性从来不会消失，只是位置前移。技术建模这些年越来越简单了，低代码、智能化、模型驱动都在解决技术实现这一端，可整体复杂性并没有解决，它从技术建模转到了业务建模。把现实世界抽象为一个业务模型，这件事仍然相当复杂，仍然是难以快速完成的。

往下再走一层，就到了我自己觉得最要紧的一个认知转变，AI 的关键不是提示词，而是上下文。上下文工程把上下文从单一提示扩展成包含七个维度的完整信息体系，系统指令、用户提示、对话历史、长期记忆、外部检索信息、可用工具和输出格式定义。它还有四个特点，系统性、动态性、精准性和格式敏感性，重视信息的呈现方式，简洁摘要优于原始数据堆砌。AI 代理的失败主要源于上下文失败，而不是模型缺陷。

上下文一长，分而治之就绕不开了。大项目要拆解为小项目、小组件，按架构里分而治之的思路来做。我自己在进 

 之前会前置一个复杂项目的分解过程，先把它拆成具体的组件或者微服务模块，再进入具体编码，目的就是降低 AI 整个的上下文负担和记忆能力压力。软件工程解决复杂性其实就两个思路，分而治之和流水线作业，其中分解这一块短期还不能完全交给 AI 去做。

有个动作特别实用，却常被忽略，及时让 AI 归纳总结。沟通几轮之后，主动让 AI 总结当前已经完成的工作和输出物，下次发起新对话时先让 AI 读这个总结文件，它就能快速了解项目整体概况，大大方便后续工作的衔接。哪怕前面的细节内容忘了，也不影响后面的推理和输出。很多人把 AI 越改越乱归罪于模型，其实多数是上下文长度和记忆能力的问题，这个动作能省掉大量重复解释。

对 To B 项目来说，原型这一步我不建议省。用 AI 或者原型工具先做一个完完整整、不挂数据库、可以做业务交付的原型，拿它去和用户快速沟通确认，能大幅减少后续的需求变更。原型里已经明确的内容，就不要再重复写进软件需求文档里。这里有个值得记的规律，原型和对象、行为、规则这些规约，最终都是要固化成 rules 加提示语模板，配到前端开发、后端开发和测试链条上去的。

刚启动一个项目时，别急着用那些复杂的工程化框架。它们会消耗大量 tokens，内置了很多治理、管控、质量安全方面的能力，导致跑一次非常耗时，生成的东西不一定是你需要的。当前常被拿来比较的两种规约驱动模式也各有脾气，Spec Coding 偏规格导向，讲究需求精确和可验证；

 偏流程导向，讲究开发完整和分阶段，选哪个往往看项目规模和团队人数。刚开始用轻量级框架就够，需求明确、方案明确即可。测试策略也要克制，功能变更时只针对当前变更测试即可，手工触发 AI 半天跑一次全量 E2E 就足够。

但也不能一转身就倒向另一头。AI 工程化不能走两个极端，一个是一句话 Vibe Coding，一个是强文档化、过重的文档化，反而丧失了 AI 的优势。我常用一个例子解释，一页纸的需求交给团队里的张三李四，做出来的功能基本差不多；交给外面能力没问题的人，做出来千差万别，你要让外人做出同样效果，需求文档可能要从一页变成五页十页。真正的最佳解，是需求就一页，AI 做出来和团队成员做的一样。

要做到这一点，靠的是把团队已有的规范标准、经验技能、约定俗成的规则全部融进去，也就是 Rule 定义和 CLAUDE.md 这类规约文件。往上再走一步，就是把团队共性经验打包成 Skill。我一直讲，Skill 可以简单理解为提示词工程加上下文工程加 MCP，再加代码片段、参考模板和最佳实践的一个组合。团队整体的开发能力和效率，也就落在把共性经验显性化、沉淀、输入给 AI 这件事上。

还有个小技巧，先抽象再泛化。我们原来写技术方案，习惯丢一个类似的方案让 AI 参考模仿，但输出的方案虽然像，有些关键点会丢掉。更好的做法是先丢给 AI 两到三个技术方案，让它先抽象出写方案的核心模式、要点、关键项和约束规则，形成一个写技术方案的元模型。这个元模型你审核补充之后，再拿它加上参考方案丢回去，输出的精度会明显提升，细节也不容易丢。

该泼的冷水也要泼。不懂计算机科学、连基本理工科思维都没有的人，想把 AI 编程用好基本是妄想。那些零基础一句话做项目的演示，场景多数是已知的、有标准解法的通用问题，问题足够标准、没什么变化，当然好解决。真到复杂需求里，要么你能写得出足够精确的提示语需求，要么你能完整读懂 AI 输出的代码。你自己玩玩小工具没有问题，但要拿它做企业生产系统，有几个人敢打包上线？

再往前一步，就是驾驭者工程。OpenAI 提出 

 这个词的时候，有人做了个很好的比喻，大模型是 CPU，提示词工程和上下文工程是内存，而 Harness 是操作系统。用马来做比方更直观，提示词工程是喊话模式，上下文工程是给路标和地图，驾驭者工程则是给马装上马鞍、套上缰绳、路旁修起围栏，防止它跑进别人的农田，也防止它碰上障碍就自己趴下。

驾驭者工程到底加了什么？我理解是三块。一块是架构约束与架构可控，不是只把约束写进 Rules 或者 CLAUDE.md，而是针对这些约束配上自动化检查的技能包或智能体，让它能自动校验。接着是反馈闭环，AI 写完程序自己运行、自己调试、自己修复，而且不只看功能，还要看安全、可靠、性能这些非功能性的东西。还有一块是全生命周期管理，把长周期记忆和会话管理从单个项目延展到组织级去。

还有个更难的关口，组织级。AI 编程要变成组织级的工程能力太难了，很多时候我们仍然是按传统岗位分工，对需求、设计、前端、后端各个角色分别做 AI 赋能，这种情况下想成倍提升效率基本不可能，就像一个老马车装了个 V8 引擎，跑着跑着只能散架。更好的方式是一个人从头到尾全链路拉通，其他配合的可能是 AI 智能体，也可能是真人，因为只要存在沟通交互，上下文就是不连贯的。

回到开头那个问题，这些习惯说穿了都不新鲜。想清楚，说清楚，需求的主控权先留在自己手里，该沉淀的规约和技能包沉淀下来，剩下的交给 AI 去跑，跑完了再回头看它哪里没做对。工具过两年大概率又要换一批，换来换去也就那么回事，这事真不用太操心。

Vibe Coding 这两年被人说得越来越玄，好像一句话丢过去，一个系统就自己长出来了。我一般要先纠正一下，我自己用的定义很朴素，Vibe Coding 就是基本不去接触、也不主动修改代码的编程方式。这句话的重点其实在后半截，不在“不写代码”，而在需求描述得足够清楚。所以效率高不高，基本不取决于你换了哪个工具。

AI编程和VibeCoding-有哪些高效的做法和习惯？

人工智能

职业发展

编程语言

VibeCoding高效核心在于清晰需求描述，而非工具选择。先明确业务需求，避免碎片化交互；用结构化Markdown文档驱动AI开发，分阶段验证方案；借助上下文工程、规约沉淀与团队技能包，实现静默式开发，提升整体交付效率。

提示词工程

上下文工程

软件工程

软件需求

单元测试

数据库

智能体

AI编程

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

AI编程和VibeCoding-有哪些高效的做法和习惯？

AI编程和VibeCoding-有哪些高效的做法和习惯？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐