企业官网建设流程全解析

最近读到不少关于“AI只是资本泡沫”的评论，Ed Zitron 的声音是其中最常被转发的一类。他对AI行业的批评很直接：大量公司靠一套漂亮PPT拿到巨额融资，真实业务却撑不起估值；大模型训练和推理成本居高不下，普通用户却找不到“非用不可”的理由。连带着他对“AI改变生产力”的说法也表示怀疑。我第一次读到时确实被说服了，因为从市场角度看，AI行业的膨胀方式确实很像历史上许多技术泡沫的前夜。

但后来我发现一个偏差：评论家们讨论的是股票、融资、算力和产业宏观趋势，而我身边的工程师讨论的是某个具体模块能否借助大模型少写大量重复代码。这两个话题都叫“AI”，实际却是两个世界。Ed Zitron 的价值在于提醒大家不要被品牌宣传骗了，但当他从“行业存在大量泡沫”进一步推导出“AI没有实际价值”时，我认为他的判断开始失真。

他真正错的地方，是拿资本市场的镜头去拍摄工程现场的细节。资本市场需要宏大故事，工程现场需要的是把一个重复任务稳定地完成。泡沫是否存在，与技术工具是否能在给定场景里省下时间，是两个可以分开回答的问题。下面我想从自己观察到和经历过的工程实践出发，把这场争论拆到一个更具体的层面：AI应该被当作什么，它真正解决了什么，以及什么样的人适合听信哪种判断。

1. 两种AI叙事，经常被混为一谈

为什么同一个AI，有人觉得是生产力，有人觉得是大泡沫？因为他们在谈论不同的对象。现在至少有两条AI叙事线，一条是资本市场的，一条是工程现场的，它们都借用“AI”这个词，但评估标准完全不同。Ed Zitron 那类批评大多数时候盯着第一条线，然后试图给第二条线下结论，这是典型的错位。

1.1 资本市场版AI：永远在讲宏大故事

资本市场需要故事，需要增长曲线，需要“未来十年改变所有行业”的蓝图。融资阶段，一个技术概念是否有具体落地场景并不重要，重要的是它足够宏大，能覆盖足够多的想象空间。于是你会看到大量“AI应用”本质上是在普通产品上加了聊天框，或者把已有规则系统包装成“自主智能体”，业务问题没有解决，产品标题倒是很激进。这类现象确实值得批判。

Ed Zitron 嘲讽这些项目，我认为没有问题。一个行业如果出现太多靠PPT融资的公司，那么这个行业一定存在严重的资源错配和评价失真。但问题也随之而来：你不能因为一个技术领域同时存在大量骗局，就宣布这项技术本身无效。二手车市场里有骗子，不代表汽车是没用的；云计算早期也有很多“云”只是把服务器放在托管机房，不代表云计算不成立。资本叙事里混入了太多杂质，不代表底层技术真正产生的改善不存在。

如果评论者只盯着资本版AI，他看到的必然是一个又一个荒诞的产品和一轮又一轮融资过山车。长期处在这种信息环境里，很容易得出“AI没有真实价值”的结论。但这个结论只是评价对象的产物，不是技术事实。

1.2 工程技术版AI：具体任务里的确定性提升

工程现场对AI的理解更朴素：它不需要拥有通用智能，甚至不需要懂得自己在做什么，只要能在明确定义的子任务上稳定降低人力成本，它就有价值。这就像你接入一个函数，输入是一段文本或代码，输出是经过处理的结构化结果。它不一定每次都对，但你可以用规则和人工兜底把错误率压到业务可接受的范围。

我见过最典型的场景是数据清洗。一家公司收到几百份来自不同系统的表格，字段名不统一，日期格式混乱，地址写法千奇百怪。传统做法是写大量正则表达式，覆盖了主要场景，然后陷在无穷无尽的新版式里。用大模型做字段抽取后，核心思路变了：不再追求“一条规则走天下”，而是让模型理解自然语言中的语义边界，把“从这段文本里抽出供应商名称和金额”当成一个阅读理解题，再让程序校验输出格式。

