企业官网建设流程全解析

ARIS grant-proposal 技能实战：从研究想法到可提交的基金申请书（KAKENHI / NSF / NSFC / ERC 等九大资助体系全覆盖）

【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址: https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep

本文以 ARIS 仓库中 skills/grant-proposal/SKILL.md 为核心骨架展开。grant-proposal 技能把已验证的研究想法转化为结构完整、评审友好的基金申请书，内置 KAKENHI（日本）、NSF（美国）、NSFC（中国，含面上/青年/优青/杰青/海外优青/重点）、ERC（欧盟）、DFG（德国）、SNSF（瑞士）、ARC（澳大利亚）、NWO（荷兰）以及 GENERIC 通用格式。读完本文，你将掌握该技能的运行常量、九大资助体系的差异化写作规范、风格参考（— style-ref）的可选用法、六阶段流水线（文献定位 → 结构设计 → 章节起草 → 外部评审 → 修订输出）、状态断点续跑机制，以及它与idea-discovery/research-lit/novelty-check/research-review/paper-illustration等子技能的完整编排关系。

一、技能定位：与论文发表平行的"资助轨道"

grant-proposal 技能解决的核心矛盾是：论文论证已完成的工作（结果 + 声明），而基金申请书论证的是未来工作（可行性 + 潜力）。它把经过/idea-discovery验证过的研究想法，组织成评审人视角下可读、可打分的申请书正文。

在 ARIS 的整体工作流中，grant-proposal 是一个并行分支，不属于 Workflow 1→1.5→2→3 的线性管线。/idea-discovery产出验证后的想法之后，用户有两条路：

┌→ /experiment-bridge → /auto-review-loop → /paper-writing (发表轨道) /idea-discovery ────┤ └→ /grant-proposal → [获得资助] → /experiment-bridge → ... (资助轨道)

与发表轨道不同，资助轨道强调"先写申请、后做实验"：申请书本身是说服评审人给钱的论证文本，其独特性在于叙事弧线设计、评审人导向的结构、预算理由说明、时间线规划以及各资助机构的特定格式（skills/grant-proposal/SKILL.md）。

整个技能的流程骨架可以概括为一条调用链：

/research-lit → /novelty-check → [结构设计] → [起草] → /research-review → [修订] → GRANT_PROPOSAL.md (文献综述) (验证空白) (aims+矩阵) (正文) (评审委员会) (修复) (完成!)

二、运行常量与参数透传：一条命令驱动的完整配置

技能头部定义了一组可被参数覆盖的默认常量（skills/grant-proposal/SKILL.md）：

参数可以直接通过—分隔符内联传递，并透传给子技能（skills/grant-proposal/SKILL.md）：

/grant-proposal "topic — KAKENHI Start-up, sources: zotero, arxiv download: true"

三、可选风格参考：— style-ref: <source>（默认关闭）

为让申请书在结构层面（章节顺序倾向、段落长度、图表密度、引用风格）向一份成功的既往提案或论文靠拢，技能提供了— style-ref可选参数。该功能默认关闭——用户不传该参数时，行为与之前完全一致（skills/grant-proposal/SKILL.md）。

仅当$ARGUMENTS中出现— style-ref: <source>时，起草前先执行辅助脚本解析参考源。仓库中对应的实现是 tools/extract_paper_style.py，其 docstring 完整定义了与调用技能的契约（tools/extract_paper_style.py）：

