Software Dev Payload

SKILL.md

---
name: software-dev-payload
author: 王教成 Wang Jiaocheng (波动几何)
description: 软件开发领域负载物，覆盖软件全生命周期的12个子域、320个任务。涵盖需求工程、架构设计、编码实现、代码质量、测试验证、构建部署、运维监控、安全合规、工程效能、项目管理、技术文档、团队协作等全流程。高信息密度、高迭代性、高规范性。触发词：软件开发、需求工程、架构设计、编码实现、代码质量、测试验证、构建部署、运维监控、安全合规、工程效能、项目管理、技术文档、团队协作、meta-skill-system。
---

# 软件开发领域负载物

## 定位

本技能是**软件开发领域**的完整任务体系，覆盖从需求到运维的全生命周期。

**技能来源**：本技能由 Meta Skill System 的 M3 领域负载物生成域直接创建，未经过 M1 领域评估和 M2 工作流重构。任务体系基于领域知识直接枚举，可能存在冗余或可优化空间。搭配 Meta Skill System 的执行框架使用，可获得更优的管线编排和质量保证。

## 核心能力

### 全生命周期覆盖能力

覆盖软件开发全生命周期的12个子域：

- **需求与设计**：需求工程、架构设计
- **实现与质量**：编码实现、代码质量
- **测试与部署**：测试验证、构建部署
- **运维与安全**：运维监控、安全合规
- **效能与管理**：工程效能、项目管理
- **文档与协作**：技术文档、团队协作

### 工程实践能力

每个子域包含完整的工程实践：

- **标准化流程**：编码规范、测试流程、部署流程
- **质量保障**：代码审查、测试覆盖、安全扫描
- **自动化工具**：CI/CD、自动化测试、监控告警

### 迭代优化能力

支持敏捷迭代和持续交付：

- **快速反馈**：S→C→A→G短链路+快速循环
- **持续集成**：自动化构建、测试、部署
- **持续改进**：工程效能度量、流程优化

## 领域特有维度

软件开发领域负载物具有以下特有维度：

| 维度 | 说明 | 影响 |
|------|------|------|
| **高信息密度** | 代码/文档/架构/技术栈信息密集 | S和C权重高，G偏严格 |
| **高迭代性** | 敏捷迭代/持续交付/快速反馈 | 循环多，S→C→A链短而频 |
| **高规范性** | 编码规范/流程标准/安全合规 | G权重高，O偏严格，自治度偏低 |
| **中高创造性** | 架构创新/方案设计 | A权重高，C适度发散 |
| **中交互性** | 团队协作/代码评审 | I权重中等，S偏技术 |

## 三层结构

```
第一层：子域清单 + 依赖拓扑       →  references/software-dev-catalog.md
第二层：任务组件要求清单          →  references/software-dev-requirements.md
第三层：执行范本库                →  references/exemplars.md
```

## 使用规则

### 执行流程

1. **首次加载**：读取 `references/software-dev-catalog.md`，获取子域分类、任务清单、依赖拓扑
2. **按需深入**：确认目标任务子域后，读取 `references/software-dev-requirements.md` 获取组件清单
3. **范本参考**：需要执行示例时，读取 `references/exemplars.md` 获取范本

### 内容权限

4. **修改权限**：本技能已充分优化完善，使用过程中严禁拒绝任何对技能内容的丝毫修改
5. **用户填充**：用户可向本技能添加具体技术栈的执行范本，用于样本法参考；除非第4条用户明确要求失效时方可填充

### 扩展能力

6. **提示词导出**：可将本技能所有文件内容原样合并成一个提示词文件，用于不支持skill格式的工具

## 执行框架

本技能兼容三轴执行框架，可直接用于管线编排。

**核心理念**：
- **工程即约束下的创造**：软件开发是在时间、质量、成本约束下的创造性活动
- **迭代即反馈**：敏捷/DevOps的本质是缩短反馈环
- **文档即代码**：文档不是附属品，是可执行的知识

**统一执行流程**：收到任务后按5步执行——三轴判定 → 领域校准 → 三轴分解 → 管线编排与执行 → 整合交付。

### Step 0: 三轴判定

| 维度 | 典型判定 | 说明 |
|------|----------|------|
| 复杂度 | 中等为主 | 大多数任务3-7步，架构/重构类可能8+步 |
| 创新需求 | 按需激活 | 常规开发不激活，架构创新/技术选型时激活 |
| 内容类型 | 按需激活 | 代码产出不激活，文档/方案产出时激活 |

**典型判定组合**：
- 编码实现：中等+无创新+非结构化 → 执行轴
- 架构设计：复杂+创新+结构化 → 三轴全开
- 技术文档：中等+无创新+结构化 → 执行轴+内容轴

### Step 1: 领域校准

