#AI代码

1周前

我司代码现在 50% 是 AI 写的，我觉得应该无人在意，老板也很开心。但如果金融系统的代码是 AI 写的呢？特斯拉 FSD 的代码是 AI 写的呢？大型医疗设备的代码是 AI 写的呢？人类早晚得在 AI 身上栽个大跟头…

#AI代码 #金融系统 #特斯拉FSD #医疗设备 #潜在风险

傅盛 Fu Sheng

2周前

我觉得现在AI代码的可读性、合理性超过了大多数人类了，为啥还有一群人在说AI代码是💩山代码？

#AI代码 #可读性 #合理性 #人类 #观点争议

4周前

我觉得接下来不久，各种公司就要为自己过去一年AI写的代码偿还技术债了

#AI代码 #技术债 #公司 #负面 #未来

1个月前

软件工程师不必担心被人工智能取代，但要警惕一个更现实的挑战：未来他们可能需要维护由人工智能生成的、日益庞大的"遗留代码"。这一天正在加速到来。一个典型的企业场景：某个部门为了快速上线新功能，调用AI工具自动生成代码。这些代码可能在短期内解决了效率问题，但随着时间推移，问题逐渐浮现——代码注释模糊、模块间逻辑混乱、缺乏统一接口，甚至存在未被发现的bug。当原始开发人员离职或转向新项目时，留在系统中的"AI代码"就成了烫手山芋。这种情况正在多个行业真实发生。某互联网公司的支付系统因AI生成代码出现逻辑漏洞，导致交易异常；某制造业企业的供应链管理系统因AI代码缺乏安全审计，被黑客利用。这些案例揭示了一个核心矛盾：AI能快速生成代码，却难以保证代码的可维护性和可靠性。对软件工程师而言，应对这种变化的关键在于转变思维。与其纠结AI是否会"抢饭碗"，不如主动学习如何与AI协作。例如，利用AI生成基础框架，但保留核心业务逻辑的设计权；建立代码审查机制，对AI生成的代码进行安全和质量把关；将AI工具作为效率工具，而非完全依赖。真正的风险从来不是技术取代人，而是人被技术的产物所困。当AI生成的代码占据系统的大部分，工程师的价值将从"编写代码"转向"修复代码"，甚至"重构代码"。这要求从业者必须持续提升编程素养和系统思维，在拥抱新技术的同时，保持对代码质量的敬畏之心。技术的进步从不意味着职业的消亡，而是能力边界的拓展。对于软件工程师来说，理解AI的本质、驾驭AI的工具，最终构建可靠的系统，才是面向未来的正确选择。

#AI代码 #软件工程师 #代码维护 #技术风险 #人机协作

1个月前

