对 ai coding 高度夸赞和担心失业的，似乎前端从业者居多？

我是后端，我觉得后端也躲不过去。主要是后端链路长，很多地方 ai 触摸不到。如果简单的项目，一个服务，一个数据库能完事，ai 也可以替代。

确切的说, 应该是 半吊子新手/外行人 和 用 AI 做了个技术栈外的东西就觉得自己行了的老手

高度夸赞在于对 AI 没有要求, AI 生成的东西表面上看的过去他们就满足了.

当你有明确要求, 比如真商业项目, 把需求梳理的清晰的文档丢给 AI, 生成个四不像, 还磨洋工折腾一两小时没修好还嘴硬的 AI 专属时刻也多的是.

前端切图仔，也能叫程序员

本来打了好多字，最后全删了，二楼说得对。

跟前后端没啥关系，业务关联性不高的，重复性的工作岗位基本都会被波及。

每一次都是前端被率先拿出来鞭尸

后端主要业务比较麻烦。前段就是功能模块多些。

任何一个现在用 ai 用的特别爽的行业，都容易被 ai 取代。
所以不分什么前后左右端，都要完蛋。

反正逛了一圈中推下来，高潮的来来去去还是那几个人。以我司来说，还是古法编程居多，虽然公司在大力推，但是没人会因为活干得快了就去接更多的活，所以前端人数还是那么多，而且还不够需要砍需求。

我感觉 AI 更适合写后端，业务逻辑好描述，UI 上的改动很难用文字描述清楚

我做为偏后端的全栈，体验上也感觉前端稍微容易 ai coding 一点。分析下来，

1. 前端的提示词更好写，需要调整和修改的地方更直观，可视化，可验证

2. 前端更容易给 LLM 足够的上下文，草图，设计稿，json 数据等等

3. 前端生态更组件化模块化，AI 容易复用

当然后端也一样，简单 CRUD ，接口 Controller ，sql ，单元测试这些一样被替代，但深层业务逻辑不会轻易 AI 化。举个例子，“我想写一个打赏主播的功能接口设计”，涉及到“订单、交易、风控、退款、结算、推荐引擎”等等，相对来说需要 AI 二次多次改写

将来大多数坐办公室的行业都逃不掉

老登来澄清一下：

其实一开始就没前端这个行业

自古以来都是所见即所得前后端一把梭的。frontpage flash 时代开发效率和表达能力比现在前端强得多。

用代码撸界面本来就是本末倒置，得不偿失的做法。

90 年代 delphi 和 VB 都支持双向绑定了。SQL 生成都是全自动的。写 CRUD 一般都 10 分钟搞定的。

前端观感上看起来会多一些，很大一部分是因为前端娱乐圈的属性就是喜欢各种发帖曝光。

排除掉这部分增加曝光的属性。前端觉得好用是因为复杂业务少，大多数场景下完全不需要去了解实际业务也完全可以做。即使稍微有一些小瑕疵也不影响使用。
后端觉得不好用，很大部分是因为需求方自己都不一定捋得清楚业务逻辑。很多时候需要反复和需求方开会扯皮，去试图理解对方的业务。这些人都不一定办得好的事，现在交给 AI去做肯定是不靠谱的。即使出现一些小瑕疵，输出结果很明确得就会体现出来，数值出现偏差了。

更何况很多开发语言水平本就不高。可能脑子里明白了，但让他描述一遍或者用文字表达出来就不知道该怎么说了。输出到 AI 来实现的时候就肯定是会有问题了。
如果需求可以明确的输出成 "如果 XXX ，那么 XXX" 这样精确的需求文档，那么是古法编程和 AI 编程其实都是一样的，按部就班的把自然语言转换成逻辑代码就行了。但是实际操作中并不会有这种可能。

主要前端一写就能看到效果， 后端 AI 从写代码到看到效果需要、代码、数据库、服务器等配套设施， 甚至还需要前端

我觉得后端可以利用 ai 一把梭前端。

