academic-project-summaries

name	academic-project-summaries
description	为科研、课题、基金、申报或项目管理场景撰写和压缩中文项目概述、项目描述、项目说明、摘要与简介。适用于有严格字数上限、固定格式（markdown/单段/分段）、学术表述要求，或需要从零散项目信息中提炼核心内容的任务。

学术项目概述与摘要撰写

概述

本技能用于把用户提供的项目信息压缩成高密度、学术风格、中文优先的项目概述文本。

目标不是机械改写，而是把原始信息整理为稳定的表达骨架，常见于：

• 基金/课题申报材料
• 项目简介、项目说明、项目摘要
• 汇报材料中的项目概述段落
• 需要严格字数控制的中文学术描述

优先处理三类约束：

1. 字数约束：如 100 字、200 字、255 字以内
2. 格式约束：单段、分段、markdown、指定标题
3. 语体约束：学术、正式、凝练、避免口语化

核心工作流

1. 先抽取，不急着写

先从用户材料中提取：

• 项目名称
• 研究对象/应用场景
• 核心问题或痛点
• 研究目标
• 主要研究内容或技术路线
• 创新点
• 预期成果/产出
• 应用价值或意义
• 明确限制：字数、语种、格式、受众

如果用户未显式提供某项，不要编造；仅可做低风险抽象归纳。

2. 组织成稳定骨架

通常使用以下压缩顺序：

背景/意义 → 目标 → 研究内容/方法 → 创新点 → 预期成果/价值

字数很紧时，优先保留：

目标 → 内容 → 创新/价值

3. 按字数预算分配信息密度

• ≤120字：只保留目标、核心内容、价值
• 121–255字：可加入背景或创新点，但每句只承载一个核心信息块
• >255字：可展开方法、成果、应用意义

4. 输出前检查

• 是否严格满足字数上限
• 是否覆盖用户最在意的信息点
• 是否存在无依据推断
• 是否符合要求的格式与语气

常用写作模板

模板A：单段压缩概述

适用于“255字以内、一段话、正式中文”。

本项目围绕【研究对象/问题】，针对【痛点/背景】，拟开展【核心研究内容】研究，重点突破【关键技术/关键机制】，形成【成果/方法/平台/模型】，以期实现【应用价值/科学意义】。

模板B：分段式项目说明

# 项目概述

## 研究目标
...

## 主要内容
...

## 创新与意义
...

模板C：极限字数版本

项目聚焦【对象】，围绕【目标】开展【内容】研究，拟解决【关键问题】，形成【成果】，服务于【应用/意义】。

255字以内中文项目概述

这是高频子场景，应作为本技能的固定子类型处理，而不是单独拆成微技能。

执行规则：

1. 默认写成一段话，除非用户要求分段
2. 优先覆盖：背景/目标/内容/创新/价值
3. 每句话避免并列堆砌太多名词
4. 如需保字数，先删修饰语，再删背景，再压缩成果表述
5. 如果用户指定 markdown，保留简洁标题即可，不要为了 markdown 增加冗余内容

输出格式建议

当用户只要正文

直接给出正文，不附加多余解释。

当用户需要交付格式

# 项目概述

[正文]

当用户明确要求字数证明

# 项目概述

[正文]

**字数：** X字

常见问题与处理

信息不足

如果关键事实不足以写出合格概述，应先指出缺口；不要把猜测当事实。

字数超限

压缩顺序：

1. 删除套话和形容词
2. 合并相近研究内容
3. 缩短背景
4. 将“预期成果+意义”合并为一句

格式冲突

若用户同时要求“极短”“很详细”“分三段”，优先满足：

1. 字数上限
2. 明确指定格式
3. 内容完整性

全文 Proposal 撰写（NBT/基金级）

当任务从"压缩摘要"扩展为"撰写完整 proposal"时，适用以下额外规则：

结构模型

用户偏好 NBT 级别的三段式结构（Platform → Strategy → Application），而非五个并列 aim：

