网盘 ByteCloud：https://cloud.bytelighting.cn

参考文章：一泽Eze - Web Access：一个 Skill，拉满 Agent 联网和浏览器能力

2026 年，Prompt Engineering 正在被重新定义。IBM、Anthropic、OpenAI 等机构不约而同地指出，这个领域正在从"写好一段提示词"演进为"设计自主推理系统的认知架构"。在这个背景下，Skill —— 一种介于 Prompt 和 Agent Framework 之间的中间层 —— 成为了释放模型能力的关键杠杆。

本文以一个具体的联网 Skill 设计案例为起点，逐步泛化出一套通用的 Skill 设计方法论，并结合学术研究和个人实践经验，探讨如何在不同领域中设计出高质量的 Agent Skill。

核心认知：上下文窗口是关键

使用 Claude Code 时，最容易被忽视的瓶颈不是提示词质量，也不是模型选择，而是 上下文窗口 的管理。可以把它理解为 Claude 的 "白板" —— 你发的每条消息、Claude 读的每个文件、执行的每条命令都会写上去。白板满了，Claude 就会表现下滑：遗忘指令、犯低级错误、开始重复自己。所以核心原则是：管好这块白板，就是管好 AI 的注意力。

策略一：先做计划，再写代码

新手最常犯的错误是直接让 Claude 动手写代码，结果方向跑偏，还浪费了大量上下文空间。正确做法是使用 Plan Mode（Shift+Tab 切换），让 Claude 先阅读文件、理清关联、输出完整计划（改哪些文件、步骤顺序、潜在风险），经你审查确认后再切回正常模式开发。多花十分钟做计划，能避免无数次返工。

1. 基本概念

1.1 定义

1. 软件可靠性：软件产品在 规定的条件 下和 规定的时间区间 完成 规定功能 的能力。
2. 串并联系统可靠性：无论什么系统，都是由多个设备组成的，协同工作，而这多个设备的组合方式可以是串联、并联，也可以是混合模式
   1. 串联系统：
      1. 一个设备不可靠，整个系统崩溃。
      2. 可靠性公式：$ R_{串联} = R_1 × R_2 × ⋯ × R_n $
   2. 并联系统：
      1. 所有设备都不可靠，整个系统才崩溃。
      2. 可靠性公式：$ R_{并联} = 1 - (1 - R_1)(1 - R_2)...(1 - R_n) $
3. 广义的软件可靠性测试：指为了 最终评价软件系统的可靠性 而运用 建模、统计、试验、分析 和 评价 等一系列手段对软件系统实施的一种测试。
4. 狭义的软件可靠性测试：指为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试。它是面向缺陷的测试，以用户将要使用的方式来测试软件。
5. ISO/IEC 25010 软件质量模型中 “可靠性（Reliability）” 的子特性分类：
   1. 无故障性（Faultlessness）：
   2. 可用性（Availability）： 产品在需要使用时可运行且可访问的能力。
   3. 容错性（Fault Tolerance）： 系统在出现故障时仍能维持部分功能的能力。
   4. 可恢复性（Recoverability）： 软件在发生失败后恢复数据和恢复服务的能力。

1. 软件系统质量属性

1.1 概念

1. 软件系统质量：软件系统与明确地和隐含地定义的需求相一致的程度。
2. 软件系统质量属性：是一个系统的可测量或可测试的属性，用来描述系统满足 利益相关者（Stakeholders）需求的程度。

1.2 分类

1. 开发期质量属性
   1. 易理解性：指设计 被开发人员理解 的难易程度。
   2. 可扩展性：软件因 适应新需求 或需求变化而增加新功能的能力，也称为灵活性。
   3. 可重用性：指 重用 软件系统或某一部分的难易程度。
   4. 可测试性：对软件测试以证明其满足需求规范的难易程度。（度量指标有：如果存在缺陷出现故障的概率、测试准备时间、测试环境的准备时间）
      1. 案例题常考，关键词：接口调试，远程调试，测试功能
      2. 与远程调试相关。
   5. 可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
   6. 可移植性：将软件系统从一个运行环境 转移 到另一个不同的运行环境的难易程度。
2. 运行期质量属性
   1. 性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
   2. 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
   3. 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
   4. 互操作性：指本软件系统 与其他系统交换数据和相互调用服务 的难易程度。
   5. 可靠性：软件系统在一定的时间内持续无故障运行的能力。（多长时间不出问题）
   6. 可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。（出了故障多久能够恢复）
   7. 鲁棒性：是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力，也称 健壮性 或 容错性。

1. 软件架构

1.1 概念（宏观）

