近期进行了三场企业AI咨询，内容覆盖通用AI知识普及、研发团队AI项目方法论的分享、以及具体项目的技术路径探讨。结合近期对各类型公司的走访观察，我梳理出以下几点或许值得分享的体悟：

企业AI认知现状：多数仍处启蒙阶段

首先必须指出，多数公司对AI的认知水平依然处于相当初级的阶段。

即使是许多位于一线城市的公司，也并未因AI浪潮的喧嚣而真正投入其中。真实情况往往是，它们不仅在AI应用上起步较晚，其整体的数字化基础也颇为薄弱。

或许可以换一个角度来表述：那些企业数字化做得较为扎实的公司，通常在AI应用上也更有章法，并且更清晰地认识到AI咨询的价值，愿意为此付费。

应用风向突变：文生图/视频需求崛起

其次，AI应用的市场风向发生了显著转变。早些时候的需求排序大致是 AI工作流 > AI客服 > 复杂AI知识库。但近期，文生图/文生视频类需求的占比急剧上升。

回顾去年我经手的AI落地项目，多数集中于工作流程自动化，偶有一两个文生文项目（例如一键生成论文摘要类），而涉及复杂数据的行业级AI应用则凤毛麟角，多数企业持观望态度。

然而近两个月以来，文生图/视频的需求显著增多，甚至有超越传统AI工作流项目的趋势。这一转变，或许要从两个关键事件说起：

其一是 Google的Nano Banana模型火爆出圈。它的意义在于两点：

1. 效果出众：生成的图片质量高，且保持良好的一致性，已在电商产品图、宣传海报、节日营销素材等场景实现规模化应用。
2. 门槛极低：使用成本低廉，用户可直接通过网页访问使用。

其二是 OpenAI的Sora2模型展现了巨大的商业想象空间。一个能够生成高质量视频、潜力堪比抖音的内容生成工具，无疑激发了市场的强烈期待。它的成功直接指向了低门槛的 “生产+分发”一体化内容网络。

更早则可追溯到五月左右发布的 Google Veo3套件，它首次实现了音视频同步生成，具备电影级质感与精准的唇形同步。当时可能由于成本或门槛，未在国内引起足够重视，但它实则是Nano Banana等爆款出现前的关键探索。我相信未来几个月，还会有更多优秀的AI视频类产品面世。

总而言之，正是Nano Banana与Sora2的快速破圈与强势表现，让市场瞬间意识到了AIGC（尤其是图像与视频）蕴含的巨大潜力，进而直接影响了企业的实际采购需求。

最后，一个关键驱动因素在于：国内在AI图像/视频领域一直跟进迅速，国外每出现一个爆款，国内都能快速推出类似产品。因此，整体上门槛较低、效果尚可，这加速了各类企业相关需求的产生。

需要注意的是，近期激增的文生图/视频需求，对于许多企业而言确实是“新增需求”，因为这部分公司原本也不太涉足AI工作流或复杂的AI知识库。这导致了一个有趣的结果：对于资金雄厚的公司，AI极大降低了内容生产成本；对于预算有限的公司，它们也得以拥有过去难以企及的内容生成能力。一个“AI素材平权”的时代似乎正在来临。

咨询心得：方法论传授优于具体实施

第三点属于个人实践中的感受：提供咨询服务优于承接具体的实施落地项目，而提供通用方法论咨询又优于提供过于垂直的专业领域咨询。

原因很直接：实施落地过程会遭遇诸多难以预料的棘手问题，这些问题层出不穷，需要持续解决。这本质上是一个复杂的工程问题，进而会演变为项目管理难题，很难单纯通过方法论讨论来规避。

而专业领域的深度咨询，很容易被客户引导至具体实施的方向。因为甲方的团队往往希望将实际工作中遇到的所有难题一次性抛出，并立即获得完美的解决方案。但这通常不现实。暂且不论咨询费用本身是否足以覆盖深度解决方案，真要解决具体问题，咨询师也必须深入了解行业内的隐性知识（Know-How），这绝非一朝一夕之功。

因此，单纯传授方法论可能显得“空泛”，且听众未必能深刻领会；偶尔遇到团队中质疑精神过盛的成员，还会不断挑战建议的合理性，这就更难推进了。这里也引出了我过去常犯的一个错误：

企图（完全）教会对方，这本身就可能是一种傲慢。尤其对于技术团队，成员往往知识面广且喜欢自主研发，若非在认知或专业上形成明显碾压，许多方案其实并无绝对的对错之分。

所以，实践中获得的真实心得是：

必须清晰地认识到自己作为乙方的定位。咨询的目的不是去评判或指点甲方的团队。特别是在专业类咨询中，不当的交流方式很容易引发相关团队的抵触情绪，原因不言自明。

要做好这类咨询，首先要“学会做人”，需要巧妙且不失分寸地向决策者传达：“您的这支产品研发团队非常优秀！”

唯有先建立良好的人际关系与信任，在此基础上，才有可能顺利开展深入的专业咨询。

企业真正需要怎样的AI人才？

第四，许多企业并不清楚自己真正需要什么样的AI人才，或者说，并不了解一名优秀的应用型AI人才应具备哪些特质。

例如，上个月一家公司在咨询时，提出了大量关于AI框架、具体技术乃至代码BUG的问题。但当我试图了解企业的整体业务蓝图时，沟通却陷入了停滞。这反映了许多公司的通病：

技术人员通常难以全面阐述公司业务，具体到产品细节也同样困难。高层业务负责人或许具备这种能力，但他们未必愿意主动、系统地分享这些信息。

因此，才有了之前关于AI项目实施的一个最佳实践建议：最好由公司核心决策者（一号位）亲自牵头。因为大型AI项目的成功落地，极度依赖跨部门的业务整合。所谓的行业Know-How，深究下去，往往就是几张关键的业务流程图和数据关系表罢了。

举例来说，去年在为一家广告投放公司规划全业务流程AI化时，对接的负责人对业务的理解程度超过60%，并且他本人抱有极强的意愿推动AI落地。

具体表现为：他不会机械地一问一答。在实际对接中，他首先展示了一张完整的业务全景图，并围绕这张图进行了长达半小时的讲解。随后结合我的提问，能立即回答的当场解答，无法立即回答的，他会协调内部资源，在第二天给出反馈。

在他的鼎力协助下，我们快速明确了AI能力边界与核心业务知识的结合点，项目得以迅速上线并落地。

综上，企业真正需要的AI人才，首先必须具备深厚的行业认知，能够清晰地勾勒出业务全景，拥有自己成体系的知识框架；其次，必须拥有强烈的意愿与驱动力，真正想做这件事，而非将其视为一项交差的任务。如果只是机械地问一答一，项目很难取得理想成果。

这也再次呼应了第三点：为何面对技术团队咨询要“先做人”？因为在信息无法顺畅流动的环境下，任何深度合作都难以开展。

以上便是近期在企业AI咨询实践中的一些观察与思考，希望能带来些许启发。

除了上述四点，我对于第二点中提到的 “文生图/视频需求隐约超过AI工作流，更是远远甩开了复杂AI知识库” 这一现象，总感到些许困惑与不解。AI在文字处理上不应如此乏力，问题出在哪里？

为何AI文字不如AI图片/视频受欢迎？

真相或许并不简单，核心在于两点：

1. 市场对两者的心理预期存在巨大差异；
2. 两者的实现与应用成本差距悬殊。

那么，为何“画张图”比“写段文字”更受企业欢迎？

首先，容错度天差地别。

我们对于视觉内容的容忍度非常高，甚至有时并不追求绝对真实。例如：抖音上的各种“网红”形象，腿部比例夸张到失真，但我们并不在意；各种漫画图片，即使头部画反了我们也觉得无伤大雅，甚至感到有趣。只有当AI试图生成极度写实的人像时，各种“恐怖谷”效应才会爆发，虽然我们不会深究，但观感上必定不适。

以上是我们对AI生成视觉内容的基本容忍度。那么文本生成呢？

如果你让AI撰写一份市场分析报告，即便文笔流畅、结构清晰，只要其中出现一个关键数据错误或逻辑漏洞，之前建立的所有可信度可能瞬间归零。

用户对文字的“准确性”要求远高于图像。图像允许“艺术加工”，文字必须“精准无误”。

另一方面，我们实际上非常厌恶正确的废话，而AI又极其擅长产出此类内容。例如，当我为学员进行了两小时密集授课后，对方用AI将会议记录一分钟生成一篇文章并请我点评时，我的感受会非常复杂。

