回复 3# rgtest
学习了，以后知道该怎么做了，嘿嘿！
很有帮助，希望有更进一步的讲解啊{:3_385:}
意犹未尽 啊
发现原文不能编辑 只能在跟帖里再多说点个人看法了
1）一个paper只解决一个问题。我自己写paper时候也犯过这样的问题，一篇paper恨不得说n个topic，结果一个topic都没讲进去。
2）先写abstract和outline再写正文。说清楚你要解决的问题（objective），为什么要解决这样的问题（motivation），解决这问题的难度是什么（challenge），为什么你的方法可以很好的解决这个问题（contribution），然后才是你怎么解决这个问题的。千万不要先发实验结果摆出来，然后再前后凑上下文。你是作者，文章逻辑写的再乱，你自己回头看都是能读懂的。但是读者和reviewer不会是去花太多精力猜度你的逻辑你的心思的。
3）讲到算法讲到复杂逻辑的时候，多用和用好flowchart，比你洋洋洒洒一段要管用。
4）一般我review都是先看abstract，introduction，和conclusion。我碰到过3个section提到的东西都不一致的，给reviewer第一感觉就是“作者到底想说什么？？？” 你想这么review的结果会是什么？
5）综述部分引用文章，尽量多引Transaction的，一些很一般的conference就不要最好了。
6）分析实验结果时候多下功夫，能定量的就定量分析。同样是“5是不是大于的3”的问题，有的人只能写一句话，有的人能通过什么统计方法给你洋洋洒洒写一段。有时候不得不承认，技术文写作是bullshitting，但你想发高质量的期刊，这是必备的生存技能。举个小例子，你是写篇paper，propose一个optimization method去解决一个问题。仿真结果出来了，怎么去分析，怎么去突出你方法好是很有学问。千万别动不动就说“显然易见，什么什么”。你可以比较computation cost，你可以比较convergence rate，你可以比较fitness value。你可以比较的有很多很多，任何方法都是优缺点的，你挑对你有利的说，引领着reviewer和读者，让他们自然而然觉得你的方法牛。你方法缺点的部分你可以回避，或者在future work里说下。
谢谢指导
谢谢分享
谢谢楼主的建议，学到很多；
学习一下拉
很有用，以后注意了
太棒了，支持这种原创性的帖子！望楼主继续努力，确实很有用。
