为什么AI一键成图、一键出量仍是奢望？

最近半年，随着 “AI 赋能”的讨论越来越多，“一键成图”、“一键出量”、“自动审图”成了工程咨询行业谈论最多的想象。

这种美好的想象并不完全缺乏逻辑基础：只要信息已经充分进入系统，规则已经明确，所谓“一键”当然可以实现。打个比方，手机拍照也是一键完成。但按下快门的一瞬间，手机已经获取了数百万像素的传感器信息，并自动完成曝光、对焦、降噪、色彩处理和图像压缩。所以，“一键”只是一个交互概念，并不意味着系统只获得了一次点击确认，而是有其他途径可以取得“生成一张照片”所需的全部信息。

问题在于，工程咨询行业对“一键”的想象，往往不是把一个已经明确的设计结果自动绘制出来，而是希望在项目事实不完整、客户需求不明确、利益关系尚未协调、设计决策尚未发生的情况下，直接得到最终成果。

这才是真正的奢望。

AI 可以压缩行业中的共性知识，可以通过编程自动完成大量重复操作，也可以根据既有经验推测缺失的信息。但它不能凭空获得某个项目特有的事实，不能代替尚未发生的协商，也不能提前知道人类自己尚未形成的判断。这些信息，最终都必须通过调查、测量、文件、数据库、人工判断或者项目推进过程中的反馈进入系统。

一、一键成图为什么仍然不现实？

这里首先要区分两件事情：一是把已经确定的设计内容自动绘制成图；二是根据一个模糊需求，自动完成整个项目的设计。前者当然可以逐步实现，甚至本来就应该被大量自动化。后者则完全是另一种问题。

项目的最终需求，在项目开始时通常并不存在

人们经常假设，甲方或者设计人员脑中已经有一个完整答案，只是没有耐心把它描述出来。因此，只要有一个足够聪明的 AI，能够“理解意图”，就可以绕过漫长的沟通和设计过程，通过一次“坦率、完整”的 Prompt 表达，直接把最终答案画出来。

实际情况当然不是这样。

甲方不知道自己最终想要什么，设计人员也不知道最后应该形成什么方案。很多需求只有在看到第一版成果之后才会出现；很多问题只有在开始设计以后才会暴露；很多原本看似重要的目标，在成本、工期和现实条件面前又会被放弃。项目需求不是一个等待被完整读取的静态对象，而是在设计过程中逐渐形成的。

我在此前的《AI牛马驱使手记》中写过：问题的提出者同样需要答案的输入，才能产生新的问题。人类之所以无法一次性给出完美需求，并不只是因为表达能力不足，而是因为在没有真正参与项目之前，人类自己也不知道最终需求是什么。很多新的想法，正是在查看成果、发现错误、比较方案和不断试错的过程中才逐渐出现的。

人类在项目中的不可或缺性，有一部分恰恰来自人类自身的局限性。不是 AI 不理解我们脑中的答案，而是我们脑中暂时根本没有那个答案。

很多约束只有在项目推进过程中才会出现

一个设计项目开始时能够收集到的，只是部分初始条件。随着项目逐步深入，新的信息还会不断进入：比如，外业调查发现了原来没有记录的现场条件；初步计算暴露出某个方案无法满足规范；施工组织分析发现原定方案难以实施；技术经济比选导致技术路线发生变化；部门审查提出新的要求；甲方调整了建设目标；利益相关干系人提出反对意见……等等。这些信息并不是一开始就存在于某个尚未写好的 Prompt 中。它们需要通过项目活动才能产生。

设计并不是做题，只是根据已知条件求解答案。设计过程本身也是一个获取信息、制造信息和重新定义问题的过程。

要求 AI 在项目开始时就一次性完成设计，相当于要求它提前知道尚未完成的调查结果，提前作出尚未经过讨论的价值选择，并提前获得只有在试错之后才会产生的认识。这不是生成能力的问题，而是时间顺序和信息来源的问题。

很多设计问题根本没有唯一的技术答案

