项目前期是不支持移动端的适应，只支持PC和pad；
后期会添加对移动端的支持，
那么前期应该【如何规划好项目的CSS样式，便于维护】？
另外：
页面数量少于10个，有必要做一套符合自己项目的【bootstrap】一样的UI样式吗？
或是 根据PSD设计图从上到下一个一个写，能复用的就复用？
我现在是这样做的：
写一个公共样式（重置、全局样式、布局、字体样式、表单、按钮，颜色）+ 某页面特殊样式.css
感觉改起来很乱，因为有些不知道应该放在什么位置上。
我也在开发中遇到这个问题，下面是我的想法，仅供参考
首先，我觉得规划css的有个影响因素，就是网站的设计思路，如果网站是有一个整个的设计风格的话，规划的时候可以将模块的粒度适度放大。
结构拆分
- 基础框架：包含重置样式、栅格、css3动画模块，还是可以加上矢量图标库（iconfont）、辅助类
- 通用样式库： 基本的复用模块，如button、form、table等，这个设计的时候要注意复用性和维护性
- 业务样式：包含网站各页面之间的网站特有的样式，如导航、列表页、评论等
- 解决方案： 可以归纳一下常用的css问题，如兼容多浏览器的高度不固定的垂直水平居中、png透明图片支持等。。
代码规范
- 命名空间+模块化+语义命名，可以参考Amaze UI HTML/CSS 规范
- 兼容性列表：这个视业务需求而定了，如果逼格高一点，如ie8+基本和hack说再见了
- javascript组件：复杂的交互组件都是和javascript配合，建议公司内部有统一的规范，如果没有，可以参考业内的bootstrap、aralejs都可以
开发工具
现在通过预处理器开发样式很常见了吧，如果是node，就用stylus或者less，像est的样式工具库应该可以帮你提高效率哈
文档
文档不多说了，对于团队的维护性不言而喻，推荐一个专门用于css自动化文档工具 -- Hologram，不过依赖于ruby
业界参考
Semantic UI
顾名思义，语义化的css库，组件的划分我觉得可以参考一下哈
Amaze UI
中国首个开源 HTML5 跨屏前端框架，采用less编写,移动优先，文档很详细,建议仔细阅读，收获不少
bootstrap什么的就不用说了
挑选一个现有的成型的CSS规范
保持选择器命名规则一直被遵循
我们项目在开发之初，决定使用网易的NEC规范，因为这个规范对CSS选择器的命名规则做了很明确的划分。但是在开发过程中期到后期，很多页面元素是 需求变更 和 设计修改 时增加或变更的，这个时候团队中并不是每一个人都能够再去遵循我们之前选择的规范。还有一种情况，就是当开发人员对CSS选择器权重不了解时，样式被覆盖情况下就会瞎定义一些不知所云的选择器以避免被复写。
一旦这种情况出现，基本也就没什么可维护性可言了。
输出文档
这一点比较好理解了，如果没有文档，你能看明白Bootstrap预定义的选择器名字的意义吗？
CSS 编译器应该是你需要的。
在 Node 项目中我喜欢用 stylus。
在 Rails 项目中我喜欢用 sass。
其它项目里我喜欢用 less。
关于如何组织维护，确实看看 bootstrap 学习学习甚好，但在实际项目中，可能要根据自己的业务需求稍作调整吧。比如我其中的一个项目，代码如下：
@import "compass";
@import "compass/reset";
@import "config";
@import "global";
@import "header";
@import "footer";
// components
@import "components/type";
@import "components/form";
@import "components/btn";
@import "components/icon";
@import "components/table";
// modules
@import "modules/agree";
@import "modules/bank";
@import "modules/dialog";
@import "modules/divider";
@import "modules/diyselect";
@import "modules/hint";
@import "modules/jump";
@import "modules/protocal";
@import "modules/step";
@import "modules/subject";
@import "modules/tab";
@import "modules/text";
@import "modules/tipbox";
@import "modules/tiptext";
@import "modules/typelist";
@import "modules/title";
@import "modules/video";
// pages
@import "pages/account";
@import "pages/audit";
@import "pages/collect";
@import "pages/depository";
@import "pages/error";
@import "pages/faq";
@import "pages/mobile";
@import "pages/profile";
@import "pages/password";
项目地址
一般都是在满足需求中，慢慢建立自己的模块化结构。各种参考借鉴吧，没有最利于重构和维护的方案，只有适合你的项目和能力的方案。
另外，可以根据目前（2014-11-20）的前端状况制订自己的重构周期，我一般规划 2 个月的重构方案，这个重构周期是根据各项目的需求和我们团队能力制订的。
简而言之，你的目的是重构和维护，所以一定要用预处理工具，直接写CSS的话毛维护性都没有。
接下来就是拆，能拆就拆，能拆多细就拆多细。roshanca的做法就不错。