这种应用不会登上科技新闻头条，也没有“改变世界”的故事性。但它在真实工作流里每天都在发生：生成测试数据、转换接口文档、给历史代码补注释、把非结构化日志整理成结构化事件。这些任务单独拿出来都很小，合在一起却占据了普通开发者相当大一部分工作时间。评论家在地铁上看融资新闻，当然看不到这类场景，除非他真的坐在开发者旁边，看一个实习生用提示词在半小时内搭出一个原来需要两天的数据提取脚本。

所以，当 Ed Zitron 说“AI并没有带来生产力革命”时，他可能是在说“公开市场的AI叙事没有兑现成足够宏大的经济增量”。这是另一个问题。技术价值的起步往往非常细碎：先在一个低风险任务里省下一点时间，再慢慢扩展到更多流程，最后变成一种长期能力。它不是一道闪电，而是一点一点渗入工作缝里的变化。

2. 真正让我改变态度的不是理论，而是三次具体任务

我对AI的态度经历过几次变化。最初看演示视频，觉得很多炫酷功能是剪出来的；后来读了几篇批判文章，觉得这可能又是新一轮泡沫；真正改变我的不是某篇论文或某次发布会，而是几个非常普通的任务场景。它们都不属于“改变世界”的项目，却让我重新理解AI的生产力价值。

2.1 第一次：写接口对齐代码，省下的是大量“类型搬运”

后端项目里经常要对接外部接口。接口文档几十页，字段有几百个，你需要照着文档生成对应的数据对象、序列化配置和基础单元测试。这种事不需要太多创造性，但极其占用时间。过去我通常下午开始手写，写完已经很疲惫。后来我把接口文档片段直接复制进一个编程助手，告诉它“生成Java数据类，字段命名用驼峰，日期类型用LocalDate，金额类型用BigDecimal”，几秒钟后得到一份初稿。

这里的关键不在于模型写得有多惊艳，而在于它把“类型搬运”这种纯体力工作压缩到了几秒。人只需要做两件事：第一，把需求边界描述清楚；第二，逐行审查输出是否正确。如果把AI的输出当作最终答案直接复制，当然会出问题；但只要把它当作一个需要人工复核的初稿，效率提升就是实在的。

在真实项目里，这类工作远不止对接接口。还有大量DTO转换、字段映射、配置文件生成、测试桩代码。它们共同特征是：重复性高、规则容易描述、出错后果不严重。AI是否“理解业务”根本不重要，它能帮你把初稿铺好，就已经省下了最枯燥的那段时间。这也让我第一次意识到，评价AI不能只看它能不能独立完成一个复杂系统，而要看它在重复劳动中节省了多少注意力。

2.2 第二次：几十份格式各异的旧单据，被压成可接受的成本

另一个例子来自一批历史采购单。单据来自不同供应商、不同年份，有的是PDF，有的是扫描件，有的表格里还混着备注。团队成员最讨厌这类任务：看起来简单，实际操作起来全是例外情况，必须打开每一份文件，人工把供应商名称、金额、日期填进系统。

我们试过两条路线。第一条是继续写规则：正则加关键词匹配，覆盖了大概七成的文件，剩下三成是新变体，每处理一个都要给规则打补丁。第二条是让模型直接做文档抽取，并要求它输出JSON，再让程序做一次字段格式校验，校验不通过的文件进入人工队列。后者不是万能的，也会出现金额错位和日期识别错误，但它至少把体力工作从一个一个看文档，变成了只在机器不敢判断时看少数几条样本。

这套流程的关键不是模型准确率有多高，而是我们为“模型可能犯错”设计了缓冲。它出错，程序能检测到；它识别不了，程序能转给人工。整个过程不需要模型完美，只需要模型把原本需要人工浏览一遍的内容，压缩到只处理异常项。最后团队负责人愿意用，因为同一批单据的处理时间从按周计算变成了按天计算。

这件事让我明白，AI在生产中的价值经常以“搭一套带错误兜底的流程”的形式出现。单独评价模型当然会得出“它不可靠”的结论，但如果你把它放进一个允许试错、有后置校验的工程系统里，它就变成了一个有用的组件。这正是只站在外部观察AI的人看不懂的部分。