设计项目通常同时面对多个相互冲突的目标：成本要低，质量要高；工期要短，施工风险要小；占地要少，又要有经济性；建设方希望顺利推进，运营方则希望使用便利……这些目标之间从来就不存在天然统一的换算关系。

少征一亩地值得增加多少建安费？缩短三个月工期值得承担多大的技术风险？主体工程的节约与三改使用的便利之间如何权衡？这些问题不能仅靠技术计算得到答案。它们涉及客户偏好、组织利益、制度权力和责任承担。

在利益主体尚未完成协调之前，所谓“最终设计要求”根本没有形成。AI可以生成若干候选方案，也可以分析各个方案的后果，但它无法仅凭模型参数推导出各方最终应当接受哪一个方案。当信息不足时，AI 往往会使用行业中的常见模式和平均偏好生成选择，其成果可能看起来专业、完整，甚至非常合理，却未必适合当下这个特定项目。

未来的主要生产形态仍然是分步进行

因此，未来咨询行业的主要生产形态，不会是人类在项目开始时提交一份超级 Prompt ，然后等待AI吐出最终成果。更可能的形态是，人和 AI 共同把问题逐步说清楚：系统首先读取已有资料，生成初步分析和候选方案；人类对关键事实、约束和方向进行确认；AI 根据新的约束继续计算和生成；新的结果又暴露新的问题，人类再次判断。

这个过程仍然是渐进的、分阶段的，而且在方向选择、冲突协调和责任确认上仍然由人主导。AI 可以让每一步变得更快，甚至可以让许多局部步骤实现“一键完成”，但它不能把一个尚未被定义的问题直接变成确定的最终成果。

未来真正可行的，是在项目的每一个阶段，让已经确定的信息自动流向下一步，让机器完成可以确定的部分，同时及时暴露仍然需要人类判断的不确定部分。

二、一键出量的瓶颈，不是没有三维模型

相较于一键成图，一键出量看起来似乎更容易实现。工程量看起来只是一个计算问题：把图纸交给 AI ，让它识别构件、读取尺寸、套用计算规则，最后输出工程数量。

但这里同样存在一个经常被忽视的问题：传统项目成果并不是为机器计算而设计的信息表达。

图纸只是一种面向“人”的成果表达

以结构设计为例，工程图纸通常由平面、立面、侧面、剖面、节点详图、附注和设计说明共同组成。一个有经验的工程师可以在不同图纸之间来回查找，根据图例、索引、行业惯例和上下文，把这些分散的信息重新拼接成对某个构件的完整理解。

但是，这种“完整”主要存在于人的理解中。

构件在几张图之间是什么对应关系，某一处尺寸适用于哪个范围，某个附注修改了哪些构件，某种材料说明是否覆盖全部同类对象，很多时候并没有一个统一、明确、事先约定的结构化表达。信息也许都有，但它散落在不同图纸中，隐藏在设计习惯里，常常依赖专业人员的默会知识才能被正确整合。

对有经验的人类来说，这是可以理解的图纸；对于程序来说，却未必是可以确定计算的数据集。

AI 推断不等于信息完备

有人会说，我们可以训练 AI 识别这些图纸，搞一个所谓新的“基座大模型”，让这个 AI 推测不同视图之间的对应关系，根据行业经验推断构件形状，也可以通过附注补全一些缺失属性。

先不提训练一个这样的“基座大模型”的成本可能需要“举国之力”，即使它真的训练出来了，也不可能达到 100% 的准确。问题不在于大模型看过的工程图纸够不够多，而是由当下大模型的基本原理决定的：再怎么训练，模型仍然只能学会“通常情况下应该怎样理解”，仍然不能完全掌握当前项目中某个特定的表达所代表的信息关联。

而工程量计算要求的是确定性，是“完全准确”，而不是“几乎准确”。一段构件被重复识别、一个扣除规则没有执行，或者一个附注的适用范围被理解错误，都可能让最终结果出现系统性偏差。而且，如果直接让大模型通过识别图纸来执行这项任务，可能还难以审计它究竟错在哪里。

任何 AI 系统如果需要靠“猜测”才能补全关键数据，那么最终工程量就始终带有不确定性，就必须经过人工复核。所以，把成果图纸丢给 AI 自动出量，这条路径没有出路。

