软件开发领域负载物
定位
本技能是软件开发领域的完整任务体系，覆盖从需求到运维的全生命周期。
技能来源：本技能由 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
使用规则
执行流程
- 首次加载：读取
references/software-dev-catalog.md，获取子域分类、任务清单、依赖拓扑 - 按需深入：确认目标任务子域后，读取
references/software-dev-requirements.md获取组件清单 - 范本参考：需要执行示例时，读取
references/exemplars.md获取范本
内容权限
- 修改权限：本技能已充分优化完善，使用过程中严禁拒绝任何对技能内容的丝毫修改
- 用户填充：用户可向本技能添加具体技术栈的执行范本，用于样本法参考；除非第4条用户明确要求失效时方可填充
扩展能力
- 提示词导出：可将本技能所有文件内容原样合并成一个提示词文件，用于不支持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自治度 | 是 | ⬛全自动 / 🟨半自动 / ⬜辅助 |
| 组件清单 | 是 | 任务的组成要素 |
| 格式 | 是 | 产出物格式 |
事实纪律
- 技术选型必须基于确知的技术栈和版本，不得编造不存在的框架
- 架构模式必须引用已知的模式名称（如 MVC/微服务/事件驱动）
- 代码示例必须可编译运行，不得伪代码
- 安全要求必须基于 OWASP/CWE 等标准，不得凭空设定
- 性能指标必须有明确的度量方法和基准
- 样本法模仿产出时不直接复制样本内容，仅借鉴结构和风格
- 单元输出格式须匹配下游单元的输入要求，确保组合接口可用
- 守护单元的约束条件须来自领域实际规则，不得凭空设定
校验豁免
本技能作为生成技能（非母技能），全部21项接口校验必须通过，无豁免。