为什么笃定 AI：企业真正需要的是什么

为什么笃定 AI？

我的判断来自企业需求与技术能力在这一阶段真正发生了交汇。

企业的大量工作依赖语言理解、非结构化资料和专业判断：阅读简历与合同、理解客户意图、比较候选方案、归纳复杂信息，以及根据上下文处理例外。这些任务长期存在，也直接影响效率、质量和收入，但传统软件很难用固定规则经济地覆盖，因此主要依赖人工完成。

大模型改变了这类问题的可实现性。它不再只解决某个预先训练好的单点任务，而是能够通过自然语言这一通用接口完成理解、抽取、生成、推理和结构化输出；随着 Tool Use、长上下文、多模态和代码能力进步，模型还可以连接企业数据与业务系统，在环境反馈中继续完成多步骤任务。

这意味着，一批过去只能由人处理，或者因为单位成本过高而无法充分处理的工作，开始出现通用、可扩展的软件实现路径。企业可以提高信息处理覆盖范围，让专业方法服务更多任务，并把人的时间留给例外、高风险决策和关系建立。

这就是我笃定 AI 的根本原因：

大模型正在把语言理解、知识处理和部分专业判断转化为通用的软件能力，从而扩大软件可以处理的问题范围，并降低认知工作的边际成本。

这里包含两步，缺一不可。模型能力的突破使这些任务从“很难实现”变成“技术上可行”；企业再通过业务知识、Context、Tool、Harness 和 Evals，把通用能力转化为可控、可复用、能够产生结果的生产系统。

这并不意味着某一套实现会长期不变。底层模型及其 API 会持续升级；当模型的推理、Tool Use 和上下文能力发生变化时，Agent Harness 中原有的路由、Prompt 补丁、工具策略和运行边界也需要重新评估；建立在其上的业务应用，则仍要独立验证用户需求、使用效果和投入产出。

因此，我看好的不是某个固定模型、Agent 架构或短期产品，而是更稳定的长期关系：企业对信息处理、专业判断和知识复用的需求持续存在，模型解决这些问题的能力不断提高，企业再通过持续演进的工程系统将其转化为生产力。

软件正在从执行规则走向参与认知工作

传统软件最擅长的是确定性任务。

字段明确、规则稳定、过程可枚举时，我们可以通过代码、数据库和 Workflow 获得可靠结果。例如计算价格、校验库存、执行审批、更新订单状态。这些任务不需要 AI，强行引入模型反而会降低确定性。

但企业中还有大量工作并不符合这种结构：

阅读简历、合同、报告、邮件和客户反馈；
理解不同表达背后的真实意图；
比较多个候选方案并给出理由；
根据上下文生成、归纳和解释；
面对例外情况判断下一步应该做什么。

这些任务不是没有规则，而是规则很难被完整写出。一个有经验的招聘顾问判断候选人是否适合某个职位，不只是匹配几个关键词。他还会结合行业背景、经历连续性、技能迁移、职位阶段和企业偏好。很多判断存在于经验里，而不是数据库字段里。

过去，软件只能管理这些工作的输入、流转和结果，真正的理解与判断仍由人完成。AI 带来的变化是：软件开始能够参与其中的认知过程。

它可以先理解非结构化信息，形成结构化判断或建议，再由确定性系统负责数据、权限、规则和执行，由人负责目标、价值判断与高风险责任。

这不是“用 AI 替换所有软件”，而是软件能力边界的一次扩展。

企业需要 AI，因为认知工作的供给长期受限

企业里的很多问题，并不是不知道应该怎么做，而是没有足够的人力把正确方法应用到每一项任务上。

一个资深顾问知道怎样分析职位需求，但没有时间逐份检查人才库里的所有简历。一个销售负责人知道怎样研究客户，但团队不可能在每次沟通前都完成同等深度的准备。一个技术负责人知道怎样审查方案风险，但很难参与每一次设计和代码变更。

这造成了几个长期存在的问题：

大量信息因处理成本过高，只能抽样阅读或直接忽略；
专业方法依赖少数有经验的人，难以稳定复制；
同一类任务由不同人员处理时，质量差异很大；
个性化分析成本过高，只能提供标准化结果；
专家长期被重复整理工作占用，无法聚焦高价值判断。

AI 的价值不只是让一个人节省几分钟，而是改变认知能力的供给方式。

过去因人力限制而无法逐条处理的信息，可以先由 AI 批量分析，再由人聚焦高价值和高风险部分。过去只能依靠培训和人工协作传播的方法，可以逐步沉淀成 Prompt、规则、Skill、Tool 和评估标准，在更多任务中被使用。

这种价值可以概括为三个变化：

提高覆盖范围：让过去没有经济条件处理的信息进入分析流程。
降低专业能力的使用成本：让更多员工和客户获得基础的专业辅助。
释放专家时间：把人的注意力从重复整理转向判断、沟通、关系建立和责任承担。

