vibe coding领域之中，亦有巨大的差距！
- 内容介绍
- 文章标签
- 相关推荐
之前参加了院里面的一个项目，我和其他两个人负责代码方面的东西。
大概就是做一个agent这样。我熟悉前端的东西，所以说我可以做前端，就派我到前端去了。
这两天一个人退出了不干了，队长希望我来后端帮帮忙，然后我时隔一个月pull下来代码。
让codex初探一下，谁懂那种，救赎感
017ae73b65f0c7fb0fac38095399d4c540×206 3.63 KB
这个耦合度，高内聚，每次读代码堪比解密军事文件。
队长他们用的是trae这样的工具，但是我暗暗感觉不是工具的问题，是他们本身就没有任何项目经验和解耦思维，脚本感太重了。就是做的是一次性可用的，不考虑可维护性和可读性。
即使同是vibe coding，也会因为人必然会有巨大的差距。那些用vibe做出好项目的佬，你们就别那么谦虚地说都是AI写的了！
一个月前我提醒过他们，一个文件一千行代码万万不可啊，那么多函数和接口，稍微改一个字段就全军遭殃了。早知道参与一下了
现在轮到我来处理这最高的山了。我想改一个检索逻辑，寸步难行啊！一个函数改了，整个流程爆红。
--【壹】--：
肯定要看的，因为我要改进后端逻辑，用更好的检索和筛选。现在耦合在一起不知道哪里入手，就是一个逻辑层的代码包含了下一个逻辑层的代码，然后黏连，各种if判断
老老实实解耦得
--【贰】--：
这个目前是有争议的，就是它写出来的东西，到底还要不要看？我也没想明白。
如果不看的话，长短无所谓的，内聚还比较好修改了。从这个角度说，你同事更native？
--【叁】--：
见过最多行的一个文件是某个框架插件的main.py，一看我去9k＋行，看力竭了hhh
--【肆】--：
vibe coding 却没有完善的 AI Rules，一路 continue 就是这个结果。几十个个提交之后必然有几千行的文件。你不给 AI 明确的约束和指令，它是不会重构的。
--【伍】--：
其实一千行我还能接受，但是六千行我晕了
我滑到底都需要两分钟
--【陆】--：
我看到的是5个行! 加油佬
--【柒】--：
正在折磨gpt，写计划解耦
--【捌】--： Bin:
最高的山
最高的屎山，最长的臭河。
蝴蝶飞不过屎山，又有谁忍心责怪
--【玖】--：
奉劝一句 能跑不要动
--【拾】--：
感觉AI只会用最短路径去实现功能，头疼医头脚疼医脚，才不管后面维护的事
--【拾壹】--：
重构吧。
--【拾贰】--：
一个文件一千多行，我以前不懂的时候用AI写前端，也这样。（照道理来说后端不太容易出现这种情况啊，因为职责分工比较明确，分多个文件也比较容易）后来发现此类文件写长了之后，会遇到大模型刚读到这个文件，上下文就爆了，然后又压缩，就会忘记之前做到哪了（这个压缩总是会出问题的，尤其是在这种情况下出问题）——所以后来我专门写了一个code-organization rule，现在就没太遇到过了，就是codex拆代码太积极了哈哈，动不动就拆
--【拾叁】--：
我这里还有个无限套娃的，人写的
--【拾肆】--：
是的，佬说的对。所以有一个人作为架构师很重要！
--【拾伍】--：
现阶段,还是和实际操作代码的人技术深度有关系
--【拾陆】--： Bin:
一个文件一千行代码万万不可啊
哈哈哈哈哈哈哈
万万不可啊
--【拾柒】--：
理想状态下，一个文件八百行以内比较好，但是真正接触项目，就会发现，很少能有主要的类能够只有几百行的，几千都是正常，上万也不是不可能，这种情况下，要求每个方法的行数更加现实点，最怕的是一个方法几千行，一个if判断上千行，那才叫头疼
--【拾捌】--：
是的佬，我们这里写了几千行的if判断 hhh
--【拾玖】--：
之前我也是做过一个大项目，因为需求随时变，越堆越多，没有考虑工业化的架构设计，bug很多，最终下决心，全部重构，目前稳定运行几个月
之前参加了院里面的一个项目，我和其他两个人负责代码方面的东西。
大概就是做一个agent这样。我熟悉前端的东西，所以说我可以做前端，就派我到前端去了。
这两天一个人退出了不干了，队长希望我来后端帮帮忙，然后我时隔一个月pull下来代码。
让codex初探一下，谁懂那种，救赎感
017ae73b65f0c7fb0fac38095399d4c540×206 3.63 KB
这个耦合度，高内聚，每次读代码堪比解密军事文件。
队长他们用的是trae这样的工具，但是我暗暗感觉不是工具的问题，是他们本身就没有任何项目经验和解耦思维，脚本感太重了。就是做的是一次性可用的，不考虑可维护性和可读性。
即使同是vibe coding，也会因为人必然会有巨大的差距。那些用vibe做出好项目的佬，你们就别那么谦虚地说都是AI写的了！
一个月前我提醒过他们，一个文件一千行代码万万不可啊，那么多函数和接口，稍微改一个字段就全军遭殃了。早知道参与一下了
现在轮到我来处理这最高的山了。我想改一个检索逻辑，寸步难行啊！一个函数改了，整个流程爆红。
--【壹】--：
肯定要看的，因为我要改进后端逻辑，用更好的检索和筛选。现在耦合在一起不知道哪里入手，就是一个逻辑层的代码包含了下一个逻辑层的代码，然后黏连，各种if判断
老老实实解耦得
--【贰】--：
这个目前是有争议的，就是它写出来的东西，到底还要不要看？我也没想明白。
如果不看的话，长短无所谓的，内聚还比较好修改了。从这个角度说，你同事更native？
--【叁】--：
见过最多行的一个文件是某个框架插件的main.py，一看我去9k＋行，看力竭了hhh
--【肆】--：
vibe coding 却没有完善的 AI Rules，一路 continue 就是这个结果。几十个个提交之后必然有几千行的文件。你不给 AI 明确的约束和指令，它是不会重构的。
--【伍】--：
其实一千行我还能接受，但是六千行我晕了
我滑到底都需要两分钟
--【陆】--：
我看到的是5个行! 加油佬
--【柒】--：
正在折磨gpt，写计划解耦
--【捌】--： Bin:
最高的山
最高的屎山，最长的臭河。
蝴蝶飞不过屎山，又有谁忍心责怪
--【玖】--：
奉劝一句 能跑不要动
--【拾】--：
感觉AI只会用最短路径去实现功能，头疼医头脚疼医脚，才不管后面维护的事
--【拾壹】--：
重构吧。
--【拾贰】--：
一个文件一千多行，我以前不懂的时候用AI写前端，也这样。（照道理来说后端不太容易出现这种情况啊，因为职责分工比较明确，分多个文件也比较容易）后来发现此类文件写长了之后，会遇到大模型刚读到这个文件，上下文就爆了，然后又压缩，就会忘记之前做到哪了（这个压缩总是会出问题的，尤其是在这种情况下出问题）——所以后来我专门写了一个code-organization rule，现在就没太遇到过了，就是codex拆代码太积极了哈哈，动不动就拆
--【拾叁】--：
我这里还有个无限套娃的，人写的
--【拾肆】--：
是的，佬说的对。所以有一个人作为架构师很重要！
--【拾伍】--：
现阶段,还是和实际操作代码的人技术深度有关系
--【拾陆】--： Bin:
一个文件一千行代码万万不可啊
哈哈哈哈哈哈哈
万万不可啊
--【拾柒】--：
理想状态下，一个文件八百行以内比较好，但是真正接触项目，就会发现，很少能有主要的类能够只有几百行的，几千都是正常，上万也不是不可能，这种情况下，要求每个方法的行数更加现实点，最怕的是一个方法几千行，一个if判断上千行，那才叫头疼
--【拾捌】--：
是的佬，我们这里写了几千行的if判断 hhh
--【拾玖】--：
之前我也是做过一个大项目，因为需求随时变，越堆越多，没有考虑工业化的架构设计，bug很多，最终下决心，全部重构，目前稳定运行几个月