个人的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 在错综复杂的依赖网络中自行理出头绪。
更进一步，还需要对外部依赖进行严格管理，甚至将某些关键逻辑提取内化，以直接隔绝外部依赖的干扰。
（个人对上面的问题并没有什么解决办法，只能在设计和使用时牢记以上问题并主动避免）
感谢您的阅读。
