大家好，我是 Kirk Lin。今天，我想带大家回到 AI 编程的"黎明时代"，聊聊我的AI coding故事。
那是在 AI Agent 和各种智能编程软件诞生之前，我们手中唯一的工具，就是 GPT-3.5 Pro 的对话框。回看现在，AI 编程似乎已是寻常事，但当时，每一步都是在黑暗中摸索。这段经历塑造了我对 AI 协作最核心的认知，也让我更加确信，再强大的工具，也无法取代清晰的思路。
故事的开始，和其他开发者一样，我被 AI 生成代码的速度所震撼。但兴奋感很快退去，现实的骨感接踵而至。那时的模型，远没有今天的创造力，它更像一个学徒，最擅长的是 "照猫画虎" 。你给它一段结构清晰、逻辑严谨的代码，它能模仿得惟妙惟肖；但如果你给它一堆杂乱无章的需求，它返回的同样是一团乱麻。
我很快意识到，指望它独立创造出完美的代码是不现实的。我们之间唯一的桥梁，就是那个简陋的对话框。我的日常工作：在 IDE 里写好一段代码作为"范例"，复制，粘贴到对话框里，然后用自然语言描述我的下一步需求，等待 AI"照猫画虎"，再把结果复制粘贴回 IDE。整个过程充满了重复劳动，效率提升非常有限，但即便如此，它依然能为我减轻一部分心智负担。
后来，GitHub Copilot 出现了。他将 AI 直接集成到了代码编辑器内部的工具。它更像一个"超级自动补全"，会在你打字的时候，实时地预测并推荐接下来可能的单行或多行代码。很多人为之欢呼，但我尝试后，却感到一丝失望。它确实能在代码编辑器里提供建议，但对我而言，它打断了与 AI 深度沟通的流程。我失去了通过一轮轮对话，把复杂上下文逐步"喂"给 AI 的能力。Copilot 就像一个只能零散回答问题的助手，并且只能专注于当前的代码文件，而我更需要的，是一个能跟着我的思路、完整理解一个复杂任务的伙伴。因此，我宁愿坚守那个原始的、手动的对话模式。
正是这段看似"原始"的经历，迫使我回归到了编程与LLM的第一性原理。我发现，AI 能否生成高质量的代码，几乎完全取决于我提供给它的"猫"（范例）画得有多好。如果我的代码结构混乱、职责不清，那么 AI 模仿出来的"虎"也必定是四不像。
这个发现让我醍醐灌顶：要想让 AI 成为一个好的开发者，我自己必须先成为一个更好的架构师。
我开始在每次与 AI 对话前，花更多时间去思考代码的结构。我会先定义出清晰的层次、独立的模块和明确的接口。我把一个大任务，拆解成一个个极小的、职责单一的代码块，然后将这些代码块作为"完美的范例"交给 AI，引导它完成后续的填充和扩展。结果是惊人的，AI 生成代码的准确性和稳定性大幅提升。
原来，AI 的"模仿"特性，成了一面放大我代码质量的镜子。它逼迫我写出最干净、最易于理解和维护的代码，因为只有这样，AI 才能读懂我的"意图"，并给出正确的反馈。
当然，无休止的复制粘贴最终还是消磨了我的耐心。既然市面上的工具不能满足我，那我为什么不自己创造一个？于是，我开始构思并着手编写一个 IDE 插件。我的思路很简单：将我那套手动的、基于对话的 AI Coding 流程自动化。我希望这个工具能帮我管理上下文，能将我的架构意图更高效地传递给 AI，把我从重复劳动中解放出来。所以我的插件可以很方便的帮我收集代码片段。保存到一个会话里面。然后直接给AI参考。
回望那段在 AI 编程"石器时代"的探索，让我深刻理解了人机协作的本质：AI 不是魔法，它是一个能力放大器。 它的上限，取决于我们的思路和我们为它构建的框架。
后来，像 Cursor 这样的工具也应运而生。说实话，Cursor 刚出来的时候并没有打动我。原因很简单，它的核心功能和我自己写的那个粗糙的 IDE 插件太像了，用起来远不如自己的工具顺手。我依然沉浸在自己创造的工作流里，享受着那种掌控一切的感觉。
直到 Cursor 推出了一个让我无法拒绝的版本。它开始支持索引一整个代码仓库，这意味着 AI 的视野不再局限于我手动"喂"给它的几个文件，而是能够理解整个项目的脉络。它可以直接对整个项目进行分析和修改，在编写新功能时，会主动考虑到其他模块的实现。这是一个质的飞跃，是我个人插件无法企及的高度。我意识到，单打独斗的时代结束了，我必须拥抱更专业的工具。于是，我开始尝试将我的整个工作流，逐步迁移到 Cursor 上。一个叫 "Vibe Coding" 的概念也开始流行，
但新的问题也随之而来。尽管有了索引，当时大模型的上下文长度依然是极其有限的。对于中大型项目来说，哪怕只是索引核心部分，也很容易突破模型的上下文天花板。我常常在一次对话的中途，眼睁睁地看着 AI 因为上下文溢出而"失忆"，开始胡言乱语，之前的所有努力都付诸东流。
这个瓶颈，再次将我逼回了原点，让我重新思考那个最根本的问题：到底什么样的代码，才是对 AI 最友好的？
答案，几乎是瞬间从我过去的经验里浮现出来的。我想起了我曾经在"屎山" MVC 项目中挣扎的日子，想起了我后来在多个项目中实践的整洁架构、六边形架构和 DDD（领域驱动设计） 。我豁然开朗：这些架构的核心，不就是通过分层和依赖倒置，将最核心、最稳定的业务逻辑（领域层）与外部易变的技术细节（如数据库、UI）隔离开来吗？
这不正是解决 AI 上下文问题的完美方案吗！
这里考虑到阅读文章的受众可能没有接触过"整洁架构"这类概念，我用一个比喻来解释一下。一个大型代码库就像一座巨大的图书馆，如果毫无章法，那 AI 就像一个第一次进去的访客，为了完成一个任务（比如"写一篇关于历史的论文"），它不得不在成千上万个书架间到处乱翻，很快就会把脑子塞满，忘记自己最初要干什么。这就是上下文溢出。
而整洁架构 ，就相当于为这座图书馆建立了一套先进的中央索引系统 。它把图书馆清晰地划分为核心的"文学典藏区"（也就是领域层，存放最关键的业务规则）和外围的"工具阅览区"（存放数据库、UI等具体技术）。当你给AI一个任务时，这套索引系统会立刻告诉它："你这次的任务，只需要参考'典藏区'第5排书架上的资料就足够了，其他地方你暂时完全不用管。"这样一来，AI的"检索范围"被极大地缩小了。
在一个分层清晰的架构里，当我需要实现一个业务功能时，我根本不需要让 AI 去理解整个项目的所有细节。我只需要把"上下文"压缩并限定在最核心的领域层 (Domain Layer) 。我可以先让 AI 聚焦于领域模型的构建和用例（Use Case）的实现，这一步完全不涉及任何数据库或框架代码，上下文的消耗极小。当最核心的逻辑完成后，我再让它去实现外围的接口适配和数据库持久化。
通过这种方式，我将一个庞大而复杂的问题，拆解成了数个各自独立、职责专一、互相之间牵连很少（也就是我们常说的"高内聚、低耦合"） 的子问题。架构，在此刻成为了 AI 的"记忆宫殿"，让它能在有限的"脑容量"里，精准地完成复杂任务。
这个发现，是我 AI 编程之路上最重要的一块里程碑。从那一刻起，我做出了一个决定：我开始坚持不自己手写一行功能代码，纯粹依靠 AI Coding 来完成开发。 因为我已经找到了驾驭这匹烈马的终极"缰绳"，那就是架构。我的角色，也彻底从一个"程序员"，转变为一个与 AI 对话的"架构师"。
而要胜任这个新角色，光有蓝图还不够，我还需要一套精良的"预制件"。巧的是，我多年来的一个工作习惯，在此时派上了意想不到的用场------我会沉淀很多代码模板。
在AI出现之前，为了减少重复的劳动，我习惯在每完成一个有代表性的项目后，都花时间将其中通用的部分抽象出来，做成一个开箱即用的代码模板。比如，我做官网首页时，会沉淀下一套包含常见布局和组件的模板；开发桌面APP时，会整理出一套跨平台的脚手架。日积月累，我一共整理了十几个这样的代码模板，并且把它们全部免费开源了，覆盖了从桌面端APP、移动端，到网页插件、小程序等常见的应用开发需求。
过去，我以为这些模板只是在为后来的"人类"开发者铺路。但当我开始纯粹依靠 AI 编程时，我震惊地发现，这些模板对 AI 来说，是远比零散代码片段更宝贵的"上下文"。
当我开启一个新项目时，我不再需要花费大量时间和 AI 讨论项目的基本结构、技术选型和编码规范。我只需要选择一个合适的模板，然后对 AI 说："基于这个模板，我们来开发XX功能。"
AI 瞬间就能理解整个项目：它知道文件应该放在哪里，代码应该遵循什么风格，甚至连部署脚本都已经为它准备好了。这些模板，就像一个预设好的"沙盒"，为 AI 提供了一个完美的、零偏差的起点。它不再需要猜测，只需要在既定的、高质量的框架内进行创造。
这时我才意识到，我无意中早已在实践上下文工程 (Context Engineering) 的核心技巧。如果说，整洁架构是通过"分层"来压缩和聚焦AI的上下文，那么代码模板就是通过"预设"来初始化和稳定AI的上下文。两者结合，为我的AI Coding工作流打造了一套坚固的"轨道"，让这列高速行驶的列车，既能跑得飞快，又绝不会脱轨。
当我自己的工作流逐渐成熟后，一个念头开始在我脑海里盘旋：这套方法论是个人的"独门绝技"，还是可以被复制的"普世之道"？于是，我开始尝试把这个方法推广到身边的朋友。我前后教会了五六位朋友，他们背景各异，有老师，有学心理学的，大部分都不是计算机科班出身。我没有想过卖课，对我来说ROI太低，我更享受这种纯粹的分享，看着他们用新的思维方式创造出自己的作品。令我惊喜的是，他们都掌握了其中的精髓。
在教他们的过程中，我被迫把我那些零散的感悟，总结成了更清晰、更具普适性的原则。
我教给他们的第一课，永远是 "拆解" 。这套习惯的源头，可以追溯到敏捷开发。我们做一个复杂的购物车功能，绝不会妄想一次性开发完所有功能，而是先上线最基础的结算，再迭代移除商品、降价提醒等。这个将大目标拆解为独立小模块，小步快跑、持续迭代的过程，与计算机科学里的分治算法思想不谋而合。
分治算法就是将一个大规模的问题，递归地分割成足够小、易于解决的子问题，最后再将子问题的解合并起来。我所做的，正是不断将一个宏大的开发目标，拆解成 AI 能够清晰理解并执行的"子问题"。
我们的核心工作，就是为AI Agent规划好一个清晰的TODO list ，而我们的每一个指令，就是这个list上一条足够小、足够精确的SOP (标准作业程序) 。当AI清空了这个列表，我们的最终目标也就达成了。
当然，Vibe Coding 并非万能的银弹。清醒地认识它的边界，是用好它的前提。
千万别指望它在所有场景下都能大杀四方。比如，你想在整个代码库里做一次全局的变量重命名，这类需要 100% 准确性的任务，从本源上就不是 LLM 这种概率生成器的强项。老老实实用 IDE 的重构功能会靠谱得多。但这里也有更聪明的协作方式：让 AI 为你写一段执行重构任务的脚本。你看，我们利用 AI 的生成能力，去创造一个能完成确定性任务的工具，这才是真正理解了它的长处。
随着我在这条路上越走越深，一个更为巧合的发现让我感到兴奋：这套源于敏捷开发和分治思想的工作流，竟然又与精益创业中的MVP（最小可行产品） 理念不谋而合。我们不再追求一次性构建一个庞大而完美的系统，而是通过快速迭代，用最小的代价验证核心想法，然后根据反馈调整方向。AI，恰恰是实现这一理念的史无前例的强大引擎。
这也让我开始重新思考，在 AI Coding 时代，我们"程序员"的角色究竟会发生怎样的变化。或许，单纯执行编码任务的"程序员"会慢慢减少，取而代之的，是更多懂 Coding、懂产品、懂设计思维，甚至懂领导力的新型复合型人才。
我们终于可以从繁琐的"语法糖"和"样板代码"中解放出来，回归编程最核心、也是最有意思的地方------解决问题的能力 。未来，重要的将不再是你掌握了多少种编程语言，而是你解决某一类型问题的深度和广度。在这个新范式下，设计思维，这种以人为本、定义问题、构思解决方案的综合能力，将变得前所未有的重要。
因为当每个人都拥有了近乎无限的"实现能力"时，最终决定胜负的，将是你的洞察力、创造力，以及定义那个"值得被解决的问题"的智慧。