AI工作流实战：WorkBuddy技能封装与本地化搭建指南

如果你最近在关注 AI 工作流，可能会发现一个现象：Coze、Dify、n8n 这类工具已经把“搭建工作流”讲得很透了，教程遍地都是，但真正落到自己项目里的却不多。原因倒不难理解——很多演示停留在“拖几个节点、点一下运行、截图发朋友圈”的层面，一旦回到真实业务，涉及技能管理、工具调用、数据流转、异常分支、权限控制时，问题立刻暴露出来。最近 WorkBuddy 这个名字频繁出现在开发者社区里，尤其是它与 CodeBuddy 的搭配使用、轻量级搭建工作台的思路，让不少人重新开始思考：AI 工作流到底应该怎么学、怎么用，才能沉淀成团队真正可复用的资产？

先说我的判断：WorkBuddy 的核心差异，不在于“又多了一个可视化画布”，而在于它把技能（Skill）、工具调用、工作台的组织方式，拉回到了开发者熟悉的本地方向。相比大而全的云端工作流平台，它更强调轻量、可控、贴近代码工程。这意味着，如果你已经被复杂编排和平台锁定折磨过，WorkBuddy 提供的是另一种取舍：把常用流程固化成技能，用本地工具链完成闭环。

这篇文章会围绕 WorkBuddy 实战展开，从工具定位、概念原理，到安装配置、核心功能拆解、简历筛选工作流完整示例、自动触发方式、常见问题排查，再到工程落地建议。无论你是零基础想入门的开发者，还是已经在用其他工作流平台、想对比迁移成本的工程师，这篇文章都能给你一份可照做的路径。文章最后还会给出 B 站付费课程的拆解逻辑，帮你省钱省时间。

1. WorkBuddy 值得学吗：先看它解决了什么问题

在讨论 WorkBuddy 之前，先回答一个问题：为什么我们需要一个专门的工作流工具？

过去，我们写自动化脚本，通常是用 Python、Shell 或 Java 直接写逻辑：读取文件、调用 API、处理数据、输出结果。代码确实是灵活的，但它有两个天然问题。第一，每次新任务都要重新写一遍流程，重复劳动多；第二，代码逻辑只有程序员能看懂，业务同学没法参与修改。后来出现了低代码平台，把流程变成节点拖拽，但新的问题又来了：平台上能用的模型有限，工具插件受平台限制，数据要传到云端，隐私和成本都让人头疼。

WorkBuddy 想解决的，正是这组矛盾。它提供一种介于“纯编码”和“纯拖拽”之间的工作流搭建方式，既保留了可视化的编排体验，又能让你在本地管理工具、模型和技能。从公开资料和社区讨论来看，它的定位是轻量级工作流工具，适合个人开发者、小团队以及在已有代码工程中嵌入 AI 流程的进阶用户。

更关键的，是它与 CodeBuddy 的分工。CodeBuddy 偏向代码生成与开发辅助，WorkBuddy 偏向工作流编排与任务自动化。二者结合后，你可以让 CodeBuddy 写代码模块，再把这些模块作为工具挂载到 WorkBuddy 的工作流里，形成“代码即工具”的闭环。这个思路，比单纯在云端平台里点节点要更适合真实工程项目。

回到很多人的疑问：我已经会 Coze 或 Dify 了，还有必要学 WorkBuddy 吗？我的建议是，工具本身不是重点，重点是理解工作流的通用思维。当你学会把任务拆成“触发、处理、工具调用、输出”四段以后，切到任何工具都只是换一套配置语法。WorkBuddy 的价值，恰恰在于它足够轻、足够贴近工程，能让你更容易把这种思维带到代码项目里，而不是被平台绑住。

2. WorkBuddy 是什么：轻量级 AI 工作流工具的定位

简单来说，WorkBuddy 是一个面向 AI 任务编排与自动化的工具，重点解决“把多个 AI 调用步骤组织成一个可复用流程”的问题。它的核心设计目标有两个：轻量化和可控制。

所谓轻量化，是指它不要求你部署一套庞大的服务端架构，而是可以在个人电脑上直接运行，也可以在项目目录中作为工程的一部分被引入。这和小团队用 n8n 自建流程、或者用 Dify 搭建应用是不同路线：n8n 偏重系统集成，Dify 偏重 RAG 应用和模型应用管理，WorkBuddy 则更侧重技能（Skill）与工作台的轻量组合。