1. Part 1: Platform design — 方法学创新（如双重幻想设计、跨模型复核），解决领域共性瓶颈
2. Part 2: Platform screening — 验证/筛选创新（如 ClpX 功能筛选），打通设计到实验的通量瓶颈
3. Part 3: Platform demonstration — 1-2 个强应用证明平台价值，ppGpp sensor 等辅助模块定位为 feedback readout 而非独立方向

国自然/重点项目“关键科学问题”两问式压缩规则

当用户已经把项目主线收束为两个核心问题，并要求“继续压成国自然/重点项目风格中文成稿”时，默认不要回到 review note 或提纲口吻，而要直接写成可提交的正式 prose。

执行规则：

1. 开头先用 1 段总述交代项目面对的共性瓶颈、技术切口与不同于传统路线之处。
2. 正文默认压成 两个关键科学问题，每问都用“问题背景 → 现有不足 → 本项目拟回答什么 → 该问题的科学实质”四步写成完整段落，而不是只给一句问句。
3. 如果项目属于平台型方法学，应把两问稳定收敛为两类接口：
   • 动态状态控制：例如生长—生产切换、氮状态、redox/ATP、应激状态的阶段化门控；
   • 空间组织控制：例如连续反应酶、调控节点、输入/输出节点的局部组织与扩散损失控制。
4. 语言上避免“我们想研究”“我们打算做”“能不能做出来”这类口语表达，优先使用“本项目拟回答/拟阐明/拟解决”。
5. 用户若未指定更长结构，默认同时附带两个复用层级：
   • 压缩版表述：适合直接放入“拟解决的关键科学问题”小节开头；
   • 一句话版本：适合摘要、图示总述或汇报标题页。
6. 当用户要求写入项目目录时，报告文件位置前必须先核对最终绝对路径已存在，避免把工作目录内的草稿误报为项目路径交付件。

科学思想 review 的写法

当用户要求“review 项目材料/with 科学思想”时，不要只润色措辞；要主动做结构性评议，并把结论写进交付件：

1. 先明确唯一主线，判断当前材料是否在讲“一个平台故事”还是“多个并列小方向”。
2. 明确旗舰应用，指出哪个系统最适合承担主生物学展示（如天然信号轴、能直接连接 growth–production trade-off 的系统）。
3. 明确辅助模块降级原则：传感器、readout、组学发现、验证模块若不能承担主因果链，应定位为 feedback/readout/supporting layer，而不是并列 aim。
4. 在文稿中显式写出当前最强卖点与最需要补的证据，尤其是 benchmark、消融、阴性对照、时间动态数据和边界条件。
5. 当用户已给出 story suggestion 时，优先按其主线重写，不要回退为平均分配篇幅的罗列式 proposal。

语言与痕迹规范

• 双语工作流：基金申报 / NSFC 用中文；manuscript / NBT 用英文
• 禁止内部痕迹：终稿必须读作独立提交文本，不得出现"从原项目材料梳理可见"、"原正文…整合如下"、"现整合如下"等装配痕迹
• 255 字中文摘要：严格字数控制，一段话，覆盖 背景→目标→内容→创新→价值
• 与源 PPT 完全同口径改写：当用户要求文稿与某个 PPT“完全同一口径”时，不做自由发挥式优化；必须严格对齐 PPT 的段落顺序、主线措辞、机制组件和示例层级。PPT 中点名的模块、元件、光控组件或结果数字（如 pMag/nMag、Top-5、KD 数值）应按原口径写入；若用户额外要求创新点“尽量用中文”，则创新点与总结段优先使用中文术语，仅保留不可替代的模型名、蛋白名、缩写和标准符号。
• 多文稿联动统一口径：当用户同时给出 proposal 正文、scientific thought summary、concept summary、汇报稿等多个相关文稿，并要求“统一改成和 PPT 完全同一口径”时，不能只改主文稿；应把标题、摘要主线、研究背景、研究思路、研究方案和创新点的层级与措辞同步到全部关联文稿，确保这些文件对外口径一致，而不是各自独立润色。
• PPT 口径 + DOCX 交付工作流：若用户在“按 PPT 完全同口径改写”之外还要求“输出为 docx”，应继续以 Markdown 为权威源文件完成统一改写，再导出一一对应的 DOCX；不要直接只改 Word。导出后至少校验关键锚点词是否保留在 DOCX 中，尤其是用户点名要求保留的机制组件、光控元件或监测模块（如 pMag、nMag、ppGpp 等）。
• 中文语音输入/口述转文字（STT）学术化纠错：原始口述笔记常带有严重的语音识别同音字错误或口语表述，必须无条件修正为精准的学术与控制论术语。典型案例如：
  • “街道 / narL街道” $\rightarrow$ “介导 / NarL介导”（jiè dǎo / jiē dào 语音偏误）
  • “幻想” $\rightarrow$ “幻想算法/幻觉算法（Hallucination Algorithms）”
  • “传感器/感应器” $\rightarrow$ 需根据控制系统定位微调。如介观监测层应表述为“报警素 ppGpp 实时检测感应器元件”以明确其作为无损、实时荧光 readout 的监测定位，而非直接重构控制回路。
  • “调控” $\rightarrow$ 宏观控制层应表述为“NarL 介导的全局转录与代谢过程调控元件设计（基于 His–Asp 双组分系统磷酸转移的邻近门控）”以突出邻近控制与系统级优化机制。