正确的道路不是从成果图纸重新猜回去

现有设计软件在生成图纸之前，内部通常已经存在大量比图纸更丰富的中间数据。对象的坐标、尺寸、类型、图层、属性、关联关系和计算过程，可能曾经以某种形式存在于设计软件或者中间文件中。但在输出为 CAD、PDF、Word 之后，这些结构化信息往往被压扁成了线条、文字和图形。

成果图纸是生产过程的最终呈现，不是最适合程序重新计算的原始数据。

因此，一键出量的正确路径，是应该尽可能在信息被压扁为成果图纸之前，把设计工具中的中间数据保留下来。这需要逐步开放现有设计工具的 API（或者可以重新单独设计处理特定数据文件的接口），读取其内部对象和中间数据文件，将构件身份、几何关系、材料属性、设计阶段、计量范围和版本状态等信息导出。这样，机器掌握的结构化信息就比单纯读成果图纸增加了一个数量级。

但可能仍然不够。程序内部存在的中间数据，由于并非为“信息完备”而设计，它显然不直接等于可计量对象。某个对象属于哪个计量项目，采用什么计量规则，是否需要扣除，是否属于本次实施范围，是否只是辅助线或者临时对象，这些信息仍可能需要人工确认。因此，在中间数据文件之上，还缺一层人工构建的信息结构。

这件事情，还从未有人系统性地做过。在一些特定场景下，已经有人在尝试了：比如公众号 Structura AI 公众号曾经开发过一个“PySap2000 库”，差不多干的就是这一类事情。人工的确认过程被封装在了一系列高度封装的函数里，完成了零散数据到准确结果的中间层。

当然，更优雅的方式不是静态封装，而是设计一个动态交互系统：AI 先完成对象分类和属性补全，对无法确定的少量问题发起确认；设计人员根据提示处理例外情况，而无需重新填写全部项目数据。人工确认一旦完成，这些信息就可以进入确定性的计算程序，最终生成工程量。

工程量需要的不是BIM，而是最小可计算模型

谈到结构化工程信息，人们很容易立刻想到BIM。这不难理解：我都三维建模了，那生成工程量还不是手拿把掐？

但 BIM 只是实现结构化信息的一种方式，并不是工程量计算的必要前提，甚至也不是充分前提。

为了构建一个完整三维模型，设计人员往往需要补充大量几何细节、空间关系和显示信息，工作量十分巨大。这些信息对碰撞检查、施工模拟或者可视化可能有价值，对于某一项工程量计算却未必真的需要。反过来，一个三维模型即使几何上非常完整，如果没有明确的计量范围、构件分类、材料属性、扣除规则和版本状态，也仍然不能直接得到可靠工程量。

三维模型和可计算数据集不是一回事。工程量真正需要的是一个针对计算目标信息完备的数据集。这里所说的信息完备，是指所有一旦发生变化，就会改变工程量计算结果的信息，都已经以机器可以读取的方式进入系统。它可以包含几何信息，也可以只包含长度、面积、断面和数量关系；它可以引用二维对象，也可以包含局部三维构件，但没有必要为了“像 BIM”而构造一个远超计算需要的完整模型。

BIM可能是这个模型的一个超集，却不应当被当作唯一答案。

三、为什么必须走自下而上的道路？

既然一键成图依赖持续产生的项目约束，一键出量又依赖生产过程中形成的结构化数据，那么企业 AI 系统就不可能仅围绕最终目标自上而下建设。

不能先提出“一键出报告”、“一键出图”、“一键出量”的顶层目标，再要求生产人员把实现目标所需的一切信息重新填进系统。这条路在逻辑上就走反了。

上层环节的输入，来自下层环节的输出

任何一个上层生产环节所需要的信息，严格来说都来自更底层的生产活动。这些信息可能是人工判断的结果，可能是程序计算的结果，也可能来自甲方、现场调查或者其他外部干系人。