为了帮你快速定位，我整理了一个对比表格：

从这张表能看出，WorkBuddy 和 Coze 不是一个维度的产品。Coze 的优势是有大量现成插件和社区工作流，比如“毛坯房拍照生成效果图”这类单场景 Demo 做得非常惊艳；但如果你想把这些流程接进自己的本地系统、用私有数据做处理，云端平台往往很难完全满足。WorkBuddy 的思路是从本地工具链出发，把 AI 能力嵌进你已有的工程流程里。

还有一个容易混淆的点：工作流这个词，在不同领域含义不同。Nginx 里的 location 工作流机制，指的是请求匹配规则的处理顺序；ComfyUI 里的工作流，是指图像生成节点图的保存与复用；而 WorkBuddy 所说的工作流，是指 AI 任务的处理逻辑，包括输入、模型调用、工具执行、条件分支和输出。理解这层区别，能避免你在搜索资料时被无关内容带偏。

所以，更稳妥的判断是：WorkBuddy 适合那些已经有一定编程基础，不希望被云端平台锁死，想要把 AI 流程像代码一样管理起来的开发者。它的学习曲线比 Coze 陡，但比从零手写一套编排框架要平缓得多。

3. 核心概念拆解：工作流、技能（Skill）与工具调用

要真正用好 WorkBuddy，有三个概念必须理解清楚：工作流（Workflow）、技能（Skill）、工具（Tool）。很多教程把这三个词混着用，导致新手一上来就糊里糊涂。

工作流是一条完整的处理链路。它包含一个触发条件、若干处理节点和一个输出结果。比如简历筛选工作流，触发条件是“输入一份简历文件”，处理节点包括“解析简历内容”“抽取关键字段”“匹配 JD 关键词”“生成评估结论”，输出结果是“筛选结果和推荐理由”。工作流的特点是：同样的输入，走同样的链路，得到稳定的输出。

技能（Skill）是工作流的一次更高层抽象。假设你已经在 WorkBuddy 里搭建了“简历筛选”工作流，并且调参调得很满意。如果下次还想做“论文摘要”或“周报生成”，是不是每次都要重搭一遍？技能的价值就在这里：它把工作流封装成一个可复用的能力单元，你可以用一句话触发这个能力，而不需要重新拖节点。社区热词里频繁出现“workbuddy skill”，说明大家已经意识到，技能沉淀才是工作流工具长期价值所在。

工具（Tool）则是执行具体动作的接口，包括读文件、写表格、调第三方 API、执行本地命令等等。工具是工作流的“手脚”，模型是“大脑”，而工作流是把它们串起来的“神经系统”。这里真正容易踩坑的地方是：很多新手以为把工具拖进画布就能用，却忽略了每个工具的入参、出参和权限配置。比如读文件工具，你需要指定文件路径、编码格式；调 API 工具，你需要管理密钥和超时时间。任何一个环节配置不对，整个工作流都会中断。

再往下拆，工作流可以分成三类节点：普通处理节点、条件分支节点和循环节点。普通节点是顺序执行，条件分支让流程按判断结果走不同路径，循环节点则用来处理批量数据。初学者最好先用普通节点跑通一个最小流程，再逐步加入条件分支。不要一上来就设计几十个节点的巨型流程图，那只会让排错变得非常痛苦。

理解了这三层抽象，你就能明白为什么轻量级工作流工具会流行起来。它本质上在做一件事：把频繁使用的 AI 处理逻辑，从“临时脚本”升级为“标准化资产”。脚本是一次性的，资产是可复用的。WorkBuddy 的意义在于降低了这层升级的技术门槛。

4. 环境准备与安装：Windows、Linux 与缓存目录

4.1 安装包获取与环境判断

WorkBuddy 的安装遵循“下载-解压-配置-运行”的标准流程。具体安装包从官方发布渠道获取即可，这里不写死版本号，因为工具迭代很快，版本细节以官方文档为准。本文演示的是通用思路，在任何版本上都适用。

安装之前，先确认你的操作系统环境：

