企业官网建设流程全解析

客户丢给我一句话：

“我要个云端 AI 工作台，打开浏览器就能用，数据别外泄，还能装我自己的业务能力。”

就这么一句。没有需求文档，没有原型图，没有一条像样的验收标准。

换成几年前的我，第一反应是打开白板画架构——前端用什么、后端怎么拆、AI 怎么接、数据怎么存。脑子里"哗"地铺开一张系统设计图，然后就开始盘算"这得写多少代码、招几个人、干几个月"。

这一次我没这么干。

我先愣了一下，然后问了自己一个问题：他要的到底是"一个系统"，还是"一个能解决他那摊事的工具"？

这两个听起来差不多，其实差着十万八千里。当你以为客户要"一个系统"，你会一头扎进去从零造；当你想明白客户要的是"能解决问题的工具"，你会先抬头看看——这世上是不是早就有人把零件造好了，我只要挑对了、拼起来就行。

这一篇我想跟你聊的，就是这么个心智转弯。做完这一单，我最大的收获不是"我搭出了一个云端 AI 工作台"，而是想明白了一件事——我一个零件都没造，四块现成的积木放一起，客户要的东西就成了。而真正值钱的，不在我拼的那几行胶水代码里，在"缝什么、不缝什么、什么绝不自己造"的一连串判断里。

下面我一段一段拆给你看。

一、客户要的从来不是一个系统

先说个你可能也踩过的坑。

客户说"我要个 XX 系统"，你听进耳朵里的，往往是"系统"这两个字。于是你开始想数据库、想服务怎么拆、想部署——你把自己代入成了一个"造系统的人"。

可你回头品品客户那句话，他真正在乎的是什么？

他说"打开浏览器就能用"——他怕的是"装起来麻烦、换台电脑就废、给同事用还得重配一遍"。他说"数据别外泄"——他怕的是"我的东西跑到不受控的地方，哪天就没了"。他说"能装我自己的业务能力"——他怕的是"买个通用工具，跟我的活儿根本贴不上"。

你看，客户嘴里说的是"系统"，心里装的全是"怕"。他不是要一堆代码和服务器，他是要几个具体的怕被解决掉。

这就是我想跟你立的第一个判断——

客户要的从来不是一个系统，是一个能把他那几个"怕"挡住的工具。

工具和系统的区别在哪？系统是你造出来的一坨东西，工具是"能干成某件事"的那个能力。客户根本不关心你这工具里面是自研的还是拼的、是一万行代码还是一百行胶水——他只关心打开浏览器那一下，东西在不在、好不好使、贴不贴他的活儿。

想通这一层，你干活的姿势就变了。

你不再问"我要造一个什么样的系统"，你开始问"我要凑齐哪几样能力，才能把他的怕挡住"。前一个问题把你推向"从零造"，后一个问题把你推向"先看看现成的有没有"。

这一步转身，就是这篇要讲的全部东西的起点。

二、把一句模糊话，剥成四个真需求

心智转过来了，接着干第一件正事——把那句模糊话，剥成几条能落地的真需求。

我没急着动手，先跟客户来回聊了几轮。不是聊技术，是聊他到底怕什么、要什么。聊完，那句含糊的"我要个云端 AI 工作台"，剥出了四条清清楚楚的需求：

第一条，隔离可控。他说"数据别外泄"，背后是——每个人的东西得关在自己的一亩三分地里，你的动不了我的，我的也串不到你的。说白了就俩字：安全，还得是"看得见、拦得住"的那种安全。

第二条，开箱即用。他说"打开浏览器就能用"，背后是——别让我装环境、别让我配一堆东西、别让我看说明书。点开链接，东西就在那儿等着我，最好连"下一步、下一步"都不用点。

第三条，能装业务。他说"装我自己的业务能力"，背后是——通用工具我不稀罕，我要的是能把我这行、我这摊活儿的门道装进去的东西。今天装一样，明天想加一样，还能接着加。

第四条，谁都能有一个。这条他没明说，但我从"云端"两个字里抠出来了——他不是要一个人用的玩意儿，他要的是"团队里谁登录，谁就有一个自己的"，互不打扰。

四条需求，背后是四个怕：怕泄密、怕难用、怕不贴合、怕独占。

你注意到没有——到这一步，我还一行代码都没写，一个技术选型都没定。我干的全是"把话听清楚、把怕剥出来"的活儿。

这不是浪费时间。恰恰相反，这四条需求就是我后面所有判断的尺子。没有这把尺子，你连"该缝什么、不该缝什么"都无从谈起——你都不知道要挡住哪几个怕，怎么知道该凑齐哪几样能力？

