程序员要不要放弃对设计的把控

要么按照你的古法编程偏好来，要么适应 ai 的工作风格，这是在接下来 36 天所有人都需要适应的过程

感觉现在很正常了，前端+接口+后端 流程交互流程还是没有大概得情况下

大概率变成了：前端（ AI 黑盒子）+接口+后端（ AI 黑盒子）

用不完的 token 可以慢慢重构下：提示优化代码逻辑，提高可维护性或者整理好模版模块，让 AI 参考重构

可以不判断把控，但你要判断把控一下你要不要判断把控:

AI 有好有坏，写出来的质量差别巨大。你可以不对生成的结果进行大幅度的判断把控，但是在此之前，你至少综合是什么 model 写的，代码、架构和产品设计的总体观感等，来判断一下你要不要判断

顶楼的文字看起来楼主就显然已经判断出了，对这个项目，这个 AI 不怎么样，必须进行判断把控。假如用 fable/astra 弄个中小型的不算太复杂的项目，通常可以不进行大幅把控

果程序员完全不关注设计，任由 AI 想怎么写就怎么写 .那程序员就该淘汰了....

新型不可能三角： （ AI ） （快） （质量）

这显然是人的问题, 也是管理问题. 现在的 AI 作为实施者已经足够了, 但系统设计和系统架构还是需要由人来把控. 能把这种后端代码提交上去说明 review 层面是有问题的. 后端作为系统业务的核心搞的如此草率?

总说 AI 会带来失业, 这种没责任心的人不失业谁失业? 换句话说, 这种人还能有工作才是对有责任心的人最大的不公平

你可以让 AI 重构啊

哈哈，代码洁癖， 我也喜欢将代码输出成我想象的样子。 共勉

程序员要做的就是做好设计和审查了。。

AI 很听劝，人不是

用 ai 写代码先提供架构设计文档, 没有的话 ai 编写出意大利面式的代码很正常

你可以让 AI 重构，不过能跑起来就不要去动了

@413420 为什么是 36 天？

而且这种不注重设计的代码，往往藏有很多隐患，你稍微改一点逻辑，它就会引发很多 bug （即使你用地表最强 ai 去改）

@xusp 这个帖子的 17 楼会回答你的疑惑 https://v2ex.com/t/1242441

如果是短期项目, 只要能跑就别浪费精力了, 如果要长期维护的项目, 可以定期让 AI 进行重构, 给 AI 约束好规则, 完善好 AGETNT.md

代码是 AI 写的，但是审美是自己的

"我关注的是这个情况是怎么产生的" 大部分，只是糊口混个饭吃。

如果你是基于这个想法，你也会这样的，因为这就是 "糊口"

对于你的建议是:
- 不要随便接手来路不明的代码，就像不要接陌生人的电话一样。
- 如果真的要接了，不要看代码，而是搞清楚需求，直接重写。

我们技术栈约束了使用 proto 定义接口，所以 proto 和 model 层定义我会 review ，具体的实现代码已经基本不看了。算是真的实现了老板以前的要求，接口是对外的，要有规范，代码实现可以随便替换😂

现阶段必须把控，AI 还不能理解每个项目在设计上的取舍边界，放任下去一堆用不着的过度设计，要么就是完全不看现有设计，迟早有一天它修不了的 bug 丢给我我得崩溃

我完全不看代码如何写的了。

我现在是只跟 ai 讨论，并用 OpenSpec 记录已经明确的需求和设计。有时候 ai 太过严谨，反复 grill 我，我就会让它自行实现。等发现问题再修订 openspec

@bojue #2 如果不是很熟悉业务功能，基本没人敢去重构整个系统或者某个大功能模块的代码。

目前算是独立开发吧，功能基本全交给 AI 了，只把控设计，定期收束整理代码。

去年，我还 review 一下 AI 写的代码，一点点打磨
今年我大部分时候只 reviewAI 写的文档，基本文档合意，就直接让实施了，让他自测/用别的 AI 复测，只把控能实现需求了

@413420 #15 可恶，把我也骗到了

我个人感觉只有玩具级的项目可以全盘交给 AI ，持续迭代的产品如果完全交给 AI ，一定会失控的。

AI 的注意力有限，有时候局部最优解并不是全局最优解，一味信任 AI 可能最后会走进死胡同，频繁的拆东墙补西墙。

用的什么 ai 写的？

典型的，放任 ai 来写，完全不 review ，只要能跑，只要能过用例就行，有问题，直接告诉 ai 什么问题，ai 自己改，也就是开发从头到尾没有看过代码是怎么实现的
也就是现在 ai 出现了，拯救了部分这类开发人员，说白了，在这个过渡期，不是 ai 革了程序员的命，是 ai 救了不少人~