这也是为什么 AI 的价值不能只用“节省工时”衡量。它还可能带来过去无法提供的服务范围、更一致的执行标准，以及更低成本的个性化能力。

隐性知识显性化，才能形成可复用的企业能力

企业采用 AI 后，一个很容易被忽略的问题是：模型并不知道企业内部真正有效的工作方法。

很多重要知识没有写在文档里。它可能存在于专家的经验、团队的沟通习惯、历史案例和对例外情况的判断中。员工可以通过长期协作逐渐理解这些知识，但通用模型无法凭空获得它们。

因此，企业 AI 的核心工作之一，是把隐性知识逐步转化为可被系统使用的显性资产：

当前场景的目标、原则和约束；
一类任务的 SOP、判断步骤和例外处理；
业务能力的输入、输出和权限边界；
优秀案例、失败案例和验收标准；
哪些环节可以自动执行，哪些必须交给人负责。

但显性化不等于把所有经验写进一个超长 Prompt。不同知识需要不同载体：场景目标可以进入 Prompt，可复用方法可以沉淀为 Skill，可执行能力需要定义为 Tool，确定性规则和权限应保留在代码与 Runtime 中，质量标准则需要进入 Evals。

只有这样，这些知识不仅仅停留在文档里，还能在实际任务中被检索、调用、验证和持续更新。

这也是企业 AI 与普通模型调用之间的重要差别。模型能力越来越容易获得，企业真正独特的是自己的业务知识、工作流程、反馈数据和质量标准。它们不能全部被笼统地放进 Context，而应分别沉淀为 Prompt 与 Skill、可检索知识、Tool 契约、确定性规则和 Eval 数据集，再由运行时根据任务装配和使用。

在 Agent 系统中，这个模型外部的生产环境通常可以概括为 Harness。它不只是一次 Tool Calling 的封装，而是统一管理 Context 选择与压缩、Tool 执行、任务状态、权限与 Sandbox、HITL、重试与恢复、可观测性以及评估反馈。业务知识资产化解决“系统依据什么工作”，Harness Engineering 解决“模型如何在真实环境中持续、可控地工作”。两者共同决定通用模型能否转化为企业能力。

AI 还在改变软件本身的生产方式

企业需要 AI，不只因为它能被放进产品和业务流程，也因为它正在改变软件如何被生产。

AI Coding 已经显著降低了实现、试验和迭代的成本。过去需要数天完成的原型，现在可能在数小时内得到验证。开发者可以更快阅读陌生代码、生成测试、比较方案和定位问题。产品与业务人员也能更直接地参与早期验证。

但实现成本下降，不代表技术工作变得不重要。真正稀缺的能力正在向上游和系统层移动：

选择值得解决的问题；
理解真实业务约束；
判断应该使用规则、Workflow 还是模型能力；
为 Agent 提供有效 Context、Tool 和运行边界；
建立评估和反馈循环；
对最终结果和风险负责。

换句话说，AI Coding 降低了功能实现成本，也使技术工作的重心进一步转向三个问题：为什么做、怎样设计，以及如何证明有效。

因此，我看好 AI，不只是因为它带来了新的产品能力，还因为它正在改变软件的生产方式、知识的整理与传递方式，以及团队的协作方式。

企业是否采用 AI，要同时回答五个问题

看好 AI 的长期方向，不等于每个具体场景都应该使用 AI。

AI 是概率性能力。它可能生成错误内容、误解意图或作出不稳定判断。越靠近业务执行和高风险决策，越不能只凭一次演示判断价值。

企业面对一个场景时，至少应该回答五个问题：

1. 价值

这个任务是否包含高成本、难以用固定规则覆盖的认知工作？如果现有代码和 Workflow 已经可以稳定、低成本地解决，通常没有必要引入 AI。

2. 能力组合

任务需要模型完成什么？是理解、抽取、判断、生成，还是需要进一步结合企业数据和外部工具？不要因为一个环节使用了模型，就把整个系统设计成 Agent。

3. 自治程度

哪些步骤必须由确定性代码或预定义 Workflow 控制？哪些决策确实需要模型根据上下文动态完成？合理原则是 Minimum Necessary Autonomy（最小必要自治）：只给系统完成目标所必需的动态决策空间。

4. 控制

错误能否被检测、限制、人工接管或安全降级？涉及金钱、权限、客户权益和不可逆操作时，必须明确人的责任和系统边界。

5. 证据

相比人工、规则和原有系统，AI 是否真的提升了质量、效率、覆盖范围或业务结果？技术指标最终必须连接任务成功率、人工修复率、采用率、成本或转化，而不是停留在“模型回答看起来不错”。

这五个问题把“要不要做 AI”从趋势判断变成了业务判断。