如果企业始终围绕顶层目标设计自动化系统，那么就必须在顶层重新搜集和整理所有输入。由于这些输入散落在文件、聊天记录、个人电脑和工程师脑中，整理它们本身就会形成巨大的额外工作量。这种系统表面上是在自动化顶层工作，实际上只是把工作量转移给了负责喂数据的人。

真正合理的方式，是把自动化工具逐步嵌入最基础的生产环节。当设计人员处理表格、修改参数、判断照片、参加会议或者确认方案时，原始信息就应当顺手以某种结构化形式形成。上层系统不再要求人重新总结一次，而是直接读取下层工具已经产生的数据。

所谓自下而上，是从一个个真实生产动作开始，让信息在产生的地方就留下可计算、可追溯的记录。

信息量和结构化程度是两个不同维度

实现一个顶层自动化目标的难度，至少取决于两个维度。第一是这个目标需要多少项目特有信息；第二是这些信息的结构化程度。

如果所需信息很多，但已经存在于字段明确、关系清晰的数据库中，那么程序依然可以快速处理；如果所需信息不算多，却散落在几十份 PDF、会议纪要、聊天记录和个人记忆中，那么系统仍然很难可靠完成任务。

此外，自动化难度还与结果的容错要求有关。结果越不允许出错，系统越不能依靠猜测弥补结构缺失。AI可以降低非结构化信息的处理成本，却不能完全消除结构的重要性。尤其是在工程量、设计校核和正式成果编制等低容错场景中，稳定的结构化数据仍然是最终确定性的基础。

自下而上的工具体系，其价值之一就是用实际生产过程倒逼信息逐步结构化，而不是到了顶层环节之后再反复去做昂贵的信息挖掘。

生产工具必须首先服务生产人员

传统企业信息系统通常从管理需求出发。管理层希望知道项目进度、人员投入、任务状态和成本情况，于是要求一线人员填写表格、更新状态、上传材料。这类系统即使给生产人员增加了一些负担，也可能通过行政要求强制推行。因为管理需求本身是刚性的，而且填写的信息通常有限，成本尚可承受。

但纯粹面向生产自动化的系统不能沿用这种逻辑。

为了实现真正的“一键出图”或者“一键出量”，需要搜集的基础信息极其庞大。假如这些信息都依赖生产人员额外填写，结果可想而知：填写工作迅速膨胀、一线人员把系统视为负担产生强烈抵触心理、应付式填报导致数据质量不断下降、管理层投入大量成本监督执行……最终只能得到一个看起来光鲜亮丽而实际完全不可用的数据系统。

生产工具不能依靠管理权力证明自己的价值，它必须首先在一线场景中替使用者节省时间。它要求用户多做的每一个操作，都应该同时替用户省掉更多操作。它采集的数据，应当尽可能成为正常生产活动的副产品，而不是额外布置的信息填报任务。能从设计软件中直接取得的数据，就不应再让人填写；能从会议录音中提取的内容，就不应再让人抄写；能从操作过程自动判断的状态，就不应再增加一个下拉菜单。

只有在系统确实无法确定，而且这个问题会影响后续结果时，才应当请求人工确认。

所以，正确的建设顺序不是先建一个宏大的数据平台，再要求一线人员持续喂养它，而是先做一线人员愿意使用的生产工具，再让结构化数据体系从工具的使用过程中逐步生长出来。

四、自动化工具的三层价值

企业在讨论AI自动化时，常常把性质完全不同的能力混在一起。识别一张照片、自动计算一项工程量、整理会议待办和提出谈判建议，都被笼统地称为“AI赋能”。但这些工作的确定性、验收方法和责任边界完全不同，并不适用同一套标准建设，我们应该进一步厘清其不同的价值场景，才能更准确地想象那个并不遥远的未来。

自动化工具大致可以分为三个层次。

第一层：消灭确定性的重复工作

第一层最容易理解，它针对是那些可以被清晰描述、明确定义和直接验收的问题。例如，在不同专业之间转换数据、按既定规则生成表格、批量处理CAD、执行明确的工程计算、对结构化数据进行校验、生成固定格式的成果、检查缺项、重复项和格式错误……等等，这类工作应该尽量使用确定性程序完成。

