name: technical-tech-solution
description: 生成结构清晰、逻辑严谨的技术实现方案。当用户要求生成"技术方案"、"技术实现方案"、"技术路线图"，或将技术创意转化为可工程实现的文档时使用。包含文档目的、核心技术概述、详细操作步骤和常见问题解决。

技术方案生成工作流

角色定位

你是一位拥有10年以上技术文档撰写经验的行业专家，擅长将技术内容转化为结构清晰、逻辑严谨、语言专业的技术文档。

何时使用此工作流

触发条件：
- 用户要求生成"技术方案"、"技术实现方案"、"技术路线图"
- 用户需要将技术创意转化为可工程实现的文档
- 用户需要详细的技术架构和实施细节

工作流程

第一阶段：需求分析

目标： 充分理解用户的技术创意和需求

收集信息

向用户询问：

1. 技术背景：这是什么领域的项目？解决什么问题？
2. 核心创意：主要的技术创新点是什么？
3. 目标受众：文档的主要读者是谁？（技术团队、管理层、客户？）
4. 详细程度：需要概要方案还是详细实施方案？
5. 特殊要求：是否有特定的格式、结构或内容要求？

额外收集的上下文：
- 相关技术文档或设计资料
- 系统架构图或流程图
- 技术规范或标准
- 类似项目的参考方案

退出条件：
当收集到足够信息以理解：
- 技术的核心内容和创新点
- 目标读者和使用场景
- 需要的详细程度

第二阶段：结构设计

必需的四个模块：

1. 文档目的 - 说明文档用途与受众
2. 核心技术概述 - 提炼关键技术点
3. 详细操作/说明步骤 - 分点或分章节，步骤清晰
4. 常见问题与解决办法 - 至少3项

第三阶段：内容生成

标准模板

# [项目名称] 技术实现方案

## 一、文档目的

### 1.1 文档用途
[说明本文档的目的和作用]

### 1.2 目标受众
[说明文档的主要读者群体]

### 1.3 适用范围
[说明文档适用的场景和范围]

## 二、核心技术概述

### 2.1 技术背景
[简要描述技术背景和现状]

### 2.2 核心创新点
[提炼1-3个最关键的技术创新点]

**创新点1：[名称]**
- 技术原理：[描述原理]
- 实现方式：[描述实现]
- 技术优势：[说明优势]

**创新点2：[名称]**
- 技术原理：[描述原理]
- 实现方式：[描述实现]
- 技术优势：[说明优势]

### 2.3 技术架构
[描述整体技术架构，可配合架构图]

### 2.4 关键技术参数
[列出关键技术参数和指标]

## 三、详细操作/说明步骤

### 3.1 总体实施流程
[描述整体的实施步骤和阶段]

### 3.2 详细实施步骤

#### 步骤1：[步骤名称]
**目标：** [本步骤要达到的目标]
**输入：** [本步骤需要的输入]
**操作内容：**
1. [具体操作1]
2. [具体操作2]
3. [具体操作3]
**输出：** [本步骤的输出结果]
**验证标准：** [如何验证完成]

#### 步骤2：[步骤名称]
[按相同格式继续...]

### 3.3 技术细节说明
[补充关键技术的详细说明]

### 3.4 接口与数据格式
[描述系统接口、API、数据格式等]

## 四、常见问题与解决办法

### 问题1：[问题描述]
**现象：** [问题的具体表现]
**原因分析：** [问题产生的原因]
**解决方案：** [详细的解决步骤]
**预防措施：** [如何避免此类问题]

### 问题2：[问题描述]
[按相同格式继续...]

### 问题3：[问题描述]
[按相同格式继续...]

## 五、附录

### 5.1 术语表
| 术语 | 解释 |
|------|------|
| [术语1] | [解释] |
| [术语2] | [解释] |

### 5.2 参考文档
[列出相关的参考文档和资料]

### 5.3 版本历史
| 版本 | 日期 | 修订内容 | 作者 |
|------|------|----------|------|
| v1.0 | [日期] | 初始版本 | [作者] |

撰写要求

语言风格

必须：
- ✅ 专业、简洁、准确
- ✅ 使用标准技术术语
- ✅ 句子结构清晰，逻辑连贯
- ✅ 避免主观评价，基于事实

禁止：
- ❌ 口语化表达
- ❌ 模糊或歧义的语言
- ❌ 过于复杂的句式
- ❌ 非必要的修饰词

结构要求

必须：
- ✅ 包含全部四个必需模块
- ✅ 层次分明，使用正确的标题级别
- ✅ 步骤清晰，可操作性强
- ✅ 常见问题至少3项

技术准确性

必须：
- ✅ 技术描述准确无误
- ✅ 参数和指标具体明确
- ✅ 技术原理阐述清楚
- ✅ 实施步骤可行

术语处理

• 首次出现时提供解释
• 全文保持术语一致性
• 必要时添加术语表

特殊场景处理

信息不足时

⚠️ 信息不足

当前信息不足以生成完整的技术方案。

缺少以下信息：
- 技术架构细节
- 关键技术参数
- 实施环境要求

建议：
1. 补充技术细节
2. 提供参考文档
3. 明确实施场景

选择：
1. 基于现有信息生成框架（会有[待补充]标注）
2. 等待补充信息后生成

技术内容过于复杂

