# Feasibility Report Writer > 按章节模板把项目资料编制成完整的科研立项/科技计划项目可行性分析报告（如宁波市公益类科技计划项目可行性分析报告）。覆盖材料摄取与事实底稿、项目信息与大纲、联网调研与证据补强、分章撰写（背景意义/国内外现状/工作基础/关键技术与创新/实施方案技术路线进度/预期目标）、组装校验与 Word 交付；分多阶段执行，每阶段产物落盘，并单独输出「参考文献与信源清单」供人工复核。用于编制可行性研究报告、可研报告、立项可研、项目可行性分析报告、科技计划项目申报书正文、公益类科研项目可研时，即使只要求其中某一章或某一环节也应使用。注意：若任务是「对标某政策/标准/规划框架做可行性分析与 V 字模型拆解、产出业务/数据/基础设施/改革清单」，应改用 feasibility-decomposition 技能；本技能产出的是按章节模板成文的完整可研报告，二者可串联（拆解结论作为本报告输入）。 - Skill: `zuoa/feasibility-report-writer` (Agent Skill, multi-file: 17 files) - Install (CLI): `npx skillmds add zuoa/feasibility-report-writer` - Raw SKILL.md: https://api.skillmd.com/api/skills/zuoa/feasibility-report-writer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: zuoa (https://skillmd.com/u/zuoa) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/zuoa/feasibility-report-writer --- # 科研立项可行性分析报告编制 ## 核心目标 把用户提供的项目资料，编制成一份**按模板成文、字数达标、事实可溯源、可直接交付**的可行性分析报告。质量优先级： 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` 校验基准）： | 章 | 上限 | |---|---| | 一 背景意义 | 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}` 路径调用： ```bash 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 目录**）： ```text 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 个关键创新/指标重点展开； - **注入行业判断**：在数据之上给出专业研判，不做单纯堆砌； - **量化必有依据**：效益/指标数字须有测算依据或信源，否则改定性并标待验证； - **不编造**：文号、数据、作者、链接、引文均不得杜撰；无网检索时显式声明。 ## 风险说明 产物为可行性分析报告草案，非立项通过保证。效益测算、技术指标须由申报单位结合实际财务、研发能力与最新政策复核；涉及个人信息、敏感数据、自动决策时，额外核查数据来源与处理合法性。