2.3 第三次：Agent 不是全自动，而是把任务拆得更清楚

AI Agent 是近两年被过度包装的词。很多演示视频给用户的预期是：“你只需要说一句话，Agent 就能像员工一样完成整个任务。”这种预期对真实生产极不友好，因为一旦任务变长，模型出现一次判断错误，整个链条就全错，而且很难定位是哪一步出了岔子。所以我一直不太信任“放一个Agent全自动跑流程”的工程方案。

但我也见过一种更务实的Agent用法：让模型做任务路由。比如一个工单系统，用户提交一句话描述问题，Agent先做意图识别和信息抽取，然后决定应该走自动回复、调用业务接口还是转给人工客服。它不负责给出最终答复，只负责判断问题属于哪一类，以及把关键参数抽出来。即使模型抽错了，后续人工处理也能发现，不会直接产生严重后果。

这里的核心价值发生了转移。Agent 不是替代整个决策过程，而是替你把用户请求的结构先理清。真实业务中最困难的一步往往不是执行，而是明确“现在这个需求应该走到哪个流程”。AI Agent 能把这一步从人工判断变成自动化，就已经减少了大量人员负担。所以评论家说“Agent只是脚本编排”时，我不反对，但脚本编排在很多业务流程中恰恰是高价值动作。问题不在于Agent能不能全自主，而在于你是否找准了它的任务颗粒度。

3. AI评论家通常看不到的三层价值

如果把AI的价值只理解为“让机器像人一样工作”，你会觉得它距离好用还很远。但一个技术带来的改变往往是分层出现的：先是替代一些重复动作，再造出一些可复用的流程，最后改变人们的任务设计能力。这三层价值分别处在不同周期，面向不同对象。

3.1 表层价值：替代重复劳动，而不是替代人

很多批判者喜欢论证“AI不能独立完成创造性工作”。这不是一个新发现。真正被一线使用的工作方式，并不是让AI独立完成某个完整岗位，而是让AI完成岗位上最重复、最容易被描述清楚的那部分动作。比如一个数据分析师每天要花时间清洗Excel；一个后端工程师每天要写重复的序列化配置；一个产品运营每天要把大量用户反馈归门别类。这类任务不产生核心竞争力，但它们就在那儿，每天都在消耗精力。

把这一步替代掉，人的时间并没有被释放成完全的空闲，而是被移动到更值得做的事里。有人可能会说，这不就是让AI给每个人当实习生吗？对，就是这样。“实习生”的价值不是让你失业，而是让你有余力去处理更复杂的判断。现实中大量组织的问题不是缺少高端的战略能力，而是高级人员被低端重复劳动淹没。AI在表层做的事情，是把人从低端事项里捞出来，只是这种价值太分散，很难被“一项革命性技术”的故事所概括。

评论家如果只看宏观经济数据，很难捕捉到这种分布式的效率改善。它不体现为某家公司突然利润倍增，而体现为无数个团队在具体任务上减少了工时。这些工时分散到各处，加起来是一个不容忽视的量。

3.2 中层价值：可复用的流程和结构化输出

我最看重的一点，是模型不再只活在一个聊天窗口里，而是可以通过接口被程序调用。文本输入、文本输出，看起来简单，却让模型变成了一个可以嵌入现有系统的模块。你可以要求它返回JSON，可以把它的输出接进数据库、消息队列，可以在它犯错后设置超时和重试。这种“API化”让AI从对话工具变成了软件基础设施。

当一项技术变成基础设施之后，它的评价标准就从“它是否聪明”变成了“它是否稳定、可控、可运维”。你不需要在与它聊天时因为一句错误回复而否定它，你只需要在程序里加一层校验：如果返回格式不合法，就请求重试；如果两次重试仍失败，就转给人工。这很像我们在微服务架构里对下游系统所做的容错处理。任何一个外部依赖都有失败的可能，负责任的系统不会因为依赖可能失败而不接入它，而会为失败设计降级路径。

