上篇我把「写JD」从 Agent 里拆了出来，做成第一个 Skill。她用了两周，JD 这块是真省心了。
但新的乱，来了。
一天接三个需求，她直接手忙脚乱。JD 能写，找人呢？筛简历呢？还是手工。
瓶颈不在写，在手上
她的一天是这样的：
早上客户 A 丢来一个 Java 负责人需求，要得急。她让「JD写作」出稿，十分钟搞定，心里还挺美。
中午客户 B 又来了一个，销售总监，薪资范围都没说清。先打电话问，再回来补需求。
下午开始找人。打开猎聘、脉脉、BOSS，一个词一个词地搜，点开一份份简历看。看到晚上九点，眼睛都花了，才筛出五个能进初面的。
晚上十点，客户 C 的需求还躺在微信里没动。
她跟我说：以前一个需求，磨一天也就罢了。三个一起来，人就废了。
我说，这不怪你。
你的 AI 只覆盖了流程的一环——写。剩下的环节，全在你自己手上。
她问：那怎么办？
拆。
我之前没急着给她上流水线。一个 Skill 够用，就别折腾。这回是真不够了，才动手。
拆成四个 Skill，一人一段
我把她的招聘流程摊开看了看，正好四段：
① 需求解析：客户的一堆碎碎念，转成结构化字段。职位、薪资、城市、级别、紧急程度，缺啥主动问。
② JD写作：上篇那个，直接复用。
③ 候选人搜索：按 JD 提炼关键词，去平台捞人，输出候选名单。
④ 简历初筛：把候选人和 JD 逐条比对，打分，给理由。
有人问，为啥不干脆做一个全能 Agent？上篇已经试过了——提示词塞不下，改一处碰坏另一处。一个 Skill 干一件事，坏了只修一段，不连坐。
串起来才是关键。前一步的输出，就是后一步的输入。客户需求进去，四个 Skill 接力跑完，交付一整套：结构化需求、一份 JD、候选名单、初筛结论。
在 WorkBuddy 里，这叫自动化任务：新建一个流程，阶段就四段——需求收集、JD 草稿、合规检查、交付。四个 Skill 各就各位，需求一进来自动开跑。合规检查那步我原打算留给人做，结果还没轮到人上场，AI 自己先断了。
要是用 OpenClaw，就是 Task Flow：每一步是一个后台任务，状态 queued、running、succeeded 清清楚楚，全存 SQLite 里，断了能查是哪一步死的。
数据在里面接力跑，像工厂流水线。焊完车门的，把车门交给装发动机的——交接的是同一张工单。
我挺得意地跟她说：以后你只管丢需求。
然后我们就翻车了。
断在半路的流水线
第一次试跑，前两步顺利得不像话。需求解析出了结构化字段，JD 也写完了，候选人搜索甚至捞回来八个人。
到简历初筛，输出是空的。
我盯着日志看了半天，才明白怎么回事。
候选人搜索输出的字段，叫「姓名」「公司」「职位」。简历初筛读的字段，叫「candidate_name」「current_company」「current_title」。
两边说的是同一件事，字段名对不上。
初筛那步按自己认识的字段名去找，一个都找不到，就当没收到数据，交了个空结果。
我跟你讲，那一刻我脸都绿了。
流水线不是人，不会猜你的意思。它只会照着字段名找东西。名字对不上，就是没数据。
修了两件事：
① 定死数据格式。四个 Skill 共用一张「交接单」，字段名统一，谁写谁读都按这张单子来。搜索输出「候选人姓名」，初筛就只认「候选人姓名」。
② 加中间检查。每两步之间加一道自动化校验，字段缺了、类型不对，立刻报错停住。原来留给人的合规检查，先派 AI 把数据这关守住。宁可断在明处，不让坏数据悄悄往下传。
再跑。通了。
流水线的灵魂，是接口
这件事我琢磨了好几天，越想越觉得有意思。
一开始我以为，流水线就是把 Skill 摆一排，顺序对了就行。
不是。
四个工人站一排，各干各的，中间不传工件，那不叫流水线，叫四个工位。
把 Skill 串起来的不是顺序，是接口——每一步交出去什么格式，下一步接什么格式，白纸黑字定死。
说实话，定这张「交接单」花的时间，比建四个 Skill 加起来还多。但值，太值了。后来她加第五个 Skill，往单子里补两行就行，十分钟的事。
讲道理，工具拆得越细，接口越要先想清楚。不然拆得越多，断得越狠。
下班提前了一小时
跑通之后，她最大的感受不是"AI 好厉害"，是：
下班提前了一小时。
三个需求一起进来，也不用熬到十点了。丢进去，跑，她只干一件事——看结果。
但她又说了句话，让我愣了一下：
"JD 我不敢直接发客户。"
流水线是通了，可没人把关。AI 写的 JD、AI 筛的简历，她总得自己过一遍，才敢往外发。
这一步，还是人工。
所以下一篇，我要给这条流水线配个「质检 Agent」——把"检查"这件最费眼神的事，也交给 AI。
你工作中哪条流程最值得串成 pipeline？评论区聊聊，我看看大家最想先把哪条线跑起来。
