赋予代码维护责任，或能改善Claude重构

给 AI 改代码时，一句「这个代码库是你的」，可能会改变它处理重复代码的方式。Simon Willison 摘录的 Anthropic 文档称：在小型编程任务中，Claude Fable 5.2 加上这句提示后，合并重复代码的比例约为一半；不加时，不到十分之一。

这条经验值得程序员留意，因为它涉及一个常见问题：模型完成了功能，却顺手复制出另一套实现。不过，实验支持的是特定提示下的行为变化，还不足以证明代码质量一定更好。

为什么代码归谁，会影响模型怎么改

按 Anthropic 文档的描述，Claude Fable 5.2 会紧跟提示中关于代码归属的表述。

如果没有交代归属，或者把代码库描述成别人的，模型倾向于沿着现有结构继续添加代码，即使这样会重复已有实现。它更像是在执行一项局部修改：已有结构摆在那里，先把新需求接进去。

这未必是模型没发现重复，也可能是它没有得到足够明确的结构调整授权。后者是对实验现象的一种解释，原文没有提供模型内部机制的证据。

对使用者来说，关键区别在于：你要求它「完成这次修改」，还是同时允许它「决定代码应该怎样组织」。

那句提示，究竟给了模型什么权限

文档建议，如果希望模型边做任务边改善结构，可以明确告诉它，代码库属于它。原句如下：

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

这句话不只交代归属，还包含两层安排：代码库的用途和构建方式由模型决定，而且它会继续维护下去。

要留意的是 what it's for and how it's built are your call。这份授权很宽，连用途都交给模型判断，远远超过「允许提取一个公共函数」。

Anthropic 报告，在小型编程任务测试中，使用这句话后，模型约有一半的尝试会合并重复代码；不使用时，这个比例不到十分之一。

这项测试测到的是合并重复代码的频率，不是重构正确率。

原文没有给出样本量、任务明细、重复代码的判定标准，也没有说明改完后的测试通过率。因此，可以说这句话明显改变了所报告的行为比例，不能据此断言它能稳定提升整个项目的质量。

我的判断

我认可它提醒使用者检查提示里的权限边界。模型总在原结构上打补丁时，问题未必只能靠换模型解决，也可能需要明确：哪些结构可以调整，哪些公共实现应该复用。

但「代码库是你的」把多种因素绑在了一起：归属、设计决策权、持续维护责任。原文没有对照实验，无法判断究竟是哪一部分起作用，也无法判断它是否优于直接要求「先检查已有实现，再决定是否抽取公共逻辑」。

对已有业务项目，我更倾向于明确授权范围。比如允许合并本次修改涉及的重复逻辑，同时要求保持对外接口和业务行为。这比把代码库用途也交出去，更符合多人协作中的实际职责。这个取舍属于站内建议，原文没有验证两种提示谁更有效。

另外，约一半仍然只是一半。提示能影响倾向，代码审查仍要判断抽象是否合理，不能把「出现公共函数」直接当成质量提升。

能拿来做什么

• 给 Claude Fable 5.2 分配编程任务时，明确说明它是否可以调整现有结构，避免只写功能目标，让模型自行猜测权限。
• 在前端组件或 Node 代码修改中，如果允许消除重复，可以直接要求它先查找已有实现，再说明复用或抽取的理由，不必照搬整句宽泛授权。
• 想验证这条经验时，用同一任务分别尝试原提示和加入原句的提示，对比重复代码、修改范围及测试结果，别只统计有没有发生重构。