过程式AI与声明式AI(with Claude)

ai产品, 声明式编程, 过程式编程, 工程实现, ai工具
19 13~17 min

过程式AI与声明式AI(with Claude)

这个概念来自于编程: 声明式编程 命令式编程

或者, 请让我用更加简单的描述:

声明式: 我要的结果是什么. 关注目标而非过程,描述期望状态.

命令式: 经过什么操作之后, 能够得到结果. 描述执行步骤, 组合行为最终得到结果.

我要讲述这样的观点:

  1. AI Native的产品应该是声明式的
  2. AI Agent的工程应该是过程式的

产品和AI产品

以AI为卖点的产品应该有什么样的特性?

传统产品：命令式的操作逻辑

传统软件产品遵循"告诉我怎么做"的设计理念。用户必须学习并执行一系列精确的操作步骤：

  • Word：格式 → 字体 → 选择字号 → 应用
  • Excel：数据 → 筛选 → 设置条件 → 确定
  • 视频剪辑：导入素材 → 拖到时间轴 → 添加转场 → 调整参数

用户需要理解软件的内部逻辑，掌握操作流程，才能得到想要的结果。学习成本是使用的前提。

AI产品：声明式的交互范式

AI Native产品的核心是"告诉我你要什么"：

  • ChatGPT："帮我写一封给客户的道歉信"
  • Midjourney："赛博朋克风格的东京街道，雨夜，霓虹灯"
  • GitHub Copilot："实现一个二分查找算法"

用户表达意图，AI理解并执行。理解意图取代了操作步骤。

声明式AI产品的三个关键特征

1. 意图驱动

传统产品：如何做？(How)
AI产品：要什么？(What)

2. 结果导向

  • 用户关注最终输出，而非中间过程
  • 评判标准从"操作是否正确"变为"结果是否满意"

3. 自然表达

  • 使用日常语言而非专业术语
  • 降低认知负担，让更多人能够创造

AI产品面临的核心挑战

意图理解的模糊性

当用户说"做个漂亮的PPT"时：

  • 什么是"漂亮"？商务风还是创意风？
  • 多少页合适？
  • 什么配色方案？

结果的不确定性

同样的输入可能产生不同的输出，这种不确定性既是AI的魅力，也是用户焦虑的来源。

声明式不等于失控

优秀的AI产品应该在保持声明式简洁的同时，提供必要的控制能力：

  • Claude：可以要求特定格式、风格、长度
  • Midjourney：通过参数微调控制输出
  • Cursor：接受高层需求，也响应具体指令

关键是默认简单，可选复杂。让新手能快速上手，让专家有深度控制。

工具和AI工具

Blender/3D Max 等等为什么应该强调工具属性, AI工具应该弱化甚至消除工具属性吗?

传统工具：强调精确控制与过程掌握

  • Blender/3D Max/CAD：用户需要学习复杂的界面、众多的参数、精确的操作流程。工具赋予用户像素级、节点级的控制权。这种过程本身对于专业人士而言，既是创作也是表达。

  • Photoshop：图层、蒙版、画笔、滤镜...每一个工具和步骤都是为了实现用户脑海中精确的视觉效果。

  • 特点：

    • 高学习曲线：需要大量时间掌握。
    • 强过程参与：用户深度介入每一个环节。
    • 高控制精度：结果的可预测性和可控性强。
    • 工具即技能：掌握工具本身就是一种专业能力。

AI工具：追求意图理解与结果生成

理想中的AI工具，如您所说，希望达到：

  • 用户："我想要一个带有未来科技感的城市天际线，傍晚，有飞行器穿梭。"
  • AI工具：直接生成符合描述的3D场景或图像。

这在概念设计、快速原型、灵感激发等阶段非常强大。

为什么AI工具不应“完全”消解工具属性和实现过程？

  1. 精确性与定制化需求：

    • 当需求不仅仅是"一个结果"，而是"完全符合我特定要求的这一个结果"时，纯声明式AI可能难以满足。例如，建筑师需要精确到毫米的结构设计，工业设计师需要特定曲率的表面。
    • AI可以生成初步方案，但微调和最终确认往往需要传统工具的精确控制。

  2. 创造过程的探索性与偶然性：

    • 很多时候，创造并非始于一个明确的目标，而是在使用工具的过程中不断探索、尝试、修正，甚至从"错误"中获得灵感（"Happy Accidents"）。
    • 如果AI完全替代过程，可能会剥夺这种探索的乐趣和可能性。艺术家与画笔、颜料的互动本身就是创作的一部分。

  3. 专业知识的深化与传承：

    • 理解工具的运作原理和实现过程，有助于深化对领域的认知。如果完全黑箱化，用户可能只知其然不知其所以然。
    • 对于专业人士而言，工具是他们思考和表达的延伸。

  4. 责任与可解释性：

    • 在一些高风险或关键领域（如医疗诊断辅助、工程设计），如果AI生成的结果有误，理解其生成过程对于追溯和修正至关重要。
    • "黑箱"式的AI在这些领域难以被完全信任。

  5. AI的局限性：

    • 当前的AI并非万能，其理解能力和创造力仍有边界。它可能无法完全捕捉用户微妙的、复杂的或高度创新的意图。
    • 在AI无法满足需求时，用户需要有能力介入并手动操作。