@413420 说实话，在这个贴子的讨论氛围下。你的这种回复确实很不友好，感觉被人戏耍了一样。

@keer 有“很”不友好吗？我认为你太敏感

随着 AI 的不断发展与进步，这种恶性事件会越来越少

但是可以确定是 AI 比大部分程序员都要写的好

你很容易就能发现，在 AI 出现之前，这些问题就已经存在了，只不过一般不是程序员大头兵的视角能够发现的。
从技术经理或者项目经理的视角出发，经理本身有些情况也是完全不参与技术实现过程，技术实现是靠带的整个团队去做的。
那时候的管理人员面对技术团队跟现在的程序员用 AI 的时候面对 AI 产出的项目的心态是一样的。

所以程序员用 AI 遇到的问题并不是凭空产生的，原来就有这些问题，只是原来不是程序员这个角色去处理这些问题罢了。
那程序员遇到了那怎么解决呢？不还是软件工程那套流程？
关键在于是不是有人或者人带着 AI 在老老实实执行这些流程罢了。

AI 出来之前一样有管理带着技术团队一拍大腿搞出依托答辩然后后续不断重构/史上雕花的。
AI 出来之后，使用 AI 的人没有老老实实按照软件工程的那套流程去做事情，犯的错就跟 AI 出来之前整个团队不老老实实执行软件工程流程犯的错是一样的。

所以到底要不要把控设计？就比如你手头这个项目，业务上有很大的提升空间，需要频繁的根据反馈去改，那你就要设计出一套能够承担这个频繁变更的一个健壮的项目框架，甚至你要反过头来去质疑需求到底合不合理，到底项目的商业逻辑合不合理等。
但是如果你只是糊弄领导，按照需求把东西做出来了，我反正不管后续，项目的商业逻辑跟我无关，我就拿个工资而已，那我觉得你还是别重构了，摆烂吧。

@woodfizky 以前代码写得很烂，但还是有人可以兜底。我以前有个同事写 java 之前是写 C 的，他的风格就是所有变量都在开头定义，并反复赋值，其他人看不懂，但他还能维护。现在 AI 写的代码水平都还过得去，但能兜底的“人”已经没了。这个风险可高可低，看企业愿不愿意经历一次。

@NoKey #28 wc 我就 是这样的，一模一样.....

@413420 #15 pv uv+1

程序员完全让 AI 写的代码，没有把关，代表开发人员的水平

AI 和你有一个能跑就行

@meteora0tkvo #22 看工作方式吧，我们现在一个人负责一个项目，最近打算把几个前端迭代了 6 年的 MES 产品 从 Angular20 重构成 Vue3 ，领导拍板了，我还在小范围测试

> 程序员完全让 AI 写的代码，代表的是 AI 的水平，还是程序员自己的水平；程序员是否愿意拿这份代码当自己的产出，让这份自己都不理解的代码为自己的能力代言。

以及 #37 说得非常好。

#26 和 #28 描述的就是完全放任收获的新型技术债。

我觉得到了大模型时代，这种长度很正常。

首先是代码大多不需要人类读，只需要将功能模块分好就好了，有些代码很长问题不大，大模型读起来很快。
第二个是大模型写的代码明显是要比人类啰嗦的多的，很容易就写长了，如果强制他分文件，分模块，会过度冗余，更不易读。

在没有 ai 的时候也是有人代码写的好，有人写的差，有人觉得需要把代码打磨到自己满意的程度，有人认为能跑就行。在 ai 时代这种问题更明显了，但是我觉得还有有人愿意去把 ai 生成的代码打磨成自己喜欢的样子的。简单可追溯的数据流，合理可读的拆分，不单对人友好，也对 ai agent 友好。

@yidinghe 你也知道之前写 c 的人转到 java ，那风格一言难尽
AI 时代怎么就变成维护不动了呢，这不解决了很多沟通成本？
更何况，你让它重构它就重构，你让它加新 feature 它也任劳任怨
我觉得 AI 时代到了，思维要转变一下，不要死抠细节，人要来驾驭 AI ，说白了就是知道方向在哪里，写好文档、注释，比死扣这个算法这样写的价值是什么要好。
从这个角度看，这不是好事么

把自己代入成 leader ，ai 相当于 100 个手下，要对这 100 个人负责，不可能一点点看，只把握关键

看产品的目的啊，如果是自己要长期维护的，自然对大框架和关键步骤要有把控，后续才知道如何指挥 ai 。oneshot 的话那就随便了