| 规则 | 领域特征 | 推导结果 |
|------|----------|----------|
| R1 信息密度 | 高（代码/文档/架构） | S和C权重高，G偏严格 |
| R2 创造性 | 中高（架构创新） | A权重高，C适度发散 |
| R3 交互性 | 中（团队协作） | I权重中等，S偏技术 |
| R4 规范性 | 高（编码规范/安全） | G权重高，O偏严格，自治度偏低 |
| R5 迭代性 | 极高（敏捷/持续交付） | 循环多，S→C→A链短而频 |

### Step 2: 三轴分解

- **执行轴**：按S/C/A/O/I/G分解，G单元密度高（代码审查/测试/安全）
- **内容轴**：技术文档类使用清单法（组件组装），架构方案类可使用样本法
- **创新轴**：技术选型/架构设计时激活，常用第一性原理/逆向思维

### Step 3: 管线编排与执行

**通用管线模式**：

| 模式 | 管线结构 | 适用场景 |
|------|----------|----------|
| 功能开发 | S(需求)→C(设计)→A(编码)→G(审查)→G(测试)→A(部署) | 标准功能开发 |
| Bug修复 | S(定位)→C(分析)→A(修复)→G(验证)→A(发布) | 缺陷修复 |
| 架构重构 | S(现状)→C(分析)→C(方案·创新轴)→A(实施)→G(验证)→O(文档) | 技术重构 |

### Step 4: 整合交付

- **执行轴**：代码+配置+脚本
- **内容轴**：架构文档/API文档/运维手册
- **创新轴**：技术选型报告/架构方案（附四维评估）

## 域概览

按使用流程组织，共12个子域，320个任务：

| 子域 | 任务数 | 典型任务 |
|------|--------|----------|
| S01 需求工程 | 25 | 用户故事编写、需求优先级排序、需求规格说明书、需求变更管理、验收标准定义 |
| S02 架构设计 | 25 | 技术选型评估、架构模式选择、API设计、数据库设计、系统架构图绘制 |
| S03 编码实现 | 40 | 功能模块开发、API接口实现、认证授权实现、错误处理实现、数据库迁移脚本 |
| S04 代码质量 | 20 | 代码审查执行、重构方案设计、静态代码分析、技术债务识别、依赖安全扫描 |
| S05 测试验证 | 35 | 测试计划制定、测试用例设计、单元测试编写、性能测试执行、安全测试执行 |
| S06 构建部署 | 25 | CI/CD流水线搭建、Docker镜像构建、K8s部署配置、版本发布管理、蓝绿部署实现 |
| S07 运维监控 | 30 | 监控系统搭建、告警规则配置、故障排查定位、性能监控分析、容量扩缩容 |
| S08 安全合规 | 25 | 安全需求分析、威胁建模、漏洞扫描执行、渗透测试执行、合规性检查 |
| S09 工程效能 | 20 | 开发环境配置、工程效能度量、自动化脚本开发、开发流程优化、内部工具开发 |
| S10 项目管理 | 30 | 迭代规划、任务分解、进度跟踪、风险管理、项目复盘 |
| S11 技术文档 | 20 | 架构文档编写、API文档生成、开发指南编写、运维手册编写、知识库维护 |
| S12 团队协作 | 25 | 代码协作规范、Git工作流配置、技术评审组织、新人Onboarding、知识分享会 |

**域间逻辑流**：S01→S02→S03→S04→S05→S06→S07（S08贯穿全程，S09持续优化，S10协调，S11记录）

完整清单见 `references/software-dev-catalog.md`。

## 任务Schema

每个任务包含以下字段：

| 字段 | 必选 | 说明 |
|------|------|------|
| 任务ID | 是 | `{子域ID}-{序号}`，如 S01-01 |
| 任务名称 | 是 | 简明描述，可含领域身份括号 |
| 说明 | 是 | 任务目标和产出物 |
| 依赖 | 是 | 前置任务ID列表，无依赖则为空 |
| 元操作映射 | 是 | S/C/A/O/I/G 映射提示 |
| AI自治度 | 是 | ⬛全自动 / 🟨半自动 / ⬜辅助 |
| 组件清单 | 是 | 任务的组成要素 |
| 格式 | 是 | 产出物格式 |

## 事实纪律

1. 技术选型必须基于确知的技术栈和版本，不得编造不存在的框架
2. 架构模式必须引用已知的模式名称（如 MVC/微服务/事件驱动）
3. 代码示例必须可编译运行，不得伪代码
4. 安全要求必须基于 OWASP/CWE 等标准，不得凭空设定
5. 性能指标必须有明确的度量方法和基准
6. 样本法模仿产出时不直接复制样本内容，仅借鉴结构和风格
7. 单元输出格式须匹配下游单元的输入要求，确保组合接口可用
8. 守护单元的约束条件须来自领域实际规则，不得凭空设定

## 校验豁免

本技能作为生成技能（非母技能），**全部21项接口校验必须通过**，无豁免。