• 支持源类型：本地 TeX 目录、本地 TeX 文件、本地 PDF（依赖pdftotext）、arXiv ID（arxiv:2501.12345或裸 ID 自动识别）、http(s) URL；Overleaf URL/项目 ID 一律拒绝——需先用/overleaf-sync克隆到本地再传本地路径（tools/extract_paper_style.py 与_classify_source实现于 tools/extract_paper_style.py）。
• 退出码契约：0表示成功（缓存已写入，缓存目录路径打印在 stdout 最后一行）；2表示缺少可选依赖（如requests、pdftotext），调用方可跳过并继续；3表示源解析/网络/解析失败，调用方必须中止提案（tools/extract_paper_style.py）。
• 确定性缓存：同源同缓存，按sha256(source_input)[:16]组织于$ARIS_STYLE_REF_CACHE（或~/.cache/aris-style-refs/），包含source_manifest.json（来源溯源）与style_profile.md（风格画像，≤200 行，仅含章节结构、分节字数、定理环境密度、图表密度、引用密度与风格、句长均值/中位数/p90、行内/行间公式比、题注习惯等统计信息，绝不包含被复制句子、声明文字、作者名、具体数字结果，见 tools/extract_paper_style.py）。

技能侧的严格规则（skills/grant-proposal/SKILL.md）与脚本契约一致：

1. 仅用style_profile.md对齐段落长度倾向、图表预算与引用密度；资助类型强制的章节顺序永远优先（KAKENHI 的研究目的→研究計画・方法→準備状況、NSF 的 Intellectual Merit→Broader Impacts 等）——机构模板优先，风格参考只细化次要结构。
2. 绝不复制缓存可达内容中的提案正文、声明、愿景陈述或预算条目——参考物可能是他人已获资助的提案，照搬语言有抄袭风险。
3. 绝不把— style-ref或缓存内容传给 GPT-6-Astra 评审子代理——提案必须凭自身质量被评判。这与仓库的跨模型评审独立协议一致（见 skills/shared-references/reviewer-independence.md：执行者只传文件路径与评审任务，评审模型自行读取一手工件，任何预先摘要、转述或解读都被视为"主观干扰"）。

四、九大资助体系规格对照：机构模板优先

技能把各机构的章节结构、子类型、语言、评审标准与文化规范做成规格表（skills/grant-proposal/SKILL.md）。这是申请书"骨架"的来源，也是评审人判断"是否外行"的第一道门槛：

KAKENHI（日本 JSPS）

• 章节：研究目的、研究計画・方法、準備状況、人権の保護（如适用）
• 子类型：基盤研究 A/B/C、若手研究、研究活動スタート支援、国際共同研究、学術変革領域、挑戦的研究、DC1/DC2（博士生）
• 语言：日语（技术术语可英语）
• 评审标准：学術的重要性、独創性、研究計画の妥当性、研究遂行能力
• 文化规范：显式逐年里程碑（Year 1/Year 2）、预算理由融入计划、强调社会的意義、给出具体预期产出（论文、数据集）、参考 KAKEN 数据库中的相关受资助项目

NSF（美国）

• 章节：Project Summary（1 页）、Project Description（最多 15 页）、References Cited、Biographical Sketch、Budget Justification、Data Management Plan
• 子类型：Standard Grant、CAREER、CRII、RAPID、EAGER
• 语言：英语
• 评审标准：Intellectual Merit、Broader Impacts
• 文化规范：Aim 1/2/3 结构、强烈期待初步数据、Broader Impacts 必须具体（具体外展活动、扩大参与计划，而非空泛的"造福社会"）、有既往 NSF 资助需写 Results from Prior Support

NSFC（中国国家自然科学基金）

• 章节：立项依据、研究内容、研究目标、研究方案、可行性分析、创新性、预期成果、研究基础
• 子类型：面上项目（强调科学问题与研究积累）；青年基金（年龄 ≤35，强调独立性与成长潜力）；优秀青年基金/优青（≤38，强调突出成就）；杰出青年基金/杰青（≤45，强调国际领先水平）；海外优青（强调海外经历与回国贡献计划）；重点项目（强调系统性深入研究）
• 语言：中文
• 评审标准：科学意义、创新性、可行性、研究队伍
• 文化规范：重视国际前沿定位、详尽的可行性分析、明确引用申请人既往论文、研究基础部分是展示 PI 能力的关键

ERC（欧盟）

