这是一套语言无关的架构与工程原则，面向由个人维护、并可能由未来编码智能体参与的小型项目。核心目标是优化局部推理：开发者应能通过查看代码库中一小块明显区域，就找到、理解、修改并验证某项能力，而无需穿越层层间接或隐藏依赖。
主要能力与主张：先论证复杂度再实现，挑战需求本身而非只改代码，区分证据与假设，让每个新概念、校验、层、配置项或测试都对应真实风险或能力；优先小而完整的方案，避免为不活跃的替代实现保留临时兼容代码，也不要用更难导航的框架去解决重复。
结构上按能力而非架构分层组织包和目录，命名与导航要直观，偏好少量高内聚包，保持浅层结构，避免 utils、common、helpers 等杂物堆。实现上为消费者设计 API，优先具体依赖，不凭习惯造接口，让副作用显式，清晰优先于聪明或投机复用，审慎处理错误，仅在值得其复杂度时使用并发。
配置与运维方面：代码与部署设置分离，外部化密钥和环境相关值，绝不内嵌凭据；可复现构建与发布，声明并固定依赖，构建一次并推广不可变制品；进程可替换、持久状态有意图，环境保持有意义的一致，系统可观测可运维。
验证与演进方面：测试可观察行为而非偶然实现，行为变更优先测试先行的红绿垂直切片，覆盖重要成功、失败与恢复路径；变更小而完整，保留契约除非有意更改；决策要持久可发现，让代码库能自我说明架构。
资料还给出快速设计检查：需求是否必要、最小结果是什么、他人会自然在哪里寻找该能力、边界是否对应真实职责、复杂度是否比直接方案更简单地解决有证据的需求或重大风险、重要行为与失败能否验证和恢复。该检查是轻量决策辅助，不是每次编辑的强制清单。原则受 Effective Go、Go 代码评审评论、Go Proverbs 和十二要素应用启发，但不强制使用 Go、不要求所有设置都用环境变量，也不要求在有意图持久状态处追求无状态。具体安装或使用命令资料未提供。