复用优先·禁止盲目创新（复用门禁 recipe）
触发场景
出现以下任一情况时，加载本 skill 并按 recipe 执行，不要直接写代码：
- 用户已强调（或历史铁律要求）"不要盲目创新、复用既有模板 / 实现"。
- 你准备调用一个已存在的函数 / handler / 组件，但不确定它"被怎么调用、参数为何"。
- 你刚确认某函数存在，正想把它接到一个新的触发点（消息点击、按钮、路由等）。
> 同源铁律：用户级 MEMORY.md「框架复用铁律 27–31」、project_spec 代码复用与禁止盲目创新规范.md（V1.0.19）。本 skill 是该规范的一键执行载体。
核心门禁 recipe（新增 / 修改复用代码前照抄）
① grep 调用点：
grep -rn "目标函数名(" <目标仓库根>
看所有调用点，确认既有调用签名与参数来源（不要只看函数定义就动手）。
② 复刻签名：
新代码用与既有调用点【完全相同】的参数与取值逻辑；
任何手写的字符串 / 数字常量，先反问——「这个值，系统别处是不是已经在推导它？」
· 是 → 删掉我的字面量，复用系统的推导路径（如响应 Content-Type、记录的 format 字段）。
· 否 → 才允许保留。
③ 仅改触发：
新代码只接入"新触发点"（点击 / 按钮 / 路由），动作本体交给既有 handler。
不重写动作、不替换内部逻辑、不在复用缝里塞格式 / 类型 / id 等本应由系统推导的字面量。
④ 验收看结果（防伪自测）：
UI 类修复 → 截图比对既有正常态，而非只看"弹窗出现 / 能打开"。
数据 / 逻辑类 → 核对真实值，而非只看连通性或"接口通"。
凡系统本就按真实数据选分支（html/md、类型判断），必须确认渲染 / 结果确实走对了分支。
⑤ 存疑先问：
判断现有框架确实不适用、必须新写法时，先向用户说明"为什么复用不了 + 打算怎么做"，
等明确确认后再动手（铁律 29）。自作主张的"创新"是返工成本最高的来源。
第 31 条一眼自检判据
我手写进复用调用的任何字符串 / 数字常量，系统别处是不是已经在推导它？
是 → 删掉我的字面量，复用系统推导。否 → 才允许保留。
（典型反面教材：复用 openReportPreview(reportId) 却硬塞 'md'，把 HTML 报告误判成 markdown 转义成源码。）
反例 vs 正例（来自 #437 真实返工）
| 写法 | 后果 | |
|---|---|---|
| ❌ 错误 | openReportPreview(reportId, 'md') |
硬塞 'md'，HTML 报告被强制走 markdown 分支 → 整页源码被转义显示 |
| ✅ 正确 | openReportPreview(reportId) |
不塞字面量，函数内部按后端 /api/reports/{id}?inline=1 响应 Content-Type 自动选 html / md 渲染 |
根因三连：① 只 grep 函数定义、没 grep 调用点；② 想当然"系统偏 md"没核实该报告实际是 HTML（应以生产真实数据为准）；③ 自测只确认"打开了"没比对既有正常态。
一键自检清单（写复用代码前逐项过）
- [ ] 已
grep -rn "目标函数名("看过所有调用点 - [ ] 新调用的参数 / 取值逻辑与既有调用点一致
- [ ] 没有任何"我猜的格式 / 类型 / id"被硬编码进复用调用
- [ ] 新代码只接触发点，动作本体交给既有 handler
- [ ] 验收比对了既有正常态 / 真实数据（不是只看连通性）
真实案例锚点
- 项目：同事会
tongshihui-python-server+admin-console+ 小程序 - 时间：2026-08-10
- 触发：#437 修正（PC 消息中心报告分享消息点击）
- 返工代价：烧 1 个版本号（frontend V2.3.544）才修正
- 历史同源返工：feed/my-notes 烧 3 版、pm-preview 烧 3 版
- 规范载体：
project_spec/代码复用与禁止盲目创新规范.md（V1.0.19） - 记忆常驻：用户级
MEMORY.md「🔴 框架复用铁律」段（规则 27–31）
关联技能
deploy-sandbox-fixes：本技能同步进平台技能库、登记 platform_skill 治理发版线时的部署避坑fastapi-version-release：version_changelog 登记规范
