企业官网建设流程全解析

黑客松最动人的部分，往往不是那些圆满交付的团队故事，而是阵容被打散之后依然有人走完全程。上个月我参加一场女性黑客松，开场不到12小时，我的算法队友就宣布退出，剩下48小时里，我一个人把一个叫 VolcanoGPT 的工具从半成品改到可上线，路演当天成功把“平行宇宙”搬上舞台。这篇复盘写给所有经历过“队友弃赛”的开发者，也写给那些担心一个人扛不住、却又不甘放弃的参赛者。

之所以想写这篇，是因为我发现大多数复盘都在讲“我们团队怎么合作”，很少有人认真讲“如果只剩一个人该怎么办”。而我这次恰好把两种情况都经历了：最初三个人组队，算法队友中途离开，我被迫重新设计项目边界。整个过程踩了不少坑，也验证了一个朴素结论——黑客松拼的不是谁的方案更全，而是谁能在有限时间里作出正确的减法。

1. 立项阶段：VolcanoGPT 这个名字是怎么来的，以及算法队友原本要做什么

1.1 我们先想清楚要做一个什么样的产品

报名黑客松之后，我和队友最先确定的是命题方向。主办方给出的主题比较宽泛，鼓励大家围绕“AI 与创作”自由发挥。我们当时的想法很直接：不想再做聊天机器人套壳，也不想做那种“输入关键词生成一张图”的常见应用。我们想做一个能让创作者真正获得灵感的工具，类似“故事宇宙生成器”。

于是有了“平行宇宙”这个概念：用户输入一个故事的起点，比如“一名宇航员在火星发现了人类的脚印”，系统立刻生成多个不同走向的宇宙设定，每个宇宙里都有独立的世界观、人物目标、核心冲突和关键事件。创作者不需要从白纸开始，只需要在这些分支里挑一个继续展开。

这个产品形态的好处是既有创意感，又有可演示性，评委一眼就能 get 到你在解决什么问题——创作里最难的“从0到1”环节，我们让 AI 来承担第一棒。

1.2 VolcanoGPT 的项目代号

项目叫 VolcanoGPT，这个代号其实是临时的。“火山”这个意象很适合我们的产品：给一句文本，系统像火山喷发一样，无预兆地吐出十几条发散的叙事方向，既有爆裂感，又有不可控带来的惊喜。我们内部开玩笑说，它就像一个“创意火山模型”。

后来这个名字一直沿用到路演，也没人觉得怪。反倒是在评委提问环节，“为什么叫 VolcanoGPT”成了一个意料之外的暖场问题——因为只要解释清楚这个名字，评委就自然理解了我们产品的核心能力：高并发式的创意发散，而不是单点回复。

1.3 算法队友原本承担的模块

我们原本的三人分工里，算法队友的工作非常关键。她负责的是“分支筛选与多样性排序”。简单说，模型一次会生成很多个宇宙分支，但其中有些相似度过高，例如两个分支都写“人类毁灭”“星际逃亡”，尽管细节不同，在用户感知里却像是同一条线。她准备做一套轻量语义去重：把各分支的文本向量化，算两两相似度，再用聚类方法挑出差异最明显的几条。

这个模块听起来高级，也确实能提升体验。但对一个48小时黑客松来说，它有一个致命问题——它处于整条链路的最后端。前端没有它还能先跑起来，可如果它一直没完成，整个项目就无法闭环。我们当时没意识到，这个排序模块已经成了整个项目的“关键链瓶颈”，它一断，所有人的工作都会卡住。

一开始我觉得算法队友的模块是最有价值的，因为她能让产品“显得聪明”。但后来我才明白，黑客松里最有价值的不是最有技术含量的模块，而是“只要它存在，产品就能完整讲下来”的那个模块。算法排序功能属于锦上添花，而非雪中送炭。

2. 队友退出后的极限重新设计：从“三个人分工”到“单人交付”

2.1 凌晨的通知和我的第一反应

比赛开始的第一个晚上，我们基本敲定了技术方案，设计同学也给出了高保真视觉稿。第二天的凌晨一点半，算法队友在群里发了一条消息，说她家里临时有事，必须回去，大概率赶不上后续赛程。

我盯着那条消息差不多一分钟没缓过来。凌晨一点半，距离路演已经不到 48 小时，后端生成服务刚搭好骨架，前端界面还是静态稿，而那个做排序的同学，是整个项目里除了我以外唯一能写代码的人。设计同学虽然还能帮视觉，但她前两周刚做完手术，不可能连续熬夜写代码。

Head：我第一反应是“要不弃赛算了”。但冷静下来以后，我给自己定了一个规矩：可以先砍方案，但不能不战而退。这时候最重要的不是抱怨，而是重新算清楚——一个人、48小时、一台电脑，到底能做多少事。

