虽然 AI 编码很厉害，但是这些问题怎么办呢？

[6581]

AI 大大提升了编码的生产效率，让很多难点都比较容易结局了，但我遇到了以下问题，有没有同感的朋友们呢？大家如何解决的呢？

1. 自己越来越不会写代码了
2. AI 写的代码有些啰嗦，有很多不太优雅
2. 对项目的把控很低，害怕代码有问题

评论区总结：
1. 大家对于用 AI 去写代码是没有任何异议的
2. 大家再说说 AI 的代码是需要去约束

有些观点很受启发：

1. AI 带来的效率提升会导致质量下降是正常的
2. 程序员对 AI 生成代码失去掌控感是 人脑算力更不上的表现
3. 使用 AI 就像是遛狗，你要控制绳子的范围，尽量让狗按照预计的路线去走


结合大家给的建议，我现在创建了几个文件：
<项目架构约束.md>
<代码规范约束.md>
<需求实现约束.md>

补充：

最近全面拥抱 AI ，其实一直也拥抱着，不过最近拥抱的方式比较好了。

1. 首先就是使用上面的约束好，代码质量好了很多
2. 现在每次写一个新的需求的时候，我都一次性把需求描述很清楚，让 agent 去做，我会花半天的时间把需求写好，然后让 ai 去执行，和我方案拉齐，然后等等，有一套固定的工作流，感觉 token 花费的也少了

[eod]

人和代码，有一个能跑就行

[sth2018]

正如《纳瓦尔宝典》所说的,判断力是决定成败的最关键技能.AI 编程后更加考验我们的判断力,代码审查能力

[theohateonion]

1. 这个不是问题，能高效生成了为什么还要手写。
2. 这个是你作为工程师要解决的问题，怎样让代码不啰嗦，让他变得符合你优雅的定义。你需要加 rule ，做好上下文管理。
3. 这个也是你作为工程师的要解决的问题，如何建立可信的验证机制，确保不出大问题。或者即使出问题了，如何快速识别和回滚。

[6581]

@eod 腿受伤了，跑不了了

[yeyeye]

你写代码的时候，会关注汇编层面的内容吗？

事实上你并不关心，你只关心产出和结果，小概率会观察性能然后优化（但也不会跑去汇编层优化）

而且 ai 产出这么多，已经没可能一个个看了，真的看不过来，你还没看完这一版，下一版又来了。

[Edward4074]

1. 多考虑代码之外的问题，比如产品层面
2. 就当成这代码是同事写的，同事写的代码只要能保证正确性，细节你也不会太多干涉是吧
3. 换个方式“把控”项目，从架构上判断哪部分“可能”有什么问题，至于具体的问题核实和分析优化仍然交给 ai

[sagnitude]

你要从写代码的变成 tech leader

[6581]

@theohateonion 嗯嗯，感谢感谢，是可以落地的一些东西

[yesterdaysun]

我认为不能简单的类比代码到汇编, 代码转汇编这个 gap 很小, 预期发生偏移的概率很小, 但是从一段需求文本到方案再到代码实现, 这中间经历了 2 次转换, 2 个 gap, 这里面预期发生偏移的概率非常大, 偏移带来的结果短期影响比较小, 反正能跑就行, 但是长期直接就是一坨 ai slop, 难以维护下去, token 消耗飞涨, 改一个问题出两个问题, 然后等项目重写吧, 所以当前还是需要人在其中判断把控的, 虽然不排除几年之后, ai 这两个 gap 也被缩到很小, 那真就没人啥事了

[Yanickkk]

担忧是对的，以后编码能力就不在是一个被动锻炼的过程了（以前不得不手写，本身就是一个锻炼的过程），未来会变成一个需要刻意练习的过程。不讨论现在的就业行驶前的情况下，我认为 AI 对老手来说是一个巨大的帮助，解放了写代码的时间，虽然花了更多的事情去 Review 。对于新手来说，如何学习 & 刻意练习的门槛变高了

[user1284]

升管理后大大提升了编码的生产效率，让很多难点都比较容易结局了，但我遇到了以下问题，有没有同感的朋友们呢？大家如何解决的呢？

1. 自己越来越不会写代码了
2. 手下写的代码有些啰嗦，有很多不太优雅
2. 对项目的把控很低，害怕代码有问题

[imagecap]

人工智能 => 人工 Agent, 懂的都懂！

[6581]

@user1284 是的，现在程序员要制定比较好的规则和流程来生产管理代码了。

大家有没有好的对代码的约束，和管理流程呢？

[v2er119]