所以真需求剥清楚了，下一步不是"开工造"，是问一个更关键的问题。

三、缝合的心智：先问"这个能不能不自己造"

大多数工程师拿到需求，脑子里蹦出来的第一句话是"这个怎么实现"。

我想跟你说，这一步——慢半拍。

我拿到那四条需求，脑子里蹦出来的第一句话不是"怎么实现"，是另一句：

“这四样能力，市面上是不是早就有现成的能拿来用？”

这句话，是这一整篇的题眼。你要是只记一句话，记这句就够了。

我给你打个比方，这事就跟装机一模一样。

你要装一台电脑，你会怎么干？你会跑去配件城，逛一圈，挑一个合适的 CPU、挑一根内存、挑一块显卡、挑一块主板，回来拼成一台整机。

你会自己去造 CPU 吗？不会。你会自己去蚀刻一块芯片、自己去焊一块主板吗？更不会。那是一整条产业链干了几十年的活儿，你一个装机的凑上去造 CPU，就是脑子进水。

装机的价值，从来不在"造零件"，在"选对零件、拼成客户要的那台机器"。客户要台打游戏的，你就配高显卡；客户要台剪视频的，你就上大内存、多核心。你的本事是"懂需求、会选配、能拼装"，不是"会造芯片"。

做这个云端 AI 工作台，是一模一样的道理。

我拿到四条需求，第一动作不是进 IDE 敲代码，是先去"配件城"逛一圈——看看运行环境、AI 能力、界面交互这些东西，是不是早有人造好了、我拿来拼就行。

逛完我发现：全都有。而且个个都是成熟货、开源货、一堆人用了好多年的货。

那还造什么？造了就是重复造轮子，造了就是拿自己那点人手，去跟人家一整个社区几年的积累硬刚——刚不过，还费劲不讨好。

所以我给你提炼这一节的核心心智——

拿到需求先别问"怎么造"，先问"这个能不能不自己造"。

能不自己造的，坚决不造。省下来的力气，全花在"选哪块、怎么拼、拼出来贴不贴客户的活儿"上。

这不是偷懒。这是想清楚了"你的价值到底在哪"。你的价值不在"我能从零写一个编辑器"这种自我感动里，在"我用最小的代价，把客户那几个怕挡住"这个结果里。

而且，这里还藏着一件更妙的事——那些现成零件，本来就是"留着给你拼"的。这话什么意思，下一节我拆开讲。

四、四块积木，一块都不是我造的

好，逛完配件城，我把要拼的四块积木摆出来给你看。为了讲清楚它们各自干嘛，我给每块起了个大白话名字。

第一块，运行时底座——相当于"身体"。

这是每个用户那间"独立小屋"，是工作台真正跑起来的地方。用户所有的东西都关在这间小屋里，你的动不了我的，我的也串不到你的——第一条需求"隔离可控"，靠它。

这块我之前专门聊过一整篇。简单说，就是把一套标准环境封成一个"罐头"，谁打开都一模一样、开盖即用。这里我不重讲，你只要记住一件事：这个"身体"是现成的容器技术，加上现成的网页版工作环境拼出来的，我一行运行时代码都没写。

第二块，调度网关——相当于"大脑"。

一百个人同时来，谁登录就给谁开一间小屋、用完了把小屋收回去、请求来了准确送到对应那间屋——这摊调度的活儿归它。第四条需求"谁都能有一个、互不打扰"，靠它。

这块我也专门聊过一整篇。它最值钱的不是调度技术本身，是几条"谁也不能越界"的死规矩。这里同样一句话带过：这个"大脑"我也没从零造，是站在现成的编排能力上，套了一层薄薄的调度逻辑。

身体和大脑，是前面两单已经备好的零件，这一单直接拿来用。真正是这一单新拼上去的，是下面两块。

第三块，编辑器交互——相当于"脸"。

用户打开浏览器，看到的那个界面、点的那些按钮、跟 AI 对话的那个框，就是这张"脸"。第二条需求"开箱即用"，很大程度上靠它——你得让用户点开就看见一个能上手的界面，而不是一个黑乎乎的命令行。

这张脸，我造了吗？没有。我用的是一个现成的网页版编辑器——它本来就长着一副好用的样子，有文件树、有编辑区、有终端。我要做的，只是把跟 AI 对话的交互，接到这张现成的脸上去。

第四块，AI 后端加上能力插件——相当于"手艺"。

这是工作台真正"有本事"的地方——能听懂人话、能干活、还能装进客户那一行的门道。第三条需求"能装业务"，靠它。AI 后端是现成的，客户那些业务能力，是往这个现成后端里"装"进去的，不是我重写一个 AI 出来。

