夜雨聆风这组文章想讨论一个正在变得越来越具体的问题：
当前端遇到 AI，软件开发中哪些东西真的变了，哪些只是换了名字？
这个问题不能只靠热点回答。
也不能只靠工具体验回答。
因为 AI 对前端的影响，不只体现在“代码能不能自动生成”。
它还会改变用户交互、产品形态、工程协作、代码审查、状态管理、职业成长和技术判断。
所以这组文章不会只写“某个工具怎么用”。
也不会只写“某个概念是什么”。
更关心的是：
AI 让哪些前端工作变便宜？ 哪些能力反而会变贵？ 前端工程师进入 AI 应用开发，应该先理解什么？ AI 编程工具到底适合什么场景？ AI 应用前端为什么比普通页面更复杂？ AI 产品为什么不能只有聊天框？ 设计系统、权限审计、中后台治理为什么会重新变重要？ 工程师如何在持续变化里建立判断框架？
这些问题比单个工具更慢。
但也更耐用。
01｜这组文章不想做什么
先说边界。
这组文章不打算做三件事。
不做资讯搬运
AI 领域每天都有新模型、新工具、新框架、新融资和新 benchmark。
这些信息有价值。
但如果只追资讯，很容易被节奏推着走。
今天讨论一个 AI IDE。
明天讨论一个 Agent 框架。
后天讨论一个新的 RAG 工具。
看起来一直在学习，实际上没有沉淀判断。
这组文章会尽量把热点放回工程现场里看：
它解决了什么问题？
它把复杂度转移到了哪里？
它对前端工作方式有什么具体影响？
不做单纯工具教程
工具教程可以很有用。
但工具会变。
按钮会变。
模型会变。
交互方式也会变。
如果只写“某个工具今天怎么点”，内容很快过期。
这组文章更关注工具背后的稳定问题。
比如 AI IDE 背后的上下文管理。
比如代码生成背后的 Review。
比如聊天界面背后的任务生命周期。
比如 RAG 背后的来源、引用和可信反馈。
不做大而空的趋势判断
“AI 会改变一切”太宽。
“前端会消失”太粗。
“所有人都要学 Agent”也太急。
真正值得讨论的是更具体的变化：
哪些工作会先被压缩？ 哪些能力会形成新的门槛？ 哪些复杂度没有消失，只是换了位置？ 哪些工程实践在 AI 时代更重要？
这组文章会尽量从这些具体问题出发。
02｜这组文章的核心判断
整组文章背后有四个判断。
第一，AI 会压低低判断密度工作的价格
简单页面、样板代码、相似组件迁移、基础测试骨架，都会变得更便宜。
这不是说它们不重要。
而是说它们不再稀缺。
过去，能快速写出第一版代码是一种明显优势。
以后，这部分优势会被 AI 稀释。
真正要看的是：第一版之后，谁能判断方向、边界、状态、风险和质量。
第二，AI 应用前端不是普通 UI 的轻微升级
很多 AI 应用看起来只是一个聊天框。
但真正复杂的是聊天框背后的任务系统。
用户输入之后，系统可能要组织上下文、检索资料、调用工具、等待确认、流式生成、保存结果，并在失败后恢复。
这些都不是普通页面状态能简单覆盖的。
AI 应用前端的难点不是消息气泡。
而是把不确定的模型过程，组织成用户能理解、能控制、能恢复的产品体验。
第三，AI 编程工具的上限取决于上下文
模型能力很重要。
但在真实工程里，代码是否可用，往往取决于工具是否理解项目上下文、任务边界、历史约定、测试反馈和开发者意图。
没有上下文，AI 只能生成“可能正确”的代码。
有了上下文，才可能生成“适合这个项目”的代码。
所以 AI 编程能力不是简单 prompt 技巧。
它更接近一种工程组织能力。
第四，技术人更需要判断框架
AI 会让信息更多，变化更快，岗位叙事更激烈。
如果只跟着热点走，很容易焦虑。
更稳定的方式，是建立自己的判断框架：
这个技术解决什么真实问题？ 它引入什么工程代价？ 它背后有什么可迁移能力？ 它是否有长期复利？
技术学习不应该只按热度排序。
应该按问题、代价、迁移和复利排序。
03｜整组文章的结构
目前这组文章可以分成四条线。
第一条线：AI 如何改变前端能力结构
对应文章：
01｜前端工程师会被 AI 取代吗？ 07｜低价值前端工作正在消失，高价值前端工作正在变重 12｜工程师如何建立自己的技术罗盘 17｜从写页面到设计系统：AI 时代前端的价值迁移
这条线讨论职业能力和技术判断。
核心不是制造焦虑。
而是拆清楚哪些能力会贬值，哪些能力会升值。
AI 会让低判断密度工作变便宜。
但它也会让需求拆解、状态建模、代码审查、工程治理、体验判断变得更重要。
第 17 篇把这个判断推进到更具体的能力迁移：
当页面实现成本下降，前端价值会更多进入体验一致性、组件治理、设计系统和复杂场景抽象。
第二条线：前端如何进入 AI 应用开发
对应文章：
02｜前端工程师做 AI 应用，第一步不该是学大模型原理 05｜AI 聊天界面的工程细节 08｜RAG、Agent、Function Calling：前端需要理解到什么程度 11｜AI 应用里的状态管理，比传统前端复杂在哪里 13｜做一个 AI 应用前端，真正难的不是 UI 16｜AI 产品为什么不能只有聊天框 18｜AI 应用里的权限、审计和用户确认
这条线讨论 AI 应用前端的实际复杂度。
重点不是模型训练。
而是应用链路。
用户输入、上下文、检索、流式输出、工具调用、确认、失败恢复、可信反馈，这些才是前端最早会遇到的问题。
第 16 篇和第 18 篇继续补齐产品侧和风险侧：
聊天框只是入口，不是所有任务的最佳形态。
AI 一旦能调用工具和执行动作，权限、审计、确认和撤销就必须进入前端体验。
第三条线：AI 编程工具如何进入工程工作流
对应文章：
03｜我用 AI 写一个真实需求 04｜AI 生成代码越强，为什么 Code Review 反而越重要 09｜Cursor 适合什么人？不适合什么场景？ 10｜AI 编程工具的真正竞争点不是模型，而是上下文管理 15｜用 AI 重构代码时，最容易踩的三个坑 19｜前端开发中的 AI 工作流：需求理解、代码生成、测试、Review
这条线讨论 AI 编程工具的真实价值和边界。
AI 很适合明确、局部、可验证的任务。
也很适合生成草稿、迁移模式、补测试骨架、阅读陌生代码。
但它不适合替人理解需求、设计架构、承担质量责任。
工具越强，越需要上下文、约束、验证和 Review。
第 15 篇和第 19 篇把这个判断落到更具体的开发动作：
AI 可以辅助重构，但必须控制目标、范围和验证。
AI 也可以进入完整开发流程，但应该参与需求理解、方案拆分、局部实现、测试补齐和 Review，而不是替代流程。
第四条线：前端工程化在 AI 时代会更重要
对应文章：
06｜一个前端项目变烂，通常不是从技术选型开始的 04｜AI 生成代码越强，为什么 Code Review 反而越重要 10｜AI 编程工具的真正竞争点不是模型，而是上下文管理 14｜前端架构不是文件夹结构，而是变化的组织方式 20｜为什么很多中后台系统越做越难维护
AI 会放大项目已有的工程质量。
边界清楚的项目，AI 能提高效率。
规则混乱的项目，AI 会更快制造局部补丁。
所以 AI 时代不是工程化变轻。
而是组件分层、状态归属、接口封装、权限规则、测试策略和 Review 规则更重要。
第 14 篇把架构问题从目录结构拉回变化管理。
第 20 篇则把这个判断放进中后台系统：难维护往往不是因为技术栈落后，而是规则、权限、表单、表格、流程和复用边界长期没有归属。
第五条线：AI 产品交互如何从 demo 走向真实任务
对应文章：
05｜AI 聊天界面的工程细节 13｜做一个 AI 应用前端，真正难的不是 UI 16｜AI 产品为什么不能只有聊天框 18｜AI 应用里的权限、审计和用户确认
这条线关注产品交互形态。
AI 产品不是把模型能力包进一个输入框。
真实任务需要结构化输入、可编辑结果、可确认动作、可追踪过程和可恢复失败。
这也是前端在 AI 产品里价值变重的原因。
04｜可以按三种方式阅读
这组文章不一定要按编号顺序读。
可以按你的关注点选择路径。
如果你关心职业变化
可以先读：
01｜前端工程师会被 AI 取代吗？ 07｜低价值前端工作正在消失，高价值前端工作正在变重 17｜从写页面到设计系统：AI 时代前端的价值迁移 12｜工程师如何建立自己的技术罗盘
这条路径回答的是：AI 时代，前端工程师应该把能力重心放在哪里。
如果你想做 AI 应用
可以先读：
02｜前端工程师做 AI 应用，第一步不该是学大模型原理 05｜AI 聊天界面的工程细节 08｜RAG、Agent、Function Calling：前端需要理解到什么程度 11｜AI 应用里的状态管理，比传统前端复杂在哪里 13｜做一个 AI 应用前端，真正难的不是 UI 16｜AI 产品为什么不能只有聊天框 18｜AI 应用里的权限、审计和用户确认
这条路径回答的是：AI 应用前端到底复杂在哪里，应该如何建模。
如果你关心 AI 编程工具
可以先读：
03｜我用 AI 写一个真实需求 04｜AI 生成代码越强，为什么 Code Review 反而越重要 09｜Cursor 适合什么人？不适合什么场景？ 10｜AI 编程工具的真正竞争点不是模型，而是上下文管理 15｜用 AI 重构代码时，最容易踩的三个坑 19｜前端开发中的 AI 工作流：需求理解、代码生成、测试、Review
这条路径回答的是：AI 工具怎样真正进入工程工作流，而不是只停留在生成代码。
如果你关心前端工程化和系统治理
可以先读：
06｜一个前端项目变烂，通常不是从技术选型开始的 14｜前端架构不是文件夹结构，而是变化的组织方式 17｜从写页面到设计系统：AI 时代前端的价值迁移 20｜为什么很多中后台系统越做越难维护
这条路径回答的是：当 AI 让生成变快，前端项目如何避免规则分叉、边界失控和维护成本上升。
05｜这组文章想建立的写法
这组文章会尽量遵守几个写作原则。
从工程现场出发
不先问概念是不是新。
先问它解决什么工程问题。
比如 RAG，不只讨论向量数据库。
还要讨论来源展示、未命中、引用对应和可信反馈。
比如 Agent，不只讨论多步规划。
还要讨论执行过程、中断点、失败恢复和用户控制。
把代价说清楚
任何技术都有交换。
AI 编程工具提升生成速度，也提高了上下文管理和 Review 的重要性。
AI 聊天界面看起来只是消息流，实际引入了流式输出、取消、中断、重试和任务状态。
把代价讲清楚，判断才有落点。
把行动路径说清楚
文章不只给判断，也要给下一步。
比如：
如何拆一个 AI 应用需求。 如何给 AI 编程工具提供上下文。 如何审查 AI 生成代码。 如何判断一个新技术值不值得学。
观点如果不能转成行动，就容易变成口号。
结语：把变化放回具体问题里
AI 带来的变化是真实的。
但变化越大，越需要具体判断。
前端工程师不需要被每个新名词推着走。
也不需要把 AI 简化成“自动写代码”。
更值得做的是把变化放回具体问题里：
用户任务怎么变了？ 工程协作怎么变了？ 代码质量怎么保证？ 状态和上下文怎么建模？ 哪些能力能长期迁移？
这组文章会围绕这些问题继续展开。
如果要用一句话概括它的方向：
不是追逐 AI 热点，而是理解 AI 如何改变真实的软件开发。