1. 先说结论vibe coding 的本质是什么vibe coding 这个词最近的讨论度很高但它不是什么玄学也不是完全让 AI 写代码、自己躺平。我自己的理解是进入一种流畅的、几乎不需要打断思路的编码状态让 Copilot 这类工具承接重复性、机械性、中间衔接的工作把注意力留给系统设计和逻辑判断。我用 Copilot 加 VS Code 的组合已经超过两年从最初把它当成高级自动补全到后面形成一套相对稳定的协作流程确实踩过不少坑也总结出一些值得复用的套路。这套组合最大的价值不是代码写得快而是把写代码的状态从逐字符敲击变成描述意图、审查产出、快速修正的循环整个节奏舒服很多。很多人以为 vibe coding 等于全自动开发其实它更接近飞行员和自动驾驶的关系你负责航向、判断和兜底AI 负责大部分平稳飞行。核心是信任边界——你要知道什么时候可以大胆让它跑什么时候必须手动接管。这个边界拿捏得好效率可以翻倍拿捏不好就是在给自己埋雷。这篇文章不做概念复述直接从我自己的实战经验出发聊清楚三件事怎么配置一套趁手的 Copilot 环境怎么把描述想法—生成代码—验证结果—重构细节做成肌肉记忆以及哪些场景我建议你绕过 AI、老老实实自己写。2. 环境配置别小看那些默认设置它们决定了一半体验2.1 插件与账号初始化Copilot 在 VS Code 里的安装本身没什么好说的扩展市场搜 GitHub Copilot 安装即可。但有几个初始化细节容易被忽略直接影响使用质量账号登录走的是 GitHub 身份如果公司网络有自定义代理需要在 VS Code 的 settings.json 里提前配置http.proxy否则插件装好但请求一直超时很容易误判为AI 不行。建议把 GitHub Copilot Chat 和主插件一起装因为纯靠行内补全做 vibe coding 是不够的对话式生成和代码解释必须配合使用。安装完以后先花两分钟跑一下官方示例确认补全和聊天面板都能正常响应这个时候再进项目不然你很难判断是配置问题还是 prompt 问题。我给团队内部做分享的时候经常打一个比方Copilot 的能力上限是模型决定的但能力下限是配置决定的。默认配置可以用但想让补全更贴合自己项目的风格必须改两处地方。2.2 核心配置文件逐项说明VS Code 对 Copilot 有专门配置项我现在的 settings.json 里长期保留以下几行{ github.copilot.enable: { *: true, markdown: false }, github.copilot.editor.enableAutoCompletions: true, github.copilot.chat.codeGeneration.instructions: [ { file: .github/copilot-instructions.md } ], editor.inlineSuggest.enabled: true, editor.suggestSelection: first }逐个说原因github.copilot.enable里我单独关闭了 markdown 文件的补全因为写文档时 AI 总喜欢接一些正确的废话打断思路。instructions 指向一个仓库内的指令文件这是给 Copilot 定团队规矩的地方比如要求注释用中文还是英文、变量命名风格、禁止使用某些不安全的 API。这个文件写好以后所有协作者共享同一套生成标准。editor.inlineSuggest.enabled一定要为 true这是行内补全的总开关。editor.suggestSelection改 first 是避免在补全和本地提示之间来回混淆。.github/copilot-instructions.md是目前很多人没用起来但价值最高的功能。我在这份文件里的内容大致包含项目技术栈说明、模块划分思路、命名约束、注释语言、异常处理风格、测试框架要求。每次让 Copilot 生成代码时它都会参考这些约束。这比你在对话里反复强调省事得多。2.3 快捷键改造让双手不用离开键盘vibe coding 强调状态流畅所以快捷键值得花一点时间定制。我个人最常用的几个CtrlEnter接受行内补全的整段建议默认是 Tab但 Tab 在缩进和跳转时容易误触。CtrlRight逐词接受补全内容。CtrlL快速把当前选中代码带入聊天窗口自定义的。AltC让 Copilot 对当前文件做一次快速 review 建议。重点不是照搬快捷键而是找到一套你不容易按错的方案。很多人觉得接受补全按 Tab 就行实际用下来在循环生成多个连续片段时Tab 经常会被编辑器其他功能拦截导致接受了一半、停住了。我改成CtrlEnter以后顺畅很多。3. 从自动补全到描述式编码的四个阶段3.1 阶段一让它学会你的项目上下文vibe coding 的第一个阶段不是急着写业务而是先让 Copilot 熟悉项目。我通常按这个顺序操作打开项目根目录下最核心的入口文件比如main.py、index.ts让插件加载上下文。打开项目文档或 README如果里面有架构说明Copilot 会把它当作重要参考。写完一个基础类型定义或接口签名观察补全是否贴合你预期的命名风格。如果补全明显离谱优先检查.github/copilot-instructions.md里的约束是否写清楚了。这里有个容易被忽略的细节Copilot 的上下文不是整个项目都理解而是基于当前打开文件和相邻文件推断上下文。所以别一口气开几十个标签页这反而会让它的注意力分散。我通常只保留当前正在改的文件、它依赖的模块文件、以及一个参考文档标签一共三四个文件生成质量最稳定。3.2 阶段二用注释描述意图让补全帮你搭骨架这是我的主力工作方式先写注释不写代码。比如我需要一个从数据库读取配置并解析成 Python 字典的工具函数我会先敲这段注释# 连接 SQLite 数据库读取 config 表中的所有键值对 # 返回 dict键为 config_key值为 config_value # 如果表不存在返回空 dict不要抛异常然后等待 Copilot 生成函数体。大部分时候它能一次给出正确的实现包括建表判断和异常吞噬逻辑。这个方式的威力在于注释本身逼我先想清楚边界条件而实现细节交给 Copilot正好符合 vibe coding 的精神——你负责稳定航道它负责平稳飞行。从实践效果看注释里写得最清楚的是输入是什么、输出是什么、异常情况怎么处理这三件事只要写明白生成结果基本靠谱。相反如果注释只写获取配置生成结果就飘得很它不知道你要什么数据结构、要不要默认值、要不要缓存最后生成了一个看起来能用但实际处处别扭的函数。3.3 阶段三用 Copilot Chat 做局部功能块生成行内补全之外Chat 模式用于一整块功能的生成比如完整的一个 REST API 端点、一条数据迁移脚本、一个复杂的查询逻辑。我给 Chat 的 prompt 通常会这样组织当前项目技术栈Python FastAPI SQLAlchemy。 需求新增一个 /api/v1/report/summary 接口接收日期范围参数 返回该范围内按类型分组的统计结果格式为 JSON。 约束使用异步方式查询只涉及 report 表参数校验失败时返回 400。 请先生成接口函数再补充 Pydantic schema 定义。这个 prompt 包含了五类信息技术栈、需求描述、约束条件、输出类型、补充要求。少一个都可能导致生成结果跑偏。技术栈信息尤其重要因为 Chat 默认只知道你当前文件的语言不清楚项目中用没用 ORM、用没用异步框架。你显式告诉它它就不会给你一段 Flask 风格代码。3.4 阶段四生成之后的主动重构我刚用 Copilot 的时候有个坏习惯看到生成代码能跑就直接用导致大量函数越堆越长因为 AI 倾向于在一个连续代码块里把所有逻辑写完。后来我形成一条铁规矩凡是 AI 生成的函数必须检查是否可以拆分。典型信号是一个函数超过 40 行函数缩进超过 3 层或者函数里同时做了数据获取、逻辑判断、结果格式化三件事。只要命中其一我就会选中代码块让 Copilot 提出拆分方案然后手动调整。拆分不是让 AI 随便拆而是让它按职责拆。比如上面提到的获取数据、判断、格式化三个步骤拆成三个私有函数每个函数保持单一职责。这一步做完代码的可维护性和可读性才有保障。vibe coding 真正的分水岭就在这里有人用 AI 生成了能跑的一坨有人用 AI 生成了能维护的代码。4. Prompt 写法与常见生成陷阱4.1 让 Copilot 理解需求的四段式描述法很多人觉得 Copilot 生成质量不稳定其实是 prompt 写得太笼统。我总结出一个四段式模板适配 Chat 模式场景在什么环境、什么上下文里工作。任务要做出的具体产出。边界哪些事情不要做、哪些情况如何处理。验收怎么判断结果正确。给一个实际例子比如生成一个数据处理函数场景一份 CSV 文件包含 user_id, purchase_time, amount 三列。 任务读取并统计每位用户的消费次数和总金额返回字典。 边界amount 列有空值时跳过该行purchase_time 不需要解析成分离的时间对象。 验收写一个单元测试验证输入三条记录时输出符合预期。前两步保证 AI 知道做什么后两步控制它不做多余的事。很多人漏掉的就是边界和验收。没有边界AI 会自作主张地把时间字符串解析成 datetime 甚至加上时区处理没有验收你拿到的代码可能没有测试还得自己补。4.2 行内补全被带偏的主要原因行内补全的生成质量直接受光标之前代码上下文影响常见的带偏情况有几种项目里存在大量重复风格的代码Copilot 会模仿当前文件里已有的写法。如果旧代码很乱它生成的新代码也会很乱。解决办法是在 instructions 文件里写明风格要求。类型不明确如果函数参数没有类型注解它无法确定该参数支持的方法很容易给出一个错误的属性调用。缩进或语法错误如果当前代码本身有语法错误补全会进入试图修复的模式生成一堆奇怪内容。对付这些带偏情况最好的办法不是删掉重写而是先修上下文再让补全重新建议。我习惯把光标往前移动几行删掉可能造成误导的变量命名字符然后重新触发CtrlEnter。大部分时候第二次建议会比第一次准很多。4.3 指令文件里必须写清楚的三件事.github/copilot-instructions.md不是什么宏大文档我最核心的内容很短大概十几行只包含三件事架构约束比如所有数据库访问必须通过 repository 层禁止在 service 层直接执行 SQL。风格约定比如变量命名使用 snake_case私有函数以下划线开头注释使用中文但代码命名使用英文。禁忌清单比如禁止使用eval()禁止把except Exception写成pass禁止在循环内执行耗时请求。这些约束不必字字句句是法律但至少保证生成结果不会犯低级结构性错误。Copilot 生成代码时确实会参考这份文件如果你发现它没遵守大概率是文件内容写得太抽象。写代码质量要高没有用要写函数行数不超过 50 行超过必须拆分这种可以检查的具体要求。5. 一套可落地的 vibe coding 工作流5.1 从需求到代码的完整流程示例下面是我近几个月做某内部工具时实际用过的一个完整流程。需求是一个批量导入用户数据的脚本输入 Excel 文件路径读取指定工作表校验数据并把合法记录写入数据库。第一步我不写代码而是用自然语言在 Chat 里描述要解决的问题并要求它给出大致的实现方案。Copilot 给出一个三步方案用pandas读取、用 Pydantic 校验、用 SQLAlchemy 批量插入。第二步我把方案拆成两个可以逐步验证的片段先实现读取和校验部分运行一下确认数据没读错再实现批量插入部分。分步生成有个好处每段代码都经过实际运行验证不会出现整个脚本跑完才发现前置步骤全错。第三步对于校验逻辑里有一处复杂的字段转换我自己写不让 Copilot 碰。原因是这个转换规则业务性太强涉及一堆模糊匹配逻辑AI 没法从上下文推出来让它生成只会制造幻觉。最终这个需求从开始到完成用了大概四十分钟其中写代码的时间只有十分钟其他时间在跑测试和数据核对。这个比例对 vibe coding 来说是正常的——AI 帮你压缩的是打字时间不是思考时间。5.2 先写测试再让 Copilot 补实现想让 vibe coding 不失控我强烈建议在关键模块上使用测试先行。不是让你写 TDD 全套流程而是让 Copilot 先生成测试用例再生成实现。比如我需要一个函数判断某个用户是否满足优惠活动条件。我先让 Copilot 基于需求描述生成一组测试用例用例里包含了正常满足条件、条件缺一个、数据为空等场景。测试用例本身就是需求规格的具象化看完测试用例你就能确认 AI 有没有理解对需求。然后让 Copilot 实现该函数跑一遍测试。测试全绿就收工有红的就根据具体报错去调整实现。这种方式比生成代码—人工目测—打包上线可靠得多因为 AI 生成的代码在语法上几乎不出错真正出错的是业务逻辑而业务逻辑错误只能靠具体的输入输出暴露出来。很多人嫌写测试麻烦我的实际体验是AI 生成测试和生成业务代码一样快麻烦的不是写测试而是把测试场景想全。而想测试场景这个事恰恰是 AI 不懂业务、无法替代你的地方。5.3 让 Copilot 做代码审查的隐藏玩法除了生成代码Copilot 还能充当初级代码审查者。我每写完一个模块会选中这段代码在 Chat 里输入请审查这段代码重点寻找潜在的异常路径、类型问题、性能问题 用简短列表返回问题位置和修改建议不要重写整段代码。这个用法在生成代码后特别有价值。因为 Copilot 生成代码时往往只盯着自己要完成的那一小块容易忽视全局性的问题比如重复连接数据库、重复计算相同值、异常处理过于宽泛。让它回头审视一遍确实能揪出不少问题。不过要注意Copilot 的审查能力有限它不太能发现这个功能不该这么做这种架构级问题更多是发现局部代码质量问题。这跟它的定位一致——它是结对编程的 junior 搭档不是架构师。6. 翻车现场实录与排查方法6.1 最典型的三类失败场景我在实际使用中总结出三类最常踩的坑分享出来省得大家再走弯路第一类生成的代码在语法上完美但在当前项目环境里无法运行。最典型的是依赖缺失、函数签名变了、或用了项目里还没有的库。解决方法是在 prompt 里显式说明只使用 requirements.txt 中已有的依赖或者基于项目现有工具库实现。第二类Copilot 给自己编造了 API。比如它给你生成了一段调用某个第三方库的方法但这个方法在文档里根本不存在。这种幻觉尤其爱出现在小众库或者新版本库里。排查方法是看见它引用 API 后立刻跳转到定义处确认如果跳不进去就搜索确认。不要轻信它信誓旦旦的代码。第三类生成的代码没有考虑并发场景。如果项目是多个 worker 同时跑任务而 Copilot 生成的代码用了模块级变量缓存数据就会引发数据错乱。这类问题不运行特定场景很难发现所以处理办法就是在 prompt 的边界部分写明 该代码可能被多线程并发调用注意线程安全。6.2 上下文污染时如何快速止损上下文污染是 vibe coding 最隐蔽的杀手。典型症状是明明聊的是 A 模块Copilot 生成的代码却参考了之前在 B 模块里的讨论内容导致出现奇怪的变量名或者多余的参数。这时候不要继续在同一个会话里纠正它因为纠正本身就是一种输入它会继续结合之前聊过的上下文生成更加四不像的结果。正确做法是开一个新会话重新贴上下文重新描述需求。这个动作成本很低但很多人不舍得放弃当前会话结果反复纠正了二十分钟还没效果。另外一个止损技巧如果某个文件里有一大段错误代码不要试图让 Copilot 在原基础上改对直接让它基于需求重写这一段并且选中完整替换范围。局部 patch 在简单改动时有效但在结构性问题时重写比修补靠谱得多。6.3 排查流程速查表我把自己遇到问题时的排查顺序做成一个小清单现在固定用这套流程基本能在几分钟内定位到问题源头症状先检查什么再检查什么最后选择补全突然变蠢当前文件是否有语法错误是否多个标签页上下文冲突关掉无关标签页后重新触发补全生成代码无法运行是否用了项目没有的依赖API 签名是否真实存在补全依赖或让 Copilot 换实现方案聊天结果跑偏prompt 是否缺少边界描述是否在旧会话里反复纠正新开会话重写 prompt样式与项目不一致instructions 文件是否提到风格当前文件里是否已有乱码风格代码在指令文件里补充风格约定这个表不是万能的但它能避免一个常见问题很多人一遇到生成结果不对就怪 AI 能力不行其实大部分问题出在上下文和 prompt 上。6.4 四十行以上的生成代码必须拆开检查前面提过函数拆分的原则这里展开聊聊为什么要专门强调四十行这个数字。行内补全的生成逻辑倾向于沿着当前函数继续往下写也就是说只要你不打断它它可以把一个函数越写越长把所有逻辑都揉进去。Copilot 能维持较强的局部一致性但代价是函数的横向复杂度膨胀。我的经验是一次生成的函数超过四十行时不太可能只有单一职责。拆分的信号包括函数内出现两个以上如果...就...的分支、出现连续三个以上步骤操作同一个对象、或者出现注释分段标记。碰到这些情况我会主动在注释里写拆分点比如# 第一步解析输入参数 # 第二步组装查询条件 # 第三步执行查询并格式化结果然后让 Copilot 把每个步骤写成一个独立函数。这样既保留了 vibe coding 的速度又不会产生一个需要花二十分钟读懂的怪物函数。这个习惯养成以后回头再看之前直接生成的代码确实会有种当时怎么能这么写的感觉。7. 一些反直觉但实际有效的建议不要盯着 AI 写代码。很多人在 Copilot 生成代码时会盯着屏幕等它蹦字这样反而会把你的注意力锁在低层次的代码细节上。我的习惯是把大块任务交给 Chat 生成时切出去看文档或整理思路过一会儿回来看结果。行内补全也不盯着逐字看而是等它给出推荐的整段代码后用快捷键接受。减少注视 AI 动作的时间是进入 vibe 状态的重要方法。不要把所有功能都交给 Copilot。有些代码自带高风险标签我会手动写涉及数据迁移和删除的脚本、涉及金额计算逻辑、涉及权限判断的核心代码。这类代码未必复杂但其正确性至关重要而且出错后的排查成本远高于手写成本。vibe coding 不是把所有代码都甩给 AI而是把合适的那部分交给 AI。尽量把文件控制在百行以内。Copilot 的上下文理解能力和文件长度成反比在超长文件里它的补全准确率明显下降。如果你的功能需要堆到四五百行先别急着写拆成多个模块、多个文件。这个建议不只是为了 Copilot也是为长期可维护性考虑。文件短了AI 给出的建议天然就更准这是一个正反馈循环。给指令文件定期做维护。我之前把 instructions 文件写好后就不管了直到有一次发现 Copilot 还在用几个月前某个已经废弃的库的导入方式才意识到约束需要跟随项目演进。现在每次一次重构技术栈或统一风格时我都会顺手更新指令文件里的对应条款。这个维护成本几乎为零但能保证生成质量不随时间衰减。8. 关于 vibe coding 的边界感回到开头说的飞行员比喻。这一整套实践走下来我最大的体会是vibe coding 并不存在一个用对了就起飞、用错了就完蛋的开关它是一场持续在做的判断练习。你判断的核心问题永远只有一个这段代码的正确性容易验证吗如果容易验证比如纯工具函数、数据转换、接口模板那就放心交给 AI它的效率远胜于手动写。如果正确性很难验证比如涉及资金、权限、状态变更的关键逻辑那就算 AI 能写得更快我也会选择自己来。Copilot 加 VS Code 是我目前用下来顺手程度最高的组合但工具会迭代、模型会升级真正值钱的不是某一款工具而是你围绕工具建立的那套流程。流程可以让一个普通工具产出稳定可用代码也可以让最强工具产出一堆不可维护的垃圾。希望上面这些实践对你建立自己的流程有帮助。如果再有人问 vibe coding 有什么用我的回答是它能把你从键盘前解放出来让你更像一个设计师而不是一个打字员。但前提是你要知道自己在设计什么。 
长河君 · 2026/10/20 21:53:39 · 阅读 1.2k vibe coding实战：用GitHub Copilot打造高效编码工作流
1. 先说结论vibe coding 的本质是什么vibe coding 这个词最近的讨论度很高但它不是什么玄学也不是完全让 AI 写代码、自己躺平。我自己的理解是进入一种流畅的、几乎不需要打断思路的编码状态让 Copilot 这类工具承接重复性、机械性、中间衔接的工作把注意力留给系统设计和逻辑判断。我用 Copilot 加 VS Code 的组合已经超过两年从最初把它当成高级自动补全到后面形成一套相对稳定的协作流程确实踩过不少坑也总结出一些值得复用的套路。这套组合最大的价值不是代码写得快而是把写代码的状态从逐字符敲击变成描述意图、审查产出、快速修正的循环整个节奏舒服很多。很多人以为 vibe coding 等于全自动开发其实它更接近飞行员和自动驾驶的关系你负责航向、判断和兜底AI 负责大部分平稳飞行。核心是信任边界——你要知道什么时候可以大胆让它跑什么时候必须手动接管。这个边界拿捏得好效率可以翻倍拿捏不好就是在给自己埋雷。这篇文章不做概念复述直接从我自己的实战经验出发聊清楚三件事怎么配置一套趁手的 Copilot 环境怎么把描述想法—生成代码—验证结果—重构细节做成肌肉记忆以及哪些场景我建议你绕过 AI、老老实实自己写。2. 环境配置别小看那些默认设置它们决定了一半体验2.1 插件与账号初始化Copilot 在 VS Code 里的安装本身没什么好说的扩展市场搜 GitHub Copilot 安装即可。但有几个初始化细节容易被忽略直接影响使用质量账号登录走的是 GitHub 身份如果公司网络有自定义代理需要在 VS Code 的 settings.json 里提前配置http.proxy否则插件装好但请求一直超时很容易误判为AI 不行。建议把 GitHub Copilot Chat 和主插件一起装因为纯靠行内补全做 vibe coding 是不够的对话式生成和代码解释必须配合使用。安装完以后先花两分钟跑一下官方示例确认补全和聊天面板都能正常响应这个时候再进项目不然你很难判断是配置问题还是 prompt 问题。我给团队内部做分享的时候经常打一个比方Copilot 的能力上限是模型决定的但能力下限是配置决定的。默认配置可以用但想让补全更贴合自己项目的风格必须改两处地方。2.2 核心配置文件逐项说明VS Code 对 Copilot 有专门配置项我现在的 settings.json 里长期保留以下几行{ github.copilot.enable: { *: true, markdown: false }, github.copilot.editor.enableAutoCompletions: true, github.copilot.chat.codeGeneration.instructions: [ { file: .github/copilot-instructions.md } ], editor.inlineSuggest.enabled: true, editor.suggestSelection: first }逐个说原因github.copilot.enable里我单独关闭了 markdown 文件的补全因为写文档时 AI 总喜欢接一些正确的废话打断思路。instructions 指向一个仓库内的指令文件这是给 Copilot 定团队规矩的地方比如要求注释用中文还是英文、变量命名风格、禁止使用某些不安全的 API。这个文件写好以后所有协作者共享同一套生成标准。editor.inlineSuggest.enabled一定要为 true这是行内补全的总开关。editor.suggestSelection改 first 是避免在补全和本地提示之间来回混淆。.github/copilot-instructions.md是目前很多人没用起来但价值最高的功能。我在这份文件里的内容大致包含项目技术栈说明、模块划分思路、命名约束、注释语言、异常处理风格、测试框架要求。每次让 Copilot 生成代码时它都会参考这些约束。这比你在对话里反复强调省事得多。2.3 快捷键改造让双手不用离开键盘vibe coding 强调状态流畅所以快捷键值得花一点时间定制。我个人最常用的几个CtrlEnter接受行内补全的整段建议默认是 Tab但 Tab 在缩进和跳转时容易误触。CtrlRight逐词接受补全内容。CtrlL快速把当前选中代码带入聊天窗口自定义的。AltC让 Copilot 对当前文件做一次快速 review 建议。重点不是照搬快捷键而是找到一套你不容易按错的方案。很多人觉得接受补全按 Tab 就行实际用下来在循环生成多个连续片段时Tab 经常会被编辑器其他功能拦截导致接受了一半、停住了。我改成CtrlEnter以后顺畅很多。3. 从自动补全到描述式编码的四个阶段3.1 阶段一让它学会你的项目上下文vibe coding 的第一个阶段不是急着写业务而是先让 Copilot 熟悉项目。我通常按这个顺序操作打开项目根目录下最核心的入口文件比如main.py、index.ts让插件加载上下文。打开项目文档或 README如果里面有架构说明Copilot 会把它当作重要参考。写完一个基础类型定义或接口签名观察补全是否贴合你预期的命名风格。如果补全明显离谱优先检查.github/copilot-instructions.md里的约束是否写清楚了。这里有个容易被忽略的细节Copilot 的上下文不是整个项目都理解而是基于当前打开文件和相邻文件推断上下文。所以别一口气开几十个标签页这反而会让它的注意力分散。我通常只保留当前正在改的文件、它依赖的模块文件、以及一个参考文档标签一共三四个文件生成质量最稳定。3.2 阶段二用注释描述意图让补全帮你搭骨架这是我的主力工作方式先写注释不写代码。比如我需要一个从数据库读取配置并解析成 Python 字典的工具函数我会先敲这段注释# 连接 SQLite 数据库读取 config 表中的所有键值对 # 返回 dict键为 config_key值为 config_value # 如果表不存在返回空 dict不要抛异常然后等待 Copilot 生成函数体。大部分时候它能一次给出正确的实现包括建表判断和异常吞噬逻辑。这个方式的威力在于注释本身逼我先想清楚边界条件而实现细节交给 Copilot正好符合 vibe coding 的精神——你负责稳定航道它负责平稳飞行。从实践效果看注释里写得最清楚的是输入是什么、输出是什么、异常情况怎么处理这三件事只要写明白生成结果基本靠谱。相反如果注释只写获取配置生成结果就飘得很它不知道你要什么数据结构、要不要默认值、要不要缓存最后生成了一个看起来能用但实际处处别扭的函数。3.3 阶段三用 Copilot Chat 做局部功能块生成行内补全之外Chat 模式用于一整块功能的生成比如完整的一个 REST API 端点、一条数据迁移脚本、一个复杂的查询逻辑。我给 Chat 的 prompt 通常会这样组织当前项目技术栈Python FastAPI SQLAlchemy。 需求新增一个 /api/v1/report/summary 接口接收日期范围参数 返回该范围内按类型分组的统计结果格式为 JSON。 约束使用异步方式查询只涉及 report 表参数校验失败时返回 400。 请先生成接口函数再补充 Pydantic schema 定义。这个 prompt 包含了五类信息技术栈、需求描述、约束条件、输出类型、补充要求。少一个都可能导致生成结果跑偏。技术栈信息尤其重要因为 Chat 默认只知道你当前文件的语言不清楚项目中用没用 ORM、用没用异步框架。你显式告诉它它就不会给你一段 Flask 风格代码。3.4 阶段四生成之后的主动重构我刚用 Copilot 的时候有个坏习惯看到生成代码能跑就直接用导致大量函数越堆越长因为 AI 倾向于在一个连续代码块里把所有逻辑写完。后来我形成一条铁规矩凡是 AI 生成的函数必须检查是否可以拆分。典型信号是一个函数超过 40 行函数缩进超过 3 层或者函数里同时做了数据获取、逻辑判断、结果格式化三件事。只要命中其一我就会选中代码块让 Copilot 提出拆分方案然后手动调整。拆分不是让 AI 随便拆而是让它按职责拆。比如上面提到的获取数据、判断、格式化三个步骤拆成三个私有函数每个函数保持单一职责。这一步做完代码的可维护性和可读性才有保障。vibe coding 真正的分水岭就在这里有人用 AI 生成了能跑的一坨有人用 AI 生成了能维护的代码。4. Prompt 写法与常见生成陷阱4.1 让 Copilot 理解需求的四段式描述法很多人觉得 Copilot 生成质量不稳定其实是 prompt 写得太笼统。我总结出一个四段式模板适配 Chat 模式场景在什么环境、什么上下文里工作。任务要做出的具体产出。边界哪些事情不要做、哪些情况如何处理。验收怎么判断结果正确。给一个实际例子比如生成一个数据处理函数场景一份 CSV 文件包含 user_id, purchase_time, amount 三列。 任务读取并统计每位用户的消费次数和总金额返回字典。 边界amount 列有空值时跳过该行purchase_time 不需要解析成分离的时间对象。 验收写一个单元测试验证输入三条记录时输出符合预期。前两步保证 AI 知道做什么后两步控制它不做多余的事。很多人漏掉的就是边界和验收。没有边界AI 会自作主张地把时间字符串解析成 datetime 甚至加上时区处理没有验收你拿到的代码可能没有测试还得自己补。4.2 行内补全被带偏的主要原因行内补全的生成质量直接受光标之前代码上下文影响常见的带偏情况有几种项目里存在大量重复风格的代码Copilot 会模仿当前文件里已有的写法。如果旧代码很乱它生成的新代码也会很乱。解决办法是在 instructions 文件里写明风格要求。类型不明确如果函数参数没有类型注解它无法确定该参数支持的方法很容易给出一个错误的属性调用。缩进或语法错误如果当前代码本身有语法错误补全会进入试图修复的模式生成一堆奇怪内容。对付这些带偏情况最好的办法不是删掉重写而是先修上下文再让补全重新建议。我习惯把光标往前移动几行删掉可能造成误导的变量命名字符然后重新触发CtrlEnter。大部分时候第二次建议会比第一次准很多。4.3 指令文件里必须写清楚的三件事.github/copilot-instructions.md不是什么宏大文档我最核心的内容很短大概十几行只包含三件事架构约束比如所有数据库访问必须通过 repository 层禁止在 service 层直接执行 SQL。风格约定比如变量命名使用 snake_case私有函数以下划线开头注释使用中文但代码命名使用英文。禁忌清单比如禁止使用eval()禁止把except Exception写成pass禁止在循环内执行耗时请求。这些约束不必字字句句是法律但至少保证生成结果不会犯低级结构性错误。Copilot 生成代码时确实会参考这份文件如果你发现它没遵守大概率是文件内容写得太抽象。写代码质量要高没有用要写函数行数不超过 50 行超过必须拆分这种可以检查的具体要求。5. 一套可落地的 vibe coding 工作流5.1 从需求到代码的完整流程示例下面是我近几个月做某内部工具时实际用过的一个完整流程。需求是一个批量导入用户数据的脚本输入 Excel 文件路径读取指定工作表校验数据并把合法记录写入数据库。第一步我不写代码而是用自然语言在 Chat 里描述要解决的问题并要求它给出大致的实现方案。Copilot 给出一个三步方案用pandas读取、用 Pydantic 校验、用 SQLAlchemy 批量插入。第二步我把方案拆成两个可以逐步验证的片段先实现读取和校验部分运行一下确认数据没读错再实现批量插入部分。分步生成有个好处每段代码都经过实际运行验证不会出现整个脚本跑完才发现前置步骤全错。第三步对于校验逻辑里有一处复杂的字段转换我自己写不让 Copilot 碰。原因是这个转换规则业务性太强涉及一堆模糊匹配逻辑AI 没法从上下文推出来让它生成只会制造幻觉。最终这个需求从开始到完成用了大概四十分钟其中写代码的时间只有十分钟其他时间在跑测试和数据核对。这个比例对 vibe coding 来说是正常的——AI 帮你压缩的是打字时间不是思考时间。5.2 先写测试再让 Copilot 补实现想让 vibe coding 不失控我强烈建议在关键模块上使用测试先行。不是让你写 TDD 全套流程而是让 Copilot 先生成测试用例再生成实现。比如我需要一个函数判断某个用户是否满足优惠活动条件。我先让 Copilot 基于需求描述生成一组测试用例用例里包含了正常满足条件、条件缺一个、数据为空等场景。测试用例本身就是需求规格的具象化看完测试用例你就能确认 AI 有没有理解对需求。然后让 Copilot 实现该函数跑一遍测试。测试全绿就收工有红的就根据具体报错去调整实现。这种方式比生成代码—人工目测—打包上线可靠得多因为 AI 生成的代码在语法上几乎不出错真正出错的是业务逻辑而业务逻辑错误只能靠具体的输入输出暴露出来。很多人嫌写测试麻烦我的实际体验是AI 生成测试和生成业务代码一样快麻烦的不是写测试而是把测试场景想全。而想测试场景这个事恰恰是 AI 不懂业务、无法替代你的地方。5.3 让 Copilot 做代码审查的隐藏玩法除了生成代码Copilot 还能充当初级代码审查者。我每写完一个模块会选中这段代码在 Chat 里输入请审查这段代码重点寻找潜在的异常路径、类型问题、性能问题 用简短列表返回问题位置和修改建议不要重写整段代码。这个用法在生成代码后特别有价值。因为 Copilot 生成代码时往往只盯着自己要完成的那一小块容易忽视全局性的问题比如重复连接数据库、重复计算相同值、异常处理过于宽泛。让它回头审视一遍确实能揪出不少问题。不过要注意Copilot 的审查能力有限它不太能发现这个功能不该这么做这种架构级问题更多是发现局部代码质量问题。这跟它的定位一致——它是结对编程的 junior 搭档不是架构师。6. 翻车现场实录与排查方法6.1 最典型的三类失败场景我在实际使用中总结出三类最常踩的坑分享出来省得大家再走弯路第一类生成的代码在语法上完美但在当前项目环境里无法运行。最典型的是依赖缺失、函数签名变了、或用了项目里还没有的库。解决方法是在 prompt 里显式说明只使用 requirements.txt 中已有的依赖或者基于项目现有工具库实现。第二类Copilot 给自己编造了 API。比如它给你生成了一段调用某个第三方库的方法但这个方法在文档里根本不存在。这种幻觉尤其爱出现在小众库或者新版本库里。排查方法是看见它引用 API 后立刻跳转到定义处确认如果跳不进去就搜索确认。不要轻信它信誓旦旦的代码。第三类生成的代码没有考虑并发场景。如果项目是多个 worker 同时跑任务而 Copilot 生成的代码用了模块级变量缓存数据就会引发数据错乱。这类问题不运行特定场景很难发现所以处理办法就是在 prompt 的边界部分写明 该代码可能被多线程并发调用注意线程安全。6.2 上下文污染时如何快速止损上下文污染是 vibe coding 最隐蔽的杀手。典型症状是明明聊的是 A 模块Copilot 生成的代码却参考了之前在 B 模块里的讨论内容导致出现奇怪的变量名或者多余的参数。这时候不要继续在同一个会话里纠正它因为纠正本身就是一种输入它会继续结合之前聊过的上下文生成更加四不像的结果。正确做法是开一个新会话重新贴上下文重新描述需求。这个动作成本很低但很多人不舍得放弃当前会话结果反复纠正了二十分钟还没效果。另外一个止损技巧如果某个文件里有一大段错误代码不要试图让 Copilot 在原基础上改对直接让它基于需求重写这一段并且选中完整替换范围。局部 patch 在简单改动时有效但在结构性问题时重写比修补靠谱得多。6.3 排查流程速查表我把自己遇到问题时的排查顺序做成一个小清单现在固定用这套流程基本能在几分钟内定位到问题源头症状先检查什么再检查什么最后选择补全突然变蠢当前文件是否有语法错误是否多个标签页上下文冲突关掉无关标签页后重新触发补全生成代码无法运行是否用了项目没有的依赖API 签名是否真实存在补全依赖或让 Copilot 换实现方案聊天结果跑偏prompt 是否缺少边界描述是否在旧会话里反复纠正新开会话重写 prompt样式与项目不一致instructions 文件是否提到风格当前文件里是否已有乱码风格代码在指令文件里补充风格约定这个表不是万能的但它能避免一个常见问题很多人一遇到生成结果不对就怪 AI 能力不行其实大部分问题出在上下文和 prompt 上。6.4 四十行以上的生成代码必须拆开检查前面提过函数拆分的原则这里展开聊聊为什么要专门强调四十行这个数字。行内补全的生成逻辑倾向于沿着当前函数继续往下写也就是说只要你不打断它它可以把一个函数越写越长把所有逻辑都揉进去。Copilot 能维持较强的局部一致性但代价是函数的横向复杂度膨胀。我的经验是一次生成的函数超过四十行时不太可能只有单一职责。拆分的信号包括函数内出现两个以上如果...就...的分支、出现连续三个以上步骤操作同一个对象、或者出现注释分段标记。碰到这些情况我会主动在注释里写拆分点比如# 第一步解析输入参数 # 第二步组装查询条件 # 第三步执行查询并格式化结果然后让 Copilot 把每个步骤写成一个独立函数。这样既保留了 vibe coding 的速度又不会产生一个需要花二十分钟读懂的怪物函数。这个习惯养成以后回头再看之前直接生成的代码确实会有种当时怎么能这么写的感觉。7. 一些反直觉但实际有效的建议不要盯着 AI 写代码。很多人在 Copilot 生成代码时会盯着屏幕等它蹦字这样反而会把你的注意力锁在低层次的代码细节上。我的习惯是把大块任务交给 Chat 生成时切出去看文档或整理思路过一会儿回来看结果。行内补全也不盯着逐字看而是等它给出推荐的整段代码后用快捷键接受。减少注视 AI 动作的时间是进入 vibe 状态的重要方法。不要把所有功能都交给 Copilot。有些代码自带高风险标签我会手动写涉及数据迁移和删除的脚本、涉及金额计算逻辑、涉及权限判断的核心代码。这类代码未必复杂但其正确性至关重要而且出错后的排查成本远高于手写成本。vibe coding 不是把所有代码都甩给 AI而是把合适的那部分交给 AI。尽量把文件控制在百行以内。Copilot 的上下文理解能力和文件长度成反比在超长文件里它的补全准确率明显下降。如果你的功能需要堆到四五百行先别急着写拆成多个模块、多个文件。这个建议不只是为了 Copilot也是为长期可维护性考虑。文件短了AI 给出的建议天然就更准这是一个正反馈循环。给指令文件定期做维护。我之前把 instructions 文件写好后就不管了直到有一次发现 Copilot 还在用几个月前某个已经废弃的库的导入方式才意识到约束需要跟随项目演进。现在每次一次重构技术栈或统一风格时我都会顺手更新指令文件里的对应条款。这个维护成本几乎为零但能保证生成质量不随时间衰减。8. 关于 vibe coding 的边界感回到开头说的飞行员比喻。这一整套实践走下来我最大的体会是vibe coding 并不存在一个用对了就起飞、用错了就完蛋的开关它是一场持续在做的判断练习。你判断的核心问题永远只有一个这段代码的正确性容易验证吗如果容易验证比如纯工具函数、数据转换、接口模板那就放心交给 AI它的效率远胜于手动写。如果正确性很难验证比如涉及资金、权限、状态变更的关键逻辑那就算 AI 能写得更快我也会选择自己来。Copilot 加 VS Code 是我目前用下来顺手程度最高的组合但工具会迭代、模型会升级真正值钱的不是某一款工具而是你围绕工具建立的那套流程。流程可以让一个普通工具产出稳定可用代码也可以让最强工具产出一堆不可维护的垃圾。希望上面这些实践对你建立自己的流程有帮助。如果再有人问 vibe coding 有什么用我的回答是它能把你从键盘前解放出来让你更像一个设计师而不是一个打字员。但前提是你要知道自己在设计什么。