这种结构化集成意味着AI的价值可以被度量。你可以统计调用量、成功率、平均节省时间、转人工比例，而不是停留在“我觉得它挺聪明”或“我觉得它是骗局”的主观判断上。这也是为什么我更建议开发者从“聊天框使用AI”转变成“API使用AI”，因为只有后者才能进入工程体系，才能被测试、被观察、被持续改进。

3.3 长期价值：让个人和团队能处理更大的复杂域

还有一个容易被忽略的长期收益：为了把任务交给AI，你必须学会拆解任务。一个完整的需求往往很难直接丢给模型，你需要思考它包含哪些子步骤，每一步的输入是什么，输出应该是什么样，出现某种错误该交给谁处理。这个过程对个人的结构化思考能力训练非常明显。

我以前认识一位做运营的同事，最初只会把Excel文件上传给AI，让它“帮我分析一下”。效果当然不稳定。后来他开始学习写一点脚本，为了调用模型，他学会了如何用Python读取表格，如何用JSON保存结果，如何处理异常。几个月后，他不再满足于简单问答，而是开始设计一个批处理流程：清洗数据、分批请求模型、校验输出、把通过和失败的记录分开。他没有上过正式的编程课，但自动化意识已经被训练出来了。

这种变化放在团队里就是集体的复杂任务处理能力提高了。当每个人都知道“一个大任务可以分成指令、执行、校验三个阶段”时，团队的协作模式会发生变化。讨论不再只是“你想让AI做什么”，而是“你想让AI承担哪一段，哪些环节需要人来兜底”。这种思考方式不会因为具体模型被人遗忘而失效。它会沉淀成一种工程素养，长期伴随个人成长。这种价值很难用一次商业数据衡量，但也正是我认为很多外部评论家看不到的那一层。

4. 真正要讨论的不是“有没有用”，而是“怎么用才有用”

围绕AI的争论经常变成非黑即白。但在工程实践里，AI适配性和任务特征高度相关。同一个模型，在一个场景里是生产力工具，在另一个场景里就是昂贵玩具。所以与其争论AI整体有没有用，不如建立一个“判断自己的任务是否适合AI”的框架。

4.1 判断AI是否适合自己的四个问题

我一般会建议团队先问自己四个问题：

• 这个任务多久发生一次？如果一年只做一次，不必为它搭建AI流程，人工更好。
• 出错后果有多严重？如果是医疗诊断、法律判决、敏感数据删改，现阶段不能完全交给模型。
• 你能不能把任务输入和输出边界写清楚？越清晰，越容易让模型稳定发挥。
• 你有没有资源做最后一道人工检查？如果没有人工兜底，就应该把AI限制在低影响场景。

把这些维度整理成一张表会更直观：

从这张表能看出一个趋势：AI最适合的场景，不是“越难越好”，而是“越有边界越好”。它更像是一个被你封装起来的智能模块，外面必须有一层协议和一层校验。如果你把一个没有任何边界的大问题直接丢给模型，它的表现大概率会让你失望，但这不代表方向错，只说明任务拆解不到位。

4.2 从最小闭环开始的落地顺序

一旦确认一个任务适合尝试，正确的落地顺序通常不是马上把整个流程自动化，而是先做一个最小闭环。这里有一个可以参考的四步法：

1. 抽出单个样本，先手工跑通模型调用，确认输入输出格式正常。
2. 把输出接到下游，写一个最简校验，比如JSON格式判断、字段存在性判断。
3. 用小批量样本（例如10到50条）继续跑，记录失败类型，不要只看成功案例。
4. 根据失败数据决定是否扩大范围，并补充异常重试和人工兜底。

为什么不要一上来就批量执行？因为大模型输出具有概率性。刚才那一条成功了，不代表下一条同样格式的内容也能成功。模型可能在很长的文本里突然漏掉一个字段，也可能在JSON里引入了一个非法字符。如果小批量测试发现了五种失败模式，后续扩大时你至少知道要在哪里加重试、哪里加规则、哪里转人工。如果完全没有失败模式数据，后续出问题时你会非常被动，既不知道是哪步的问题，也不知道是模型问题还是流程问题。

