今天搞 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]

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