北京
GitHub上有个现象越来越常见：开发者用AI辅助工具写完代码，合并提交，然后发现自己也看不懂这套系统是怎么运行的。这不是段子，是580个真实对话里反复出现的困境。
2025年11月的一项研究分析了开发者与ChatGPT的协作模式。研究者追踪了对话流程，发现最常见的问题不是代码跑不通，而是"这段代码为什么能跑"。更棘手的是，当AI建议的解决方案涉及多个文件改动时，开发者往往只能照做，无法验证每一步的合理性。
另一份同期发布的DevGPT数据集揭示了更深层的问题。研究者整理了开发者向ChatGPT提问的内容分布，排在前几位的不是语法问题，而是架构决策：该不该用这个设计模式？这个依赖库会不会有隐患？AI给出的答案通常只有"可以这样做"，却很少解释"为什么这样做在半年后不会变成技术债"。
生产环境的崩溃比Demo演示残酷得多。2026年2月的一篇技术复盘指出，大量LLM应用死在上线后的第三周——不是因为模型效果不好，而是因为没人能调试那个由AI生成的、层层嵌套的RAG（检索增强生成）管道。Demo里漂亮的回答，背后可能是二十几个隐式调用的API，任何一个超时都会让整个链路雪崩。
有开发者开始用"Slop"这个词形容AI生成的低质量代码——能跑，但满是冗余和隐患。2025年10月的一篇实践指南提出更务实的思路：与其追求让AI写更多代码，不如先建立代码审查的硬性规则。比如，任何AI生成的函数必须通过人工的边界条件测试，任何架构改动必须留下决策记录。
这场协作实验还在早期。580个对话里有个细节：当开发者把AI当作"结对编程伙伴"而非"代码生成器"时，最终代码的可维护性明显更高。区别不在于工具，而在于人是否还在思考。AI可以加速打字，但不能替人承担理解系统的责任——这个边界，现在越来越模糊了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
