Vibe Coding 这个词第一次出现在我视野里还是两年前的一个深夜。当时我在折腾一个内部工具卡在一段正则和状态机的边界逻辑上索性把整段代码丢给 AI 助手让它“看着改”。结果它不光把正则改对了还顺手帮我重写了状态机的两个判断分支。那一刻我突然意识到编程这件事的入口可能正在从“手写每一行”变成“描述意图 让模型补全细节”。一年半过去我自己的开发方式已经彻底被这种工作流渗透今天想把这些体会完整地写下来包括它带来的效率、它埋下的坑以及它对我理解“编程”这件事本身的冲击。1. 先聊清楚Vibe Coding 到底改变了什么1.1 一年半前我的编程习惯在大规模使用 Vibe Coding 之前我的日常开发基本遵循一套固定流程先读需求文档再画数据流图然后建分支、写接口、调样式、跑测试最后手动修一修边界条件。这套流程本身没什么问题但它有一个很消耗心力的部分——大量“低认知密度”的代码填充。举个很典型的例子对接一个第三方支付网关。核心逻辑其实是签名算法和回调验签真正需要动脑的可能只有两三百行。但为了这两三百行你需要写配套的 HTTP 封装、参数校验、错误码映射、日志打印、配置读取、重试策略。这些代码不难甚至可以说枯燥但它们必须存在而且不能写错。我以前大概会花三分之一到一半的项目时间在处理这类“胶水代码”。Vibe Coding 进入我的工作流之后最直接的改变是这些胶水代码不再由我逐行手写而是变成了一种“对话式产出”。我描述接口契约描述边界条件描述我希望的错误处理方式AI 在几秒内生成一整段可运行的代码。我不再是一个逐字逐句的编码者更像是一个带方向感的审查者。这个转变带来的效率提升不是百分之五十而是倍数级的。1.2 从“写代码”到“描述意图”的转型刚开始用 Vibe Coding 的时候我犯过一个认知上的错误我以为它只是“缩进版的搜索引擎”需要什么都去问问完复制粘贴。后来发现这完全是浪费。真正的 Vibe Coding 工作流是把“描述清楚意图”当成第一生产力。什么叫做“描述清楚意图”我举一个自己迭代了很久的模板。现在我给 AI 下达一个编程任务时通常包含四个要素输入数据长什么样、输出目标是什么、业务规则有哪些、不允许触碰哪些边界。写清楚这四件事AI 给出的代码基本能用写不清楚它就会给你一堆看似完整、实则跑不通的“幻觉代码”。这个发现直接改变了我的工作方式。我现在写需求文档很大程度是在为 AI 准备上下文。我会把字段含义、枚举值、主键生成规则、并发要求全部写清楚不是因为文档要交给谁审而是因为 AI 需要这些信息来减少猜测。写文档的时间没有消失但从“为了交付而写”变成了“为了更少返工而写”本质上是同一个时间花在了更值的地方。1.3 我不再把它当成“自动补全 Plus”有几个很流行的说法说 Vibe Coding 就是高级版自动补全或者说是“会和你聊天的 Copilot”。说实话我刚开始也是这么定位的但用了半年之后我越来越觉得这个类比有误导性。自动补全的粒度是“下一个 token”它默认你已经有完整的设计只是手速跟不上脑速。Vibe Coding 的粒度是“一个功能单元”它要求你在对话中完成设计决策。你问它“帮我写一个带过期时间的 LRU 缓存”这不是补全这是一个微观的系统设计任务数据结构选型、并发策略、清理时机、边界行为。AI 会一次性给出整套实现而你需要判断这些设计决策是否符合业务场景。所以把 Vibe Coding 当自动补全用你会得到很多代码片段但质量很不稳定把它当一个“随时在线、水平还行、但偶尔会胡说八道的初级工程师”来用你的整个协作模式会不一样。你会习惯给它布置任务、验收结果、指出问题让它重新改。这个磨合过程很像带一个新人但它的学习速度比你带过的任何一个新人都快同时它犯错的随机性也更让人头疼。2. 核心工作流我这一年半怎么用 AI 写代码2.1 我的工具链与选型理由先亮一下我目前的 Vibe Coding 工具链这不是广告纯粹是我自己跑了一年半之后留下来的组合。我日常主力是 VS Code 加两个 AI 插件一个负责行内补全和单文件级重构一个负责跨文件的代码生成和对话式调试。另外我重度使用命令行下的 AI 代码审查工具在提交前跑一遍静态审查能拦下一部分明显的问题。项目文档和上下文管理我用 Markdown所有给 AI 看的“项目背景说明”都放在仓库的 docs/ai-context.md 里。有人会问为什么同时用两个插件不直接用一个全家桶原因是它们的擅长点不一样。行内补全适合改函数、写测试、补注释这些动作速度快不需要大段上下文对话式生成适合新建模块、重构接口、解释陌生代码它需要的是全局视角。我试过把两件事交给同一个工具效果不是不行而是在频繁切换对话历史时会变得迟钝。分开用各取所长效率反而更高。关于“vibe coding 工具”这个词我理解它不只是指 IDE 插件还包括那些帮助你管理 AI 上下文、版本回溯、提示词模板的工具。我在实践中发现最强的工具往往不是功能最多的而是能和你的现有 Git 工作流无缝兼容的。毕竟 Vibe Coding 的产出还是代码代码还是要走 Git工具再花哨版本管理混乱了一切都是零。2.2 高杠杆操作模式按任务而非按文件很多新手用 Vibe Coding还是带着旧习惯按文件维度和 AI 对话。“帮我改一下 userService.go”“帮我给 auth.go 加个接口”。这种用法不是不行但体验很割裂因为你的项目逻辑是横跨多个文件的AI 每次只看到一个文件它给出的修改往往会在别的文件里引发编译错误或接口不匹配。我这一年半最重要的一个心得是把对话粒度提高到“任务级”。我不再跟 AI 聊“这个文件怎么改”而是聊“这个用户注册流程需要支持手机号和邮箱两种方式帮我梳理改动点”。AI 会先列出它需要修改的文件清单再逐个改动最后告诉我哪些地方需要我手动确认。这样一来AI 的输出就不是零散的补丁而是一个内部自洽的小型变更。我可以直接把它提交为一个 commit出了问题回滚也方便。这种任务级的工作方式让 Vibe Coding 真正进入了我的主干开发流程而不是游离在边缘做辅助。2.3 关键词背后的提示词工程本地化实践聊 Vibe Coding 绕不开一个词提示词工程。但我要说别把提示词工程想得太玄乎。我在真实项目里总结下来好的提示词就三个标准具体、有约束、可验证。具体是指你的描述要包含真实业务名词而不是泛指“用户管理”这种模糊说法。我一直用真实项目里的字段名、类名、接口路径来写提示词AI 的幻觉率明显下降。有约束是指明确告诉 AI“不要做什么”比如“不要引入新的外部依赖”“不要改动数据库迁移脚本”“不要修改公共配置”。这些约束看起来是在限制 AI实际是在保护你的项目边界。可验证是指你提出了一个可测试的验收标准。比如“生成一个函数输入是订单号输出是订单状态和支付时间要求能通过单元测试”。AI 生成完之后你不需要肉眼一行行审查逻辑直接跑测试绿了就算过红了自己去迭代提示词。这套方法把“信任 AI”这个抽象问题变成了一个工程问题。2.4 关键节点我如何拆分大需求用 Vibe Coding 写一个小工具我闭着眼睛都能搞定。但遇到那种牵涉十几个模块、几十张表的大需求怎么用 AI 而不翻车这才是真正的考验。我的做法是“三层拆分”。第一层业务目标层我要做一个库存预警系统。这一层我只跟 AI 对齐概念让它帮我梳理核心实体、状态流转、关键规则产出设计文档。第二层模块拆分层我把库存预警拆成库存数据接入、预警规则配置、消息通知渠道、报表展示四个模块每个模块独立对话。第三层功能点层每个模块再拆成若干可独立验收的功能点一次对话只产出一个功能点。这个拆分看起来费力实际上省掉了大量返工。AI 在没有全局视野的时候一旦上下文不够就会自己脑补需求然后产出一些“看起来合理但根本没人要”的功能。按“业务目标 - 模块 - 功能点”三层拆解之后每一个对话的上下文都被控制在模型能稳定处理的范围内产出质量显著提升。我现在接大需求前期花在拆解上的时间反而比我以前手写代码时更多但它买回的是后期不用返工的确定性。3. 踩过的坑与避坑指南3.1 无限附加功能需求的熵增Vibe Coding 有个特别隐蔽的陷阱它太擅长加功能了。你跟它说“帮我加一个按钮”它会顺手帮你把按钮的样式、过渡动画、点击埋点、空状态提示全部生成了。单个看都合理但叠加在一起一个本来只需要两天的需求AI 能给你膨胀成五天的代码量。我一度被这种“富贵病”折磨。项目进度虽然在往前跑但代码仓库的膨胀速度比功能增长速度快得多。后来我给自己定了一条纪律每一次对话明确声明“这个需求的范围到此为止不要做超出我描述的扩展”。如果 AI 还是扩展了我就把多余部分删掉。这件事不能妥协因为 AI 扩展出来的代码你是要长期维护的它的每一行都在增加技术债。3.2 代码“看起来正确”但运行失败这是 Vibe Coding 最磨人的坑AI 生成的代码读起来逻辑自洽、注释清晰、命名得体但一跑起来就是各种报错。最典型的是三种情况用了并不存在的 API 方法、把异步当同步写、对边界条件的判断完全错误。我印象最深的一次是让 AI 写一段处理时间戳的函数。它给了我一个很漂亮的实现还用了一个我从来没见过的标准库函数。结果编译直接报错因为那个函数是它从训练数据里“缝合”出来的根本不存在于当前语言版本中。从那天起我给自己立了个规矩AI 代码必须跑关键路径测试不经过验证的代码一律视为“参考代码”绝对不允许直接合并进主干。跑不起来还不是最可怕的最怕的是它在某个隐蔽分支里用了错误逻辑让你在测试环境怎么跑都正常一上线就出事故。所以我现在有一道固定工序每次 AI 提交代码我会要求它同时给出三个测试用例覆盖正常路径、边界路径和异常路径。它写的实现可能是错的但测试用例要是也写不出来那说明它自己也还没想清楚这时候我就得重新拆解需求再喂一遍。3.3 上下文窗口的幻觉与依赖为什么 AI 有时会突然“失忆”把你前面跟它敲定的约定忘得一干二净这跟模型的上下文窗口限制有关。我踩过最深的一个坑是在一次长对话的第 30 轮AI 突然把一个数据结构改回了最初版本。我没有逐行 diff直接合并结果半个模块崩了。后来我学乖了不在同一个对话里长期作战而是把确定性的约束写进项目文档。每当我跟 AI 达成了一个重要约定我会立刻把它追加到 docs/ai-context.md。后续的每一次新对话我先把这份文档粘贴给 AI再开始说新需求。这个习惯救了我很多次。因为 AI 没有持久记忆它只有上下文窗口你不在每次对话开始时把关键约定喂给它它就真的会“翻脸不认账”。用文档对抗遗忘是我这一年半最有效的防坑手段没有之一。3.4 测试驱动与 AI 代码审查很多人问我要不要信任 AI 生成的代码我的答案是不要信它而是让它自己证明给你看。这是我从 TDD 里借来的思路应用到 Vibe Coding 上效果出奇地好。具体操作是这样我需要一个功能时先让 AI 写测试用例描述期望的行为和边界输入。测试用例通过了说明 AI 理解了需求然后让 AI 写实现代码跑这些测试。如果测试失败我要求它看失败信息分析原因而不是粗暴地改测试去迁就实现。最后我会把生成的代码交给 AI 审查工具从性能、安全、代码风格三个维度做一遍静态扫描并把扫描结果反馈给它。这套“测试先行 AI 自审”的流程执行了半年之后我的代码合并到主干的通过率从最初的六成提升到了九成以上。这不是因为我写提示词的水平进步得多厉害而是流程把 AI 的“自说自话”限制在一个有验证机制的安全网里了。3.5 版本控制与回滚策略Vibe Coding 生成代码的速度快犯错的速度也快。如果你的版本控制策略不够敏捷代码库里会迅速混入一堆“来源不明”的改动到时候你想回滚都不知道从哪里切。我的策略非常简单但极其有效每个任务级别的 AI 对话独立分支独立提交。无论 AI 帮我改了多少个文件我都要求自己只提交一次commit message 写清楚“这个提交是 AI 生成的某某功能后续维护需要注意哪几点”。这样每个 AI 生成的功能都是一个原子提交出问题直接回滚这一条 commit不会牵连其他功能。另外我给自己定了一个强制流程AI 生成的代码必须经历“本地跑通关键路径 → 提交到分支 → 代码审查包含 AI 审查和人工抽查两轮 → 合并到主干 → 部署到预发环境”五步。任何一步不通过就打回重来。这套流程听起来繁琐但它把 Vibe Coding 的失控风险压到了最低。我宁可多花二十分钟走流程也不想花一整天在一个无法定位的线上故障上。4. 嵌入式与专业领域中的 Vibe Coding4.1 硬件环境下的限制“嵌入式 vibe coding”是最近被讨论得比较多的话题。我也在几个嵌入式项目里试过用 AI 辅助感受很复杂。先说结论嵌入式 AI 编码可行但它离“无脑生成”还有相当距离。嵌入式开发有几个天然制约第一资源受限AI 往往不擅长考虑内存占用和 CPU 时序第二硬件交互AI 没有真实的寄存器手册和硬件行为反馈它对设备驱动的理解经常来自“类 Unix 环境的惯性”放到裸机上就会出问题第三调试链路长你没法像写 Web 后端一样快速起一个服务验证逻辑每次验证都要编译烧录迭代成本高出一个数量级。所以嵌入式 Vibe Coding 的正确姿势是把 AI 用在逻辑层而不是硬件层。比如状态机、协议解析、数据滤波算法这些不直接操作寄存器的代码AI 可以帮你写框架、生成测试数据、解释调试信息。但到了配置时钟树、操作 DMA、处理中断优先级这些环节我强烈建议你自己对着芯片手册一行行看轻易别让 AI 替你做主。4.2 嵌入式开发中怎么用 AI 才是正确姿势我试用过几个 AI 辅助嵌入式开发的场景分享一下实际效果好和不好的案例方便你判断自己的项目的适配度。效果好的是协议栈的解析代码。比如 Modbus、MQTT-SN、自定义私有协议这些协议格式清晰、状态转移明确AI 很擅长从描述中生成可用的解析器和组帧工具。效果不错的还有单元测试的生成。嵌入式代码的单元测试长期是个痛点AI 可以帮你在宿主机上跑测试的代码写好 mock减少手工打桩的时间。效果不好的是实时控制相关的代码。PID 控制器的数学公式 AI 当然懂但这个控制周期内你能做多少次浮点运算、中断里能不能用互斥锁、缓存一致性怎么保证这些它全都不知道。我在一个电机驱动项目里让 AI 帮忙优化一段中断处理函数它给出的版本在我的平台上会导致中断响应超时。从那之后凡是涉及硬实时逻辑的代码我都只让 AI 做解释性辅助也就是给我讲清楚当前代码在干嘛而不会让它直接改逻辑。4.3 行业工具现状与选型建议很多人搜“vibe coding 工具”看到的往往是面向 Web 开发的一堆助手。嵌入式方向的工具支持相对落后但这两年也在快速补课。我目前的嵌入式工作流里常用的是通用对话式 AI 加一个本地的代码索引工具后者可以把整个代码库和芯片 SDK 塞进索引AI 回答问题时能引用到真实的寄存器定义幻觉率降低了很多。选型建议上我只想说一点嵌入式项目的工具优先考虑那些支持“私有化部署”或“本地模型”的方案。不是说云端不行而是嵌入式项目经常涉及尚未公开的硬件信息代码库外泄风险比纯软件项目高得多。你可以想象一下如果你所在团队正在做一款还没发布的新款微控制器适配把所有代码喂给一个云端模型这是多大的隐患。本地模型可能效果稍差但安全边界清晰。行业里没有完美的工具安全性和便利性的取舍你得提前想清楚。5. 项目管理与人月神话的再思考5.1 AI 是否解决了“人月神话”问题《人月神话》里有一句经典结论往一个延期项目里加人手只会让它延期得更厉害。Vibe Coding 时代我经常思考这个问题答案有点反直觉它确实改变了个人的产出密度但并没有解决团队层面的协作复杂度。过去一年半我观察到的现象是一个人 AI 可以完成以前两三个人的产出。但如果这件事发生在团队里那个人就会成为新的瓶颈。AI 生成的代码量太大、太快但代码评审、部署、运维、需求梳理这些环节的能力没有同步增长。结果是AI 把编码瓶颈往前推了推到了需求澄清和代码评审这两个环节上。所以我觉得Vibe Coding 不是让人月神话消失了而是让人月神话换了位置。以前瓶颈在写代码现在瓶颈在“决定写什么代码”和“验证代码是否该写”。如果你的团队还在用传统的方式做需求评审和代码审查AI 带来的效率红利会有一个明显天花板。5.2 技术债与维护成本每一个用过 Vibe Coding 的人都需要正面回答一个问题AI 生成代码的维护成本到底有多高我的真实感受是短期看省力中长期看取决于你有没有做好代码审查和文档沉淀。AI 生成代码最典型的问题是命名不统一、风格漂移、层次混乱。同一段业务逻辑你在三个不同对话里让 AI 写会得到三种截然不同的写法。它们可能都能跑通但维护者会非常痛苦因为整个代码库缺乏一致性。这个问题靠提示词是治标不治本的必须靠代码风格规范文件和持续的代码审查来约束。我现在会在每个项目开始前花很少的时间让 AI 根据团队规范生成一份项目级编码规范然后要求它在每次生成代码时都参考这份规范。这样做之后代码库的一致性有了明显改善。AI 生成的东西不是不能用而是你需要把它当“外包团队交过来的代码”来管理验收标准和文档要求一条都不能省。5.3 团队协作中的“ AI 写代码”边界在团队里推广 Vibe Coding最大的阻力往往不是技术而是人的接受度。有的同事觉得 AI 代码信不过有的同事怕被别人替代还有的同事觉得用 AI 属于“偷懒”。我经历过最激烈的一次讨论是关于“ AI 生成的代码能不能写自己的名字进 Git 提交记录”。我的观点是Vibe Coding 不是把责任转嫁给 AI而是把责任转移到提交者身上。AI 只是工具提交者需要对每一行代码负责。在这个原则下我认为团队应该鼓励适度使用 AI但必须划定边界核心业务逻辑、安全关键逻辑、数据迁移脚本这三类代码必须有人工逐行审查而工具类代码、模板代码、单元测试、文档示例可以大范围交给 AI。还应该有一个基本的共识AI 的使用方式和生成代码的质量应该像技术栈选型一样写进团队的手册。不写清楚每个人按自己的习惯来代码库就会成为一个风格四分五裂、问题无人负责的工地。6. 从新手到可以复现的成长路径6.1 一个真实的项目复盘讲一个我印象最深的项目能完整展示我是怎么用 Vibe Coding 把一个东西从零做出来的。那是一个面向内部团队的设备报修系统大概要支持设备登记、扫码报修、指派维修工单、状态跟踪和统计报表。以前我自己写这类系统估算工作量是三周。这次我刻意全程用 Vibe Coding记录下来的实际耗时是八个工作日。其中前三天用来做设计和拆解中间三天是写核心业务代码最后两天是写测试、处理边界情况和修 bug。这个项目里最让我惊喜的不是代码生成速度而是 AI 在帮我整理数据库表结构时的表现。我给了它业务需求描述后它先产出了六张表的 schema我检查后发现大部分合理只有两处关联关系有问题。我给它指出后它还主动提出了一条我之前没考虑到的数据保留策略。这种“结构化场景下的提示性建议”是 Vibe Coding 最有价值的地方它不是一个只会抄代码的机器而是一个能基于你的业务描述做推演的工具。6.2 如何训练你的“AI 同事”用 Vibe Coding 一年半我最大的感悟是AI 的能力边界一半取决于模型本身一半取决于你愿不愿意训练它。很多人的使用体验差是因为他们把 AI 当成搜索框用完就走从不做知识沉淀。我现在的做法是给每一个长期项目建一个 ai-context.md 文件里面包括项目简介、目录结构、关键技术约定、常见命令、已知陷阱、个人代码风格偏好。每次开始一个新对话我会花十几秒把相关部分复制给 AI让它在同一个上下文里干活。这十几秒的投入能让 AI 的输出质量从“大概得改几次才能用”提升到“基本一次到位”。这就像带一个新人入职。新人第一天你就把公司架构、代码规范、部署流程一股脑讲给他听他当然会懵但你要是不讲他就会拿自己过去在别的公司的经验乱套。AI 也一样它的训练数据里有无穷多项目经验你如果不告诉它你项目的特殊性它就给你套一个通用的外壳最后你还是得自己拆了重做。6.3 判断哪些代码可以交给 AI不是所有代码都适合 Vibe Coding我踩了足够多的坑之后总结出了一个相对清晰的判断框架按三个维度筛选任务的标准程度、上下文的完整程度、验证的容易程度。标准程度高、上下文完整、容易验证的代码是 AI 的舒适区。比如写一个 JSON Schema、生成一份数据迁移脚本、写一个 React 组件、实现一个公开算法。这些任务有明确的对错标准AI 几乎不会跑偏。标准程度低、上下文分散、难以验证的代码是 AI 的高危区。比如推动一个跨模块的业务流程变更、优化一段线上故障的代码、设计新的系统架构。这些任务需要全局观和渐进的验证AI 一旦失去上下文就会开始胡编。我自己在实操中把任务分成三类可以大胆交给 AI 的是“实现型任务”需要一起讨论的是“设计型任务”坚决自己动手的是“决策型任务”。实现型就是需求已经很清晰AI 负责翻译成代码设计型是需求有多种方案AI 负责出几个草案让你选决策型是涉及成本、风险、人力的选择这个只能人来定。把这个判断框架用好你会发现 Vibe Coding 的效率红利和风险底线是可以同时守住的。7. 常见问题与排查技巧实录7.1 遇到“ AI 改动其他文件”的处理这是 Vibe Coding 里最容易让人抓狂的问题你只是让 AI 改了一个工具函数它却擅自去改了三个调用方的代码还可能改歪了。我的处理方式分两步。第一步是立刻 reject 本次改动只保留它对你指定文件的那部分变更。如果修改已经提交了就用前一个 commit 做 diff把不必要的改动摘出来。第二步是在提示词里明确加一句“只允许修改我指定的文件其他文件即使看起来也应该改也要先问我”。把这句话放到每一次任务级对话的末尾AI 越界修改的发生率会大幅下降。7.2 怎么让 AI 产出风格统一的代码我经常被问到这个问题AI 生成的代码风格太飘忽怎么办。我验证过最有效的手段不是在提示词里说“请你保持风格一致”而是给它一个具体的、风格良好的示例文件。我会挑一个我手工写的、最有代表性的模块文件把它放到对话开头然后说“这是我项目中已有的代码风格范例后续生成的代码请严格遵循这个风格”。AI 对示例的模仿能力远强于对抽象规则的理解。你给它十条编码规范它可能每条都当耳边风你给它一个真实文件它反而会模仿得相当到位。7.3 上下文对话太长的应对方式当对话超过一定轮数AI 就开始变得迟钝甚至早忘记最初的约定。我建议一旦发现 AI 开始重复问已经确认过的问题或者代码质量和前几轮相比明显下降就果断开新对话。开新对话前把已经确认的方案摘要复制出来整理成一个“给 AI 的情况说明书”包含当前任务目标、已完成事项、遗留问题、本轮需要它做的事。这就像你跟一个人约谈前先发一份会议纪要他不需要翻历史聊天记录拿到纪要就能上手。虽然一开始整理概要要花几分钟但相比在乱糟糟的长对话里反复纠正错误这点成本低太多了。7.4 AI 生成代码的安全审查要点Vibe Coding 的另一个隐蔽风险是安全漏洞。AI 生成的代码在正常路径下表现良好但在恶意输入下可能翻车。我最常见的例子是 SQL 拼接、反射调用、反序列化、文件路径处理。我现在的强制要求是所有涉及用户输入、外部系统交互的 AI 代码必须通过一轮专项安全审查。审查时我会重点看三类问题是否有输入校验、是否用安全的字符串拼接方式、是否有资源释放逻辑。AI 代码审查工具会提示一部分问题但真正判断“这个数据源是否可信”这类问题还是需要人来猜测业务上下文。安全审查是 Vibe Coding 流程里最不能省的一环你省下的五分钟可能会变成一个你半夜爬起来修的安全事故。8. 常见问题速查表症状常见原因排查步骤预防手段编译通过但运行报错AI 使用了不存在的 API 或错误的并发模型跑单测检查异常栈核对 API 文档强制 AI 生成测试用例跑通后才合并上下文越长质量越差达到模型上下文窗口限制开新对话粘贴项目摘要和已确认约定任务级拆分维护 ai-context.md无故改动无关文件提示词边界不清AI 自作聪明审查 diff回滚无关改动明确“只改指定文件其他改动先询问”代码风格不一致多个对话使用了不同上下文对照项目规范重新审查每次对话提供风格示例文件安全漏洞AI 没有考虑恶意输入场景专项安全审查检查输入校验和资源释放涉及用户输入的代码强制安全审查需求理解偏差大业务规则描述不清对照需求逐条验收核心行为使用四要素提示词输入、输出、规则、边界9. 关于嵌入式与未来方向的一些个人判断9.1 嵌入式 Vibe Coding 的机会在哪里前面讲了嵌入式开发里 AI 的限制但我也想说这个方向的机会其实很大只是机会点和 Web 开发不太一样。我认为嵌入式 Vibe Coding 最值得发力的两个方向一个是硬件抽象层的标准化另一个是测试基建的补齐。硬件抽象层的标准化意味着一旦芯片厂商开始提供标准化的 SDK 描述文档AI 就能在更高抽象层次上帮你生成设备驱动骨架。现在很多芯片手册已经趋向结构化这正是 AI 发挥优势的土壤。测试基建补齐的方向更明确嵌入式开发最缺的就是宿主环境下的可测试性。如果 AI 能帮你生成高质量 mock 和硬件仿真层很多原本只能在真机上验证的逻辑就能提前在自动化测试里跑通。谁会先把这两个方向做扎实谁就能在嵌入式 Vibe Coding 这场竞赛里拿到下一张门票。9.2 一年半之后我的最终感受回到标题本身如果说这一年半我只能讲一句最有价值的心得那就是Vibe Coding 没有改变“编程需要理解本质”这件事它改变的只是“实现细节的获取方式”。图形界面没有让程序员不再需要懂算法快捷指令没有让文案不再需要懂修辞。Vibe Coding 也一样它让编码速度有了数量级上的提升但它也把更多的责任推到了开发者身上——你要更懂需求、更懂边界、更懂验证、更懂取舍。我在实际使用中发现真正让我成长最快的时刻往往不是 AI 顺利生成代码的时刻而是它生成一堆错误代码逼着我去逐行调试、理解它为什么会错的时刻。那是一种非常独特的“教学相长”。AI 是一面镜子它的输出质量直接反映你对问题理解得有多透明。你用 Vibe Coding 用得越好就越需要建立更清晰的思维框架而不是相反。9.3 给正在入门的读者三个建议如果这篇文章能给你留下点有用的东西我希望是这三条建议。第一从“小闭环”开始。不要第一个项目就想着让 AI 帮你搭建整个系统先找一个两周内能完成的小工具从一个独立函数、一个简单接口开始完整走一遍“描述、生成、测试、审查、提交”的闭环。你会在这个闭环里体会到 Vibe Coding 的节奏和风险点。第二用文档对抗遗忘。无论你用什么模型、什么插件请一定维护一份你自己的 AI 上下文文档记录你每个项目的关键约定。这不是浪费时间这是你所有 Vibe Coding 效率的底座。第三永远保留人审环节。AI 写得再快、再像样都请保留一道人工审查的关卡。尤其对于涉及生产环境、用户数据和资金交易的项目这道关卡就是你的安全底线。我见过太多被 AI 代码坑惨的案例无一例外都是省略了这一步。Vibe Coding 这条路我才走了一年半还有很多未知的边界没有探索完但就目前走到的地方而言它给我的收获已经远远超过了工具本身。它会继续演化我也会继续拿真实项目去检验它。希望这篇心得能帮你在自己踏进这条河之前少呛几口水。