Linux.do论坛一篇技术文章指出，随着项目从Demo级向工程级演进，AI辅助编程（Vibe Coding）暴露出明显瓶颈：AI缺乏大局观，在修复Bug和功能迭代中倾向打补丁，导致架构腐化、注释沦为变更日志，项目陷入’局部最优’引发的全局熵增。Plan模式生成的蓝图在V1.0之后迅速失效。作者认为问题本质在于喂给AI的信息密度过低——大量源代码挤占有限的上下文窗口，真正的工程意图反而被稀释。为此，文章提出’影子架构’方案：在项目根目录建立.blueprint目录，与src/严格镜像，以高密度Markdown文档记录模块的职责契约、接口摘要和依赖拓扑，充当面向AI的’符号表’，使AI用约200个Token即可理解一个模块的定位。工作流上倒置Source of Truth：AI接到需求后禁止直接扫描代码，须先检索蓝图定位架构归属，再由Architect Agent在文档层进行沙盘推演与更新，人类Review蓝图变更后，最后一步才将蓝图’投影’同步为代码。作者规划了名为The Vibe Compiler的落地工具，借助Claude Code以Prompt as Code方式注入蓝图索引、架构演进、意图实现三阶段思考链，并辅以蓝图生成、依赖可视化和上下文聚焦三个脚本。文章将其类比为汇编时代引入C语言：AI时代代码成为新的汇编语言，需要以’意图语言’管理AI行为，程序员角色转向’状态管理者’。
事件分析
该构想的看点在于将’文档优先’推向极端：蓝图成为唯一真理源，代码退化为可再生的投影。这与业界已有的规范驱动开发、Cursor Rules、CLAUDE.md等实践方向一致，但更进一步主张意图与实现的物理分离。争议点同样明显：蓝图与代码的同步漂移可能成为新的熵源，缺乏自动化一致性校验时，’投影’失真反而会误导AI；高密度文档自身的持续维护成本也不容忽视，’谁来保证蓝图不过期’与原文批评的Plan模式蓝图失效问题形成一定悖论。后续走向上，若作者开源该Skill并沉淀可复用的蓝图格式标准，或能吸引社区跟进验证；长期看，此类架构记忆层思路可能被IDE厂商和Agent框架吸收，演变为内置的工程意图管理能力。
核心观点：AI编程的真正瓶颈不是生成能力而是上下文信息密度，意图与实现的分离或将定义下一代开发范式。
原文链接：Linux.do