其次，实施成本差距巨大。

一个“文生图”功能，在企业内可以作为一个独立工具使用。设计师用它来寻找灵感、生成初始素材，然后手动筛选、修改，并无缝嵌入现有的设计流程中。

但一个“复杂AI知识库”或“深度AI工作流”项目，则意味着需要将AI能力深度整合进现有的核心业务系统。这需要打通数据孤岛、构建复杂的工程链路、处理长上下文信息、并确保输出的稳定与可靠。

这首先是一场伤筋动骨的“工程改造”，其次对于很多数字化基础本就薄弱的企业而言，其门槛和总体成本都太高了。

因此，视觉类AIGC能够立竿见影地实现降本增效，且初期投入成本较低，企业自然会用脚投票。而且它们的接入门槛确实不高，关键在于用心摸索。

近来，一些关注我的前端团队负责人表达了他们的担忧。他们敏锐地察觉到，人工智能对编程领域，特别是前端开发，产生了巨大冲击，这让他们感到了切实的职业压力。

于是，他们提出了一个普遍的疑问：前端开发者能否成功转向AI领域？如果能，在这个全新的赛道上又能走多远？

如果我们将视野聚焦在应用层的AI赛道，答案是肯定的：前端开发者非常适合转型AI。潜在的目标岗位包括AI工程师或AI产品经理，表现优异者甚至可以成长为AI项目负责人。我的身边已经有不少成功的转型案例，因此大家不必过度焦虑。

接下来，我们将深入探讨两个核心问题：第一，为什么前端开发者尤为焦虑；第二，为什么前端背景在转向AI时具备独特优势？

AI编程浪潮下的前端处境

从ChatGPT的横空出世到DeepSeek的迅猛发展，近三年时间里，真正稳定消耗算力（Token）的文字类AI应用，大致只有三类：

1. ChatGPT/DeepSeek官网的直接对话；
2. 简单的AI客服系统；
3. AI编程辅助工具，如Cursor、Claude Code。

此外还有一些工作流类应用，但对算力的消耗相对较小。我们暂且抛开ChatGPT这类通用对话机器人，思考一下：为什么AI客服和AI编程能够率先成为爆款应用？

原因其实相当清晰：

AI客服所需处理的数据结构相对简单，当前的技术瓶颈主要在于准确率的细微提升，例如如何从95%提升到98%。

而AI编程这一品类得以爆发的核心驱动力，部分源于程序员群体乐于尝试和分享的特性，繁荣的开源生态为代码领域的AI模型训练提供了海量、高质量的语料库。

GitHub上拥有超过2亿个开源仓库，覆盖了几乎所有主流的编程语言和技术栈。这种结构化程度高、且通过代码逻辑实现了隐式标注的文本数据，是训练代码生成模型的理想素材。

当我们把视角聚焦到前端开发领域，情况则更为特殊。我们不得不正视一个现实：前端的业务逻辑普遍相对简明，并且其各种实现模式几乎在GitHub上已被“穷举”。换言之，训练一个能够熟练生成前端代码的AI模型，其数据基础是完全充足的！

再将目光转向后端领域，对于常规的增删查改（CRUD）类业务，AI处理起来游刃有余。然而，许多公司的核心业务代码通常不会公开，因为发布这些代码无异于暴露商业机密。因此，可用于训练后端AI模型的公开语料，在质量和多样性上相对欠缺。

此外，我认识一些从事芯片底层开发的朋友，AI编程辅助工具对他们而言几乎毫无用处，因为GitHub上根本没有相关的专业语料。

综上所述，前端业务逻辑的简洁性，加上GitHub上极其丰富的相关代码库，直接导致了AI在前端代码生成领域已经表现得相当出色。我们可以通过一个具体例子来感受：

AI编程工具的真实提效分析

在许多Cursor等AI编程工具的宣传案例中，我们常看到这样的演示：

用户输入提示词： “帮我用JavaScript实现一个数独游戏。”

大约30秒后，Cursor便能完成从需求理解、问题拆解、代码编写到最终实现预览的完整流程。演示效果通常如下图所示：

生成的数据游戏不仅功能完整，往往还支持响应式布局。如果由开发者手动编码实现，可能需要4到8小时，而Cursor仅用30秒，效率提升何止十倍，甚至高达百倍。

这类场景确实容易让人产生“AI将彻底颠覆开发效率”的印象。但我们需要冷静地拆解这类案例的特点：

1. 需求明确、任务标准化： 数独游戏的规则是全世界统一的，AI只需要基于训练数据中的类似模式生成代码，无需理解复杂的、独特的业务上下文。
2. 演示场景不关注代码质量： 在追求“展示速度”的演示中，代码的健壮性、可维护性、是否符合团队规范等工程化要求通常被忽略。即使生成的代码难以扩展或存在瑕疵，也不影响演示效果。
3. 极端成功案例的放大效应： 一些演示视频可能会精心挑选AI表现最佳的时刻，而回避它犯错或需要反复调试的情况。例如，Cursor生成复杂交互的UI代码时，可能遗漏关键细节，导致实际应用中需要大量人工修改。

这种快速生成能力，对于非专业开发者、初创团队、需要快速验证MVP（最小可行产品）、开发短期使用的原型或简单工具的场景极具价值，能显著降低技术门槛。

然而，这仅仅是理想化的演示场景。现实世界中的商业项目开发，其复杂性远超于此。

前端业务开发的实际提效场景

为了客观评估Cursor等工具在真实业务开发中的提效作用，我们首先拆解一个典型前端开发流程及各环节的大致时间占比：

从上表可以看出，占用开发者主要时间的环节集中在：

1. 需求分析与理解
2. UI 视觉稿还原与组件开发
3. 核心业务逻辑实现
4. API 对接与联调调试

接下来，我们逐一分析Cursor在这些关键环节的实际表现：

需求分析环节：AI介入难度极高

原因在于：

近期与几位前端团队负责人的交流中，我深刻感受到他们普遍的焦虑情绪。这种焦虑主要源于AI技术对编程领域，尤其是前端开发带来的巨大冲击。他们迫切地想知道两个核心问题：前端工程师是否有可能转型进入AI领域？以及在这个全新的赛道上，前端背景的从业者能走多远？

如果我们将视野聚焦在应用层的AI赛道，答案是非常积极的：前端工程师不仅非常适合转型AI，而且具备独特的优势。 潜在的目标岗位可以瞄准AI工程师或AI产品经理，能力出众者甚至可以成长为AI项目负责人。事实上，我身边已经有不少从前端成功转型AI的鲜活案例。因此，过度的焦虑并无必要。

接下来，我们将深入剖析这两个问题：第一，为何前端领域对AI冲击的感受尤为强烈？第二，前端背景为何在转型应用层AI时具备适应性？

AI编程浪潮下的前端困境

从ChatGPT横空出世到DeepSeek等模型不断涌现的近三年里，真正能够稳定消耗算力、产生持续价值的文字类AI应用，主要集中在这三类：

1. 像ChatGPT、DeepSeek官网那样的直接对话聊天应用。
2. 相对简单的AI客服系统。
3. AI编程辅助工具，例如Cursor和Claude Code。

除此之外，虽然也存在一些工作流类项目，但它们对算力的消耗量级通常较小。那么，为何AI客服和AI编程能成为最先爆发的应用场景呢？原因其实相当直接：

AI客服所需的数据结构相对简单，当前的技术瓶颈更多在于准确率的提升，例如如何将识别准确率从95%优化到98%。

而AI编程这个品类能够兴起，其核心驱动力之一在于程序员群体乐于尝试和分享，繁荣的开源生态为代码领域的AI模型训练提供了海量、高质量的语料库。 GitHub上托管着超过2亿个开源仓库，覆盖了几乎所有主流的编程语言和技术栈。这些结构清晰、逻辑严谨（代码本身即是一种隐式标注）的文本数据，无疑是训练代码生成模型的理想素材。

当我们把视角进一步聚焦到前端开发领域时，情况就显得更加微妙和具有挑战性。我们不得不正视一个现实：前端的业务逻辑普遍相对标准化和模块化，并且这些模式几乎已经在GitHub等开源平台上被完全“穷举”了。 换句话说，要训练一个专门针对前端开发的AI“分身”，现有的数据储备是完全足够的。

再将目光转向后端开发。对于常规的增删查改（CRUD）类业务，AI处理起来已经驾轻就熟。然而，许多公司的核心业务代码和算法出于商业机密考虑，并不会公开分享。这导致可用于训练后端AI模型的高质量语料，在丰富程度上略逊于前端。