1. 软件系统架构是关于软件系统的 结构、行为 和 属性 的高级抽象（宏观层次上）。
2. 在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是描述组件的 交互关系。
3. 在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或对象。
4. 软件系统架构不仅指定了软件系统的 组织 和 拓扑结构，而且显示了 系统需求 和 组件 之间的对应关系，包括设计决策的 基本方法和基本原理。
5. ANSI/IEEE 1471-2000是对软件密集型系统的架构进行描述的标准。在该标准中，
   1. 视图 主要用于描述 软件架构模型。
   2. 在此基础上，通常采用 视角 描述某个 利益相关人（Stakeholder）所关注架构模型的某一方面。
   3. 架构 则是对所有利益相关人关注点的 响应和回答。

1. 概述

1. 核心目标：重复的体系结构模式（软件复用/重用）
2. 软件体系结构（架构）风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族（一类架构所共有的特征），即一个体系结构定义一个词汇表和一组约束。主要包括以下三部分：
   1. 架构定义：
   2. 架构词汇表：包含构件和连接件
   3. 架构约束：约束定义构件和连接件的组合方式
3. 体系结构风格反映了领域中众多系统所 共有的结构和语义特性，强调对 架构设计 的重用，并指导如何将各个模块和子系统有效地组织成一个完整的系统

智能体（Agent）搭建相关资料

1. 概述

2025 年 12 月 18 日，Anthropic 发布了新的开源标准 Agent Skills，早期叫 Claude Skills，后来变成了大家可以按照约定使用的标准。

以前我们要让 AI 完成一个复杂任务（比如：帮你写代码、部署测试环境、或者按照公司品牌规范写推文），我们通常需要写一段超长的 Prompt（提示词）。

但问题是：Prompt 太长了 AI 容易忘，而且每次都要重新教一遍，并且在此期间 AI 可能需要通过多次调用工具以便获取和处理这些任务的能力，容易导致 Token 无限消耗。

AgentSkills 的出现就是为了解决这个问题。简单来说，它给 AI 制定了一套 “标准技能包”，类似于给 AI 的 “说明书”，任何支持该标准的 AI 都能通过阅读说明书学会这个技能，且执行得非常稳。

1. 面向对象的设计原则（SOLID）

1.1 单一职责原则（Single Responsibility Principle, SRP）

1. 简介：一个类只负责一个功能领域中的相应职责（避免混乱）
2. 定义：单一职责原则要求类应该只有一个设计目的

1.2 开闭原则（Open Closed Principle，OCP）

1. 简介：对扩展开放，对修改关闭（提高系统的扩展性、稳定性）
2. 定义：可扩展系统并提供新行为，通过添加抽象层实现，是其他原则的基础。对扩展开放对修改封闭

1. 系统设计

1.1 概念

1. 设计工程是指在整个软件开发过程中，通过对需求工程的结果进行分析和设计，制定出系统的整体设计方案，包括概要设计、详细设计、应用设计等多个部分。
2. 主要目的：为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。

1.2 设计方法

1. 结构化设计方法
2. 面向对象设计方法

对于后端开发来说，熟练掌握 Linux 的日志分析命令是基本功，整理了一些基于 tail、less、grep、sed、awk 的日志查询场景，帮助快速定位问题。

1. 软件需求

1.1 概念

1. 软件需求：指 用户对系统 在功能、行为、性能、设计约束等方面的 期望。

1.2 软件需求的层次

1. 业务需求：
   1. 整体全局视角，反映 企业 或 客户 对系统高层次的目标要求
   2. 通常来自 项目投资人、客户、市场营销部门 或 产品策划部门
   3. 通过业务需求可以确定 项目视图 和 范围。
2. 用户需求：
   1. 用户视角，描述用户的具体目标，或用户要求系统必须能完成的任务
   2. 通常采取 用户访谈 和 问卷调查 等方式，对用户使用的场景进行整理，从而建立用户需求。

1. 软件开发环境

1. 软件开发环境（Software Development Environment，SDE），应支持多种集成机制
2. 定义：是支持软件工程化开发和维护的一组软件工具和 环境集成机制
3. 要求：需要支持 平台、数据、界面、控制 和 过程集成，且支持小组工作方式，提供配置管理
4. 主要功能：
   1. 维护软件开发的一致性与完整性
   2. 实现配置管理及版本控制
   3. 支持数据的多种表示形式及自动转换
   4. 实现信息的自动检索与更新
   5. 提供项目控制和管理功能
   6. 支持开发方法学
5. 集成机制组成：
   1. 环境信息库：存储 与系统开发相关 的信息，是 SDE 的核心部分，支持多工具间的 信息交流与共享
   2. 过程控制与消息服务器：实现 过程集成和控制集成 的基础，通过控制流程、调度工具及传递消息来协调各个开发活动
   3. 环境用户界面：包括环境总界面以及各部件各工具的界面。具有一致的用户界面，可以发挥环境的优越性，提高工具的使用效率，减轻用户的学习负担