• Windows 10/11，建议使用 PowerShell 管理员模式执行命令。
• Linux 发行版，建议 Ubuntu 20.04+ 或 Debian 11+。
• macOS，需要注意系统版本和芯片架构，Intel 和 Apple Silicon 的安装包可能不同。

4.2 Linux / Ubuntu 安装示例

下面以 Linux 环境为例，演示解压安装和 PATH 配置：

# 1. 创建目录 sudo mkdir -p /opt/workbuddy # 2. 解压安装包到目录（实际包名以下载文件为准） sudo tar -xzf workbuddy-*.tar.gz -C /opt/workbuddy # 3. 建立软链接，让 workbuddy 命令全局可用 sudo ln -s /opt/workbuddy/bin/workbuddy /usr/local/bin/workbuddy # 4. 验证安装 workbuddy --version

如果workbuddy --version能正常输出版本信息，说明安装成功。如果提示找不到命令，优先检查软链接路径是否正确，以及 bin 目录下是否存在同名可执行文件。

Windows 用户则简单很多，一般来说，解压安装包后进入解压目录，在 bin 目录下找到workbuddy.exe，然后在系统环境变量 Path 中加入该目录即可。添加完环境变量后，需要重新打开命令行窗口才生效。

4.3 缓存目录的配置与迁移

使用过程中，模型缓存、临时文件和工作流快照会占据磁盘空间。尤其是频繁调试工作流时，缓存容量增长很快。社区里关于“workbuddy缓存目录怎么更改”的讨论热度很高，正好说明这是刚需问题。

更稳妥的做法是，在安装完成后立即检查缓存目录位置，并迁移到空间充足的磁盘。下面是一份配置文件示例：

# 配置文件：workbuddy config 中的缓存设置 # 将默认缓存迁移到 D 盘（Windows 示例） cache.dir=D:\\WorkBuddyCache # Linux/macOS 示例，推荐放在独立数据盘 # cache.dir=/data/workbuddy/cache # 日志保留天数 log.retention.days=7

修改配置后，需要重启 WorkBuddy 或重新加载配置。这里有一个重要提醒：迁移缓存目录前，备份好原有缓存目录内容，再修改配置，否则已保存的工作流快照可能丢失。改完后运行一个简单的测试任务，确认新缓存目录下有文件写入，才算迁移成功。

5. 核心功能拆解：工作台、技能管理与项目搬迁

5.1 搭建你的第一个工作台

WorkBuddy 里的工作台，可以理解为一个项目空间。每个工作台包含独立的工作流、技能和工具配置。这种设计类似于 IDE 里的“工作区”，好处是不同项目之间互不干扰，你可以为简历筛选项目单独建一个工作台，为内容创作项目建另一个工作台。

搭建工作台时，最重要的是提前规划好目录结构。推荐按“项目-场景-版本”三层组织：

workbuddy-project/ ├── workflows/ # 工作流定义文件 │ ├── resume-filter/ │ │ ├── v1/ # 第一版，可追溯 │ │ └── v2/ # 优化版 ├── skills/ # 技能配置 ├── tools/ # 工具接入配置 ├── data/ # 测试数据，不入版本库 └── logs/ # 运行日志

这套结构的核心思想，是把工作流当成代码对待。版本目录确保你随时可以回滚到上一个可用版本，data 目录不入版本库是为了避免敏感数据泄露。很多初学者把所有文件堆在一个目录里，结果一个月后再看，自己都分不清哪个工作流是哪个项目的。

5.2 Skill 技能：把流程固化为能力

技能是 WorkBuddy 最有价值的功能之一。简单理解，技能 = 工作流 + 触发条件 + 参数模板。当你已经调通一个工作流后，可以把它保存为技能，之后通过自然语言指令或关键词直接触发，而不用打开画布重新跑流程。

Skill 的设计背后有一个很重要的思想：AI 工作流最终要面向业务使用。业务同事不知道什么叫节点，什么叫入参出参，但他们知道“筛选一下这份简历”。技能把复杂的内部流程收敛成一个简单入口，这才让工作流具备了团队复用的可能性。

在配置技能时，建议给每个技能写清楚三件事：输入参数描述、适用场景说明、输出格式约定。输入参数描述决定了触发时的参数映射是否准确；适用场景说明能防止别人在错误的场景下调用；输出格式约定则方便下游程序自动解析结果。

5.3 工具接入与权限边界

