上周我在本机跑一个 AI 批量处理脚本目标很简单把几十段产品描述自动改写并分类。第一次跑通时我确实很兴奋觉得接下来只需要等待结果就好。但第二次执行时同一批输入里混入了几条特殊格式的文本输出立刻跑偏而且错误不是报错是那种看起来完全正常但信息错乱的结果。那一刻我突然意识到真正应该被审视的不是某一条生成效果而是整个流程的结构。我们正处在一个把“效率”当成最高信仰的时期。“AI 是效率社会的新宗教”这个判断放在库哈斯的建筑隐喻里看格外精确。库哈斯是那个用《疯狂的纽约》和“广普城市”概念拆解现代都市的荷兰建筑师他会说现代城市不是靠广场和纪念碑组织起来的而是靠电梯、网格、空调和基础设施制造出一种新的密度。今天的 AI 体系也类似我们用地平线一样不断延伸的计算能力把原来需要人慢慢处理的文本、代码、图片和流程全部压缩进一条条自动化管道里。我们相信更快就是更好相信模型越大就越接近答案。但问题也藏在这种“相信”里。宗教的核心是一种不假思索的信任。当一个人开始默认 AI 说什么都对、批处理永远稳定、Agent 做得多就一定好他就已经从使用者变成了信仰者。这也是为什么值得用库哈斯式隐喻做一次冷静的拆解不是反对 AI而是看清 AI 在效率社会里到底替我们承担了什么又遮蔽了什么。1. 先理解库哈斯的隐喻AI 为何会成为效率社会的“新宗教”1.1 从建筑到效率库哈斯在观察什么库哈斯不是做 AI 的但他对基础设施的观察非常适合用来理解 AI。他研究曼哈顿时发现现代都市的密度不是来自土地面积而是来自垂直叠加。电梯让摩天楼成为可能网格提供了均质的空间单位。一座楼里可以塞进办公、居住、商业、娱乐不同活动在同一栋建筑里叠在一起形成一种“拥挤文化”。今天的 AI 体系本质上也是这样的垂直结构。大模型是“电梯”GPU 是“土地”Prompt 是入口Agent 则是楼里活动的使用者。过去需要跨部门、跨环节才能完成的复杂任务现在被压缩进一个对话窗口。你让 AI 写一份竞品分析它可能读链接、做总结、生成表格、给建议看起来像一个小团队在干活。但支撑这一切的不是某个天才员工的判断而是一套基础设施的堆叠。这种变化本身没有好坏但它改变了我们对“能力”的定义。以前判断一个人能不能做项目要看他的知识、经验和判断力现在还要看他能不能组织好 AI 工具。效率社会的逻辑是谁能让更多流程并行、更快产出谁就更有价值。库哈斯对城市的观察同样是这个逻辑真正决定城市形态的不是纪念碑而是基础设施的容量和分布。1.2 “新宗教”不是指神坛而是默认信仰我不认为 AI 真的会像宗教一样建教堂、立神像。但“新宗教”这个隐喻的价值在于它提醒我们注意很多不需要论证的默认判断。比如现在团队开会时最常见的建议是“先用 AI 试一下”。写文档、写代码、做PPT、生成周报都要先让 AI 出一版。这本身非常高效但慢慢会变成一种条件反射一切任务都可以交给自动化管道。我们很少再问“这个任务是不是适合用 AI 做”“如果 AI 做错了谁负责发现错误”“这个流程持续跑一年会不会让团队丧失某些基础能力”。库哈斯描述“广普城市”时重点不是赞美它而是冷静地记录它如何被基础设施、资本和效率逻辑塑造。今天的 AI 应用也类似。它被资本和效率逻辑推动着迅速铺满每一个领域。我们看到的不是某一家公司的独立选择而是一种普遍的行业惯性不拥抱 AI 似乎就落后了不把流程自动化似乎就浪费了人力。这种惯性就是“效率崇拜”的日常形态。它不需要你去烧香只需要你默认“更快就是更好”。所以我说它是“新宗教”不是因为它要求你信仰某个神而是因为它让效率本身成为了不需要论证的前提。面对这样的变化我们要做的不是站队支持或反对而是像库哈斯一样把那座建筑拆开看看哪里是承重墙哪里是装饰哪里是应急出口。注意AI 不应该代替你思考它只是让思考的结果更快落到可执行的东西上。如果你真的这样使用它它才是一个工具如果你把判断权整个交给它它就变成了信仰对象。2. AI 应用空间把大模型、上下文和 Agent 放进同一个建筑里2.1 大模型是“空间”上下文是“面积”Token 是“租金”很多刚开始接触 AI 应用的人会把大模型理解成一个“什么都知道的数据库”。但实际上它是一个基于概率生成下一个 token 的系统。你可以把它理解成一栋巨大的建筑每个能力区域就是空间能同时放进空间里的信息量取决于上下文窗口。上下文窗口是有限的。它就像建筑里的可用面积Token 则是使用面积要付出的租金。每一次调用你输入的提示词、附带的资料、模型生成的回答都要消耗 Token。以为“把所有资料都贴进去模型就能更准确”是新手最容易踩的坑。你塞进去的内容越多面积占用越大成本越高关键信息反而可能被稀释。实际落地时我通常建议先做一个简单的信息裁剪先明确这次任务真正需要的字段和上下文是什么。把无关的背景描述删掉只保留会影响输出的部分。如果资料太长先用检索或摘要方式压缩再放入 Prompt。这不是因为我们不够有钱而是因为大面积无用的上下文会降低模型的注意力质量。库哈斯讲城市时同样强调密度不是无限制叠加而是需要设计。真正可用的空间不是最大的那一块而是布局最合理的那一块。2.2 Agent 像“空间中的活动”提示词是“设计图”单次调用大模型相当于你走进建筑里的一个房间完成一个动作就离开。Agent 则更像你在整个建筑里组织和安排一系列活动读取资料、调用工具、生成结果、校验输出、通知人工。它的价值不是“一次生成”而是“把多步判断组织成流程”。这就引出一个常见误解很多人以为 Agent 是万能自动执行器只要给一个目标它就能自己完成所有事。但实际运行中Agent 的每一步都需要明确的设计。你要告诉它目标是什么。可以调用哪些工具。哪些环节允许自动决策。哪些环节必须停下来等人确认。失败后是重试、跳过的还是整体退出。提示词在这个过程中就是“设计图”。它不是一段祈祷词而是一份空间使用方案。设计图越模糊施工就越容易出错。这也是为什么同样的底层模型不同团队用出来的效果差异很大。我以前做过一个小实验让一个 Agent 任务从“帮我优化这段代码”改成“先读取仓库结构定位负责这个函数的文件分析可能出现性能瓶颈的位置修改然后运行测试最后输出改动摘要”。两种写法的结果完全不同。后者更像一个真正的小组作业流程因为它给空间里的每个动作都划定了区域。2.3 给开发者的落地建议先画一张“空间使用图”在写具体代码之前我建议先画一张最简单的“空间使用图”。它不需要是正式文档甚至可以写在笔记里包含以下几个要素输入从哪来用户上传、数据库读取、API 回调还是队列消息。中间经过哪些模块预处理、构造 Prompt、调用模型、工具调用、输出解析。输出到哪里数据库、文件、消息通知、下游接口。异常分支超时怎么办限流怎么办校验不通过怎么办。人工确认点哪些输出需要人看一眼才能进入下一步。用伪代码表示就是一个非常基础的结构# 一个通用的 AI 处理流程伪代码示例 def run_ai_task(input_text, context): validated_input preprocess(input_text) prompt build_prompt(validated_input, context) result call_llm(prompt) return postprocess_and_validate(result)关键是你在一开始就要知道流程会在哪里断而不是等问题发生后再去猜。这个步骤看起来很简单但它决定了后续能不能稳定扩展。3. AI 幻觉不是“故障”而是“都市奇观”怎么和它共存3.1 为什么生成式 AI 注定会产生幻觉AI 幻觉是这个领域最容易让新用户困惑的问题之一。你问模型一个事实性问题它会用非常流畅、非常自信的语气给出一个错误答案。很多人第一反应是“这工具还不成熟”但实际上幻觉不是单纯的缺陷它是生成式系统的一种固有副产品。大模型的训练目标不是记住一个数据库而是学会在给定上下文时计算最可能的 token 序列。它更像是一个“可能性合成器”而不是“查表器”。库哈斯在描述曼哈顿时说过摩天楼的存在让城市叠加了虚拟与现实形成一种奇观。AI 生成内容也有类似特征它在统计空间里叠出了一段看起来合理、但未必对应现实的文本。意识到这一点很重要。因为如果你把 AI 当数据库幻觉就是灾难如果你把它当生成器幻觉就是一个必须被设计和管理的风险。工程上要做的不是彻底消灭幻觉而是在它可能出现的地方加护栏。3.2 四层排查输入、上下文、模型参数、输出校验当输出出现异常时我建议按下面的顺序排查而不是直接换一个更大的模型。排查层常见现象排查动作修复方向输入层输出与用户意图偏离检查输入格式、编码、截断、字段缺失增加预处理明确输入边界上下文层关键信息被忽略或冲突检查上下文是否过短关键信息是否被截断裁剪上下文重组摘要确保重点信息前置模型参数层输出过于发散或重复检查 temperature、top_p、max_tokens 等参数降低自由度设置更明确的输出约束输出校验层内容流畅但与事实不符检查有没有做结构化校验和关键字段检查增加规则校验、RAG 校验或人工审核点比如如果模型输出“三个选项”时只输出了两个先不要急着改模型。先看你的 Prompt 里是否明确要求三个并编号再看上下文里有没有例子干扰最后看参数是否允许更长输出。3.3 工程上怎么降低幻觉影响降低幻觉影响通常有四类做法检索增强生成RAG让模型在回答前先从自己的知识库里检索相关资料而不是凭空生成。这会大大减少事实性错误的概率。结构化输出约束要求模型用 JSON 或固定格式输出再做程序校验。如果字段缺失直接判定失败不让错误结果继续流转。低自由度参数在事实问答或代码生成场景中把 temperature 调低。在创意写作场景中才需要更高的自由度。人工审核节点在最终结果进入业务系统前设置一个人工确认点。尤其是高风险场景这一步不能省。一个很简单的校验逻辑示例# 校验示例要求输出必须包含关键字段 def validate_structured_output(output: str, required_keys: list[str]) - bool: try: data json.loads(output) return all(key in data for key in required_keys) except (json.JSONDecodeError, TypeError): return False这只是一个示意但它说明一个思路不要让生成结果直接变成最终结果而是先经过一层可执行的合法性检查。工程上我们要把 AI 当作一种“有想象力的中间人”而不是“可信赖的终审者”。风险提醒如果某个流程一旦出错会造成较严重的影响请务必保留人工复核环节并在设计阶段就确定好失败处理路径。4. 从单次调用到“事件空间”AI Agent 工作流的方法论4.1 为什么单次跑通不等于稳定可用很多人在尝试 AI 编程或 Agent 开发时最容易进入的误区是单次跑通就认为方案可行。但单次跑通只说明输入输出路径存在不说明这个路径在异常情况下还能保持可用。真实使用中会出现很多单次验证覆盖不到的问题并发访问时被限流或超时。某一条输入格式不合法导致后续任务全部失败。长时间运行后模型返回结果开始漂移。Token 成本超过预期但没有监控。模型升级后Prompt 行为发生变化。数据隐私和权限没有在流程中验证。库哈斯讲的“事件空间”是指城市中多种活动在同一个空间里冲突、重叠、共存的场所。Agent 工作流也一样当多个任务同时发生它们会争抢上下文、资源和服务额度。如果设计时只考虑了“一对一”场景那批量场景一定会出问题。4.2 三步法先跑通再可观测最后工程化我比较推荐所有 AI 应用都按照这个顺序演进不要跳步。第一步最小跑通。先用一条最典型的输入验证核心链路输入能进、模型能调、结果能出、输出格式能解析。这一步的目的是确认“这件事确实能做”。先不要加复杂分支也不要调高性能参数。第二步加入可观测性。给每次调用打日志记录输入摘要、输出前 N 个字符、耗时、Token 消耗、异常信息。这一步的目的是回答“当问题发生时我能不能知道发生了什么”。没有日志的 AI 流程就像没有消防通道的建筑。第三步工程化兜底。在跑通和可观测的基础上再逐步加入重试、熔断、权限控制、并发限制、审计记录、人工复核节点。这时候再去做批量任务才不会一塌糊涂。为什么这个顺序很重要因为如果你一上来就追求完整工程化你会发现需要处理的问题太多根本跑不完如果你一直停留在“跑通”阶段你就永远不敢把它放给真实用户使用。4.3 避免把 AI 变成“自动化宗教仪式”的检查清单在把一个流程交给 AI 之前我建议对照这份检查清单做一个审查。这不是为了限制使用而是为了防止把工具仪式化。结果最终由谁负责有没有明确到具体角色。失败时是自动重试还是停止并通知人工有没有成本上限单次任务费用失控时能否及时熔断用户输入边界怎么定哪些内容不能进入模型输出如何与业务指标对齐是人工抽检还是程序定时评估如果模型版本或供应商发生变化这个流程还能不能稳定运行团队有没有保留脱离 AI 的手工操作能力这些问题看起来不酷但它们是真实工程的核心。你可以热情拥抱 AI但不能把整个系统的稳定性建立在“AI 一定不会错”这个信仰上。一个实用的原则先跑通再可观测最后工程化。不要反过来。5. 效率的新边界什么场景不适合让 AI 做“主祭司”5.1 AI 适合解决什么不适合解决什么很多人会问“AI 到底适不适合我这个场景”我认为与其问“适不适合”不如问“失败代价高不高”“是否需要人的价值判断”。比较适合用 AI 的场景通常具备以下特征重复性内容生产比如初稿、摘要、分类。有一定容忍度的信息提取比如从长文中抽取关键字段。代码补全和模板生成比如写单元测试、补注释、生成固定模式代码。知识库问答在接入检索后能够给出有依据的答案。头脑风暴和发散思考帮助团队扩展选项。不适合的场景通常也有共同点需要极高事实准确性的最终输出比如医疗诊断、法律文书终稿、财务审计。需要承担法律或公共责任的任务。涉及复杂价值权衡的选择。需要长期记忆和稳定人格的互动。输入数据极其敏感且无法通过私有化部署或安全协议解决时。不是说 AI 在这些场景里完全不可用而是它更适合做辅助、打草稿、提供候选方案不能把最终决定权直接交给模型。5.2 警惕“同质化风险”库哈斯在广普城市中看到的问题库哈斯在描述“广普城市”时有一个关键观察当所有城市都被同样的基础设施、同样的交通系统、同样的商业逻辑塑造时城市会失去特征。你可以在任何一座现代化城市看到几乎一样的机场、CBD、购物中心。效率带来了便利也带来了同质化。AI 正在制造类似的问题。当越来越多团队使用同一个大模型、同一套 Prompt 模板、同一种生成策略输出内容会逐渐趋近于一个“平均答案”。你会发现很多 AI 生成的文章、方案、代码在结构和语气上惊人地相似。这种同质化在短期看效率很高但长期看它会削弱产品差异化和组织的独特判断力。避免同质化需要在 AI 使用策略上加入自己的规则建立自己的知识库和语料而不是只依赖模型的默认知识。定义一个明确的输出评价标准不同场景使用不同标准。让 AI 参与发散而不是直接替代收敛。保留团队自身的写作、代码评审和决策风格。库哈斯提醒我们基础设施会塑造行为。AI 作为新基础设施也在塑造我们怎么思考、怎么写、怎么设计。如果这个过程完全无意识那么最终产出的不是一个有独特气质的项目而是一堆流畅但无差别的 AI 拼贴。5.3 效率不是目的人的判断才是边界效率社会真正的风险不是效率不够高而是把效率当成了唯一的目的。AI 可以以一秒钟生成一百个答案但它不能替你决定哪一个答案是你真正想要的。那个决定需要你理解背景、权衡风险、照顾利益相关者的感受甚至需要你承担错选之后的责任。所以在团队里我比较建议做一件事写一份简短的“AI 使用边界”文档里面明确哪些环节可以用 AI哪些环节必须人工。不需要很复杂只需要描述清楚每个流程的责任边界。真正成熟的 AI 应用不是所有人都依赖模型而是所有人都知道模型在哪里会被切断、人工在哪里介入。AI 可以生成一百个答案但不能替你决定哪一个才是你想要的。6. 给要做 AI 应用的人一个可复用的判断框架6.1 从“AI 是新宗教”到“AI 是新基础设施”如果我们要继续使用库哈斯式隐喻我认为更健康的视角是这样AI 是新宗教只是一个现象描述而不是行动指南。真正值得采用的行动框架是把 AI 当成一种新基础设施。基础设施的特点是你需要它但也要为它建设容量、冗余、维护和逃生通道。你家里用电不会天天对着电表跪拜但你一定会关心电压是否稳定、有没有配漏电保护、断电后怎么应急。AI 应用也应该如此。评估一个场景是否值得接入 AI可以从四个维度打分维度问题判断方向任务可自动化程度这个任务是不是高度重复、规则清晰可自动化程度越高越适合失败代价模型出错会造成多大损失失败代价越高越需要人工复核数据私密性输入数据是否敏感是否可以私有化数据私密要求越高越要控制外发个性判断需求这个任务需要体现组织或个人独特判断吗个性越强越不能只靠通用模型这个框架不能替代具体评估但至少能帮你在接到一个“用 AI 优化某流程”的需求时快速建立判断坐标。6.2 落地时的最小清单无论你做的是 Cursor 这类 AI 编程工具还是基于 Spring AI 做企业级集成或者本地部署一个模型来处理隐私数据有一些清单是通用的明确输入输出的格式和边界。确认模型的能力边界不把“未知”当“支持”。在关键流程设置人工复核节点。记录日志和 Token 成本建立监控。设计失败响应路径重试、降级、停止。定期回顾输出质量更新 Prompt 和评估集。保留随时退出 AI 流程、回到手工模式的能力。这七条看起来简单但每一条都对应一类真实的线上事故。6.3 用“库哈斯式提问”做效率审查最后分享几个我平时会用来审查 AI 流程的问题它们来自库哈斯式观察的启发我们是在设计和建造一个空间还是只是把模板贴满每一面墙当一个流畅的 AI 答案出现时我们能否提出一个反对意见还是只能接受这个系统如果突然失效整个团队能在多长时间内回到可用的手工路径上我们投入的 token、算力和人力最后沉淀出的是产品能力还是只是过程仪式这些问题不需要立刻回答但它们应该被定期提起。因为 AI 应用的真实挑战不是如何把一个简单功能跑起来而是如何保证这个功能长期稳定、可控、有边界地运行。如果你正打算把一个重复流程交给 AI我建议你把这篇文章当成一次设计前检查。不要急着追求最大吞吐先画出空间结构标出边界和出口。AI 是效率社会的新宗教但真正值得建造的不是一座供奉 AI 的神殿而是一套能让人类更清醒地使用效率的基础设施。