最近一个月找了个兼职，干的就是一个后台简单的数据CRUD系统。这个系统很特别，全部代码都是用AI写的。我来的时候前端有基本的功能页面和后端的一些基本的数据库表。看起来是一个像那么回事的系统。我在这里面干了一个月，最后实在受不了 AI 生成代码导致的混乱而离开。之前我没有这么大规模的使用AI，也没有这么大量的用 Claude cli。一开始我刚进来工作还尝试手写点代码，然后做小的改动。项目里面几乎全是 AI 生成的代码，我很难去做改动，加上我对 react 那坨东西也不太熟悉。人脑对代码的理解很难跟得上 AI 产出代码的速度，看了没多久我也放弃了手工写代码，全部改用 Claude cli 来写。一开始用 claude cli 很惊艳。我用一些很简单的prompt让它去添加某个页面，某个 list 组件，它能很快的做好。而且做出来的前端效果居然完美兼容整个前端 ui 风格，没有乱生成不同风格的 css。这可能也是得益于 react 的功劳。不得不说 Claude cli 写 react 真的很强。很少翻车，也很少会弄出你不想要的功能。然后我进入了这个项目的深坑，一个 C 语言写的系统底层。一开始遇到的坑就是编译链接。这个 C 项目本身有一套 makefile，但也是 AI 生成的，会经常出问题。然后就让 AI 去修复编译链接相关的问题。修着修着 AI 会自己写一个 shell 脚本自己去编译。然后我这一个月有很大一部分时间在为 AI 写的这个 shell 脚本修车。不得不说 c 项目的编译依赖是一个极需精力维护的东西。一旦涉及到动态/静态链接，第三方库依赖，各种改代码翻车的事情就会出来。然后 AI 生成的代码编译时会有一大堆的 warning，出错时你要在这一大堆的 warning 里面找 error，然后贴给AI，让它去修复。为什么不让 AI 去做编译？理由很简单，太费token了。如果不省着点用，全部让ai去操作一切，AI 读编译结果输出是一大笔 token 开销，会被 Claude 限制。本身 C 项目代码 AI 写起来似乎不难。它能很快的完成一些指定的任务。但面对 segment fault 这种事情也很无力，更不要提查内存泄露的问题了。segment fault 要开 debug 模式把内存布局 dump 出来交给 AI 才能改。另外就是对与一些细小的问题像空指针检查，计算 strlen，memory length，和 tcp package length 这类问题经常会翻车。还有就是你要检查出以上问题出现在什么位置也很难，你只有不断的告诉它在哪里加 log，然后通过 log 判断哪里有问题。或者直接把 log 丢给它，让它去修复。这样每完成一个功能需要花费大量的时间去 debug，最终算下来 debug 的时间并不比开发的时间少。这个项目另外一块用的是 golang 开发的后台系统。得益于 go 本身就很简单，完成某些特性的写法也只会有一种。 AI 写 go 代码是非常容易的。而且维护起来比前端 typescript 和 c 语言要容易得多。容易出问题的地方就在数据库的 migration 上。你把这块交给 AI，就很难得到一个能够在多个环境里保持一致的数据库 schema。得益于 go 语言本身容易阅读的特性，你可以很快速的读明白 AI 生成的代码是干啥的。也能很快速的知道它生成的代码很多是有很大的问题的，经常会舍近求远的写一些不必要的代码，或者用很复杂的方式实现一个很简单的功能。而那个很简单的功能只需要调用其他模块的一个接口即可。然后 AI 会在一个模块里面把代码越写越多。这也可能是 Claude 为了节约读 context 的复杂度，经常能看到 Claude 会拿 grep 命令在代码里面搜来搜去。由此可见 AI 代码的模块的划分和改动是很无力的。极容易产生出一大坨代码全放在一个模块里面的情况。这个项目我后面几乎都在调试接口返回的数据是否正确，功能实现是不是正常，端到端网络通信是不是可靠的发出来了，另一边是否正确的接收了。然后还遇到另一个问题就是几个同事一起协作时，merge 代码时产生的痛苦。由于大家都是用 AI 在写代码。提交上来的代码冲突不断，merge 代码时即使是自己这一方写的也判断不出来冲突该如何合并（因为全是 AI 写的）。AI 会经常生成一大堆代码，这也让 merge 代码的工作更加雪上加霜。经常会出现一个功能写完后，可能会不小心在 merge 的时候被删掉。这也对协作产生了不小的挑战。我最后离开的原因，就是我一天吭哧吭哧的干了不少时间，最后实际上看到的产出却很少，全都是在修各种各样的运行问题和 debug 一个功能是否真的如预期那样可靠。时间浪费不少，同时又拿着别人的钱在干活，最终又没干多少活。这样对大家都不利的局面我还是及早退出算了。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1144 条信息

#AI代码 #代码调试 #C语言 #Go语言 #协作困难

1个月前

useEffect 又立功了，Cloudflare 的 API 挂了，这么大的事故，原因竟然是 dashboard 当中的一个 React useEffect 没有写好： “在依赖数组中包含了一个有问题的对象。由于这个对象在每次状态或属性变化时都会被重新创建，React 将其视为“始终是新的”，导致 useEffect 每次都会重新运行。因此，API 调用在单次仪表板渲染中执行了多次，而不是仅执行一次。” 最终 DDoS 了自己。我怀疑这代码是不是 AI 写的。😄😄

#useEffect #Cloudflare API 故障 #React #DDoS #AI代码

2个月前