此外，在与几位从事芯片开发的朋友交流后，我发现AI辅助编程对他们的帮助微乎其微，因为GitHub上几乎找不到相关领域的开源代码作为训练数据。

综上所述，前端业务逻辑的特性与开源生态的充沛供给，共同造就了AI在前端开发领域已经取得了相当显著的成果。我们可以通过一个具体例子来感受：

理想与现实：AI提效的极限在哪里？

在许多展示Cursor能力的宣传案例中，我们经常看到这样的场景：

输入提示词：
“帮我实现一个数独游戏，使用JavaScript实现。”

大约30秒后，Cursor就能完成从需求理解、问题拆解、代码编写到最终预览的整个开发流程。最终呈现的效果如下图所示：

这个生成的数独游戏不仅功能完整，甚至还考虑了响应式布局。如果交由开发者手动编码实现，可能需要4到8小时，而Cursor仅用30秒，其效率提升何止十倍，甚至可能达到百倍。

这类演示确实极具冲击力，容易让人产生AI将彻底颠覆开发工作的印象。但我们需要冷静拆解这类案例的典型特征：

1. 需求极端明确，任务高度标准化： 数独游戏的规则全球统一，AI只需基于海量训练数据中的既有模式进行复现和组合，无需复杂的上下文理解和创造性决策。
2. 演示场景中代码质量并非首要考量： 在突出“AI速度”的演示中，代码的健壮性、可维护性、是否符合特定团队规范等工程化要求往往被有意忽略。即使生成的代码存在瑕疵，也不影响演示效果。
3. 极端理想化场景的刻意放大： 部分演示可能会选择性展示AI表现最优的时刻，而规避其出错或需要人工反复调试的情况。例如，生成复杂交互界面的代码时，AI可能会遗漏关键细节，导致在实际集成时需要大量返工。

这种能力对于非专业开发者、初创团队快速验证MVP（最小可行产品）、开发一次性工具或制作演示原型非常有帮助，能显著降低技术门槛。

然而，这仅仅是高度简化的理想场景。现实商业环境中的业务开发，其复杂程度远非一个独立的数独游戏可比。

剖析真相：AI在前端实际业务中的提效表现

为了客观评估Cursor等工具在实际业务开发中的提效作用，我们首先需要拆解一个典型前端项目的开发流程及各环节的时间占比：

从上表可以看出，占据开发者大部分时间的环节主要是：

1. 需求分析与理解
2. UI界面还原与组件化开发
3. 复杂业务逻辑的实现
4. API接口的集成与调试

接下来，我们逐一分析Cursor在这些核心环节中的实际表现：

需求分析：AI介入难度极高

原因显而易见：

1. 需求分析涉及深厚的业务背景知识、多方利益权衡和大量需要人类经验的主观判断。
2. 业务需求本身可能频繁变更，AI难以高效追踪和理解动态变化的上下文。
3. 许多隐性需求和非功能性需求难以用简洁的自然语言精确描述，导致AI生成的结果与预期存在偏差。 结论：在需求分析环节，AI工具目前几乎无法提供实质性帮助。

UI还原：能力有限，仍需大量人工干预

尽管当前Cursor已支持基于Figma设计稿或截图生成UI代码，但仍存在明显局限：

在数字修图的日常实践中，滤镜的应用几乎是不可或缺的环节。必须承认，滤镜对于提升照片的视觉质感确实发挥着显著作用。然而，这类后期滤镜主要承担修饰功能，若想真正优化影像品质，还需依赖镜头滤镜的辅助。特别是对于风光摄影的爱好者而言，镜头滤镜无疑是继相机机身和镜头之后的第三大必备装备。

尽管相机镜头滤镜在外观上仅是一片小巧的玻璃，但实际选购时所需掌握的知识却相当丰富。本文旨在深入探讨镜头滤镜的基本概念、核心类型及选购策略，助您做出明智决策。

镜头滤镜种类详解

拍摄时需依据场景条件挑选合适镜头，滤镜的选择同理。当前市场中的滤镜品种繁多，各自具备独特效果，唯有应用于对应场景方能最大化其效用。

针对风光摄影，最常使用的包括减光镜、偏振镜和渐变镜三大类。此外，许多用户在购入新镜头后，通常会加装一片UV镜以保护镜头前组。至于柔光镜、星芒镜、防激光滤镜等特殊效果滤镜，则专用于人像、夜景或演唱会等特定拍摄场景。

上图汇总了常用滤镜及其功能，可作为选购参考。接下来将详细剖析各类滤镜的工作原理与实际效果。

紫外线滤光镜（UV镜）

紫外线滤镜在胶片相机与CCD传感器时代应用较为广泛，能够有效过滤紫外线，减少蓝调过度显现，从而提升画面清晰度与色彩还原度。

但对当今主流的CMOS数码相机而言，紫外线过滤的需求已大幅降低。由于紫外线属不可见光，使用与否的视觉差异并不明显。然而，UV镜至今仍广受欢迎，其主要用途已转向保护镜头，防止灰尘、水渍或刮擦损伤镜头镀膜。

减光镜（ND镜）

相机自身可通过调整快门速度、ISO感光度与光圈大小来控制进光量，但调节范围有限。若需更大幅度的光线控制，便需借助减光镜。减光镜又称中性灰度镜，核心功能在于减少进入相机的光线总量，在慢门摄影中应用极其广泛。

▼采用长曝光模式拍摄后，水面趋于平静，波浪痕迹几乎消失

拍摄流动云彩或丝滑水面效果时，减光镜必不可少。此外，在人群或车流密集的场所，结合减光镜进行长时间曝光，可消除移动物体，获得纯净简洁的画面。

根据减光程度差异，常用减光镜分为十个档位：ND2、ND4、ND8、ND16、ND32、ND64、ND128、ND256、ND512、ND1000。数值越高，减光效果越强。一般而言，三档适用于拍摄落日余晖，六档用于阴天场景的长曝光拉丝效果，十档用于晴天环境的长曝光。若在正午强光条件下，甚至可能需要使用十五档减光镜。

渐变镜（GND镜）

渐变滤镜表面具有从透明到灰色的渐变涂层，可平衡环境中的光线差异。在日出日落、沙滩海岸、天地交界或海天相接等高对比度风光摄影中效果尤为突出，常见档位包括GND0.9与GND1.2。

▼使用渐变镜后，天空与水面的亮度反差缩小，整体曝光更趋均衡，云层细节凸显，画面层次感显著增强

渐变镜仅在一侧产生作用，常见颜色有渐变灰、渐变蓝与渐变橙。渐变灰用于平衡天空与地面的光比；渐变蓝可增强天空的通透感；渐变橙则能强化日落时的温暖氛围。实际使用时，需将滤镜的中灰层对准画面高光区域，以实现压光效果。

▼未使用渐变镜拍摄时，天空部分曝光明显高于水面，云层细节几乎丧失

此外，渐变镜还可细分为软渐变、硬渐变、标准渐变与反向渐变四种类型。软渐变与标准渐变适用于常规场景；硬渐变过渡分明，多用于海岸线等明暗界线清晰的拍摄；反向渐变则专为日出日落设计。

偏振镜（CPL镜）

光线在不同折射率的介质界面会发生反射与折射，强烈反光会削弱画面细节。偏振镜能选择性允许特定振动方向的光线通过，从而消除或减弱非金属表面的反光现象。

▼在博物馆隔玻璃拍摄文物时使用偏振镜，除光源倒影外，其余反光基本被消除

水面、天空、玻璃等物体反射或散射的光线多为偏振光。通过偏振镜的过滤，天空会显得更蓝、更通透，水面与玻璃的反光大幅减少，画面整体更清澈透亮。

▼晴天搭配偏振镜拍摄水面，倒影更为清晰，画面通透度进一步提升

偏振镜厚度较大，使用时应注意避免与其他滤镜叠加，否则可能增加眩光与色散，影响画质。

特殊效果滤镜

除上述风光摄影常用滤镜外，市场上还存在多种针对特殊场景设计的滤镜。例如人像拍摄常用的柔光镜、夜景摄影的抗光害滤镜、拍摄日出日落或点光源的星芒镜，以及演唱会专用的防激光滤镜。

▼使用星芒镜拍摄落日场景

这些特殊滤镜虽然用途专一，但效果显著，能极大提升画面的艺术美感。若常拍摄人像，建议配备一套柔光滤镜；若不熟悉相机直接拍摄星芒的技巧，星芒镜能简化操作。另外，观看演唱会时需特别注意：现场激光可能对相机传感器造成不可逆损伤，切勿随意拍摄，若需记录应使用专用防激光滤镜。

