上个月我还在用 Excel 管我的工作流。客服问题来了手动回，知识库更新了手动同步，写代码手动跑检查，发文章手动一个个平台粘贴。每天忙到凌晨，仔细一算，大半时间花在了"切换"上——从这个工具切到那个工具，从这件事跳到那件事。
后来我用 tri-workflow 把这些流程串了起来。一周时间，搭了四条线：客服、知识库、编码协作、自媒体发布。今天聊聊每条线怎么搭的、踩了哪些坑、现在跑得到底怎么样。
客服系统：AI 先接 80% 的问题
先聊最痛的。做雷达鸭那段时间，用户反馈全靠我一个人扛。每天打开飞书，十几条未读消息，有问功能的、有报 bug 的、有说"能不能加个 XX 功能"的。回吧，太占时间；不回吧，用户体验差。
我一开始想的是"搞个智能客服"，但又觉得太重——要对接 IM、要做知识库、要做意图识别，想想就头大。后来我用 tri-workflow 的多 Agent 协作模板改了改，三天就跑起来了。
原模板是任务分解→并行分发→结果聚合→冲突检测→最终输出，我改成了串行加分支的结构。核心思路很简单：用户发消息过来，先判断是什么类型的问题，再去知识库找答案，找得到就让 AI 组织语言回复，找不到就转人工。
workflow_name:customer-servicenodes:-id:receive_messagename:接收用户消息type:autorole:{type:mcp,target:lark-im}action:监听用户私信并提取问题内容outputs:-{name:user_message,type:string}-{name:user_id,type:string}-id:intent_classifyname:意图分类type:autorole:{type:skill,target:tri-intent}action:判断是咨询、报障还是建议inputs:-{name:user_message,type:string,source:receive_message.outputs.user_message}outputs:-{name:intent_type,type:string}-id:kb_searchname:知识库检索type:autorole:{type:skill,target:tri-loop}action:在知识库中检索相关答案inputs:-{name:query,type:string,source:receive_message.outputs.user_message}outputs:-{name:kb_results,type:array}-{name:hit_score,type:number}-id:hit_checkname:命中判断type:conditionconditions:-{expression:"hit_score >= 0.8",target_node:generate_answer}-{expression:"hit_score < 0.8",target_node:human_transfer}depends_on:[kb_search]-id:generate_answername:AI 生成回复type:autorole:{type:skill,target:tri-content}action:基于知识库结果生成回复inputs:-{name:user_message,type:string,source:receive_message.outputs.user_message}-{name:kb_results,type:array,source:kb_search.outputs.kb_results}outputs:-{name:answer,type:string}-id:answer_reviewname:人工审核type:approvalapproval:approvers:[客服]auto_approve_after:10msla:{expected_duration:5m,timeout:10m,unit:m}depends_on:[generate_answer]-id:send_replyname:发送回复type:autorole:{type:mcp,target:lark-im}inputs:-{name:answer,type:string,source:answer_review.outputs.answer}-{name:user_id,type:string,source:receive_message.outputs.user_id}depends_on:[answer_review]-id:human_transfername:转人工type:autorole:{type:mcp,target:lark-task}action:创建待办通知客服跟进depends_on:[hit_check]-id:log_recordname:记录对话日志type:autorole:{type:system,target:tri-loop}action:记录到知识库信号库depends_on:[send_reply,human_transfer]第一个坑是置信度阈值。我一开始设的 0.7，结果 AI 经常答非所问——知识库没有的内容它也硬凑。有次用户问"怎么导出数据"，知识库明明只有导入的说明，AI 也敢编一段导出步骤出来。后来调到 0.8，低于阈值的直接转人工，准确率一下就上去了。代价是转人工的比例从 10% 升到了 20%，但我宁愿多花点时间人工回，也不想让用户收到瞎编的答案。
第二个坑是审核超时。我一开始把人工审核的超时设成 30 分钟，结果经常出现用户等了半小时还没收到回复的情况。后来改成 10 分钟自动通过——AI 生成的回复本来就是基于知识库的，风险可控，真有问题用户会再问回来。
跑了两周，数据是这样的：80% 的问题 AI 直接答了，剩下 20% 转人工。我每天花在客服上的时间从两小时降到了二十分钟。而且日志记录节点会把每轮对话存到知识库的信号库，哪些问题被问得多、哪些问题知识库答不上来，一目了然——这直接喂给了下一条线。
知识库更新：从写完就忘到自动闭环
我的知识库以前是个笑话。说是知识库，其实就是一堆零散的 Markdown 文件，散落在不同的文件夹里。想找个东西全靠搜索文件名，内容过时了也不知道，新的经验写完就丢。
搭完客服线之后，我顺手把知识库更新也做成了一条流水线。用的是data-pipeline模板改造的。
思路是这样的：从各个地方采集"信号"——客服没答上来的问题、复盘中的经验教训、代码提交里的 fix/feat 提交——然后过滤、分类、提取知识点、去重、人工审核、最后入库。
workflow_name:knowledge-base-pipelinenodes:-id:signal_collectname:信号采集type:autorole:{type:skill,target:tri-loop}action:采集客服对话、复盘笔记、代码提交记录outputs:-{name:raw_signals,type:array}-id:quality_filtername:质量初筛type:autorole:{type:skill,target:tri-content}action:过滤低质量信号，去重去噪inputs:-{name:raw_signals,type:array,source:signal_collect.outputs.raw_signals}outputs:-{name:filtered_signals,type:array}-id:classify_tagname:分类打标type:autorole:{type:skill,target:tri-content}action:领域分类和标签化inputs:-{name:filtered_signals,type:array,source:quality_filter.outputs.filtered_signals}outputs:-{name:tagged_signals,type:array}-id:knowledge_extractname:知识点提取type:autorole:{type:skill,target:tri-content}action:提取结构化知识点inputs:-{name:tagged_signals,type:array,source:classify_tag.outputs.tagged_signals}outputs:-{name:knowledge_drafts,type:array}-id:duplicate_checkname:去重校验type:autorole:{type:system,target:tri-loop}action:检查是否已有相似内容inputs:-{name:knowledge_drafts,type:array,source:knowledge_extract.outputs.knowledge_drafts}outputs:-{name:new_items,type:array}-{name:update_items,type:array}-id:human_reviewname:人工审核type:approvalapproval:approvers:[知识管理员]auto_approve_after:24hsla:{expected_duration:4h,timeout:24h,unit:h}depends_on:[duplicate_check]-id:vectorize_and_storename:向量化入库type:autorole:{type:system,target:tri-loop}action:向量化并存入向量数据库retry:{max_attempts:3,interval:60s,backoff:exponential}depends_on:[human_review]-id:notify_updatename:更新通知type:notificationnotification:channel:飞书recipients:[全体成员]depends_on:[vectorize_and_store]第一个坑：采集源太多了。我一开始把客服对话、代码提交、复盘笔记、甚至聊天记录全塞进去了，结果信噪比极低——90% 的信号都是噪声，人工审核根本看不过来。后来我砍到只留三个来源：客服未命中的问题（说明知识库缺这部分）、复盘笔记里的"经验教训"章节、代码提交的 commit message 里带 fix/feat 的。信噪比一下就上来了。
第二个坑：自动审核。我试过让 AI 自己审核自己提取的知识点，结果嘛……你懂的，自己审自己，什么都能过。后来还是加了人工审核节点，虽然慢了点，但质量有保障。不过我设了 24 小时自动通过——不是什么生死攸关的知识，晚点入库也没事。
知识库的更新从"我想起来才更"变成了"每天自动更"。刚上线第一周就新增了四十多条知识，大部分来自客服没答上来的问题。现在知识库能回答的问题越来越多，客服线的 AI 命中率也跟着涨——这两条线形成了一个正循环。
说个好笑的，有次我自己搜知识库，搜到一条知识觉得写得挺好，想不起来什么时候写的，翻了日志才发现是 AI 从我的复盘中提取出来的。那种"我自己的经验我自己都忘了，知识库还记得"的感觉，挺奇妙的。
编码协作：CI/CD 半小时搭完
我写代码有个坏习惯：写完就提交，经常漏了跑测试、忘了做代码检查。结果就是 CI 挂了被同事吐槽，或者上线了才发现 bug。
我知道应该搞 CI/CD，但每次搭 CI 配置都觉得麻烦——要写 YAML、要配环境变量、要搞缓存、要处理各种 edge case。这次我用 tri-workflow 的ci-cd-pipeline模板，半小时就搞定了。
workflow_name:coding-pipelinetriggers:type:eventdetail:Git Push 事件触发nodes:-id:code_checkoutname:代码检出type:autorole:{type:system,target:git}outputs:-{name:code_path,type:string}-id:static_checkname:静态代码检查type:autorole:{type:skill,target:tri-review}action:检查代码规范、潜在 bug、安全问题inputs:-{name:code_path,type:string,source:code_checkout.outputs.code_path}outputs:-{name:issues_count,type:number}-id:check_passname:检查通过判断type:conditionconditions:-{expression:"issues_count == 0",target_node:unit_test}-{expression:"issues_count > 0",target_node:notify_issues}depends_on:[static_check]-id:unit_testname:单元测试type:autorole:{type:system,target:npm/pytest}action:运行单元测试套件retry:{max_attempts:2,interval:60s,backoff:fixed,on_failure:abort}inputs:-{name:code_path,type:string,source:code_checkout.outputs.code_path}outputs:-{name:pass_rate,type:number}-{name:coverage,type:number}depends_on:[check_pass]-id:test_passname:测试通过判断type:conditionconditions:-{expression:"pass_rate == 100",target_node:build}-{expression:"pass_rate < 100",target_node:notify_test_fail}depends_on:[unit_test]-id:buildname:构建打包type:autorole:{type:system,target:npm/docker}inputs:-{name:code_path,type:string,source:code_checkout.outputs.code_path}outputs:-{name:build_artifact,type:string}depends_on:[test_pass]-id:deploy_stagingname:部署到预发布type:autorole:{type:system,target:docker/k8s}inputs:-{name:build_artifact,type:string,source:build.outputs.build_artifact}outputs:-{name:staging_url,type:string}depends_on:[build]-id:smoke_testname:冒烟测试type:autorole:{type:system,target:curl}inputs:-{name:staging_url,type:string,source:deploy_staging.outputs.staging_url}depends_on:[deploy_staging]-id:notify_successname:成功通知type:notificationnotification:{channel:飞书,recipients:[开发团队]}depends_on:[smoke_test]-id:notify_issuesname:代码问题通知type:notificationnotification:{channel:飞书,recipients:[提交者]}depends_on:[check_pass]-id:notify_test_failname:测试失败通知type:notificationnotification:{channel:飞书,recipients:[提交者]}depends_on:[test_pass]第一个坑：全量检查太慢。我一开始把静态检查、安全扫描、lint、类型检查全塞到一个节点里，跑一次要十几分钟。等流水线跑完，我都开始写下一个功能了。后来我把检查拆成了两部分：核心检查（lint + 类型检查）放在 CI 里，跑一次三分钟；安全扫描和深度审查放到晚上的定时任务里。体验好多了。
第二个坑：测试不稳定。有些测试依赖网络，有时候网络波动测试就挂了，重试一次又过了。我一开始设的是失败就停，结果经常因为网络问题流水线红了。后来给测试节点加了重试——最多两次，间隔一分钟。假阳性少了很多。
现在提交代码心里踏实多了。以前提交完总觉得漏了什么，现在流水线绿了就稳了。tri-workflow 产出的不只是 CI 配置，还有一份设计文档，每个节点的输入输出、SLA、重试策略都写得清清楚楚。后来我加了新的检查步骤，直接改设计文档，tri-workflow 自动生成新的 CI 配置，不用自己去抠 YAML。
自媒体发布：从随缘更新到每周两篇
再说说自媒体这条线。我在 CSDN 写文章，以前的模式是：周末有空了就写一篇，没空就拉倒。选题靠灵感，写稿靠心情，发布靠手动。更新频率极其不稳定，有时候一周三篇，有时候三周一篇。
用 tri-workflow 搭了一条内容流水线之后，模式变了：每天自动采集热点，每周固定产出两篇，发布全自动化。我只需要做一件事：审核。
这条线没有完全匹配的模板，是我自定义的。tri-workflow 的模板匹配度只有 60% 多，我选了"自定义"模式，从零搭的。
workflow_name:self-media-publishtriggers:type:scheduledetail:每周一、三、五早上 8 点触发nodes:-id:hotspot_collectname:热点采集type:autorole:{type:skill,target:tri-content}action:从技术社区采集热点话题outputs:-{name:hot_topics,type:array}-id:topic_screenname:选题筛选type:autorole:{type:skill,target:tri-content}action:结合个人定位筛选合适选题inputs:-{name:hot_topics,type:array,source:hotspot_collect.outputs.hot_topics}outputs:-{name:selected_topics,type:array}-id:outline_generatename:大纲生成type:autorole:{type:skill,target:tri-content}action:为每个选题生成文章大纲inputs:-{name:selected_topics,type:array,source:topic_screen.outputs.selected_topics}outputs:-{name:outlines,type:array}-id:outline_reviewname:大纲审核type:approvalapproval:{approvers:[作者],auto_approve_after:12h}sla:{expected_duration:2h,timeout:12h,unit:h}depends_on:[outline_generate]-id:article_writename:文章撰写type:autorole:{type:skill,target:tri-article}action:基于大纲撰写完整文章inputs:-{name:approved_outlines,type:array,source:outline_review.outputs.approved_outlines}outputs:-{name:articles_draft,type:array}depends_on:[outline_review]-id:deai_rewritename:去 AI 化改写type:autorole:{type:skill,target:tri-humanize}action:去 AI 化改写inputs:-{name:articles_draft,type:array,source:article_write.outputs.articles_draft}outputs:-{name:articles_final,type:array}depends_on:[article_write]-id:article_reviewname:终稿审核type:approvalapproval:{approvers:[作者],auto_approve_after:24h}sla:{expected_duration:4h,timeout:24h,unit:h}depends_on:[deai_rewrite]-id:format_adaptname:多平台排版适配type:parallelinputs:-{name:approved_articles,type:array,source:article_review.outputs.approved_articles}depends_on:[article_review]-id:publish_csdnname:发布到 CSDNtype:autorole:{type:api,target:csdn}depends_on:[format_adapt]-id:publish_zhihuname:发布到知乎type:autorole:{type:api,target:zhihu}depends_on:[format_adapt]-id:publish_juejinname:发布到掘金type:autorole:{type:api,target:juejin}depends_on:[format_adapt]-id:data_collectname:发布数据回收type:autorole:{type:skill,target:tri-content}action:收集各平台阅读、点赞、评论数据depends_on:[publish_csdn,publish_zhihu,publish_juejin]-id:report_generatename:生成周报type:autorole:{type:skill,target:tri-content}action:生成本周内容运营周报depends_on:[data_collect]第一个坑：发布节点串行。我一开始把三个平台的发布节点串起来了——先发 CSDN，再发知乎，最后发掘金。每次发布要等三分钟，虽然也不算长，但总觉得没必要。后来改成并行发布，一秒钟就完事了。tri-workflow 的编译优化阶段会自动识别没有依赖关系的节点，建议改成并行——这个功能我一开始没当回事，用了才发现是真香。
第二个坑：选题跑偏。AI 选的选题经常是那种"什么火写什么"，但跟我的定位不搭。比如有次它给我选了个"抖音运营技巧"的题，我一个写技术的怎么会写这个？后来我在选题筛选节点加了定位约束，把我的领域关键词（鸿蒙、ArkTS、前端、AI 工程化）喂进去，选题就靠谱多了。
更新频率从"随缘"变成了"每周两篇"，而且我实际花的时间反而少了。以前写一篇文章要大半天，现在只需要审核大纲和终稿，加起来不到一小时。数据回收和周报生成也是自动的，哪些选题受欢迎、哪个平台效果好，每周一目了然。
雷达鸭的运营内容也是用这条线跑的。案例采集、内容审核、多平台发布，全串起来了。以前我管运营靠的是"今天想起来就做"，现在靠的是"流程到点自动提醒我"。这两者的差别，用过的人都知道。
几点经验
四条线搭下来，踩了不少坑，也攒了点心得。
先扫环境再设计。我第一条客服线就犯了这个错——直接让它设计，结果依赖的某个 MCP 服务我根本没配，到校验阶段被打回来返工。多花两分钟让 tri-workflow 扫一下环境，能省后面一小时的麻烦。
模板能套就套，套不了再自定义。七条内置模板覆盖了大部分常见场景，套模板十分钟搞定，从零搭可能要半小时。而且模板里的节点都是经过验证的，SLA、重试策略、异常处理都帮你想好了，不用自己踩一遍。
每个节点都要有 SLA。这是我最开始忽略的。没有 SLA 的审批节点，会永远卡在"等审批"里没人管；没有 SLA 的自动节点，挂了也不知道。给每个节点设上预期耗时和超时时间，出了问题至少能知道卡在哪。
渐进式交付，别一步到位。tri-workflow 有个设计我很喜欢：每个阶段都产出可独立交付的中间产物。你可以先让它出个初版模型，看看节点对不对，再让它补全细节，再优化，最后生成产物。不用一口气憋到底，中间随时可以调整。
我现在的做法是：先用模板快速搭个雏形，跑两天看看哪里不顺手，再迭代优化。tri-workflow 的阶段七迭代反馈就是干这个的——SLA 连续七天低于 80% 就提示你优化，环境变了就重新扫环境，模板更新了就提示你升级。
工作流这东西，不是搭完就完事了。它是个活的东西，要跟着你的业务一起长。tri-workflow 有意思的地方就在于，它不是让你"画一个流程图然后就那样了"，而是给你一套持续迭代的机制——设计、跑、收集反馈、优化、再跑，循环往复。
四条线跑了一个月，我最大的感受不是"效率提升了多少"，而是"脑子里的待办事项少了"。以前总觉得有什么事没做，现在流程替我记着，到点自动跑，有问题再找我。这种感觉，有点像从手工作坊进了工厂——你还是那个干活的人，但你不用再管流水线什么时候开、下一道工序是谁。
我是老三，10+ 年软件开发经验，软件设计师、人工智能应用工程师，专注鸿蒙应用开发（ArkTS）北向开发与 Web 前端，探索 AI 自动化，不定期在 CSDN 分享鸿蒙 / AI 方向技术文章。
本文遵循 MIT 协议，转载请注明出处。
