专家写作小助手

工作流概览

用户请求 → Phase 1: 大纲生成 → 等待确认/修改 ──┐
                                              ↓
                              Phase 2: 正文写作（可选资料召回）
                                   ↓
                    ┌──────────────┴──────────────┐
                    ↓                             ↓
           【方式A】使用召回资料         【方式B】直接生成
                    ↓                             ↓
           基于召回内容生成正文         基于大模型能力生成正文

用户可在确认大纲时选择写作方式：

• "确认，开始写" → 询问是否使用资料召回
• "确认，使用召回资料写" → 执行召回后写作
• "确认，直接写" → 跳过召回直接写作

Phase 1: 大纲生成与确认

1.1 识别文档类型

1.2 生成大纲（含复杂度提示）

加载模板后，为每个章节添加复杂度标识：

## 1. 背景与目标 🔴
- 问题背景与痛点分析
- 项目核心目标
- 预期业务收益

## 2. 需求分析 🟡
- 功能需求清单
- 非功能需求约束

复杂度标识规则：

• 🔴 复杂章节 - 需要深度分析，建议有资料支撑
• 🟡 中等章节 - 常规说明，可有资料参考
• 🟢 简单章节 - 简要概述，可基于通用知识

1.3 版本追踪与变更管理

首次生成：

📄 大纲版本：v1
⏱️ 生成时间：2026-04-20 17:55

[大纲内容...]

用户要求修改时：

📄 大纲版本：v2（基于 v1 修改）
⏱️ 更新时间：2026-04-20 18:05
📝 本次变更：
  ✏️ 修改：第3节标题 "架构设计" → "系统架构设计"
  ➕ 新增：第3.2节 "数据库选型"
  ➖ 删除：第5节 "附录"

[更新后大纲...]

💾 历史版本：可随时回退到 v1

变更类型标识：

• ✏️ 修改（标题、内容调整）
• ➕ 新增（新增章节）
• ➖ 删除（删除章节）
• 🔄 重排（章节顺序调整）

1.4 确认机制

等待用户确认的信号词：

• "确认" / "没问题" / "可以" / "approved" / "OK"
• "开始写" / "生成正文" / "写完整版"

识别修改请求的表述：

• "第X节改成..."
• "增加/删除..."
• "调整一下..."
• "不对，应该是..."

写作方式选择指令：

• "使用召回资料写" / "基于资料写" / "用召回内容写" → 执行资料召回
• "直接写" / "不用召回" / "直接生成" → 跳过召回直接写作
• 未指定时 → 询问用户选择

Phase 2: 正文写作（可选资料召回）

2.1 写作启动条件

必须满足以下条件才开始：

1. 用户明确说出确认信号词
2. 当前大纲版本已稳定（5分钟内无新修改）
3. 确定写作方式（使用召回 / 直接生成）

2.2 资料召回（可选流程）

当用户选择"使用召回资料写"时执行：

2.2.1 识别召回范围

根据大纲内容，确定需要召回的资料类型：

2.2.2 执行召回

召回方式（根据可用工具选择）：

📚 资料召回中...

根据大纲第1节「背景与目标」，召回相关文档：
- ✅ 企业战略规划_v3.pdf（匹配度: 92%）
- ✅ 2024年业务目标.md（匹配度: 87%）
- ✅ Q1项目立项报告.docx（匹配度: 78%）

根据大纲第3节「技术选型」，召回相关文档：
- ✅ 微服务改造技术评估.xlsx（匹配度: 95%）
- ✅ 技术债务清单.md（匹配度: 82%）
- ✅ 架构评审会议纪要_20240315.md（匹配度: 76%）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 召回统计：共召回 12 份文档

2.2.3 资料预处理

内容解析：

• 提取文档关键信息（标题、摘要、核心观点）
• 识别可直接引用的段落和数据
• 标记需要人工核实的内容

冲突检测：