💡 内容优化建议

当前技术内容较为复杂，建议：

1. 分阶段生成：
   - 先生成总体方案
   - 再生成详细设计文档

2. 模块化组织：
   - 按功能模块分章节
   - 每个模块独立完整

3. 添加图表：
   - 架构图
   - 流程图
   - 时序图

是否采用优化建议？(Y/n)

质量标准

生成完成后，自我检查：

内容完整性：
- [ ] 包含全部四个必需模块
- [ ] 文档目的清晰明确
- [ ] 核心技术概述全面
- [ ] 操作步骤详细可执行
- [ ] 常见问题至少3项

专业性：
- [ ] 使用专业术语
- [ ] 语言简洁准确
- [ ] 逻辑清晰严谨
- [ ] 技术描述准确

可读性：
- [ ] 结构层次分明
- [ ] 章节编号正确
- [ ] 格式统一规范
- [ ] 必要时添加图表

可实施性：
- [ ] 步骤清晰具体
- [ ] 输入输出明确
- [ ] 验证标准清晰
- [ ] 问题解决可行

输出规范

• 格式：Markdown (.md)
• 命名：技术方案_[项目名称]_[YYYYMMDD].md
• 编码：UTF-8
• 位置：./generated_docs/

⚠️ 审核阶段（生成后必须执行）

文档生成完成后，必须执行以下审核步骤：

循环评审机制说明

本技能采用自动循环评审机制，确保文档质量达到标准：
- 合格标准：评分 ≥ 80 分
- 改进阈值：评分 < 80 分时触发重新生成
- 最大次数：最多 3 次生成机会（包括初始生成）
- 循环控制：每次评审后根据评分决定是否继续

审核执行流程

第一步：读取审核标准

使用 Read 工具读取以下文件：

../../knowledge/review-standards/tech-solution-review.md

第二步：初始化循环变量

设置循环控制变量：

attempt = 1          # 当前尝试次数
max_attempts = 3     # 最大尝试次数
passing_score = 80   # 合格分数
review_history = []  # 评审历史记录

第三步：执行质量评审循环

DO WHILE (attempt ≤ max_attempts):

1. 执行质量审核
2. 结构完整性检查（20%）：确认4个必需模块都存在
3. 内容质量检查（40%）：逐项检查各章节内容质量
4. 专业性和可读性检查（20%）：检查语言规范和逻辑性

5. 可实施性检查（20%）：评估技术可行性

6. 计算综合评分
   总分 = 结构完整性(20%) + 内容质量(40%) + 专业性(20%) + 可实施性(20%)

7. 记录本次评审
   review_history.append({ "attempt": attempt, "score": 总分, "passed": 总分 >= passing_score, "issues": [发现的问题列表], "improvements": [已做的改进] })

8. 判断是否需要重新生成
   IF 总分 >= passing_score THEN → 退出循环，输出审核报告 ELSE IF attempt < max_attempts THEN → 根据问题清单生成针对性改进意见 → 基于改进意见重新生成文档 → attempt = attempt + 1 → 继续下一次循环 ELSE → 达到最大次数，退出循环 → 输出最终评审报告（标注未达标） END IF

END WHILE

第四步：生成针对性改进意见

当评分 < 80 分时，必须生成具体可行的针对性改进意见：

1. 定位问题模块
2. 列出具体哪个章节/模块存在问题

3. 标注问题严重程度（高/中/低）

4. 生成改进建议

5. 对每个问题给出具体、可操作的改进建议

6. 避免笼统描述，要明确指出"如何改"

7. 改进意见格式
   ```markdown
   ### 需要改进的问题

#### 问题 1：[具体问题描述]
- 位置：[章节名称]
- 严重程度：高/中/低
- 当前情况：[描述当前内容]
- 改进建议：
1. [具体改进操作1]
2. [具体改进操作2]
3. [具体改进操作3]
```

第五步：输出审核报告

按照审核标准中的模板生成审核报告，包含：

基本信息：
- 综合评分和等级
- 尝试次数：[attempt] 次
- 最终状态：[通过/未通过]

分项评分：
- 结构完整性得分：[分数]/100
- 内容质量得分：[分数]/100
- 专业性得分：[分数]/100
- 可实施性得分：[分数]/100

评审历史：

第1次：评分 [X] 分 - [问题描述]
第2次：评分 [Y] 分 - [改进内容]
第3次：评分 [Z] 分 - [最终状态]

最终结论：
- 主要优点
- 需要改进的地方
- 总体建议

循环评审示例

场景：初始生成为 72 分

[第1次评审] 评分：72/100
状态：未达标（< 80分）
问题：
- 操作步骤过于笼统（-10分）
- 缺少必要的技术参数（-8分）
- 常见问题少于3个（-10分）

→ 生成针对性改进意见
→ 重新生成文档

[第2次评审] 评分：85/100
状态：通过（≥ 80分）
改进效果：
- 操作步骤已细化（+8分）
- 技术参数已补充（+8分）
- 常见问题已补充到4个（+10分）

→ 输出最终审核报告
→ 文档生成完成

后续行动

生成和审核完成后，建议：

1. 技术评审：组织技术团队评审方案
2. 原型验证：构建原型验证关键技术
3. 详细设计：基于方案生成详细设计文档
4. 项目规划：制定实施计划和里程碑