feasibility-report-writer

Imported from zuoa/aj-skills (skills/feasibility-report-writer/SKILL.md). Install upstream with npx skills add zuoa/aj-skills --skill feasibility-report-writer. Copyright stays with the author.

科研立项可行性分析报告编制

核心目标

把用户提供的项目资料，编制成一份按模板成文、字数达标、事实可溯源、可直接交付的可行性分析报告。质量优先级：

1. 事实真实、可溯源：关键数据/政策/现状均有信源，推断与建议不得写成事实；
2. 结构合规、字数达标：严格按模板 6 章结构，每章不突破字数硬限；
3. 逻辑闭环：研究内容↔关键技术↔技术路线↔进度↔预期目标前后呼应、指标互不矛盾；
4. 可复核：正文每处外部引用都能在独立信源清单中按号定位链接与原文。

不要以篇幅、口号或未经验证的指标代替质量。

目录与输出位置

• {baseDir} = 本 SKILL.md 所在目录（只读资产：scripts/、references/、templates/、examples/）。调用脚本一律用 {baseDir}/scripts/...，依赖装在 {baseDir}/.venv 时用 {baseDir}/.venv/bin/python 执行；不要假设当前工作目录是仓库根或 skill 根。
• 所有产物写入用户当前工作目录下的 outputs/（即运行命令时所在的目录），绝不写入 skill 目录。下文及各 reference 中出现的 outputs/... 路径，一律相对于当前工作目录解析；--input/--output/--sources/--output-dir/--report/--manifest 等参数同理。
• skill 目录里的 outputs/ 仅为结构占位，运行时不写入；工作目录下若尚无 outputs/，运行时按需创建。

任务路由

先判断用户需要哪种结果，只执行必要分支：

• 只给零散资料、方向未定：先做 Stage 0 摄取与事实底稿，再 Stage 1 大纲确认。
• 资料较全、要求一次成稿：依次跑 Stage 0→1→2→3→4，但每阶段产物仍分别落盘。
• 只要求某一章/某几章：复用已有事实与信源，只写该章，不重跑全流程。
• 只要联网调研/信源核查：跑 Stage 2，输出调研底稿与信源清单，不写正文。
• 已有报告草稿、要求修订：进入非破坏性修订，以旧稿为基线另存新版本，记录对事实/字数/信源的影响，不无故重写。
• 只要最终 Word/字数校验：跑 Stage 4 的 wordcount_check.py 与 generate_docx.py。

纯文本分析（摄取、分章撰写）不需要初始化 Python 环境。只有实际生成 DOCX 或程序化技术路线图时才检查依赖（bash {baseDir}/scripts/setup_env.sh）。

模板

默认模板：references/report-template.md（由用户 可行性分析报告.doc 拆解，6 章结构 + 字数硬限 + 每节官方写作指引）。模板路径可切换，便于将来扩展其他可研类型（如投资项目可研），但本技能默认且仅内置科研立项模板。

字数硬限（{baseDir}/scripts/wordcount_check.py 校验基准）：

工作流（五阶段，每阶段产物落盘）

Stage 0 — 材料摄取与事实底稿

读取 references/intake-and-facts.md。优先从对话与用户文件提取信息，不重复询问已给出的内容。Office 材料（.doc/.docx/.pptx）用 {baseDir}/scripts/office_to_markdown.py 转文本（--output-dir 指向工作目录下的 outputs/intake）。不扫描第三方依赖与生成文件，不回显密钥/令牌/个人敏感信息。

为每项关键信息标注证据状态：用户已确认 / 资料有据（可定位到用户文件）/ 合理推断（尚待确认）/ 待确认（影响立项判断的缺口）/ 建议方案（研发建议，非既有事实）。不得把「合理推断」「建议方案」写成已实现事实；一次成稿时保留 【待确认：…】，不偷偷补造。

