这是一个创建于 37 天前的主题，其中的信息可能已经有所发展或是发生改变。
提需求的人都觉得编程非常简单，把需求扔给 AI 输出的东西就能用，实际可能连需求都没弄清楚。程序员得应付模模糊糊的需求和维护 AI 输出勉强能用的编码。
 | 1 tqyq88 3 月 18 日 同感，ai 的 code 效率高，拉翔的速度也是杠杠的 |
 | 2 lifei6671 3 月 18 日 确实是，有时候 AI 想的太多，有时候 AI 又想的太少，导致写的代码慢慢失控了。 |
 | 3 libasten 3 月 18 日  3 怕的时候需要微调一个地方，来回折腾几次都没能达标，自己去手动改，又不知道在哪里，怎么改。 |
 | 4 GuluMashimaro 3 月 18 日 自己用的小工具类的，不 review 正常。但是你商业项目直接用 ai 生成也不 review ？起码需求得帮客户完善吧 |
 | 5 pagxir 3 月 18 日 via Android 目前 AI 写代码进度完全不可控，开局很快，后面就跟炼丹一样，有可能会出废品也可能能用 |
 | 6 june4 3 月 18 日 梦游式编程，追求的是能用就行 |
 | 7 crysislinux 3 月 18 日 via Android 是这样的，我们的项目已经开始失控了，很多开发者其实不会去想方案合不合适，容易头痛医头脚痛医脚。。 |
 | 8 iamdhj OP @GuluMashimaro 现在问题是客户或者领导觉得代码实现非常简单，程序员只是 AI 搬运工。需求没明确可能也会让你先出个版本看看，你如果说难办他们告诉你直接把需求／代码扔给 AI 就行，非常简单。 |
 | 9 cloudzhou 3 月 18 日 ai 掩饰了开发者的水平差异倒是可能的，因为看起来都能跑起来 但是 ai 的工作过程，也受开发者的水平影响的，长期维护的项目会体现出来的 |
 | 10 msg7086 3 月 18 日 很多人没搞清楚写代码和做软件工程的区别。软件工程不是简单无脑扔提示词这么简单。 |
 | 11 AoEiuV020JP 3 月 18 日 2 架构要求高了，上限高了， 实际上不用 AI 的话你把需求扔给同事输出的东西你一样维护不了，代码质量并不能保证比 AI 强， |
 | 12 cominghome 3 月 18 日 一句提示词下去拉了七八页大的，这还 review 个鸡毛。vibe coding 关注输入输出行了，对了，让 ai 把测试用例写好 |
 | 13 imagecap 3 月 18 日 让 ai 干这个，干那个，说实话效率是真的低。在生成代码只适合做 demo ， 工程化的成本不是一般的高， 尤其是在屎山上用 ai 拉屎，ai 吹不是蠢就是坏 |
 | 14 whusnoopy 3 月 18 日 最近的体验恰恰相反 在一个良好构建的大型项目里使用 AI 来清理和重构部分过时代码，在我对架构熟悉且知道自己在干什么的前提下，AI 能显著加速我的过程，也没有失控乱改，对原有架构有变动的话我会判断，是 AI 瞎搞要他改回去，或确实是更优解，可以按更优方案推进 |
 | 15 94 3 月 18 日 所以《软件需求分析》是单独的一门必修课程…… |
 | 16 0o0o0o0 3 月 18 日 简单来说就是 ai 和人类没有对齐 |
 | 17 novaline 3 月 18 日 道和术的区别 |
 | 18 houshengzi 3 月 18 日 又回归到重修大学的《软件工程》这一课 |
 | 19 yplam 3 月 18 日 把代码架构设计好，效果会好很多，尽量把独立功能解耦出来，单个包的代码量控制在 AI 能有效处理的范围内 |
 | 20 lindas 3 月 18 日 没关系，以后的事情就留给以后接手的同事/AI 吧 |
 | 21 Orlion 3 月 18 日 恰好最近维护一个老项目，有类似的感触：背景是一个老接口需要增加逻辑，但这个接口年久失修，代码逻辑一坨答辩，很难看懂，干脆让 AI 直接写，写完之后其实还是不敢 keep 进代码库。最终还是在 AI 的帮助下把逻辑理顺了才 keep 进代码库。所以在现阶段，即使有 AI ，还是依赖对代码库理解透彻的负责任的研发，这两个特性缺一不可。 |
 | 22 swaylq 3 月 18 日 跟 #14 有同感。问题不在 AI 本身，在于很多人跳过了架构设计直接开始 vibe coding 。我这边的经验是把模块拆小、接口定义清楚，AI 在单个模块内写代码质量其实还行。一旦让它跨模块搞大动作，基本就是在给自己挖坑。说白了 AI 放大了"不做设计直接写"的后果，以前人肉写烂代码至少还知道烂在哪，现在 AI 写的烂代码连定位都费劲。 |
 | 23 hkz670 3 月 18 日 1 确实，现在很多人已经把软件工程理解成了‘Ctrl+C 需求，Ctrl+V 给 AI ，出了问题算程序员态度不够积极’。需求不清楚不要紧，架构没设计不要紧，代码能不能维护更不要紧，反正先让 AI 糊一版出来，出了坑再让开发背锅就行。 说到底，AI 现在最大的价值之一，可能就是让一些本来就不尊重研发流程的人，更加自信地不尊重研发流程了。 |
 | 24 wqhui 3 月 18 日 一直都没多少人能把自己的需求想清楚，对于复杂的系统来说就是灾难，只能是纯黑盒，出问题就修一修 |
 | 25 chimission 3 月 18 日 你把 ai 当做的实习生对待， 技术方案一定是要是自己的想法，你可以把草案喂给 ai 来完善，你来 review ，不合适的地方就改掉，最后才是让 ai 根据完善的技术方案来实现。一定不要让 ai 从头到尾接管，想象一下你直接让实习生来做一个系统，那一定是失控的 |
 | 26 timethinker 3 月 18 日 AI 拉低了编程入学门槛，但同时也一定程度上封堵了迈向高阶的道路，当新人习惯了在几分钟之内生成成千上万行代码的时候，阅读代码本身已经变得不再具有现实意义，即便是资深工程师，在面对海量生成的代码时也会望洋兴叹，因此将来的工程可靠性是一个问题，数量级完全不对等，解决办法只能是用 AI 来驯服 AI 。 我在想，当 AI 的结构范式稳定以后，将来可能会冒出一门全新的学科。这门课不教你怎么写具体逻辑，而是研究怎么在高维层面控制通用模式的组合与应用。它的核心目标是在工程实践中对冲掉那些由于过度生成带来的混乱和复杂度。说白了，就是把人的想法和 AI 的算力强行对齐，建立一套从混沌中压榨效能的协议。 |
 | 27 zerovoid 3 月 18 日 哪怕是人力代码时代，都有可能因为需求和架构问题，导致系统设计出问题， AI 代码时代无非把这几十年的软件知识消化了，那该怎么出问题，还是怎么出问题。 |
 | 28 vst93 3 月 18 日 AI 幻觉“减轻”之后带来了严重的人类幻觉，特别是非开发人员 |
 | 29 adoal 3 月 18 日 这是好事啊（沙师弟说）。需求足够清晰才能写出好的程序。人写代码时，需求方，以及开发方的管理人员、商务人员不明白这个道理，或者不想明白这个道理，反正你需求搞得再凌乱模糊，写代码的人总会为了把代码写出来而做沟通细化需求，完成从模糊想法到精确描述的转换工作。用 AI 来写了，有些人以为可以淘汰大量程序员了，然后发现自己的描述能力根本不足以让 AI 确定你要做什么。那么无非就是以前一行一行写（粘贴）代码的继续做这个从模糊到精确的转换，只是不用一行一行代码输入或者贴入了而已。 |