AI 可以帮助编写程序、识别输入或者处理异常，但核心结果应当能够根据明确规则复现和验证。这一层自动化的目标不是“像人一样思考”，而是彻底消灭不值得人重复进行的操作。它显然也是企业最应该优先建设的一层，因为它最容易衡量价值，同时会自然产生后续系统需要的结构化数据。

第二层：简化仍需人类确认的工作

第二层是 AI 可以完成大部分初步工作，但仍然需要人类确认的任务。例如，对外业照片进行初步判读、对房屋拆迁进行初步筛选与编号、从会议纪要中提取待办事项、根据资料生成报告初稿、核对合同与报价文件、将非结构化资料映射到标准字段……等等，这类工作的合理目标不是完全取消人工，而是改变人工介入的方式。

过去，人需要从零开始完成全部工作。以后，程序可以先生成一个初步成果，并标出低置信度内容，人做内容检查、处理例外情况并作出最终确认。人工工作从“全面生产”转变为“重点审核”。如果系统设计得当，人类只需要把注意力集中在少量真正有歧义、有风险和有项目特定性的内容上。

第三层：为模糊性工作提供认知支持

第三层是无法被完全标准化，也不存在唯一正确答案的工作。例如，对外沟通、商务谈判、合同策略、方案取舍、风险权衡、组织协调、特定复杂问题的处理……对于这类任务，AI 的价值不能替人作出最终决定，但可以提供最佳实践、相似案例、风险清单、候选策略和不同选择可能造成的后果。

它可以提醒一个缺乏经验的项目人员：“过去类似项目中通常还需要关注这些问题”；也可以帮助资深人员快速检索公司内部曾经如何处理相似冲突。越往上层走，AI 的角色越接近认知辅助，而不是自动执行。

五、真正的复利价值是可动态更新的AI数据资产

自动化工具解决的是眼前的生产效率问题。但如果这些工具能够持续积累项目中的中间信息，它们还会形成另一个更长期、更难复制的价值：企业自己的AI数据资产。

这里所说的数据资产，不是说把公司现有文件全部扔进一个向量数据库，或者单纯建设一个能够搜索以往项目文档的所谓知识库。真正有价值的，是在生产过程中自然形成的、结构化的、能够持续更新的项目经验。

经验不再单纯依赖资深工程师主动整理

咨询行业长期依赖资深人员的项目经验。这些经验往往不在正式成果中，而在他们对异常情况的敏感性、对风险的判断、对方案的取舍以及对历史教训的记忆里。

企业当然希望资深工程师把这些经验整理出来，但这种愿望通常难以实现。一方面，资深人员日常工作已经很忙；另一方面，要求一个人的核心经验被完整标准化，本身也与组织中的个人激励存在冲突。指望总工们主动花费大量时间，把自己最有价值、最难替代的能力整理成一套任何人都可以使用的系统，往往并不现实。

自动化工具提供了另一条道路。

当资深工程师使用工具审查成果时，他修改了什么、否决了什么、补充了哪些条件、在哪些地方要求重新计算，这些行为本身就可以沉淀为经验。最终成果只能记录了“是什么”，而过程数据还可以记录“为什么”。比如，哪些候选方案被放弃了？为什么被放弃？哪些AI的判断被人工修正过？什么情况触发了例外处理？哪些风险在什么阶段被发现？某个结论依赖了哪些事实？……真正宝贵的经验，从来都不在标准答案里，而是在偏离标准答案的原因里。

系统最应该积累的，不光是最终文件，而是人类对机器结果作出的修改、确认和否决的过程，以及这些决定背后的理由。

这种经验沉淀不要求资深人员专门撰写教材。一个精巧的自我迭代的系统，应该让它发生在正常生产过程中，是工作本身的副产品。

数据资产可以在使用过程中持续更新

一个可用的AI知识体系不应该是项目启动时整理一次、几年后逐渐过时的静态资料库，它应当从两个方向持续更新。

一个方向当然来自公司内部的新项目。这些项目不断产生新的中间数据、新的例外情况、新的处理方式和新的人工修正。每一个使用者与系统的交互，都有可能为下一位使用者增加一条可复用经验。

