我一直一直在思考的一个问题是：- 将代码重构为新的具有功能对等性的模式的成本会多快下降？- 这会如何改变我们对技术债务的权衡？如果工程团队使用三种不同的抽象方式，这些方式不一致，跨组件泄露实现细节，并以非常难以理解的方式重复功能，那么按照传统说法，这是一个存在性问题，可能会摧毁整个业务，因为所有开发时间最终都会被bug修复和处理无意义的复杂性所消耗，速度会降为零，公司将无法继续迭代。但如果Claude可以可靠地重新组织代码，修复模式，并在被要求时编写工作迁移代码，那么看待技术债务的方式似乎已经改变了。如果你愿意赌上一年内模型在这些任务上的表现会好很多，那么改变会更大。…
源讨论Opus 4.5 将改变一切原帖 1,353 条评论 · 导入时统计让我困扰的是这类帖子：中级工程师并不会被指派原子化、全新领域的项目。如果一个工程师每天所做的只是从零开始构建应用程序，而没有任何期望其他人会随后进行扩展、在其基础上构建或依赖它，那么当然，Opus 4.5 可以取代他们。工程的难点不在于“构建一个能运行的东西”，而在于以一种易于理解、易于扩展的方式构建它。 毫无疑问，我可以给 Opus 4.5 下达“构建一个 XYZ 应用程序”的指令，它会表现得很好。但日常工作中，当我让它“帮我构建这个功能”时，它会使用奇怪的抽象，而且经常需要我多次尝试才能以我认为“正确”的方式完成。任何非技术人员可能会读到后说“如果能运行就没事”，但任何合理的工程师都会知道这还不够。
完整原文把你的经验，加入这段讨论。
> 但如果Claude可以可靠地重新组织代码，修复模式，并在被要求时为状态编写有效的迁移，那么关于技术债务的整个思维方式似乎都改变了。 是的，我最近用了4天时间用Claude清理了一个已经上线7年以上的工具。（在那几年里，只有大约3个月的工程时间花在了它上面。） 我们多年来一直知道这个工具需要什么，但啊，实际的工作相当混乱，而且一直不是优先事项。我仔细审查了Opus的所有清理工作，我对结果非常满意。甚至用"热情"这个词来形容也是准确的。 所以即使Claude不能完全自主地清理所有技术债务，它仍然可以非常迅速地解决一些类型的技术债务。
完整原文好观点。处理技术债务的大部分成本在于阅读代码并记录问题。我发现当Claude有一个功能正确的参考实现时，它可以生成更好的代码。而且不需要非常具体地指出问题。我曾经提到过“我在X和Y中看到重复的键，重新设计以减少重复和冗长”。它想出了一个更优雅的实现方式。 所以也许分2-3个阶段是有意义的。第一阶段需要功能正确，但可以接受代码异味，比如泄漏的抽象、冗长和重复。在第二阶段和第三阶段消除所有这些问题。你可以将这个过程整合到初始规范中；你甚至不会看到有异味的中间代码；它只作为模型迭代改进代码的一步！
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。