代码重复会造成维护噩梦： * 必须在多个地方应用错误修复 * 特征在重复项中的演变不一致 * 重构变得更加困难 * 代码库变得不必要的大 * 入职需要更长的时间（需要学习更多代码）此技能将“实施 X”请求转换为两阶段工作流程： 1. **搜索阶段**：查找现有的类似实现（端点、组件、服务、模型） 2. **重用或证明**：重用/扩展现有代码或证明为什么需要新的实现结果：代码库保持干燥、可维护且一致。当用户说“创建”、“实现”、“添加”或“构建”新功能时，**立即**在编写任何新内容之前搜索现有的类似代码。 **触发短语**： *“为...创建一个新的API端点” *“实现一个组件......” *“添加一个服务来处理...” *“为……建立一个模型” *“编写一个函数......” **第 1 步**：从请求中提取搜索关键字 * 用户：“创建 API 端点来获取用户个人资料” * 关键字：“API 端点”、“获取”、“用户”、“个人资料”、“GET” **第 2 步**：在代码库中搜索类似模式 **主要：语义搜索 (mgrep)** * mgrep for：“获取用户数据的API端点”，“配置文件检索处理程序” * 通过含义查找类似的实现，而不是精确的文本 **次要：文字搜索（Grep/Glob）** * Grep for：“router.get”，“app.get”，“/api/user”，“profile” * 全局：“**/_user_.ts”、“**/_profile_.ts”、“**/routes/**” **第 3 步**：分析结果 * 找到3个相似的端点：GET /api/user/:id、GET /api/user/settings、GET /api/admin/users * 全部使用相同的身份验证中间件、验证模式、错误处理 **第 4 步**：呈现重用选项 * **选项 A** ：扩展现有 GET /api/user/:id 以包含配置文件数据 * **选项 B** ：使用与现有用户端点相同的模式创建新端点 * **选项 C** ：证明为什么需要全新的方法 **步骤 5**：实施所选选项（以现有模式作为模板） **在反重复技能之前**：用户：“创建 API 端点来更新用户电子邮件” Claude：_使用不同的身份验证、验证、错误处理从头开始编写新端点_结果：相似端点的第 5 个变体，不一致的模式 **经过反重复技能**：用户：“创建 API 端点来更新用户电子邮件” Claude：_搜索代码库，找到 4 个具有一致模式的现有用户端点_ Claude：“找到 4 个类似的用户端点。它们都使用：authMiddleware、validateUserInput、standardErrorHandler。我将按照此既定模式创建新端点。”结果：一致的实现、重用的中间件、可维护的代码提取关键信息： * **类型**：他们正在建造什么？（端点、组件、服务、模型、功能、实用程序） * **领域** ：什么业务领域？（用户、产品、订单、付款、授权） * **操作** ：什么操作？（创建、读取、更新、删除、获取、验证、转换） * **技术**：什么堆栈？（反应、Express、TypeScript、SQL、GraphQL）解析示例：请求：“创建一个 React 组件来显示产品详细信息” 解析： - 类型：React组件 - 领域：产品 - 操作：显示/渲染 - 技术：React、TypeScript（可能）创建多种搜索方法以最大化覆盖范围： **主要：语义搜索 (mgrep)** 首先使用 mgrep 进行模式发现 - 通过含义查找相似的代码： *“显示产品信息的组件” *“处理电子邮件发送的服务” *“用户输入的验证逻辑” *“API 路由中的错误处理模式” mgrep 在搜索“显示用户详细信息”时会找到 UserCard、ProductCard、ProfileView，即使名称不匹配也是如此。 **次要：文字搜索（当 mgrep 不足时）** **A。基于关键字的搜索** (Grep)： * 核心领域术语：“产品”、“产品”、“产品” * 操作术语：“显示”、“渲染”、“显示”、“查看” * 技术模式：“React.FC”、“函数组件”、“const._=._ =>” **B。文件模式搜索**（Glob）： * 域文件：“**/_product_.tsx”、“**/_Product_.tsx” * 位置模式：“**/components/** /_Detail_.tsx”、“**/components/** /Product*” * 特定类型：“**/models/Product*”、“**/services/product*” **C。结构搜索**（带正则表达式的 Grep）： * 类定义：“类.*产品” * 函数导出：“export (function|const).*product” * API 模式：“router.(get|post|put|delete).*product” 有关详细模式，请参阅 [references/search-strategies.md]()。同时运行多个搜索以提高速度： **阶段 1：语义搜索 (mgrep)** mgrep“显示产品详细信息的组件” mgrep“实体的详细卡片模式” 审核结果 - 如果找到足够的匹配项，请跳至步骤 4。 **阶段 2：文字搜索（如果需要）** 1. grep: **/*.tsx 中的“product”（查找所有与产品相关的组件） 2. Grep:“ProductDetail”（查找相似的详细组件） 3. glob: "**/components/** /Product*.tsx" （查找产品组件文件） 4. grep:“interface.*Product”（查找产品类型定义） 5. grep:“display.*product.*props”（查找渲染逻辑）所有搜索并行运行（请参阅并行执行优化器技能）。 **时间**：约 5-10 秒即可在大型代码库中进行全面搜索。对发现进行分类： **完全匹配**：几乎相同的实现 * 示例：找到 ProductDetailCard、ProductSummaryCard、ProductPreviewCard * 所有渲染产品数据具有相似的结构 **紧密匹配**：相似的域，不同的操作 * 示例：Found ProductList（呈现多个产品） * 可以提取共享渲染逻辑 **模式匹配**：类似的操作，不同的域 * 示例：找到 UserDetailCard、OrderDetailCard * 一致模式：实体的 DetailCard 组件 **反模式**：不该做什么 * 示例：找到具有 500 行单片组件的 ProductView * 展示了实现新组件时要避免的事情按相关性排名： 1. 精确匹配（最高重用潜力） 2. 接近匹配（部分复用） 3. 模式匹配（模式一致性） 4. 反模式（从错误中学习）为用户提供明智的选择： **选项 A：重用现有实现**“找到已显示产品详细信息的 ProductDetailCard 组件。我们可以直接使用它还是您的用例有所不同？” **选项 B：扩展现有实现** “找到 ProductSummaryCard（显示基本产品信息）。我们可以扩展它以显示完整的详细信息，而不是创建新组件。” **选项 C：提取共享模式** “找到 3 个类似的 DetailCard 组件（产品、用户、订单）。我们可以创建一个通用的 DetailCard 并将其用于产品。” **选项 D：遵循既定模式**“在用户/订单详细信息组件之间找到一致的模式。我将按照相同的结构创建 ProductDetailCard 以保持一致性。” **选项 E：证明新方法**“现有 ProductView 是一个 500 行的整体，关注点分离很差。我将创建一个新的模块化 ProductDetailCard。这就是为什么新方法是必要的：[理由]” 在建议新的实施之前，请务必先提出选项 A-D。根据所选选项： **如果重用**：导入并使用现有代码从 '@/components/products/ProductDetailCard' 导入 { ProductDetailCard }； // 直接使用 **如果扩展**：修改现有组件 // 使用附加字段扩展 ProductSummaryCard // 之前：显示名称、价格 // 之后：显示名称、价格、描述、图像 **如果提取模式**：创建通用抽象 // 创建 DetailCard 通用组件 // 重用产品、用户、订单 **如果遵循模式**：使用现有作为模板 // 从 UserDetailCard 复制结构 // 适应产品域 // 保持一致性（相同的 props 模式、相同的样式、相同的错误处理） **如果是新方法**：记录理由 /** * 产品详情卡 * * 新实现（不重用 ProductView） * * 理由： * - 现有 ProductView 是 500 行整体 * - 关注点分离不佳（混合数据获取、渲染、业务逻辑） * - 难以测试和维护 * * 这个实现： * - 分离关注点（仅限演示组件） * - 可在产品目录和购物车中重复使用 * - 遵循用户/订单建立的详细信息卡模式 */ **始终以 mgrep 开头进行语义发现：** mgrep 根据含义查找代码，而不是确切的文本。即使命名约定不同，这也会捕获类似的实现。 **按工件类型划分的 mgrep 查询模式：** 神器| mgrep 查询示例 ---|--- API端点| “处理用户身份验证的端点”、“用于数据检索的 API 路由” 组件| “显示列表的组件”、“带有验证的表单组件” 服务 | “发送电子邮件的服务”、“订单处理的业务逻辑” 型号| “用户数据的数据库模型”，“带有时间戳的实体” 实用程序 | “日期格式化的帮助函数”、“验证实用程序” **何时回退到 Grep/Glob：** * mgrep 不返回结果（小众术语） * 需要精确的文本匹配（特定函数名称） * 文件模式搜索（查找所有 *.test.ts 文件）不同的工件类型需要不同的搜索策略。 **API 端点**（Express、Fastify、NestJS）：关键字：router.get、router.post、app.get、@Get、@Post、/api/ 模式：HTTP 方法 + 路由路径 + 域术语文件：**/routes/**、**/controllers/**、**/api/** 搜索“用户配置文件端点”的示例： - Grep: **/*routes*.ts 中的“router\.(get|put).*profile” - Grep: **/*.ts 中的“/api/user” - 全局：“**/routes/**/user*.ts” - Grep：“getUserProfile|updateUserProfile”（通用命名） **React 组件**（功能、类）：关键词：React.FC、函数组件、类.*extends React 模式：导出函数 ComponentName, const ComponentName = 文件：**/components/**、**/*.tsx、**/*.jsx 搜索“产品卡组件”的示例： - Grep: **/*.tsx 中的“功能.*产品.*卡” - Grep: **/*.tsx 中的“ProductCard.*=.*=>” - 全局：“**/组件/**/产品*.tsx” - Grep: **/*.tsx 中的“export.*ProductCard” **服务/业务逻辑**：关键词：类.*服务、导出.*服务、提供、注入模式：服务命名约定、依赖注入文件：**/services/**、**/lib/**、**/utils/** 搜索“电子邮件服务”的示例： - Grep: **/*.ts 中的“class.*Email.*Service” - Grep: **/*.ts 中的“sendEmail|emailService” - 全局：“**/services/**/*email*.ts” - Grep：“nodemailer|sendgrid|aws-ses”（通用电子邮件库） **数据库模型**（Prisma、TypeORM、Sequelize）：关键词：模型、模式、实体、@Entity、接口。*模型模式：数据库列定义、关系文件：**/models/**、**/entities/**、**/schema/** 搜索“用户模型”的示例： - Grep：**/*.prisma 中的“模型用户” - Grep: **/*.ts 中的“@Entity.*User|class User.*extends” - 全局：“**/models/**/user*.ts” - Grep: **/*.ts 中的“接口 User.*{” 有关综合模式，请参阅 [references/search-strategies.md]()。在业务域中搜索以查找相关代码： **电子商务域名**： * 用户：身份验证、个人资料、偏好 * 产品：目录、详细信息、库存 * 订单：购物车、结帐、付款 * 运送：地址、追踪、履行 **搜索策略**：从领域术语开始，扩展到相关术语领域：产品主要：“产品”、“产品”、“产品” 相关：“商品”、“目录”、“库存”、“SKU” 操作：“addProduct”、“getProduct”、“updateProduct”、“deleteProduct” **跨域模式**：跨不同域寻找相似的操作：操作：“详细视图” 搜索：“*DetailCard”、“*DetailView”、“*Detail.tsx” 查找：UserDetailCard、ProductDetailCard、OrderDetailCard 模式：实体细节组件的一致结构根据技术堆栈定制搜索： **打字稿**： - “接口产品”（类型定义） - “类型产品=”（类型别名） - “产品延伸”（继承） - “作为产品”（类型断言） **GraphQL**： - “类型产品”（模式定义） - “Query.product”（查询解析器） - “Mutation.createProduct”（突变解析器） - “gql\`.*product”（查询字符串） **SQL/Prisma**： - “模型产品”（Prisma 架构） - “CREATE TABLE 产品”（SQL 迁移） -“SELECT.*FROM 产品”（原始查询） - “prisma.product.findMany”（Prisma 客户端） **反应查询/SWR**： - “useQuery.*product”（数据获取挂钩） - “useMutation.*product”（突变挂钩） - “queryKey:.*product”（缓存键）检测到这些短语时自动应用反重复搜索： **明确的创作意图**： *“创建一个新的[工件]” *“实现一个[工件]” *“添加一个[神器]” *“建造一个[神器]” *“写一个[工件]” *“生成一个[神器]” **示例**： *“创建一个新的API端点来获取订单” *“实现一个登录组件” *“添加处理付款的服务” *“使用电子邮件和密码构建用户模型” *“编写一个函数来验证用户输入” **隐式创建**（从上下文推断）： *“我需要[做某事]”→可能需要新代码 *“我如何[完成任务]”→可能需要新的实施 *“你能[构建功能]”→ 绝对需要代码 **在/实施阶段**： * 每项涉及编写新代码的任务 * 在编写第一行实现之前 * 即使对于“简单”任务（搜索需要 <10 秒）在以下情况下跳过反重复搜索： **用户明确请求新方法**： *“创建一个新的实现（不要重用现有的）” *“我知道有X，但我想要一种不同的方法” *“忽略现有代码并重新开始” **修改现有代码**： *“更新 UserController 以添加验证” * “修复ProductCard组件中的bug” *“重构 OrderService 以使用 async/await” **非代码任务**： *“解释身份验证的工作原理” *“查看 ProductCard 组件” *“运行测试套件” **配置/数据文件**： *“添加新的npm包” *“更新.env文件” * “创建迁移文件”（与创建模型不同）当用户说“创建 API 端点以更新用户电子邮件”时： 1. **在编写任何代码之前立即暂停** 2. **宣布搜索**：“在实施之前，让我搜索现有的用户端点以确保一致性......” 3. **运行搜索**（5-10 秒） 4. **当前发现**：“发现 4 个现有用户端点遵循一致的模式。我将使用相同的结构。” 5. **使用发现的模式实施** 这变得自动 - 用户不需要请求搜索，它会主动发生。搜索完成后，使用此决策树： **问题1：找到完全匹配？** * 是 → 直接重复使用（选项 A） * 否 → 转到 Q2 **问题2：找到紧密匹配（相同域，相似操作）？** * 是 → 我们可以延长吗？（选项B） * 如果是 → 扩展现有 * 如果没有 → 转到问题 3 * 否 → 转到 Q3 **Q3：找到模式匹配（相似结构，不同域）？** * 是 → 提取通用抽象？（选项C） * 如果是 → 创建通用版本 * 如果抽象太复杂 → 遵循模式（选项 D） * 否 → 转到 Q4 **问题 4：现有的实现是反模式？** * 是 → 证明新方法的合理性（选项 E）+ 记录为什么应重构现有代码 * 否 → 遵循既定模式（如果有），否则实施新模式 **最终检查**：在实施新代码之前，回答： *“为什么我们不能重用现有的代码？” *“这个实现有何不同？” *“这会造成重复吗？” **高重用潜力**（≥80%相似）：→ 直接重用或扩展 **中等重用潜力**（50-79% 相似）： → 将共享逻辑提取到实用程序/帮助程序中 → 适应现有模式 **重用潜力低**（30-49% 相似）： → 遵循既定模式以确保一致性 → 记录差异 **没有重用潜力**（<30%相似）： → 实现新的，但记录其不同的原因 → 考虑这是否表明缺少抽象 **搜索阶段**：搜索次数： 1. Grep "router\.(put|patch).*user" → 找到 3 个端点 2. Grep "/api/user.*email" → 找到 1 个端点 (GET /api/user/email) 3. glob "**/routes/**/user*.ts" → 找到routes/user.ts 结果： - PATCH /api/user/profile（更新姓名、简介） - PATCH /api/user/password（更新密码） - PUT /api/user/settings（更新首选项） **分析**：所有 3 个端点都遵循相同的模式： router.patch('/api/user/:field', authMiddleware, // JWT 认证 validateUserInput, // 模式验证 userController.update, // 控制器方法 standardErrorHandler // 错误处理）； **建议** ：“找到 3 个现有用户更新端点。它们都使用： * auth中间件（JWT身份验证） * validateUserInput（Joi 模式验证） * userController.update（集中控制器） * standardErrorHandler（一致错误） **选项 A**：扩展 userController.update 以处理电子邮件更新 **选项 B**：按照相同的模式创建新端点我建议**选项 A**（扩展现有控制器）以避免端点扩散。控制器已经处理配置文件/密码/设置更新，电子邮件符合相同的模式。” **实施**（选项A）： // userController.ts（扩展现有）异步更新(req, res) { const { 字段 } = req.params; const allowedFields = ['个人资料', '密码', '设置', '电子邮件']; // 添加电子邮件 if (!allowedFields.includes(field)) { return res.status(400).json({ error: '无效字段' }); } // 添加特定于电子邮件的验证 if (字段 === '电子邮件') { 等待 this.validateEmail(req.body.email); } // 已有的更新逻辑等待 this.userService.update(req.user.id, 字段, req.body); res.json({ 成功: true }); } **防止重复**：没有创建新端点，重用现有模式，一致的身份验证/验证。有关完整示例，请参阅 [examples/api-endpoint-reuse.md]()。 **搜索阶段**：搜索次数： 1. Grep "ProductDetail|ProductCard" in **/*.tsx → 找到 2 个组件 2. Glob "**/components/**/Product*.tsx" → 找到 5 个产品组件 3. grep "function.*Detail.*Card" in **/*.tsx → 找到 8 个 DetailCard 组件结果： - UserDetailCard：以卡片布局显示用户信息 - OrderDetailCard：以卡片布局显示订单信息 - ProductSummaryCard：显示产品摘要（不是完整的详细信息） - ProductListItem：在列表中显示产品（最少信息） **分析**：发现**模式**：所有“DetailCard”组件共享结构：接口 DetailCardProps { 数据：T；加载？：布尔值； onEdit?: () => void; onDelete?: () => void; } 函数 DetailCard({ 数据, 加载, onEdit, onDelete }) { 如果（加载）返回 ; 返回（ <卡片> <卡片标题> {/* 标题 */} <卡体> {/* 字段 */} <卡片操作> {onEdit && } {onDelete && } ）； } **建议**：“找到用于用户和订单实体的一致 DetailCard 模式。我不会从头开始创建 ProductDetailCard，而是将该模式提取到通用 DetailCard 组件中。” **实现**（选项 C - 提取模式）： // Components/common/DetailCard.tsx（新通用组件）接口 DetailCardProps { 数据：T；字段：数组<{标签：字符串；键：T 的键；渲染？：（值：任意）=> ReactNode }>; 加载？：布尔值； onEdit?: () => void; onDelete?: () => void; } 导出函数 DetailCard({ 数据、字段、加载、onEdit、onDelete }: DetailCardProps) { 如果（加载）返回 ; 返回（ <卡片> <卡体> {fields.map(字段=>(