工程实现的过程式

细节是魔鬼, 黑盒也是魔鬼, 工程实现应该尽可能的消解不透明度

  1. 工程的本质要求精确、可验证和可复现：

    • 精确性 (Precision) ：工程成果（无论是软件、硬件还是物理结构）往往需要满足极其严格的规范和性能指标。"差不多"在工程中是不可接受的。一条简单的命令很难蕴含如此复杂的约束。形式化的工具和语言（如CAD软件的参数化建模、编程语言的类型系统、形式化验证语言）是确保精确性的基石。
    • 可验证性 (Verifiability) ：工程成果必须能够被验证其是否符合设计要求、是否安全、是否可靠。这需要测试工具、仿真环境、静态分析器等。一条简单的命令生成的结果，如果其内部逻辑是黑箱，就很难进行有效的验证。过程式的步骤和中间产物为验证提供了锚点。
    • 可复现性 (Reproducibility) ：给定相同的输入和环境，工程过程应该能产生相同的结果。这对于调试、审计和迭代至关重要。版本控制系统、构建脚本、自动化测试框架等工具保证了过程的可复现性。

  2. 复杂系统的分解与管理：

    • 大型工程项目极其复杂，远超单一命令所能概括。必须将其分解为更小的、可管理的模块和任务。每个模块可能由不同的团队或专业工具负责。
    • MCP或A2A这样的AI系统，更像是高级协调者或指挥官。它们发出的"简单命令"可能是对下一级AI智能体或传统工具的高层指令，而这些智能体或工具内部依然遵循着严谨的过程式逻辑来完成具体任务。例如，MCP可能命令"构建并部署用户认证模块"，但这个模块的实现依然需要代码编写、编译、单元测试、集成测试、打包、部署等一系列过程式步骤，这些步骤由专门的工具（IDE、编译器、测试框架、CI/CD流水线）支持。

  3. 风险控制与安全保障：

    • 在许多工程领域（如航空航天、医疗设备、金融系统），失败的代价极高。形式化的方法和过程是管理风险、确保安全的重要手段。例如，安全关键系统的开发有严格的编码标准、审查流程和认证要求，这些都依赖于过程和工具。
    • AI生成的内容，如果缺乏透明度和可解释性，很难在这些领域被直接采纳用于核心功能，除非其生成过程本身是可信的，或者其输出经过了严格的过程式验证。

  4. 调试、维护和迭代的需求：

    • 任何复杂的工程系统都会出错，都需要调试。过程式的实现和日志记录、状态快照等工具对于定位和修复问题至关重要。如果只有一个"黑箱"AI的最终输出，调试将异常困难。
    • 系统建成后需要长期维护和升级。理解系统的内部结构、模块间的依赖关系、历史变更记录（通过版本控制）是维护的前提。这些信息都蕴含在过程式的开发和文档中。

  5. 人类认知与协作的局限性：

    • 即使AI能力再强，人类工程师仍然需要理解、审查和批准AI的工作。过程式的展现方式（如设计文档、流程图、代码审查）更符合人类的认知习惯，便于团队协作和知识传递。
    • A2A协作也需要明确的接口定义、通信协议和任务边界，这些本质上也是一种形式化的过程约定。

  6. "简单命令"背后的复杂语义：

    • 看似简单的命令，如"设计一个高效的排序算法"，其背后可能需要AI调用算法知识库、性能分析工具、甚至代码生成和测试工具，这些内部运作依然是高度过程化和工具化的。AI的"简单"在于用户交互层面，而非其内部实现层面。

指标

这里我抛砖引玉, 提出一些我觉得可能需要引入的指标

  1. 不介入成功率（Non-intervention success rate, NSR）
    · 定义：一次交互或一个自动流程即可达到业务验收标准的占比。
  2. 平均完成时长（Time-to-Completion, TTC）
    · “提出需求 → 最终验收”所用的壁钟时间。
  3. 用户介入次数（Human Intervention Count, HIC）
    · 每个任务中用户需要再次下指令、修改 prompt、点击确认的次数。
  4. 重试-修正回合数（Retry Rounds, RR）
    · 从首次输出到可接受结果所经历的来回轮数。