• 每句话只承载一个核心信息块，避免并列堆砌名词
• 压缩顺序：删套话/形容词 → 合并近义内容 → 缩短背景 → 合并成果+意义

正式申报语体与主线保全（高优先级）

当用户明确要求“用官方语言形式”“不要太多口语化/思想战线的表述”时，必须把文本整体收紧为正式申报书语体，而不是只做轻度润色。

执行规则：

1. 采用客观、正式、学术化表述，避免使用“完整故事”“换句话说”“这样做的目的”“我们现在应该”“不是……而是……”等带有解释口吻、对话痕迹或动员色彩的句式。
2. 若用户说明某些学者或团队（如 Liming Liu、Sang Yup Lee）只是背景方向指示，则应将其整合为一个紧凑的“研究背景与方向依据”板块，用于说明研究基础、问题来源和执行方向；不要让这些外部路线取代项目自身主线。
3. 当用户已经明确项目主线时，必须原样保留其链式结构，并作为正文骨架展开：生产过程问题 → 新的 de novo design 方法 → 新建的筛选/验证方法 → 执行层 → 提高产量 → 形成新的合成生物学方法。不得在压缩过程中丢失“筛选验证方法”或“产量验证终点”两个关键层。
4. 当用户删除某一执行轴或模块时，正式稿中默认采用正向写法，只陈述保留的结构与应用形式，不反复写“也不再保留 X”“不再依赖 X”等历史说明，除非用户明确要求比较版本演化。
5. 对基金/重点项目/课题申报类文本，优先使用“本项目拟……”“相关研究表明……”“基于此……”“据此形成……”等书面句式，使文本读起来像独立提交稿，而不是内部讨论稿或修改说明。

方法学对比交付

当用户需要优缺点总结时，使用以下骨架：

## 总体判断
一句话总体定位。

## 一、方法A的主要缺点
## 二、方法B的主要缺点
## 三、共同局限
## 四、压缩版总结
## 五、一句话结论

执行要点：先给总体判断，不堆细节；缺点写成学术限制而非情绪否定；区分单类缺点与共同局限。

Gap 分析 / 参数对比

用户重视 gap-analysis、change-summary 和参数比较表格，需同时呈现支持性证据与边界条件对比。实验方案中每个关键 claim 应有对应的定量验证设计（如 benchmark、消融实验、阳性/阴性对照矩阵）。

新方法写作：必须显式展开 evidence clue chain

当用户要求把“新方法”“新平台”“新筛选体系”写得更像高分期刊或高水平 proposal 时，不能停留在“将进行验证”“将设置对照”“将比较现有方法”这类泛化措辞，必须主动展开成可审查的证据链。

执行规则：