四块积木，摆完了。你回头数数——

身体，现成的。大脑，现成的。脸，现成的。手艺，现成的。

没有一块，是我从零造的。

到这儿，我要跟你说这一节最想说的一句话，也是这一篇的暗线——

这四块积木能拼到一起，不是因为我手巧，是因为它们本来就是被设计成"能拼"的。

什么意思？

那个网页版编辑器，它的作者早就想到了"会有人想往我这儿加新东西"，所以他专门留好了口子——你想加个面板、加个功能、接个别的界面进来，往约定的地方一放就成，不用去改它的老底子。

那个 AI 后端也一样。它的作者早就把"往我这儿加新本事"设计成一件标准动作——你把新角色、新技能、新工具按约定的方式放进去，它自己就发现了、就用上了，同样不用你去动它的内核。

这些"能往里缝东西"的口子，不是我发明的，是这些开源工具的作者，当初造它们的时候就原生留好的。

这一点特别重要，你得咂摸出味来——

我这个"缝合的人"，本事不在"造口子"。造口子那是人家工具作者的功劳。我的本事在于：看得懂哪儿有现成的口子、看得懂这个口子是留着干嘛的、然后决定往这个口子里缝什么。

你再回头看装机那个比方就更透了：主板上那些插槽——插 CPU 的、插内存的、插显卡的——是主板厂商设计好的，不是你这个装机的开的。你的能耐是"知道哪个槽插什么、该插哪一款"。

看懂扩展点在哪、决定往里缝什么——这才是缝合式交付真正的手艺。代码写得多不多，一点都不重要。

五、真正的功夫，在"不缝什么"

讲到这儿，你可能觉得——不就是把四块现成的拼起来嘛，听着不难。

难的地方来了。缝合这活儿，真正的功夫不在"缝什么"，在"不缝什么"。

我给你几个我当时忍住没干的事：

我没有自己造一个编辑器。

我完全可以说："现成的网页版编辑器不够贴合我的需求，我自己写一个更顺手的。“很多人会这么想，也真有人这么干。但我忍住了——客户要的是"打开浏览器就能用”，一个成熟的现成编辑器早就把这件事做到位了，我从零写一个，写三个月都未必有人家稳。这个零件，绝不自己造。

我没有自己造一个 AI 后端。

我也完全可以说："我要对 AI 的行为做深度定制，现成的后端框不住我，我自己撸一个。“打住。客户要的是"能装我的业务”，而现成的 AI 后端本来就把"往里装新本事"这条路铺好了——我要做的是往里装，不是把这条路重修一遍。这个零件，也绝不自己造。

我没有自己造运行环境、没自己造调度。

这两块前面说了，前两单已经备好，直接拿来。我连"要不要顺手优化一下"的念头都摁住了——它们现在能用，就别动。

你发现规律了吗？我每一次"忍住不造"，背后都是同一句判断：

这个零件，别人已经造得比我好、比我稳、比我久了，我再造一个，只会给自己刨坑。

为什么说是刨坑？因为你每多造一个零件，就多背一份维护债。

你自己写的编辑器，往后每一个 bug 都得你修，每一次升级都得你跟，每一个新需求都得你加。而你用现成的，这些活儿是背后一整个社区在替你扛。你自研的那点"更贴合"，换来的是没完没了的维护包袱——这笔账，怎么算都不划算。

所以缝合式交付有一股子"克制"劲儿在里头——

能用现成的，就绝不自己造；忍得住"我上我也行"的冲动，才是真本事。

这话反过来说更扎心：一个工程师最容易犯的毛病，恰恰是"手痒"——看什么都想自己写一遍，觉得自研才叫本事、拼装是没技术含量。可站在"给客户交付价值"这个立场上，真正的技术含量，是你有没有那个眼力和定力，把该借的借来、把不该造的摁住。

不是你能造多少，是你敢不造多少。

六、缝合出来的，是客户能用的产品

四块积木缝好了。我们回到最开始那个问题——客户到底拿到了什么？

客户拿到的，不是四个代码仓库，不是一堆服务器，不是一份架构图。

客户拿到的是：打开浏览器，登录进去，一个界面就在那儿等着他；界面里，AI 能听懂他的话、能干他那一行的活儿；他的东西关在自己那间小屋里，谁也偷不走、串不了；团队里再来一个人，登录一下，又是一个一模一样、干干净净的工作台。

四条需求，四个怕，一个不落，全挡住了。

这就是客户要的"工具"。他不会问我"这里面几块是自研的、几块是拼的"，他只会说一句"哎，好使"。

