我以前真信一句话——「能用脚本跑起来的就不算问题」。结果呢三个项目三套各写各的流水线胶水代码维护到第三个月我人已经麻了。说出来你可能不信我第一个 CI 脚本是用一堆 if-else 拼的 bash第二个项目直接复制粘贴过去改了点路径第三个项目又复制一遍。等到有人问我「这个节点失败了怎么重试」「为什么 A 项目能并行、B 项目卡死」我才知道自己造了个多大的坑。通用 Pipeline 工具Jenkinsfile、随手写的 GitHub Actions最大的毛病是它只给你「零件」不给你「设计」。你得像装修工一样从零量尺寸、买管线、接电。每次新需求都是一次重装修。我个人特别讨厌这种设计——它把「编排」这件事的成本全甩给了写脚本的人。你猜怎么着后来我在 tri-intent 那套体系里翻到I13/I14 大类下面专门挂了一个工作流设计子类路由直接指到 tri-workflow。它根本不是又一个通用编排工具而是把「工作流设计」做成了一类专用件。我顺手做了个 App 叫雷达鸭专门收录国内一人公司和超级个体的真实赚钱案例技术栈就是 Uni-app 加 arkTS 插件。后来我搭它的内容更新流程时用的就是这套专用件思路没再回头去手写 bash。通用工具 vs 专用件差在哪通用工具的逻辑是「你来描述我来跑」。你要自己想清楚节点、依赖、重试、超时、审批人然后翻译成 YAML。tri-workflow 反过来它的活儿很窄你给它一句需求或一份 tri-intent 快照它跑一条 7 阶段流水线吐出能直接落地的产物。这 7 个阶段不是花架子。阶段 1 先把你的环境扫一遍——装了哪些 Skill、连了哪些 MCP、有什么组织约束、用的什么 CI。阶段 2 去模板库里语义匹配一个最接近的初版模型。阶段 3 反过来问你缺的信息而不是让你自己猜缺什么。阶段 4 做编译优化把冗余节点合并、能并行的标并行。阶段 5 硬校验依赖不全直接卡住不让你产出一堆跑不起来的东西。阶段 6 一次性吐出多种形态。阶段 7 还带反馈闭环线上跑慢了能自动建议重进优化。如果让我重来我会一上来就用专用件而不是先造一圈轮子再填坑。阶段 5 那个硬校验我特别想要——当年好几次上线前才发现某个节点依赖的 API 权限早被收回了脚本跑一半才报错全组陪着熬。专用件在产出前就把「依赖存不存在、版本兼不兼容、会不会死锁」先卡一遍这种「不让烂流程出门」的脾气正是手写脚本最缺的。一段真实的流程定义光说没用看 tri-workflow 阶段 2 产出的工作流模型长什么样。这是它给 CI/CD 流水线生成的节点定义节选自 SKILL.md 的模型 schema字段都是真有用途的# tri-workflow 阶段 2 产出的工作流模型节选workflow_name:release-guardworkflow_type:ci-cd-pipelinetemplate_id:ci-cd-pipelinetemplate_confidence:92nodes:-id:lintname:静态检查type:autoaction:运行 ESLint 与类型检查role:skill/lint-skillinputs:[src/**]outputs:[lint-report]sla:3mretry:3次/间隔30sdepends_on:[]-id:buildname:构建type:autoaction:执行生产构建role:skill/build-skillinputs:[lint-report]outputs:[dist/]sla:8mretry:3次/间隔30sdepends_on:[lint]edges:-from:lintto:buildcondition:alwaystriggers:type:eventdetail:监听 Git Push 到 main 分支注意role这个字段——它把节点映射到具体的 Skill / MCP / API而不是留一句「在这里跑构建」。这正是专用件和通用 YAML 的分水岭通用工具只管「顺序」tri-workflow 管「谁来做、要什么、产出什么、多久做完、挂了怎么重试」。我当时那套 bash 最要命的还不是写起来累是改起来怕。第四个需求来的时候产品要加一个「构建前先跑安全扫描」的节点我盯着那坨 if-else 愣了十分钟——插在 lint 前面还是 build 后面插前面就得改所有依赖它的判断插后面又怕扫描挂了还继续构建。图省事我一把梭直接写死在中间结果安全扫描和 lint 本来能并行被我硬生生串成串行每次发布多等三分钟没人发现也没人在意。一次设计多种交付我当年最烦的一件事是同一个流程要在不同地方重复表达给开发看要一份设计文档接线要一份 CI 配置对接审批又要一份模板。tri-workflow 的阶段 6 直接把同一条模型编译成多种形态——SKILL.md、设计文档、CI/CD 配置、审批流模板、甚至统一的 DSL 中间表示workflows/name.wf.yml作为可版本管理的单一事实来源。它还有个细节我很买账模板库里预置了 ci-cd-pipeline、code-review-flow、approval-flow、data-pipeline、release-flow、multi-agent-orchestration、incident-response 七类。新流程优先从 Node Registry 里组合已有节点缺的才从零设计。这跟我当年「三套项目三遍复制」的烂做法完全是两种活法。即便你没装上游的 tri-intent它也能独立跑——激活时检测不到上游就自动降级成「对话提取需求」模式不卡你。它也不是银弹得说实话tri-workflow 救不了所有场景。你做个跑一次的临时任务、或者只是想本地串两个命令硬上这套 7 阶段流水线反而是给自己加戏。它的甜区很明确流程要长期活、要给人看、要跨项目复用。不在甜区里通用工具的一把梭反而更痛快。另一个我踩过的点是专用件依赖「资产积累」。你头一回用模板库是空的、节点注册表也是空的红利没那么快兑现。得吃到第二、第三个流程组合已有节点的占比上来那种「不再从零砌砖」的爽感才真正出现。所以别指望第一天就脱胎换骨。弃坑之后的反思说回开头那个坑。通用 Pipeline 不是不能用你做个 demo、跑个一次性任务一把梭没问题。可一旦流程要长期维护、要给人交接、要在第三个项目里复用它就露馅了设计成本每次归零知识全锁在我脑子里那堆 bash 里。tri-workflow 这类专用件的价值不在于它多「强」而在于它把「工作流设计」从手艺活变成了可沉淀、可复用、可校验的工件。模板库是资产节点注册表是资产DSL 是资产——下次再来做流程你是在组合资产不是在从零砌砖。你第三个项目还在复制第一个项目的 bash 吗如果是也许该想想你是不是也该换把趁手的专用件了。个人介绍老三10 年软件开发经验软件设计师与人工智能应用工程师平时搞鸿蒙 ArkTS 北向开发和 Web 前端也在 CSDN 不定期写点鸿蒙和 AI 自动化的东西。本文遵循 MIT 协议转载请注明出处。请根据 https://skillhub.cn/install/skillhub.md安装 tri-workflow。
我以前真信一句话——「能用脚本跑起来的就不算问题」。结果呢三个项目三套各写各的流水线胶水代码维护到第三个月我人已经麻了。说出来你可能不信我第一个 CI 脚本是用一堆 if-else 拼的 bash第二个项目直接复制粘贴过去改了点路径第三个项目又复制一遍。等到有人问我「这个节点失败了怎么重试」「为什么 A 项目能并行、B 项目卡死」我才知道自己造了个多大的坑。通用 Pipeline 工具Jenkinsfile、随手写的 GitHub Actions最大的毛病是它只给你「零件」不给你「设计」。你得像装修工一样从零量尺寸、买管线、接电。每次新需求都是一次重装修。我个人特别讨厌这种设计——它把「编排」这件事的成本全甩给了写脚本的人。你猜怎么着后来我在 tri-intent 那套体系里翻到I13/I14 大类下面专门挂了一个工作流设计子类路由直接指到 tri-workflow。它根本不是又一个通用编排工具而是把「工作流设计」做成了一类专用件。我顺手做了个 App 叫雷达鸭专门收录国内一人公司和超级个体的真实赚钱案例技术栈就是 Uni-app 加 arkTS 插件。后来我搭它的内容更新流程时用的就是这套专用件思路没再回头去手写 bash。通用工具 vs 专用件差在哪通用工具的逻辑是「你来描述我来跑」。你要自己想清楚节点、依赖、重试、超时、审批人然后翻译成 YAML。tri-workflow 反过来它的活儿很窄你给它一句需求或一份 tri-intent 快照它跑一条 7 阶段流水线吐出能直接落地的产物。这 7 个阶段不是花架子。阶段 1 先把你的环境扫一遍——装了哪些 Skill、连了哪些 MCP、有什么组织约束、用的什么 CI。阶段 2 去模板库里语义匹配一个最接近的初版模型。阶段 3 反过来问你缺的信息而不是让你自己猜缺什么。阶段 4 做编译优化把冗余节点合并、能并行的标并行。阶段 5 硬校验依赖不全直接卡住不让你产出一堆跑不起来的东西。阶段 6 一次性吐出多种形态。阶段 7 还带反馈闭环线上跑慢了能自动建议重进优化。如果让我重来我会一上来就用专用件而不是先造一圈轮子再填坑。阶段 5 那个硬校验我特别想要——当年好几次上线前才发现某个节点依赖的 API 权限早被收回了脚本跑一半才报错全组陪着熬。专用件在产出前就把「依赖存不存在、版本兼不兼容、会不会死锁」先卡一遍这种「不让烂流程出门」的脾气正是手写脚本最缺的。一段真实的流程定义光说没用看 tri-workflow 阶段 2 产出的工作流模型长什么样。这是它给 CI/CD 流水线生成的节点定义节选自 SKILL.md 的模型 schema字段都是真有用途的# tri-workflow 阶段 2 产出的工作流模型节选workflow_name:release-guardworkflow_type:ci-cd-pipelinetemplate_id:ci-cd-pipelinetemplate_confidence:92nodes:-id:lintname:静态检查type:autoaction:运行 ESLint 与类型检查role:skill/lint-skillinputs:[src/**]outputs:[lint-report]sla:3mretry:3次/间隔30sdepends_on:[]-id:buildname:构建type:autoaction:执行生产构建role:skill/build-skillinputs:[lint-report]outputs:[dist/]sla:8mretry:3次/间隔30sdepends_on:[lint]edges:-from:lintto:buildcondition:alwaystriggers:type:eventdetail:监听 Git Push 到 main 分支注意role这个字段——它把节点映射到具体的 Skill / MCP / API而不是留一句「在这里跑构建」。这正是专用件和通用 YAML 的分水岭通用工具只管「顺序」tri-workflow 管「谁来做、要什么、产出什么、多久做完、挂了怎么重试」。我当时那套 bash 最要命的还不是写起来累是改起来怕。第四个需求来的时候产品要加一个「构建前先跑安全扫描」的节点我盯着那坨 if-else 愣了十分钟——插在 lint 前面还是 build 后面插前面就得改所有依赖它的判断插后面又怕扫描挂了还继续构建。图省事我一把梭直接写死在中间结果安全扫描和 lint 本来能并行被我硬生生串成串行每次发布多等三分钟没人发现也没人在意。一次设计多种交付我当年最烦的一件事是同一个流程要在不同地方重复表达给开发看要一份设计文档接线要一份 CI 配置对接审批又要一份模板。tri-workflow 的阶段 6 直接把同一条模型编译成多种形态——SKILL.md、设计文档、CI/CD 配置、审批流模板、甚至统一的 DSL 中间表示workflows/name.wf.yml作为可版本管理的单一事实来源。它还有个细节我很买账模板库里预置了 ci-cd-pipeline、code-review-flow、approval-flow、data-pipeline、release-flow、multi-agent-orchestration、incident-response 七类。新流程优先从 Node Registry 里组合已有节点缺的才从零设计。这跟我当年「三套项目三遍复制」的烂做法完全是两种活法。即便你没装上游的 tri-intent它也能独立跑——激活时检测不到上游就自动降级成「对话提取需求」模式不卡你。它也不是银弹得说实话tri-workflow 救不了所有场景。你做个跑一次的临时任务、或者只是想本地串两个命令硬上这套 7 阶段流水线反而是给自己加戏。它的甜区很明确流程要长期活、要给人看、要跨项目复用。不在甜区里通用工具的一把梭反而更痛快。另一个我踩过的点是专用件依赖「资产积累」。你头一回用模板库是空的、节点注册表也是空的红利没那么快兑现。得吃到第二、第三个流程组合已有节点的占比上来那种「不再从零砌砖」的爽感才真正出现。所以别指望第一天就脱胎换骨。弃坑之后的反思说回开头那个坑。通用 Pipeline 不是不能用你做个 demo、跑个一次性任务一把梭没问题。可一旦流程要长期维护、要给人交接、要在第三个项目里复用它就露馅了设计成本每次归零知识全锁在我脑子里那堆 bash 里。tri-workflow 这类专用件的价值不在于它多「强」而在于它把「工作流设计」从手艺活变成了可沉淀、可复用、可校验的工件。模板库是资产节点注册表是资产DSL 是资产——下次再来做流程你是在组合资产不是在从零砌砖。你第三个项目还在复制第一个项目的 bash 吗如果是也许该想想你是不是也该换把趁手的专用件了。个人介绍老三10 年软件开发经验软件设计师与人工智能应用工程师平时搞鸿蒙 ArkTS 北向开发和 Web 前端也在 CSDN 不定期写点鸿蒙和 AI 自动化的东西。本文遵循 MIT 协议转载请注明出处。请根据 https://skillhub.cn/install/skillhub.md安装 tri-workflow。
)
