Some notes about the proposal feedback. The direactor of the group reminds us that it is good to learn from the refused proposal, and I try to take some nots in this blog according to the feedback that is refused, and try to list some key points here.
从评审人的角度考虑的几个宏观问题
1 整个大的学科领域，是否值得资助研究，是否还是比较热的研究大方向。
2 小的细分领域，是否值得资助研究，有新的研究价值。
3 细分领域，有没有别人在做。没有的话就好说，有的话 ，你的特色是什么，跟别人不同的点。
4 你有没有能力按照所说的内容做出来。
5 怎么衡量你做出来的这个内容的效果。
如果这几个问题都能回答的比较好，或者超过平均的水平，这个proposal中的概率就比较大，前两个问题千万不要有硬伤，因为这个是比较客观的因素，如果入手点就选错了，后面再费劲也很难有好的结果。
Falsifiable scientific hypothesis
One question to answer in the proposal feedback is about the falsifiable hypothesis, if the proposal contanis the 可证伪的假说，and if this thing is valuable.
之前写paper的时候很少从这个角度考虑问题，似乎科学的理论，一般都是“可证伪、且未被证伪”的。
下面是网上的关于可证伪性的一些论述：
“不可证伪”其实就是那种“永远都不会错”的无赖逻辑。所以科学必须是可证伪的。注意，可证伪性并不等于已经证伪，也就是说，你不必真的去找黄色的树叶，也不必真的去找烧煤的恒星，“如果我能找到，那么你就错了”这就叫可证伪。
波普尔把“可证伪性”作为衡量一个理论“科学性”的标准——可证伪性越强，科学性就越强，没有可证伪性，就没有科学性。
创新性的表述
通常的创新性就是之前说的AMD，新的体系，方法，数据，场景等等，如果paper做出来了，contribution里面自然可以有很多的表述，比如性能，速度提升了多少，但是在写项目书的时候这些细节还没做出来，这些是一些类似的例子：
基本的思路是：将创新点分段、分层说明，以增强逻辑性和说服力：
背景描述：说明问题或现状。
创新性内容：突出你的核心方法或理论。
可能的影响：展望潜在成果和意义。
因为不可能是你自己说是创新，就是创新了，一定要有理有据。创新方式的表述可能有很多种，但是以下几种应该是比较常见的：
提出了新的方法或者理论
提出基于XXX的YYY新理论（理论上的创新）
当前的YYY研究主要采用AAA方法，但其在处理ZZZ问题时效率低下。本项目拟提出一种基于XXX的新理论框架，旨在提升对ZZZ问题的描述能力。初步理论分析表明，该框架具有更高的鲁棒性和适应性。
背景首先是说明针对的是什么什么问题，本问题提出了xxx方法框架，旨在提升xxx。初步的理论分析，该框架方法有xxx样的效果。
这种可能是难度比较高的，很具有原创性的创新，比如美好心灵电影里的Nash提出的博弈论这种程度类型，可能就属于原创的理论，应该是一般人很难做到的程度了，特别是理工科。
还有一种比如周志华老师提出的这种learnware学件的概念，有点类似于huggingface这种不同模型的组合，提出了一个大的概念之后，往往后续可以进行一系列的细致的探索，是一种很有开创性的工作。
在理工科的场景下，后面两种可能是比较常用的类型：
某种技术应用在了其他的场景
开发针对XXX问题的YYY工具，比如：
现有工具多针对AAA场景，难以适应复杂的BBB环境。本项目计划开发一款针对XXX问题的专用工具，通过YYY技术实现数据处理效率的显著提升，填补BBB场景工具的空白。
借鉴技术发展趋势 ，引用其他领域的技术趋势或新工具，表明这些技术在你的研究场景中具有潜在的创新应用价值。
示例：近年来，XXX技术在YYY领域展现出强大的潜力。然而，其在ZZZ场景中的应用尚未展开。本研究将首次尝试将XXX技术引入ZZZ领域，通过开发特定算法，实现对AAA问题的高效解决。
常见的就是已有方法使用了新的硬件计算架构，已有方法使用到了新的数据或者新的应用场景下等等，总之要想办法能说明一个”新”字，不管是从哪个角度的新，总之这个事情需要是一定程度上别人没有做过的事情。
强调已有方法在已有应用基础上的改进
即使没有完成实验，可以重点描述你的方法设计与现有方法的不同之处，突出它的潜在优势。
示例：本研究拟设计一种基于XXX的改进型算法，通过优化YYY计算流程，有望在ZZZ问题上实现性能提升。同时，该方法的模块化设计为进一步扩展到AAA领域提供了可能。
If the hypothesis can be assessed
One reason for refusal for our proposal is that it can not provide a solid evaluation approach. The reviewer said they don’t know how the thing we described can be assessed.
Maybe the thing that can be assessed follows the same pattern, such as “sth can improve the accuracy/save resource/improve the speed in how much” If the hypothesis does not follow this pattern in CS domain, it might not the right thing or proper description for the problem. You could also say that the approach is helpful for doing sth or facilitate the other things, but it is important to try to move another step, answering how this is helpful in quantitatively is important to make it be assessable.
However, it seems that in computer science or software engineering, the falsifiable is not that much relevent, see this question, I’m a little bit confused about it. Although some topics in cs is not fully relevent to the concept of falsifiable, at least, the clear metric about the assissibility and to show that the thing you work on is good, is critial section in proposal. (How to evaluate the presented approach, and how to refine the presented approach during the lifetime of the project)
Clearly, if you could not show to the reviewer if your things is good or not good, the reviewer will have no ideas and will give a refusal at last. Without this evaluation (or some prototype for the proof of concept), you can not show if the method or approach is doable.
Otherwise, reviewer might provide some senteces like:
The abstract goals are great, but the linkage to reality was too tenuous.
I was not able to really evaluate this with the level of specifics presented.
Scope, assumption and requirements
Two aspects
One aspect is to evaluate if your institution have enough ability to conduct this research, such as do you have enough device, background in related field and people to do that. Another is the quality of the proposal (the points mentioned above), the proposal will be approved when both of these two aspects are good.
Key questions
It might be easier to evaluate a proposal compared with wrting a proposal from scratch. I recently know some rules about evaluating the proposal, which is called Heilmeier’s Catechism there are all kinds of online resources about it, this is one official version. I put it here. When writing a proposal, just assume you are a reviewer and asking yourself about these questions back and forth. Just use these questions as a template to write the proposal or paper.
The first three are basically the necessary question for writting a paper.
What are trying to do can be used to convey ideas to someone in leadership position quickly. Typical way is three sentences template, 背措效, backgound, method, effects (such as how much speed or resource cost is improved/saved).
Second and third are usually related. The limitation of current works is the new things for your approach. The typical new aspect in cs comes from using new architecture, using new data, using existing approch in a new scenarios, and new method. The new is not the goal, the goal is to make things(targeted metric) better.
the subsequent ones are hard to answer, it is the question that are really important and motivate you from the pure research to the research that can make out sth useful, or deliver sth useful. Who cares and what difference will it make is really important.
关于科学问题的形式
这个很难有一个很精准的回答，自己也在不断学习的过程中，只能说大概什么不是科学问题，然后科学问题大致是什么样的。
明显不是科学问题的表述和思考方式：
提出了一个xx系统，实现了xx功能（工程项目里的功能指标）
提出了xx方法/算法/技术，或者优化策略，把某某指标提升了多少 (工程项目里的性能指标)
单纯地说某个研究方向不是科学问题
A现象为什么会发生，这个不是科学问题而是科普问题
带有科学问题特性的表述和思考方式：
在自然科学方面，最后的结尾是就是机制，机理之类的研究，在计算机软件应用这种偏向于工程的方面，典型的就是提出了一个模型，这个模型可以在某个条件下描述某一类问题。比如把尝试把当前遇到的问题抽象成一个数学问题，用这种思路去考虑。
具有一定的普适性，而不是仅仅能解决一个，两个很具体的问题
工程项目里性能提升到90%，那最后的10%可能需要科学问题的指导才能有所突破，科学问题的目的最后还是为了指导实践的，弄清楚了科学问题能更好地指导实践。（有点鸡生蛋蛋生鸡的感觉，好的工程实践的突破需要用到好的科学原理）
提出的这个需要能被证伪，也就是说在某个条件下是不成立的
提出的这个argument不是假说，或者是猜想，而是要能被证明的
对于当前的研究对象或者想要研究的内容，从科学原理，技术方法，产品落地，三个层面去划分。比如规模化试剂盒是一个产品，药物分子检测是一个技术，背后的机理是科学原理，就是说科学大概是不能直接产生经济效益的。
工程问题到科学问题的过渡
某个性能指标提升了-》为什么就能提升了，背后的机理，机制，模型是什么，是不是遵循什么规律，为什么会这样
还有一个需要注意的是：
第一步是问得对了，比提出一个算法，使得性能或者可扩展性提升了，这个时候需要问的是，影响当前算法的扩展性的核心因素是什么。这个时候大概问对了，但还是没有触及核心，核心就是再进一步思考，需要case by case 了，所以你问的这个科学问题还不能是在A场景也行，在B场景也行，这样就不是核心的科学问题了。
常见到的表述
AAA如何影响BBB （实际上就是数学模型里面的自变量和因变量）
AAA和BBB之间的关系 （实际上也是模型中自变量和因变量的关系）
如何构建xxx模型
xxx机制的研究 （实际上就是模型的核心研究点）
申请书的题目，尽量避免技术或者某某方法研究的表述？一说提出某某方法，就容易联想到工程问题上去。
xxx理论与方法研究
面向xxx的xxx研究
xx驱动的xx研究
具体可以参考《论技术科学》常读常新
一个整理科学问题的套路
提出一个问题（xxx场景下，哪种种方法、结构如果做xxx 能如何影响xxx表面因素的问题，就是提出一个结构和表象之间的关联问题）
提出一个科学假说（xxx 方法能够影响xxx因素）
提出一个验证这个假说的方法
AI时代一个梳理科学问题的套路
先看下整个流程，然后用AI工具比如gemini把整个的流程图都绘制出来，这个是从workflow的角度上或者是整个流程的角度上梳理的。然后就是从纵向的角度去梳理相关的问题，比如每一层具体需要怎么弄，难点是什么等等，一下就能说清楚的事情应该不是科学问题和真正需要集中力量攻克的地方。这个时候需要对着这个图好好梳理，凝练难点，不是从某个应用领域或者场景的角度，而是从CS的角度或者问题本身难点的角度去说。
图驱动的proposal撰写
比如新来一个proposal或者是paper撰写想概念的任务，开始的时候布置十字街这些文字，而是鲜花图，图画好了，内容也就串联起来了，比如30也左右的基金稳当，至少要有三个记住路线图，还有一个总的研究路线图，在拓展的就是从上到校的整体思路图，还有相关工作的背景图，最后可能的话再把自己的研究工作也整理成图的形式，这样这些图画好了，整个基金的内容也就撑起来了，写paper的话也是这样的思路了。先所一些预实验之后，就开始着手准备流程图了，然后同时想着exp部分要呈现出什么样的指标的图等等。