我的建议是：第一次接触某个AI任务时，以“把一条样本跑通并记录错误”为目标，而不是以“把一万条数据处理完”为目标。单次跑通只代表流程没有断，不代表结果稳定可用。

4.3 需要避免的三种失败方式

根据我自己和新手团队协作的经验，最容易导致AI项目失败的往往不是模型能力，而是使用方犯了三类错误：

第一，没有定义“正确答案”就上模型。感觉型需求最容易翻车。比如你说“帮我优化这段文案”，但你没说清楚是要更正式还是更活泼、要不要保留具体数字、输出多长。模型只能猜，猜完你不满意，然后你觉得它答非所问。这其实不是模型的问题，是需求描述本身不够工程化。

第二，把模型输出当作最终结果，没有校验层。生产任务不是写论文，格式错误会导致下游程序直接崩溃。模型返回“25,000”和“25000”之间差异巨大。没有校验层等于把你的流程暴露在所有状态空间下。

第三，把所有步骤一次性塞进对话，不设中间验证点。一个长任务链条越长，出错定位越难。更好方式是把任务切成多个子步骤，每个子步骤独立输出，独立校验。如果最后结果异常，沿着子步骤日志查找，很快能锁定出问题的那一段。

模型接入后，如果要排查生产问题，建议沿这条链路走：先看输入是否干净，很多错误来自源数据本身；再看模型返回是否完整，是否触发截断；接着看程序里的JSON解析是否对错误格式做了兜底；然后看日志里有没有超时、重试、权限异常；最后看校验规则是否覆盖了业务里最常见的异常分支。大多数AI应用故障都不是什么高深问题，而是把模型当成万能函数之后忘了给它加异常处理。

5. 悲观评论的价值，以及它错在哪里

前面写了这么多，也许有人会觉得我在给所有AI造势。其实不是。Ed Zitron 这类怀疑论者提出的问题非常重要，比如模型训练成本、版权争议、算力消耗以及对产品概念的包装。如果完全没有这类人，整个行业会被硅谷式乐观语境彻底吞没。我反对的是那种把技术全盘否定的结论，而不是反对批评本身。

5.1 悲观派说对的部分

从行业宏观层面看，现在存在大量“为了做AI而做AI”的产品。很多企业采购AI不是因为用户真的需要，而是因为老板觉得不拥抱AI就会被淘汰。这种需求驱动的项目，上线之后常常连一个像样的评测集和验收标准都没有，最后沦为演示用品。

同时，模型训练和推理的资源消耗确实高得惊人。无论是训练一块大模型所需电力，还是云端推理所需的算力成本，都不是“所有人都能用得起的公共资源”。这种资源错配让小团队和个人开发者更难参与底层创新，也让大公司更容易利用资本壁垒垄断话语权。我相信任何人都应该为此保持警惕。

还有版权问题。模型训练数据中哪些素材获得授权，生成内容是否涉嫌复制和抄袭，目前在法律上仍然充满争议。如果把这些议题放在显微镜下，任何一家AI公司都可能有让人担忧的部分。悲观派坚持把这些黑箱问题摊在桌面上，是必要的。批评不是破坏，而是技术走向成熟前的一次次压力测试。

5.2 乐观派经常掩盖的部分

乐观派喜欢展示成功的demo，但很少主动告诉你模型距离可稳定使用还有多远。幻觉是最常被提起的问题，模型会在明明不确定的时候给出一本正经的答案。很多乐观派选择忽略这种不确定性，或者轻描淡写地说“只要配合提示词就能解决”。在低风险场景里确实可以解决，但当任务变复杂后，幻觉仍然会以隐蔽方式出现。

更麻烦的是“输出漂移”。同一个提示词，同一家公司升级模型后，可能返回完全不同的结构和风格。这意味着你无法在把提示词写好后一劳永逸。每一次上游模型版本更新，都可能影响下游系统稳定性。因此如果你把AI做进生产流程，最好锁住模型版本，单独做回归测试，而不是无脑跟随最新模型。

