167、SAP Fiori与ABAP开发
2026/9/6 5:12:47
核心论点：大模型没有改变"精确任务占 80-90%“这个比例，它改变的是任务入口——把原来由人桥接的"模糊输入→精确输出"自动化了。WorkBuddy、OpenClaw 这类桌面 Agent 让非技术人员也能用自然语言控制电脑，但构建这些 Agent 的能力边界、定义自动化规则、保证系统安全可控，仍然是工程师的工作。工程师的价值不是"写代码更快”，而是"定义 AI 的边界"。
问题定义：WorkBuddy 越普及，越要问"还要工程师吗"
桌面 AI Agent 已经能让非技术人员用自然语言控制电脑：格式化 PPT、清洗 Excel、自动发邮件、抓取网页数据。腾讯 WorkBuddy 兼容 OpenClaw 生态，20+ 开箱即用的技能包，安装后直接说"帮我把这份报告转成 PPT"就能执行。
于是问题自然冒出来：如果 AI 能让非技术人员自动化办公任务，还要软件工程师吗？
直接回答：需要。但不是需要"写代码的人"，而是需要构建 Agent 能力、定义自动化边界、审核安全风险的人。这个转变不是预测，是正在发生的现实。
大模型出现前的任务分布
企业信息系统里的任务，按输入输出精度分两类：
| 类型 | 比例 | 典型场景 | 为什么是精确的 |
|---|---|---|---|
| 精确输入→精确输出 | 80-90% | 写代码、填表单、查数据库、调用 API、做 Excel | 系统只接受结构化输入，输出也是结构化 |
| 模糊输入→模糊输出 | 10-20% | 写文案、谈客户、做设计、创意工作 | 这些工作本来就不在信息系统里，由人直接处理 |
核心原因：传统软件是表单驱动的。用户必须精确输入（选三级菜单、填必填字段），系统才能处理。办公自动化也一样——VBA 脚本、RPA 工具都需要精确配置"点击哪个按钮、复制哪列数据"，非技术人员用不了。
大模型改变的是什么
不是任务比例变了，是入口变了
| 维度 | 大模型前 | 大模型后 |
|---|---|---|
| 输入方式 | 写 VBA 脚本 / 配置 RPA 流程 | 说"帮我把这份报告转成 PPT" |
| 理解方式 | 人必须精确描述每一步 | 大模型靠语义理解拆解任务 |
| 执行方式 | 脚本执行固定流程 | Agent 动态规划 + 工具调用 |
| 输出方式 | 固定格式 | 自然语言 + 结构化文件 |
关键洞察：任务总量没有变，变的只是"谁来理解用户意图"。
大模型把原来由工程师/技术助理处理的模糊任务（理解"把报告转成 PPT"到底意味着什么），桥接成了系统能执行的精确任务。原来这个桥接工作需要技术人员写脚本，现在 Agent 来做。
真正被放大的是"模糊输入→精确输出"
| 场景 | 模糊输入 | 精确输出 | 大模型前怎么做 |
|---|---|---|---|
| 桌面自动化 | “帮我把这份报告转成 PPT” | 解析 Word → 提取大纲 → 生成 PPT | 工程师写 VBA / Python 脚本 |
| 电商客服 | “我买的洗衣机坏了” | 创建退货单 + 预约取件 | 用户选菜单 → 填表单 |
| 代码生成 | “加个用户登录功能” | 完整的 auth.py + 测试 | 工程师写需求文档 → 写代码 |
| 数据分析 | “上个月销量怎么样” | SQL + 可视化图表 | 分析师写 SQL + 做报表 |
高价值场景 = 模糊输入 + 精确输出。大模型出现前，这个转换需要技术人员来做；现在 Agent 来做。
桌面自动化正是这个"模糊→精确"的典型场景。WorkBuddy（腾讯推出的桌面 Agent 平台，兼容 OpenClaw 生态）正是瞄准这个场景——20+ 开箱即用的技能包，安装后直接说"帮我把这份报告转成 PPT"就能执行。
但它有明确的能力边界：
| 能做的 | 不能做的 |
|---|---|
| 执行预设技能（PPT 转换、Excel 清洗、邮件发送） | 理解业务上下文和隐性需求 |
| 调用已有 API 和桌面应用 | 决定"这个任务该不该自动化" |
| 多步骤流程编排 | 定义"什么是正确行为" |
| 自然语言交互 | 做出安全/合规/架构层面的权衡 |
| 扩展 OpenClaw 生态技能 | 识别"这个自动化会不会泄露敏感数据" |
WorkBuddy 解决的是"怎么执行任务"的问题，不是"该执行什么任务"的问题。
工程师的新分工
既然 Agent 能执行任务但不知道"该不该执行、怎么执行才对"，工程师的角色从"脚本编写者"变成了"Agent 架构师"：
传统工程师：需求 → 设计 → 写代码 → 测试 → 上线 AI 桌面自动化时代的工程师： 需求理解 → 定义 Agent 能力边界 技能开发 → 编写 OpenClaw Skill / WorkBuddy 技能包 质量保证 → 安全审查 + 异常处理 + 降级策略 系统集成 → 权限管控 + 数据流设计 + 合规审计从"脚本编写者"到"Agent 架构师"
| 工作 | 之前 | 现在 |
|---|---|---|
| 写脚本 | 从零开始写 VBA / Python / RPA | 编写 OpenClaw Skill 包，定义工具描述 |
| 调试 | 读日志、设断点 | 追踪 Agent 多步执行的中间状态 |
| 权限设计 | 配置文件读写权限 | 定义 Agent 能操作哪些应用、能访问哪些数据 |
| 安全审查 | 代码审计 | Prompt Injection 检测、数据泄露防护、沙箱隔离 |
| 知识沉淀 | 写文档 | 写 Skill 描述、few-shot examples、工具 schema |
为什么工程师不可替代
1. 定义能力边界比执行任务更重要
WorkBuddy 能自动化办公任务，但不知道：
- “财务报告不能自动发送给外部，必须人工确认”
- “客户数据不能离开本地，Agent 只能在沙箱里跑”
- “这个自动化任务如果出错，回滚策略是什么”
工程师的价值 = 把业务规则转成 Agent 能理解的约束条件。
2. AI 会放大错误，不只是放大效率
Agent 执行的是"用户想要的"，不是"用户应该要的"：
# 用户说："帮我把所有客户数据导出"# Agent 执行：导出全部客户信息，包括手机号、身份证、地址# 问题：没有脱敏、没有权限检查、没有审计日志工程师要审核：数据权限、隐私合规、异常处理、可观测性。这正是 shop-agent 里"参数硬强制"和"降级矩阵"的思路——AI 不会主动做这些。
3. 系统集成是人的工作
WorkBuddy 擅长执行单个技能，不擅长：
- 多 Agent 协同（谁先谁后、出错怎么回退）
- 跨系统数据流（从 CRM 到 ERP 的数据映射）
- 故障隔离（一个 Agent 挂了不影响其他任务）
- 技术选型权衡（本地模型 vs 云端 API、延迟 vs 隐私）
shop-agent 的架构决策：LangGraph + 多执行器 + PostgreSQL + Redis，这些"为什么这么选"AI 给不了——它没有"业务未来会怎么变"的上下文。
4. 责任在人，不在 AI
任务出问题：
- WorkBuddy 可以说"用户让我这么做的"
- 工程师要说"我设计了这个自动化流程"
生产系统的责任链终点永远是人。
工程师不可替代的核心能力
| 能力 | 说明 | AI 能做到吗？ |
|---|---|---|
| 能力定义 | 决定 Agent 能做什么、不能做什么 | ❌ 需要业务理解 |
| 安全边界 | 数据权限、沙箱隔离、合规审计 | ❌ 需要全局视野 |
| 质量守门 | 识别 Agent 执行结果里的安全漏洞、数据泄露 | ⚠️ 能辅助，但最终责任在人 |
| 异常处理 | 设计 Agent 失败时的回滚和降级 | ❌ AI 只见过正常情况 |
| 系统集成 | 多 Agent 协同、跨系统数据流 | ❌ 需要架构设计能力 |
结论：工程师的新定位
| 时代 | 工程师的角色 |
|---|---|
| 桌面自动化前 | 脚本编写者（从需求到实现，主要工作量在编码） |
| 桌面自动化后 | Agent 架构师 + 安全守门员（定义能力边界 + 审核执行结果） |
未来工程师的价值不是"写脚本更快"，而是"让 Agent 在正确的边界内执行"。
这需要更强的业务理解、安全意识和架构能力，而不是更快的打字速度。WorkBuddy 消灭的是"重复性脚本工作"，创造的是"更高技能的 Agent 设计工作"——工程师从"脚本员"变成"AI 能力架构师"。
核心要点
- 大模型没有改变任务比例，只改变了任务入口：80-90% 的精确任务依然存在，变的是"模糊→精确"的桥接工作从人变成了 Agent。
- 工程师的价值从"写代码/脚本"转向"定义 Agent 的边界"：哪些任务该自动化、哪些数据该保护、系统失控时谁来负责。
- 定义能力边界比执行任务更重要：Agent 能自动化执行，但不知道"该不该自动化、执行错了怎么办"。
- AI 会放大错误，不只是放大效率：没有安全边界和数据权限控制的 Agent，会把错误规模化。
- 责任链终点永远是人：生产系统的最终责任不在 AI，而在设计这个自动化流程的工程师。