而这里我想跟你点破一件事——这个工作台的每一个功能，都不是我"设计"出来的，是从客户那句模糊话里"提纯"出来的。

你回头看：隔离可控、开箱即用、能装业务、谁都能有一个——这四样，哪一样是我拍脑袋加的？没有。全是从客户的怕里剥出来的。我没往里塞任何一个"我觉得很酷、但客户没要"的功能。

功能是提纯出来的，不是设计出来的。你越想着"我要设计一个牛逼的系统"，越容易往里堆客户根本不要的东西；你越盯着"客户到底怕什么"，交付的东西越干净、越贴。

说到这儿，我想给你看一个行业里的说法，你会发现"缝合式交付"根本不是我一个人的邪门歪道。

业界有一类工程师，专门干"到客户现场、把现成的软件平台配起来解决客户最棘手的问题"这件事。有一家以这类工程师闻名的公司，公开这么描述他们的活儿（我把原话给你翻译过来）：

他们跟传统的咨询顾问不一样——大部分时候是把现成的部件开箱即用地拼到一起，不必为每个客户重新发明轮子；他们真正聚焦的，是组合出一套对的功能架构。而他们那个平台本身，就建立在数十个开源工具和微服务之上。

你品品这几句——“把现成部件拼起来”“不重新发明轮子”“组合出对的架构”“建立在数十个开源工具之上”——这不就是我这一篇从头讲到尾的"缝合"吗？

（说明一下：这是业界对这类工程师角色的公开定义，我拿来印证"缝合式交付是一门被承认的手艺"，跟本文这单业务的客户、团队没有任何关系，别对号入座。）

所以你看，“不重造轮子、把现成件组合成对的架构”——这是被行业写进职业定义里的东西。价值在"组合"和"取舍"，不在"从零发明"，这不是我的个人偏好，是这一行早就想明白的道理。

七、写在最后

回到开头客户那句话——“我要个云端 AI 工作台，打开浏览器就能用，数据别外泄，还能装我自己的业务能力”。

这一篇我想跟你捋清楚的，就是拿到这么一句模糊话之后，我脑子里那趟没写在代码里的路：

先分清他要的是"系统"还是"工具"——他要的永远是工具；再把模糊话剥成四条真需求、四个怕；然后忍住"怎么造"的冲动，先问"能不能不自己造"；接着把四块现成的积木——身体、大脑、脸、手艺——一块一块认出来、拼起来；最难的一步，是想清楚"哪些绝不自己造"，把手痒摁住；最后交付给客户的，是一个提纯出来、干干净净、正好挡住他那四个怕的工具。

从头到尾，我没造一个零件。

我做的全部事情，是"选什么、拼什么、绝不造什么"的一连串判断。价值全在这些判断里，不在代码里。

而且别忘了那条暗线——这四块积木之所以能拼到一起，是因为它们的作者，早就把"能往里缝东西"的口子留好了。我不是造口子的人，我是那个看懂口子在哪、决定往里缝什么的人。

未来真正会用 AI 交付的人，不一定是那个能从零写出一个系统的人，而是那个知道什么该借、什么该拼、什么绝不自己造的人。

工具越来越现成，零件越来越多——会造的人一抓一大把，会取舍、会缝合的人，才越来越金贵。

这一篇我们只讲了"心里那趟路"——怎么想清楚缝什么、不缝什么。可"想清楚"离"真跑起来"还差一大截：四块现成的积木，凭什么就能严丝合缝拼成一个整体？那张现成的"脸"怎么接上现成的"手艺"？往 AI 后端里"装业务能力"到底是怎么装进去的？缝合的接缝处，又有哪些取舍要拿捏？

这些"怎么缝到一起"的门道，下一篇到工程落地的现场，一处一处拆给你看。

关于 ArchAIHarness

这篇文章是「看懂 AI 与智能体」专栏的一部分，由ArchAIHarness持续输出。

ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产，主张：

架构师定义秩序，AI 在秩序中生长。人立法，AI 执行，体系审计。

如果你也希望 AI 在明确的架构边界内协作，而不是在混沌中碰运气，欢迎到 GitHub 上看看我们在做什么：

• 组织主页：github.com/ArchAIHarness — 了解完整理念与资产全景
• 本专栏：zhuanlan-ai-and-agents— 所有文章的源码与发布记录
• 实践指南：docs— 架构哲学、工程方法和落地指南
• 开源工具：agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools
• 工程样例：framework— DDD + AI 协作的工程底座，展示如何在开发中融合 AI

Engineered by Architects · Empowered by AI · Audited by Discipline