立项报告 · proposal-writer

二次开发：本技能改编自 Yuan1z0825/nature-skills 的 nature-proposal-writer（Apache-2.0），在保留其「证据先于文字、论证先于章节、契约先于段落、内容先于语言」的科研写作状态机骨架基础上，平移到中文项目申报 / 立项报告场景，去掉其对 references/ 文献目录的强依赖（改为用户直接提供事实 / 数据 / 需求清单），升级为「提示词 + 可执行 CLI」双形态。署名见本目录 NOTICE.md 与仓库 THIRD_PARTY_NOTICES.md。

这个技能做什么

把用户脑子里"想做的一件事"（一个项目、一个课题、一场活动、一笔预算、一个内部创新点），按一条有纪律的写作状态机落成一份评审看得懂、挑得出毛病、站得住理由的完整立项报告草稿。

它不是一句"帮我写个立项书"就直接出成品的玄学 prompt。它坚持四步走，每一步都有交付物：

1. 证据表先于文字 —— 动笔前先把支撑"为什么该立这个项"的事实 / 数据 / 需求一条条列成表（每条带来源、可靠度），没有证据的主张不许进正文；
2. 论证图先于章节 —— 写正文前先把"背景 → 问题 → 目标 → 方案 → 预期价值"的论证链画清楚，每一节只论证一个主张；
3. 章节契约先于段落 —— 每一节开写前先写死"这节要说服评审什么、能说什么、不能说什么"；
4. 四层 QA 先于交付 —— 交稿前逐层自检：内容层、结构层、语言层、评分层，逐项不省略。

典型场景（中文项目申报高频）：

• 项目立项申请：向公司 / 单位 / 基金方申请一个新项目的立项；
• 课题开题报告：研究课题、研发课题启动前的开题；
• 活动方案申报：市场活动、内部活动、赛事、培训项目的立项申报；
• 预算申请材料：为一笔预算申请撰写立项 / 必要性说明；
• 内部创新提案：向管理层提交的改进型、创新型项目提案。

输入要求

• 必填（CLI 输入文件应包含）：
  1. 立项主题：这个项目 / 课题 / 活动叫什么、属于什么类别（研发 / 市场 / 运营 / 基建 / 学术课题等）；
  2. 关键事实 / 数据 / 需求信息清单：用户手里已有的、能支撑立项的真实信息——现状数据、痛点、市场规模、用户反馈、政策依据、已有先例、资源情况等。每条尽量带来源（哪个部门、哪份报表、哪份调研、哪条政策）。
• 强烈建议提供（缺失处正文一律标「（待确认）」，不替用户编造）：
  • 申请方 / 负责人、项目周期、预算盘子；
  • 想要达成的具体目标、打算怎么做的初步思路；
  • 可量化的预期收益、已知的风险点。
• 信息不足时：先向用户追问最关键的 2–3 个缺口（尤其是"这个问题到底有多大、拿什么数据证明"），不要凭空把报告写满。

输出结构（模板见 scripts/templates/proposal-writer.template.md）

一份完整立项报告草稿，自上而下七节：

1. 立项基本信息：名称 / 类别 / 申请方 / 周期 / 预算——缺失字段一律标「（待确认）」，不留空也不编造；
2. 背景与意义：引用证据表里的真实信息论证"为什么现在必须做这件事"，不编造数据；
3. 问题与目标：问题与目标一一对应，每条目标必须可检验（可量化或可验收）；
4. 方案与计划：技术路线 / 实施步骤 / 里程碑 / 所需资源；
5. 预期价值与风险：明确的价值主张（对谁、带来什么）+ 风险清单及应对措施；
6. 证据表：用户提供的证据逐条列出，含来源 / 可靠度 / 是否被用于论证；
7. 四层 QA 自检报告：内容层（每条主张有证据支撑吗）/ 结构层（章节符合契约吗）/ 语言层（表述准确、不夸大吗）/ 评分层（对照评审标准自评打几分、哪里扣分），四层逐项给结论，不省略。

工作流程

1. 建证据表（状态一）：把用户提供的事实 / 数据 / 需求逐条登记成表，标注来源与可靠度（高 / 中 / 低）。用户没提供的，不许自己补。
2. 画论证图（状态二）：按"背景 → 问题 → 目标 → 方案 → 预期价值"串成一条论证链；每一节只承载一个核心主张，主张之间有因果衔接，不跳跃。
3. 定章节契约（状态三）：对照输出七节，为每节写死三件事——这节要说服评审什么（purpose）、允许出现的主张（allowed claims）、禁止出现的主张（forbidden claims）。
4. 逐节成稿（状态四）：按契约逐节写正文；每节写完对照契约自查，超纲或证据不足的句子直接删（删除胜于解释）。
5. 四层 QA（状态五）：依次跑内容层 → 结构层 → 语言层 → 评分层，把每层结论写进第七节自检报告；评分层低于可接受线的，明确指出回退到哪一节重写。

质量规则（必须遵守）

• 只用真实信息：正文只使用用户提供或证据表中真实存在的事实；凡需补数据、补引用、补人名 / 金额 / 日期而用户未给的，一律标「（待确认）」，绝不编造。
• 不自动升级事实强度："可能改善"不许写成"显著提升"，除非证据表里有对应强度的依据。
• 问题与目标一一对应：第 3 节每条问题必须能映射到至少一条目标，每条目标必须可检验（有量化指标或验收标准）。
• 章节契约式写作：每一节必须有明确的说服目的；写完对照契约，超纲内容删除。
• 四层 QA 逐项不省略：内容 / 结构 / 语言 / 评分四层每层都要给明确结论，不许只写"已检查，无问题"糊弄。
• 删除胜于解释：某个主张证据不够时直接删掉，不要在正文里找补；解释留到答辩。
• 该停就停：关键证据缺失到无法支撑核心主张时，在自检报告里如实标注"本报告因证据不足暂不具备申报条件"，而不是硬写满。

边界与异常处理

• 用户只给了一个模糊想法、没有任何事实数据 → 先追问"现状是什么、有什么数据支撑痛点"，拿到证据清单再动笔；不要直接写一份空泛模板。
• 证据表与正文主张对不上（正文出现了证据表没有的主张）→ 视为 QA 内容层不通过，回退删除该主张或要求用户补证据。
• 问题与目标数量不对等（问题 3 条、目标只有 2 条）→ 视为结构层不通过，必须补齐对应目标。
• 预算 / 周期 / 申请方缺失 → 不阻塞成稿，对应字段标「（待确认）」，并在自检报告评分层扣"信息完整性"分。
• 评审标准未知 → 评分层按通用立项评审维度（必要性、可行性、价值、风险可控性、方案清晰度）自评，并注明"评审标准待用户提供后复评"。
• 用户给的是英文材料 / 双语专有名词 → 保留英文专有名词，正文用中文公文式书面语。

与脚本配合

• 批量 / 命令行场景：scripts/draft_proposal_writer.py（纯标准库，一条命令跑通）；输入为用户整理的立项主题 + 关键事实 / 数据 / 需求清单文本，输出为含七节结构的完整立项报告 Markdown 草稿。
• 自定义模板：复制 scripts/templates/proposal-writer.template.md 修改后使用。