一名云计算从业者的思考

大家都在搜：

热搜词1 热搜词2 热搜词3

当前位置：首页 > 产品思考 > 正文内容

AI Coding 的危险，不是写错代码，而是让人放弃判断

anycodes17小时前产品思考50

这两年 AI Coding 很热，热到一种有点奇妙的程度。

以前大家写代码，哪怕是去百度、Google、Stack Overflow 找一段代码复制回来，中间至少还有一个“人”的过程。你要知道自己想找什么，要判断这段代码是不是适合当前项目，要改变量名、改逻辑、改依赖，还要在脑子里过一遍它为什么能跑。这个过程可能低效，也可能笨，但它至少让人参与了判断。

AI Coding 出来以后，这个过程被极大压缩了。很多人不再搜索，不再阅读，不再理解，而是直接说一句话，让 AI 生成。它确实带来了某种平权，让很多原本不太会写代码的人，也能快速做出一个页面、一个工具、一个小应用。甚至有人开玩笑说，文科生加上 Claude Code，就能顶一个很强的理工科毕业生。这句话当然夸张，但它背后有一个真实变化：**AI 把“生产代码”的门槛降下来了。**

我不否认这个变化的价值。相反，我觉得这是一次非常重要的生产力释放。AI 写代码、写材料、整理信息、生成初稿，这些都会成为未来工作的常态。今天很多公司都在讲 AI 提效，有些团队甚至会把 Token 消耗、AI 使用率、AI 生成材料占比当成一种组织效率指标。这个现象背后说明，AI 已经不只是一个工具，它开始变成组织管理和效率叙事的一部分。

但问题也正在这里出现。

**当一个组织开始把“用了多少 AI”当成效率指标时，它可能已经悄悄把“有没有思考”这件事放到了后面。**

AI 很擅长做确定性的事情，尤其是那些已经被大量人做过、被大量文本描述过、模式比较清楚的事情。写一个常见页面，补一个接口，生成一段 CRUD，整理一篇材料，做一个会议纪要，它都可以很快，甚至快到让人产生一种错觉：只要给 AI 足够多上下文，它就能把所有事情做完。

但真正难的事情，往往不是确定性的。

做产品尤其如此。产品经理真正有价值的地方，不是把已有答案组织得更漂亮，而是在没有标准答案的时候做判断。行业里现在没有这个东西，我们要不要做？一个看起来小众的方向，是不是未来会变大？一个用户今天说不需要的能力，是不是三个月后会变成核心诉求？一个功能眼前能带来增长，但长期会不会破坏产品结构？这些问题不是简单的信息归纳，也不是把历史经验喂给模型就能解决的。

AI 可以给你概率最高的答案，却很难替你承担那个不被大多数人相信的判断。很多时候，产品判断恰恰发生在“历史经验不够用”的地方。真正有价值的机会，常常不是从共识里长出来的，而是从少数人的不舒服、不甘心、不相信里长出来的。这个时候，人是不是还有自己的判断力，就变得非常重要。

