AI
提出问题
- 对 AI Coding 的个人理解
- AI Coding 的个人最佳实践
- 概括一下平时用 AI Coding 的工作流
- 用过哪些 AI IDE ，有什么差异
- 对 AI IDE 中 Agent 的个人理解
- 对 AI IDE 中 MCP 的个人理解
- 是否了解 AI IDE 中 Tab 补全模型及其原理
- Collector(信息收集) VS Creator(生产作品)
关于 Vibe Coding
AI 并不会解放不会写代码的人，而是极大放大会写代码的人的生产力。
所谓 Solo Builder 的神话，本质是对工程复杂度的嘀咕，是噱头。
关于 Vibe Coding 的本质判断，从需求文档直接生成完整应用在工程上不可成立，包括 Cursor，ClaudeCode。
真实需求不可穷举，存在大量隐形需求，边界条件，长期维护问题。大模型对长上下文 + 系统级约束天然不擅长。
因此，端到端自动生成，只能极简场景 Demo 级别成立，一句话生成完整产品是伪命题，不是时间问题，而是系统复杂性问题。
有且仅有程序员能驾驭好 Vibe Coding，为什么不懂代码的人用不好 AI，因为 Prompt 不等于需求表达，非程序员往往用自然语言描述却无法描述结构，约束，状态，性能目标。例如一个简单需求的 UI 设计：布局模型，响应式规则，边界情况，状态同步，前端程序员能使用前端语言把问题说清楚，AI 才能对症下药。
Vibe Coding 的真实问题，AI 生成的代码能跑不能用。常见问题如：
- 不考虑长期维护性
- 性能和资源消耗失控，如上下文，token，请求体。
- 可观测性、报警
- 拓展性
- 安全性
没有工程判断力的人，无法为 AI 的代码兜底。
正确的人机分工方式可以是
- 人决定：架构，边界，裁剪空间，判断什么该做，什么不该做
- AI 在约束范围内搜索解，执行复杂型，局部型任务
AI 真正擅长的代码类型是一次性代码，适合交给 AI 的例如小脚本，Demo，单元测试，工具代码，简单函数
AI 不适合处理的如核心后端服务，性能敏感系统，复杂状态机，长链路推理，多模块一致性系统
原因是，AI 的奖励函数偏向于输出正确而不是长期可维护。
因此复杂系统拆解能力，架构审美能力，知道哪些架构好维护，哪些技术难以维护，以及清楚认识到 AI 的能力边界，进而给 AI 设置边界，这些能力显得更加重要。
为什么对 AI Coding 高度夸赞和担心失业的人中前端从业者居多
后端链路长，很多地方 ai 触摸不到。如果简单的项目，一个服务，一个数据库能完事，ai 也可以替代。
确切的说, 应该是 半吊子新手/外行人 和 用 AI 做了个技术栈外的东西就觉得自己行了的老手。高度夸赞在于对 AI 没有要求，AI 生成的东西表面上看的过去他们就满足了.
当你有明确要求, 比如真商业项目, 把需求梳理的清晰的文档丢给 AI, 生成个四不像, 还磨洋工折腾一两小时没修好还嘴硬的 AI 专属时刻也多的是
跟前后端没啥关系，业务关联性不高的，重复性的工作岗位基本都会被波及
前端观感上看起来会多一些，很大一部分是因为前端娱乐圈的属性就是喜欢各种发帖曝光。
排除掉这部分增加曝光的属性。前端觉得好用是因为复杂业务少，大多数场景下完全不需要去了解实际业务也完全可以做。即使稍微有一些小瑕疵也不影响使用。
当然也有很多人仍在坚持古法编程。
但你会发现，绝大多数生成的作品都是 "一次性原型或玩具"：灵光一现即可实现，却缺乏持续迭代、架构设计与用户验证，因此难以具备商业价值、也难形成可持续的产品形态。
真正能够利用 Vibe Coding 实现变现的，往往是具备一定 编程经验 或 产品思维 的 "专业人士"。
他们不仅能用 AI 快速实现灵感，还能对作品进行持续优化、迭代和工程化打磨，从而将 "灵感原型" 进化为 "可用产品"
AI 不会让没有积累的人"平地起飞"，但有可能让有准备的人"一飞冲天"。