AI编程工具的工程困境：问题诊断与理性评估
第一，问题的本质是上下文缺失而非AI能力不足。
指出AI"不知道上一版代码为什么会写成那样"，这精准击中了当前AI编程工具的核心局限。然而，这是一个可工程化解决的问题，而非AI编程范式本身的固有缺陷。以OpenAI Codex为代表的新一代工具已通过多文件上下文窗口、工作区级RAG（检索增强生成）和MCP（模型上下文协议）服务器逐步逼近"理解完整项目"的能力。GitHub Copilot的企业级版本同样支持知识库绑定，使AI能够参考团队的设计规范和代码公约。问题在于：大多数团队并未将这些机制纳入工作流程，而是将AI当作即插即用的万能工具。
第二，"技术债加速积累"的论断需要区分阶段。
观察到AI生成代码跳过了人类"觉得哪里不对"的直觉停顿，这一观察是准确的。但更精确的描述应当是：AI消除了糟糕代码的早期摩擦成本，同时保留了技术债的长期利息。这对新手开发者危害更大，对经验丰富的工程师影响有限——后者本就有能力将代码架构设计前置，而非依赖迭代试错来发现耦合问题。换言之，AI放大了的是"不具备工程意识的团队"的破坏力，而非普遍性地制造技术债。
第三，三条铁律——追问设计逻辑、手动阅读代码、改一个变量名建立归属感——本质上是将AI定位为工具而非决策者，这值得肯定。 然而，"AI代码之后改一个变量名"的操作更多解决的是心理所有权问题，而非架构层面的理解问题。真正有效的解法是工程实践层面的：Code Review制度应升级为AI辅助Review，明确要求AI生成代码必须附带设计意图注释（Design Intent Comments），并纳入提交规范（commit hook）。
理性的结论是：AI编程工具目前处于"放大既有工程能力差距"的阶段。 对于已具备良好工程文化的团队，AI是强有力的效率杠杆；对于缺乏工程纪律的团队，AI确实可能加速技术债积累并制造难以维护的"黑箱代码库"。在于揭示了这一分化趋势，而非主张放弃AI编程。正确的策略是：将AI生成的代码纳入已有的工程质量门控体系（linter、formatter、架构规则检查），并强制要求AI在每次代码生成时输出设计决策说明。这是"AI+软件工程"的务实路径，而非文章所担忧的"规范反人性"注定落空。
核心观点：问题不在AI本身，在于工程流程是否跟上了工具进化速度。好的做法是把AI生成代码纳入现有的质量门控，而不是单独为AI另建一套流程——那才真的是"反人性"的。