1. 默认把“新方法成立”拆成至少四层，优先顺序为：benchmark → 候选压缩/富集 → ablation → control matrix → function bridge / 终点闭环。
2. benchmark 不能只写“与现有方法比较”，要点名比较维度，如时间、算力、throughput、命中率、阳性富集倍数、后续部署保留率。
3. 对平台型方法，必须回答“为什么这不是工具拼盘”，因此默认加入关键步骤消融比较。
4. 对筛选方法，必须回答“为什么 readout 不是 surrogate artifact”，因此默认加入 readout 与独立结合参数、后续功能保留率或终点表型的桥接证据。
5. 对执行层方法，必须回答“为什么效应不是非特异负担”，因此默认写完整阳性/阴性对照矩阵，而不是只写“设置对照组”。
6. 对完整 proposal，收束层应加入跨尺度总证据链，例如“计算候选质量提升 → 筛选富集 → 执行层因果成立 → 生产终点受益”。
7. 如需快速调用固定写法，参见新增参考文件 references/method-evidence-chain-for-proposals.md。

执行层/调控层写作加硬规则（高频修正）

当用户指出“执行形式太虚”“缺少具体调控内容”“没有写清楚怎么调、为什么这么调、什么结果才算证明成立”时，必须把执行层段落从概念说明改写为硬方案，而不是继续抽象解释。

执行规则：

1. 对每个执行模块，按固定顺序写成完整 prose：
   • 为什么选这个调控轴/节点；
   • 具体调控什么分子事件；
   • 怎么调控（binder、近邻、linker、时序、诱导方式）；
   • 这样调控的目的是什么；
   • 应出现什么结果模式才算证明机制成立。
2. 对动态调控模块，默认要写清“什么时候启动调控”。若存在生长—生产切换，优先采用“生长前期低干预、生产窗口激活”的时序表述，并说明这样做是为了避免生物量阶段的代谢负担与背景泄漏。
3. 对状态轴优选，不要只说“更合理”或“更符合文献”，必须把原因落到主因果链上，例如：该轴是否直接连接 nitrogen-state sensing、Gln/Glu pool、核心 reporter、执行节点和产量终点。
4. 对执行层证实，必须写出“结果模式”，而不是只列 readout 名称。优先写成多层一致结构，例如：状态 readout 改变 → 执行节点改变 → 代谢池/同位素流改变 → 终点产量改善。
5. 对酶邻近模块，必须区分“真实邻近效应”与“简单共表达效应”，正文中默认加入几何构型对照、表达对照、功能对照，并说明期望看到“局部中间体变化 → 酶功能变化 → 终点收益变化”的三级结果模式。
6. 当用户已有前期 mimic / virtual metabolism / proxy 结果时，默认将其降级为“模块优先级与验证顺序的前期支持”，不得把 mimic 写成方法成立的硬证据。正式方案中的主证明必须回到实验级 readout、对照矩阵、时间过程和因果链。
7. 若用户明确要求 proposal 更硬，优先删去“可比较候选”“有望”“可能提供路径”等软句，改写为“本项目拟调控……”“其直接目的是……”“若该模块成立，预期应首先观察到……”这类带判定逻辑的句式。

将行业白皮书/市场报告整合进 proposal 背景

当用户提供行业白皮书、市场研究、政策报告或产业地图类材料，并要求“作为研究背景加入 proposal”时，优先把这些内容整合到立项依据 / 研究背景 / 研究意义部分，而不是打散到研究内容、技术路线或创新点里。

执行规则：

1. 先提炼该报告的产业链结构、赛道分类、平台化趋势、中国与海外差距、政策/资本/园区集聚等高层结论。
2. 只保留能服务本项目定位的背景信息，不要把行业报告变成大段资料搬运。
3. 必须把产业背景重新收束回用户项目：回答“这份产业背景为什么说明当前迫切需要这个平台/方法/模块”。
4. 对平台型项目，优先使用“单点产品竞争 → 平台效率竞争”“单技术突破 → 设计-构建-测试-学习闭环能力”这类转折句，把行业背景自然引到方法学必要性。
5. 如果项目本身是平台叙事，行业报告内容应强化平台定位，而不是引入新的并列方向。
6. 相关表述应读起来像正式申报书背景综述，而不是书评或读书笔记。

