拒绝硬编码：我用这套 AML 模板引擎，让数字员工学会了“举一反三”

# 拒绝硬编码：我用这套 AML 模板引擎，让数字员工学会了“举一反三” 昨天深夜，有个老客户微信找我吐槽。说他们刚上线的自动化流程，业务字段改了一个字母，整个服务就得重新打包上线。这太折腾了嘛。我回他：你还在用“死”代码做“活”业务。自动化引擎得像乐高，能拆能拼，还能动态生成。 最近我在改“左帮右臂”数字员工平台的架构，专门搞了一套 AML 模板管理系统。这玩意儿的核心不是执行任务，而是定义和复用任务。让数字员工从“只会做一件事”变成“能根据指令做一百件事”。 底层存储我设计得很精简。SQLite 里就两张核心表：`AmlTemplate` 和 `AmlObject`。前者存“怎么做”，比如操作类型、模板内容；后者存“做什么”，记录业务对象和 Schema。模板和数据分开，业务对象随便变，只要模板逻辑不变，系统就稳嘛。 为了配合存储，我搭了套 RESTful API。模板管理接口支持动态查询。开发者传个 `type` 和 `item_type` 参数，就能筛出特定场景的模板。比如查所有针对“客户对象”的“查询类”模板。新增模板时，系统自动处理 JSON 序列化，前端传来的复杂配置能无损存进数据库。维护起来省事多了。 让系统变“聪明”的是模板渲染引擎。我写了个轻量级渲染函数，支持两种语法。一种是变量替换，比如 `{name}` 直接换成参数值。另一种是条件渲染，像 `{status?:}`。模板能根据上下文动态生成 XML 结构。状态为空就不生成标签，有状态就带上值。一套模板能适配多种业务分支。 渲染完还得执行。系统先根据 ID 从数据库拉模板，渲染引擎处理后生成标准 AML 字符串，再交给底层执行器调用业务逻辑。用户不用管这些，只关心输入参数。系统自动完成“模板查找 - 变量渲染 - 指令执行”。业务接入门槛低了不少。 最让我兴奋的是它和大模型的结合。以前创建新业务对象，得程序员写代码定义字段。现在通过 AI 代理，用户用自然语言描述需求，系统自动生成 AML 代码。比如用户说“创建一个汽车零件对象，包含编号、名称、价格”，大模型直接解析出标准 AML 结构。 生成的 AML 内容直接通过对象 API 批量导入数据库。系统自动识别 `item_type` 和 `name`，存入 `AmlObject` 表。数字员工能执行任务，也能动态“学习”新业务对象。这种“生成即使用”的能力，传统工作流引擎比不了。 设计系统时，我把文件结构分层分得很细。数据库初始化、模板 API、对象 API、渲染逻辑、执行逻辑，各自独立，互不干扰。后续迭代时，我可以单独优化渲染算法，不影响存储层。对企业级应用来说，可维护性比功能本身更重要。很多系统初期跑得快，后期改不动，就是因为架构耦合度太高。 用这套 AML 模板引擎，其实是在构建一个“元编程”系统。代码不直接写死业务逻辑，而是描述逻辑的生成规则。业务需求变了，改模板或加参数就行，不用动核心代码。这种架构思维，对正在探索数字化转型的团队或许有用吧。技术是工具，更是组织业务逻辑的一种方式。 如果你也在搞类似的自动化系统，或者对数字员工背后的技术架构感兴趣，建议亲自上手试试。我们已经在“左帮右臂”平台集成了这套引擎，直接访问 eastaiai.com 就能看实际场景里的效果。真实业务场景，比文档说明问题更直接。期待在社区看到你的实践反馈，一起把数字员工的能力边界拓宽点。