用了 figma MCP + claude code + GLM 还原的效果感觉挺差的，跟实际上的完全不一样。就我目前实际的使用来看，html css 还是得自己手动调，其他的 AI 能搞定。figma UI 还原这个我看别人的演示还原度非常高，GLM 在编程方面我觉得是我用过的国产里的最好的，但是搭配 figma mcp 就是不行。

@cvooc 还有卖课的和打广告的，cursor 自从 claude 亲自下场以后，是一个贴都看不到了

@passon ui 不一定描述，可以将设计稿预处理或者有元数据送入模型。
后端追求的是稳定性，可复现，可测试很重要。大模型不同的厂家，不同的版本，甚至同一个版本的不同请求都可能有不少差异。

比起前端，后端 AI 写感觉更简单

最近同事都在用 AI 写代码，最后出现很多预料不到的 bug ，还得通宵擦屁股，还不如一开始就自己写。

无所谓担不担心，时代的车轮都会往前滚。

我是后端，现在基本都靠 AI 写代码了，一般的企业级业务（ CRUD ）需求基本一遍过，直觉我现在的文字功底比高考巅峰期强得多。

包括楼上说的订单/支付/退款/推荐系统之类，七八成交给 AI 写都没问题，人工 review/测试。只不过要做好架构准备好文档，这两块做太差那就是无限返工。

厂商自己也喜欢前端，最近 gemini3 又是 vibe coding 前端界面出来展示

AI 最好用的地方在哪？就是那些已经有现成解决方法的可以剥离出来的东西。耦合的东西越少，它给你提升的效率越高。
比如，你跟 AI 说我要做一个 api 网关转发，它很快就能给你把代码撸出来，或者小到你说我要向后端请求数据，数据格式是 xxx ，拿来再做个排序，也是很方便的
但是如果你要它做更复杂的东西，不是不能做，而是你在给他的提示词上就要非常详细。做出来还要仔细 review ，花掉的时间不一定比你自己写更少

Vibe Coding 非常好, 但出现 BUG 时对新手而言就是灾难, 会进入 Vibe Coding 解决 BUG 的死循环; 看不懂生成的代码, DEBUG 能力差, 没有经历过古法编程时代的新手, 解决问题的效率会很低; 对于老手, Vibe Coding 是一个非常高效的辅助工具, AI 能快速提供思路, 实现原型代码, 对于性能优化, 多线程并发还是需要根据经验给 AI 提示

@cvooc 一两年前 AI 连表面上看得过去的小项目都搞不出来，现在已经能做了。如果 AI 就停在当前的水平，之后不发展了，那确实可以说它谁都替代不了。但是看看一两年前 AI 能做什么，现在能做什么，这个趋势还是挺明显的。搞定那些有明确需求的商业项目其实也是时间问题而已。实际上这种商业项目真正难的是你需要把业务逻辑给说清楚，其实只要用自然语言能描述清楚也可以，并不需写代码。

个人经验觉得是还是怎么使用工具的问题（当然工具质量也有影响，例如 claude > gpt ），“写一个防抖函数”和“写一个页面”，需要的上下文是不同量级的。

某种程度上我觉得我越来越嗦了，会给 agent 交代很多上下文，例如“用 antDesign 拼一个页面，上面是一个筛选的表单，里面有字段 ABCDE ，分别是 xxx 类型和 xxx 校验规则，点击表单的提交按钮后表单下方出现一个结果列表，列表用 antDesign 的 Table 控件来实现，从我提供的 mock json 结构提取字段放到每一行里，它们的格式是 xxxx 。。。” 敲这么多字是挺烦的，但这样能大概框住结果，产出物质量也能过关。

对我来说工作流程没变化，分析需求--转化为代码结构--实现--联调，只是后三步开始交给 AI 去处理，我最后 review 一下即可。我们也在尝试 spec-driven development （ BMAD 、openspec 、spec-kit 这些），计划提供更完整的产品 context 信息，然后将前后端项目串联起来，看看这样落地 Spec → 计划故事点 → 拆分任务 → 具体实现 的开发流程的效果。

