简介：这是一份互联网+大学生创新创业大赛项目计划书范例，面向准备参赛的高校学生团队，可作为撰写计划书的参考蓝本。其原型项目聚焦服装搭配APP，围绕网上购衣难以预览效果、搭配知识不足等痛点，完整呈现项目概述、产品技术、市场分析、发展战略、商业模式和团队分工等核心章节，示范了从创意到商业逻辑的完整表达。资源共1个docx文档，大小15KB，内容精简，便于直接编辑或改造。目前已有13060人浏览学习，经过大量用户检验。参考后可快速掌握计划书结构，并借鉴3D建模、用户数据采集、电商导购等具体写法和运营思路，有效节省备赛成本。
1. 4页范例在互联网+大赛里到底卡在哪
“互联网+大学生创新创业大赛”里最容易被高估的材料是 20 页长报告，最容易被低估的是这份 4 页的项目计划书范例。网评阶段评委不会逐行读材料，一份 4 页文档平均停留时间只有 90 秒左右，他要在脑子里快速回答三个问题：你做的是什么事，为什么是你做，往后能不能落地。页数一旦锁死，写作就从“把事说完”变成“做信息取舍”，这也是 4 页比 20 页难写的原因。这里不讲怎么堆理由和奖状，而是从共 4 页的 DOCX 范例出发，讲清楚计划书的内核结构、限页写作方法、Word 排版控制，以及交稿前的自检动作，适合正在备赛、替团队写文本，或者把路演材料转成网评文档的同学。
2. 先把内核立住：4页计划书的七个模块与评审视角
计划书排版再漂亮，内核乱了也没用。写 4 页计划书时，必须先接住评审视角，把“我们有个想法”翻译成“这是一个可推进的项目”。
2.1 网评在90秒里找的三个答案
评审翻到你的页面前，先看项目名称和摘要，接着快速扫整个页面结构。所以写 4 页时，应该默认对方不会读完整段，只会找三个答案：第一，需求是否具体，用户场景在哪；第二，解决方案是否有技术或模式上的差异；第三，团队和进度是否让结果可信。
这决定了四个页面的信息布局：把痛点放前面，把解决方案放中间，把可执行性放最后。反过来，如果第一页放满荣誉和学校名称，评委就得再花一次跳转成本去找重点。4 页计划书最怕的就是“看完第一页还不知道你要干什么”。
2.2 七个模块排在4页里，先过一遍“信息密度”检查
4 页不是七个章节平均分配，而是按评审想看到的东西分配。我常用的方式是把计划书拆成七个模块，用一张表控制每块的页数权重：
| 模块 | 建议占位 | 评审想看到什么 | 常见败笔 |
|---|---|---|---|
| 市场痛点 | 半页 | 具体场景、真实用户 | 抄行业报告，没有画面 |
| 解决方案 | 1页 | 技术/服务怎么运作 | 只写功能清单 |
| 创新点 | 半页 | 与现状相比差异在哪 | “首创”没有对照 |
| 团队 | 半页 | 能力与项目匹配 | 全是title没有分工 |
| 实施路径 | 半页 | 节奏是否可信 | 只写“完成产品” |
| 商业模式 | 半页 | 怎么持续运作 | 每一项都写免费 |
| 财务与风险 | 半页 | 算过账、有边界感 | 收支全是拍脑袋 |
这张表本身就是一份写作骨架。写的时候我把每个模块先提炼成一句“评审想看的答案”，再展开成段落。如果你发现某一模块没法用一句话回答，那就说明信息密度不够，宁可删掉也不要硬扩成半页。
为了便于团队协作，我会把同样的模块结构写成一个 JSON 配置，交给负责整理资料的成员对照填充：
[ {"module": "market", "page": 0.5, "core_answer": "谁在哪个场景下痛", "forbidden": "写趋势不写人"}, {"module": "solution", "page": 1.0, "core_answer": "用什么方式解决", "forbidden": "堆功能不讲流程"}, {"module": "innovation", "page": 0.5, "core_answer": "和现状比差异在哪", "forbidden": "自封首创"}, {"module": "team", "page": 0.5, "core_answer": "为什么你们能做", "forbidden": "只写职务不写能力"}, {"module": "roadmap", "page": 0.5, "core_answer": "未来半年怎么走", "forbidden": "只有里程碑没有验证"}, {"module": "business", "page": 0.5, "core_answer": "钱从哪来、怎么闭环", "forbidden": "什么都免费"}, {"module": "finance", "page": 0.5, "core_answer": "成本结构合理", "forbidden": "只看收入不看支出"} ]这份配置不是拿去给评审看的，而是给队友分工时用的。它反映一个原则：页数越少，越要先锁死每个模块的“核心回答”，再让每个人用自己的话往里填。如果某一段字数超了，优先回头改这一句 core_answer，而不是删段落里的某句话，这样才不会越删越散。
2.3 一句话定位：计划书里所有段落的校准线
七个模块写完后，我会把整个项目压缩成一句话，贴在文档顶部或项目背景第一段里。这句话的公式是：
【目标用户】在【具体场景】下遇到【痛点】， 【我们】用【技术/资源】把【关键指标】从 A 变成 B。写成示例就是：高校实验室设备管理场景下，我们用智能排班与 RFID 标签结合，把设备闲置率从 38% 降到 12%。这句话一旦成立，后面写解决方案和财务时都往它上面靠；如果写完解决方案感觉不像同一个项目，基本就是这句话没立住。
这句话还有一个用法：打印出 4 页初稿，只读每段首句。如果首句连不起来，说明段落之间的逻辑断了。这是 4 页写作里最便宜的质量检查。
3. 限页数的极限取舍：哪个模块写多少字、哪些信息用表格承载
4 页最忌讳的是每一页都想塞满。页数限制不只是“少写点”，而是要重新设计信息载体：文字、表格、图示各分担多少。这一章给出可复制的操作路径。
3.1 四页黄金结构：先把“页”定好，再往页里填字
拿到空白页先别写，打开 Word，先用结构占位。按我的习惯，四页分配是这样的：
| 页码 | 内容 | 控制在 | 页面作用 |
|---|---|---|---|
| 第1页 | 项目名称、痛点、一句话定位 | 半版文字 | 让评委确认“这项目值得看” |
| 第2页 | 解决方案、技术流程、创新点 | 1版 | 让评委确认“有差异” |
| 第3页 | 团队、实施路径、商业模式 | 1版 | 让评委确认“你们能执行” |
| 第4页 | 财务、风险、联系方式 | 1版 | 让评委确认“算过账” |
为了避免写过头，我通常会给自己定一个字数预算：第一页不超过 350 字，第二页不超过 600 字，第三页不超过 500 字，第四页不超过 400 字。这样即便加上标题、表格、图片，整体内容也不会超过 4 页。
预算怎么定？先写完初稿，统计每页字数，把超出的部分强行“降级”成表格或图片。例如团队部分，不要用大段文字写每个人“性格开朗、热爱创新”，而是用一张表列出成员、专业、负责模块、匹配理由。表格一行能说清的事情，绝不用三行句子。
3.2 用 Markdown 起草、pandoc 出 DOCX
写作阶段我一般不会直接在 Word 里敲，而是先用 Markdown 起草，再用 pandoc 转成 DOCX。这样最大的好处是：结构调整的代价低，转格式后全文可以统一沿用一套 Word 样式，不会出现“这页黑体、那页仿宋”的情况。
经常使用的一行转换命令如下：
pandoc plan.md \ --reference-doc=plan-ref.docx \ --toc \ --toc-depth=2 \ --resource-path=./assets \ -o plan.docx这里有几个参数的实际含义：--reference-doc指定一个 Word 模板文件，pandoc 会读取这个模板里的标题、正文字体和页边距，输出就有了统一样式；--toc表示生成目录，4 页文档可以不要，但如果学校要求目录，就先留出半页；--resource-path指图片所在目录，写在 Markdown 里的图片路径相对这个目录找。转出来的 DOCX 基本能达到“能交稿”的程度，之后再微调页码就够了。
提示：
--reference-doc只需第一次准备完整。把它放进团队共享目录，所有人用同一份模板，导出格式就不会各改各的。
这一步通常容易踩两个坑：一是 Markdown 里用了|表格，但列数不一致，pandoc 会直接把它当普通文本；二是图片路径含有空格，转换时显示链接破损。写 Markdown 时就别在文件名里留空格，我统一用英文文件名加短横线，例如architecture-flow.png。
3.3 文字降级成表格：计划阶段就标好“载体类型”
在 Markdown 里写每部分之前，我会先在标题下标一个小记号：[表]表示这段用表格承载，[图]表示放示意图，没有标记的才写长段落。这个标记对后续生成 DOCX 特别有用，因为表格和图片在 Word 里能快速成为视觉锚点，而纯文字段落会被扫读跳过。
最常见的写法是：商业模式部分用一张“成本项—收入项—来源”表；实施路径用一张阶段表：时间、阶段、里程碑、验证方式。页面放不下时，优先删掉过渡性质的句子，保留结论。这种取舍比“删字”更接近结构层面的压缩。
4. 用 Word 排版把 4 页范例做成“一页一屏”：样式、行距、配图三件套
一份 4 页项目计划书能不能让评委顺利看完，排版占一半。这里的排版目标不是花哨，而是“一页一屏”：评委无论用屏幕还是打印版，都能在一屏里看到完整层次，不需要来回拖动。
4.1 评委扫读会看的四个锚点
人眼扫读页面时不会均匀阅读，四个位置决定留不留下：
第一是页面顶部的大标题和副标题，要能看到“项目名—关键领域—一句话价值”。第二是每个模块的段首句，所以首句必须是结论。第三是图片和表格的图注与表头，要让评委光看图注就能知道这张图提供了什么事实。第四是加粗关键词，比如数字、比例、外部合作单位，一眼能看到差异。
这意味着 4 页排版不是做完文字再加粗，而是在每个页面底部问自己：这一页在不滚动鼠标的前提下，能不能看到完整结论？如果不能，就减少信息密度，而不是缩小字号。
4.2 用 python-docx 统一样式，避免手滑
直接手动设置 Word 样式容易漏掉某个标题。我会在生成 docx 后，用一个小脚本再刷一遍全部样式，保证页边距、正文字号、行距统一。
from docx import Document from docx.shared import Pt, Cm from docx.oxml.ns import qn doc = Document("plan.docx") # 统一页边距：A4，上下2.5cm，左右2.8cm for section in doc.sections: section.page_height = Cm(29.7) section.page_width = Cm(21.0) section.top_margin = Cm(2.5) section.bottom_margin = Cm(2.5) section.left_margin = Cm(2.8) section.right_margin = Cm(2.8) # 统一正文样式：西文Times New Roman，中文宋体，小四号 normal = doc.styles["Normal"] normal.font.name = "Times New Roman" normal.font.size = Pt(12) rpr = normal.element.get_or_add_rPr() rfonts = rpr.get_or_add_rFonts() rfonts.set(qn("w:eastAsia"), "宋体") # 一级标题：Arial，16磅，控制段前段后 h1 = doc.styles["Heading 1"] h1.font.name = "Arial" h1.font.size = Pt(16) h1.paragraph_format.space_before = Pt(12) h1.paragraph_format.space_after = Pt(6) doc.save("plan-styled.docx")参数说明：qn("w:eastAsia")必须设置，否则中文字体不会随font.name改变；top_margin左右边距按 cm 控制，边距过窄容易显得版心太满，边距过宽会让 4 页内容放不下；Pt(12)即小四号字，是网评材料里比较稳的正文字号。行距我一般不在脚本里设，而是放到 Word 模板里统一调整，避免同一段出现 1.2 倍和 1.5 倍混用的样子。
4.3 页面安全：跨 Word/WPS 打开不散架
很多团队会在 Windows 上排好，到交稿前用学校机房或 WPS 打开，结果分页乱了。常见原因主要分三类，我一般用一张表列给队友自查：
| 问题 | 原因 | 调整动作 |
|---|---|---|
| 页码跑到页脚之外 | 有分节符混用 | 删除多余分节符，统一用“下一页分节符” |
| 图片跨页断裂 | 图片不跟随段落 | 图片设为“嵌入型”或“浮于文字上方” |
| 表格行被切断 | 表格行跨页显示 | 表格行属性里关闭“允许跨页断行” |
| 字体变样 | 缺字体或中文字体不匹配 | 用宋体/Times New Roman，不依赖生僻字体 |
这个检查动作不需要重排，只要在交付文档前另存一份 DOCX，再另存一份 PDF。在 PDF 里确认每一页边界，能发现大多数排版问题。4 页计划书追求的不是设计感，而是稳定；一个表格断在页尾，评委就很容易判成“内容没排版好”。
5. 交稿前10分钟的自检动作：把4页范例拧成一张牌
最后一套动作可以直接照着做，把 4 页计划书当成一张牌来检查，而不是当成一篇文章来读。
5.1 先用命令行把 DOCX 转成 PDF 看真实页数
我习惯在交付前用 LibreOffice 把 DOCX 转成 PDF，看一眼真实页数到底是 4 页还是 6 页：
soffice --headless --convert-to pdf plan-final.docx python -c "import pypdf; print(len(pypdf.PdfReader('plan-final.pdf').pages))"如果打印出的页数不是 4，说明前面哪个模块超了预算，而不是 Word 的显示欺骗了你的眼睛。用 PDF 页数作为最终裁决，比在 Word 里反复滚动靠谱。
5.2 三遍自读法：标题、图表、数字
第一遍只读每页的标题和首句，确认它们一句话能连成项目主线；第二遍只看图和表格，确认每个图表都有表头，且能独立说明一个事实；第三遍只看数字，把全文所有百分比和使用量全部列在一起，凡是没有来源的都在交稿前补上“预估”或“据团队调研”的限定词。三遍读完大概只需要 5 分钟，但能筛掉大部分逻辑断层。
5.3 最终命名与提交动作
最后一步是文件名。不要用“未命名文档.docx”或“修改4稿—真最终版.docx”，我一直用下面这个格式作为收尾：
团队名称-项目名称-网评版-v1.0.docx提交到系统时再把“docx”和“pdf”一起上传；如果平台只收 docx，就把 PDF 版转成图片附在最后一页，方便评委无损查看。完成这个动作后，双击打开第一页，把鼠标停在项目名称上，想一下评委在你这一页停留的前 5 秒先看哪里——这个动作比再改十版都值钱。
本文还有配套的精品资源，点击获取