| 30 adoal 3 月 18 日 事实会打脸每一个不写代码/不会写代码/不想写代码却言之凿凿认为有 AI 就不需要程序员的人。 |
 | 31 guqikang 3 月 18 日 AI 写-》 AI 改，有问题，AI 的问题，要我手动改？没办法，我是前端不会 java  老板：那还是让 AI 改吧～ |
 | 32 yifangtongxing28 3 月 18 日 那是你的事 老板们只动嘴 |
 | 33 macscsbf 3 月 18 日 https://www.nodeseek.com/post-653656-1 我在开发一个工具来改善这种情况。 |
 | 34 xiaomimicoin2 3 月 18 日 以前 让 开发团队 对接个东西, 对方 api 的阅读就要一个星期. 从开发 到出结果, 大概 2 周以上, 还是比较简单的需求. 这, 现在只要 自己需求清楚 ,功能出来很快. ai 是全栈吧. |
 | 35 HotieCutie 3 月 18 日 AI 出来后，所谓的技术大佬认为 AI 太强了，几乎可以只通过提示词就能完成任何开发，他认为不需要去看 AI 的代码是怎么实现了， 你只需要说明白自己的需求，然后 AI 做完后去验收，有使用上的问题，就让 AI 改。关键他自己也没通过 AI 做出什么能商用的 产品来，反而不断地要求我们使用 AI 去快速完成所有需求，时间不断压榨，而且还要多线程使用 AI 进行开发，反正就是搞的 极其的烦，做出来东西如果有问题，他就说你没用好 AI ，不会用 AI ，为什么不多学学怎么用。唉。。。 |
| 36 HotieCutie 3 月 18 日 而且如果被他看到你还在手搓代码，又是一顿责怪，说 AI 比你聪明，写的肯定比你好，自己写不累吗。 呵呵，有些很复杂的逻辑，想让 AI 搞明白都难，写出来有问题又是一顿说，时间又紧。 非常精神内耗 |
Select Language