168 lines
6.7 KiB
Markdown
168 lines
6.7 KiB
Markdown
# 评审雷区清单
|
|
|
|
评审专家最常拍死的几类问题。**写完每章对照过一遍**,中一条就重写。
|
|
|
|
---
|
|
|
|
## 1. 与指南脱靶 (一票否决)
|
|
|
|
- 项目名称、指南方向、创新分类与指南文件**不一致** (一个字都不能改)
|
|
- 研究内容不能映射回指南的研究任务清单
|
|
- 考核指标缺项 — 指南要求 5 项,你只写了 4 项
|
|
- 指南要求"研发 X 套软件",你写"研究 X 软件理论" — 类型对不上
|
|
- 自行扩大或缩小指南范围 — 指南限定 A,你做 A+B
|
|
- 重点研发应用示范类项目却没有示范单位/示范点 — 类型错位
|
|
|
|
**自查**: 把指南文本逐条贴进 spec_lock,每写完一节回去标"已覆盖"。
|
|
|
|
---
|
|
|
|
## 2. 假大空话术 (低分项)
|
|
|
|
直接 ban 的词组:
|
|
- "国际领先" / "国际一流" / "填补空白" — 除非有第三方测试报告
|
|
- "首次提出" — 除非确实没人做过且能给文献证明
|
|
- "重大突破" / "重要意义" / "深远影响" — 缺信息量
|
|
- "立足国际前沿,聚焦关键核心" — 万能开场, 评审看疲了
|
|
- "建设具有 XX 特色的世界一流 YY" — 喊口号
|
|
|
|
替换原则:
|
|
- 用**指标+对比**替代形容词: "实现 10000 TPS,比现有方案 (Hyperledger Fabric 3000 TPS) 提升 3.3 倍"
|
|
- 用**机制+创新点**替代"突破": "通过 XX 解耦 + YY 流水线,降低共识延迟到 100 ms"
|
|
|
|
---
|
|
|
|
## 3. 指标无法考核 (致命)
|
|
|
|
不可考核的写法:
|
|
- "显著提升性能" — 显著 = 多少?
|
|
- "支持大规模交易" — 大规模 = 多少 TPS?
|
|
- "提升用户体验" — 怎么测?
|
|
- "优化算法效率" — 优化几个百分点?
|
|
|
|
可考核的写法:
|
|
- "TPS ≥ 10000, 端到端延时 < 100 ms (用 Caliper 工具测试,提供 CNAS/CMA 报告)"
|
|
- "示范园区 ≥ 4 个, 区块链节点 ≥ 50 个, 交易量 ≥ 50 万吨"
|
|
- "发明专利 ≥ 5 项 (已获受理通知书)"
|
|
|
|
每个指标必须能回答: **怎么测? 谁来测? 验收时拿什么证明?**
|
|
|
|
---
|
|
|
|
## 4. 经费不合理 (扣分)
|
|
|
|
| 雷区 | 后果 |
|
|
|----|----|
|
|
| 间接费用超比例 (≤500 万部分 >30% / 500-1000 万 >25% / >1000 万 >20%) | 财务退回 |
|
|
| 设备费占比过高 (>40%) | 评审质疑必要性 |
|
|
| 劳务费支付给本单位编制内人员 | 违规 (劳务费仅给临时聘用) |
|
|
| 预算说明不写**任务相关性 + 政策相符性 + 经济合理性** | 退回补充 |
|
|
| 50 万以上设备没在 B3 表明细 | 必须明细到型号、功能、技术指标、生产厂家 |
|
|
| 自筹资金没出资单位承诺函 | 视为无配套 |
|
|
| 预算总额与指南资助额度不匹配 | 直接形式审查不过 |
|
|
|
|
详见 `budget_rules.md`。
|
|
|
|
---
|
|
|
|
## 5. 限项违规 (一票否决)
|
|
|
|
- 项目负责人在研重点研发/重大专项/农业关键核心技术 **>2 项** — 直接退回
|
|
- 同一指南方向同一单位申报 **>1 项** — 学校层面就会被砍掉
|
|
- 同年同人不同基金多头申请 NSFC — 不予受理
|
|
- 主要参与人单位与所在单位**不一致**且未说明原因 — 退回补充
|
|
- 项目负责人在退休/出站等状态变动 — 须重新审查资格
|
|
|
|
**写之前先跟用户确认**: 你是不是已经在执行其他重点研发/重大专项? 团队成员有没有重叠的?
|
|
|
|
---
|
|
|
|
## 6. 研究内容/方法/路线混淆 (低分)
|
|
|
|
最常见的混乱:
|
|
- 研究内容里写了方法 (HOW)
|
|
- 研究方法里写了目标 (WHAT)
|
|
- 技术路线里写了背景 (WHY)
|
|
|
|
正确的边界:
|
|
| 章节 | 回答的问题 | 写什么 |
|
|
|-----|----------|------|
|
|
| 立项依据 | WHY | 现状 → 痛点 → 我们切入 |
|
|
| 研究目标 | WHAT (终态) | 量化指标、预期成果 |
|
|
| 研究内容 | WHAT (任务) | 技术 1, 技术 2, ... 8 项关键技术 |
|
|
| 研究方法 | HOW (原理) | 用什么算法/模型/原理来做 |
|
|
| 技术路线 | HOW (流程) | 输入 → 处理 → 输出, 5 个阶段如何串起来 |
|
|
|
|
写完检查: 把每章第一段拿出来读,能否准确回答上面"回答的问题"?
|
|
|
|
---
|
|
|
|
## 7. 团队介绍踩雷
|
|
|
|
- ❌ 只列 title 不挂钩本项目: "XX 教授, 长江学者, 主持过 N 个项目" — So what?
|
|
- ❌ 团队规模虚胖: 写 50 人但项目只需要 15 人 — 会被问每人投入多少人月
|
|
- ❌ 单位 ≥ 8 家, 分工不清 — 容易被砍掉冗余
|
|
- ❌ 关键单位的关键资质没体现: 比如做碳交易的项目,中碳登的"生态环境部唯一授权"是核心,不要漏写
|
|
- ❌ 项目负责人没主持过同级别项目 (国自然青年→面上 OK, 没承担过任何项目→评审打问号)
|
|
|
|
正确写法每人 200-400 字:
|
|
```
|
|
姓名 + 现职 + 学位
|
|
学术兼职 (1-2 个最相关的)
|
|
研究方向 (1 句, 与本项目对齐)
|
|
代表成果 (3-5 项, 论文/专利/项目)
|
|
**在本项目中承担 X 任务,提供 Y 支持** ← 必有
|
|
```
|
|
|
|
---
|
|
|
|
## 8. 文献雷区 (诚信问题)
|
|
|
|
- ❌ 编造文献作者/期刊/年份/DOI — 学术不端,可能撤项
|
|
- ❌ 文献全是 5 年前的 — 现状分析不可信
|
|
- ❌ 引文密度不均: 立项依据 30 篇, 其他章节 0 — 立项依据没读够
|
|
- ❌ 全是中文文献或全是英文文献 — 国内外现状分析做得不全
|
|
- ❌ 引用顺序乱 (顺序编码制要求按出现顺序编号)
|
|
|
|
正确做法: 让用户提供**真实文献清单**,你只负责按 GB/T 7714 排版。详见 `citation_gbt7714.md`。
|
|
|
|
---
|
|
|
|
## 9. 进度/里程碑踩雷
|
|
|
|
- ❌ 进度表只写"完成 XX 研究" — 看不出节点和交付物
|
|
- ❌ 中期目标和最终目标完全一样 — 中期指标必须是 50% 完成度
|
|
- ❌ 里程碑没有可验证的交付物 — 评审无法判断进度
|
|
- ❌ 关键里程碑都堆在最后 6 个月 — 风险过高
|
|
|
|
正确做法: 每个里程碑必须有
|
|
- 时间点 (绝对日期)
|
|
- 事件 (做了什么)
|
|
- 关键指标 (达到什么状态)
|
|
- 考核方式 (怎么验)
|
|
- 交付物 (具体的报告/软件/原型)
|
|
|
|
---
|
|
|
|
## 10. 组织/保障踩雷
|
|
|
|
- ❌ 复制粘贴 — 8 个课题写一样的"建立总体组+课题组" — 评审一眼看出
|
|
- ❌ 没说明协调机制具体频率 — "定期组织交流"不够,要写"每月 1 次进展通报 + 每季度交流"
|
|
- ❌ 风险分析全是套话 — "本项目可能存在技术风险" — 没用,要具体化
|
|
|
|
---
|
|
|
|
## 11. 形式审查清单 (递交前最后一遍)
|
|
|
|
- [ ] 项目名称与指南、申报书、立项批复一致
|
|
- [ ] 字体: 标题黑体四号 / 正文宋体小四 / 英文 Times New Roman / 行距 1.5 倍
|
|
- [ ] 不填的栏目用"无"标注,**没有空白**
|
|
- [ ] 缩略词第一次出现注明全称 + 英文原文
|
|
- [ ] 单位名称与公章一致
|
|
- [ ] 必要附件齐全 (合作协议盖章扫描、推荐函、伦理审查等)
|
|
- [ ] 总字数与各章节字数符合预算
|
|
- [ ] 引文按 GB/T 7714 顺序编码,文中 [N] 与文末参考文献对应
|
|
- [ ] 表格编号、图编号、公式编号连续无遗漏
|
|
- [ ] 经费表三个层级 (B1/B2/B3/B4) 数字对得上
|
|
- [ ] 课题任务书附 PDF 扫描签章件
|