<标签>{字段.标签}

{field.render ? field.render(data[field.key]) : data[field.key]}

))} <卡片操作> {onEdit && } {onDelete && } ）； } // Components/products/ProductDetailCard.tsx（使用通用）导出函数 ProductDetailCard({ 产品, 加载, onEdit, onDelete }: Props) { 返回（ <明细卡数据={产品} 加载={加载} 字段={[ { 标签: '姓名', 键: '姓名' }, { label: '价格', key: '价格', render: (val) => `$${val}` }, { 标签：'描述'，键：'描述' }， { label: 'Stock', key: 'stock', render: (val) => `${val} 单位` }, ]} onEdit={onEdit} onDelete={onDelete} /> ）； } **防止重复**： * 没有重复的 DetailCard 实现 * 所有实体可重用的通用组件 * 跨用户、订单、产品保持一致的 UI/UX * 重构现有的 UserDetailCard 和 OrderDetailCard 以使用通用的有关完整示例，请参阅 [examples/component-pattern-extraction.md]()。 **搜索阶段**：搜索次数： 1. Grep "sendEmail|emailService" → 找到 EmailService 类 2. Grep "nodemailer|sendgrid" → 找到nodemailer设置 3. Glob "**/services/**/*email*.ts" → 找到 services/EmailService.ts 结果： - 具有 sendEmail() 方法的 EmailService 类 - 已发送：欢迎电子邮件、订单确认、通知 - 使用nodemailer + AWS SES **分析**：EmailService 已经存在并且结构良好：类电子邮件服务{ 异步 sendEmail(to: 字符串, 主题: 字符串, 模板: 字符串, 数据: 任意) { const html = this.renderTemplate(模板, 数据); 等待 this.transporter.sendMail({ to, subject, html }); } 异步 sendWelcomeEmail(用户: 用户) { ... } 异步 sendOrderConfirmation(order: Order) { ... } } **建议**：“发现现有的 EmailService 已发送 3 种类型的电子邮件。我将向现有服务添加 sendPasswordResetEmail 方法，而不是创建新服务。” **实施**（选项 B - 扩展现有）： // services/EmailService.ts（扩展现有类）类电子邮件服务{ // ...现有方法... 异步 sendPasswordResetEmail(用户：用户，resetToken：字符串) { const resetUrl = `${process.env.APP_URL}/reset-password?token=${resetToken}`; 等待这个.sendEmail( 用户.电子邮件, '密码重置请求', '密码重置', // 模板名称 { userName: user.name, resetUrl, expiresIn: '1 小时' } ）； } } **防止重复**： * 没有创建新的电子邮件服务 * 重用现有的nodemailer配置 * 复用模板渲染逻辑 * 跨应用程序发送一致的电子邮件有关完整示例，请参阅 [examples/service-extension.md]()。 **问题**：不先搜索就实现 **不好的方法**：用户：“创建 API 端点来更新用户电子邮件” 克劳德：*立即从头开始编写新的端点* 结果：重复端点，具有与现有用户端点不同的身份验证、验证、错误处理。 **正确方法**：用户：“创建 API 端点来更新用户电子邮件” Claude：“让我先搜索现有的用户端点……” Claude：*找到 3 个相似的端点* 克劳德：“找到现有的模式。为了保持一致性，我会遵循它。” **规则**：在实施之前始终进行搜索。需要 5-10 秒，避免随后数小时的重构。 **问题**：查找现有代码但仍要实现新代码 **不好的方法**：搜索：找到 ProductSummaryCard 组件 Claude：“找到了 ProductSummaryCard，但我将从头开始创建 ProductDetailCard” *创建具有不同样式、道具、结构的重复卡片组件* 结果：两个相似的组件应该是一个，UI 不一致，双重维护。 **正确方法**：搜索：找到 ProductSummaryCard 组件 Claude：“发现 ProductSummaryCard 显示基本信息。我们应该扩展它以显示完整的详细信息，还是需要单独的组件？摘要版本可能会得到增强，而不是创建副本。” **规则** ：当搜索发现类似代码时，默认重用/扩展。仅在合理的情况下创建新的。 **问题**：仅搜索完全匹配，缺少相似模式 **不好的方法**：请求：“创建端点 GET /api/products/:id” 搜索：仅“GET /api/products”（太具体）未命中：具有类似结构的所有其他 GET 端点结果：错过了跨用户、订单等的 GET /:id 端点的既定模式。 **正确方法**：请求：“创建端点 GET /api/products/:id” 搜索次数： - “router.get.*:id”（查找所有参数化的 GET 端点） - “/api/.*/:id”（按 id 模式查找所有资源） - “产品”（查找所有与产品相关的代码） **规则**：使用多种搜索策略（关键字、模式、文件）。广撒网，过滤结果。 **问题**：在不理解现有代码的情况下复制它 **不好的方法**：发现：具有 15 个道具、内部状态、副作用的复杂 UserDetailCard 克劳德：*复制整个组件，重命名用户→产品* 结果：货物崇拜的复杂性、不必要的道具、混乱的代码 **正确方法**：发现：复杂的 UserDetailCard Claude：“这个组件很复杂（15 个 props，内部状态）。让我分析一下产品用例实际需要什么......” Claude：“产品细节只需要 5 个 props。我将按照核心模式创建简化版本，但没有不必要的复杂性。” **规则**：在重用之前了解现有代码。不要迷恋货物的复杂性。 **问题**：仅找到 1-2 个相似的片段后创建通用抽象 **不好的方法**：找到：UserDetailCard、ProductDetailCard（2 个组件） Claude：“让我创建具有 20 个配置选项的 DetailCard 通用组件来处理所有可能的情况......” 结果：过度设计的抽象比复制代码更难使用。 **正确方法**：找到：UserDetailCard、ProductDetailCard（2 个组件） Claude：“找到了 2 个相似的组件。它们足够简单，目前将它们分开就可以了。如果我们添加第三个实体（订单），那么我们将提取模式。” **规则**：抽象需要 3 个以上相似的部分（三规则）。两个实例还不能证明通用抽象的合理性。 1. **执行前执行搜索** ：每个“创建/实施”请求都会首先触发搜索 2. **结果呈现给用户**：用户看到发现了什么以及为什么重用是/不合适的 3. **重复使用合理**：如果重复使用，请解释重复使用的内容。如果没有，请解释为什么不。 4. **维持模式**：新代码遵循代码库中既定的模式 5. **避免重复**：多个地方不存在几乎相同的代码 6. **适当的抽象**：仅当存在 3 个以上相似的片段时才创建通用代码（三规则） **流程指标**： * 触发搜索的“创建”请求的百分比（目标：100%） * 平均搜索时间（目标：<10秒） * 找到相关结果的搜索百分比（目标：>60%） **结果指标**： * 重用现有代码的实现百分比（目标：>40%） * 遵循现有模式的实施百分比（目标：>80%） * 阻止代码行（与从头开始实现相比） **质量指标**： * 一致性得分：相似工件的相似程度如何？（目标：>80% 结构相似性） * DRY 违规：存在多少近似重复项？（目标：<任何模式的 3 个副本） * 重构负担：多长时间需要在多个地方应用错误修复？（目标：下降）在完成实施之前，验证： * 搜索已执行（未跳过） * 搜索涵盖多种策略（关键词、文件、模式） * 分析结果（确定精确、接近、模式匹配） * 考虑了重用选项（A、B、C、D、E） * 如果重用：现有代码被理解（不是盲目复制） * 如果延伸：延伸自然贴合（非强迫） * 如果是新的：记录理由（为什么现有代码不起作用） * 遵循的模式：新代码与现有类似代码一致 * 适当的抽象：仅当 3 个以上相似的片段时才使用通用代码有关更深层次的主题，请参阅参考文件： **搜索策略**：[references/search-strategies.md]() * 按工件类型进行综合搜索模式 * 特定技术的搜索策略 * 领域驱动的搜索方法 * 高级正则表达式模式 **重用模式**：[references/reuse-patterns.md]() * 何时直接重用 vs 扩展 * 提取共享逻辑 * 创建通用抽象 * 重构以实现可重用性 **决策框架**：[references/decision-framework.md]() * 重用与新实现的决策树 * 计算相似度分数 * 证明新代码的合理性 * 记录决策 **与阶段集成**：[references/phase-integration.md]() * 在/plan阶段使用反重复 * 在/implement阶段使用反重复 * 使用发现的模式更新 plan.md * 在NOTES.md 中记录重用决策在以下情况下成功应用反重复技能： 1. **主动搜索**：在任何“创建/实施”请求之前自动触发搜索 2. **全面覆盖**：使用多种搜索策略（关键词、文件、模式、领域、技术） 3. **分析结果**：结果分类（精确匹配、接近匹配、模式匹配）和相关性评分 4. **重用优先**：在选项 E（新）之前考虑选项 A-D（重用、扩展、提取、遵循模式） 5. **维持模式**：新的实现遵循既定的代码库模式 6. **记录理由**：如果在现有代码相似的情况下创建新代码，则明确说明理由 7. **坚持DRY原则**：不引入不必要的重复 8. **适当的抽象**：仅在合理的情况下创建通用代码（三规则：3+相似的片段） 9. **用户知情**：用户了解发现了什么以及为什么重用发生/不发生 10. **时间高效**：搜索在 <10 秒内完成，不会减慢开发速度

防重复

包含技能