写在前面
从2025年9月至今，算算已经很久没有认真写过博客了。如果说忙，确实忙，工作强度比之前翻了好几倍；说懒，似乎也不太准确——主要是我迷上了Vibe Coding，一不留神就沉浸其中，难以自拔。
这一年AI发展实在太迅猛了，短短一年间，效率提升肉眼可见。有一段时间，我甚至一度以为，以后可能再也不需要自己学习技术细节了，博客也不用记了——反正AI都能代劳。
然而用得久了才明白，不行，该记还得记，该学还得学。原因很简单：你脑子里的认知决定了你眼中LLM的能力边界。巧妇难为无米之炊，这句话一点没错。
还有一个老生常谈的问题——你必须想清楚，哪些能力是你自己的，哪些是平台赋予的。AI平权之后，你自己的价值到底在哪里？这个问题，值得每一个还在使用工具的人认真思考。
这一年发生了什么？我做了什么？
2025年初，我第一次接触Vibe Coding是从Cursor开始的。给我的感觉是眼前一“新”——注意，不是“亮”，而是“新”。为什么这么说？因为它做的事情，说白了就是把从百度搜答案、从Chat Agent复制结果的过程简化了，仅此而已。那时候的Cursor，也不过是Agent、Ask、Manual这几项功能。
在一知半解的状态下，我在DJJ的引导下参与了CodeLf的编写，开始记录每次改动的changelog、项目简介、编码规范，目的就是为了让Vibe Coding更高效。也是那时候接触到MCP的，知道了这套规范可以统一各个模型调用工具的方式，相当于让模型有了手和脚。
到了2025年6月，在前司遇到一个略显笨拙的需求：官网只有PC端，没有H5端。等H5做完了，又反过来要求PC端做移动端适配——太反人类了。
当时我在想，怎样才能尽可能复用代码，不至于在适配移动端时完全手写一套重复的轮子。于是干脆在根目录下创建了一个叫h5的目录，把所有移动端页面代码放进去，封装了一个composition hook，在route配置和App.tsx中做了相应处理，通过媒体查询渲染两个不同的文件入口。说白了就是两套代码，顶多算是响应式。关键是，我把这个想法交给Cursor，它真的完整实现了这套方案，而且肉眼可见地把这个需求的工作量降了下来。
尝到甜头了。
同年同月，桌面端应用需要重构，从老旧笨重的C#客户端换成Electron。这是个完全陌生的领域，文档翻完就忘。以往的经验告诉我，上手最快的方式从来不是啃文档，而是模仿——先做出一个demo，看到效果，才能更直观地理解它的作用。
先走起来，再说跑的事。Cursor帮我走了这条捷径：写完一个页面，自己仿照着改造出其他同类页面。就这样，我居然对以前一听就头大的IPC通信、本地化数据库、自动化启动配置这些东西有了探索的欲望，也开始觉得它们并不是那么遥不可及。
其实从这时候开始就有个苗头了：动手做得少了，想的事情多了。我开始花更多时间在CI、架构编排、代码复用这些方向上。
2025年7月14号，亚马逊推出了Kiro，我是首批体验者。这次才是眼前一“亮”——它推出了spec模式：先出文档、todo，然后才coding。这个模式让Vibe Coding终于有了章法可循。事实证明这也成了后来的主流，各家厂商陆续推出了plan模式。
也是这段时间，我认识了云中江树，才发现原来提示词还有这么多门道。rule里面我加入了角色设定、技术偏好、注意事项等，一时间确实帮了大忙——LLM理解上的歧义减少了，我自己的表达也更条理清晰了。
合理的分段、引用、重点标注、分隔符——这些东西确实能有效提升提示词的质量，也能让我们自己的表达逻辑更清楚。一句话总结：书面表达的时候，怎么让人看的成本最低，提示词就怎么写。这就是所谓的Prompt Engineering（提示词工程）。
9月份，我参与了resumePolice项目，几套提示词搭载在dify上做简历优化。难以置信的是，它最终收获了2.2k星。效果确实也还可以，让我更深刻地意识到提示词的重要性。
这时候开始接触Claude Code了。但作为一个常年在VSCode里混、井底之蛙的前端，对命令行CLI多少有点生理性抗拒，浅尝辄止，草草用了一下就放下了，没用到深层玩法。
那时候的模型能力已经很强了，但是不稳定，频繁在Gemini 2.5 Pro、Sonnet 3.5、Opus 4.1之间切换。当Vibe经验还不够的时候，遇到问题我们总是习惯性地怪模型——当然有一部分原因是模型，但绝不是全部原因。具体后面单独开章节说。
到了11月，Google Antigra vity推出，好评一片。虽然它没推出什么全新概念或功能，但光靠plan迭代模式和顶级模型的量大管饱，实在太香了。一度让我沉沦其中。结果2026年3月中下旬，用量限制来了，它把自己唯一称道的优势给砍掉了。
ok，吃饱了骂厨子的事不多做。考虑到Google生态下的Gemini DeepResearch、NotebookLM这些功能确实不错，我还是保留了每月20美元的One Pro订阅。事实也证明，它确实给我带来了帮助。
总之，2025年是Vibe Coding元年。这一年涌现了太多AI概念：Vibe Coding、Prompt Engineering、Context Engineering、Agent、MCP……数都数不完。
Context Engineering
前面提到了Prompt Engineering（提示词工程），接下来要说的是Context Engineering。Plan模式的推出，让我深切体会到，开发体验的重心明显从编码往需求描述转移了。
模型能力越来越强，需要的不再是用什么技术去实现，而是如何让LLM清楚地知道它要做什么。
回想一下传统开发流程里的几个常见且不可跳过的场景：
case1：新项目
需求澄清 -> 产PRD -> 确认细节 -> 技术调研确定架构、设计 -> 任务拆分 -> 编码 -> 测试。这套工作方式在Vibe Coding里仍然适用。
case2：迭代新需求
需求澄清 -> 产PRD -> 确认细节 -> 了解熟悉现有设计 -> 技术调研确定架构、设计 -> 任务拆分 -> 编码 -> 测试。同样，这套方式仍然适用。
case3：接手新项目
读代码、读配置、看架构。
总结下来就一句话：在开始编码之前，我们需要对本次任务有目标、有谱、有迹可循——要完成什么样的需求？在什么样的项目背景下完成？本次要改动哪些文件？目标是什么？
不止一次听到身边人说：“AI老是乱改，还不如我自己写”“太不稳定了，一会儿好一会儿坏”“你怎么知道它写的是对是错”……
这些质疑背后，不排除有模型本身的原因，但更说明了Context Engineering的重要性——它正是在规避和削弱这些现象的有效手段。
推荐的工作流是这样的：和Gemini沟通具体plan的时候，我会让LLM进行反问，让它挖掘并引导解决需求中所有不明确或者存在风险的点。习惯性在结尾加上一句“你还有哪些不清楚的地方需要确认？”
和Gemini沟通时，我还会要求它帮我做需求评估，设计方案。遇到没接触过的复杂场景，会调用DeepResearch做深度调研，看过报告后如果觉得可行，再让Gemini总结并重新评估。甚至，有时候我直接让它帮我生成喂给其他LLM的提示词。
可以分享一篇与Gemini的对话记录——从选题确定、UI风格确定（UI提示词）再到Coding提示词的生成，完全让Gemini生成，互相引导，效果并不差。
其实很多东西是自然而然的，不是凭空出现的。当你不停Vibe Coding的时候，你会想：
- 如果LLM知道的足够多、足够了解我就好了——于是有了Context Engineering和Memory。
- 如果它能够像人一样去操作浏览器、去读文档、去点击、去执行命令行、去看原型和设计稿——于是有了Function Calling。各家模型接口不一，就有了MCP来实现大一统。
- 如果它能把做过一遍的事情都记住，不用再重新探索一遍——于是有了Skills。
其实我们在追求更好Coding效果的过程中，一直都在不自觉地明确Context。它不是某一个固定的环节，而是贯穿始终的。像最开始调整全局提示词、当前对话的提示词、@具体的文件行数——让LLM聚焦，让它更清楚自己该做什么、如何去做，这本质上就是在精简和优化Context。
Claude Code的Memory体现在Claude.md和Projects（自动记忆的存储路径）上。官方说它很擅长总结犯过的错误并记录下来避免下次再犯——这其实也是在优化Context。
让LLM不要过分信马由缰，我们给它套上缰绳。提示词 + Context + 约束（Skills、Rules）+ 能力（MCP）+ Hooks……这些东西共同构成了Vibe Soc。
上下文窗口不够？各种Agent提供了SubAgent能力，实现协作和分工——分散任务节省上下文，让每个Agent专注于一件事，同步结论汇总，从而解决上下文爆炸的问题，高效完成任务。
对于长任务或复杂任务，我会开启一个单独的Session来做Plan迭代和任务拆分。保存Plan和Task后，再新开一个Session进行Coding。Coding过程中告诉Agent每个阶段任务完成后要留出测试时间。
Coding过程中使用/btw提出疑问。当任务偏离时，直接按Esc指出问题，确认后让它更新Plan，确认无误后再继续开工。
看吧，这世界上从来没有魔法，代码世界里也没有。不过是按部就班的逻辑性发展罢了。
害怕LLM听不懂人话？也怕自己说不清人话？那就描述需求时加上注意：在某某情况下，你不要做某某。再加上示例：脱敏处理 xxx -> x*x。效果立竿见影。
该切的时候就切，永远别把一个上下文窗口用到满。完成一个任务就切，长任务适时/compact一下。上下文一旦爆炸，它的脑容量就不够了——传给LLM的参数远比你的实际Prompt少得多。
当我们处理好了Context，理论上什么功能都能实现。LLM帮你拉高上限，你的上限也同样影响着视角里LLM的上限。一个设计模式或架构的好坏，从外行、行家和专家眼中的评判标准和速度是完全不一样的。
在一个项目迭代里，你的既有认知决定了Agent的上限——如果你只知道for，你就不会想到用forEach、map等高阶函数；如果你只是用习惯了没有去思考去查资料，你就会忽略for的性能更好。
做性能优化的时候，如果没人告诉你，你也没接触过，你可以结合DevTools和Performance来分析。但如果你只从代码层面看，怎么看都觉得合理，怎么也不知道如何优化。
可你要是问AI“哪里可以优化？我需要借助什么工具？需要提供什么资料？”——它可能会给出参考思路，但这取决于它的知识库和训练时间节点。
问也是一门学问。认知决定了你能问出什么样的问题，也就决定了整个Coding的方向、质量和效率。
这才是工程师最根本的价值所在。举个例子——脱敏的性能优化，我用了将近一个月的时间把大数据卡死优化到1分钟，但交互仍然是阻塞的。而从1分钟到10秒，只用了一个下午。像Blur这种小细节就会损耗性能——要不是之前偶然爆出的错误，嘉奇定位到了这个原因，我可能想都不会想到。而且事实证明，LLM也没有提到这方面的优化。
DeepResearch能做的是帮你在深水里调研，找到合适的参考方案，再给出思路。工具是工具，怎么用还是看人。
LLM的“服从”：是概率的退让，而非情绪的觉醒
有个有意思的现象：为什么有时候我们凶一下LLM，它就会“乖”起来？这不是魔法，也不是它有了人的情绪。原因在于LLM的训练结构本就有权重和偏置一说，而情绪本来就是权重的一部分。LLM匹配到一系列结果后，根据权重和偏置综合决定取用顺序。这也充分体现了提示词和Context的重要性——至少在现阶段的架构下，就是这个样子。
据说，LLM也害怕“杀人犯”之类的字眼？
这段话是我通过一些资料产生的个人理解，不够专业也不完全准确。之后我把它拿去问了Gemini，它帮我做了优化——你看，AI的工具性就在这里：它不是万能钥匙，但它可以帮你把碎片化的理解整合得更系统。
AI已经把获取知识、搜集知识的成本拉得极低。但前提是——我们能问出什么样的问题？它并不会像一个活生生的人、一个老师一样主动给你传道授业。这就是最开头我们说的：持续学习、持续记录，这个习惯不能丢。
好的信息获取渠道和一手的资讯，是目前最重要的资产之一。
新的问题
新的问题来了：代码质量到底还重不重要？
本着负责任的态度和降低维护成本的角度来看，当然重要。但从现象来看，其实我们更关心的是“别出问题”，而不是“代码好不好看”。可这本身就是一个悖论——不出问题，往往恰恰要依托于代码质量。
LLM确实很强，但远远没有强到完全自动化的程度。大型项目、复杂应用下，依然需要真正有从业经验的人去Review。这也是短期内工程师存在的理由。但必须承认，AI确实带来了效率革命和能力边界的突破——所以以后，可能真的越来越不需要传统意义上的“工程师”了。
但这个“不需要”的背后，是工程师需要主动进化：从会写代码，变成会问问题、会定义问题、会引导AI解决问题的人。
这才是未来竞争力的核心。