现在已经不用看 AI 每一行代码了，我代码已经完全交给 AI 来生成，但是我有 100%把握，所有我用 AI vibe 出的项目我都掌握着项目结构，整体框架，内部实现的核心细节。因为这些东西全都是我手动设计的（虽然具体代码实现并不是我来实现）。AI 只是将我的设计落实的工具

我现在的看法是，如果完全放弃对代码的设计、理解和顶层的掌控，那么“你”作为程序员将完全没有任何价值
说难听点，既然都是对 AI 许愿那你干的活和随便拉个路人然后培训下就开始对 AI 许愿有什么区别。啥？遇到专业问题不会编程没法解决？可一天到晚吹现在 AI 这么强大已经完全不用写代码完全不关心底层的不也是“你”吗？

未来怎么发展不知道，现在变化太快了，但至少我觉得现在程序员还是必须得控制代码设计的

现在我要求 AI 遵循最佳实践并且不要过度设计，发现写出来的代码比我写的漂亮太多，还有一些非常复杂的性能优化，过去我要转耳挠腮调好几天的事情，用 AI 调半个下午就能实现，被降维打击后，我就开始不在乎代码了。。。

如果 token 越来越便宜，你说的情况可能是无所谓的，和上面楼说的一堆黑盒暴露 API ，能跑就行。
但是如果 token 并没有便宜或者说公司裁掉太多人深度转向 AI ，过于深度使用 AI 导致 token 费用研发占大头，那么这个时候良好架构设计的人应当是会有一定的竞争力的，良好的架构设计显而易见的在后续迭代开发中会消耗更少的 token 。

AI 就像装修公司，你不看着他不给他提意见，那它给你的东西就要多糊弄有多糊弄。
如果这个房子（项目）你自己多少有点想住的意思，你就得按步骤一步一步的来（分析、设计、选型），每一步都得拿鞭子抽它几回才能出来个将就的结果。

难道不是吗？用 Skill 规范代码

当然不能放弃，为什么要放弃？ 这到底是你的工程还是 AI 的工程？ 就因为 AI 吐模板代码吐得快？

其实我感觉这个问题比较宏大，也是未来会探讨的一个方向，首先，得声明你的角色是什么，员工 or 老板，在如此大规模需求快速迭代的情况下，我感觉很少有人说是会很细致的去仔细看这个代码，因为你这样做老板不给加钱，你搞得越细致就会越耽误自己的时间，因为大家都在 ai 快速开发迭代，你们不跟着搞就会被淘汰，在说回来，如果项目架构设计明确，分工职责清楚的情况下，我想 ai 也不会胡乱开发了，他胡乱开发的原因，其实一部分来自于所谓的取舍，所以这并不是单方面造成的原因。
在从个人角度说，如果是为了自己的项目，那确实有必要好好规划设计，严格审核，因为那是提高自己的一步，这只是非常有必要的。
说了这么多，其实我想说的是，这个问题没有标准答案，就和没有 ai 的时候为了开发速度快，必然会欠下一部分技术债一样，ai 虽然来了，但是取舍还在，是一个需要不断探讨完善的话题和方案，没有绝对的答案。

需求不急的话还是会自己扣一下 AI 代码的细节，需求急了的话那就不管代码格式代码结构了，功能没问题就算了。

最开始就要先把框架定好，不然就是 n 多个脚本

说明使用 ai 那个人 代码水平不咋地额，因为 ai 会扫描目录，看你之前的风格。除非我指定让它写到一个文件，否则它从来没有把所有都放到了但文件里

感觉大部分“程序员”写的还不如 AI 生成的

@JZen 老哥，可否分享下你的全局约束条件。

手工编程也得分层设计，先降低复杂度，然后实现某一小块功能。完全交给 AI ，没了前面的边界限制和取舍，项目复杂度成几何上升。
AI 倾向于越搞越复杂，它仗着懂得多喜欢大而全。而人有品味有取舍的能力，品味可以降低项目复杂度。ai 还有速度要求，AI 把项目搞复杂了，兜不住了，又要快又要不贵。他就开始躺平了，框框一顿思考，甩给你一个可能性，一验证不行！

现实是，很多初级中级程序员，手工编程的质量真的不如大模型，大模型在使用前用通过初始环境做很多限定条件约束，保证代码质量和编码始终符合高标准规范，把大模型的整体编码水平始终提升到 P9-P10 级别的技术专家/研究员，很多人不做初始预设，总是不做好整体的规划，就着急入手功能开发，肯定是屎山堆砌。

这明显是 AI 写完，没 review 一下。而是只关注是否已经实现需求。
他就跟测试一样，黑盒测试，用例过了就没问题。
不管内部实现成多糟糕
一把梭

拥抱 AI ，抛弃 手写的陋习