只要作为第一当事人判断力还在，问题不大。
复杂的问题，完全交给 AI 甩手不管，AI 一定会有和业务无关的多余的发挥。
区别是你对业务了解和参与的程度，还是一样会影响产品的质量。

所以，过往沉淀的语言编程和代码工程能力并没有作废。

[Lemonyi]

@6581 你说的是 Spec 驱动吧，SDD ，大厂一般都架构师或者高级弄好了，小公司也不需要

[zuokanyunqishi]

@theohateonion 这还是软件工程的能力,😄

[lyz0205]

vibe code 其实也是一个工程问题。
以前是人工写代码，确实能把控得很好，现在给够时间仍然可以把控得很好。
只是都还没有适应这突如起来效率提升，技术更新迭代太快了，整个行业都浮躁，都在害怕被落下。
至于自己会不会写代码，在我看来，原来使用的 Java 、c/c++、Python 也都是语言。区别是熟悉 Java 这些语言的人是我们程序员，范围比较小，而现在 vibe code 熟悉的人变成了所有人。共同点是 Java 会讲代码翻译成 JVM 的语言，而 vibe code 会讲自然语言翻译成 Java ，其实就是封装了一层，就像 Java 封装了 JVM 的指令一样。
最后慢慢沉淀吧，以前一个只会写 Java 而不知道 JVM 原理的人是没办法成为一个优秀的 Java 程序员的，给他自己写，写出垃圾代码的可能也很大。现在是都懂自然语言，但不懂得程序的运行原理，给他怎么搞，都是相当于以前用 Java 写增删改查。上来写个可运行的程序，就是我们以前写的 hello world 。

[theohateonion]

@zuokanyunqishi 是的，目前阶段，只要还是 LLM ，就不可避免的会出现上下文污染问题导致结果偏移，软件工程现在要解决的问题是如何组织合理的上下文让 AI 尽可能的聚焦，不然做的越多错的越多，最后的结果就是项目失控。

[ktyang]

1. 不会就不会，现在不会写汇编也不影响调代码不是。
2. 看你怎么加约束和管控了。
3. 对项目的把控度和对代码的把控度是两个问题。前者大量应用软件工程的方法，后者就放弃吧。

[hackyuan]

解决不了，不然最近各家 C 端产品：淘宝、美团、高德、腾讯等 bug 频出、样式错乱就不会出现了，吐槽帖很多。

[crysislinux]

你只需要记住公司是老板的不是你的，管理层不会因为你更注重质量就给你多发钱，反而可能因为耽搁了时间少给你钱。大胆的 vibe 大胆的 merge 吧，大不了 n+1 。

[wjv22019]

只有在 AI 生成代码前的设计文档和最后生成完成的总结文档调整，AI 的代码看不完，根本看不完

[hunono]

你现在关注内存地址\手动释放内存吗?如果不关注,你放心吗?不怕内存爆了?不怕内存泄露?不怕内存$%@#$^^?如果放心,那上面 3 个问题你担心什么?

[duanxianze]

因为你还在按传统的开发的方式思考，所以有这种想法，新时代应该有新的开发流程，整个流程的我才疏学浅想不明白，但基本上不该有 java go rust 这种东西，人类输出需求文档，ai 直接生成二进制代码，不需要关心 ai 中间是如何实现的

[LowBi]

现在的问题是如何把业务需求好好的通过文字及图片好好描述给 AI ，AI 的代码瓶颈不是屎山，而是人类的业务需求屎山。要尽量理解，确保 AI 不会被误导。业务一复杂大脑理清并组织语言超累

[snakejia]

这个问题看工资,以现在的工作和工资情况来说,干一天是一天

[xixi1412]

30 年前的版本：

1. 越来越不会写汇编了。
2. 编译器生成的汇编很啰嗦，有很多不太优雅。
3. 对项目的把控很低，害怕汇编有问题。

思维载体只是从编程语言换成了自然语言。

解：
1. 用高级语言（自然语言）编写，编译器（ agent harness ）会帮你处理好.
2. 配置编译策略（有什么代码洁癖和规范，就在 agents.md 中声明一下）
3. lint 解决代码质量，test 解决逻辑和业务质量，build 解决编译问题，agent 解决一切问题，你把控方向盘就行。

[wsseo]

现场出问题，领导一问三不知。

[quxiaojuncuiyue]

我觉得你最应该关心的是自己的腰包会不会瘪。你关心的上述问题，其实在非 ai 时代也存在。之前的时代里，你团队里难道就没有代码写的稀拧、啰嗦的人吗 就没有不服管不可控的情绪化的人吗？都有吧，这些都不影响项目上线。

[6581]