• 章节：Extended Synopsis（5 页）、Scientific Proposal Part B2（15 页）
• 子类型：Starting Grant（博士毕业 2-7 年）、Consolidator Grant（7-12 年）、Advanced Grant（资深学者）
• 评审标准：Ground-breaking nature、Methodology、PI track record
• 文化规范：强调"高风险/高回报"、方法学表格（WP/deliverables/milestones）、预期 Gantt 图、强 PI 叙事

DFG（德国）｜SNSF（瑞士）｜ARC（澳大利亚）｜NWO（荷兰）

• DFG：State of the Art、Objectives、Work Programme、Bibliography、CV；语言英语或德语；标准为科学质量/原创性/可行性/PI 资质
• SNSF：Summary、Research Plan、Timetable、Budget；语言英语；标准为科学相关性/原创性/可行性/既往记录
• ARC：Project Description、Feasibility、Benefit、Budget；语言英语；标准为研究质量/可行性/对澳大利亚的益处
• NWO：Summary、Proposed Research、Knowledge Utilisation；语言英语；标准为科学质量/创新性/知识转化

GENERIC（通用兜底）

任意未列出的机构，由用户在参数中提供章节名、页数限制与评审标准：

/grant-proposal "topic — GENERIC, sections: Background|Methods|Impact, language: English"

五、六阶段工作流：从解析参数到定稿输出

完整流水线共六个阶段（skills/grant-proposal/SKILL.md），每个关键节点都设有强制检查点（AUTO_PROCEED=false时阻塞等待用户确认）。

Phase 0：参数解析与上下文收集

从$ARGUMENTS提取四类信息：研究方向/想法、资助类型（"科研費"→KAKENHI、"NSF"→NSF、"国自然"→NSFC、"基金"→NSFC）、子类型（"Start-up"、"若手"、"青年"、"CAREER"、"优青"、"海外优青"）、覆盖项（输出格式、语言、评审轮数）。

随后从项目目录收集上下文，优先级如下：idea-stage/IDEA_REPORT.md（来自/idea-discovery，缺失时回退./IDEA_REPORT.md）→refine-logs/FINAL_PROPOSAL.md（来自/research-refine）→refine-logs/EXPERIMENT_PLAN.md（来自/experiment-plan）→review-stage/AUTO_REVIEW.md（来自/auto-review-loop，既往评审反馈对基金是金矿，缺失时回退根目录）→NARRATIVE_REPORT.md/STORY.md→ 文献笔记 → 用户论文清单（publications.md/cv.md/bio.md/CV.pdf）→grant-proposal/GRANT_STATE.json（断点续跑）。

上下文不足时按规则处理：无研究想法→建议先跑/idea-discovery；无文献综述→Phase 1 内联调用/research-lit；无论文清单→PI 资质段落留[TODO: Add publications]占位符。

Phase 1：文献与领域定位

调用/research-lit "$ARGUMENTS"做多源文献检索（arXiv、Scholar、Zotero、本地 PDF），并针对竞争性已受资助项目做 WebSearch（KAKENHI→KAKEN 数据库、NSF→NSF Award Search、NSFC→国自然项目库），识别竞争课题组及其近期论文。随后用/novelty-check验证空白是否真实存在，并构建全文最重要的一句话——gap statement：

"Despite progress in [X], [specific gap] remains unaddressed because [reason]. This proposal addresses this by [approach], which will [expected impact]."

🚦 检查点 1：向用户呈现领域综述摘要与 gap statement，等待确认后进入 Phase 2。

Phase 2：叙事结构与 Aims 设计

先设计逻辑架构再动笔，四件事：

1. 定义 Specific Aims（2-4 个），每条满足：独立有价值（一个 Aim 失败，其余仍产出可发表结果）、逻辑相连（Aim 1 使能 Aim 2）、可交付物具体（论文/数据集/工具/基准）、预算与时间线内可行。
2. 构建 Claims-Aims-Evidence 矩阵：

