ds-principles 是一套面向工程实践的紧凑原则集合，整体思路是“若触发条件匹配，则应用对应规则”，并建议在回顾时指出哪些原则真正改变了决策。资料按四个部分组织：设计、调试与验证、流程、类型。
一、设计原则
- 先减后加：先删除死代码与过时的检查，再做能工作的最短改动；没有单一使用者的抽象不引入。适用于评估改动规模或想新增一层抽象时。
- 数据形状优先：在写逻辑之前先确定核心类型与结构。适用于编写新逻辑之前。
- 领域建模：把状态放进单一结构（如带类型的联合、状态机或查找表），而非分散的条件分支。适用于代码分支很多或同一形状在多个文件中重复时。
- 为新需求重新设计：把新需求当作从第一天就存在来适配。适用于新增内容使设计吃紧时。
- 降低读者负担：内联只有一个调用者的包装，缩小可变作用域。适用于代码难以追踪时。
- 边界处设守卫：在输入进入处（CLI、配置、网络、文件、外部 API）做校验，内部信任类型、核心逻辑保持纯净。适用于新增校验或错误处理时。
- 步骤幂等：即使崩溃后重跑，步骤也到达同一状态。适用于命令、初始化与重试。
- 无共享写入者：在使用锁之前，先让每个并发参与者拥有自己的文件、分支或键。适用于并行工作触碰共享状态时。
- 迁移后删除：一次改动中迁移所有调用方并删除旧 API，不保留垫片。适用于替换 API 或分阶段重写时。
- 比较方案：对前所未有的设计先画两三个方案，偏好更少但打磨更好的功能。适用于全新架构、体验或范围选择时。
二、调试与验证原则
- 修根因：在状态首次出错的地方修复；守卫只能处理合法状态。适用于调试时。
- 攻击前提：两次失败的修复共享同一假设时，写下该假设并直接检验。适用于第三次尝试之前。
- 证明其可用：运行真实的东西并阅读真实输出，而非代理指标。适用于宣称完成之前。
- 可验证单元：把工作拆成每步都以一次通过的检查结束的单元。适用于批量清扫、迁移与堆叠提交。
- 测试行为：断言调用方可观察的内容，使测试在重构后仍然成立。适用于编写或保留测试时。
- 解释数字：找出限制测量的因素，并确认它测量了正确的工作。适用于基准与评测分数。
- 构建工具：把批量或重复工作写成可重跑的脚本。适用于大批量编辑或检查。
三、流程原则
- 守住上下文：保留摘要而非转储，把大量阅读交给子代理。适用于输出或文件很大时。
- 不要因等待人而阻塞：对可逆工作直接推进并展示结果。适用于想先问“我该做吗”时。
- 固化重复教训：同一纠正出现两次就变成 lint、测试或脚本。适用于错误反复出现时。
- 注释解释原因：只为代码无法表达的原因保留注释，如外部约束或公开 API 契约；删除叙述性注释与死代码；若某段代码的意外需要注释解释，就修正代码。适用于编写或审阅代码时。
四、类型原则
- 让非法状态不可表示：用可辨识联合而非可选字段堆叠。
- 在边界把外部数据一次性解析为具名类型，内部信任它。
- 不可信输入用 unknown，绝不用 any；校验前不做 as 断言。
- 类型由 schema 派生，而非手写守卫。
- 在默认分支加 never 检查，使新增变体导致构建失败。
- 对不可混用的基础类型加品牌标记，如用户 ID 与订单 ID。
资料未提供安装方式、命令示例、版本、平台支持、收费与效果数据，以上内容暂未提供。