镜头滤镜挑选要点

选购滤镜时，除根据拍摄习惯与场景选择类型外，还需关注以下关键因素，以确保投入物有所值并完美匹配设备。

滤镜口径匹配

滤镜口径是选购的核心参数之一，必须与镜头口径一致方可正常安装使用。

常见镜头口径包括40.5mm、49mm、52mm、55mm、58mm、62mm、67mm、72mm、77mm、82mm等。通常镜头筒身会明确标注口径尺寸，旋转镜头即可轻松找到。

方镜与圆镜对比

镜头接口多为圆形，但滤镜却有圆形与方形之分。圆形滤镜采用旋入式安装，方形滤镜则通过插入支架固定。

相对而言，方形滤镜不易产生暗角，支持多片叠加，使用灵活性较高。但其价格昂贵，需搭配不同规格转接环，且缺乏遮光罩保护，易受杂光干扰产生眩光或鬼影。

圆形滤镜保管与使用更为便捷，镜片边缘设有保护圈，不易损坏。可配合遮光罩使用，抗杂光能力较强，不用时也可长期安装在镜头上，省去频繁拆卸的麻烦。但在广角镜头上可能遮挡内置闪光灯，且仅适用于相同口径镜头，多镜头用户可能需要购置多套滤镜。

从产品特性分析，方镜与圆镜各有优劣，难以简单判定高下。实际选择更多取决于个人使用偏好与拍摄需求。

可调参数与固定参数选择

如前所述，ND镜、GND镜等滤镜常有多档位可选。若需频繁调整档位，有两种解决方案：一是购买多个固定档位滤镜，根据需要更换；二是选择档位可调的单片滤镜，实时调整参数。

固定档位滤镜价格相对亲民，但更换繁琐；可调档位滤镜使用方便，但成本较高。对于新手，建议先购置一套品质优良的固定档位滤镜（如ND1000、GND0.9等主流型号），待技术熟练后再考虑升级至全功能可调滤镜。

前置与后置安装方式

按安装位置划分，相机滤镜可分为前置与后置两类。前置滤镜即常见于镜头前端的旋入式滤镜，装卸便捷，无需拆卸镜头。但需确保滤镜或转接环口径与镜头完全匹配，更换镜头时可能需同步更换滤镜系统，成本较高。

后置滤镜又称内置滤镜，安装在相机CMOS传感器前方，可对传感器起到一定保护作用。其优点在于不受镜头口径限制，一块滤镜即可适配多支镜头，成本较低。但更换滤镜时必须卸下镜头，操作稍显不便。

此外，后置滤镜因安装在机内，体积小巧，便于携带与收纳。

磁吸与螺纹结构差异

螺纹滤镜诞生较早，曾是镜头滤镜的主流设计。其边缘带螺纹，可旋入口径匹配的镜头，安装方式传统，价格通常较低。

磁吸滤镜出现较晚，但因装卸便捷性优势，逐渐受到摄影师青睐。其缺点在于价格普遍高于螺纹滤镜。

滤镜品牌与产品推荐

本人以风光摄影为主，目前主要使用卡色（Kase）滤镜套装。实际体验表明，其做工质感与成像质量均表现优异。卡色作为国内知名光学滤镜品牌，产品在国际市场也占有一席之地。

OpenAI所发布的这张AI发展预测图，普遍被业界视为一个经典参考：

在国内的技术发展脉络中，两个关键事件节点构成了重要的分水岭：DeepSeek的发布与Manus的发布。DeepSeek标志着国内模型的推理能力达到了足以支撑构建Agent的水平；而Manus则首次将Agent应有的完整形态呈现在公众面前，尽管其实际表现尚有不足，但业界对其未来潜力抱有极高的期待。

具体到模型的基础能力，核心无非围绕两点展开：模型的推理能力与上下文长度。

而诸如Manus这类智能体，在模型基础能力之上，需要投入大量工作的部分在于提供丰富多样的工具，正如下图所示：

Agent架构的设计核心始终围绕两个关键环节：意图识别以及工具调用。模型会根据用户对话内容解析其根本意图，随后选择并调用最合适的工具，同时确保工具调用的质量与准确性。

从这个视角审视，Agent（例如Manus）的实现原理似乎并不复杂。以最简单的空气质量查询工具调用为例：

然而，用户的意图往往是多元且动态变化的。在查询天气之后，他可能立刻转向关注旅游相关的信息。如果智能体要妥善处理此类连续请求，就必须提供对应的工具支持。当工具数量增加到两个时，系统的整体复杂度便显著提升：

此时将对应两个工具的调用定义：

[
  {
    "tool_name": "weather",
    "tool_desc": "查询某地的天气",
    "tool_examples": ["上海天气怎么样", "北京天气怎么样"]
  },
  {
    "tool_name": "travel",
    "tool_desc": "某地的游玩计划",
    "tool_examples": ["上海有哪些好玩的", "北京有哪些好玩的"]
  }
]

必须注意的是，上述所有功能的实现高度依赖于模型的基本能力。例如，当用户输入一句话如“上海天气怎么样，有什么好玩的？”时，系统需要完成以下几个关键步骤：

1. 意图识别的准确性：能否精准识别出需要同时调用旅游Agent和天气Agent。
2. 关键词抽取的精度：能否准确提取出旅游地点及其他必要参数，并成功传递给相应的Agent。
3. 回答组织的质量：即使所有工具都能正常运行，最终回答是否清晰、有用，这极其考验全局调度Agent的整合与表达能力。

至此，再次回归Agent架构的两个核心难点——意图识别与工具调用，读者应能有所体会。意图识别的准确是良好表现的基础，而工具组织的合理性则是最终高质量输出的保证。

这里仅涉及两个工具，便已初显复杂之感。而Manus在最初发布时就包含了20多个工具（目前数量更多）：

[
  {
    "name": "message_notify_user",
    "description": "向用户发送无需回复的消息。用于确认收到消息、提供进度更新、报告任务完成或解释方法变更。"
  },
  ......
  {
    "name": "file_str_replace",
    "description": "替换文件中的指定字符串。用于更新文件中的特定内容或修复代码错误。"
  },
  {
    "name": "file_find_in_content",
    "description": "在文件内容中搜索匹配文本。用于查找文件中的特定内容或模式。"
  },
  ......
  {
    "name": "idle",
    "description": "特殊工具，表示已完成所有任务并即将进入空闲状态。"
  }
]

Manus的提示词部分内容也较为庞大：

# 关于 Manus AI 助手
## 简介
我是 Manus，一个被设计用来处理多种任务的 AI 助手。我致力于在各种场景下，为你提供有用、翔实且多样化的支持。

## 我的使命
我的主要目标是：通过提供信息、执行任务和给出建议，帮助你更顺利地达成目标。我希望成为你在问题求解和任务执行中的可靠伙伴。

## 我处理任务的方式
当接到一个任务时，我通常会：

1. 分析你的请求，理解你真正想要的是什么
2. 将复杂问题拆分成更小、更易处理的部分
3. 为每个步骤选择合适的工具和方法
4. 在执行过程中保持与你的沟通畅通
5. 以清晰、有条理的形式呈现最终结果

## 我的性格特征
- 以“帮助你解决问题”为导向
- 注重细节，追求完备
- 能适应不同类型用户的需求
- 面对复杂问题时保持耐心
- 对自己的能力与限制保持诚实

## 我擅长帮助的领域
- 信息收集与研究
- 数据处理与分析
- 内容创作与写作
- 编程与技术问题排查
- 文件管理与组织
- 网络浏览与信息抽取
- 网站与应用的部署辅助

## 我如何“学习”
我会从交互与反馈中不断优化自己的行为模式，在任务中积累经验。每一次协作，都会帮助我更好地应对未来类似的问题。

## 沟通风格
我会尽量做到：
- 说明清晰、逻辑严谨
- 根据你的偏好调整技术深度
- 在需要时使用较技术化的表达
- 在适合的场景使用更口语化、易懂的表述

## 我坚持的价值观
- 尽可能提供准确、可靠的信息
- 尊重用户隐私与数据安全
- 以负责任的方式使用技术
- 对自身能力边界保持透明
- 持续改进和自我迭代

## 如何更好地与我协作
我们的协作会更高效，如果你能：

- 尽量清晰地描述任务与预期结果
- 在必要时给出中途反馈，便于我调整方向
- 将复杂需求拆分成更明确的子任务
- 在已有成功经验的基础上，逐步尝试更复杂的挑战