| Aim | Key Claim | Preliminary Evidence | Proposed Validation | Risk Level | Deliverable | |-----|-----------|---------------------|--------------------|-----------:|-------------| | Aim 1 | [claim] | [pilot data, prior work] | [experiments] | LOW | [paper, dataset] | | Aim 2 | [claim] | [theoretical basis] | [experiments] | MEDIUM | [paper, tool] |

3. 设计叙事弧线——基金与论文的弧线根本不同：

Problem → Why Now → What We Propose → Why It Will Work → What We Will Deliver (而非: Problem → Method → Results → Implications)

• Problem：存在什么空白、为何重要（科学 + 社会）
• Why Now：哪些新发展（新数据、新方法、新需求）使当下是正确时机
• What We Propose：具体 Aims 与路线
• Why It Will Work：初步数据、PI 既往记录、团队专长、可行性论证
• What We Will Deliver：具体产出、时间线、预期论文

4. 设计时间线与里程碑（按年或按季度），并调用/research-review以"资助评审委员"人设对结构做批判性反馈，评估 Aims 独立性、叙事弧线、风险识别与时间线现实性，找出"评审人最担心的单一问题"。

🚦 检查点 2（最关键的检查点）：呈现完整结构（gap、各 Aim 标题与风险、时间线、评审反馈），用户可"go"、改结构、退回 Phase 1 或停止。

Phase 3：章节起草

按机构模板逐节写完整散文，而非提纲。起草顺序刻意优化叙事连贯性：Specific Aims/研究目的（先写最后打磨）→ Background/Significance/State of the Art → 研究计划与方法（逐 Aim 带可行性论证）→ 图表 → 时间线与里程碑 → PI 资质/準備状況 → 预算理由（只写叙事，金额留[AMOUNT]占位符）→ 社会影响（如机构要求）。

图表是基金的利器，建议三张：全体構成図（Aims 关系 + 共享资源 + 产出，最重要的一张）、実験パラダイム図、年次計画 Gantt 图。出版级图调用/paper-illustration，简单流程图/Gantt 直接生成 SVG 或 matplotlib。🚦 图检查点：询问用户要哪几张，只生成被点名的。

各机构起草细则（节选）：KAKENHI 用である調正式学术日语、逐年内包预算理由、强调社会的意義；NSF 用直接清晰英语、每 Aim 带初步数据段、Broader Impacts 必须具体；NSFC 立项依据定位国际前沿、创新性列出编号创新点、研究基础引用 PI 本人论文（尽量带 IF 与引用数）、可行性分析覆盖技术/队伍/时间/条件四维；ERC 写"高风险/高回报"叙事、Extended Synopsis 自洽有力、含 Work Package 表与 Gantt。

Phase 4：外部评审

对完整草稿调用/research-review，让 GPT-6-Astra 以 xhigh 推理扮演该机构评审委员：按官方标准给每节打 1-5 分、找出致命缺陷、给出资助/修改/拒稿建议、输出按严重度排序的行动项，全部存入grant-proposal/GRANT_REVIEW.md。

评审通过 Codex MCP 完成时，遵循仓库测试所固化的"路径优先"模式（tests/test_mainline_large_payload_prompts.py 验证了grant-proposal/codex_panel_review_bundle_round_1.md与grant-proposal/codex_panel_review_bundle_round_N.md的 bundle 约定）：先写评审 bundle 文件（含评审标准 + 提案绝对路径），再把 MCP 提示保持极短：

mcp__codex__codex-reply: threadId: [from Phase 2] # 继承线程的模型/努力级别，不要重发 prompt: | Read the grant review bundle at <absolute path to grant-proposal/codex_panel_review_bundle_round_1.md> and follow all instructions in it.

Round 2+ 复用同一线程与同一短提示模式，bundle 内含变更日志、需检查的 diff/文件路径与当前提案绝对路径，聚焦"Round 1 的 CRITICAL 与 MAJOR 问题是否已解决"。