2.2 把原来的方案拆成两层：必须有的和可以牺牲的

我把产品能力全部列出来，然后分两类。第一类是“没有它故事就讲不完整”的能力，第二类是“有它更好，没有也能跑”的能力。

必须保留的能力有三个：

1. 用户输入一个故事起点。
2. 系统生成多条宇宙分支，每条分支带结构化字段。
3. 用户可以查看分支详情，并复制或保存内容。

可以牺牲的能力有两个：

1. 语义去重与多样性排序。这个没有也能演示，最多是生成的几条分支看起来有点相似。
2. 用户账号体系。本来打算做登录收藏，也一并砍掉，改成本地存储。

这个决策做了一个小时，做完之后我突然轻松了很多。因为被我砍掉的恰恰是那些最依赖队友、也最花时间的部分。现在剩下的工作量，理论上是我可以独立掌控的。

2.3 时间预算表：只有把时间花出去，才知道是不是真来得及

砍完方案之后，我重新排了一张时间表，精确到小时。我按“每连续工作6小时休息40分钟”的节奏，把剩余48小时切成了以下预算：

这张表后来证明大体靠谱，虽然中间有一些偏差。最大的偏差是“提示词工程”部分，我原本以为10小时足够，结果花了13小时，害得前端时间被压缩到10小时。所以你如果以后也做独立交付，请一定在时间预算里给“AI交互的不可控性”留出缓冲。

2.4 技术选型：所有东西都必须长在“我已经会用”的技能树上

队友退出之后，我对技术栈做了一个原则性变化：任何模块，只要不是我自己已经玩过超过两轮的，通通不碰。即使它更高效、更时髦。

举几个具体例子。后端我本来考虑换用异步框架，后来还是用回自己最顺手的 Python 轻量框架，厉害不厉害另说，但它部署简单，遇到任何问题，社区里都有现成答案。前端也没有引入重型组件库，就用一套自己写过的轻量样式方案，外加少量交互脚本，保证我能在一晚上把界面撸完。

大模型侧，我选的是自己平时就在跑的文本生成 API。有句实话想分享：黑客松赛场上千万别临时换模型供应商，因为每家 API 对系统提示词的敏感度不一样，连参数默认值都不一样。你过去在 A 平台调得顺的 temperature，换到 B 平台效果可能完全不同。48小时里我们根本折腾不起这个。

3. 核心实现：让 VolcanoGPT 在“可控随机”和“高质量”之间找到平衡

3.1 提示词工程：真正意义上的“需求说明书”

因为砍掉了排序模块，多样性压力全部转移到了提示词和参数侧。我必须让大模型“主动”生成差异明显的分支，而不是事后靠程序去过滤重复。所以我在系统提示词里做了非常明确的结构限制。

一开始我写的系统提示词只强调“请生成多个不同方向的故事分支”，结果效果很差。模型返回的六个分支里有四个都是“人类在火星建立基地”，唯一的区别是把主角名字换了一下。后来我换了一种思路：不再告诉它“要多样”，而是告诉它“必须用不同的类型去写”。

我给模型指定了六个固定的叙事类型：个人成长、政治博弈、文明演变、技术失控、神秘现象、伦理困境。然后要求它每一条分支必须选择一个类型，且同一个批次里不能重复。这个问题模型一旦切到确定轨道上，输出质量立刻稳定很多。

示例系统提示词：

你是一个叫 VolcanoGPT 的宇宙规划引擎。用户会给你一段故事起点。请生成6个平行的宇宙分支，每个分支必须选自不同叙事类型。JSON 输出，每个分支包含 universe_id、story_type、world_view、protagonist、conflict、timeline、hook。

这个设计最大的好处是：它把“多样性”从算法问题变成了“约束问题”。我不需要做向量去重，只要模型严格遵循“不同类型不得重复”，输出天然就有区分度。这也算是我在损失掉算法队友之后，用设计手段对冲技术缺口的心得。

3.2 参数调节：temperature 不是越大越好

我在调参上反复试了三个组合。第一次是 temperature 0.7，输出稳定，但分支与分支之间的差异度不够。第二次是 temperature 1.3，差异是大了，可好几条分支的逻辑开始飞，比如出现了“火星人反过来移民地球并统治恐龙”这种过于跳脱的内容。第三次我把它落在 0.9，同时把 top_p 设为 0.92，才勉强找到了“有想象力又不过分混乱”的甜点区。

这里要提醒大家一个关键认知：temperature 控制的是概率分布的形状，不是“创意浓度”。调到很高，模型做的不是更创意，而是更随机，随机的结果往往不是惊喜，而是无意义。好用的做法是固定 medium-high 区间，然后靠提示词里的结构去拉多样性，而不是单纯把参数往死里调。

