这些项目崩溃的原因并非“凭感觉编码”。 它们崩溃的原因是，代理会做出局部正确的修改，但这些修改在全局上却是错误的。代理不会记住代码存在的意义、之前尝试过的方法，以及下游的漏洞所在。 更好的 Rails 需要： > 结构化记忆：依赖关系图、调用链、所有权边界等，以便用户理解 > 检索时需考虑影响范围，而不仅仅是语义相似性 > 基于执行的验证（测试、构建），而非文本置信度 一旦代理能够获取整个代码库的状态，安全地模拟变更，并通过运行的工件证明其正确性，“如何编码”就不再是瓶颈。 “如何构建”——在哪些约束条件下，如何权衡取舍——才成为问题。 护城河从代码编写转移到了判断和审查。 我们终将实现这一目标——只是时间问题，而不是会不会实现的问题。