我随时准备协助你处理各种任务，也期待和你一起，完成更多有趣、有价值的事情。

这些设计已经引入了相当高的复杂度，且后续的上下文工程应用也极其繁琐，不利于初学者更好地理解和学习Agent的核心概念。从学习目的出发，早期的OpenManus版本是一个更合适的选择，它足够简洁。今天我们就以此为基础进行拆解，依旧从意图识别和工具调用的视角展开分析。

最近阅读了一篇来自Anthropic官方的长文：《Skills explained: How Skills compares to prompts, Projects, MCP, and subagents》。这篇文章也解答了许多人心中的疑惑：Claude Skills 与 MCP、Project 之间到底有何区别？

我们将重点探讨MCP和Skills，力求从本质层面将它们阐述清楚。首先从MCP开始。

MCP：连接AI与外部世界的协议

模型上下文协议（Model Context Protocol, MCP）是由Anthropic提出的一种开放标准协议，它使得AI模型能够与外部数据源和工具进行交互。

它与HTTP协议类似，是一种被广泛接受的约定标准，只要各方遵循即可实现互联互通。

MCP诞生的原因非常直接：大模型若要真正解决问题，必然需要与各类外部接口交互，例如浏览器、数据库、文件系统等。

在MCP出现之前，我们是如何获取外部信息的呢？答案是高度定制化。

我们需要编写一个中间层程序，由它直接调用大模型API以获取用户请求，解析后再去调用相应的数据库读写API，或者根据大模型返回的参数执行其他API调用。简而言之，用户实际访问的是这个中间程序，由它弥合了大模型能力与外部世界的鸿沟。

但这种做法引发了不满：有人质疑这种“中间程序”存在的必要性。于是，一种新思路出现了：在模型底层直接实现固定格式的API调用能力。这样一来，用户可以直接与大模型对话，而大模型能够自动调用预设的API来完成诸如数据库读写等操作。

随着文件读写、浏览器控制等需求的涌现，为了提升效率，业界沿用了这一标准化思路。最终发现这套方法行之有效，便逐渐演变为一个正式协议。

MCP的出现，为AI与外部世界的交互建立了统一规范，使得AI应用能够无缝集成各种外部数据源和工具。

以上是相对概括性的描述。若想深入探究其架构，可以参考下图：

MCP是智能体（Agent）技术发展过程中的必然产物，尤其是在当前这个早期阶段。 如何理解这一点呢？

大模型发展已近三年，从去年开始，无论是推理能力还是上下文长度都得到了显著增强，确实达到了所谓“L2”级别的能力。因此，以Manus等框架为代表的智能体架构开始流行起来：

这种架构得以流行的前提，一方面是新技术的突破（模型能力增强），另一方面是互联网多年积累的丰富生态，大量现成的小工具和服务正等待被调用。例如，在微信与朋友聊天时：

1. 朋友询问最近的天气，我无需额外查询，AI可以直接给出答案；
2. 朋友发来一篇论文，我只需在微信中表达翻译或解读的意图，微信便能自动完成对论文的翻译或解读。

智能体架构或模型本身无法穷尽用户的所有意图，但它可以提供一系列有限的服务。当用户的某个意图恰好匹配到某项服务时，系统便会调用该服务，从而带来贴心的体验：

这里提到的无限意图与有限实现，也是我个人在开发智能体项目时的一个重要心得。我并不太关心智能体在开放场景下的泛化聊天能力，但如果用户的意图命中了我预设的服务范围，那么服务的质量就必须得到严格保障。

举一个实际工作中的案例。一家业务正常的公司通常会有BI（商业智能）数据看板，但老板往往缺乏耐心仔细阅读数据。善于“面向老板编程”的我们，可以预先实现许多MCP服务，静待老板提出各种意图时调用：

老板BI案例分析

首先是传统的工作模式：

老板想了解：“上月华东区销售额排名前三的产品是什么？”
→ 员工打开BI系统 → 选择日期范围 → 筛选华东区域 → 按销售额排序 → 查看前三名
→ 整个过程耗时5-10分钟
→ 缺乏耐心的老板可能因此不满。

采用MCP模式后：

老板直接询问AI：“上月华东区销售Top 3产品是什么？”
→ AI自动调用【BI工具.查询销售排行(区域=华东， 时间=上月， 数量=3)】服务
→ 10秒后给出清晰答案
→ 老板获得高效反馈，团队工作顺畅。

接下来看看简单的实现思路。首先需要预制MCP工具包（相当于告诉AI，它拥有以下可用的工具）：

# 这些工具在后台静待被老板“召唤”
老板专用工具包 = {
    “销售分析”: {
        “区域销售排行”: “按区域查询Top N产品”，
        “同比分析”: “对比同期销售数据”，
        “趋势预测”: “预测下月销售情况”
    }，
    “客户分析”: {
        “大客户清单”: “找出消费额最高的客户”，
        “流失预警”: “识别有流失风险的客户”
    }，
    “运营分析”: {
        “库存预警”: “检查库存不足的产品”，
        “成本分析”: “分析各类产品的成本结构”
    }
}

正因为“服务员提供了这份菜单”，AI在完成意图识别后，会自行进行工具匹配，并生成相应的调用指令：

近期围绕OpenClaw的各类信息呈现出显著的夸张倾向，例如流传着依靠498元为他人部署“小龙虾”即可实现年入百万的说法。尽管这种收入计算方式令人费解，但其引发的狂热现象足以说明，在巨大的利益驱动下，市场的非理性程度可见一斑。

那么，这是否意味着OpenClaw就是通往智能自动化的终极答案呢？事实恐怕并非如此。

坦诚而言，虽然笔者也完成了OpenClaw的部署并运行了演示案例，但后续更多时间投入于对其源代码的研究，旨在从工程实现的角度探究智能体（Agent）技术的未来演进方向。最终的测试结果高度“符合预期”：

1. 过往工作流（Workflow）能够处理的任务，OpenClaw同样可以完成。
2. 过往工作流无法胜任的任务，OpenClaw自然也难以突破。

这种情形颇具电影《国产凌凌漆》中达文西手电筒的意味：有光源照射时才发光，没有光源则必然黯淡。

其根本原因相当明确：现有的智能体范式并未实现本质升级，底层模型能力也未迎来革命性突破。OpenClaw并未引入前所未有的新技术，市场上早前已存在类似形态的产品。然而，它却成功引爆了市场热点。尽管这一现象令人费解，但它确凿地反映了当前市场的选择。

它或许与部分理论预期相悖，但现实层面却选择了它，当然，这种选择可能是阶段性的。

然而，随着身边不明就里的群体日益扩大，加之自媒体的鼓吹日趋神化，许多尝试使用OpenClaw的同学发现其实际能处理的事务相当有限，进而开始自我怀疑，担忧是否已落后于时代。因此，我们有必要在此进行一番清晰的梳理：

本文面向那些对OpenClaw充满好奇，又不希望被复杂代码劝退的产品经理、运营人员及创业者。

笔者将力求从工程视角进行阐述，但表达方式会偏向产品经理可落地理解的范畴：帮助您理解它能做什么、如何运作、能力边界何在、潜在风险有哪些，以及是否值得投入。

OpenClaw 到底是什么？

许多人在初次接触OpenClaw时，会同时受到两种极端叙事的冲击：

1. 一种将其描绘为**“奥创”降临的前夜**：安装后，您便获得了一位能够替代您工作的数字员工。
2. 另一种则贬斥其为**“脚本套壳”**：无非是传统自动化工具披上了一层AI的外衣。

这两种观点都只揭示了部分真相。更贴近工程现实的结论是：

OpenClaw 是一套集成了聊天入口、智能体编排、本地执行沙箱及可扩展技能包的开源数字员工框架。

它并非“具备思考能力的生命体”，更非“万能的自动化解决方案”。其本质在于将大语言模型的推理能力，接入一套可控的执行系统中，使得AI从“仅能对话”进阶为“可以实操”。

换言之：它并非AI能力本身，而是将AI能力转化为可交付产品的那一层关键工程与产品化封装。

三个核心问题：穿透喧嚣，直达本质

在接触任何新技术或产品之前，习惯性地提出三个问题，有助于快速将“自媒体叙事”还原为“产品事实”。

问题一：它究竟解决什么核心痛点？ OpenClaw解决的并非“让AI更擅长聊天”，而是一个更为具体、商业价值也更明确的痛点：