我把最终参数和一个对比结论放这里，方便你直接参考：

3.3 JSON Schema：把模型输出变成前端能直接渲染的数据

这个项目的前端要展示许多不同字段，如果让模型返回纯文本，前端就得用正则去拆，费劲且容易坏。所以我从一开始就用了结构化返回模式。

每个宇宙分支都包含这六个字段：

• universe_id：分支编号，前端用它做锚点。
• story_type：叙事类型，前端用它做标签展示。
• world_view：世界观设定，不超过80字。
• protagonist：主角信息，包括身份和目标。
• conflict：核心冲突，不超过60字。
• hook：一个极具吸引力的开场钩子。

可能有人觉得 JSON 输出会限制表达能力。我的实测结论是：对于这种产品，限制反而是好事。结构化字段让用户能快速扫描每个宇宙的差异，也能让路演评委在5秒内看懂产品逻辑。自由文本虽然读起来华丽，但它没法在界面上形成对比，体验会大打折扣。

3.4 并发问题：我被每秒请求数狠狠教育了一次

因为前端需要一次性展示多个分支，我最开始的设计是每个分支单独发一次请求，六个分支并发调六次 API。本地测试一切正常，但部署到线上环境后，第一次真实路演压力测试就崩了——平台限流，六个请求里有三个返回 429。

这种错误在开发环境永远遇不到，因为你只有一个人在用。但路演时现场网络和我自己的预热脚本会同时打上去，很容易触发并发限制。处理办法是把六次请求合并成一次：让模型在单轮对话里一次性生成包含六个分支的完整 JSON，前端再解析渲染。

这个方法非常有效，不但绕过了限流，还把整体响应时间从十几秒压缩到三四秒。代价是超时时间变长，如果模型一次生成的内容太多，容易出现截断。我的兜底方案是给 JSON 输出设置“中位数长度”约束，避免单轮输出超过 3000 字。

3.5 前端的“平行宇宙”视觉表达

视觉上我们做的是“卡片宇宙堆叠”的交互：用户在输入框提交句子后，屏幕中央会先出现一个火山图标，然后六张卡片依次从底部弹出来，每张卡片代表一个平行宇宙。点击卡片，卡片会翻转展开，露出完整的宇宙设定。

这个效果看似复杂，其实核心就是一个 CSS 动效加一点前端状态管理。动手之前设计师跟我说，黑客松千万不要做那种需要复杂数据可视化的交互，比如关系图谱，太容易暴露数据质量问题。我后来深以为然，卡片式展示最大的好处是：一个字段没返回，最多是卡片留白，不至于整体崩塌。你要是也一个人做黑客松，请把 UI 设计成“可容忍数据缺陷”的样子。

4. 最后一公里：部署、路演Demo和被评委提问的应对

4.1 部署过程中最不该踩的坑，我还是踩了

第34小时进入部署阶段。我以为把代码推到云上就完事，结果在环境变量配置上栽了个跟头。模型 API 的密钥放在环境变量里之后，线上服务一直报认证失败，我在本地怎么测都是好的。

折腾了一小时，最后发现是部署平台的环境变量名里有空格。对，你没有看错——我复制配置时，在变量名的末尾多加了一个空格，平台侧一直把它当成不同的变量名。这个错误低级到我不想承认，但它确实花了我整个部署阶段三分之一的时间。

从此之后我的习惯变成了：所有环境变量名统一小写加下划线，且每配完一个键值，都在线下环境加一行启动时校验，防止配置飘移。

4.2 永远准备一份“预录Demo”，是对现场最大的尊重

到了第40小时，我反复测试了几遍核心链路。结果发现一个玄学问题：即使我自己本地跑得很稳，一旦浏览器开太多后台页面，请求中间件有时候会失去响应，出现“六条宇宙只回来五条”的尴尬。这种问题发生概率不高，但路演只有五六分钟，碰到一次就完蛋。

所以我做了一个后来被证明极其值当的决定：用录屏工具把3条不同的输入例句各跑一遍，提前录成演示视频。每条视频控制在60秒左右。万一现场翻车，我可以直接切到录制画面放给评委看。

结果路演当天真的用上了。我打开现场 Demo 时，正好赶上网络波动，页面转了七八秒还没加载出来。我当时没有犹豫，直接切到预录视频，一边放一边讲解。评委后来在提问环节说，他们以为那就是正常的动态演示，压根没有意识到是视频。预录Demo不是作弊，它是在高压现场保证信息有效传递的保险绳。

4.3 评委的典型提问，以及我是怎么回答的

