写了一篇博客关于现在公司内的 AI Coding 现状，不少朋友都来和我反馈，说很贴切反映了他们的工作现实。大家一起以不同的靠谱程度大量 AI Coding ，协作起来真的非常痛苦。所以特别分享这篇文章在 V2EX ，可能可以获取更多共鸣。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
 |
1
poxiaohy Aug 31
60 分和 80 、90 分的差距不是 AI 带来的，古法编程时代一样有这个问题。最近大家讨论 AI 编码问题，无论尽职的个人软件能力也好，技术架构问题的个人硬件实力也罢，AI 一直充当的都是放大器
|
 |
2
Chengyunlai Aug 31
文章写的不错，但是让我跳出了 v2ex
|
 |
3
sagnitude Aug 31
只不过古法时代可以体现在代码质量里面，很容易被 code review 看见罢了
|
 |
4
pluviacon Aug 31
确实不是会不会用 AI 的问题，而是有没有理解需求和现有代码的态度问题
有些提交看着能跑，但小功能都能写得又长又绕，Review 完了感觉还不如重新实现更快 |
 |
5
JobsHwang Aug 31
最近也有相同感悟。
「尽职编程」某种程度上就是：agent 能同时做越来越多的事，但最后仍要由一个有限的人守住上下文、判断和结果责任。 |
 |
7
yangwa Aug 31
方案不错，但是得有眼光的管理层，允许 review,和以前古法时代一样，没有多少项目组会给时间去做 review ，这种矛盾小，个人的尽职会越来越减少
|
 |
8
liushengxian1230 Aug 31
确实觉得如此。
不过公司内的个体差异探讨的前提在很多公司不成立，可能没有统一报销大家自己买自己的，或者用不同的模型/agent/hareness 都有可能，所以互联网上鲜有人讨论 |
 |
9
did Aug 31
同事 A: 这代码是我让 AI 写的，具体情况我也没看呢，有什么 bug 你就问 AI 让他给你修改。 同事 B: 这一看就是 AI 写的垃圾文档，都是重复的内容，至于是不是(其实不是)。 目前所在公司的真人真事。
|
|
10
did Aug 31
ai 是放大器，他会放大优点，也会放大缺点。
|
 |
11
Josephwaaaa Aug 31
同事用了 AI 以后对重构屎山代码的信心大增..
|
 |
12
nakun233 Aug 31
有没可能 review 这块也要形而上，人不能成为瓶颈
|
 |
13
SilenceLL Aug 31 via iPhone
巧了，刚在 x 刷到
|
 |
14
issakchill Aug 31
这确实是新时代的的新课题
|
 |
15
bwnjnOEI 4 days ago
看到你也花大量时间在理解模型产出的文档上我就没往下看了因为我也一样。抛开这点，agent 失败的地方都是文档内容点之间的空隙，你也是吗？
|
 |
16
monkeydream 4 days ago
你就是懂技术的项目经理，把 AI 当作产品、架构师、高级开发、测试来用。
项目经理不是啥都不管，得看文档、技术架构、任务执行情况、测试结果评估是否要调整。 |
 |
17
c0nstantien 4 days ago
个人认为 IT 因为 AI 的介入，开始由技术向社会工程转变了
|
 |
18
JasonYip 4 days ago
AI 训练的模式让它很擅长回归一个目标明确的任务，即使这个任务很难你也会发现他竟然能完成的很好。但是问题就恰好也出在这，尽管模型能力、harness 本身都在尽力降低用户的心智负担，但是永远没办法一步到位帮用户与 LLM 对齐上下文语义空间。一旦 LLM 与用户理解的语义空间的距离越大，那么 LLM 发生超出用户预期的情况也会越多。因此，很多人实际上连和人沟通都费劲，何况让 ai 去猜他的上下文 XD
归根结底还是有很大一部分的人在做许愿式编程，即使 harness 已经超前帮用户做到了给一个 PRD 生成一个 spec ，甚至会让用户不断讨论。但是这些人依旧在欺骗自己，在关键的 spec 审查和决策的时候随意处置。当然这也是侧面反映出 OP 所说的，很多人其实对于自己 coding 的代码不负责任。 个人感觉 ai 时代更加突出的瓶颈是人与人之间协作，人之间交换信息的效率。不负责任的人沟通起来费劲，不带上下文、充满错误、不慎重的沟通，加剧了这一点。 |
Select Language