现在是 2026 年 5 月份。vibe coding 的概念快出来一年半了。而距离笔者首次使用 ai 进行辅助编码，也已经过去接近 5 年 (2021.07 ~ now) 的时间。从最开始的 tab 补全，到基于 chat 生成的 code snippet，再到现在看似全流程的 coding agent，AI 辅助编码的能力已取得长足的进步。
有人认为 AI 是 bullshit，只是在生产重复的垃圾，也有人声称 AI Agent 完全接管了自己的工作流程。颇有速胜论与速败论的感觉。当然，在生产 AI slop 成本接近于 0 的当下，如果不是做文化舆论传播研究，去纠结这些，似乎也已经失去了价值。即使争议不断，但是大家也都基本同意，AI 的确将一些重复性的编码工作消灭了。it's really do some works.
PS: 笔者对 AI 属于二线尝鲜党。当一个新产品 / feature 被推出的时候，并不会着急去体验。往往会等上半个月到 3 个月不等，才会开始尝试了解。毕竟产品和 Feature 太多太多，而人类的注意力又太过有限（haha。如果过了时间，声量也降下来了，可能就不会再投入关注了。
本文结合笔者的 vibe 经验，试图回顾一下遇到的问题、引入解决方案。
AI 辅助编码发展概览#
虽然才短短几年，但 AI 辅助编码的范式已经换了几轮了。那就在此做一些简单回顾吧。
tab completion#
笔者最初接触 ai 辅助编码是在 2021 年 7 月，也就是 GitHub 推出 GitHub Copilot technical preview 的时候。现在回想，很容易误认为是两个时代，但实际上看看时间，也仅仅不到五年而已。
那时候笔者还没听说过 gpt。对于初次接触 TabCompletion 的笔者而言，copilot 的效果非常惊艳，整块整块的代码补全，写好注释然后稍加等待，很快就能看到质量不错的代码。Tab 的整体接受率也是比较高的，尤其是在写 boilerplate 的时候，对于那时候作为学生且仍然需要写大量 boilerplate 练习的笔者，确实给笔者带来了极好的体验。
但是缺陷也是很明显的。tab completion 对于业务代码的帮助不大，尤其是早期 ide plugin 还存在不少 bug 的情况下，经常会出现 tab completion 候选代码与 IDE 自身的补全能力冲突的情形。这时候的体验就不太好了。but it's fair. 从外部视角来看业务知识本就乱如麻团，短视的手工代码匠（笔者）也未曾奢望其真能解决这些问题。nothing to complain, it's better than nothing.
chat snippet#
时间来到 2022 年 12 月，在笔者等一众普通人的眼里，chatgpt 横空出世，技惊四座。在那个新闻上 AI Chat 产品一只手数得过来的年份，笔者也是第一次体验到了 amazing 的感觉。一次非常随意的 chat，能根据话题内容进行具有关联性的回复，并进行适当的展开，它好像真能在一定程度上理解问题，并给出带有一些有效信息的回复（虽然这些信息往往被包在大量的车轱辘话中）。其局限性也非常明显，没有实时的知识更新和工具能力，连回答 "今天天气如何这样" 这样的简单问题，也做不到。（要知道，各家的语言助手也能凭借着有多少人工，就有多少智能的工人智能完成这样的任务🤣）。
尽管其实时能力存在缺陷，但对于大部分具体的问题，不那么实时的知识也够用了，毕竟人类千百年来沉淀下来的知识，还是非常有价值的。在这种情况下，提问的效果就很依赖问题给出的上下文。于是问题就变成了，“如何提出一个好问题”，aka. 提问的智慧。
好在这个缺陷很快就被 tool use / function call 补齐了
于是 RAG 和 prompt 工程占领了热点。timeline 上开始堆满 langchain, prompt 技巧这样的词。开始尝试告诉模型更多的领域知识，给出更明确的要求，期望模型能够给出更符合期望的输出。相对来说，这还是非常有效的。通过给出更为详细上下文、领域知识，模型确实可以开始做一些业务代码了，而且在 MVP 级别的 repo 中，表现得还相当不错！
但随之而来的就是知识库切分不当、召回顺序错乱、模型忽略检索结果的工程难题，以及模型上下文大小的硬性限制。导致即使有再多业务知识，也无法避免选择性遗忘，尤其明显的是捡芝麻丢西瓜式的选择性遗忘。
有人开始探索结构化 prompt 以一种更好的方式为 large language model 提供更为详尽的上下文。换句话说，在 prompt 中。
这称之为 Prompt Engineering
但是当要提供的内容越来越多的时候，单纯靠结构化 prompt 已经无法满足需求了。
chat assistant in editor#
仅仅在网页中 ask then copy & paste 显然是不符合工程师的便捷美学的。没过几个月，一系列 ide extension 就如雨后春笋般冒了出来，试图将这种的体验内置到 ide 中（cursor 则走了另外一条魔改 vscode 的路）。
这种深度集成使得提供代码上下文的能力更方便了，编码者也不再需要手动复制到网页代码、重复描述目录结构、解释项目约定，再把答案搬回 IDE 了。但在模型上下文长度的硬性限制下，再多的工程手段也显得有些苍白，问题在于，在一个 repo 中，提供什么样的上下文，提供多少上下文。一时间这成为工程难题与热点。
经过很长一段时间的工程探索，相关产品开始引入越来越多的工程手段，试图提供完备的上下文，比如打开的文件、选中的代码、项目索引、相关文件、编辑历史、diff、terminal output、rules，这些都可能被纳入上下文。而另一边，模型上下文长度与模型能力也在稳步增长。给出的代码效果也越来越符合要求。
在这样的双重作用下，ai 辅助编码的效果也的确有了显著的增长，不再局限于 MVP 级别的 repo。开始承担更多生产级别的任务。
coding agent#
但这还不够。既然编码效果达到了可以接受的水准，那么下一个问题自然就是规模化了。如何减少人为介入呢？
如同十几个月前 IDE Chat Assistant Extension 那般，一系列 Agentic CLI / IDE 开始批量冒出来。agent loop 开始进入舞台中央。借鉴人类维护大规模软件的工程经验，引入读、写、测的反馈循环。这一套循环从单文件，到多文件，再到多任务，多需求。上下文需求与模型能力稳步增长。loop 也越来越长。
context engineering 也进一步演进到了 harness engineering.
但是，模型能力的增长仍无法满足上下文需求。我们仍然面临着上下文不充分与不准确的矛盾。
因此上下文管理，还是需要弄清楚 deep dive 到 agent loop 的.
人工越少，人工越多。
Agent Loop 如何运作#
上下文管理#
我们有太多太多隐性知识了。有些信息隐藏在结构中，有的信息则是以 “通识” 的形式存在。
人可以依赖的不只是符号，但是另外难以用 符号表达的部分，往往只能被笼统的概括为 taste，
凭借着经历堆叠出来的 taste，让人觉得，应该怎么做。
比如 调光，
但是，AI 的问题，很可能与我相似。缺少 taste。
如果我进行深入思考。
全栈
大纲
AI 辅助编程的发展历程
- tab 阶段
- chat snippet 阶段
- agent 阶段
AI 编码的不同阶段面临的难题 - 当前知识库管理 / 上下文管理
- 领域知识
- 世界知识
Agent Loop - what it does.
- how, why.
AI 编码在不同领域的表现差异 - 安全
- 业务开发
- infra 开发
如蜜糖般甜腻，却又具有快乐水清爽。
于是，岌岌可危。
如果，这是一件工艺品。
我是个技术消费者，编码是存在乐趣的。
也许是在成长过程中，我所能掌控的事物并不多，所以我非常痴迷于这种感觉。
用 jyy 的话来说，
It's do really works.