搜索
  • AI 辅助编码在实际业务前端落地效果如何？
  • 发布于 2天前
  • 74 热度
    12 评论
AI Coding 新闻天天有，Demo 天花乱坠个个都是 SOTA 。抛个实际点的问题，前端工程师们实际在 PC 中后台通过源码构建的场景，利用 Figma + AI 辅助（ Cursor/Claude Code/...）完成业务需求的实际效果怎么样，能满足预期吗？有感觉比较满意的经验分享吗？
用户评论
  • Kily
  • 能搞定非业务的，比如让 ai 帮整个表单架子还是 ok 的，但是表单延申出来的动态逻辑控制、校验规则之类的，还是得靠人写，也就是还原产品 prd 里那些弯弯绕绕的逻辑。另外写工具也不是万能的，我最近在重构老页面，让 ai 帮我封装 antd 的 Formitem,支持双向字段映射，ai 写不出来，可能是因为没学过，我在网上也没搜到类似的实现。
  • 2025/9/1 9:22:00 [ 0 ] [ 0 ] 回复
  • 阳光
  • 我倒觉得 AI 在后端使用更丝滑，前端需要 UI 还原，交互多的也不好描述清楚，还有自动化测试我们前端也没有，纯用 AI 还是不太靠谱，还要自己读 AI 写的代码，大量测试完善。
  • 2025/9/1 9:20:00 [ 0 ] [ 0 ] 回复
  • 远行客
  • 1 有特定 UI 要求, 图片/动效 较多的,AI 无能为力,或者说你压根不知道如何清晰地表达
    2 你需要不断修改项目的 project_rules 或者喂 context7 的文档, 反反复复地调试
    3 对 UI 库上的每个组件形式, 需要单独调试,特别是弹窗, 一连串的交互动作,特别难
    4 在使用 AI 写项目前,要求你对整个项目有一个充分的认知, 可以让 AI 写 prd,一项项对. 同时要将 数据库, 存储, 环境 等提前告知 AI
    总之 AI 适合没有特定 UI/交互要求的项目, 最好能从 0.0.1 版本每次只加 1 个功能,慢慢累加
  • 2025/9/1 9:18:00 [ 0 ] [ 0 ] 回复
  • 徒步旅行
  • 1. 对于能力低的开发，AI 辅助编码是有用的，反正也不会写， 没有思路， 用了 AI 起码能把代码搞出来， 至于对不对，就看 AI 了。
    2. 对于能力强的开发，AI 辅助编码比较鸡肋，如果描述少了，AI 就根据自己的思路逻辑写代码，可能跟你的思路不一样，这个时候就比较变扭了。如果把自己的思路描述很详细，其实跟自己写代码时间差不多，有时候用 AI 可能更费时间，你还要检查 AI 的代码是不是根据你的思路写的。
  • 2025/9/1 9:15:00 [ 0 ] [ 0 ] 回复
  • 星空寂云
  • 你的感觉没错。因为前端的反馈周期最短，浏览器就能直接运行，所以登上 “愚昧之巅” 的人最多。现在设计稿的还原还处于“史密斯吃面”的初级阶段。你可以生成一万个史密斯吃面，都是有两个眼睛一个鼻子，至于眼睛在哪鼻子在哪，属于管你这那的，就问你有没有两个眼睛吧。对于设计稿还原，你直接盯着 figma 和 figma 插件的生态就可以了，真到可用的阶段，一定是最先反映到最前沿。
  • 2025/9/1 9:13:00 [ 0 ] [ 0 ] 回复
  • 青春不留白
  • 讲个这周的事情，SMS Forwarder 这个软件正式开始收费了，摸鱼半天写了个替代品侧载到自己手机上（没有一行代码是自己写的, 我也从没写过安卓）完美代替。
  • 2025/9/1 9:08:00 [ 0 ] [ 0 ] 回复
  • 夜有星光
  • 写后台这种有主流组件库的比如 antd 非常好用，你把需求描述清楚生成的基本可用。如果是 C 端自定义样式的组件，哪怕有 figma MCP 生成的效果也是一坨。如果你只在乎功能可用，然后样式是基本美观的话，用 ai 工作效率非常高。但是样式交互定制化要求非常高的话，还是要手搓。我是这么认为的。
  • 2025/9/1 9:03:00 [ 0 ] [ 0 ] 回复
  • 路生云烟
  • 前端早就能 vibe coding ，后端还是要费点功夫，要把需求拆成极小的单元任务块才行。公司的祖传项目用 DDD 重构时，面对项目中总数高达 27w 行的存储过程，cursor 都冒烟了也毫无办法，只能靠人工一个一个的拆。
  • 2025/9/1 9:01:00 [ 0 ] [ 0 ] 回复
可能感兴趣的话题