个人的AI使用感受我相信现在大部分人都将自己的一部分甚至全部的体力活交给AI了。这当然是时代的进步但个人如何在时代的进步中发展自己AI真的很方便快捷它带来了一种此前未有过的满足感。这份满足感来源于极快的成品速度来源于个人对项目整体把控层次的提高。但这是畸形的因为它构建的地基并不是稳定的。畸形的底座堆砌出来的金字塔无法承受任何变动因为任何变动都相当于推倒重来。如果人类写的是屎山代码那ai写的代码更是屎山中的屎山。AI写出屎山代码的原因是什么这是一个显而易见的问题因为人类并没有在工程上约束好AI忽视了AI的缺陷。甚至许多开发者在某种程度上放大了AI的缺陷。1、对AI不切实际的期许这个期许不是指对AI代码质量的期许而是对其代码速度的期许。LLM带来的超快编码速度让很多人忽略了曾经人类开发的习惯是一小时学东西、十分钟写代码。而今天的人类却妄想AI提供百倍千倍的开发速度这当然是不可能的。但是AI coding却在往这方面一路狂奔因为这样最赚钱。在我看来让AI先慢下来而不是让人慢下来审查AI代码才是未来最重要的代码工程。2、AI能力的阉割AI coding 最依赖的是什么信息请回答以下两个问题LLM网页版为什么不适合用来写代码API/本地部署的AI最常出现的错误类型是什么在我的实际体验中这两个问题的答案都指向一个原因信息不足。网页端 LLM 缺失的是本地配置、运行时环境反馈以及对项目实情的持续把控因此它只能给出脱离上下文的“看起来正确”的片段。而 API 与本地部署虽然能打通部分上下文却往往又缺失了前沿信息、权威文档、社区成熟方案与最新的实践经验导致输出要么过时要么陷入重复造轮子。3、现有工程设计对AI是负担传统的软件工程是对人类设计的。面向对象设计原则、分层架构、依赖注入、各种设计模式……让AI执行任务时不得不面对大量无效代码要过滤掉其中与任务无关的信息这显然是不合理的设计。LLM需要的是聚焦。它需要的是一体式的、完整的逻辑交互过程。在单一个上下文单元里应当清晰承载接收输入——审查约束——进行处理——验证结果——最终输出。相应地工程结构应该走向文件级别的逻辑与结构内聚给出封装清晰的逻辑说明和强约束边界以对待数据的方式——数据结构工程——对待代码而不是指望 AI 在错综复杂的依赖网络中自行理出头绪。更进一步还需要对外部依赖进行严格管理甚至将某些关键逻辑提取内化以直接隔绝外部依赖的干扰。个人对上面的问题并没有什么解决办法只能在设计和使用时牢记以上问题并主动避免感谢您的阅读。