今天搞 B 端的项目，突然想到一个想法，需求文档的描述结合 chartGPT 生成前端代码有没有搞头。

[joker95271]

我初步的想法是把需求文档对特定模块的描述（比如表单的名字，输入规则，校验等等）内容喂给 GPT,GPT 根据我的描述输出给我代码。或者是一个展示的 element 的 table 部分。具体到业务逻辑我们自己再去完善。 大概是这种各位大佬思想碰撞一下。

[ZGame]

我觉得从低代码平台去考虑比较好, chatgpt 去理解低代码 schema json,然后喂给 chatgpt 去产出

[gaobh]

有搞头，不过不要搞一整个需求文档直接扔给他的 gpt 。要做结构拆分上传，流程处理方式，分流程重复深度生成。非常适合产品经理和前端使用

[joker95271]

@gaobh 是的，需求文档上就会按照页面和功能点来写，把功能点拆成一个单元（一次对话）生成一个区域。比方说一个列表页面的搜索区域，列表区域，和操作。以及其他的功能。

[1044523901]

在搞，还没落地....

[joker95271]

@1044523901 能分享下思路么

[ruoxie]

去年就已经做了 https://github.com/lowcoding/lowcode-vscode?tab=readme-ov-file#%E7%94%9F%E6%88%90-curd

[ruoxie]

ChatGPT 更多的是做中文翻译成英文变量的工作，生成的代码没法直接用，而且团队有自己的代码规范

[xubingok]

没有搞头...gpt 完全不考虑复用的...也没有什么组件概念.

[nothingistrue]

「（比如表单的名字，输入规则，校验等等）」，「具体到业务逻辑我们自己再去完善」：如果前后这两大阶段都是人做的，那么整个编码就只剩非常小的一点工作了，还需要什么 GPT ；如果这俩你人不做，那么人都看不懂的东西，GPT 也做不了。

当然，跟低代码、代码自动生成工具一样，不是完全没用，是能抽走大量低级重复工作的。不过，只要是上了年龄的开发，基本都会明白：虽然我们总是在蔑视复制粘贴，但是「复制—粘贴—调整」往往比「提取公共—维护公共」，或者「提取公共—不维护—废弃已过时公共—重新提取」更有效。

[teenthsch]

@xubingok 都 gpt 自动生成代码，还考虑复用？还考虑组件？

[ZnductR0MjHvjRQ3]

能这么说的要么不写代码 要么用 gpt 用的少。。。

[mlhorizon]

结合一个脚手架代码，利用 gpt 实现聊聊天就给做好几个增删改查，让码农摸鱼更轻松点。
或者结合 NoCoDB 这种，利用 GPT 快速给做个壳出来。

[drydiy]

我说句实话。说有搞头的有一个算一个，都没写过几天代码。
对于 B 端业务系统来说，前端最麻烦的是跟后端对接口/字段、写业务逻辑代码、满足产品那不合理又能实现的交互逻辑。
B 端那些什么表单之类的，我一个 C V 组合拳 就解决了，改改名称有多少工作量？？
所以，低代码平台同理。真正需要解决的是业务逻辑、业务逻辑、还是业务逻辑。你不能帮我写业务逻辑代码，都是垃圾。

[kkwa56188]

太慢了, 再加个脑机接口吧, 这边大脑一想需求, 那边代码就写好了可以跑起来了.

[gaobh]

说没搞头的都是开发吧，这个给产品很有用的，以往都是原型+文档，现在一边写文档一边就能出 7788 的效果，足够了，给开发讲交互那不是分分钟拿捏，这不是提效降本

[xhawk]

@drydiy 看似是开发大佬，理解很到位，加个联系方式请教一下 cv 组合拳

[xhawk]

我的想法是，不是思考的产品没用，而是我的理解未来可能是没有文档的，一切均原型，通过原型出代码，这个看似更靠谱。最后对接一下领域知识，系统就完成了。

[LeeReamond]

@gaobh
1. 一边写文档一边能实现 7788 的效果基本是资深开发的要求，让产品经理来搞？
2. AI 的幻觉问题如何解决，你可以生成代码，但你只要有一丁点不符合描述的，产品能解决？
3. 有原型+文档还理解不了需求的，建议不雇佣小学生团队捏

[murmur]

这不就是低代码么，现在大一点的 OA 都能办到，还写个屁的文档，直接客户一边说你一边做

[LandCruiser]

没搞头，一是不可实现，二是搞出来的东西不可维护。

[royalknight]

只能从 0 到 1 ，没法从 1 到 100

[leehome]

gpt , copilot 已经能做了

[ren2881971]

完全没有搞头。B 端的项目业务逻辑太强了。

[joker95271]

