先写个大纲看看显示效果

README.md

-# 项目规范和管理
+# 项目规范和要求
 
+本文件用于规范所有项目成员的开发行为，并在一定程度上保障项目的代码质量。
+本文件规定了在项目开发中，代码应该怎么写，不能怎么写，以及部分规范在什么情况下可以例外。
+除了本文件中规定的所有规范以外，在部分项目中还有各自独立的规范要求和约定。在项目规范和本规范有冲突时，以具体项目规范为准。
+
+## 基本目标
+
+本规范期望达到的目标有以下几个
+* 让项目易于维护
+  通过统一的代码规范和约定，让项目代码变得更容易阅读。让任何一个具备相关知识的开发者都能够在尽可能短的时间内上手进行基本的开发和修改。
+* 控制代码质量
+  通过强制性的代码规范和约定，避免一些容易出现在开发中的影响到代码质量的问题。
+* 降低部署风险
+  通过执行代码规范和约定，来降低从测试到部署的过程中出现问题的风险。
+
+## 项目代码编写原则
+
+每个项目参与者在进行项目开发时，都应该尽其所能的遵守以下几个原则
+### 开始开发前
+  * 不要立即动手
+    拿到需求后不要马上进行编码。先进行思考并和产品沟通，**确保自己确实理解了需求，并对整个流程了然于胸之后，再动手**。
+  * 先进行询问和检索
+    在进行开发之前，先了解一下想要的东西是不是已经有了类似的实现，或者干脆就不需要实现。**避免让开发变成重复造车轮**。
+### 开发过程中
+  * 随时注意自己的编码是否易读
+    尽可能的做到**每一行代码都能让人一眼看懂**，而不需要花费额外的时间去理解。
+  * 随时注意自己的脚本和函数是否功能单一而且明确
+    如果需要实现复杂的逻辑，就将其拆成多个简单功能来调用。**确保每个函数的功能能用一句话说清楚**。
+  * 随时注意避免代码过度耦合
+    避免重复造车轮，最关键的就是在制造车轮的时候考虑到**让其他人也能使用**。
+  * 随时注意代码长度是否过长
+    如果是单个函数代码过长，考虑拆成几个子函数；如果是单个文件过长，考虑拆成多个文件；单个模块文件太多的，考虑建立一个子目录来存放文件。
+### 开发完成后
+  * 至少完成一次代码自审
+    在代码完成之后，**必须重新审查一遍**。以便于补充注释，修改错漏，删除多余的打印输出。
+  * 上传之前必须进行检查
+    每次推送代码到服务器之前，先确认当前代码能否**正常**运行，确认之后才能上传。
+  * 每次提交都要明确的说明修改了什么
+    除了合并代码以外，在提交的时候应该明确的说明自己这次的提交修改的内容。**不要在提交的时候随意编写毫无意义的提交说明**
+
+**以上要求可能会随时增加，请随时关注本规范的最新版本**
+
+## 代码规范
+
+## 注释规范
+
+## 版本管理规范
\ No newline at end of file