判断只有进入生产，才可能形成企业价值

理解“为什么需要 AI”只是起点。如果不能继续回答“在哪个业务环节使用、怎样进入生产、如何证明有效”，方向判断仍然无法转化为企业价值。

从判断到结果，需要经过一条完整链路：

AI 的长期能力变化
→ 企业中值得解决的认知任务
→ 人工、规则与旧系统的业务基线
→ 模型推理、检索、Tool 与编排方式的组合
→ 业务知识资产化与 Harness Engineering
→ 真实用户和业务流程
→ 质量、效率、覆盖范围与业务结果

这条链路中，每一步都有不同的失败方式：

场景判断错误：团队可能用 AI 解决一个并不重要的问题；
业务知识没有显性化：模型只能给出缺少业务深度的通用答案；
系统边界不清：Agent 可能把概率性判断直接带入高风险操作；
缺少评估体系：团队无法区分演示中的偶然成功与可重复的稳定效果；
没有进入真实流程：即使模型效果很好，也难以转化为用户采用和业务结果。

因此，企业真正需要的并不只是“会调用模型”的开发者，而是能够连接方向、业务和生产的人。他需要完成四类工作：

判断方向与边界：理解 AI 能改变什么，也知道什么不应该交给 AI；
完成场景和知识建模：把业务目标、专家经验、数据、风险和验收标准表达清楚；
设计并实现生产系统：组合模型、检索、Tool、Workflow 或 Agent，并通过 Harness 统一治理 Context、执行、状态、权限、HITL、恢复、观测与评估反馈；
对结果负责：把技术表现连接到质量、效率、覆盖范围、采用率和业务结果，并根据反馈持续演进。

AI 技术会继续降低实现门槛，但这条从方向判断到业务结果的链路不会自动完成。能够跨过这些环节，才是 AI 时代技术负责人、架构师和 AI Builder 的核心价值。

应用团队不押注模型，而是判断能力如何转化为价值

我之所以笃定 AI，是因为大模型能力持续跨过真实任务的可用阈值，软件能够处理的认知任务正在增加，专业能力被复制和使用的成本也在下降。这个底层变化已经使新的产品与工作方式成为可能。

对企业 AI 应用团队来说，基础模型主要由模型厂商提供。我们的职责不是判断哪家厂商最终胜出，也不是参与基础模型训练，而是持续理解模型能力边界，并回答两个更贴近业务的问题：当前模型在哪些任务上已经达到可用水平，以及怎样把这些能力适配到企业场景并形成可验证的价值。

这需要完成几类判断：

任务适配：模型适合承担理解、抽取、生成、判断还是动态决策？哪些部分仍应交给规则、Workflow 或人？
模型选型：在代表性任务上比较质量、稳定性、时延、成本、数据安全和供应商约束，而不是只看公开 Benchmark；
系统适配：通过模型抽象层和 Harness 隔离厂商差异，围绕 Context、Tool、状态、权限、HITL 和 Evals 形成生产系统；
持续演进：模型升级后重新运行评估集，判断哪些 Prompt 补丁、路由规则和自研机制可以简化或删除；
价值验证：将模型表现连接到任务成功率、人工修复率、处理成本、采用率和业务结果。

因此，模型是不断改善的基础能力，而不是企业应用的最终价值。企业真正需要负责的是场景选择、能力适配、生产工程和结果验证。即使模型足够强，如果任务不重要、业务知识不足、系统边界不清或没有进入真实流程，也不会自动带来增长。

我笃定的是以下几个长期变化：

软件正在获得理解和处理非结构化任务的能力；
专业认知能力的复制和使用成本正在下降；
企业的隐性知识可以逐步变成可复用的软件资产；
AI Coding 正在降低软件生产与验证成本；
业务判断、系统边界、Context、评估和治理会变得更加重要。

不过，每个场景是否值得采用 AI，都必须由实际结果验证。如果一个 AI 方案相比规则和人工基线没有稳定增益，如果错误成本无法控制，如果数据和评估条件不足，或者用户根本没有持续使用，就不应继续扩大投入。

随着模型进步，团队也应该重新评估旧设计。一些过去需要复杂 Prompt、规则路由或自研补丁解决的问题，可能已经被模型原生能力覆盖。长期投入 AI，不代表不断增加复杂度，也包括及时删除已经没有必要的机制。

真正可靠的长期判断，不是相信所有问题最终都会变成 Agent，而是确认模型能力正在改变软件和知识工作的基本结构，同时坚持用证据判断每个场景，明确 AI 的使用边界，并在效果不达标时停止投入、缩小范围，或者退回规则与人工流程。

企业为什么需要 AI，最终可以收敛成一句话：

在可验证、可控制的前提下，把过去难以规模化的认知工作转化为可复用的软件能力。

这比采用哪一个模型、框架或产品更值得长期关注。