zuoa 科研立项可行性分析报告编制
核心目标
把用户提供的项目资料，编制成一份按模板成文、字数达标、事实可溯源、可直接交付的可行性分析报告。质量优先级：
- 事实真实、可溯源：关键数据/政策/现状均有信源，推断与建议不得写成事实；
- 结构合规、字数达标：严格按模板 6 章结构，每章不突破字数硬限；
- 逻辑闭环：研究内容↔关键技术↔技术路线↔进度↔预期目标前后呼应、指标互不矛盾；
- 可复核：正文每处外部引用都能在独立信源清单中按号定位链接与原文。
不要以篇幅、口号或未经验证的指标代替质量。
目录与输出位置
{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 校验基准）：
| 章 | 上限 |
|---|---|
| 一 背景意义 | 800 |
| 二 国内外现状 | 500 |
| 三 工作基础 | 1000 |
| 四 关键技术与创新 | 1000 |
| 五 实施方案·技术路线·进度 | 2000 |
| 六 预期目标 | 1000 |
工作流（五阶段，每阶段产物落盘）
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 个关键创新/指标重点展开；
- 注入行业判断：在数据之上给出专业研判，不做单纯堆砌；
- 量化必有依据：效益/指标数字须有测算依据或信源，否则改定性并标待验证；
- 不编造：文号、数据、作者、链接、引文均不得杜撰；无网检索时显式声明。
风险说明
产物为可行性分析报告草案，非立项通过保证。效益测算、技术指标须由申报单位结合实际财务、研发能力与最新政策复核；涉及个人信息、敏感数据、自动决策时，额外核查数据来源与处理合法性。