产品交互复盘：删掉不必要功能前，先看用户路径

产品交互复盘：删掉不必要功能前，先看用户路径

许多开发者建立了一个又一个 Markdown 复盘文档文件夹，里面写满了“界面弹窗太多导致转化率下降”、“前端数据模型与后端字段映射混乱”等深刻总结。但在下一个月开发新功能时，依然手忙脚乱地在界面里塞入了 4 个新的确认弹窗，代码里重新出现了同名不同义的脏数据类型。

放在文档库里的复盘记录只是死文字。只有把复盘结论翻译成可被 ESLint、TypeScript 类型系统与 Git pre-commit 静态拦截的代码硬规约，复盘才算真正派上了用场。

1. 从“死文档”到“工程卡尺”的转化路径

人类工程师在忙碌或赶进度时，记忆是靠不住的。产品交互设计中的“极简取舍”不能寄希望于自觉，而要靠静态分析工具的无情拦截。

如果你复盘发现“二级弹窗会破坏核心沉浸感”，那么就应该写一个正则或 AST 规则，禁止在 Modal 组件内部嵌套 Modal；如果你复盘发现“后端字段没做非空防御导致白屏”，就应该把 TypeScript 配置调到最严严格模式。

graph TD A[月度故障/产品复盘记录] --> B{复盘结论分类机制} B -->|交互体验类结论| C[约束为 UI 组件库 Design Token / 禁忌模式] C --> D[自定义 ESLint 规则 / AST 静态扫描] B -->|代码架构类结论| E[约束为 TypeScript 强类型 Schema] E --> F[Git Pre-commit / Husky 拦截] D --> G[提交代码时自动拦截违规代码] F --> G G --> H[复盘经验永续生效]

如上面所示，极简取舍的闭环链条：把复盘经验转换为静态规约，再通过 git hooks 强制卡住。

2. 用 ESLint 与 AST 静态检查阻止反模式重演

我们可以在项目中使用eslint命令对代码进行静态规约扫描，找出违规的交互反模式与滥用的复杂状态：

# 执行 ESLint 扫描，捕获项目中被禁止的组件嵌套与魔数硬编码 npx eslint "src/**/*.{ts,tsx}" --format stylish

如果在终端中看到报错，开发者应现场修复才能提交代码，彻底阻断了不良代码合入主干的可能。

3. 自定义 ESLint 插件：自动化阻断 UI 交互反模式

下面是一段自定义的 ESLint 规则代码。它展示了如何通过简单的 AST（抽象语法树）节点匹配，禁止开发者在代码中滥用多重嵌套弹窗（Modal in Modal），从而强行落地产品交互的极简原则：

// eslint-rules/no-nested-modal.js /** * @type {import('eslint').Rule.RuleModule} */ module.exports = { meta: { type: 'problem', docs: { description: '禁止在 UI 交互中嵌套多层 Modal 弹窗，维护产品交互极简原则', category: 'Best Practices', }, messages: { avoidNestedModal: '【复盘规约】严禁在 Modal 组件内部嵌套另一个 Modal！这会严重破坏用户沉浸感，请改用 Drawer 或平铺视图。', }, schema: [], }, create(context) { let modalStackCount = 0; return { // 匹配 JSX 元素的开始标签 JSXOpeningElement(node) { const tagName = node.name.name; if (tagName === 'Modal' || tagName === 'Dialog') { modalStackCount++; if (modalStackCount > 1) { context.report({ node, messageId: 'avoidNestedModal', }); } } }, // 匹配 JSX 元素的结束标签 JSXClosingElement(node) { const tagName = node.name.name; if (tagName === 'Modal' || tagName === 'Dialog') { modalStackCount = Math.max(0, modalStackCount - 1); } }, }; }, };

将这条规则配置到.eslintrc.js中后，任何人在编写代码时只要试图嵌套 Modal，编辑器立刻红线报错，连 CI 流水线都无法通过。

4. 可持续迭代的月度复盘三步走

为了确保复盘记录真正转化为代码硬卡尺，在每个月末执行这三步：

1. 提取最大痛点 Issue：从当月的 Bug 列表与用户反馈中，挑出最严重或频次最高的 2 个问题。
2. 制定代码化解决方案：
   • 痛点：按钮重复点击导致重复发请求 ➔解法：写一个全局 HookuseSingleSubmit，并用 ESLint 强制校验表单提交函数。
   • 痛点：新加功能导致主界面太拥挤 ➔解法：制定“主屏功能炝的组件审查标准。
3. 合入 lint-staged 与 Husky：把验证规则自动化绑定在git commit动作上。

通过把复盘落到代码和 AST 静态工具上，你每一次踩坑留下的经验，都会演变为守护代码库质量的铁壁铜墙。