AI写代码不是问题，没人懂系统才是
The problem is not the AI code, but nobody knows anything anymore
当大模型能自动生成代码，真正的危机并非代码质量，而是整个团队对系统架构和决策意图的彻底失忆。在大公司里，从L1到L7的工程师都在依赖Claude Code，管理层只关心交付速度，导致没人阅读代码、没人思考逻辑，甚至没人真正理解自己在构建什么。数据工程、产品管理等领域看似被AI赋能，实则让缺乏基础知识的团队陷入更深的维护泥潭。当AI无法自我驱动，人类若放弃对架构、设计和意图的把控，最终留下的将是一堆无人能维护的“黑盒”代码。
问题不在于AI生成的代码，而在于没有人再真正了解系统架构或当初做出某些选择背后的意图。
HN 评论区
238- zero_shift
周六我还在以一种模糊的方式反思这个问题，试图追溯工作中某个决策的来龙去脉。
代码变更本身并不重要。但足以说明的是，这关乎我们某款产品中的一个 AI 功能。
代码是由 Claude 根据提示词生成的。而提示词是根据 Atlassian AI 集成生成的工单。Atlassian 消化了由 AI 撰写的文档。这些文档源自战略备忘录，我有 90% 的把握它们完全是由 Claude 写的。
战略是由管理层在高管领导的敦促下选定的。如今高管们主要通过 AI 撰写的备忘录进行沟通。我不知道他们如何做决策，但他们会引用科技影响者、市场状况和客户预期。
这让我陷入了沉思。那么，究竟是谁做出了这个决策？可以说经过了多层人工审查，但决策的实际源头却难以 pinpoint（定位）。
我们开发这个功能并非因为我们想要它，而是因为我们认为别人期望它。
或许反思一下市场现状，能揭示出谁才是真正的掌舵者。
2026 年，投资者和客户的预期从何而来？至少在科技领域，这非常模糊。似乎充斥着炒作。有些炒作来自真正的信徒，有些来自愤世嫉俗者。但两者都响应着奖励越来越夸张的声明的市场激励。
市场的“行动”从何而来？驱动力是什么？
投资者似乎并不真正理解……
- glouwbug
当你编写代码时，你会通过重构和重写不断重塑你的理解，直到将其内化。通过内化，你获得了推理能力（在关键停机期间）和沟通能力。一个能够沟通的团队可以共同解决问题，从一个人的愿景，到产品白板讨论，再到工程的架构，直至 UX 和 UI 的艺术性。
让我困惑的是，我们竟然完全忘记了就在 4 年前，世界还是这样运转的。
- MomsAVoxell
从职业角度来看，我觉得这并不那么戏剧化——这主要是因为我一直大规模交付代码的行业将“审查”作为第一原则，即任何未经测试、未经审查的代码都不得上线，因为安全关键/实时要求和认证规范就是这样规定的。
审查 AI 生成的代码与审查任何其他代码并无二致，因此审查工具——正如理所应当的那样——也受益于……更多 AI 的庄重应用。但是：所有 AI 代码都经过人工审查。
所以影响并不大。我们只是不发布未经 100% 人工审查的代码。如果这不可逾越：那你做错了。用 AI 让代码重新变得可读。
然后，把 AI 放回它的盒子里。不要给开发者 100% 全天候的 API 订阅访问权限：给他们真正的硬件，让他们能 100% 本地运行。
因此，本地 AI 才是最好的 AI，伙计们。不要使用超出你本地运行能力的 AI，这是保持 AI 代码可维护性的好方法。
行业迟早会证明这一点：如果你不能把你的 AI 放进盒子里妥善保管，那你做错了……而且本应在几十年前就养成这种习惯，以应对未来工具的需求……（另见：不记录你与 AI 交互的所有内容？大失败。）
当然，Big Metal AI™ 那种令人绝对沉醉的成瘾性会让许多消费者陷入深深的“新文盲”泥潭——然而：“好”的 AI 代码实际上就是好代码。
- bengold14
我每天都在看到这种情况。问题在于，代码是我们所做工作的错误抽象。LLM 已经解决了编码问题，但它们没有解决系统、协作或系统维护问题。
编辑：既然我似乎触动了某根神经——我正在做一个项目来解决这个问题：https://www.archme.io 如果你想知道我对正确抽象的看法。
- vld_chk
对此我深有同感。我在七月底换了公司。前四周，AI 让我感到自由。我不再需要理解数行万行遗留代码库。入职从未如此轻松。只需问 Claude，它就能告诉我这里发生了什么以及是如何发生的。
但两个月后，情况开始适得其反。我仍然一无所知。我对系统设计和核心组件有一些了解，但对某些底层机制如何运作却毫无头绪。因为 AI 替我阅读代码、替我编写代码，而我将其当成了自己的理解。
上周，我最终限制了 AI 的使用，强迫自己（这真的很难）至少亲自阅读和编写一些代码，以便开始对这里发生的一切有所了解。
- hollowonepl
AI 不是为程序员准备的，他们总会抱怨，而且只要有时间和资源，当然能产出更好的原子代码。AI 是为那些集业务分析师、架构师和产品经理于一身的人准备的，这些人具备编程能力，但决定将编程在整个软件工程生命周期中仅作为一个有限的角色。只要态度正确，当然还要对 AI 进行一定程度的微观管理（他们以前对程序员也得这么做），他们就能以更少的沟通摩擦、更少的人来维护团队协作，取得相同或类似的结果，并更接近解决他们发现的问题，而不是讨论编程哲学和其他不再具有声望或独特性的工匠宣言。而这正是当 AI 被交给错误的人使用时，人们抱怨的关键点。
- meowface
这并非既定事实。这关乎意志力和用心。LLM 是终极的拐杖。我过度依赖拐杖，越来越多的人也会过度依赖拐杖。但这本质上是一个心理问题。
只要你足够自律和用心，你仍然可以掌握知识并从 LLM 中获得力量倍增的效果。但在实践中，大多数人不会这样做。你无法强迫别人做到。但你可以强迫自己做到。
- ecshafer
从长远来看，AI 将使软件工程变得更加重要。获取需求、用户反馈、测试、产品愿景。这些现在是关键的差异化因素。
如果你能真正获得一套良好的需求，写出所有的测试用例，然后扔给 AI 让它一次性搞定。这就完美了。