评测也是一个长期问题。很多公开榜单和分数只能代表特定数据集上的表现，与你自己业务数据分布差别很大。一个模型在某个综合榜单上排名靠前，不代表它能正确理解你公司的术语。所以最可靠的评测，始终是你自己的小批量业务样本上的人工评估。那些包装过头的“真实案例”，通常省略了失败率，或者只选取了对产品有利的样本，看多了容易把人带到坑里。

5.3 怎样形成自己的判断而不是站队

网络争辩里最廉价的事就是站队。有人因为看到AI骗局而否定一切，有人因为押注AI叙事而拒绝承认问题。更务实的做法是建立一手的证据链。我的建议是“三步开地图法”。

第一步，找出三个会高频影响你工作的任务。第二步，用相同的输入集，分别跑“纯人工”和“AI辅助”两条路径，记录耗时时长、出错次数和修复成本。第三步，得出一个有限的结论：“在我手里的数据分布上，任务A和任务B值得用AI，任务C不值得。”这个结论可能不能 generalize 到全行业，但至少能指导你自己的下一步决策。

这种验证方式会让人很快意识到，AI的效用是高度情境化的。它可能在一个公司是效率引擎，在另一个公司却因为数据格式和业务口径太特殊而表现平平。不要用别人的成败来定义自己的选择。获得第一手证据后，你自然能同时理解悲观派和乐观派为什么各执一词：他们很可能是在用不同数据样本评价同一个东西。

6. 从“Ed Zitron 错了”到“把AI当成工程材料”

回到最初的问题：Ed Zitron 真的错了吗？如果只看“AI行业存在大量泡沫”这一点，他没有错。但他如果因此断定AI技术没有真实价值，那就错了。真实价值未必以那种“宏大叙事”的方式存在，而可能以非常普通的方式潜伏在每一行自动生成的代码、每一个被压缩的数据清洗任务、每一段被结构化提取的文档里。

6.1 AI不是魔法，也不是骗局，而是概率性的工程材料

一个比较接近工程事实的类比是：AI不是魔法，也不是骗局，而是一种概率性材料。就像混凝土，它刚被用于建筑时，很多工程师担心它不如传统石材稳固。它确实可能开裂，但如果设计时考虑荷载、湿度和养护条件，它就能成为城市最广泛应用的结构材料。AI也一样，你不可能要求一个概率模型像确定性代码一样每次输出相同结果，所以你必须为它的概率性设计缓冲。

在工程系统里，“会出错的组件”并不少见。数据库会超时，下游服务会抖动，第三方接口会偷偷变更协议。工程师不会因为这些可能风险就拒绝使用它们，而是会用重试、降级、熔断、监控、人工兜底等方式把风险控制起来。真正造成灾难的，往往不是组件本身会出错，而是设计者没有预想到它会出错。

所以，如果你要长期使用AI，最重要的能力不是掌握某个提示词技巧，而是会用工程手段管理不确定性。定义输出协议，加入格式校验，设计失败分支，记录每一次异常。当你把这些事情做完，AI才从“一个聪明的聊天者”变成了“一个可被测试的服务组件”。

6.2 从“写代码”到“设计任务”

对于开发者来说，AI带来的最大变化，短期看是代码生成辅助，长期看则是角色重心的迁移。传统开发模式里，我们要花大量时间把业务需求转成可执行代码，但每个重复函数、每段模板代码，未来都可能由模型生成。人的价值会更多落到“设计任务”上：把模糊业务问题拆成可执行的子任务，为每个子任务定义输入输出和质量标准，最后再把各阶段结果组装成完整系统。

这听起来不像是普通程序员的工作，但正在逐渐成为日常工作的一部分。你和AI协作时，最重要的一步不是回车运行，而是提前想清楚它的输出要被什么系统消费、出错时该怎么办。这种思路和设计API、设计模块边界非常像。换句话说，未来最稀缺的能力不是都会写某一种语法，而是能通过提示词、上下文、工具调用等多种方式，把没有清晰结论的问题变成一个可以通过计算机一步步验证和修正的流程。

这也是我为什么并不焦虑AI写作、AI编程等概念的影响。工具会