简单说：它就是品控规则的「测试用例」。任何工程化的规则系统都需要两样东西——规则本身，以及用来验证规则是否还在线的样本集。规则告诉你「什么样的输出才算合格」，样本集告诉你「现在的输出还合不合格」。两者缺一不可。在 sharp-skills 里，每个模块（tech-writing / dataviz / copywriting / api-design / interview / presentat

Spring Event 机制是观察者模式的工程化实现，但它不是银弹。+ 自定义线程池 + 事件携带完整上下文 +@Order控制顺序。但一旦你发现自己在写第 10 个，就该停下来想一想了——你是不是在用事件机制逃避架构设计？把正常的流程编排拆成一堆离散的 Listener，除了让调用链不可追踪之外，没有任何好处。观察者模式解决的是"Subject 不依赖 Observer"的问题，不是"我不知道

这个认知没错，但只覆盖了模板方法 20% 的用法——剩下的 80% 藏在各种 Spring 组件里，你天天在用却从来没把它跟设计模式挂钩。剩下的 6 个步骤是 JdbcTemplate 帮你写好的——这就是模板方法模式的本质：**固定流程 + 可变步骤**。# 你写 JdbcTemplate 的 callback 写了三年——这就是模板方法，但你从没把它当设计模式。ps -> ps.setStri

java：从文件读字节：把字节按 UTF-8 解码成字符：给字符流加缓冲，减少系统调用三层可以独立替换。比如把换成，上面两层不用动。职责垂直拆分，运行时水平组合。用组合代替继承，给对象动态添加职责。它最适合的场景是：- 功能可以独立变化- 功能可以叠加组合- 不想改原有类但它也带来成本：调用链变深、顺序敏感、对象身份改变。用之前先想清楚，你的场景是真需要装饰器，还是只是想让类结构看起来"很设计模式

如果你写过，你就用了三个装饰器。Java I/O 是装饰器模式的教科书示例——每本教材引用它，每个教程赞美其灵活性。但没人说需要7层装饰器读一个文件时会怎样。这是装饰器模式的真实问题：它的代价与你想组合的功能数量呈平方级增长。每个装饰器包裹一个接口、加一个功能、把其余全部传递。要7个功能，你需要7个装饰器、7个构造调用、7层深的链。调试它需要解包7层。测试它需要 mock 7个接口。理解它需要读7

AI 输出的 80 分到 100 分之间，差的不是更大的模型、更长的 prompt、更多的示例——差的是可执行的品控规则。把"好"的定义从主观判断变成可量化的标准，从"应该做什么"变成"绝对不能做什么"，AI 的输出质量会直接跳一个台阶。sharp-skills 把这件事做成了可以直接安装的规则包。不是理论，不是方法论，是你可以今天就开始用的约束条件。

电商系统的订单状态流转，大概是 if-else 癌变的重灾区。这个方法的作者后来离职了。他留下的遗产是 500 多行的，包含 12 种状态、45 种状态转换。每加一个新状态，要找遍所有 if-else 分支里有没有遗漏。改一行就怕改错十行，上线一次心惊肉跳一次。

别做那种"AI生成完直接commit"的事，我见过同事这么干，code review的时候发现测试里所有的mock都是any()，所有断言都是assertNotNull——这种测试除了拉低覆盖率什么用都没有。返回的是null需要显式类型转换，而AI完全不理解这个坑——它在训练数据里见过argThat的用法，但不了解Java泛型在Mockito里的类型推断限制。我的经验是：涉及Spring容器和测试

绝不让AI一次性重构超过3个策略类。小块小块来，每块重构完跑一遍全量测试，确认没引入回归再继续。AI给的"一口气全重构"的方案看起来很爽，但出了问题你都不知道从哪开始排查。AI生成的所有条件判断必须逐行核验。它可能会遗漏条件、合并不该合并的分支、或者"优化"掉一些看起来不合理但实际有业务含义的逻辑。别偷这个懒。重构前后跑同一组测试用例。这看起来是废话，但实际执行中很容易因为"策略类拆完了肯定没问题

我们有个支付回调服务，逻辑不复杂——接收第三方支付结果，校验签名，更新订单状态，发个通知。这代码跑了两年没出过事，直到上个月我决定让AI帮我重写异常处理部分。起因是代码里的try-catch太随意了，到处都是catch(Exception e)然后log.error完事，有些异常该重试的没重试，该回滚的没回滚。我把代码丢给AI，让它帮我"规范化异常处理"，它倒是挺积极，一口气给我加了七八种异常类型