工具接入是 WorkBuddy 实操中最容易出现问题的部分。常见的工具类型包括：文件读写、外部 API 请求、数据库查询、命令行执行。推荐先用官方内置工具跑通流程，再接入自定义工具。

自定义工具的关键配置包括：工具名称、请求地址、认证方式、入参映射和超时时间。这里必须强调安全边界：涉及密钥和 Token 时，不要让它们硬编码在工作流 JSON 中。要从环境变量或密钥管理服务读取。涉及生产环境数据时，必须先在小范围测试环境验证，遵循最小权限原则——工具只需要具备完成当前任务所需的最小权限，不要为了省事把管理员密钥直接填进去。

5.4 项目搬迁与跨环境迁移

社区热搜里有一个“workbuddy 搬迁项目 win”，说明很多用户都在研究如何把项目从一台机器迁到另一台机器。跨环境迁移的核心，不是拷贝程序安装包，而是要导出工作流定义、技能配置、工具配置和关联文件，然后在目标环境重新导入。

更稳妥的搬迁路径是：先导出 JSON 配置，在新环境创建空白工作台，再导入配置，接着逐个验证工具连接，最后跑一遍最小回归用例。数据库连接、API 地址、文件路径这类带有环境属性的配置，在搬迁后几乎一定需要修改，不要当做可以直接复用。

6. 实战示例：从零搭建“简历筛选工作流”

6.1 场景设定

简历筛选是社区热搜里出现频率很高的场景，也是工作流工具的经典教学案例。假设你需要从一批简历中筛选出符合“Java 后端 3 年以上经验”的人，并输出结构化评估表。手工做这件事，打开每份 PDF 阅读、对照 JD 判断、写邮件回复，一个人一天最多处理几十份。用 WorkBuddy 搭建工作流后，批量处理几百份是常规能力。

6.2 工作流设计

简历筛选工作流按以下链路设计：

1. 输入：读取简历文件目录。
2. 解析：提取简历中的文本内容。
3. 抽取：用模型抽取候选人的关键信息。
4. 匹配：与 JD 关键词做条件判断。
5. 输出：生成筛选结果表。

6.3 工作流定义示例

下面是一份简化版的工作流配置文件，字段名以你的 WorkBuddy 版本为准，重点是理解结构：

{ "workflowName": "resume-filter", "version": "v1", "trigger": { "type": "manual", "inputSource": "data/resumes" }, "nodes": [ { "id": "1", "type": "file-reader", "config": { "path": "data/resumes", "extensions": ["pdf", "docx"] } }, { "id": "2", "type": "llm-extract", "model": "default-llm", "prompt": "从简历文本中抽取：姓名、工作年限、技术栈、学历、最近岗位", "outputFields": ["name", "years", "skills", "education", "lastTitle"] }, { "id": "3", "type": "condition-match", "config": { "rules": [ { "field": "years", "operator": "gte", "value": 3 }, { "field": "skills", "operator": "contains", "value": "Java" } ] } }, { "id": "4", "type": "output-writer", "config": { "format": "csv", "path": "output/resume-result.csv" } } ], "edges": [ { "from": "1", "to": "2" }, { "from": "2", "to": "3" }, { "from": "3", "to": "4" } ] }

这份配置文件分为三部分：工作流元信息、节点定义和连线关系。节点 id 在 edges 中用于确定执行顺序。如果你的版本支持可视化编辑，通常会自动生成类似结构，不需要手写 JSON；这里展示 JSON 是为了让你理解工作流的本质其实是一份可读的数据结构。

6.4 关键逻辑解释

真正决定筛选质量的是 node 2 的抽取 prompt 和 node 3 的匹配规则。

prompt 必须给出清晰的抽取字段说明，并要求模型严格输出结构化结果。抽取字段决定了后续规则判断可以依赖哪些信息。如果抽取不完整，后面的关键词匹配和年限判断都会失真。

匹配规则中的 “gte” 表示大于等于，“contains” 表示包含。条件分支节点还支持多个规则组合，比如“年限大于等于 3 且技术栈包含 Java”。实际项目中，JD 里的“3 年以上”往往是硬性条件，而“熟悉分布式”“有高并发经验”是加分项。更精细的做法是设置两层判断：硬性条件不满足直接淘汰，加分项用于排序和推荐理由生成。

7. 自动触发与外部调用：WorkBuddy 的工程化扩展

7.1 通过命令行触发

工作流搭好后，每次在界面里点击运行有点笨重，工程化落地时更常用的方式是命令行触发或 API 触发。假设 WorkBuddy 提供了命令行工具，那么手动触发一个简历筛选任务的思路是：

# 触发本地工作流，传入简历目录参数 workbuddy run resume-filter --input data/resumes --output output/result.csv

命令行方式的优点是便于脚本化，可以放进 cron 定时任务里。比如每天凌晨自动处理前一天投递的简历，第二天早上 HR 就能收到结构化筛选结果。这是工作流工具从“演示玩具”变成“生产工具”的关键一步。

7.2 通过 HTTP API 调用

如果你的项目是 Spring Boot 或 Python Web 服务，更推荐的方式是通过 HTTP API 异步触发工作流。下面是一个 Java + HttpClient 的调用示例，用来向工作流服务提交任务：

// 文件路径：src/main/java/com/example/workflow/WorkflowClient.java import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; public class WorkflowClient { private static final String API_URL = "http://localhost:8080/api/workflows/resume-filter/run"; private static final String API_TOKEN = System.getenv("WORKBUDDY_API_TOKEN"); public static void main(String[] args) throws Exception { String requestBody = """ { "input": "data/resumes", "callback": "http://your-server/notify/result" } """; HttpClient client = HttpClient.newHttpClient(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(API_URL)) .header("Content-Type", "application/json") .header("Authorization", "Bearer " + API_TOKEN) .POST(HttpRequest.BodyPublishers.ofString(requestBody)) .build(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println("提交状态码: " + response.statusCode()); System.out.println("任务ID: " + response.body()); } }

这个示例演示了三个关键实践：API Token 从环境变量读取、通过回调地址接收结果、提交后拿到任务 ID。拿到任务 ID 后，即使流程运行很久，你也能在外部系统追踪执行状态。注意，这里的 API 地址和端点路径仅为示例思路，实际应以你部署的服务端口和路由为准。

7.3 在 Python 脚本中调用

Python 使用者可以用 requests 库做同样的提交操作，核心逻辑完全一致：构建请求头、提交输入参数、等待回调或轮询结果。写到这里，我想强调的是：工作流工具只是执行引擎，真正让它融入工程的是外部触发和结果回传机制。建议你在学习 WorkBuddy 时，至少掌握“命令行触发”和“API 触发”其中一种方式。

8. 运行结果与效果验证

8.1 运行命令示例

以简历筛选工作流为例，验证步骤如下：

# 确保 test-data 目录下有 3 份测试简历 workbuddy run resume-filter --input test-data --output test-output/result.csv

8.2 预期输出与判断标准

如果流程正常执行，你会得到一份 CSV 文件，大致内容如下：

姓名,工作年限,技术栈,学历,最近岗位,匹配结果 张三,5,"Java,Spring,MySQL",本科,后端开发,通过 李四,2,"Python,Java",硕士,测试开发,不通过 王五,3,"C++,Go",本科,后端开发,不通过

判断工作流是否成功的标准有三个：

第一，输出文件是否生成，并且格式是否符合预期；第二，同一份输入文件，重复运行两次的结果是否稳定；第三，规则匹配是否符合常识。比如李四虽然有 Java 技能，但工作年限只有 2 年，被判定不通过是合理结果；王五年限满足但技术栈不包含 Java，不通过也合理。

8.3 失败后的第一排查顺序

如果运行失败，不要直接看代码输出，按下面顺序排查最快：

1. 查日志：确认是哪个节点报错。
2. 查输入：确认输入目录路径是否存在、是否有可读文件。
3. 查模型：确认默认模型配置是否正常，提供测试文本给模型试用。
4. 查权限：确认涉及到外部 API 的工具是否有有效密钥。

日志是第一步。优秀的日志会告诉你失败发生在文件读取阶段、模型推理阶段还是结果写入阶段。定位到阶段后，再缩小范围检查具体配置。盲目重跑和随机改动配置，只会让问题更难排查。

9. 常见问题与排查思路

以下表格整理了 WorkBuddy 使用过程中最常见的问题和排查方法，建议收藏备用。

其中“上下文超长”是高频问题。工作流中传入了长文档时，经常会超出模型上下文限制。更稳妥的做法是在工作流里增加文本切分节点，将长文本按段落或固定长度切块，再分块处理。这比简单换一个长上下文模型更可控，也能显著降低 API 调用成本。

10. 最佳实践与工程建议

10.1 命名与目录规范

工作流和技能的命名直接影响团队协作效率。建议采用“场景-动作-版本”格式，例如resume-filter-v2、weekly-report-v3。目录结构按第 5 章推荐的“项目-场景-版本”三层组织。这样即使几个月后再回来维护，也能快速定位。

10.2 配置与密钥管理

严禁在 JSON 工作流定义中硬编码 API 密钥和数据库密码。建议使用环境变量或密钥管理平台。每个工具分配独立的密钥，遵循最小权限原则。一旦某个工具的密钥泄露，只需要单独轮换它，而不影响其他项目。

10.3 测试与回归

工作流本质上是一个程序，必须有测试意识。每次改动 prompt 或匹配规则后，都要用同一份测试数据集跑一遍，对比结果变化。这能让你及时发现“修复了一个 bug 却引入了三个回归问题”。建议每个工作台保留一个test-data目录和一组历史结果文件，作为回归基准。

10.4 版本控制与回滚

如果 WorkBuddy 支持配置导出，务必把工作流定义纳入 Git 管理。每次修改前导出一份副本，修改后如果有问题，可以快速回滚到上一个可靠版本。不要把工作流定义只存在工具内部，否则一次误操作可能丢掉几周的工作成果。

10.5 日志与留痕

生产环境使用工作流时，需要保留足够的运行日志。日志至少应包含：任务 ID、输入摘要、各节点耗时、模型消耗 token 数、最终输出地址。这些数据既能用于排查问题，也是评估成本和优化 prompt 的重要依据。

10.6 安全边界提醒

在编写工具配置时，要特别注意防止提示注入和路径穿越问题。来自外部的输入内容，严格控制其读取文件的范围；把模型输出当命令执行时，必须设置白名单。不要因为追求“全自动”，而让工作流在无监督状态下执行高危操作，比如直接修改生产数据库或删除文件。相关操作必须先经过人工审批步骤。

11. 总结与后续学习方向

WorkBuddy 真正讲清楚的一件事是：AI 工作流不是画布上的几个节点，而是可复用、可版本化、可工程化的能力资产。它让你把常用的 AI 处理逻辑从临时脚本升级为标准技能，同时保持本地化和可控性。对于开发者来说，这意味着工作流不再是“平台限定功能”，而是一种可以嵌入自己工程的编码方式。

如果你是零基础入门，建议按照这个节奏推进：先装好环境，跑通一个最小工作流，理解触发、节点、输出三个基础环节；然后尝试把一个完整的小任务（比如简历筛选）拆成工作流，调整 prompt 和匹配规则；接着学习技能封装，把调通过的工作流固化下来；最后再研究 API 调用、缓存迁移和项目搬迁这些工程化细节。如果你已经在用 Coze 或 Dify，则可以更关注 WorkBuddy 与代码工程结合的部分，思考现有流程能否用本地工具链重新实现。

关于 B 站那套号称“最细最全”的 10 节付费课，这里给你一个不吃亏的拆解思路。无论课程具体内容是什么，市场上这类课程通常逃不开固定的结构：先是安装和环境配置，然后是界面和核心概念解释，接着是第一个最小工作流示例，再到工具调用、技能封装、条件分支、数据输入输出、项目实战，最后是调试和发布。想判断课程值不值得买，就看它在“案例深度”和“真实避坑”两个维度上有没有超出公开资料的信息量。很多课程讲的是软件操作步骤，这些步骤看官方文档也能学会；真正值钱的，是讲师在真实项目中积累的参数调优经验、多人协作规范和生产部署路径。

就当前阶段而言，你可以先用本文的示例自己搭一个简历筛选工作流，走通从配置到验证的完整闭环。这个最小闭环建立起来以后，后续学习新工具、新功能的成本会大幅降低。毕竟，工具会迭代，平台会更换，但“把任务拆成工作流、把工作流固化为技能”这套方法论，才是 AI 时代开发者真正值得沉淀的东西。