⚠️ 降级路径：若mcp__codex__codex不可用（无 OpenAI API key），跳过外部评审，在GRANT_REVIEW.md注明"External review skipped — no Codex MCP available. Consider running/auto-review-loop-llmseparately."，提案在无外部评审下仍可使用。

Phase 5：修订与输出

把评审反馈按严重度分级：CRITICAL（致命缺陷，立即修）、MAJOR（显著弱点，提交前必修）、MINOR（锦上添花，有余力再修）。实施 CRITICAL 与 MAJOR 修复；若MAX_REVIEW_ROUNDS > 1，经mcp__codex__codex-reply再提交一轮。

Markdown 输出目录结构（默认）：

grant-proposal/ ├── GRANT_PROPOSAL.md # 完整提案，含全部章节 ├── GRANT_REVIEW.md # 评审历史与反馈 ├── GRANT_STATE.json # 状态持久化文件 ├── figures/ # 生成的图表（如有） └── references.bib # 文献库（如使用了引用）

LaTeX 输出结构（OUTPUT_FORMAT = latex时）：main.tex主文件 +sections/下的aims.tex、background.tex、research_plan.tex、timeline.tex、pi_qualification.tex、budget.tex+references.bib+figures/。

定稿自检清单（节选）：所有机构必需章节齐全、gap statement 清晰且靠前出现、每个 Aim 独立且逻辑相连、时间线含逐年里程碑、预算用[AMOUNT]占位（不编数字）、语言匹配机构、除 PI 个人信息外无遗留[TODO]、引用真实（无幻觉引用）、评审反馈已处理。

六、状态持久化：长任务防上下文压缩的断点续跑

基金申请起草是长任务，可能触发上下文压缩。技能在每个阶段结束时把状态写入grant-proposal/GRANT_STATE.json：

{ "phase": 2, "grant_type": "KAKENHI", "grant_subtype": "Start-up", "language": "Japanese", "codex_thread_id": "019cfcf4-...", "gap_statement": "...", "aims_count": 3, "status": "in_progress", "timestamp": "2026-03-18T15:00:00" }

调用时检查该文件：不存在或status: "completed"→ 全新开始；in_progress且 24 小时内 → 从保存阶段恢复（读GRANT_PROPOSAL.md与GRANT_REVIEW.md恢复上下文）；超过 24 小时 → 视为过期状态，全新开始。完成时置"status": "completed"。

该 24 小时过期阈值与仓库的 skills/shared-references/output-versioning.md 中"陈旧状态检测"协议一致（默认阈值 24 小时，auto-review-loop、research-refine同样采用 24h）。输出文件的版本管理同样遵循该协议：可被覆盖的文件（如GRANT_PROPOSAL.md）先写时间戳副本（{FILENAME}_{YYYYMMDD_HHmmss}.md）再写固定名最新副本，下游技能只读固定名文件。

七、关键红线：基金 ≠ 论文，且绝不编造

技能把以下规则列为硬约束（skills/grant-proposal/SKILL.md），这是基金申请区别于论文写作的根本纪律：

• 不编造预算金额：只写叙事性预算理由，具体金额一律留[AMOUNT]占位符交用户填写。
• 不编造 PI 信息：无论文清单时留[TODO: Add publications]，绝不虚构论文、资助或资历。
• 不幻觉引用：只用文献综述得到的引用，不确定的标注[VERIFY]。
• 基金 ≠ 论文：强调"我们将做什么"与"为何可行"，而非"我们发现了什么"。
• Aims 必须独立有价值：Aim 2 失败时 Aim 1 与 Aim 3 仍应产出可发表结果。
• 初步数据去风险：纳入任何预实验、既有数据集或既往论文来证明可行性。
• 评审人导向的结构：关键句加粗、编号列表清晰，让评审人省力。
• 文化规范缺失即红旗：KAKENHI 缺社会的意義、NSF 缺 Broader Impacts、NSFC 缺国际前沿定位，都是评审人眼中的警示。
• 大文件处理：Write 因体积失败时，立即改用cat << 'EOF' > file分块写入，静默执行不询问。
• 飞书通知可选：存在~/.claude/feishu.json时，每个阶段转换发checkpoint、最终输出发pipeline_done；文件不存在则静默跳过。