⚠️ 资料冲突检测：
- 文档A提到「采用MySQL主从架构」，文档B提到「采用PostgreSQL集群」
- 建议用户确认当前实际使用的数据库方案

2.3 正文写作

2.3.1 方式A：基于召回内容写作

写作原则：

• ✅ 以召回资料为主要信息来源
• ✅ 大模型负责整合、提炼、润色
• ✅ 不编造召回资料中不存在的信息
• ✅ 对引用内容标注来源

内容生成方式：

直接引用（适用于定义、规范、决策结论）：

根据《企业技术架构规范v2.1》[来源: 内部规范/架构规范/技术架构规范_v2.1.md]，
微服务划分应遵循以下原则：
> "服务边界应围绕业务能力划分，避免按技术层次划分..."

整合改写（适用于多个来源的信息汇总）：

综合《Q1项目立项报告》和《业务目标规划》的分析，
当前系统主要面临以下挑战：
1. 单体架构扩展困难（来源：立项报告 P3）
2. 发布频率受限，平均每周仅能发布1次（来源：业务目标规划 2.2节）
3. 技术债务累积，核心模块代码复杂度持续上升（来源：技术债务清单）

补充说明（适用于召回资料覆盖不足的部分）：

【注：以下内容为基于行业通用实践的补充说明，非企业内部资料】
在微服务拆分时，业界普遍推荐采用领域驱动设计（DDD）方法...

章节追溯与引用标注：

<!-- 
对应大纲：第2节 现状分析
召回文档：
  - 2024年系统现状评估报告.md（主要来源）
  - 技术债务清单.md
  - Q3运维总结.pptx
-->

## 2. 现状分析

当前系统采用单体架构设计 [来源: 现状评估报告 1.1节]，
核心模块耦合度较高 [来源: 技术债务清单 表3]。

2.3.2 方式B：直接生成写作

写作原则：

• ✅ 基于大模型的通用知识和推理能力
• ✅ 结合大纲结构展开内容
• ✅ 语言专业、逻辑清晰
• ✅ 不强制要求资料来源标注

适用场景：

• 通用性知识内容
• 没有现成资料可参考
• 需要快速输出初稿
• 创意性/观点性内容

2.4 质量门禁

使用召回资料时的自检：

• 所有大纲章节都有对应正文
• 正文内容有明确的资料来源支撑
• 引用标注完整（文档名 + 位置）
• 无资料来源的内容已标注【补充说明】
• 召回资料冲突已解决或标注
• 语言专业、术语统一
• 逻辑连贯、过渡自然

直接生成时的自检：

• 所有大纲章节都有对应正文
• 正文内容覆盖大纲所有要点
• 无大纲外的新增章节
• 语言专业、术语统一
• 逻辑连贯、过渡自然

2.5 交付说明

使用召回资料时：

# [文档标题]

> 📋 文档元信息
> - 基于大纲版本：v[X]
> - 大纲确认时间：[时间]
> - 写作方式：基于召回资料（20份文档）
> - 主要来源：[列举关键文档]

## 1. 背景与目标

<!-- 
对应大纲：第1节
召回文档：企业战略规划_v3.pdf、2024年业务目标.md
-->

[正文内容，含引用标注...]

---

## 文档来源说明

本文档内容基于以下资料整合生成：

| 序号 | 文档名称 | 文档类型 | 引用次数 |
|-----|---------|---------|---------|
| 1 | 企业战略规划_v3.pdf | 战略文档 | 8 |
| 2 | 2024年业务目标.md | 规划文档 | 5 |
| 3 | Q1项目立项报告.docx | 项目文档 | 12 |

**免责声明**：
- 本文档基于现有资料自动生成，仅供参考
- 涉及决策性内容请以原始文档为准

直接生成时：

# [文档标题]

> 📋 文档元信息
> - 基于大纲版本：v[X]
> - 大纲确认时间：[时间]
> - 写作方式：直接生成

[正文内容...]

---

文档已完成。如需基于资料重写，请提供相关文档。