1. AI的价值常常卡在“最后一公里”：您可以向它提问并获得方案，但若要求它将方案实际落实到您的电脑、浏览器、文件系统或操作系统中，它便“断电”了。
2. OpenClaw的核心作用正是：将“文本方案”转化为“具体动作”，把“口头建议”变成“实际执行”。

问题二：它是如何实现这一点的？ 它所依赖的并非某个神秘模型，而是一个朴素且高度工程化的解耦架构：

1. 前端负责指令接收，支持微信、飞书、Telegram、命令行界面（CLI）等多种渠道。
2. 中端负责决策与流程编排，即智能体运行器（Agent Runner）：理解意图、规划步骤、循环调用工具。
3. 后端负责安全执行，即部署于本地或服务器的执行器：在受控的沙箱环境中执行具体操作。

问题三：这与我有什么关系？ 答案取决于您的角色，这决定了您应当兴奋还是保持冷静：

1. 如果您是重度电脑使用者，日常工作充斥着手动整理、复制粘贴、运行脚本、数据查询、表格填写等重复劳动：OpenClaw可能成为您的“数字效率助理”。
2. 如果您是团队管理者：它更类似于一位“可复用的自动化实习生”，前提是您能将任务高度标准化，并严格管控其权限与操作风险。
3. 如果您是产品构建者或决策者：OpenClaw最值得深究的并非其现有功能，而是它所提供的一套“数字员工产品范式”。

带着以上三个问题的清晰认知，我们方可进入真正的“拆解”环节。

拆解 OpenClaw：核心架构一览

OpenClaw的整个系统可以简化为三个核心组件外加一个扩展机制。您可以将OpenClaw的结构形象地记忆为：入口 — 大脑 — 手脚 — 技能包。

1. 入口（Gateway）：负责接收来自微信、飞书、Telegram、网页等各类渠道的消息，进行统一的格式化处理与路由分发。
2. 大脑（Agent Runner）：调用大语言模型以理解用户意图、规划任务步骤、决策调用哪些工具，并在多轮循环中驱动任务直至完成。
3. 手脚（执行器/沙箱环境）：真正操作文件系统、命令行、浏览器、调用API等，并实施严格的权限与安全控制。
4. 技能包（Skills）：使系统能力能够像“插件”一样扩展。安装一个新技能，即增添一项可执行的新能力。

下方图示，是帮助非技术人员高效理解OpenClaw整体架构的“总览图”：

这套架构的关键价值在于：实现了“思考决策”与“动手执行”的职责分离。而其真正能够流行起来的原因，很可能在于“入口”层面切实解决了用户“最后一公里”的便捷性问题。

接下来，我们通过一两个简单实例，来直观感受其工作流程。

从案例到流程：一次完整的任务执行

假设您在微信中发出指令：“帮我整理桌面上的PDF文件，按项目名称分类放到对应的文件夹里。”

这条消息将在OpenClaw内部经历一段标准化的工程流水线处理。

阶段一：入口的“翻译与分发”

微信消息首先被相应的适配器捕获，并转换为内部通用数据格式（通常是JSON），随后提交给网关（Gateway）。 Gateway扮演着“交换机”的角色：它知晓这条消息应路由至哪个助理实例处理；同时也能识别一些无需大模型介入的基础指令（如 /help），直接进行本地化处理以提升响应效率。

阶段二：大脑的ReAct推理循环

智能体运行器（Agent Runner）在此阶段 typically 执行以下步骤：

关于钉钉AI表格与飞书多维表格在当前行业中所处的生态位及其核心目标，我们此前已进行过较为深入的探讨：

企业迫切需要一套能够实现 “多人分散录入 → 集中汇总 → 统一分析 → 按权限查询” 的轻量化系统。

过去，Excel、OA系统以及各类低代码平台都在争夺办公领域的市场份额，而目前表现最为突出的无疑是飞书多维表格和钉钉AI表格。

企业追求 “这套系统” 的原因十分明确：传统的协作方式效率确实过于低下。一旦引入合适的系统，效率的提升将极为显著。

然而，必须指出的是，这种效率的跃升并非完全由AI表格技术本身带来，或者说：

AI表格所带来的改进属于企业数字化转型过程的自然延续，其中AI技术实际贡献的比例并不高，通常仅占10%左右。

尽管只占10%，但这部分价值绝不能忽视，因为它构成了整体拼图的最后关键一块，对于实现系统功能的完整性具有重大意义。

此外，市场上还存在一些看似处于同一赛道的产品，如Coze、Dify、FastGPT等。实际上，它们与AI表格并非同一竞争维度：

AI表格具备真正替代传统OA系统的潜力，而Coze等平台则难以胜任。后者的应用场景更多地局限于简单的知识库构建或对话交互。

理解这一点需要我们从实际使用者——如HR、财务等业务人员的视角出发。他们通常并不青睐对话式交互体验，甚至可能有所排斥。他们早已习惯于Excel的操作逻辑，能够熟练地从一张表格中快速定位关键数据，且这一行为模式已相当固化。Excel才是他们真正意义上的“工作台”。

综上所述，在AI办公这一赛道中，体验上无限趋近于Excel的表格形态无疑是核心中的核心。基于这一基本认知，我们再来深入探究多维表格应用模式究竟是什么。

多维表格应用模式探析

此处直接引用官方定义进行阐述：

多维表格应用模式代表了一种创新的业务系统搭建方式。通过简单的拖拽操作，即可构建出专业级的业务系统，无需任何技术背景。业务人员也能快速创建出符合实际业务需求的交互界面与流程。

应用模式提供了面向最终用户的操作界面，而多维表格则提供了底层的数据库和运行引擎。一个应用可以关联多个多维表格文件，两者相辅相成，共同构成一个完整的业务系统。

坦率地说，基于我对AI表格的现有理解，初次接触这个定义时仍感到有些费解，因此决定亲自体验一番。于是，我直接打开了已有的多维表格文件，点击进入“应用”模块：

界面中呈现了丰富的组件库：

我们不妨设想一个具体功能：需要整理各种编程工具的评分（以星数为计），并依据星数多少进行排序。为此，我们选择一个柱状图组件：

初步尝试时遇到了一些配置障碍，不确定后续如何设置。于是，转而从官方模板库中选取一个现成模板进行学习。我们的需求与该模板颇为相似：

该模板的数据源名为“M1-团队业绩”：

由此看来，正确的做法似乎是：为原始数据源新建一张数据表，并将其中的文本描述转化为结构化数据：

在此基础上，我们再次尝试创建排序表格，结果立即成功呈现：

至此，相信各位对多维表格应用模式的本质已有判断：它本质上属于零代码编程的范畴，主要应用于基础数据就绪后的分析与展示环节，是 “多人分散录入 → 集中汇总 → 统一分析 → 按权限查询” 流程中，“统一分析与展示”模块的具体实现。

就个人观点而言，这项功能应被视为一项基础配置，其重要性并未达到网络上某些宣传所描述的“神乎其技”的程度。更重要的是，它所解决的问题，并非企业数字化转型实施过程中的核心痛点！

那么，企业真正的难点是什么？他们究竟缺少什么？

企业核心痛点与缺失环节剖析

大约在五年前，当时尚未出现多维表格这类工具（或我个人未曾接触）。公司曾面临一个令人极为困扰的需求：

公司需要与大量外部兼职人员协作进行数据整理，涉及流程极其复杂：

1. 每日内部人员需面试大量兼职者，单日数据过百后，缺乏系统支撑，操作现场混乱不堪；
2. 兼职人员初试通过后进入作业群，需实际完成一份测试任务，经内部员工评估合格后方可转为长期兼职；
3. 进入实际数据处理阶段后，又需经历 “提交→初审（通过或打回重做）→复审（通过或打回重做）” 的反复循环；
4. 每日结束时，需根据实际完成情况对数据进行归档并结算费用。

这是一套完整的标准作业程序工作流，执行周期仅三个月。专门开发系统不仅时间上来不及，后续的迭代效率也无法满足需求。

由于经常遇到有人擅自修改数据且无操作日志可查的情况，我个人感到十分困扰。同时，由于缺乏有效的消息通知机制，流程节点常常被卡住。为此，公司曾调配三名项目经理进行协调，但实际执行中依然问题频发……

其实，这里的核心需求非常简单：在Excel的基础上，增加权限控制（视图控制）功能，并在数据更新后触发定向通知即可。

然而，正是这样一个看似简单的功能，在多维表格问世之前，我一时之间竟束手无策！

以上案例真实地回答了企业缺失什么以及为何不自行开发的问题。从中亦可看出，企业真正需要的是一套能够快速组织数据与流程的工具。如果能用自然语言实现则更佳，因为梳理SOP本身就是一个繁琐的过程。