另一个方向来自外部环境。行业规范、技术路线、政策要求、市场情况和最佳实践都在变化。系统可以主动检索新的公开资料，在与设计人员交流时发现知识缺口，并把可能需要更新的内容提交审核。

需要注意的是，自动发现新知识，不等于未经审核就自动修改公司的可信知识。动态更新的知识体系必须保留来源、时间、适用范围、版本和审核状态。互联网新内容可以先进入候选资料区，经过验证后再进入正式知识层。否则，所谓“自我更新”容易变成持续污染。一个可靠的AI数据资产，需要区分原始资料、AI推断、项目人员在交互中确认的信息、公司审核通过的方法、已经过期或者存在争议的知识，唯有如此，系统才能在持续学习的同时保持可追溯性。

它的价值由此产生复利：每一次使用不仅利用了已有知识，同时也为系统增加新的经验。后来的使用者能够继承此前所有使用者已经确认过的判断，而不必从头开始。

自动化工具可以成为公司知识产权的边界

云端的通用大模型具有强大的推理和语言能力，但它不应该是企业全部核心数据的长期“经手人”。如果这样做，等于将产自于企业的高价值数据无偿贡献给了大模型厂商，严重威胁企业的技术壁垒。

更合理的架构是，让本地自动化工具成为整个系统的手和脚。项目文件解析、设计软件连接、原始数据处理、规则计算、权限控制和过程记录尽量在公司的本地系统中完成。出于效率和质量的考虑，大模型可以基于案例数据辅助开发工具，一旦工具开发完成就退场；或只在必要时取得经过筛选的最小必要上下文。这可以显著减少模型接触公司完整知识体系的机会。

公司的 AI 核心资产将包括：对项目数据的结构化方式、自动化工具掌握的业务流程、经过验证的计算规则、历史项目积累的例外情况、人工修改形成的判断经验，以及从事实到结论的完整证据链。大模型可以被替换，本地工具可以调用不同模型，但公司的业务逻辑、项目记忆和方法体系仍然留在公司内部。

如此，企业才能建设一个不依附于某个大模型的知识库，而是一套以本地工具为生产入口、以结构化数据为核心、以大模型为推理能力的组织操作系统。自动化工具是它的手和脚，动态数据资产是它的记忆，大模型则只是其中可以不断升级和替换的大脑模块之一。

六、千里之行，始于足下

“AI 发展太快了。”
“是啊，5 年后我们全部得失业。”
“我看，5 年都用不了！”
“唉……”

这样的对话每天在身边发生。但从尚能生存的当下，到所谓全部失业的未来，中间会发生什么？我们看当下清晰，看远景也很清晰，唯独看近期是一团乱麻，需要投入真正深刻的思考，才能将它一点一点解开。

一键生图、一键出量、自动审图，这些想象在未来当然最终都会实现，但它们却不是今天建设系统的起点。工程咨询行业的 AI 转型一定会消灭很多岗位，但不会消灭所有人。未来行业的主要生产形态，不会是 AI 脱离人类独自完成整个项目，而会是一种人为主导、分步推进、持续确认的生产过程。自动化系统的上下文，一定是从生产一线开始，从最小的工作环节开始，从信息第一次产生的位置开始。

自动化也是逐步发生的：先消灭确定性的重复操作，再用AI简化需要人工确认的工作；先让一线工具自然产生结构化数据，再让上层系统读取这些数据；先形成可靠的信息链条，再逐步实现更复杂的自动化目标。在这个过程中，机器负责处理共性，人负责确认特性；机器负责生成候选结果，人负责作出价值判断；机器负责记住已经发生的一切，人负责决定下一步应该向哪里走。

让确定的信息自动流动，让尚未确定的问题及时暴露，让人的每一次介入都发生在真正需要判断的地方，并让每一次判断都沉淀为公司下一次可以复用的能力。到了那一天，“一键”就会真的会出现。不是 AI 凭空创造了一切，而是整个生产体系终于提前完成了这一键所需要的全部准备。

至于减少了的这么多岗位上的人未来何以自处，这是人类的“新经济学”需要回答的问题。