技术方案编写技能

概述

输入：需求文档 或 用户描述
输出：Word格式技术方案（15章节）→ 自动转换并提供下载链接

输出版本

支持两种输出模式：

精简版包含：
1. 项目概述（背景、目标、范围）
2. 需求分析（功能需求、技术需求）
3. 总体架构设计（架构图、技术栈）
4. 技术选型方案
5. 功能模块设计（简化）
6. 部署架构设计
7. 实施方案（里程碑）
8. 风险分析与应对

使用方式：生成时指定版本，如"生成精简版技术方案"

执行流程

1. 解析需求 → 2. 生成15章节方案 → 3. 自动转Word → 4. 提供下载链接

重要提示

⚠️ 必须输出Word格式文件，不是Markdown！

生成Markdown后，必须转换为Word格式，按以下优先级尝试：

优先级1：pandoc命令（最快，格式规范）

pandoc 技术方案.md -o 技术方案.docx --reference-doc=references/政府文档模板.docx

优先级2：docx技能（系统预置，精确控制）
- 调用 skill_load("docx") 使用技能生成

优先级3：脚本转换（需要python-docx库）

python scripts/md_to_docx.py 技术方案.md

失败降级：以上方式都不可用时，输出Markdown文件并告知用户"当前环境不支持Word转换，请使用Markdown文件或手动转换"

