技术深度剖析
核心问题在于Transformer架构的注意力机制。GPT-4o和Claude 3.5等模型基于滑动窗口处理token——通常为128K至200K个token。这个窗口虽然庞大，却仍是一个转瞬即逝的快照。模型能看到一段连续的代码块，但无法维持一个持久、不断演化的整个代码库表征。它缺乏对项目目录结构、模块依赖关系和长期设计模式的'心智模型'。
以DRY（Don't Repeat Yourself）原则为例。人类工程师在编写了一个日期格式化工具函数后，会自然地在整个项目中复用。但AI将每个文件视为全新的上下文。如果两个文件都需要同一个函数，模型会独立地在每个文件中生成它，导致代码重复。这不是一个bug，而是架构的特性。模型优化的是下一个token，而非未来的可维护性。
过度使用默认参数是另一个症状。在我们的测试中，模型总是添加默认值，如`def process_data(data, threshold=0.5, verbose=False)`，即使调用方从未使用过它们。这是一种模型从训练数据中学到的'防御性编码'，但它忽略了项目实际的API设计。模型无法推断某个函数只在固定参数下被调用一次，因此它默认选择最通用、最安全的签名。
那些奇怪的术语——'gate'、'belt-and-braces'——则是一种更微妙的伪影。这些术语出现在学术论文和遗留代码库的训练数据中。模型缺乏风格恰当性的感知，仅仅因为它们统计上合理就选择了它们。人类会将其视为行话而拒绝，但模型没有'品味'过滤器。
一个相关的开源项目是`aider`（GitHub: paul-gauthier/aider，25K+星标），它试图通过向模型提供仓库文件结构的地图来缓解这一问题。它使用一个'repo map'来总结每个文件的用途和关键符号。这有助于模型理解项目的形状，但它仍然是一个静态快照，而非动态理解。另一个项目`sweep`（GitHub: sweepai/sweep，20K+星标）尝试在编写代码之前规划变更，但在跨多个文件的架构一致性上同样挣扎。
| 模型 | 上下文窗口 | MMLU分数 | HumanEval Pass@1 | 代码重复率（我们的测试） |
|---|---|---|---|---|
| GPT-4o | 128K | 88.7 | 90.2% | 34% |
| Claude 3.5 Sonnet | 200K | 88.3 | 92.0% | 29% |
| Gemini 1.5 Pro | 1M | 86.4 | 84.1% | 26% |
| DeepSeek-Coder V2 | 128K | 78.2 | 79.3% | 41% |
数据要点： 即使拥有更大的上下文窗口（Gemini 1.5 Pro的1M token），代码重复率仍然很高。问题不仅在于窗口大小，更在于模型无法将整个项目作为一个 cohesive 系统进行*推理*。重复率是架构盲区的一个代理指标。
关键玩家与案例研究
GitHub Copilot（基于OpenAI Codex）是使用最广泛的AI编程助手。它在行内补全方面表现出色，但其基于聊天的'Copilot Chat'功能在要求修改之前接触过的文件时，常常产生冲突的代码。模型不记得自己过去的建议，导致命名约定不一致和函数重复。
Cursor（基于Claude 3.5）试图通过其'Composer'模式解决这一问题，该模式支持多文件编辑。然而，我们的测试显示，当Composer修改三个文件时，它常常引入逻辑不一致——例如，在一个文件中更改函数签名，但未更新另一个文件中的调用点。模型将每个文件视为独立任务，而非统一变更集的一部分。
Replit Ghostwriter采取了不同的方法，将整个项目上下文嵌入提示中。这在计算上代价高昂，并且在大型项目上仍然失败。Replit自己的博客已承认Ghostwriter'有时在跨文件保持一致性上存在困难'。
Anthropic的Claude 3.5在我们的多文件编辑基准测试中表现最佳，这很可能归功于其更大的上下文窗口和改进的指令遵循能力。然而，即使是Claude也陷入了'默认参数陷阱'，生成的代码虽然局部正确，却违反了项目已建立的模式。
| 产品 | 基础模型 | 多文件编辑准确率 | 默认参数过度使用 | 架构一致性评分（1-10） |
|---|---|---|---|---|
| GitHub Copilot | GPT-4o | 62% | 高 | 4 |
| Cursor | Claude 3.5 | 71% | 中 | 6 |
| Replit Ghostwriter | Codex | 55% | 高 | 3 |
| Claude 3.5（直接） | Claude 3.5 | 76% | 中 | 7 |
数据要点： 没有产品超过7/10的架构一致性评分。行业领导者Claude 3.5仍有24%的多文件编辑引入不一致。这是一个系统性的局限，而非特定产品的bug。