NBT 平台故事打磨规则（新增高优先级）

当用户要求“往 NBT 级别 story 打磨”“不是把 story 写顺，而是 sharpen platform line”“根据 critique 优化”时，必须按以下顺序重写，而不是平均分配篇幅给多个方向：

1. 先写一句话总评：点明当前 story 的最大短板，通常从“平台主线不够锋利 / 生物学应用分散 / 技术优势尚未被定量证明”三类中判断。
2. 立刻提炼唯一主线句，格式优先为：我们建立了一个[方法平台]，并通过[验证/筛选引擎]把计算设计转化为可验证的细胞内模块，最终用于[旗舰应用场景]。
3. 明确采用三段式结构：
   • Part 1: Platform design
   • Part 2: Platform screening
   • Part 3: Platform demonstration 不要回退为五个并列 aim。
4. 必须指定一个旗舰应用承担主生物学展示；若存在天然信号轴、能直接连接 growth–production trade-off 的系统（如 NarQ–NarL），优先提升为主应用。
5. 传感器、readout、组学发现模块如果不能承担主因果链，必须明确降级为 feedback/readout module，而不是并列主方向。常见写法：X sensor 不是独立项目，而是贯穿平台部署层的 feedback readout。
6. 每一部分都要显式拆成三类内容：
   • 这一部分已经强的地方
   • 这一部分还弱在哪里
   • 必须补的关键证据
7. 对 NBT 级平台稿，必须主动要求并列出以下定量证据包（按模块选择）：
   • 设计层：compute time、candidate diversity、cross-model consistency、wet-lab hit rate、ablation
   • 筛选层：throughput、cost advantage、enrichment fold、linker/mechanism controls、orthogonal assay correlation
   • 应用层：因果节点、mutant controls、time-course、dynamic vs static comparison、boundary-condition analysis
   • 反馈层：dynamic range、specificity、response speed、orthogonal correlation
8. 结尾必须给出NBT 级别判断，区分：
   • 当前更像强 proposal / 高潜力平台雏形
   • 还缺哪些闭环才够冲 NBT 并明确最强卖点不是模块数量，而是是否改变别人做 binder engineering 的方式。
9. 对此类任务，输出中优先保留一个最强最终一句话，作为摘要、图注、汇报和题目锚点。

学术思想 summary / 科学思想摘要（proposal review 高优先级子型）

当用户要求“review 某个 proposal / 项目文稿，并写一个学术思想 summary / 科学思想摘要 / scientific thought summary”时，不要把任务降级成普通摘要，也不要只做措辞润色。应把它视为对项目主线、平台逻辑、学术定位与证据缺口的结构性提炼。

执行规则：

1. 先读目标文稿本身，再补读同目录下最相关的上下文材料（如 scientific thought、story optimized、core method positioning、review note 等）。不要脱离项目语境写成泛泛概述。
2. 默认交付应为独立、可直接引用的中文 markdown 文件，保存在同一项目目录中，文件名优先使用：<原文件名>_scientific_thought_summary.md。
3. 正文建议使用以下稳定骨架：
   • 总体判断
   • 核心学术思想（3–4 个递进层）
   • 在当前项目语境中的最佳主线
   • 学术定位与潜在贡献
   • 当前最需要补强的学术证据
   • 压缩版学术思想总结
   • 最终一句话
4. “学术思想”要回答的不是“这篇文稿写了什么”，而是：
   • 这个项目真正要解决的共性问题是什么
   • 方法学主张是什么
   • 平台主线如何收束
   • 哪个应用应是旗舰应用
   • 哪个模块应降级为 feedback/readout/supporting layer
   • 最强 claim 与最缺证据分别是什么
