iDWong 应用系统类项目可行性研究报告生成器
Agent 协作架构
feasibility-report skill（主流程：调度 + 文件写入）
├── feasibility-analyzer agent（分析师）
│ 职责：读取 SRS/设计方案/已有可研，输出结构化项目信息摘要
│ 输出：项目背景、建设目标、功能清单、技术架构、缺失信息清单
│
├── feasibility-writer agent（撰写者）
│ 职责：摘要 + 模板规范 → 符合可研报告语言的章节内容
│ 约束：只写摘要中有的内容，缺失数据填"待定"
│
└── feasibility-reviewer agent（审查者）
职责：四维度审查（结构完整性/数据一致性/语言规范/可研要求）
→ 有问题 → 反馈给 writer 修正 → 重新审查（最多2次）
→ 全部通过 → 主流程写入文件
多章节串行：每个章节走 writer → reviewer 流程，审查通过后写入文件，再生成下一章节。
工作模式
| 模式 | 触发场景 | 入口 |
|---|---|---|
| 完整生成模式 | 从零生成完整可研报告 | → Step A |
| 章节补充模式 | 补充或修改某个章节 | → Step B |
| 审查修复模式 | 审查已有报告，找出问题并修复 | → Step C |
Step A：完整生成模式
A1：扫描项目上下文
先主动扫描项目，找到已有文档再开始工作，不要直接问用户。
按以下优先级扫描：
| 优先级 | 文件类型 | 查找方式 |
|---|---|---|
| 最高 | SRS需求规格说明书 | Glob("**/*需求*说明书*.md") |
| 高 | 设计方案 | Glob("**/*设计*方案*.md") Glob("prd/planning/**/*v1*.md") Glob("docs/**/*v1*.md")（旧根） |
| 中 | 可研报告（已有版本） | Glob("**/*可行性*研究*.md") Glob("**/*可研*.md") |
| 低 | 路由/代码 | src/router/, src/views/, src/api/ |
找到文档后：
- SRS需求说明书：提取项目背景、建设目标、功能模块清单、业务角色、非功能需求
- 设计方案：提取项目概述、功能范围、核心模块设计、数据结构
- 已有可研报告：识别为"局部完善模式"或"审查修复模式"，进入对应 Step
扫描完成后告知用户找到了哪些文档，并说明将从中提取哪些信息用于生成可研报告。
A2：收集补充信息
基于扫描到的文档，识别缺失的信息，只询问文档中没有的内容：
从文档中可以提取（不需要询问）：
- 项目背景、建设目标、功能模块（来自 SRS 或设计方案）
- 业务角色和权限（来自 SRS）
- 技术架构（来自设计方案或 SRS 技术方案章节）
通常需要补充询问的信息：
- 项目类型：自主研发类 / 提升推广类 / 引进实施类
- 编制单位、编制时间
- 投资估算（金额、费用分类）
- 项目周期和里程碑计划
- 实施范围（总部/企业）
- 是否有现有系统（提升推广类必问）
- 主流产品分析情况（引进实施类必问）
每次只问一个问题，优先给出选项供用户选择。
A3：调用 feasibility-analyzer 分析项目文档
使用 Agent 工具，subagent_type: "feasibility-analyzer"，传入：
PROJECT_PATH: {项目根目录绝对路径}
FEATURE_NAME: {项目名称，如有}
SOURCE_DOCS: {步骤 A1 找到的文档路径列表}
MODE: from_docs
收到摘要后，对照"缺失信息"清单，补充询问用户（A2 步骤中未收集到的信息）。
A4：生成任务清单
必须先展示任务清单，再逐个生成，禁止一次性写入整个文档。
| 序号 | 任务名称 | 类型 | 状态 |
|------|---------|------|------|
| 1 | 创建文件 - YAML封面 + 文档信息 | [主流程] | [ ] 等待中 |
| 2 | 一、现状及必要性 | [Agent] | [ ] 等待中 |
| 3 | 二、建设目标及内容 | [Agent] | [ ] 等待中 |
| 4 | 三、技术方案 | [Agent] | [ ] 等待中 |
| 5 | 四、投资估算 | [Agent] | [ ] 等待中 |
| 6 | 五、项目组织及计划安排 | [Agent] | [ ] 等待中 |
| 7 | 六、可行性分析 | [Agent] | [ ] 等待中 |
状态标识：[ ] 等待中 → [进行中] → [完成]
A5：生成文档
文件命名规范：
prd/planning/{YYYY-MM-DD}-{项目名称}-可行性研究报告-V1.0.md
任务1（主流程直接写）： 用 Write 创建文件，写入 YAML frontmatter 封面和文档信息表。
封面必须使用以下 YAML frontmatter 格式（对照模板 references/templates/feasibility-report-template.md 的"文档封面"章节）：
---
title: "可行性研究报告"
subtitle: "{项目名称}"
author: "Wong"
date: "编制单位：Chaos Dev Studio\n\n{年月中文，如：二零二六年五月}"
lang: zh-CN
toc: true
toc-depth: 3
numbersections: false
geometry: "left=3.17cm,right=3.17cm,top=2.54cm,bottom=2.54cm"
---
封面之后紧跟文档信息表（参照模板"一、文档信息"章节格式）。
禁止使用 <br/>、<br> 等 HTML 标签。
任务2-7（Agent 流程）： 每个章节按以下步骤执行：
Step 1: 调用 feasibility-writer
subagent_type: "feasibility-writer"
传入：
PROJECT_PATH: {项目根目录}
CHAPTER: {章节名称，如"一、现状及必要性"}
项目信息摘要: {A3 中 feasibility-analyzer 的完整输出}
补充信息: {用户提供的投资估算、里程碑等}
Step 2: 调用 feasibility-reviewer 审查
subagent_type: "feasibility-reviewer"
传入：
PROJECT_PATH: {项目根目录}
CHAPTER: {章节名称}
章节内容: {feasibility-writer 的输出}
项目信息摘要: {A3 的摘要，用于核对数据一致性}
Step 3: 处理审查结果
- 无问题 → 进入 Step 4
- 有问题 → 将审查报告传给 feasibility-writer 修正，重新审查（最多2次）
超过2次仍有问题 → 写入文件并在章节末尾附注"待人工复查：[问题描述]"
Step 4: 写入文件
先用 Read 读取文件当前内容，再用 Edit 追加章节内容
每次追加不超过 150 行
A6：全文档质量检查
所有章节生成完毕后，主流程执行最终检查：
- 结构完整性：对照模板目录，确认六个章节全部存在，无遗漏
- 章节编号一致性：检查所有章节标题是否使用中文数字（一、二、三…），无"第N章"格式
- 不适用章节：确认 1.3/1.4 等不适用章节保留了标题和说明，未被直接删除
- 封面格式：确认文件开头是 YAML frontmatter，无
<br/>等 HTML 标签 - 数据一致性：投资估算合计是否正确，性能指标是否前后一致
发现问题立即用 Edit 修复，修复完成后再进入 A7。
A7：转换为 Word 文档（可选，问一次）
所有章节生成完毕且质量检查通过后，问用户是否导出 Word——不要不问就导。 需要导出时走本技能 Step D 的流程，不要另找工具：
bash ../common/export-word.sh prd/planning/<可研报告文件名>.md feasibility-report
导出后按 Step D 的要求验图：unzip -l <docx> | grep -c "word/media/"，数字必须等于图片张数。
失败先查技能根 config.json 的 apiBaseUrl。
Step B：章节补充模式
- 读取现有可研报告对应章节
- 读取模板中该章节的编制说明和要求
- 按规范补充缺失内容，用 Edit 工具更新
Step C：审查修复模式
C1：扫描文档
找到可研报告：Glob("**/*可行性研究报告*.md") 或 Glob("**/*可研*.md")
C2：逐章审查
对照模板检查每个章节：
- 章节结构是否完整
- 编制说明要求的内容是否都已填写
- 表格数据是否完整
- 是否有遗漏的章节
C3：输出审查报告
## 审查报告
### P0 结构性问题（必须修复）
- [ ] 问题描述 → 修复方案
### P1 内容缺失（需要补充）
- [ ] 问题描述 → 修复方案
### P2 规范不符（建议优化）
- [ ] 问题描述 → 修复方案
审查完成后自动进入修复，无需询问用户确认。
报告结构（标准模板）
参考 references/templates/feasibility-report-template.md，完整结构如下：
YAML frontmatter 封面
一、文档信息（信息表 + 历史版本表）
一、现状及必要性
1.1 项目背景
1.2 国内外现状及发展趋势（引进实施类/自主研发类）
1.3 系统现状（仅提升推广类，其他类型写"本节不适用"）
1.4 主流产品分析（仅引进实施类，其他类型写"本节不适用"）
1.5 需求和必要性分析
二、建设目标及内容
2.1 顶层设计及总体规划
2.2 项目建设目标
2.2.1 业务及功能目标
2.2.2 系统性能目标
2.2.3 系统运维目标
2.3 项目开发功能
2.4 项目实施内容
2.5 项目运维方案
三、技术方案
3.1 技术路线
3.1.1 总体架构
3.1.2 应用架构
3.1.3 数据架构
3.1.4 技术架构
3.1.5 集成架构
3.1.6 部署架构
3.1.7 性能指标
3.1.8 自主可控要求
3.2 数据建设方案
3.3 系统安全建设方案
3.4 技术标准规范
3.5 关键技术
四、投资估算
4.1 投资估算汇总
4.2 投资费用明细
4.2.1 软件购置费
4.2.2 硬件购置费
4.2.3 软件开发费
4.2.4 软件实施费
4.2.5 数据建设费
4.2.6 运维服务费
4.2.7 租赁费
4.2.8 集中办公费
4.3 投资分配表
五、项目组织及计划安排
5.1 项目组织及职责
5.2 里程碑计划
六、可行性分析
6.1 技术论证
6.2 效益分析
6.3 风险评估
章节裁剪规则：
| 章节 | 适用条件 | 不适用时处理 |
|---|---|---|
| 1.3 系统现状 | 仅提升推广类 | 保留章节标题，正文写"本项目为[类型]，本节不适用" |
| 1.4 主流产品分析 | 仅引进实施类 | 保留章节标题，正文写"本项目为[类型]，本节不适用" |
注意：不适用的章节必须保留标题和说明，不能完全跳过，否则章节编号会断裂。
关键原则
- 每次只问一个问题，优先给选项
- 章节编号使用中文数字：一、二、三、四、五、六（对应模板格式）
- 里程碑时间节点使用"T+N月"格式（T为可研报告批复时间），不写具体日期
- 封面必须使用 YAML frontmatter 格式，禁止使用
<br/>等 HTML 标签 - 不适用章节保留标题并写"本节不适用"，不能完全跳过
- 编制说明内容不出现在最终报告中
- 数据不足时用合理的行业参考值填写，不写"待定"；只有投资金额等真正无法估算的数字才填"待定"
- 生成完成后主动提示用户可以导出 Word 格式
导出文档
触发词：「导出可研报告」「可研报告导出Word」「可研报告转Word」
Step 1：找到可研报告 Markdown 文件
Glob("prd/planning/*可行性研究报告*.md")
Glob("docs/规划/*可行性研究报告*.md") # 兼容旧根
Glob("docs/01-需求与规划/*可行性研究报告*.md") # 兼容更旧的归档路径
若找到多个文件，列出让用户选择；若只有一个，直接使用。
Step 2：执行导出
> **⚠️ 导出前后各一件事**：① 图片必须放在**文档同级的 `images/` 子目录**且**文件名纯 ASCII**——这是唯一可用形式，`img/`、`images/sub/`、`../images/`、与文档同目录、中文名**全都静默丢图**（脚本仍打印 `Export succeeded`，但 `word/media/` 是空的）；② 导出后立刻验 `unzip -l <docx> | grep -c "word/media/"`，数字必须等于图片张数。实测边界表见 `../common/README.md`。
bash ../common/export-word.sh <markdown文件路径> feasibility-report
Step 3：反馈结果
- 导出成功：告知用户文件已生成，路径为
prd/planning/<文件名>.docx - 导出失败：检查
../config.json中的apiBaseUrl是否配置正确
文档命名规范
prd/planning/{YYYY-MM-DD}-{项目名称}-可行性研究报告-V{版本号}.md
示例：prd/planning/2026-05-04-能源厂区设备巡检系统-可行性研究报告-V1.0.md
修订：就地改也要改文件名。 不论体量大小一律就地 Edit 改（大文档尤其别整份重写，小文档也不要另存新文件）——目录里永远只留最高版本那一份；改完必须三样一起动——文首「文档版本」、版本记录表、mv 把文件名的版本号也改掉（局部修订 +0.1，结构性重写进大版本；日期取改动当天）。**绝不允许内容已是 V1.1、文件名还写 V1.0。**改名后 grep 一遍旧名，把 README 清单、下游「来源」行、tools/ 脚本里的引用一并改掉。完整规则见 ../common/README.md。
外部依赖与降级：Word/xlsx 导出
导出链走技能库根的 config.json 里的 apiBaseUrl（端点不随仓库分发，取值见该文件）。
| 情况 | 表现 | 怎么办 |
|---|---|---|
没配 config.json |
脚本报「无法从 config.json 读取 apiBaseUrl」 | 从同级 config.example.json 复制后填地址 |
| 服务没起 | curl 连不上 / 超时 |
先自检（在技能自己的目录下跑）：curl -s -o /dev/null -w '%{http_code}' "$(python3 -c 'import json;print(json.load(open("../config.json"))["apiBaseUrl"])')/"，连得上就行（/ 不是路由，返回 404 也算通；连不上才是服务没起），起服务后重试 |
| 两者都缺 | —— | 降级交 md，并在交付清单里写明「Word 未导出（端点未配）」 |
三条不许：不许把「导出失败」写成完成；不许跳过导出直接说交付完成；
不许在导出后不验图——unzip -l x.docx | grep -c 'word/media/' 要等于文档里的图片张数（文件名含中文会静默丢图）。