企业官网建设流程全解析

作者：尔东陈在路上｜发布日期：2026-07-28｜原文：https://mp.weixin.qq.com/s/yIqwpPK0XmlbrPgDeXRTvw

上周在高校做AI coding 训练营，答辩环节有个细节印象深刻；

有个学员做了一个博客网站，功能做得挺全：未登录能浏览、能按分类筛选，登录后能发文章、存草稿、编辑删除，还有评论系统、管理员后台，甚至用 Cloudflare Tunnel 做了内网穿透，把本地后端暴露给组员访问。

技术上确实有想法。但我听完演示，只问了他一个问题：

「这个博客，你是给自己记事用的，还是要分享给别人看、还要有互动？」

他愣了一下，说没太想过。

我说，那你的评论功能和分享功能，可能根本不需要做。

一、功能没有判断依据，就会什么都想做

这不是挑刺。这是一个很多人——包括工作多年的产品经理——都会掉进去的坑。

你不想清楚「为什么做」这件事，你的功能就没有判断依据。

没有判断依据会怎样？就会什么都想做。看到别人有评论就加评论，看到别人有分享就加分享，功能列表越来越长，每一个都做得半生不熟。最后交付出来的东西，用户用不上，你自己也说不清它的价值在哪。

而如果你一开始就明确「这是我自己的知识库，不对外」，那评论、分享、多用户权限这些全部可以砍掉，省下来的时间够你把编辑器体验打磨得非常舒服——那才是你每天真正会用到的东西。

取舍的依据不来自功能本身，来自目标。

二、立项文档的价值不是走流程

我在训练营里花了很大力气讲立项这件事，很多学员一开始不理解——不就是写个文档吗，为什么不直接开干？

因为在企业里，项目的每一个阶段本质上都是在「把事情想清楚」，而不是上来就写代码。真实的比例是：70~80% 的时间花在讨论产品设计和方案设计上，真正敲代码的时间不到 30%。

立项文档只需要回答三件事：能解决什么问题、需要投入多少成本、多长时间能交付。

看起来很简单，但学员交上来的立项文档，问题惊人地一致：

信息错位。把产品方案、技术方案的内容一股脑塞进立项——数据库怎么设计、接口怎么定义，这些不该出现在立项阶段。立项只谈价值、成本、时间。

缺乏量化。目标写的都是「提升用户体验」「提高运营效率」，没有对比基线，没有数字。那你怎么知道做完之后到底提升了没有？

收益模糊。主观定性的描述，没办法客观评估这个项目算不算成功。

这三个问题背后是同一件事：没有真正回答「为什么做」，只是在填模板。

拿到模板就开始填，是最省力的做法，也是最没用的做法。立项文档的价值恰恰在于——它逼着你在花钱花时间之前，先把这件事想明白。

三、想清楚 ≠ 想大而全

但这里有个容易走偏的地方。

我在指导学生项目的时候一直强调另一句话：一开始不要想得大而全，能把整个链路验证完、能跑通，就可以了。

有个组做外卖平台，设计里有独立的骑手端 App。我建议他们砍掉——商家手动更新配送状态就行，先保证「下单 → 接单 → 配送 → 完成」这条主链路能跑通。

这和「想清楚为什么做」并不矛盾，反而是同一件事的两面：

想清楚是为了知道什么该做；MVP 是为了知道什么先做。

MVP 不是将就，是科学地降低风险。因为没上线之前，你永远不知道它真实上线后能不能解决问题。先做最小可用版本去验证，反而是更负责任的做法。

想清楚目标 → 砍掉不服务于目标的功能 → 在剩下的里面挑最小闭环先跑通。这是一条完整的链路。

四、工具越快，越要慢下来

为什么现在特别想说这件事？

因为 AI 把「做出来」的成本压得太低了。以前做一个原型要一周，现在半小时。以前写一份 PRD 要两天，现在几轮对话就有初稿。

好处是显而易见的。但副作用也很明显：当做出来变得很便宜，人就更容易跳过想清楚这一步。

反正生成一版不要钱，那就先生成看看。看着不对再生成一版。看似在快速迭代，实际上是在用工具的速度掩盖判断的缺失——因为你从来没有一个标准来判断「对」是什么样子。

我自己现在的习惯是，在打开 AI 工具之前，先用 ASK 模式把它当顾问聊几轮：这件事到底要解决什么问题，谁会用，用完之后什么指标会变化。方向确认了，再让它按标准格式整理成立项文档，然后才进入生成原型、写代码的环节。

前面这十几分钟，决定后面那几天有没有白干。

工具越快，越需要慢下来先想清楚。

最后留一个问题给你：你手上正在做的那个项目，如果现在有人问你「为什么做这个」，你能在三十秒内讲清楚吗？

如果不能，可能不是表达问题。

—— 尔东陈在路上