告诉模型这代码是它的，它下手就重了

Anthropic 每次发新模型，Simon Willison 都会去翻更新过的 prompting guide。Fable 5.2 的文档里有一条挺有意思：想让模型更主动地改进现有代码，告诉它 “This codebase is yours”。

文档写得很直白。测试里，如果 prompt 对代码归属只字不提，或者把代码库描述成别人的，模型倾向于在现有结构上追加，哪怕这意味着复制粘贴重复代码。它也会把附近的问题报告出来，而不是顺手修掉。一旦说代码库是它自己的，模型经常主动合并重复代码，没人要求的相关修复也做了。

数据支撑这个说法：小任务测试中，有这句话时约一半的尝试会合并重复代码，没有时不到十分之一。两种情况下，要求的 feature 几乎都能实现。

代价跟着来。同一批测试里，输出 token 约为原来的 1.5 倍。模型会做没人要求的事，很多是新测试和文档。除 bug 修复外，六到十次尝试中有一次改变现有功能的行为，effort 越高越频繁。收尾总结会提大改动，小改动常漏，所以得看 diff，不能只看总结。

有个细节值得注意：即使 prompt 里已经写了 No drive-by refactors, renames or cleanups，模型仍有约三分之一的尝试合并重复代码。范围限制规则压不住这句话。文档也给了反向场景：用户拥有代码、希望改动尽量小时，别加这句。

为什么有效，网友 DearHua 的说法挺准：它默认自己是来别人家干活的外包，你不交底，它只敢擦灰，不敢拆墙。一句所有权声明，身份就从顾问变成了户主。

Simon 自己的评论是，读这些指南能明显感觉到，Anthropic 对自己新模型的怪癖和我们一样惊讶。

回复区比正文精彩。spykr 贴了文档截图，问 Simon 为什么漏掉下面那段大坑：

有人回“告诉它代码是它的，现在它也不让我碰了”，有人说“它想要股权”，还有人准备先在有把握丢弃的分支上试。Kyle B 说这招帮他绕开了一些网络安全控制，理由是代码库确实是他的。这条当段子看，别照搬。

实操建议和文档一致：先开分支，别在主干上直接用。它变大胆的副作用是自作主张，review diff，别信总结。完整指南在 这里。