根据以往项目经验，完整实施一套中等复杂度的AI工作流系统大约需要三个月。其中，两个月时间都用于与企业共同梳理业务流程。流程梳理的产出通常包括两项关键成果：

SOP流程图以及对应的数据结构。这两者便是我们所谓的 “AI时代的自然语言” ，其形态如下所示：

AI客服与多轮问答：洞察项目本质

近日，一位正在AI领域创业的粉丝，在阅读了《AI学习路线图》后向我提出了一个颇具代表性的困惑：他感觉自己的项目“AI含量”很低，不清楚方向是否正确，希望我能提供一个概括性的说明帮助他快速理清思路。

实际上，开展AI项目必须具备全局视野，清晰定位自己正在涉足哪种类型的AI项目至关重要。我们曾对所有AI项目进行过系统性的分层解析，不同类型的项目在实施难度、成本投入以及核心卡点上存在显著差异，因此所需的能力模型也截然不同。

结合过去两年服务多家公司的实践经验，当前企业需要重点关注的AI项目主要可以归纳为以下三类：

1. 工作流AI；
2. AI客服；
3. 多意图、多轮知识问答系统。

如果你对团队正在推进的AI项目属于哪一类别毫无概念，那就需要引起高度重视了。AI项目往往具有一种“看似简单，实则精妙”的特性，如果底层的方法论出现偏差，后续将不可避免地走上许多弯路，这些就是所谓的“AI项目试错成本”。

例如，去年我们曾为某公司部署了一套AI客服系统，初期效果显著，效率大幅提升，以至于该公司直接裁撤了整个客服团队。然而，后续他们在自行迭代系统时，不慎破坏了原有的架构设计，导致系统出现问题后，由于没有人工客服可以应急补位，造成了重大损失。最终，他们不得不重新召回部分客服人员以备不时之需。

这些经历都是宝贵的“学费”。为了避免大家重复缴纳这些学费，接下来我将分享一些私密的实战心得。

工作流AI：数字化与流程优化的核心

在近两年专注于“AI+管理”的实践过程中，我接触了超过三十家企业，并深度服务了其中十余家，共主导完成了23个AI项目。值得注意的是，其中有18个都属于标准的工作流AI项目。

这意味着，近80%的企业需求都指向了工作流类AI项目！

面对这个结论，不少朋友会心生疑问：这也能算AI项目？

他们发现，这类应用的重点和难点，几乎完全集中于梳理工作流程、制定标准作业程序（SOP） 上，而AI技术在其中所占的比重，有时甚至不足20%。

于是，有人怀疑自己的“打开方式”不对，转而尝试采用类似“智能体（Agent）”的架构，试图让AI自主感知、规划并执行任务。这样一来，系统的复杂度是上去了，但实际表现往往显得笨拙而不实用。

为了提升效果，他们不得不在提示词（Prompt）设计上投入大量精力，甚至尝试将完整的SOP“口述”给AI，结果依然不尽如人意，最终感到气馁：所谓的智能体，还不如规规矩矩的工作流好用，费这么大劲图什么呢？

以上这些，正是工作流类AI项目面临的标志性问题。处理这类项目时，必须深刻理解其内核：这类项目的本质是推动企业数字化，流程梳理自然是重中之重，没有必要人为地增加技术复杂度。

从企业的视角来看，他们真正需要的是一套能够实现**“多人分散录入 → 集中汇总 → 统一分析”** 的轻量级系统。这块市场过去由Excel、OA、低代码平台等工具争夺，而当下竞争尤为激烈的，是飞书多维表格与钉钉AI表格这类新兴生产力工具。

所有这类项目的难点都不在于技术开发，而在于梳理SOP与沉淀行业Know-How。其背后折射出的核心理念是“数据即流程”。同时，企业始终追求低成本、快上线，哪种工具生态系统能够最好地满足这些诉求，企业就会选择它。

因此，这类项目的核心是流程重构与优化，在整个系统运行中，AI的占比确实不重。甚至，将其严格归类为“AI项目”可能都显得有些勉强。

以最近在HR体系进行的一个AI赋能项目为例，AI的实际占比确实不足20%（图中蓝色部分为必须由AI处理的环节）：

所以，面对这类项目，最务实的做法就是老老实实地梳理工作流。最终选择用代码原生开发，还是利用AI表格等工具来实现，都可以根据实际情况灵活决定。这类系统的真正挑战，往往在于管理层面：

当然，这里也引出了两个值得思考的遗留问题： 第一，何时应该引入AI的泛化能力，以增加整个系统的灵活性，让我们的AI系统不仅能解决固定问题，还能像智能体一样，引导用户进行更自由的探索？ 第二，钉钉等平台提出了“AI表格助理”的概念，声称可以一键生成SOP，这是否意味着我们不再需要自行梳理SOP了？

关于第二个问题，答案是想得太简单了！除非有一天，Claude Code这类工具能够完全、准确地理解你的复杂业务需求，否则“AI表格助理”的基础恐怕都难以真正成熟。

第一个问题则相对复杂一些，我们稍后再做探讨。接下来，我们先明确一下工作流AI的实施方法论。

工作流AI实施方法论

前文粉丝的困惑，暴露的是项目实施层面的具体问题。我们除了要理解他直接提出的疑问，还应洞察其背后“隐藏”的关切：在企业体系内，究竟应该如何系统地实施工作流AI？ 这可以拆解为三个层次的问题：

1. 我们该如何决策优先用AI解决哪些业务环节？
2. 我们该如何推动实施，并说服管理层提供支持？
3. 最后才是粉丝遇到的、关于具体如何操作的执行层困惑。

实际操作起来，有一套简洁的口诀可循：先看预算再分拆，能用AI就AI。

• 先看预算：即全面梳理公司的各项业务，找出成本投入最高的部分，优先对其进行AI化改造。
• 再分拆：将目标业务模块的每个操作节点进行极度细致的拆解。可以参考如下示例：

或者这种形式：

如果需要向管理层汇报，则还需要完成三件事：

1. 将拆解后的流程节点中，需要用到AI技术的关键环节醒目地标注出来。
2. 分析该节点的现有成本结构。
3. 估算出利用AI实现该节点自动化或智能化的改造成本。

最终，你需要向决策者呈现一本清晰的“账本”：我们计划用AI具体优化业务的哪个环节，这个环节原先耗费了多少成本，而用AI改造它又需要投入多少资源？

相较于技术实现本身，能够有效说服老板、争取到预算，往往是项目前期更重要的一个卡点。

总结与展望

近来有读者反馈我的文章内容略显详尽，因此本次分享暂且到此为止。最后做一个小结： 工作流AI属于最为基础的AI项目类型，通常是顺手就能推进、成功率高且几乎必然带来效率提升的项目。对于企业的技术负责人而言，推广这类稳赚不赔的项目以提升自身影响力，是相当划算的选择。

当然，它的缺点也很明显：AI技术含量较低，不太具备“高科技感”。如果你希望挑战AI含量更高的项目，就不得不提到另外两大类型：AI客服与多意图、多轮知识问答系统。

AI客服：数据处理与准确率的博弈

AI客服属于入门级的AI应用，其核心在于相对简单的数据处理，多用于标准的一问一答场景。值得指出的是，在完成本体任务（即SOP执行）后，是可以引入类智能体的闲聊功能来增强体验的。

这类项目的难点同样不在于复杂的代码开发，而在于数据处理。由于问答逻辑相对简单，数据复杂度较低，技术上几乎不存在难以逾越的障碍。当前许多AI客服系统面临的最大挑战，其实是准确率。

• 如何将系统准确率从80%提升到90%？这主要是一个提示词工程问题。
• 如何从90%提升至95%？这就进入了数据工程的范畴。
• 如何从95%推进至98%？这需要构建有效的数据飞轮系统。
• 如何最终达到99.99%的极致可靠？这涉及到更复杂的快慢系统设计，此处不再展开。

多意图、多轮知识问答：殿堂级的系统工程

多意图、多轮知识问答则属于殿堂级的AI应用，其核心在于复杂的数据工程与思维链（CoT）设计。国内很多公司在这一领域都处于“心向往之，然力不能及”的状态。

在推进AI项目的进程中，“可观测性” 是一个无法回避的核心议题。可观测性本质上关联着项目的可评估性，由此衍生出诸如RAG评估系统、AI专业能力评估策略等一系列重要课题。

