过去两年在工作中看到令人不安的一面————用 AI 掩饰根本性错误,忽视对事物本质的思考。
第一个案例是评审 Email 相关的需求,这个需求其实可以用另一种方式实现更简单,然而有个老员工用 DeepSeek 然后说可以实现,事实确实可以实现但没必要,换一个方法更好。
第二个案例是去年离职的一家 IT 公司。它也在推广 AI 的使用,比如 Cursor ,用 AI 整理文档等等,还要填写 AI 减少多少工时。有趣的是项目架构设计错误,用 MVC 强行嫁接 ETL ,结果产生大量上帝方法和上帝类,新人很难理解,领导就说“不懂得用 AI 整理?”,可是理解困难的主要原因是架构问题,而且业务流程也设计错导致成本很高。然后用 AI 检查代码,结果许多人提交了代码卡在 Code Review 改了很久导致需求延迟交付,归根结底仍是架构的问题,管理层也不去解决,反正 AI 说要改就改。
这两个案例可以总结出一点,当前部分员工/企业正在将 AI 作为“合理化错误”的工具,AI 说需求能做就执意推动而不考虑更优方案,AI 被错误地使用后工作会更累,因为根本性问题永远得不到解决。
自己最初接触编程是在 13 岁,14 岁就会用 Access 和 Delphi 独立构建信息管理系统并打包加壳,写帮助文件,所以对技术和产品的认识长达 16 年,虽然技术过时但核心理念从未改变:以用户为中心、识别和控制风险、流程不能成为效率的枷锁,可靠、易用比华丽的界面更重要······。
总之,在 AI 提供便利的同时不要忽视对事物本质的思考,更不能将其作为掩饰根本性错误的工具,直面问题的本质才能更好地解决问题,否则一切都是空中楼阁。
1
dji38838c 7 天前
如同很多人所预言
大家都懒得思考了 |
2
JoeJoeJoe PRO 现在的 ai 能力还不足以让人无条件的信任
code review 是必不可少的 |
3
v21984 6 天前 via Android
背锅也是 AI 的工作之一
|
4
fuzhao77 6 天前 via Android
终于有人发现企业错误的使用 ai 会导致企业自身更加的停滞,我写过一篇论文,就是关于 ai 不能滥用,并不是所有企业所有业务对 ai 都适用,只是我是个农民,说话还不如放屁,我写的也不是正规论文格式因此没有发表,国作登字-2025-A-00319004 ,因此我决定先申请版权,等有些企业因此倒霉了,有专家开始说了,我再拿出我的版权作品说明我早就发现了这个问题。
|
5
cyp0633 6 天前
ai 不是银弹,为了 ai 而 ai 不可取
|
6
sampeng 6 天前 via iPhone
我现在最反感的是当我提出一个疑问被人甩 AI 的回答,我去,我御三家都是在用的,我不知道自己问么。我就是要问这个问题根因是什么,我提出来就是问潜在坑怎么搞,ai 是无法总结人类 Ai 在问题上踩的坑的。
|
7
kenshinhu 6 天前
同感,也有想过未来是否越是依赖 AI 就会越是被困,毕竟已经可以解决生活中的大部分事情从而不再去思考。
|
8
akira 6 天前
不确定你们是怎么使用 AI 的 ,如果只是打开 gpt 去问,那只是基础的用法 。 进一步的 是需要不断的迭代更新 相关的提示词 以及 上下文 的
|
9
fzls 6 天前
AI 是个好东西,但用的人也需要有能力去判断 ai 给出的答案是否有瑕疵,可以用来省时间,但不能用来完全替代思考
|
10
zhang666 6 天前 via iPhone
Ai 一会拉进低端代码工作者和中端代码工作者的距离,顶级的 ai 还做不到,ai 目前写出来的上下文深度太低。一个顶级代码工作者,知识的系统性,经验,汇总起来,感觉要几百 M 的上下文才可能。现在一般 ai 上下文才 200k 太少了
|
11
nnnnnnamgn 6 天前
ai 没问题,强制用 ai ,为了用 ai 而用 ai 的公司有问题,比如微软用 ai 搞了一堆垃圾
|
12
zhanshen1614 OP @akira 有完善上下文和提示词但这个要审批的,领导发现上下文和提示词试图让 AI 判断架构设计和伪需求这种根本性问题有时候会带来不必要的麻烦。
|