输入过短时，只问最影响立项判断的 3–5 个组合问题（研究对象/核心问题/团队与基础/预期指标/起止周期），不先问不影响内容的问题。

产物：outputs/project_brief.md（事实底稿 + 证据状态 + 待确认项清单）。

Stage 1 — 项目信息确认与大纲

填写项目画像：项目名称、承担单位、合作单位、负责人、研究起止年月、总预算、项目类型。生成与模板 6 章 1:1 的大纲（outputs/outline.md），标注重点章、材料缺口与每章将引用的信源规划。模糊项用合理默认并显式说明，不阻塞；仅做一次确认点。大纲确认后再进入调研与撰写。

产物：outputs/outline.md。

Stage 2 — 联网调研与证据补强

读取 references/research-and-evidence.md。有网络能力时实际执行外部检索，不得只凭模型记忆给结论。检索上限 4–5 次，覆盖：①政策依据（国家/省/市文件，核验文号与发布机构）②国内外研究现状（近 3–5 年代表性进展）③技术标杆/同类项目 ④产业/市场数据（支撑背景与效益测算）。

每条结果立即录入 outputs/research/sources.json，字段：序号、类型、标题、发布机构、日期（发布/访问）、链接、引用要点（用于哪章·引用了什么）、核验状态（已核验原文 / 基于摘要或二手 / 仅检索命中未核验 / 未执行外部检索）。必做三项判断：技术可行性与创新性初判、主要风险（3–5 条）、推进建议。

无网络能力时，显式在调研底稿与信源清单写「未执行外部检索」，仅列用户提供材料来源与检索策略，绝不编造文号、数据、作者或链接。

产物：outputs/research/research_dossier.md（调研底稿 + 关键发现表）+ outputs/research/sources.json。

Stage 3 — 分章撰写

读取 references/report-template.md 与 references/section-writing-guide.md。按 6 章顺序撰写，每章独立落盘到 outputs/sections/，严守字数硬限。把 Stage 0 事实与 Stage 2 信源织入对应章节；正文不出现 [信源N] 等引用标记，信源统一记入独立清单（靠「引用要点（章节·引用内容）」与正文对应）。

深度硬要求（最易写浅、务必达标）：①第四章关键技术——每条必须点名到具体算法/模型/方法（如 YOLOv8、迁移学习、多源融合、边缘轻量化推理），给技术机理与可考核指标，禁止用「智能/先进/高效」等空话替代（详见 report-template.md 第四章、section-writing-guide.md 第四章「深度自检」）；②第五章技术路线——必须给分层技术架构 + 逐模块技术路径（输入→核心算法/模型→输出→衔接下一模块）+ 数据流，图 1 是技术架构/数据流图、不是进度时间轴；不得把「基础研究—系统开发—集成应用—示范推广」阶段流水账写进技术路线（那是实施方案/进度）；③第五章（一）实施方案——必须给建设内容分解（建什么/交付物）+ 技术/平台硬件（用什么，点名技术栈与硬件）+ 数据方案（来源/规模/标注质控）+ 实施步骤 + 试验验证设计（场景/对照/指标/判定），不泛泛而谈（详见 report-template.md 第五章、section-writing-guide.md 第五章「深度自检」）。关键技术 ↔ 创新点 ↔ 技术路线模块 三者 1:1 呼应。技术路线图优先程序化生成（matplotlib / mermaid，图元与正文术语一致、图号连续）。每 2–3 章做一次确认点。

产物：outputs/sections/01_背景意义.md … outputs/sections/06_预期目标.md（+ 技术路线图源文件/图片）。

Stage 4 — 组装、校验与交付

按 references/report-template.md 的「组装 Markdown 约定」组装完整报告（front-matter 封面信息 + #/## 层级正文 + 图题），再逐项过 references/quality-checklist.md 五道门：

