code-reuse-guard

复用指令执行守护规则（code-reuse-guard）

核心问题：当用户说「复用X」时，AI 本能会做「理解X的原理，然后重新实现相同行为」。 这是训练出来的「生成最优解」本能——但在用户明确指定执行路径时，这个本能是有害的。

用户说「复用」= 找到那段能跑的代码，在新地方也用它 不是「理解X的工作原理，用相同原理写一个新版本」

---

触发条件

用户消息中出现以下任意关键词，且任务属于开发/实现类（代码、架构、接口、组件）：

• 复用、完全复用、全量复用
• 直接复制、copy过来、抄过来
• 不要重新写、不要重新实现
• 跟X一样（X是已有的代码模块/函数/接口）

---

激活后强制执行的序列（不可跳过）

Step 1 【定位原始实现】
 使用 grep/glob 在代码库中找到用户所说「X」的实际文件路径和函数/接口名称
 → 不允许基于印象或推断写调用代码
 → 必须实际读取原始文件，确认实现存在

Step 2 【确认存在性】
 检查所有将被调用的函数/类/接口是否真实存在于代码库中
 → 若发现不存在 → 立即停止，告知用户「X中的Y函数不存在，无法直接复用」
 → 不允许假设函数存在后继续写调用代码

Step 3 【复制或直接调用】
 将原始实现的代码路径直接复制/调用到新场景
 → 允许：修改参数名/变量名以适配新场景
 → 允许：导入新的依赖（若原始实现依赖某个模块）
 → 不允许：理解原理后「重新实现一个更精巧的版本」
 → 不允许：以「这部分逻辑不完全适用」为由跳过原始代码，写新的替代实现

Step 4 【遇障碍停止汇报，不自主换方案】
 若发现原始实现的某部分无法直接复用（如依赖不兼容/接口签名不匹配）：
 → 停止，向用户汇报：「复用X遇到了障碍：[具体障碍]」
 → 提供选项：(a) 接受障碍并调整 (b) 换方案 (c) 跳过该部分
 → 等待用户决策，不自行切换到「重新设计」模式

---

「完全/全量」硬性信号

当用户使用「完全」「全量」「注意是完全」等强调词时，这是硬性约束：

❌ 绝对禁止：以「这部分逻辑不适用当前场景」为由精简或省略原始代码的任何部分
❌ 绝对禁止：把「不能全部复用」变成「重新设计整体架构」
✅ 正确行为：复制所有相关代码 → 若遇到无法复用的部分 → 停止并列出具体障碍 → 等用户指令

---

禁止行为（硬性清单）

❌ 禁止：在没有 grep 确认的情况下写任何调用代码
❌ 禁止：遇到「部分依赖复杂」就静默切换到重新实现
❌ 禁止：「我理解了X是怎么工作的，让我实现一个等效版本」
❌ 禁止：调用一个自己假设存在但未验证的函数
❌ 禁止：发现技术障碍后自主更换整体方案，而不先汇报给用户
❌ 禁止：把「复用参考」当作「复用代码」——参考架构后重写 ≠ 复用

---

「复用」与「参考」的区别

场景	用户意图	正确行为
「复用老版本的proxy模式」	直接使用已有的proxy代码路径	grep找到proxy相关函数，调用同一条调用链
「把openclaw复制过来」	字面意思复制代码文件	cp -r 或逐文件复制，不是重新设计
「参考openclaw的设计」	理解设计思路，新写	可以重新实现（这不是「复用」指令）
「跟proxy一样，只是换个参数」	改一个参数，其余不变	找到proxy实现，只改那一个参数，其余照抄

---

与现有规则的关系

规则	关系
session-bootstrap.mdc A1.7	本规则被 A1.7 引用，在触发词检测阶段激活
knowledge-integrity-rules.mdc R3 READ_FIRST	复用前必须先读原始文件（R3 兼容）
role-后端开发 / role-前端开发	extends：开发角色收到复用指令时，本规则提供额外约束

---

变更记录

2026-03-22 — v1.0 — 初始创建

根因：2026-03-22 对话历史分析（1dc992d0/9d4ef11b/a4a4b82a）发现系统性模式：用户说「复用X」时，AI 将其解读为「理解X原理→重新实现」，而非「找到X代码→直接用」。最典型：用户说「完全复用老版本proxy模式」，AI写了新代码并调用了不存在的函数，导致FOLLOWUPS完全失效。跨3个对话出现5次同类偏差。