AI 辅助编码在实际业务前端落地效果如何？

25 年都过去三分之二了，还在怀疑 vibe coding 的能力，别人说不好你就继续刀耕火种吗

前端早就能 vibe coding ，后端还是要费点功夫，要把需求拆成极小的单元任务块才行。

公司的祖传项目用 DDD 重构时，面对项目中总数高达 27w 行的存储过程，cursor 都冒烟了也毫无办法，只能靠人工一个一个的拆。

@mumbler 我没有怀疑，是实际遇到一些 case 发现并不好解决，想请教下看看大家的经验，你怎么就能断定我在刀耕火种呢？如果你有实际的效果特别满意的 case ，可以分享下经验，不要纸上论道。

@dickeylth 我觉得你不如把你的 case 发出来..

@dlmy 前端也有前端的痛，多模态可视化的能力目前看还达不到像素级精准还原的要求，figma MCP 也不完全是银弹（除非 Figma 和 PRD 质量都非常高），另外数据处理逻辑在复杂业务场景里也会很碎片化，交给 AI 要想干好，实测也需要很多上下文手把手的补充比如这里显示的数据从哪个字段取、面向展示需要做什么额外格式化逻辑等等

@nanyong0627 可以，上一条回复补充了

加一些具体描述以免讨论泛泛而谈：

1. 面向的是中后台依赖 Pro Code （源码开发）场景，对 UI 有一定高保真还原要求；
2. Figma 和 PRD 受个体差异质量无法要求，Figma MCP 返回的结构化数据里节点排列可能会和在 Figma 中看到的图比如顺序上有差异，PRD 中可能会混合前端和后端的需求；
3. 部分场景下针对已有功能的优化不一定有完整的 Figma ，可能产品会基于线上截图给一些调整后的效果图；而对于图像的 OCR 识别，现成的即使是最好的 Claude 系模型也还做不到像素级精确识别布局间距这些信息；
4. 接口返回字段和页面 UI 上的映射关系，就过往的开发模式依赖于前后端的沟通，存量的业务逻辑在有限的注释量下交给 AI 来消化

ai 在前端就是无敌的存在

写后台这种有主流组件库的比如 antd 非常好用，你把需求描述清楚生成的基本可用。如果是 C 端自定义样式的组件，哪怕有 figma MCP 生成的效果也是一坨。

如果你只在乎功能可用，然后样式是基本美观的话，用 ai 工作效率非常高。但是样式交互定制化要求非常高的话，还是要手搓。我是这么认为的。

前端这个职业可以说已经废了。 即时是用 GitHub Copilot 里非常辣鸡的 GPT-5 min 写出来的落地页也非常的好。

讲个这周的事情

SMS Forwarder 这个软件正式开始收费了

摸鱼半天写了个替代品侧载到自己手机上（没有一行代码是自己写的, 我也从没写过安卓）完美代替

个人的体验：对于视觉要求（例如元素位置精度、动画效果）不高的 UI 基本上能搞定。

如果是手写 css 若一点，但凡你用那种助记词，ai 完爆初中级前端，你还得背助记词，ai 直接写的又快又好

涉及一些复杂的业务逻辑，还不如自己想想写得快

你的感觉没错。

因为前端的反馈周期最短，浏览器就能直接运行，所以登上 “愚昧之巅” 的人最多。

现在设计稿的还原还处于“史密斯吃面”的初级阶段。

你可以生成一万个史密斯吃面，都是有两个眼睛一个鼻子，至于眼睛在哪鼻子在哪，属于管你这那的，就问你有没有两个眼睛吧。

对于设计稿还原，你直接盯着 figma 和 figma 插件的生态就可以了，真到可用的阶段，一定是最先反映到最前沿。

如果还有机会换工作,面试的时候我只能说熟练编写各种 AI 工具提示词...

1. 对于能力低的开发，AI 辅助编码是有用的，反正也不会写， 没有思路， 用了 AI 起码能把代码搞出来， 至于对不对，就看 AI 了。
2. 对于能力强的开发，AI 辅助编码比较鸡肋，如果描述少了，AI 就根据自己的思路逻辑写代码，可能跟你的思路不一样，这个时候就比较变扭了。如果把自己的思路描述很详细，其实跟自己写代码时间差不多，有时候用 AI 可能更费时间，你还要检查 AI 的代码是不是根据你的思路写的。

cursor + claude4 。在公司已经几个月没有手写代码了。。

现在真可以用嘴写代码了