不过也可能这都是空话，说不定明年就被裁了哈哈

1. 实际上现在顶尖的大模型在 JS 和 JAVA 上都不存在障碍，参考 https://roocode.com/evals
2. 前端是能看到的界面，更容易被理解生成的成果，所也更容易被分享。所以每次发新模型，大家都会分享模型生成的界面，前端一次又一次的失业 ；而后端的成果分享出来也只有程序员能看懂。
3. 前端整体链路上比后端更短，所以模型在生成后端代码时可能需要更多的上下文，也更容易犯错；但随着模型和上下文工程的优化，这部分差异会越来越不明显。

当前，ai 冲击的是 curd/初中级程序员的市场；但 ai 发展太快了，把时间拉长，可能所有可以解决又容易被验证的都将被 ai 解决。

扯犊子，后端在 AI 冲击下也早就死了，AI 根据 TDD 去实现 API 根本早就已经完全不需要人工介入了，AI 完全可以循环跑出最完美的结果，人工只需要负责理解业务写好 Spec 和定义好数据 Schema 就行了。如果做不到就是纯粹设计的不行，可能这一步还不如 AI 代替。

这件事本质是前端和喜欢说前端被 AI 干死的都是喜欢输出内容的，所以看起来前端老是死去活来的，反而是 AI 在设计生成 UI 这一块一直是在进化，每次都有全新的体验。

@enpitsulin 现在 AI 写代码唯一的问题就是大型项目中很容易重复造轮子，如果需要避免又要提供很长的上下文，对于多人协作不是很友好，代码复用程度会很低，导致越来越乱，还有可能功能实现但是性能上不是最优，仍需要手动优化。但是对纯粹逻辑的代码，说 AI 可以代替编码工作完全没问题

其实对界面有要求的话，用 ai 难多了，有时候你要的效果很难描述出来。没要求的话当然快，什么效果 ai 说了算。这一点后端的需求反而容易说明白

此外界面也难测试，没法让 ai 自测。但是我后端的需求可以写单元测试让 ai 自己看

@cvooc #2 多尝试尝试更有发言权。从个人实践经验来说，你结论是完全错误的

总有人说什么复杂的功能、业务 ai 无法完成（或完成的很好）其实问题点不是在 ai 弱，是使用 ai 的人不懂业务、不懂架构

@xsen 你这话很奇怪：人弱，导致 AI 弱；人强，自然 AI 强。

按这个道理，AI 能很好地完成复杂功能也必然需要强人，强人自己写肯定能搞定，用 AI 就不一定，和高赞的回答其实殊途同归。

@john6lq #34 我现在只遵循一个原则只尝试解析一次，就是做一次尝试、然后只筛选
人类与动物最的区别就是：就是会不断制造新工具、使用新工具，而不是抵触、固守成规

人弱，导致 AI 弱；人强，自然 AI 强

若这个意思都无法理解，那真的更多就是你自身的问题

AI 能很好地完成复杂功能也必然需要强人

你有这个疑问，那说明你软件这行白混了；你练基础的需求与架构都不曾入门

#34
强人自己写肯定能搞定，用 AI 就不一定

所以你想说的是，拿把斧头一样可以砍树，那为嘛要用电锯
走路也可以到罗马，为嘛要坐飞机、高铁
走路一样可以通勤，为嘛要开车、坐地铁

我是从你的逻辑做出这样的推断的

很多人的逻辑很奇怪
一样的工具，别人可以做得更好更快
但是他自己达不到预期的效果，他首先怀疑的是工具的问题、而不是自身的问题

人与人的一个最大区别除了自身天赋之外，最大的区别就是拥有的工具、对工具的使用的区别
这里说的工具包括所有自身天赋之外的，包括不限于资源、家庭、学校诸如此类，也包括各种软件工具