![](https://runor.cn/zb_users/upload/2026/06/202606140945233734218.png)

AI Coding 也是一样。

表面上看，AI Coding 是效率工具。以前一个人一天写几百行代码，现在可能一天生成几千行、几万行代码；以前一个需求要做几天，现在可能几个小时就有一个版本。团队的 Token 消耗上去了，提交量上去了，功能数量上去了，周报也变好看了。可问题是，这些代码真的被理解了吗？真的被 review 了吗？真的能长期维护吗？

我最近和一些公司、一些团队聊 AI Coding 的使用情况，一个非常真实的反馈是：AI 写出来的代码太多了，很多人已经没时间认真看了。代码评审当然还在，UT 当然也在，E2E 也可以让 AI 自己补，但当一天可能生成十几万行、几十万行代码的时候，人很容易从“评审者”变成“批准者”。他不再真正理解代码，而是在流程上点头。

这时候风险就开始变形了。

过去代码风险大多来自人写错了。现在代码风险可能来自人没看懂 AI 写了什么，却以为流程已经保证了质量。更麻烦的是，AI 非常擅长制造一种“看起来合理”的完整性。它会写注释，会补测试，会解释为什么这样设计，会把一个错误包装得很像工程决策。人如果没有足够强的判断力，很容易被它说服。

我见过一些很典型的问题。比如 A 做完一个功能，B 用 AI 改另一个功能时顺手把 A 的逻辑改坏了，但 B 只验证了自己的路径，于是代码就被推上去了。再比如 AI 在代码里写了一段看似解释性的注释，后续生成 E2E 或 UT 时，另一个 AI 又把这段注释当成事实依据，反过来为错误逻辑补上了测试。更极端一点，一个付款流程里如果出现“超时则默认成功”这种兜底逻辑，AI 甚至可能把它解释成“为了提升用户体验的优化方案”。如果测试也是 AI 写的，评审也是 AI 辅助看的，最后这个错误就会在一层层“合理化”里被放过去。

这才是 AI Coding 真正危险的地方。

**它不是让错误变少，而是让错误更像正确答案。**

以前一段糟糕代码，可能一眼就能看出很糙。现在 AI 生成的代码往往结构完整、命名合理、注释清晰、测试齐全，甚至文档都写得像模像样。它不再像一个明显的半成品，而像一个可以被交付的东西。可越是这样，人越容易放松警惕。因为我们的大脑很容易被完整性欺骗：一个东西看起来像工程产物，我们就默认它经历了工程判断。

但 AI 没有工程责任感。

它不知道这个功能上线后谁来背锅，不知道这个漏洞会不会影响客户数据，不知道这个页面是不是符合长期产品结构，不知道这段代码三个月后有没有人能维护。它只是在当前上下文里生成一个看起来最合理的结果。如果上下文错了，它会沿着错误继续生成；如果注释错了，它可能把注释当成规则；如果测试目标错了，它会为错误目标写出通过的测试。

所以我觉得，现在很多团队在使用 AI Coding 时，最需要警惕的不是“AI 写得不够快”，而是“人退得太快”。

当后端同学可以用 AI 快速改前端，产品同学可以用 AI 快速写脚本，运营同学可以用 AI 快速生成工具，这当然是进步。但如果所有人都能提交代码，原先依靠角色分工、代码熟悉度、模块边界建立起来的质量体系，也会被重新冲击。以前一个前端项目可能就几个人长期维护，每周发布几个功能，大家知道谁改了哪里。现在可能十几个人、几十个人都能借助 AI 往里面加东西，一周堆出几十个功能，代码量膨胀得很快。只要有一两个人没有理解规范，或者只是相信 AI 已经处理好了，整个系统的风险都会被放大。

这不是某个人懒，也不是某个团队不专业，而是生产方式变了以后，治理方式还没有跟上。

AI Coding 把代码生产平权了，但没有自动把工程责任平权。不是每个能生成代码的人，都理解架构边界、权限边界、安全边界和发布边界。不是每个能让 AI 补测试的人，都知道测试有没有覆盖关键路径。不是每个能让 AI 修 bug 的人，都知道它有没有引入另一个更隐蔽的问题。

更深一层看，这里面还有一个很有意思的变化：未来可能会出现越来越多“AI 写给 AI 看”的东西。

AI 写需求文档，AI 写技术方案，AI 写代码，AI 写测试，AI 做评审，AI 生成上线说明，AI 总结问题复盘。整个链路看起来非常自动化，非常高效，但如果人在里面只剩下审批、转发和确认，那么这个系统到底是在服务人，还是在绕开人？

这不是一个哲学问题，而是一个非常现实的产品问题。

我们做一个阅读网站，是给人阅读，还是给 AI 阅读？我们做一个视频网站，是给人观看，还是给 AI 消费？我们做一个 APP，是给人使用，还是给指标使用？今天大多数软件最终还是给人用的。人的感受、人的困惑、人的误操作、人的审美、人的信任，仍然决定了一个产品是不是真的成立。

如果一个系统从需求到实现都越来越由 AI 生成，而人没有在关键环节进行判断，那么它可能会越来越像“逻辑上成立的产品”，但不一定是“人真的愿意使用的产品”。

代码也是一样。代码不是写完就结束了，代码是要运行、要维护、要被排查、要被扩展、要承担真实后果的。AI 可以帮我们加速生产，但它不能替我们承担后果。一个安全漏洞不会因为是 AI 写的就少造成损失，一个错误付款逻辑不会因为有测试就变得合理，一个用户体验问题不会因为 PRD 写得漂亮就不存在。

所以我不太喜欢把 AI Coding 简单理解成“让每个人都变成程序员”。这个说法听起来很热血，但它容易遮蔽一个更关键的问题：**AI Coding 真正需要的不是人人都会写代码，而是人人都要重新学习如何驾驭生成出来的东西。**

驾驭 AI，不是会写 Prompt。会写 Prompt 只是很小的一部分。真正的驾驭，是你知道什么时候该相信它，什么时候该怀疑它；知道哪些事情可以交给它，哪些事情必须自己想；知道它生成的结果在哪里最容易出问题；知道如何设计边界，让它即便犯错，爆炸半径也是可控的。

这对个人是挑战，对团队也是挑战，对平台更是机会。

未来 AI Coding 一定会继续发展，AI 写材料、写代码、写测试、写方案也都会越来越普遍。阻止它没有意义，否定它也没有意义。真正重要的是，我们要为这个新的生产方式建立新的质量体系。代码量暴涨以后，传统 review 方式可能不够了；AI 生成代码以后，传统测试方式可能不够了；更多非研发角色参与应用生产以后，传统权限和发布流程也可能不够了。

这里面有一个很重要的判断：**未来 AI Coding 真正的基础设施机会，不只是代码生成，而是安全执行环境。**

因为未来的问题不只是“AI 能不能写出代码”，而是“AI 写出来的代码应该在哪里运行”。如果 AI 生成的是一个页面、一个脚本、一个爬虫、一个内部工具、一个自动化 Agent，它天然就可能访问文件、网络、数据库、密钥、企业 API，甚至可能对真实业务系统产生影响。这个时候，把 AI 生成的代码直接放进生产环境，或者直接在个人电脑、企业内网里运行，本质上都是高风险行为。

![](https://runor.cn/zb_users/upload/2026/06/202606140945353694163.png)

过去我们讨论安全，更多是在代码写完之后做扫描、审计和发布卡点。但 AI Coding 时代，代码生成速度太快，参与角色太多，传统安全流程很容易跟不上。更现实的做法，是默认把 AI 生成代码放在一个受控的执行环境里：权限最小化，网络可限制，文件系统可隔离，密钥不可直接暴露，调用外部接口要被审计，高风险动作要有人确认，运行过程要可观测，出现异常时能快速停止和回滚。

**不是先假设 AI 生成的代码可信，而是先假设它不可信，然后给它一个可控的运行边界。**

这个安全执行环境，未来可能会成为 AI Coding 平台、Agent 平台、Serverless 平台非常重要的竞争力。谁能让 AI 生成的代码更快地运行起来，同时又把风险收敛在一个可控范围内，谁就更有机会成为企业愿意采用的应用生产入口。因为企业最终不会只为“生成得快”买单，它真正需要的是：生成得快，但不要把系统搞坏；交付得快，但不要泄露数据；试错得快，但不要让错误扩散到不可收拾。

所以，接下来真正有价值的能力，不只是让 AI 更会写，而是让 AI 写出来的东西更可控。比如生成代码前能理解项目边界，生成过程中能遵守架构约束，生成之后能做安全扫描、依赖分析、权限检查、测试覆盖评估、运行时隔离和灰度验证。更进一步，平台要能识别哪些代码是 AI 生成的，哪些逻辑来自用户明确要求，哪些逻辑来自模型推断，哪些地方缺少人工确认，哪些变更可能影响已有用户路径。

这些能力听起来不如“十倍效率”刺激，但它们决定 AI Coding 能不能从个人玩具变成企业生产力。

我一直觉得，AI 时代最危险的不是人用 AI，而是人误以为自己已经掌控了 AI。

一个人如果很清楚 AI 的边界，AI 会成为非常强的放大器。它可以帮你更快试错，更快搭原型，更快生成材料，更快验证想法。但如果一个人并不理解自己要做什么，也不理解 AI 生成了什么，只是因为 AI 很快、很完整、很自信，就把判断权交出去，那么 AI 放大的就不是能力，而是混乱。

所以回到最开始那个问题：到底是人在驾驭 AI，还是 AI 在驾驭人？

我的答案是，短期内两种情况都会发生。会驾驭 AI 的人，会比以前更强；不会驾驭 AI 的人，可能会比以前更危险。因为过去不会写代码，最多是写不出来；现在不会判断，却可以生成很多看起来能跑的代码。过去一个人能力不足，产出有限；现在一个人判断不足，却可能借助 AI 快速制造大量风险。

这也许才是 AI Coding 时代最值得警惕的地方。

它让生产变快了，但没有让判断自动变强。它让更多人拥有了创造软件的能力，但没有让更多人天然拥有工程责任。它让代码看起来更完整，但也让错误更容易隐藏在完整性里面。

**AI Coding 的未来一定很大，但越是这样，我们越应该认真面对它带来的另一面：效率不是免费的，自动化也不是免费的。所有被 AI 加速的东西，最终都需要被人、被流程、被平台、被组织重新接住。**

否则我们很可能会看到一个很荒诞的局面：大家每天消耗越来越多 Token，生成越来越多代码，写出越来越多材料，做出越来越多应用，但真正理解这些东西的人越来越少，真正敢为这些东西负责的人也越来越少。

那就不是提效了。

那是把思考外包以后，留下了一地看起来很高效的风险。

扫描二维码推送至手机访问。

本文链接：https://runor.cn/?id=56

分享给朋友：

返回列表

上一篇：AI Coding 的终点不是写代码，而是应用生产入口

没有最新的文章了...

刘博说云

大家都在搜：

AI Coding 的危险，不是写错代码，而是让人放弃判断

“AI Coding 的危险，不是写错代码，而是让人放弃判断” 的相关文章

五个人教一个人点鼠标：云服务的荒诞现实

两种 FaaS 产品哲学：AWS Lambda 和 AgentCore Runtime 的专业化分工 vs 阿里云 FC 的平台进化

为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念

自证害死的不仅仅是产品经理，更是一个团队

回归产品思维：一位前产品经理的八点反思

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

AI Coding 的危险，不是写错代码，而是让人放弃判断

“AI Coding 的危险，不是写错代码，而是让人放弃判断” 的相关文章

五个人教一个人点鼠标：云服务的荒诞现实

两种 FaaS 产品哲学：AWS Lambda 和 AgentCore Runtime 的专业化分工 vs 阿里云 FC 的平台进化

为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念

自证害死的不仅仅是产品经理，更是一个团队

回归产品思维：一位前产品经理的八点反思

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论