@royalknight 为的是省略 CV 其他代码和修改字段。rule 的逻辑以及方法名完全都能生成。开发的关注就偏向业务逻辑。

[joker95271]

@ren2881971 为的是省略 CV 其他代码和修改字段。rule 的逻辑以及方法名完全都能生成。开发的关注就偏向业务逻辑。

[GeekGao]

有搞头 != 能赚钱

[Pig930]

借楼突发奇想一下，有那种通过自然语言就能生成需求文档的项目吗

[whythings]

这个想法很好，我现在很多需求文档都是通过 chatgpt 帮忙梳理，B 端一部分需求是比较通用的，可以抽离出通用的。定制的部分更多通过人工实现，idea 我个人非常赞同，

但是商业化方面不好评估，
1.投入方面，需要研发投入，还需要市场推广等
2.收入方面，企业还是个人付费？ 营收能力如何？

[tikazyq]

https://replit.com/

[gogogo1203]

@Motorola3 今夕是何年..... 这个方面别人都走烂了. tldraw v0 等等等. 有文档生成的, 有直接从低保真生成前端的.

[joker95271]

@whythings 不是盈利项目。就是工具化公司内部使用提效的

[linyongxin]

前几天我发文/t/1034801 就是说到 AI 机器人训练自己的内容库。
电商的 ai 客服普遍很拉胯，所以基于销售客服的场景实在是非常大。需要能接入微信等 im 、公众号、小程序

[ZnductR0MjHvjRQ3]

@gogogo1203 我去试了 v0 效果很一般

我需要一个手机上展示的画板页 底部有一个横向滚动的导航栏 导航栏上有八个按钮 均匀分布，顶部有一个 导航 上面有五个按钮均匀分布

这是需求 google 翻译成英文给他
这是出来的效果
https://img2.imgtp.com/2024/04/26/6CEoDYu6.jpg

我就想说 这和产品拉框有啥区别 完全得益于 ui 框架 甚至都不如给产品一低代码 出来的效果好 。。。。
某种意义上说 如果研发一套完美的内部低代码 甚至可以省开发很多事 直接产品拉低代码 然后开发是知道低代码生成代码的转化规则的 然后开发再去二次开发 市面上也有做的不错的 蓝湖那种 ui 转代码的问题就在于 代码格式太烂了

这种东西为什么要硬套 AI 呢？ 如果靠语言 靠沟通来修改页面 不费劲？ 一个理解偏差 要修正的可能就很多地方了
你自己用的过程中没有遇到过表述有点偏差回答的驴头不对马嘴的情况吗？

我不是为了怼你 我只是说说我的看法
如果不能 80%帮你完成 重复但略有灵活的业务逻辑 那就是没用 讲道理 copilot 已经做的非常好了 他甚至都可以帮你完成一些重复的灵活的业务逻辑

[ZnductR0MjHvjRQ3]

@linyongxin 因为人太神奇了

[zy0829]

首先我觉得要分两个边界来谈，如果只是纯前端页面 我的结论是有搞头，不能做到 100% 但是对于我这种不喜欢画页面的人来说能先搞个 70%就很不错了。如果目标是生成完整的带数据交互的前端项目这个就别谈了，毕竟前端 后端 产品 一人一个想法

[joker95271]

@zy0829 是的呀，一般都是 cv 历史功能，然后改文案改规则改方法名。我的出发点就是把 cv 这步都胜率，利用需求文档的功能描述（我们产品会写表格对表单的描写包含字段名+输入限制）生成页面。后面具体的掉接口以及复杂的业务逻辑开发自己写。100%肯定是不可能的

[moudy]

@drydiy 很多人没理解问题有两类，一类是框架带来的复杂性，这种 chatgpt 能搞定。另一类是问题本身的复杂性，并不是说你把编程语言换成需求文字就能消除掉……可能复杂性还因此提高了

[pobo]

感觉 gpt 就类与之前的搜素，不会的时候问一嘴，它比搜索智能一点，但没有大局和规则意识，像一个学富五车的门外汉

[gogogo1203]

@Motorola3 这些工具都是为了快速出可视 ui, 又不是让你直接丢到生产里。 而且所有 AI 都是需要通过后续 prompt 一点点改的。 我不用这些工具， 我只是举例这个方向都做烂了。v0 现在加入了 shadcn 的 ui 库，满满都会完善起来。和 copliot 上都是 gpt4 套壳， 本质上没有区别

[RandomJoke]

没搞头，B 端最麻烦的就是理解业务，然后沟通，往往人和人之间有时候都沟通不太清楚，需要当面解释反复沟通。你是指望产品写的文档能让 GPT 给你生成代码？要是简单需求，生成模板原型框架之类的，一堆低代码的平台就已经能解决了