我觉的你说的很有道理，以后我就用自然语言去写代码了

[poxiaohy]

@yeyeye 这个类比感觉不对，汇编基本是正确的，但是 LLM 因为幻觉漂移问题会一本正经分析出错误结论。更类似你是组长，带了几个大模型 agent 开发（和人一样，不同 agent 能力参次不齐），然后没法 review 全部大模型的代码，怎么管控团队代码质量，本质还是软件工程的范畴。

[zpxshl]

@poxiaohy 现在好的 LLM 的幻觉很少了，而且还在不断成长中。很难挑出他们的逻辑问题了

[6581]

@wsseo 是啊，就是这个，自己对代码掌控很差啊

[zsyevan]

1. 自己越来越不会写代码了
但你应该越来越会“管理代码”。

2. AI 写的代码有些啰嗦，有很多不太优雅
各种用于简化代码的 skill ，检查代码重复的工具，你会用得越来越顺手。

2. 对项目的把控很低，害怕代码有问题
高强度的代码测试用例覆盖缓解代码逻辑问题， 代码鸟瞰图、项目观察工具会被开发出来，进而应用到当前项目中去。

[Parva]

1. “越来越不会写代码” ai 只会越来越强，变强的速度快得可怕，不要写代码了，渐渐不用读代码了。

2. “AI 写的代码有些啰嗦，有很多不太优雅” 这是模型问题，容易过度抽象、设计，可以加点提示词告诉它不要过度，或者加点 skill 比如 Ponytail

3. “害怕代码有问题” 可以问 ai 代码质量如何，架构规范合理，有没有文件膨胀；想办法从各种角度去验证它，比如让 ai 去做接口、压力、并发测试，截图测试。让 ai 做到从测试人员的角度去测它没问题就够了，不用担心上线后有问题，避免不了，手写代码也可能会有问题

[valkyrjaE]

你的问题都源自于对业务的掌控力不足，或者更直白点你看不懂 ai 写的代码

[poxiaohy]

@zpxshl 还是不行，我的项目有些 bug ，弱点的模型就找不出来，经常需要几个互验。可以去看看屎山代码测评，不同模型能力差距还是有的，大的项目特别明显。

[archxm]

这是杞人忧天

[ethan2jam]

我自己的看法是可能得自己私下练练，哪怕是看点面经都是好的。虽然我不知道未来程序员会发展成什么样，但是就目前来看，找工作时面试官还是会问你八股和过往项目经历。

[vfs]

1. 自己越来越不会写代码了: 就像很多人不会写汇编一样, 习惯了就好了.
2. AI 写的代码有些啰嗦，有很多不太优雅: 反思自己, 是不是自己代码风格太粗矿了
2. 对项目的把控很低，害怕代码有问题: 还怕出问题就多写测试.
(哈哈)

[qianckjuan]

token 够用吗，够用让 ai 写 testcase ，然后让 ai 拿着测试环境去测试。
就是让 ai 把 qa 的活也干了

[6581]

@Parva 好的，已经用上 Ponytail 了

[fzls]

1 和 2 不算问题，3 确实是个问题-。-
我让 AI 写的代码我都会看一遍，然后如果其中有些看起来不符合我的习惯，或者有问题，就让 AI 再调整下，这样提交进去的时候至少我也大致有数，不然时间久了根本不知道仓库现状了，就失控了

[songco]

总要留个人背锅的，不用担心

[catazshadow]

拿汇编做类比的是大错特错，高级语言到汇编的编译过程是确定的，哪是现在这些 LLM 搞出来的概率抽卡？

[foryou2023]

老板不会写代码，有员工会写就行了。老板会在意代码写的稀烂么？只在乎功能是否能完成就行了。

[noahhhh]

项目的文档一定要自己写，长项目 AI 压缩上下文，大量 tool call 很容易忘记重点，测试方法也要看

[halida]

1. 自己越来越不会写代码了：错了，天天审核代码，要知道怎么写。
2. AI 写的代码有些啰嗦，有很多不太优雅：骂他，让他改好了才能提交。
2. 对项目的把控很低，害怕代码有问题：所以要看代码。

总之长期的代码还是要看。短期的无所谓。流程知道就行。

简单的说就是把自己当成架构师，架构师怎么做就怎么做。

[zerovoid]

能跑就行，
难道你工作的代码都是你从零开始写的吗？
你接了屎山代码的项目，你敢改？

[sentinelK]

曾经也有人质疑汽车引擎 ECU 电喷控制不如自己的拉线油门+化油器。
自动变速箱不如手动。

[wsseo]

很多人的对比都不对。