• 真实性门：无把推断/建议/未检索结果写成事实；引用均可追溯；
• 字数门：运行 {baseDir}/scripts/wordcount_check.py，每章 ≤ 硬限；
• 一致性门：研究内容↔关键技术↔技术路线↔进度↔预期目标指标互不矛盾；术语/图号一致；
• 引用门：正文无任何 [信源N] 标记；信源全部在独立清单且每条标注「用于哪章·引用了什么」；清单与 sources.json 一致；链接可达性抽查；
• 格式门：按 report-template.md「格式规范」——封面/章/节/正文/图题的字号、字体（黑体/宋体）、首行缩进、页眉页脚齐全正确；【待确认：…】/【待验证：…】 标蓝斜体（由 generate_docx.py 自动套用）。

生成独立信源清单：outputs/参考文献与信源清单.md（人工复核用，按序号列表，含标题/机构/日期/链接/引用要点/核验状态），与 sources.json 双向一致。

导出：在用户当前工作目录下运行，产物落在工作目录的 outputs/；脚本与 venv 用 {baseDir} 路径调用：

python3 {baseDir}/scripts/wordcount_check.py --input outputs/可行性分析报告_[项目名]_v1.0.md
python3 {baseDir}/scripts/generate_docx.py --input outputs/可行性分析报告_[项目名]_v1.0.md \
  --output outputs/可行性分析报告_[项目名]_v1.0.docx --with-markdown \
  --sources outputs/research/sources.json

若依赖缺失，先 bash {baseDir}/scripts/setup_env.sh，再用 {baseDir}/.venv/bin/python 执行上述脚本（仍从工作目录运行，outputs/ 路径不变）。同一输入重复导出由 sha256 旁车文件避免重复生成；内容变化用新版本文件名或 --overwrite。

产物：outputs/可行性分析报告_[项目名]_v1.0.md + .docx + .docx.sha256 + outputs/参考文献与信源清单.md + outputs/quality_report.json。

输出契约

按任务范围交付，不强制制造无关文件。完整项目的推荐产物（全部落在当前工作目录的 outputs/ 下，不要写进 skill 目录）：

outputs/
├── project_brief.md                 # Stage 0 事实底稿
├── outline.md                       # Stage 1 大纲
├── intake/                          # Stage 0 Office 转换稿（office_manifest.json + *.md）
├── research/
│   ├── research_dossier.md          # Stage 2 调研底稿
│   └── sources.json                 # Stage 2/4 机读信源
├── sections/                        # Stage 3 分章
│   ├── 01_背景意义.md
│   ├── 02_国内外现状.md
│   ├── 03_工作基础.md
│   ├── 04_关键技术与创新.md
│   ├── 05_实施方案与进度.md
│   ├── 06_预期目标.md
│   └── tech_route_diagram.*         # 技术路线图（图1）
├── 可行性分析报告_[项目名]_v1.0.md      # Stage 4 组装正文
├── 可行性分析报告_[项目名]_v1.0.docx
├── 可行性分析报告_[项目名]_v1.0.docx.sha256
├── 参考文献与信源清单.md             # ★ 独立信源清单（人工复核）
└── quality_report.json              # 五道门校验结果

首次草案至少同时给出：一句话项目定位、已确认事实与待确认项、6 章正文、信源清单、字数校验表、下一轮最值得确认的问题。

编写纪律

• 面向客户而非流程：交付用户需要的报告，不堆砌过程叙事；
• 突出重点而非平均用力：3–5 个关键创新/指标重点展开；
• 注入行业判断：在数据之上给出专业研判，不做单纯堆砌；
• 量化必有依据：效益/指标数字须有测算依据或信源，否则改定性并标待验证；
• 不编造：文号、数据、作者、链接、引文均不得杜撰；无网检索时显式声明。

风险说明

产物为可行性分析报告草案，非立项通过保证。效益测算、技术指标须由申报单位结合实际财务、研发能力与最新政策复核；涉及个人信息、敏感数据、自动决策时，额外核查数据来源与处理合法性。