AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载技术债务的可怕之处不在于它存在而在于它从未被系统性地识别、度量与排序。AASagentic-awesome-skills仓库中的brooks-debt技能提供了一套可复用的技术债务评估方法论以 Symptom → Source → Consequence → Remedy症状 → 根源 → 后果 → 补救铁律贯穿始终通过四步流程完成全代码库的腐化风险扫描、Pain × Spread 定量评分、债务意图分类与按风险分组汇报。读完本文你将掌握这套评估框架的完整操作流程与输出规范能够直接运用于任意代码库产出可供团队排期的重构路线图。技能定位什么时候使用 brooks-debtbrooks-debt是 AAS Claude 插件中 brooks 技能家族的一员。根据其 SKILL.md 的定义它用于识别、分类和优先级排序可维护性问题帮助团队建立重构路线图其设计理念汲取自十二本经典工程书籍如The Pragmatic Programmer、Clean Code、Refactoring、Domain-Driven Design等详见同家族的 brooks-lint 技能。触发场景很明确当用户询问技术债务、重构优先级、该先清理什么、为什么这个模块这么难改之类的问题时就应启用该技能。它关注的不是语法层面的风格问题而是结构性的、概念性的债务——正如 brooks-lint 所强调的最难的 bug 是概念性的而非语法性的命名致敬《人月神话》作者 Fred Brooks。brooks-debt的核心操作文档是 debt-guide.md下文即以该指南为主线展开。铁律所有发现必须遵循 Symptom → Source → Consequence → Remedydebt-guide.md开篇即规定了评估的强制约束——Iron Law铁律代码库中的每一项发现都必须按四个环节完整陈述环节含义Symptom症状你观察到的外在现象如某函数过长、某模块改动频繁出 bugSource根源导致该症状的底层结构原因如缺失抽象层、依赖方向错误Consequence后果该问题对开发效率、质量或交付的具体影响Remedy补救可行的修复方向供团队后续评估与排期这条铁律的价值在于防止评估退化为流水账式列问题。只报症状不追根源团队拿到的是噪音只给结论不列依据结论无法被复核。四环节闭环使得每一条 finding 都同时具备可解释性与可执行性也直接支撑了后续的评分与分组。证据收集最多只问一个问题评估的第一步是确认信息充足性。指南给出的策略非常克制如果证据不足只向用户提出一个问题且必须从以下四个候选问题中选出与当前已知信息最相关的一个代码库中哪个部分修改一个典型功能耗时最长定位改动成本最高的区域哪个模块是开发者避而不碰的为什么定位恐惧/风险区域系统哪些部分测试最少、bug 最多定位质量薄弱区域是否存在只有一个人完全理解的模块定位知识孤岛/单点依赖得到一次回答后立即继续不得追问第二个问题如果用户拒绝回答或表示不知道则基于现有证据继续并在报告中明确标注哪些区域因证据不足未能评估。这种单问题 明示盲区的设计背后是务实的评估哲学技术债务评估的本意是快速建立全局画像而不是陷入无止境的信息收集同时坦诚标注评估盲区比假装全面更符合工程诚实原则。四步分析流程评估主体由四个按序执行的步骤构成。指南特别强调顺序不可颠倒必须先完整列出所有发现再开始评分。Step 1全面腐化风险扫描Full Decay Risk Scan第一步要求扫描全部六类腐化风险且在评分任何一条之前先列出所有发现。这样做的目的是防止锚定效应——避免因为过早聚焦早期发现而遗漏系统性的模式。六类风险的定义与排查要点如下1. Cognitive Overload认知过载命名问题是否普遍存在是否存在深层嵌套逻辑、散落在多个模块中的超长函数 排查信号开发者读代码时是否需要大量脑力解压同名不同义或同义不同名。2. Change Propagation变更传播哪些模块一旦被修改就会引发连锁效应新增一个功能时是否有模块是人人必修的 排查信号改动局部需求却被迫触碰大量无关文件牵一发动全身的上帝类God class。3. Knowledge Duplication知识重复同一个概念被独立实现了多少次领域词汇在全代码库中是否保持一致 排查信号多处各自实现同一套校验/转换逻辑DRY 原则的违反同一业务概念在不同层有不同命名。4. Accidental Complexity意外复杂度是否存在不带来价值的架构层或抽象基础设施开销与所解决问题的规模是否成比例 排查信号为简单需求搭建了过重框架抽象层只传递数据、不提供任何封装价值。5. Dependency Disorder依赖失序是否存在依赖环领域逻辑是否反向依赖基础设施是否有模块在分层体系中找不到明确位置 排查信号包/模块间的循环引用业务核心耦合了数据库、消息队列等具体实现。6. Domain Model Distortion领域模型扭曲业务逻辑是否放在了正确的层代码命名是否与业务命名一致领域对象是否贫血anemic只有 getter/setter 而无行为 排查信号业务规则散落在控制器或工具类中领域对象退化为纯数据传输对象。Step 2用 Pain × Spread 为每条发现评分在列出全部发现之后逐条评分。评分体系由两个维度构成Pain疼痛度1–3 分——该问题当前对开发速度的实际拖累程度3 分开发者主动回避此区域大多数改动都会在此引发 bug例没人想碰 billing 模块因为一改就坏别的东西2 分在此区域工作明显比代码库其他部分慢例在这里加一个字段要花别处 2–3 倍时间1 分属于质量问题但当前未造成实际痛苦例命名不一致但我们彼此都懂意思Spread波及范围1–3 分——该问题影响的文件、模块或开发者数量3 分影响 5 个模块或团队全体开发者例每个新功能都要触碰 core/ 里的上帝类2 分影响 2–4 个模块或团队子集例auth 与 notification 模块强耦合1 分局限于单一模块或单个开发者负责的区域例只有一个人维护的遗留解析器Priority Pain × Spread最高 9 分。优先级分档如下优先级分值分类处置动作7–9Critical debt关键债务在下一个迭代sprint内处理4–6Scheduled debt计划债务在本季度内规划1–3Monitored debt监控债务记录并持续观察该公式的精妙之处在于把痛不痛与影响面多大两个正交维度相乘一个极度痛苦但仅限单人维护的模块3×13只应被监控而一个中等痛苦但影响全团队的模块2×36则应进入季度计划。这避免了团队被局部剧痛牵着走而忽视全局慢性病。Step 3分类债务意图Intentional vs Accidental评分之后将每条发现标记为有意债务或意外债务Intentional debt有意债务——为赶 deadline 而做出的有意识取舍且预期日后偿还。团队知晓它的存在。它可能是正当的战略原型、迁移期间已知的临时 workaround。Accidental debt意外债务——在缺乏明确决策的情况下累积的劣化团队并未主动选择它甚至可能不知道它存在。这正是 Ward Cunningham 原始定义所警示的类型——不是战术权衡而是结构性侵蚀。指南给出了一条关键的判定规则没有任何可见偿还计划的有意债务无关联 ticket、无代码注释、无文档化的决策记录在优先级处理时应视同意外债务。因为团队知道这一前提已经不成立它事实上已退化为无人负责的结构性侵蚀。处置原则明确先集中治理能量于意外债务因为有意债务至少有一个明确的所有者owner其风险是可控、可追踪的。Step 4按腐化风险分组最终报告按风险类型分组呈现而非按文件或模块分组。按风险分组能够揭示系统性模式进而决定干预层级变更传播是系统性的 → 需要架构级干预改造依赖结构而非局部重构认知过载是孤立的 →局部重构即可解决这一区分至关重要同样的 finding若属系统性模式局部修补只会让债务在别处复发若属孤立问题动用架构改造反而属于过度工程。输出规范Debt Summary Table评估完成后输出使用标准报告模板模式Mode标注为Tech Debt Assessment。在 Findings 之后追加一张债务汇总表## Debt Summary | Risk | Findings | Avg Priority | Classification | Intent | |------|----------|-------------|----------------|--------| | Cognitive Overload | N | X.X | Monitored/Scheduled/Critical | intentional/accidental | | Change Propagation | N | X.X | ... | ... | | Knowledge Duplication | N | X.X | ... | ... | | Accidental Complexity | N | X.X | ... | ... | | Dependency Disorder | N | X.X | ... | ... | | Domain Model Distortion | N | X.X | ... | ... | **Recommended focus:** [risks with highest average priority]表中每行聚合一种风险Findings为该风险下的发现条数Avg Priority为该类风险的平均 Pain×Spread 分值Classification对应 7–9 / 4–6 / 1–3 三档Intent标记该类债务主要是有意还是意外。表末的Recommended focus直接给出平均优先级最高的风险类型作为团队下一步的聚焦方向——这也是整个评估的核心交付物一份可排期、可追踪、有依据的重构路线图输入。使用流程与边界在实际调用该技能时SKILL.md 定义了完整的执行顺序若用户未描述代码库或未指明具体区域先按 Auto Scope Detection 自动判定评估范围执行指南 Step 1扫描六类风险并先列全、后评分应用 Pain × Spread 公式评分并分类债务意图Step 2–3按腐化风险分组Step 4按标准报告模板输出并附 Debt Summary Table报告 Mode 行标注Tech Debt Assessment。需要明确的使用边界Limitations该技能仅在任务与其上游来源及本地项目上下文明确匹配时使用应用任何变更前须自行验证命令、生成代码、依赖、凭据与外部服务行为示例不能替代环境专属的测试、安全审查涉及破坏性或高成本操作须经用户批准。换言之它产出的是评估结论与建议路线落地执行仍需工程师判断与验证。小结brooks-debt的价值不在于发明新的度量指标而在于把技术债务治理从凭感觉升级为一套可重复的四步流程全量扫描六类腐化风险先列后评杜绝锚定→ Pain × Spread 定量排序区分痛点与影响面→ 意图分类识别真正无人负责的意外债务→ 按风险分组汇报区分架构级干预与局部重构。配合 Iron Law 的四环节表述与 Debt Summary Table团队可以拿到一份既解释为什么又回答先做什么的债务全景图并据此排出可执行的迭代计划。对任何正在扩张、重构或接手遗留系统的团队而言这套框架都值得直接落地一试。赞分享AI 技能AI 插件【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,445 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载相关推荐技术债务评估实战基于 agentic-awesome-skills 中 brooks-debt 技能的六维风险扫描与 Pain × Spread 优先级模型技术债务评估实战基于 agentic awesome skills 中 brooks debt 技能的六维风险扫描与 Pain × Spread 优先级模型AI 技能AI 插件Brooks-Review PR 代码审查指南基于 12 本经典软件工程著作的腐化风险扫描与 Iron Law 实践Brooks Review PR 代码审查指南基于 12 本经典软件工程著作的腐化风险扫描与 Iron Law 实践 本指南围绕 agentic awesomAI 技能AI 插件终极指南如何用Arnis将现实世界城市一键导入Minecraft终极指南如何用Arnis将现实世界城市一键导入Minecraft 你是否梦想过在Minecraft中重建自己的家乡城市或者想探索纽约、巴黎、东京等世界著名都桌面应用游戏开发GIS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考