精选理由
dotey 用崩溃日志的例子说清一件事：agent 找代码靠读上下文，不靠猜命名，历史命名烂也不用怕。
针对代码库中方法名、变量名、模块名因历史改动而“词不达意”的问题，agent 不是靠猜关键字去搜索，而是先阅读错误日志定位崩溃位置，再以该处代码为起点沿上下文寻找相关代码。它会在上下文中逐步补全信息，直到足以定位问题，才生成修复代码。在 bash 这类语义搜索容易受命名误导的场景下，这种基于代码片段的阅读方式可以绕开历史债的干扰。
原文 · 宝玉
其实不用担心代码命名的问题，agent 并不是简单通过猜关键字去找代码的，它会阅读代码片段，根据上下文去找。 举个例子来说，它发现程序崩溃了，它会先根据错误日志去定位到崩溃的位置，然后先阅读这部分的...
其实不用担心代码命名的问题，agent 并不是简单通过猜关键字去找代码的，它会阅读代码片段，根据上下文去找。 举个例子来说，它发现程序崩溃了，它会先根据错误日志去定位到崩溃的位置，然后先阅读这部分的代码，以此为起点，再去找相关的代码，直到上下文足够定位问题，再去生成修复的代码。 zwdroid @zwdroidai @dotey 向老师请教个问题：历史代码中有很多局部的改动，导致很多方法名其实根本表达不了它的意图，还有日志、变量名、甚至模块名，这些历史债都在，但是因为项目众多，所以基本不让随便改动，那在这种“词不达意”的代码充斥的情况下，bash 这种语义搜索很容易被误导，有什么好的建议吗？例如通过 mapping ？ 🔗 View Quoted Tweet 💬 3 🔄 0 ❤️ 4 👀 2418 📊 2 ⚡