八、子技能编排与输出协议

技能依赖四个子技能（skills/grant-proposal/SKILL.md）：

资助轨道完整链路（本技能的主用例）：

/idea-discovery "direction" ← Workflow 1: 找到已验证想法 /research-refine "idea" ← 打磨方法 /grant-proposal "idea — KAKENHI" ← 本技能：写基金申请书 ← [提交并获资助] /experiment-bridge ← 带资助实施实验 /auto-review-loop "results" ← Workflow 2: 迭代至可提交 /paper-writing ← Workflow 3: 写论文

发表轨道（跳过本技能）：/idea-discovery → /experiment-bridge → /auto-review-loop → /paper-writing → submit。

所有输出文件遵循三项共享协议（skills/grant-proposal/SKILL.md）：输出版本化协议（skills/shared-references/output-versioning.md——先写时间戳文件再复制为固定名）、输出清单协议（skills/shared-references/output-manifest.md——运行产出超过 15 个工件时在MANIFEST.md逐条登记；未达阈值不建清单，避免重复索引）、输出语言协议（skills/shared-references/output-language.md——尊重项目的语言设置）。

九、从源码看实现支撑

几个关键机制在仓库源码中有直接印证：

• 风格参考解析链：技能脚本先经"规范严格安全链"解析$STYLE_HELPER（依次尝试.aris/tools/、tools/、$ARIS_REPO/tools/，并可从.aris/installed-skills.txt或~/.aris/repo恢复仓库根，见 skills/grant-proposal/SKILL.md），解析失败即中止——保证用户点名要的风格参考必须被满足。底层实现 tools/extract_paper_style.py 对 TeX 源统计章节结构、定理环境密度、图表密度、引用密度与风格、句长分位数、公式行内/行间比等（_profile_from_tex实现于 tools/extract_paper_style.py），对 PDF/HTML 源则做尽力而为的启发式画像（_profile_from_text，tools/extract_paper_style.py）。
• 评审 bundle 约定：测试 tests/test_mainline_large_payload_prompts.py 断言了主流程技能（含 grant-proposal）在把大载荷交给 Codex 时，必须使用"bundle 文件 + 极短路径提示"模式，避免在 MCP 提示中内联大段正文——这既保护提示长度，也符合 skills/shared-references/reviewer-independence.md 的"评审人自行读取一手工件"原则。
• 技能目录：docs 侧的技能清单 docs/SKILLS_CATALOG.md 将/grant-proposal登记为"结构化基金申请书起草——KAKENHI (JP)、NSF (US)、NSFC (CN，含面上/青年/优青/杰青/海优/重点)、ERC (EU)、DFG (DE) 等"，与技能头部 description 完全一致。

结语：一条命令，九套体系

grant-proposal 的核心价值在于把"写基金"这件高度依赖机构知识与评审心理的复杂任务，折叠成一条可参数化的命令与六个带检查点的阶段。它不替你决定研究方向（那属于/idea-discovery），不替你编造预算与资历（那是硬红线），而是把"从已验证想法到评审可读申请书"之间的全部机械化劳动——文献定位、gap 论证、Aims 设计、机构格式、外部评审、修订闭环、断点续跑——交给可复现的流水线，让 PI 把精力留在最需要人类判断的地方：结构决策与最终数字。上手方式：确认idea-stage/IDEA_REPORT.md或refine-logs/FINAL_PROPOSAL.md就绪后，直接运行/grant-proposal "你的研究方向 — KAKENHI 若手"（或替换任意支持的机构），并在每个检查点给出你的判断即可。

【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址: https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep