1. 先说结论Joule Studio 到底是干什么的这两年 SAP 圈子里只要提到 AIJoule 这个词基本绕不开。我在项目上被问得最多的一个问题就是“Joule Studio 能不能用来开发 skill是不是以后 ABAP 和 Fiori 都不用写了”先把话放在前面能但它的边界非常清晰。Joule Studio 开发的 skill是运行在 SAP Joule 这个企业级 AI 助手语境下的“技能”它解决的是“让业务用户用自然语言跟系统交互、让 AI 帮你完成特定业务任务”这一类问题。它不是拿来替代 ABAP、CAP、RAP、Fiori 这些传统开发技术的万能锤。你要是指望拿它去改写一个高并发的物料账过账程序或者实现一套复杂的 MRP 跑批逻辑那大概率会碰得头破血流。我做 SAP 技术顾问这些年最深的感受是每一种技术都有它出生的语境。Joule Studio 出生的语境是 SAP 想让你把“业务用户的使用体验”重新做一遍而不是把“底层的业务逻辑”重新写一遍。理解了这个基本面你才知道哪些 skill 适合用 Joule Studio 开发哪些东西压根就不该往这儿放。这篇文章不打算写成一个产品说明书式的空架子我尽量按我实际在项目里摸索出来的路径走先讲清楚 Joule skill 的核心机制和边界再拆解一个具体的业务案例从需求到发布、再到效果评估最后把踩过的坑和排查经验整理成清单。如果你是 SAP 顾问、BTP 开发者或者企业里负责数字化创新的业务分析师这篇内容应该能帮你省下不少试错时间。2. 为什么说 Joule skill 不是“万能锤”先理解它的技术边界2.1 Joule skill 到底包含哪些构成要素一个 Joule skill 的本质是把你的一段业务能力封装成“AI 可以理解和调用的服务”。这套封装在 Joule Studio 里由几个核心部件组成每个部件都有自己的职责技能描述Skill Description你用自然语言告诉 Joule“这个 skill 能干什么、什么时候应该被触发、需要哪些输入”。这一段文本至关重要因为 Joule 的意图识别引擎就是靠它来匹配用户请求的。工作流Workflow真正干活的步骤序列。你可以把多个 API 调用、条件分支、变量赋值串起来形成一条完整的业务处理链。函数Function可复用的逻辑片段类似于传统开发里的函数或方法。函数里可以写 JavaScript可以调用 BTP 上的 Destination也可以消费 SAP S/4HANA Cloud 的 API。企业知识库连接Knowledge Base让 Joule 能去检索企业内部的文档、标准操作流程或者历史案例分析用于回答开放式问题。触发条件和上下文Triggers Context定义什么场景下 Joule 会把用户的请求路由到这个 skill 上来。这看起来跟低代码平台很相似但它跟传统开发的差别在于交互模式。传统开发的交互模式是“用户点击一个按钮 → 触发一个事件 → 后端逻辑执行 → 返回结果”Joule skill 的交互模式是“用户用一句话描述诉求 → AI 理解意图 → 匹配并调用 skill → skill 执行 → AI 把结构化的结果翻译成自然语言反馈给用户”。这个差别直接决定了 skill 的适用场景它特别适合那些“用户不太清楚事务码或报表路径、但很清楚自己要什么结果”的场景。比如业务财务跑过来问“这个月 Q 库存的金额为什么比上个月涨了这么多”如果你让他自己去 SE16N 查表、再折腾几个报表对数据估计他得先骂十分钟但如果你有一个封装好的“库存差异分析 skill”他直接跟 Joule 说一句话就能拿到答案甚至 Joule 还能主动把差异的来源收货、发货、迁移、盘点调整拆给他看。2.2 传统 SAP 开发与 Joule skill 开发的正面差异拿 ABAP 开发和 Joule skill 开发做一次对比两者的分工其实一目了然对比维度传统 ABAP / RAP / Fiori 开发Joule Studio skill 开发核心目标实现业务逻辑、数据持久化、复杂事务处理让 AI 理解并执行特定业务任务优化人机交互用户入口事务码、Fiori 磁贴、报表选择屏幕自然语言对话技术栈ABAP、CDS、ODATA、UI5描述 工作流 函数JavaScript API适用场景高并发批处理、复杂校验、数据一致性要求高的场景知识解读、数据查询、系统操作引导、决策辅助不适合的场景大模型理解不了你那些隐藏的业务规则对事务一致性要求极高的核心过账逻辑对开发者的要求ABAP 功底、业务建模能力业务理解能力 API 设计思维 提示词意识所以每当有人问我“Joule Studio 能不能替换 ABAP”时我一般会反问他一句你家的数据一致性校验能在一次自然语言对话里完成吗多数场景是不能的。Joule skill 擅长的是“把复杂系统变简单”而不是“把简单系统变复杂”。2.3 核心选型判断什么需求才值得用 Joule Studio 开发 skill我在项目里的判断标准基本可以归纳成三条缺一不可需求属于“理解型”或“查询型”用户要的是“得到信息、找到原因、理解状态”而不是“创建一笔订单、触发一次过账、修改一条主数据”。输入输出是结构化或半结构化数据skill 的输入通常是几个自然语言参数比如公司代码、物料号、期间输出通常是结构化数据经过 AI 加工后的文本。如果输入输出高度非结构化比如让 AI 读一份 PDF 合同再填多个字段skill 能实现但复杂度会直线上升调试成本很高。背后有可复用的 API 或 OData 服务Joule skill 自己不做数据持久化它是个“调用者”。如果底层连个标准接口都没有你还得先去 BTP 或 S/4 侧造一个那工作量就不是单纯“写个 skill”能覆盖的了。用一个接地气的比方Joule skill 像是一个训练有素的“前台接待”他能听懂你说的话知道你的需求该找哪个部门办也能把部门的答复整理成你能听懂的汇报但他不会去财务部替你填凭证更不会去仓库替你搬货。想清楚这个定位后面所有决策就顺了。3. 实战案例拆解从 FAGLL03 收付款对方名称需求说起3.1 需求背景与业务痛点的还原这次的需求跟我们热搜词里那条很贴近“SAP 在标准事务码 FAGLL03 报表中展示收付款对方名称”。FAGLL03 是 SAP 里查总账行项目最常用的标准报表财务用户天天都用它对账。但标准输出里通常会显示“收付对方代码”比如供应商号、客户号而财务的同事往往希望直接看到对方名称比如“上海某供应链管理有限公司”而不是一串 6 位数字。放在以前要实现这个需求常规路径是复制标准报表做 Z 版本或者在 FAGLL03 的增强点里写代码去取数、拼接名称。这活儿说大不大说小也不小一旦你复制了标准报表后续标准升级就得做回归测试长期维护成本很高。而且需求在财务内部往往还会变今天想看收付款对方名称明天想看“是否属于关联方”后天又希望按对方名称实现快速筛选。我当时拿到的初始诉求是“能不能做一个工具让财务用户直接输入‘查某个供应商的所有行项目’系统直接把对方名称也一并展示出来”。如果走传统报表增强也能做但周期通常是按周计而用 Joule skill 来包装核心洞察是FAGLL03 只是一个入口用户真正想要的不是“报表”而是“答案”——这个月我跟哪些供应商有往来、金额多少、有没有异常。3.2 为什么这个场景适合用 Joule skill 而不是改报表我判断这个需求适合做 skill有四个理由财务用户会问的问题通常很口语化比如“帮我查一下 2024 年 11 月供应商 31000042 的发生额”这种问题放在传统报表里要先想事务码、再在选择屏幕填一堆条件对不熟悉系统的人是种负担。数据的呈现方式需要“二次解读”。FAGLL03 能给出行项目但对方名称、关联关系、异常波动这些信息要靠人去二次查询。Joule skill 可以把多段查询整合成一次查询再让大模型整理成一段自然语言结论用户不用再脑补。标准功能不该被随意复制。能不动标准程序就尽量不动这是 SAP 实施的一个铁律。用 skill 做“包装层”底层还是标准报表的数据源风险可控。需求会持续迭代。财务用户对“自然语言问数据”这件事很容易上瘾有了第一个 skill马上会提第二个、第三个。Joule Studio 的迭代速度快改描述、加参数、换工作流比改 ABAP 程序轻量太多。3.3 完整的 skill 设计思路与处理流程在 Joule Studio 里设计这个 skill我的处理路径大致是下面的样子第一步定义技能边界。这个 skill 只管“总账行项目的查询与解读”不碰凭证过账也不碰主数据维护。我在描述里写清楚“当用户希望查询供应商或客户相关的科目行项目、并希望了解对方名称及往来金额时使用本技能”避免跟其他财务类 skill 产生路由冲突。第二步规划输入参数。我设计的输入参数包括companyCode公司代码可选不填则默认当前用户权限范围内的公司代码accountType科目类型比如供应商K或客户DbusinessPartner业务伙伴编号fiscalPeriod会计期间支持“202401”这种格式也支持“上一月”“本季度”这类相对表达由 AI 自动换算displayNameFlag是否显示对方名称默认 true第三步设计函数逻辑。这是整个 skill 的最核心部分。我需要调用底层接口去查 FAGLL03 的行项目数据。标准做法是封装一个 API 到 BTP Destination让 skill 里的函数通过 HTTPS 去调用。函数内部处理三件事把自然语言里解析出来的参数映射到接口字段上调用接口获取行项目集合同时按业务伙伴分组把每组的对方名称、发生金额合计、币种等数据整理成结构化 JSON把完整的数据集返回给模型层做生成。这里有个关键设计不要让大模型直接去算金额合计。大模型在算术上不是百分百可靠尤其是几十行数据加总这种事交给函数用 JavaScript 去算算完把确定性的结果作为上下文给大模型它只负责组织语言和提炼结论。这样即使大模型对数字的表述有个别出入底层的算术结果也是准的。第四步设置企业知识库检索。我在 skill 里挂了一个知识库里面放了财务科目表的说明文档、关联方的定义规则、以及历史对账异常案例。当用户问“为什么这笔金额波动这么大”模型可以从知识库里检索到过去类似的处理经验并给出参考建议而不只是冷冰冰地抛出行项目明细。第五步部署和测试。Joule Studio 支持直接把 skill 发布到测试环境的一个特定渠道比如内部测试群或指定用户组。我习惯先在隔离环境里用一批真实业务数据做验证重点测试几类典型问法正常查询、带条件组合的查询、模糊问法比如用户只说了供应商简称、以及完全无关的请求。确认意图路由稳定后再放开到更广的用户范围。3.4 关键效果与经验收获这个 skill 上线后财务用户的实际体验变化非常直观。以前查一个供应商的行项目至少要点四五次屏幕、还要手工记一下对方名称现在只要在 Joule 对话栏里输入“查一下 2024 年 11 月供应商 31000042 的全部行项目并告诉我往来金额”几秒钟内就能得到一段相对完整的文字结论下方还可以附带可下钻的明细列表链接。但这里我也必须说一个反常识的发现用户对“文字结论”的关注度其实没有对“准确数字和可追溯性”的关注度高。所以我在界面上保留了“原始数据列表”的展示区域让用户可以点开查看每一笔行项目的明细而不是只信 AI 说的话。这一点非常重要——企业级 AI 工具的价值不只是“生成内容”更重要的是“生成的内容能被验证”。如果你只给一个 AI 总结的句子而不给数据出处财务用户在使用时心里永远不踏实。4. 实操过程复盘在 Joule Studio 里搭建一个可用 skill 的具体步骤4.1 前期准备BTP 子账户、Destination 与 API 就绪做 Joule skill不是打开 Studio 就能直接开写。你底层得有资产。我的标准做法是先确认三样东西一个 BTP 子账户用于部署和运行环境、一套可以访问的业务 API可以是 S/4HANA Cloud 的标准 OData 服务也可以是自定义的 CAP 服务、以及一个通往 API 的 Destination。这里想单独讲一下 Destination 配置。很多人第一次做 skill 失败问题不是出在 skill 本身而是出在 API 连接上。你要在 BTP Cockpit 里配置一个指向后端系统的 DestinationURL 填 OData 服务的根地址认证方式通常选OAuth2ClientCredentials或者BasicAuthentication具体取决于你的后端设置。配置完成之后一定要先做一次“Test Connection”确保外网能通、认证能过、HTTP 状态码是 200然后再回 Joule Studio 里创建函数去调用这个 Destination。注意如果你用的是 S/4HANA Cloud还要确认服务的通信场景Communication Scenario和通信安排Communication Arrangement已经配好。很多人忽略了这一步导致接口报 401。这部分配置在业务侧看起来是“管理员的事”但作为 skill 开发者你最好也清楚否则排错时非常被动。4.2 Jupiter Studio 界面操作创建项目、技能、意图与上下文不同版本的 Joule Studio 界面细节可能有差异但核心操作脉络是稳定的创建项目Project输入项目名称和描述选择对应的业务领域比如 Finance。建议命名时把“渠道”也带上例如“Finance_AccountName_Inquiry”方便后续跟其他项目区分。创建技能Skill在项目下新建一个 skill然后填写“名称”和“描述”。描述这个字段非常关键别小看它。你要把它当作一段“路由说明”来写什么情况下触发、触发时要收集哪些信息、收集不到时应该反问哪个问题。描述写得越具体意图匹配的准确率越高。配置意图Intents和实体Entities意图是“用户想干什么”实体是“用户提到的具体业务对象”。比如意图是“查询往来行项目”实体包括“供应商编号”“客户编号”“期间”“公司代码”。Studio 里通常会要求你给每个意图写几个示例问法比如“查一下供应商 31000042 上个月的全部行项目”“A 客户这个季度的发生额是多少”。示例越贴近真实用户的表达习惯越好。搭建工作流Workflow把“接收输入 → 调用函数 → 整理输出”这个链条搭出来。这里要注意分支逻辑的设计如果用户没提供期间工作流应该先让模型反问用户补全信息不要直接带着空参数去调用接口。引用知识库如果这个 skill 需要结合业务文档回答开放式问题可以把对应的知识库挂载进来并设置检索范围。测试与发布Studio 里一般都有调试面板你可以输入不同类型的用户问法看意图识别是否正确、工作流是否把参数传到位、函数返回值是否符合预期。测试通过后再发布到生产环境或指定渠道。4.3 函数开发的经验JavaScript 不是万能但也不能不会Joule Studio 的函数支持 JavaScript 语法这让熟悉前端的同事上手很快。但有个容易踩的坑函数里能调用的 API 是受沙箱限制的不是所有 Node.js 的第三方包都能用。我建议尽量只依赖标准库和平台提供的 API 客户端避免把 lodash 这类重型依赖塞进去。另外函数的执行时间通常有超时限制像“一次性从 FAGLL03 拉取十年行项目数据再汇总”这种操作设计上就应该拆成多次分页查询或者交给后端服务去完成。函数内部我最常写的一段逻辑是“参数级联”和“结果归一化”。什么是参数级联比如用户说“查一下今年以来的数据”模型翻译出的期间范围可能是一个列表而不是单个值函数要把这个列表展开成可查询的条件。结果归一化则是把接口返回的复杂嵌套结构拍平统一成[{ itemNumber, postingDate, amount, counterpartyName }]这种扁平结构再返回给模型层降低模型理解数据的难度。如果你不会写 JavaScriptJoule Studio 也支持纯配置式的工作流搭建。但说实话要做真正好用的企业级 skill一点脚本能力都没有会比较辛苦——函数的灵活性决定了 skill 的深度。算是我个人的一条建议做 Joule skill 的顾问懂点 ABAP 更好懂点 JavaScript 是基本盘懂点 API 设计思维则是加分项。4.4 发布渠道与权限控制Skill 开发完不是直接对全世界开放的。Joule Studio 里通常可以选择发布到干净的环境或者指定的应用渠道也可以限制只有特定用户组可用。权限控制在企业场景中是不可省略的一环财务数据本身就是敏感数据不是每个人都能看所有供应商的往来明细。Skill 需要遵循 S/4HANA 侧的数据权限框架用户在对话里拿到什么数据、不能拿到什么数据应该跟他用事务码直接查询时的权限一致。这一点看起来是“权限管理”的范畴实际上直接决定了一个 AI 助手在企业里能不能真正落地。如果用户通过 Joule 能查到他在 FAGLL03 里查不到的数据那问题就大了。所以每次我做完 skill都会让一个低权限测试账号跑一遍核心场景验证“权限收敛”是否生效。5. 常见问题与排查技巧实录5.1 技能无法触发多半是描述和意图写得不到位这是我在 Joule Studio 碰到的最高频问题用户在对话里问了一句话Joule 就是死活不触发对应的 skill。排查思路一般是按顺序来先检查技能描述。描述太泛会跟其他 skill 抢路由描述太窄又会导致该触发时触发不了。理想的状态是“描述里明确写出触发条件和不触发条件”。比如我们这个财务场景我会写“当用户提到供应商/客户行项目查询、收付对方名称、往来金额时使用本技能当用户要求创建凭证或修改主数据时请不要使用本技能”。检查示例问法覆盖度。示例问法不能只写标准问法要多写一些口语化的变体。财务用户习惯说“给我看看 31000042 的对账单”而不是严格说“查询供应商 31000042 的行项目”。所以示例问法这一块最好直接找真实业务用户的聊天记录来整理而不是开发人员自己脑补。检查上下文优先级。Joule 如果同时挂了多个 skill路由是有优先级或权重的。确认目标 skill 没有被其他更泛化的技能拦截。最后检查发布状态。听起来很蠢但我真遇到过团队同事调了半天最后一查发现测试版本根本没发布到当前测试渠道的情况。5.2 检索到的数据不对先看函数返回值再看模型理解用户反馈“Joule 给的数字不对”这种问题在我开发初期出现过好几次。我的排查套路是分两步先确认函数返回到模型层的数据是什么。打开调试面板查看函数执行的日志看看调用接口时传入的参数对不对、返回值是不是符合预期。如果函数返回的数据本身是对的那问题大概率出在模型组织语言的时候对数据的理解有误比如把“借方金额”讲成了“贷方金额”。再确认模型是否有足够的字段信息来理解数据。我遇到过函数返回 JSON 字段名只有amount模型根本分不清这个字段到底是借方还是贷方。后来在函数里把字段命名改成了debitAmount和creditAmount模型的理解准确率瞬间提升。这个小改动给我一个很深印象给模型的字段语义越明确模型的输出越准确。如果函数返回值本身有问题那就继续往底层接口查HTTP 状态码是不是 200、有无数据权限拦截、分页参数是否丢失、期间格式是否匹配等。这类问题的定位逻辑跟传统接口联调一模一样。5.3 响应太慢问题往往出在“不必要的数据量”上Joule skill 的响应时长是整个体验的关键指标之一。用户问一句话如果转圈超过 15 秒就开始焦躁了。我在实际调优中总结出几个提速策略缩小数据范围默认只取当前会计期间或最近三个月的数据而不是拉全量再让模型过滤。延迟知识库检索不是所有问题都需要企业知识库。如果用户问的是“查一下某供应商的发展余额”不需要检索知识库可以在技能流程里把知识库检索设为条件触发。减少模型二次生成的复杂度如果用户只是要数据列表就不要诱导模型生成大段分析文字如果想让它分析波动原因那就另设计一个“分析”入口让用户主动触发深度模式。这既省 token也省时间。我实际测下来从“拉全量数据 强制知识库检索 长文本生成”优化到“限定数据范围 条件检索 简洁输出”之后响应时长大概能缩短 40% 到 50%对业务用户来说体感差距非常明显。5.4 快速问题速查表实操中容易忽略的细节问题现象可能原因处理建议技能调用不触发技能描述太泛或太窄、示例问法不足重写描述注明触发条件和不触发条件补充真实用户问法接口返回 401Destination 认证配置错误或通信安排未配置检查 BTP Destination 认证类型检查 S/4 侧通信场景数据权限失控没有校验用户权限上下文在函数里调用权限校验接口确保与事务码查询权限一致金额汇总不一致让模型参与算数而不是用函数计算所有的数值计算一律在函数里完成模型只做语言表达响应超时数据量过大、知识库检索拖慢设置合理的数据时间范围知识库检索改为条件触发模型给出冗长回答没有限定输出格式要求在技能流程的“输出提示”里明确要求简洁、结构化、只列重点5.5 一些从实战里熬出来的避坑心得除了上面这些可以直接照抄的排查步骤我还有几个比较冷门的“土办法”虽然看起来不那么 AI-native但确实很管用第一一定要保留“人可以直接看的数据详单”。即使 Joule 给出的自然语言结论再漂亮也要把背后的结构化明细附在结果里。不要以为用户喜欢“只看结论”企业级的用户恰恰是需要“结论 证据”的。没有证据的 AI 回答在财务这种责任重的部门里很容易被挑战。第二将 skill 的外部表现设计得“像一个人”而不是“像一个系统”。比如当用户的请求信息不完整时好的 skill 会自然反问“请问您需要查看哪个供应商是 2024 年 11 月还是全年”而不是生硬地回答“缺少参数”。这种会话体验的提升只靠流程编排是不够的你必须在技能描述或提示词里把“追问策略”写清楚让模型知道“遇到未知参数时的行为标准”。第三上线前找真实用户做黑盒测试。我习惯把开发好的 skill 交给一个完全不懂技术的业务用户去试用让他在没有任何操作手册的情况下跟 Joule 对话。他问出来的问题通常跟我准备的测试用例差别很大。这些“意外问法”是最宝贵的调优素材——你要把高频的意外问法逐一补充进示例问法里让意图识别效果随着使用不断变好。6. 它的边界在哪哪些场景千万别用 Joule Studio聊完能做什么还得把丑话说清楚。根据我这段时间的实际体验下面几类场景我强烈不建议用 Joule Studio 硬扛第一类核心事务类操作。比如凭证过账、物料移转、采购订单审批等。这些操作的共同特征是一旦出错可能产生连锁的财务或业务影响而且需要强一致性和完整的审计轨迹。Joule skill 本身的定位是“辅助交互”不是“事务处理引擎”。你可以用 skill 引导用户去完成审批、把用户带到正确的操作界面但不要让 AI 直接代劳执行“事后不可回退”的操作。企业级系统里操作者是谁、什么时候操作的、操作了什么内容每一份审计要求都有它的道理。别为了一点便利牺牲整个合规性。第二类高复杂度、需要事务性一致性的批处理逻辑。典型如月末物料账的结算、折旧范围并行处理就像热词里提到的“多账套多折旧范围”、平行分类账的月末结转。这些逻辑对执行顺序、数据一致性、锁管理有极高要求。你当然可以在 Joule 里做一个“查询当前结算状态”的辅助 skill但把整套结算逻辑搬进 Joule 的函数和工作流里纯属自找麻烦。第三类纯粹的“提示词美化工程”。如果某个需求本质上只是“给用户一段写得更漂亮的文案”那就别硬把它包装成 skill。Joule skill 的价值体现在“能调 API、能查数据、能结合上下文做事”而不是给用户创作一段抑扬顿挫的市场宣传语。非结构化的文本生成需求直接用 Joule 的原生对话能力就好没必要单独开发 skill。第四类需要依赖大量前端交互定制的场景。Joule 的对话界面有它自己的框架你不能像 Fiori 那样自定义像素级的布局。如果需求里充满了复杂的表格操作、拖拽、批量选择、个性化筛选器那对话式 UI 本来就不是最佳载体。正确姿势是两个系统配合Fiori 负责复杂操作Joule skill 负责引导用户进入正确的 Fiori 界面、或者把 Fiori 里的关键数据用自然语言解读出来。打个比方来收束这一节Joule skill 是助手不是发动机。发动机必须稳定可靠、输出强劲助手不必替代发动机助手要做的是让司机不用再打开引擎盖检查每一个零件就能安心上路。你见过让助手去拧发动机螺丝的吗那是维修工干的事。维修工好比传统 ABAP 开发——他才是真正深入系统底层、保住系统底线的角色。两者各干各的活企业才能真正跑得又快又稳。7. 个人经验总结给跃跃欲试的同行们的一些建议最后说说我的真实体会。Joule Studio 对 SAP 生态的冲击是真实的但这种冲击不是“取代”而是“把开发的重心从用户界面转向用户意图”。以前我们花大量时间写选择屏幕、调表格布局、配按钮事件现在这些依然要做但多了一个全新的层次理解用户为什么问这个问题、他想得到什么。这种能力重塑对 SAP 从业者来说既是挑战也是机会。我个人的建议是如果你时间有限先别急着把 ABAP 或 Fiori 丢掉先把下面三件事做起来一是梳理出你当前业务中最高的 3 个“查询解读型”需求评估它们是否适合包成 skill二是去 BTP 上把 Destination 和数据权限的链路彻底吃透——这是 skill 能否真正落地的地基三是养成一种习惯每次写完 skill都找真实用户做黑盒测试把他们的自然表达沉淀成训练素材。从我试过的项目来看Joule skill 最打动人的时刻不是它完成了某个炫酷的技术演示而是业务用户在试用了之后露出“这东西真的能用”的表情。那一刻你会觉得之前所有的折腾都值了。行业里的技术名词一直在变但真正做事的方法论从来没有变过理解业务、选对工具、守住边界、持续打磨。Joule Studio 也是如此它是一款值得认真对待的工具但前提是你得知道它的边界在哪里它最适合哪些场景它服务于怎样的工作流程。想清楚了这些你踩的坑会少很多。