例如，OpenAI此前联合来自60个国家/地区的262位医生，基于5000个真实医疗对话场景构建的 HealthBench，便是一套综合性评估策略的典范，尽管其侧重点更偏向于整体性能评估。

本文将聚焦于大模型厂商Anthropic发布的一篇关于Agent评估的技术论文，借此深入探讨AI项目评估的系统化方法与工程实践：

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

什么是评测？

评测是对系统进行系统性检验的方法。通过输入预设的任务，检查Agent的输出或行为是否符合预期目标。

Anthropic将完整的评测流程拆解为以下几个结构化模块：

1. 任务：代表一次独立测试的输入指令及其对应的成功标准。
2. 单次试验：指任务的一次具体执行过程。由于模型输出存在随机性，通常需要多次运行同一任务以获得稳定的评估结果。
3. 评分器：用于评估Agent在某个特定维度上表现的判定逻辑。一个任务可以包含多个评分器及检查点。
4. 记录：完整记录单次试验过程中的所有细节，包括输入、输出、工具调用、中间推理步骤及结果。
5. 结果：指单次试验结束时环境的最终状态。例如，一个订票Agent可能输出“机票已订好”，但真正的评测结果需要通过检查数据库是否存在有效的预订记录来确认。

通常，一个评测框架会提供并发运行任务和工具、记录全过程并自动评分的功能。

一个有效的Agent评测体系必须覆盖从输入到最终行为的完整闭环，确保Agent在多轮交互和复杂工具调用中的表现都能被有效量化和评估。

评估的价值前文已有提及，Anthropic的表述虽然略显抽象，但其核心理念可以概括为：通过明确界定成功标准，使开发团队能在产品上线前主动发现问题，而非在用户投诉后才被动进行修复。

Anthropic指出，缺乏系统评测的团队往往陷入“被动修复”的循环，每解决一个已知问题都可能无意中引入新的问题，且难以区分性能波动是真正的回归还是模型输出的随机性所致。

需要补充的是，即便建立了评估体系，也可能出现修复一处而另一处出现问题的情况，这是Agent乃至所有AI项目固有的复杂性所带来的挑战。

然而，毋庸置疑的是，采用系统化评测的团队对项目本身的理解必然更为深刻。相应的，他们的工作方式也会更加专业，能够利用失败的测试用例持续“训练”和优化系统。最终，当这个自我强化的“飞轮”成功运转时，几乎就意味着整个项目走向了成功。

从能力评测到任务评测

Anthropic将评测主要分为两大类：能力评估与回归评估。

能力评估是项目可观测性的基石，它聚焦于“Agent能做什么”，通常从通过率较低、Agent容易失败的任务开始，目标是量化和推动模型新能力的提升。

而回归评估则关注“Agent是否仍然能完成之前可以胜任的任务”，其预期通过率应接近100%，主要用于防止在版本更新和迭代过程中引入性能倒退。实践中，最佳方式是复用历史错误数据集，确保每次发布前都执行一遍回归测试。

在实际项目开发中，我们也能观察到这种分类趋势。以Descript的视频编辑Agent为例，其评测体系围绕“不破坏已有内容、按要求准确执行、执行质量”三个核心维度设计。

这套评测体系经历了从人工评分，逐步演进到由产品团队定义标准、LLM自动执行评分，并辅以周期性人工校准的过程。目前，他们常态化运行两套测试：一套用于质量基准评测，另一套用于回归测试。

而Bolt AI团队则是在Agent已被广泛使用后才着手搭建评测系统。他们在3个月内构建了一套完整的自动化评测流程，包括自动运行Agent、对输出进行静态代码分析、浏览器应用测试，以及使用LLM作为评判者来检测Agent的行为表现。

结合我们过往在大型AI项目中的生产实践经验，系统化的评测体系无疑是提升迭代效率、保障产品质量的关键工具。

只有建立了可量化评估的指标与方法，我们在面对AI项目时才不会盲目摸索，也不会轻易得出“模型能力仅止于此”的片面结论。

如何进行评测

Anthropic总结了三种主要的评测方式：代码型评分器、模型型评分器和人工评分器。

模型评分

模型型评分器是指使用另一个大语言模型来进行打分或判断，例如基于评分量表的打分、自然语言断言、与参考答案对比等。

这类评分器的优势在于灵活性高，能够捕捉主观性强和开放式任务的细微差别。但其缺点在于结果存在不确定性，需要消耗更多计算资源，并且必须通过人工标注来进行校准以确保其准确度。

在问答、摘要、对话等输出形式多样的任务中，模型型评分器可用于衡量答案是否符合人类预期、是否优雅有用、是否遵循指定的格式规范等。

例如，在对话型Agent的评测中，常常需要第二个LLM来模拟用户发起多轮问答，并通过精心设计的提示词来评价Agent的交互质量和目标完成度。

从广义上讲，前文提到的HealthBench就可以采用模型评分器来实施。

人工评分

这种方式大家最为熟悉，它是最原始、理论上也最“可靠”的评分方式。人工评分器适用于需要专家判断或难以用简单规则量化的复杂场景。

人工标注能够提供“金标准”质量，精准匹配专业用户的主观评判，通常用于校准模型评分器或进行最终的质量验收。然而，其代价是昂贵且耗时的。

实践中，可以采用抽样检查、专家复核或众包评估等方式，对关键指标或异常输出进行人工审查，以确保评测结果的可靠性。

代码评分

代码型评分器涵盖了字符串匹配、断言检查、静态分析、环境状态校验等方法，通过确定性的逻辑来快速判断结果是否符合预期。

其优点是高效、客观且易于复现，特别适用于结构化输出和确定性任务，例如对编程Agent的代码输出进行评估。

在编程Agent的评测中，常规做法是对生成的代码运行自动化测试，只要代码能通过预设的单元测试即可认定为通过。

Anthropic指出，对于此类任务，“代码型评分器是天然的选择”：软件任务可以直接用“代码是否能成功运行、测试是否通过”来客观评价。

人工评分最为人熟知，模型评分则是我们用模型替代人力、提升效率的工具。而“代码评分”这个概念可能让许多同学感到困惑：它究竟指什么？

代码型评分器的核心并非“测试代码生成能力”，而是 利用代码执行这一确定性手段，来验证Agent在完成复杂任务后所产生结果的正确性。

它旨在解决Agent评估中的一个主要痛点：对于复杂、开放式的任务，如何避免主观、模糊的评价，实现自动化、客观的评估？

举例来说，“编写一个计算斐波那契数列的Python函数”这个任务，其结果是可执行的。

这个例子背后对应着论文中一个较为拗口的翻译：任务的结果必须能够通过某种明确的规则或外部系统进行客观验证。

在这个场景下，就可以使用代码评分器：一个脚本会自动导入Agent生成的函数，然后用一系列测试用例（例如 fib(10) 是否等于 55）去运行它，并检查结果是否正确。

此处的“评分器”就是一个自动化的验证脚本或规则引擎。它的作用是：接收Agent的产出，调用相应的工具或应用预设的规则，判断产出是否满足事先定义的成功标准。

再比如，许多涉及工具调用的任务就很适合采用代码评分器。一般的AI项目可能不常用到此方法，但它非常契合Agent的工作模式，因此许多同学对此不太熟悉。

接下来，我们需要根据不同的项目领域进行区分：不同类型的AI Agent，由于其任务目标和交互模式各异，需要采用针对性的评估策略。

编程型Agent

编程型Agent需要完成编写、测试和调试代码的任务，其评估通常借鉴软件工程中的测试思想。常见做法是赋予Agent明确的编程任务，例如修复代码漏洞、实现特定功能模块等，并使用自动化测试或脚本来验证输出代码的正确性。

例如，著名的基准测试SWE-Bench和Terminal-Bench都基于这一思路构建：

1. SWE-Bench会提供一个GitHub问题，要求Agent修改代码，修改完成后使用项目原有的测试套件进行验证。
2. Terminal-Bench则要求Agent完成一项完整的工程任务（如编译Linux内核），通过成功执行所有必要步骤来判断其是否合格。

这些评估的关键在于准备可运行的测试环境和详尽的单元测试，以便对代码结果做出二元化的判定。

除了最终的结果验证，还可以对Agent的执行过程进行评估。例如，使用静态分析工具检查代码质量，使用LLM评分器评估其代码风格和可读性，或者检查Agent调用了哪些工具和命令，以确保工具调用序列的合理性。

以下YAML示例展示了一个复杂编码任务的评估配置，其中可以包含单元测试、静态分析、状态检查和工具调用检查等多个评分器：