code-tastelisted

# Code Taste 个人代码品味，重点约束**判断力**而不是语法风格。 ## Overview 先控制复杂度，再实现功能；先把模型、边界和命名想清楚，再进入实现细节。 从第一性原理出发，先追问原始问题和原始需求到底是什么，再讨论方案、抽象和实现。 ## 何时用 · 先定档 判断力 skill 的头号���败模式是**对琐碎改动过度上设计脑**。所以先定档，再决定起多少、读哪层深度。 **用本 skill**：编写新代码 / 涉及结构判断的补丁 / 重构；做方案设计、模块拆分、接口设计；review 代码、评估坏味道、判断是否该抽象；定期回看近期 merged MR / 提交序列，识别补丁背后反复缺失的概念（自底向上迭代，沉淀进 `references/examples/`，一案例一文件）。 **先别来本 skill**： - 核心是“为什么坏了 / 哪里报错 / 线上现象怎么定位” → 使用项目对应的 debugging / trace 能力，证据不足时不要先下结构结论。 - 核心是“要不要新增功能、功能怎么设计”且需求还没稳 → 先澄清原始需求和约束。 - 已有明确设计 / 计划 → 本 skill 只检查复杂度和边界，不替代执行型 skill。 **定档**（决定起多少设计脑）： | 档 | 什么改动 | 起多少 | |----|----------|--------| | **T0 琐碎** | 不涉及新的语义判断，主要是配置值、版本号、文案、格式或机械重命名等改动 | 不起设计脑，优先直接改；最多扫常驻项——命名是否表意、日志 / 错误是否带上下文 | | **T1 局部** | 在既有大概念和边界内，调整行为，或设计 / 调整局部小概念、类型与流程 | 局部设计 + 代码 review——确认 owner 不变，再看正确性、可读性、命名、函数层级与日志（见 [[/references/code/review|代码 Review]]） | | **T2 结构** | 改变顶层概念、owner、模块边界、依赖方向、跨边界契约或广泛引用的公共符号 | 完整设计脑——模型 / 边界 / 依赖 / 接口（从 [[/references/architecture/README|架构判断入口]] 进入） | 不同档位使用不同的主要观察尺度： - **T2：系统 = 核心概念 + 主流程**，先判断顶层概念、owner、边界及其协作关系。 - **T1 及以下：程序 = 数据结构 + 算法；代码 = 控制 + 逻辑**，在既有边界内判断数据如何表达、行为 如何实现，以及执行顺序与业务规则是否清楚分离。 > 档由改动的**语义变化与影响层级**决定，不由行数、文件数或是否新增类型决定：百行机械 rename 仍是 > T0；大概念内部新增私有类型或接口可以是 T1；5 行修改若改变跨边界契约也应是 T2。 意图标记也随档位增量判断：T0 通常不新增，但不能让已有 mark 与代码失真；T1 的 bugfix、行为分支和 局部契约变化检查 `spec` / `rule`；T2 的接口、模型和边界变化检查 `spec` / `rule` / `link`，只有具体验证 场景值得长期寻址或复用时才补 `case`。详细判断见 [[mark|结构化意图标记]]。 ## Core Rules - 先判断原始问题是业务问题还是技术问题，不要直接掉进实现细节。 - 新概念只有具备独立身份、owner、生命周期、行为或契约，且