很多同学还是不清楚为什么要用语音输入。因为语音输入可以大大提高我们 AI 写代码和写作输出，做自媒体本质上就是内容，内容就是生命线，通过持续地分享、输出内容，来增加流量而想要更多内容，语音输出是能够大大提高我们的输出效率的。为什么有的人在边工作之余，还能够去写作大量的内容？本质上就是因为他把随时自己记录到的一些灵感和思考，第一时间记录下，久而久之自己的素材内容越来越多，形成持续的复利效益。我自己今年明显感觉对创业有一个比较好的掌控感，本质上就是因为我对于内容输出有了一个新的提高。

#语音输入 #AI代码 #写作 #内容输出 #自媒体

2个月前

兄弟们，请教下你们是怎么放心，让AI写代码的？我之前试试，它总是错啊

AI编程工具激战：Claude Code、Gemini Cli崛起· 1144 条信息

#AI代码 #代码错误 #AI信任度 #程序员 #质疑

2个月前

我这段日子的主要工作就是在 review 同事们自己本地 Vibe Coding 生成的未经仔细 review 就 push 上来的代码，如果说 review AI 生成的代码是在给 AI 铲屎的话，我现在属于云铲屎官了

#Vibe Coding #代码审查 #AI代码 #云铲屎官 #消极

3个月前

关于AI写代码，确实很难完全替代人类编程，这是共识没错。但在需求侧，一个更有趣的现象正在发生：既然AI不能帮我完成所有功能，那么我就只选择AI可以完成的功能去做，然后等着AI迭代升级。而不是再去雇个程序员，去完成那20% AI写不好的代码。特别是对于前端，这是个挺要命的失业倾向 ... 从更广泛的市场看（非互联网技术公司），后面可能更需要熟悉AI能力边界的AI工程师，而不是精专某个领域的程序员团队。他们只需要用AI快速写东西解决问题，到这一步，有8成的需求可能已经覆盖了，如有需要，后面再找外包做完实在需要，又不能用AI写好的部分就可以了。而紧接着带来的问题只是，如何在设计阶段让AI划分和设计好架构，让人类开发者更容易接手补漏。只会CURD/CSS的程序员或将广泛失业，毕竟AI即用即付，不需要缴纳社保，外包也是

AI编程工具激战：Claude Code、Gemini Cli崛起· 1144 条信息

#AI代码 #程序员失业 #AI工程师 #需求侧变革 #技术外包

3个月前

未来可能没有原型软件了因为没有人会浪费时间跑去画图了可以靠嘴遁ClaudeCode直出了胆子再大些 PM直接干工程工程直接修AI代码就完了…

AI编程工具激战：Claude Code、Gemini Cli崛起· 1144 条信息

#原型软件 #ClaudeCode #PM干工程 #AI代码 #软件未来

4个月前

大部分人都说AI写代码只能提效20% 这事儿是搁在23年用github copilot 写一个youtube爬虫，从前1个多月都写不完 ClaudeCode只需要给它代理池和所有要求信息，1个小时之后，代码一个字符没改，直接采集效率飞起想想吧，1小时vibe coding VS 1个月做不出来这就是AI的力量，对于构建一个新东西而言，差的已经不是百倍生产力了说只能提效20%的，绝大部分原因是什么？因为那坨屎山代码，就算换一个人类来，没人讲一遍也很难上手干明白屁文档没有，代码又一坨答辩，耦合着大量业务逻辑，你指望AI能写明白？人类都写不明白，咋指望AI提效…… 甚至还有的代码里有一大堆错字，比如craeted time，这玩意AI写不出Bug就奇了怪了别抱着屎山啃了，人就负责写指导文档，100% AI Native挺好如果你能保证仓库让任何一个实习生来了参考下文档都能上手，那AI绝对能改的飞快

AI编程工具激战：Claude Code、Gemini Cli崛起· 1144 条信息

#AI代码 #生产力提升 #代码质量 #AI native #效率飞起

大喵(8年前端讲师，能教你学会编程)

4个月前

发现用ai写多了代码后，自己再动手改/写代码就会觉得烦躁，觉得太慢，觉得在浪费自己的时间

AI编程工具激战：Claude Code、Gemini Cli崛起· 1144 条信息

#AI代码 #效率降低 #编程烦躁 #依赖AI #负面情绪