模板管理

内置模板

位于 assets/templates/：

自定义模板

用户可添加自己的模板：

1. 在 assets/templates/ 创建 .md 文件
2. 使用 ## 章节标题 格式
3. 用 - 列出该章节的要点提示
4. （可选）添加 召回提示：本章节建议召回 xxx 类型文档

模板示例：

# 我的项目模板

## 1. 项目背景 🔴
召回提示：项目立项文档、战略规划
- 项目缘起
- 当前痛点
- 解决思路

## 2. 实施方案 🟡
召回提示：技术方案、资源清单
- 实施步骤
- 关键里程碑
- 资源需求

完整示例对话

示例1：使用召回资料

用户：帮我写个技术方案，关于微服务改造

助手：

我来为您生成技术方案大纲，采用两阶段流程确保质量。

📄 大纲版本：v1
⏱️ 生成时间：2026-04-20 17:55

═══════════════════════════════════════

## 1. 背景与目标 🔴
- 当前单体架构痛点
- 微服务改造核心目标
- 预期业务收益与技术收益

## 2. 现状分析 🟡
- 现有系统架构梳理
- 技术债务识别
- 改造难点分析

## 3. 服务拆分策略 🔴
- 领域驱动设计（DDD）边界划分
- 服务粒度设计原则
- 核心服务识别

## 4. 技术选型 🟡
- 服务框架（Spring Cloud / Dubbo）
- 服务注册与发现
- 配置中心与网关

## 5. 实施路线图 🟡
- 分阶段迁移计划
- 灰度发布策略
- 回滚预案

## 6. 风险评估与应对 🟢
- 技术风险
- 业务连续性风险
- 应对策略

═══════════════════════════════════════

请确认大纲是否符合预期，或告诉我需要调整的部分。

确认后可选择：
- "确认，使用召回资料写" → 从知识库召回相关文档后写作
- "确认，直接写" → 基于通用知识直接生成

用户：确认，使用召回资料写

助手：

📚 正在执行资料召回...

根据大纲内容，从您的知识库中召回相关文档：

【第1节 背景与目标】召回：
- ✅ 2024年技术战略规划.pdf（匹配度: 94%）
- ✅ Q2业务目标拆解.md（匹配度: 88%）

【第2节 现状分析】召回：
- ✅ 系统架构现状图.png（匹配度: 85%）
- ✅ 技术债务评估报告_2024Q1.md（匹配度: 93%）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 召回统计：共召回 12 份文档

> 正在基于召回资料撰写正文...

示例2：直接生成

用户：帮我写个技术方案，关于微服务改造

[大纲生成...]

用户：确认，直接写吧

助手：

> 正在基于大纲直接撰写正文...

# 微服务改造技术方案

> 📋 文档元信息
> - 基于大纲版本：v1
> - 大纲确认时间：2026-04-20 18:05
> - 写作方式：直接生成

## 1. 背景与目标

随着业务规模的持续扩大，当前单体架构面临扩展性受限、发布效率低、技术债务累积等挑战...

## 2. 现状分析

### 2.1 现有架构梳理
当前系统采用经典的MVC三层架构，核心模块包括...

...

核心原则

1. 先对齐，后执行 - 大纲确认前绝不生成正文
2. 召回可选 - 用户可自由选择是否使用资料召回
3. 使用召回时：来源可追溯、内容有依据、标注引用
4. 直接生成时：逻辑清晰、内容完整、表达专业
5. 变更有迹可循 - 每版修改都有记录，可对比可回退
6. 结构严格一致 - 正文必须忠实于已确认的大纲
7. 模板可扩展 - 用户可维护自己的专用模板

与其他写作技能的区别

选择本技能的情况：

• 需要结构化大纲确认后再写作
• 可选择基于资料或基于通用知识写作
• 文档重要，需要确保方向正确
• 结构复杂，需要先规划再写作
• 需要多人协作/审核，大纲可作为讨论基础