5. 输出语言必须读起来像正式 proposal 评议或项目思想提炼，不得出现“根据上文”“从这次对话可见”“现整合如下”等装配痕迹。
6. 若项目属于 NBT 平台叙事，优先把总结写成“平台科学”而非“单点工具优化”：强调它是否把研究对象从单个模块推进为可设计、可筛选、可部署、可监测的系统平台。
7. 明确区分“学术思想摘要”和“概念性凝练摘要”：前者保留 proposal review / 学术评议口吻，强调总体判断、主线收束、学术定位与证据缺口；后者可进一步压缩为概念主线与价值判断。若用户要求在已有“学术思想摘要”基础上“继续凝练”，默认是在保留学术判断框架的前提下压缩，而不是自动改写成纯概念摘要。

将“学术思想/概念摘要”改写为正式稿件（新增高频子型）

当用户要求把已有“学术思想摘要 / 概念集成摘要 / story note”直接改成正式稿件语气与内容时，不要停留在“评议稿润色”层面，而要把文本整体改写为可直接进入 proposal、汇报正文或正式项目摘要的成稿。

执行规则：

1. 先判断原文是否属于“内部分析稿”。典型信号包括：
   • “更准确的表述应当是”
   • “更适合被写为”
   • “当前版本中”
   • “换言之”
   • “这样表述的好处在于” 这类句子在正式稿中应整体删除或改写为客观陈述。
2. 将“评议性标题”改为“正式标题”。例如：
   • “学术思想与概念集成摘要” → “项目学术定位与研究方案摘要”
   • “总体学术判断” → “项目总体定位”
3. 把原文中的“判断/建议/更适合如何写”统一改成直接陈述项目内容本身，避免让正文看起来像在讨论写法。
4. 保留状态边界：
   • 已完成的方法学与实验验证，要用完成时态和肯定表述；
   • 应用层初步方向，要保持审慎，不夸大为已闭环完成的机制结论。
5. 将条目式“论证笔记”改写为连续学术 prose；但涉及 pipeline、阶段顺序、对照关系时，仍要保留明确结构，不可为了流畅性牺牲方法语义。
6. 用户若未要求极限压缩，正式稿优先采用以下结构：
   • 项目总体定位
   • 已完成的方法学基础
   • 应用层研究方向与实施路径
   • 学术定位与创新性
   • 下一步研究重点与关键证据链
   • 一句话项目概括
7. 终稿必须读起来像独立提交文本，而不是“对原稿的说明”或“review note 的整理版”。

参考文件

• references/user-proposal-conventions.md：用户偏好、格式规范、已知 workflow 细节
• references/nbt-platform-story-sharpening.md：NBT 平台故事打磨清单、旗舰应用/反馈模块降级原则、必补证据包
• references/industry-report-to-proposal-background.md：如何将产业白皮书/市场报告/政策材料压缩整合进 proposal 背景

方法学对比 / 缺点总结型交付

当用户不是要“项目概述”，而是要对一类方法、路线或技术做优缺点总结、对比归纳、局限性综述时，也可使用本技能的压缩写法，尤其适合中文 markdown 交付。

推荐骨架：

# 标题

## 总体判断
一句话给出该方法族的总体定位：更擅长生成、筛选、验证还是决策。

## 一、方法A的主要缺点
### 1. ...
### 2. ...

## 二、方法B的主要缺点
### 1. ...
### 2. ...

## 三、共同局限
### 1. ...
### 2. ...

## 四、可直接引用的压缩版总结
[1段可粘贴正文]

## 五、一句话结论
[适合图注/汇报/摘要]

执行要点：

1. 先给总体判断，不要一上来堆细节。
2. 对“缺点”要写成学术限制，避免情绪化否定。
3. 区分“单类方法自身缺点”和“几类方法共同局限”。
4. 收尾时给一个压缩版总结，方便用户直接粘贴到方案、论文或汇报中。
5. 若用户要求写入 markdown 文件，正文应保持可独立阅读，不要加入对话痕迹或装配说明。

可复用支持文件

• references/255-char-chinese-project-summary.md：255字以内中文项目概述的专用说明与示例

相关技能

• scientific-writing
• academic-revision-specialist
• literature-review