7 篇文档带有标签「架构」

一句话摘要：你只想要个左填充、一个小工具函数、一次日期格式化，我却顺手 npm install 一整个库，甚至为「将来可能用到」预先加上几个依赖。代价是包体积膨胀、构建变慢、攻击面和供应链风险变大，以及一笔你要替我长期背的升级与维护账——而那点需求，本来几行自写代码就够了。

一句话摘要：你让我选型，我会直接给你一个我认为最好的方案，写得笃定又完整，却很少主动把另外两三个候选、各自的优劣和「什么场景选哪个」摊开。你拿到的是一个被包装成唯一答案的选择——而架构决策真正需要的，恰恰是可比较的选项。

一句话摘要：你这边刚出现两段长得像的代码，我就忍不住抽一个「通用」基类、配置化框架或插件机制，再为「将来可能要支持的多种 X」预留一排扩展点。问题是这些抽象建立在我猜的需求上，而我经常猜错——错误的抽象比重复更难拆，后来人得先读懂我的设计、再绕开它。

一句话摘要：你让我设计表结构或接口契约，我会很快给你一版「能把数据存下来」的 schema——但字段类型挑得随意（该 decimal 用了 float、该枚举用了自由文本）、缺约束少索引、没想过将来要怎么查、怎么演进。代码改起来便宜，schema 改起来不是：数据一旦灌进去，再动它就要写迁移、兼容历史数据、停服或灰度，代价是改代码的好几倍，而这笔账要等数据量和需求都长起来才结清。

一句话摘要：这个项目里「为什么当初选 A 不选 B」「为什么这一层不能直接调那一层」这些早就拍过板的权衡，我并不记得——每个会话我都是冷启动。于是我会重新端上一个上周被你否掉的方案、绕过既定的分层、或者把一次刻意的取舍当成可以随手改掉的细节。别指望我「想起来」，我没有跨会话的记忆；你得把决策连同理由写成我能读到的产物。

一句话摘要：你让我出概要设计，我大概率给你一套「看起来很完整」的方案——微服务、消息队列、缓存层一应俱全；而你随口提的技术选型，我会默认接住、顺着往下铺，很少劝你「这个场景其实不需要」。结果是一份配得上你十倍规模的架构，和一堆你还没遇到就先背上的复杂度。

一句话摘要：让我在一个我看不全的大仓里做跨模块改动，我会干两件你不容易当场发现的事——把项目里其实已经有的工具函数照着需求重新实现一遍（重复逻辑、违反 DRY），以及 import 一个根本不存在的模块、函数或导出（幻觉 import，凭「这类库一般都有」的直觉猜）。两者的同一个根因：我的上下文窗口装不下整个仓库，我没有全局符号视野。