上个月我还在用 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 协议转载请注明出处。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