最终返回Word文件路径供用户下载，格式：[技术方案_xxx.docx](computer://路径)

步骤1：解析需求

需求文档：用parse_file解析，提取项目名称、背景、功能列表、技术要求

用户描述：提取关键信息，不足时用占位符 [xxx]

步骤2：生成技术方案

⚠️ 内容格式原则：优先使用段落文字描述，减少表格使用。仅在以下场景使用表格：
- 对比类内容（如技术选型对比、方案对比）
- 清单类内容（如功能清单、接口清单）
- 配置清单（如服务器配置）

一、项目概述

1.1 项目背景
- 用段落描述业务现状和痛点，3-5条痛点，每条2-3句话
- 用段落描述建设必要性，3-4条，每条说明为什么必须建设

1.2 项目目标
- 总体目标：一句话描述
- 具体目标：用段落分条描述，每条包含量化指标
- 阶段性目标：按阶段用段落描述，说明时间节点和目标内容

1.3 项目范围
- 建设范围：用段落描述包含的功能、数据、接口建设内容
- 边界界定：用段落明确说明包含和不包含的范围

1.4 建设原则
- 4-6条原则，每条用段落说明原则内容和实施方式

二、需求分析

2.1 业务需求分析
- 核心业务流程：用ASCII流程图展示
- 业务场景：用段落描述3-5个核心场景，每个场景说明当前痛点和预期效果

2.2 功能需求分析
- 功能需求清单：使用表格（功能点、描述、优先级）
- 其他用段落描述功能分类和优先级说明

2.3 技术需求分析
- 性能需求：用段落描述各项性能指标要求
- 兼容性需求：用段落描述浏览器、移动端、分辨率等要求
- 部署需求：用段落描述部署方式、安全要求

2.4 数据需求分析
- 数据来源：用段落描述各类数据来源
- 数据处理需求：用段落描述采集、存储、分析需求
- 数据安全需求：用段落描述加密、访问控制、备份要求

2.5 接口需求分析
- 系统集成接口：使用表格（系统名称、对接内容）
- 对外服务接口：用段落描述接口服务对象和方式

三、总体架构设计

3.1 设计原则
- 4条原则，每条用段落说明

3.2 架构总览
- 逻辑架构图：使用ASCII图
- 架构层次说明：用段落描述各层职责和组成

3.3 部署架构
- 部署拓扑图：使用ASCII图
- 服务器配置清单：使用表格（角色、数量、配置、用途）

3.4 技术架构
- 技术栈选型：用段落描述各层技术选型和理由

架构图增强：除ASCII图外，可选生成可视化图表代码：

方式一：Mermaid代码（适合流程图、时序图）

graph TB
    subgraph 表现层
        A1[Web前端]
        A2[移动端]
    end
    subgraph 业务层
        B1[业务模块1]
        B2[业务模块2]
    end
    subgraph 数据层
        C1[(数据库)]
        C2[(缓存)]
    end
    A1 --> B1
    A2 --> B1
    B1 --> C1
    B1 --> C2

方式二：Draw.io XML（可选增强，需要技能支持）

用户要求生成可编辑架构图时：
1. 检查是否有 drawio-generator 技能
2. 有：调用 skill_load("drawio-generator") 生成 .drawio 文件
3. 没有：仅提供 ASCII图 + Mermaid代码，告知用户可自行用 Mermaid 在线渲染

图表生成优先级：
1. 默认：ASCII图 + Mermaid代码（无需额外技能，兼容所有环境）
2. 用户要求专业图表：尝试调用 drawio-generator，无技能则降级为 Mermaid
3. Word中：保留ASCII图（可读），Mermaid代码块供后续渲染

架构图格式：

┌─────────────────────────────────────────────────────────────┐
│                        表现层                                │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                  │
│  │ Web前端  │  │ 移动端   │  │ API接口  │                  │
│  └──────────┘  └──────────┘  └──────────┘                  │
├─────────────────────────────────────────────────────────────┤
│                        业务层                                │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                  │
│  │ 业务模块1│  │ 业务模块2│  │ 业务模块3│                  │
│  └──────────┘  └──────────┘  └──────────┘                  │
└─────────────────────────────────────────────────────────────┘

四、技术选型方案

4.1 AI技术选型
- AI应用场景：用段落描述各场景的技术方案
- 模型训练/部署方案：用段落说明

4.2 开发技术选型
- 前端技术：用段落描述技术栈及理由
- 后端技术：用段落描述技术栈及理由

4.3 数据存储技术选型
- 各类数据存储方案：用段落描述选型及理由

技术选型参考：
- 政府项目：Spring Boot + Vue.js + MySQL
- AI项目：Python FastAPI + Vue.js + MySQL + 向量数据库
- 互联网项目：Go/Node.js + React + MySQL + Redis

行业最佳实践参考（使用表格对比）：

五、功能模块设计

每个模块包含：
- 模块概述：用段落描述模块功能定位
- 核心功能：用段落分条描述各功能点
- 数据流向：使用ASCII流程图

模块优先级：P0为核心模块，P1为重要模块

六、数据架构设计

6.1 数据架构总览
- 数据架构图：使用ASCII图
- 数据流向说明：用段落描述

6.2 数据库设计
- 数据库选型：用段落说明选型理由
- 核心数据表：使用表格（表名、用途、主要字段）
| 6.3 数据治理方案 | 数据质量保障表格 + 数据安全治理表格 |

七、安全架构设计

7.1 安全架构总览
- 安全架构图：使用ASCII图
- 安全层次说明：用段落描述各层安全措施

7.2 安全措施详述
- 网络安全：用段落描述防火墙、入侵检测等措施
- 应用安全：用段落描述认证、授权、加密等措施
- 数据安全：用段落描述加密、备份、脱敏等措施
- 安全审计：用段落描述日志、审计等措施

八、部署架构设计

8.1 部署方案
- 部署模式：用段落描述私有化/云部署方案
- 部署架构：使用ASCII拓扑图

8.2 服务器配置
- 服务器配置清单：使用表格（角色、数量、配置、用途）

8.3 高可用方案
- 应用高可用：用段落描述负载均衡、故障切换
- 数据库高可用：用段落描述主从复制、读写分离
- 存储高可用：用段落描述集群、冗余

九、接口设计

9.1 接口规范
- 设计原则：用段落描述RESTful规范、版本管理等
- 统一响应格式：用代码示例展示
- 错误码规范：使用表格（错误码、说明）

9.2 核心接口清单
- 按模块分组：使用表格（接口名称、请求方式、路径、说明）

十、性能保障方案

10.1 性能指标
- 性能指标：用段落描述各项指标要求

10.2 性能优化方案
- 前端优化：用段落描述压缩、缓存、懒加载等
- 后端优化：用段落描述数据库优化、缓存策略等
- AI模型优化：用段落描述模型压缩、边缘部署等

10.3 压力测试方案
- 测试场景：用段落描述测试场景设计
- 测试工具：用段落介绍测试工具

十一、实施方案

11.1 项目组织架构
- 组织架构图：使用ASCII图
- 职责分工：用段落描述各角色职责

11.2 实施计划
- 总体进度：用段落描述各阶段时间安排
- 关键里程碑：使用表格（阶段、时间、目标、交付物）

11.3 质量保障
- 代码质量：用段落描述代码规范、评审机制
- 测试质量：用段落描述测试策略、验收标准

十二、运维保障方案

12.1 运维体系
- 运维组织：用段落描述运维团队组成
- 运维职责：用段落描述各岗位职责

12.2 监控方案
- 监控体系：用段落描述监控架构
- 监控指标：使用表格（监控对象、指标、告警阈值）

12.3 备份方案
- 备份策略：使用表格（备份对象、方式、频率、保留时间）
- 恢复演练：用段落描述演练机制

12.4 应急预案
- 应急响应流程：用段落或流程图描述
- 故障分级：使用表格（级别、响应时间、处理时限）

十三、项目预算

13.1 预算明细
- 使用表格（费用类别、项目、金额、说明）
- 金额用占位符 [xxx万元]，不编造具体数字

13.2 预算说明
- 用段落说明预算构成、估算依据

成本估算参考区间（供参考，实际以市场价为准）：

说明：以上为市场参考价，实际以采购/招标为准

十四、风险分析与应对

14.1 风险识别
- 用段落描述各类风险及其影响

14.2 风险应对措施
- 使用表格（风险类别、应对措施）

十五、附录

术语定义
- 使用表格（术语、定义）

系统功能清单
- 使用表格（模块、功能点、功能描述、优先级）

参考资料
- 用段落列出相关标准文档

注意：功能清单要覆盖所有模块，与"功能模块设计"章节对应，优先级与"需求分析"章节一致。

步骤3：转换为Word（政府文档格式）

必须输出符合政府文档规范的Word文件！

格式规范

其他要求：
- 页边距：上下2.54cm，左右3.17cm
- 行距：正文1.5倍行距
- 页码：底部居中

转换方式（二选一）

方式一：pandoc + 模板（推荐）

pandoc 技术方案.md -o 技术方案.docx --reference-doc=references/政府文档模板.docx

方式二：docx技能（精确控制）

// 标题样式配置
styles: {
  paragraphStyles: [
    { id: "Title", name: "Title", 
      run: { size: 44, bold: true, font: "黑体" },
      paragraph: { alignment: AlignmentType.CENTER } },
    { id: "Heading1", name: "Heading 1",
      run: { size: 32, bold: true, font: "黑体" } },
    { id: "Heading2", name: "Heading 2",
      run: { size: 28, bold: true, font: "黑体" } },
    { id: "Heading3", name: "Heading 3",
      run: { size: 24, bold: true, font: "黑体" } }
  ]
}
// 正文：font: "宋体", size: 24, 首行缩进480 twips（2字符）

格式检查

转换后检查：
- [ ] 标题字体是否为黑体
- [ ] 正文字体是否为宋体
- [ ] 字号是否符合规范
- [ ] 表格是否有边框

步骤4：提供下载

返回Word文件路径：技术方案/[项目名称]/技术方案_[项目名称]_[日期].docx

质量检查清单

生成后检查：
- [ ] 15个章节是否完整
- [ ] 每个章节是否有表格内容（不是空标题）
- [ ] 架构图是否清晰（ASCII格式）
- [ ] 预算金额是否使用占位符
- [ ] 技术选型是否符合项目类型

参考文件

• references/模板.md：完整版章节框架（15章节）
• references/模板-精简版.md：精简版章节框架（8章节）
• references/示例-南岸AI值班管理系统.md：完整示例（参考风格和深度）
• references/政府文档模板.docx：Word格式模板（pandoc引用）