路演结束后，设置了五分钟提问，评委的问题大约集中在三个方向：

第一个问题是：你怎么保证生成的六个宇宙一定是“平行”的，而不是语义重复？这个问题正好打在我砍掉的排序模块上。我的回答是：我们通过提示词约束不同叙事类型来保证第一层差异，再通过 JSON 结构里的世界观字段拉开第二层差异，不依赖后续程序过滤，所以即使没有额外的去重模型，用户看到的六条分支依然有足够区分度。

第二个问题是：它如何服务于真实的创作者？我给的场景是：短篇小说作者卡文时，用它生成故事开局；剧本策划需要拆分多线叙事时，用它做世界观参考。我把产品定位成“灵感起搏器”，而不是“内容生成器”，这个定位让评委觉得产品克制且有边界感。

第三个问题是：如果让你继续做两天，优先级是什么？我说第一是加回语义去重，第二是加分支对比编辑功能，第三是做多语言支持。这里的关键是，你不能说“我不知道”，你要表现出你对产品后续方向有明确判断，哪怕那只是临时想的，也要分好优先级。

4.4 成绩并不是重点，闭环才是我最看重的

最后的结果，我们拿到了“最佳独立交付”评审团认可。其实这个条线和名次无关，我更开心的是：在算法队友缺席的情况下，项目没有留下不可用的半成品，我也没有因为沉默成本死守原方案不放。

现在作为一个完整的回看：VolcanoGPT 上线后，我自己还陆续让几位朋友试用过，大家普遍反映“生成的分支足够脑洞”，但“有些分支的细节还不够丰满”。这说明当前版本在字段深度上还有很大提升空间。但至少，这个项目已经可以作为一个独立作品被讨论，而不是一堆躺在分支仓库里的代码孤岛。

5. 复盘清单：如果再来一次，我会在第一天就做这三个决定

5.1 把队友的模块默认设计成“可降级模块”

这是我从这次经历里收获最大的一条经验。以后组队参加黑客松，无论队友多靠谱，我都会在任务拆解阶段默认加一个规则：核心链路必须由至少两个人理解，任何模块都应该是“有队友能更快，没队友也能凑合跑”的状态。

我这次的问题在于，排序模块只有算法队友一个人懂，她想做的时候很容易，但她说走就走之后，我连降级方案都没有。如果我一开始就把排序定义为可选项，并提前想好“如果没时间做，用什么提示词策略兜底”，后面就不会那么被动。

5.2 每六小时强制给自己一次“Demo闭环检查”

独立开发的问题不是慢，而是容易钻牛角尖。我花了很多小时在调生成文本的格式细节上，结果等到第24小时才发现，前端展示时字段宽度不够，长文本溢出。如果我每6小时就强制自己停下来，打开浏览器走一遍“输入-生成-展示-复制”的完整链路，就能更早发现这个问题。

我的建议是设一个闹钟，不管当前代码写到哪，都要手动跑一遍用户视角的核心路径。别在后台逻辑里不出来，黑客松最重要的永远是“看起来能用”，而不是“内部设计得优雅”。

5.3 给路演留出专门的“话术时间”

很多开发者重实现、轻表达。我这次前期也没太重视路演，直到第40小时才意识到，自己居然连30秒的产品简介都没有写顺。现场一旦紧张，很容易变成“我做了一个AI生成工具”这种平淡输出。

后来我给自己写了一个话术模板，分三句话：第一句讲场景痛点，第二句讲产品形态，第三句讲核心创新点。比如：创作者卡文时最怕空白，VolcanoGPT 用“平行宇宙”的方式一次性给出多个故事走向；用户只需要输入一句话，六张卡片就会弹出完全不同的世界；我们通过叙事类型约束和结构化输出，保证了分支的多样性和可用性。

这套话术后来帮我节省了大量解释成本，也让评委在最短时间抓住重点。以后不管参加什么比赛，我都会在开发启动之前就先写好这三句话，哪怕后续产品方向变了，也只是在上面做改动，而不是从零开始想。

写在最后：一个人也不要把自己当成团队的反面教材

我知道很多人在黑客松里最怕遇到队友弃赛，一提“一个人扛项目”就觉得是惨剧。但我想说的是，单人作战确实残酷，它会逼着你把产品砍得更锋利。当你想保留的东西变少，反而更容易把一个点打到极致。

VolcanoGPT 这个项目对我而言，最大的收获不是技术上的突破，而是我发现自己可以在混乱中快速重建优先级。很多人遇到困难后的第一反应是自我怀疑，但正确的顺序应该是：先算清时间，再决定砍什么，最后才轮到情绪。只要你还有一台电脑、一个能跑的演示、一个想清楚的故事，你就没有真正失败。