字节笔记本
2026年9月24日 · 约 11 分钟读完
豆包负责干活，Jev 决定往哪走：一张发票的办公自动化
如果要找一个最适合 Jev 和豆包工作结合的办公场景，我会选发票审核。
这个场景足够具体，而且每天都可能发生。
从一张 128600 元的发票开始
假设上午，财务邮箱收到一封供应商邮件。
附件里是一张 128600 元的发票。对方在邮件里说明，希望当天安排付款，同时提醒这次的收款账户已经发生变化。
豆包工作先接手这封邮件。
它读取邮件内容和附件，然后去公司已有的资料里寻找对应的采购单、合同、供应商信息和过去的付款记录。
很快，几个问题就出现了。
原合同金额是 120000 元，这次发票金额是 128600 元，多了 8600 元。
供应商原来登记的收款账户尾号是 8821，这次发票上的账户变成了 3476。
过去几次付款中，这家供应商没有出现过账户变更。
到了这里，豆包已经把相关材料找齐，但还不能直接进入付款流程。
Jev 在这个节点介入
它不需要重新生成一篇总结，而是直接对当前资料做判断。
例如：
发票金额是否与现有采购依据一致 否 0.99
收款账户变更是否需要额外核验 是 0.98
当前是否满足付款条件 否 0.99
建议处理状态 暂缓付款
判断完成以后，豆包工作继续往下处理。
它找到原采购合同，把 120000 元和本次 128600 元的差异整理出来。
接着查询供应商档案，把原收款账户和本次新账户放在同一份记录里。
然后生成一封给供应商的邮件，要求对方补充 8600 元的费用依据，同时提供正式的账户变更证明。
财务台账里的付款状态也会同步调整为"待核验"。
与此同时，这笔采购的负责人会收到一个待办，要求确认新增的 8600 元是否已经走过内部审批。
整个过程里，财务人员不需要先自己翻合同，再查历史付款记录，最后手动判断这张发票到底哪里有问题。
豆包工作负责把分散的信息找回来，并继续完成后续操作。
Jev 负责在关键节点给出结构化判断。
第二天，如果供应商补回了账户变更证明，同时提供了新的采购补充单，豆包可以再次把这些资料整理出来。
Jev 重新判断后，结果可能变成：
金额是否已有采购依据 是 0.98
账户变更是否已有有效证明 是 0.96
内部审批是否完整 是 0.94
是否可以进入付款流程 是 0.93
这时豆包再把这笔记录从"待核验"调整为"待付款"，整理好材料，交给财务人员做最后确认。
但缺了一块：怎么把 Jev 接进来
前面写 Jev 和豆包工作的时候，我一直觉得少了一块。
到底怎么把 Jev 接进去？
研究了一下以后，实际做法比想象中简单。目前豆包工作没有现成的 Jev 连接器，最快的方法是自己做一个 Skill。
TypeSafe 已经开放了 Jev 的 HTTP API，请求地址就是：
POST https://api.typesafe.ai/v1/systemone所以不需要改豆包工作本身。
我准备先做一个「发票审核」Skill。
目录很简单：
invoice-review/
├── SKILL.md
└── scripts/
└── jev-review.sh先在 TypeSafe 后台创建 API Key，然后放到电脑的环境变量里：
export TYPESAFE_API_KEY="你的 Key"Key 不写进 Skill，也不要放进提示词。
接下来真正重要的是 jev-review.sh。
它接收豆包整理好的发票信息，然后直接调用 Jev：
curl -s https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "jev-latest",
"state": "'"$1"'",
"questions": {
"amount_match": {
"type": "noul",
"instructions": "发票金额与采购单或合同金额一致"
},
"bank_changed": {
"type": "noul",
"instructions": "本次收款账户与已备案账户不同"
},
"action": {
"type": "choice",
"instructions": "根据当前资料选择下一步处理方式",
"criteria": {
"pay": "资料完整，可以进入付款流程",
"hold": "资料存在缺失或差异，暂缓付款",
"approval": "需要额外内部审批",
"review": "存在明显异常，需要人工复核"
}
}
}
}'Jev 官方支持在一次请求里同时放 Choice、Score 和 Noul，而且这些问题会针对同一个 state 独立判断。返回的也不是一篇文字分析，而是可以直接被程序读取的 JSON。
接下来写 SKILL.md。
这里不需要告诉豆包 Jev 是什么，只要把工作过程写清楚：
---
name: invoice-review
description: 当用户要求审核发票、付款申请或供应商账单时使用
---
收到发票后：
1. 读取发票中的供应商、金额、银行账户、发票号码。
2. 查找对应合同、采购单和供应商备案资料。
3. 整理成统一文本。
格式：
供应商：
发票金额：
合同金额：
采购单金额：
本次银行账户：
备案银行账户：
是否存在补充协议：
当前审批状态：
4. 调用 scripts/jev-review.sh，把上面的完整文本作为参数传入。
5. 读取 Jev 返回的 answers。
当 action.choice 为：
pay：
整理付款资料，但正式付款前要求用户确认。
hold：
找出缺失材料，并生成向供应商索取资料的邮件草稿。
approval：
说明需要补充的内部审批，并创建待办。
review：
停止自动处理，把异常项目整理给用户确认。
如果 action.confidence 低于 0.7，不自动执行下一步。然后把整个文件夹打包成 ZIP。
进入豆包工作：
技能 · 连接器 · 伙伴 → 新建 → 上传技能
把这个 ZIP 上传进去就可以了。豆包工作现在已经支持上传自定义 Skill，也可以通过对话创建自己的 Skill。
跑起来是什么样
假设财务收到了一张 128600 元的供应商发票。
直接对豆包说：
"审核一下这张发票。"
豆包先按照 Skill 打开发票，再去指定目录找到合同和采购单。
最后整理出来：
供应商：XX 云服务公司 发票金额：128600 合同金额：120000 采购单金额：120000 本次银行账户：尾号 3476 备案银行账户：尾号 8821 补充协议：没有 审批状态：正常采购审批已完成
这段内容直接传给 Jev。
返回结果可能是：
{
"amount_match": {
"noul": 0.01
},
"bank_changed": {
"noul": 0.99
},
"action": {
"choice": "hold",
"confidence": 0.96
}
}豆包看到 hold 以后，就按照 Skill 继续处理。
它不会提交付款，而是把 8600 元差额和银行账户变化整理出来，生成一封要求供应商补充材料的邮件，同时把财务台账状态改成"待核验"。
第二天供应商补回追加采购单和账户变更证明。
再次运行同一个 Skill。
这次 Jev 返回：
{
"amount_match": {
"noul": 0.98
},
"bank_changed": {
"noul": 0.99
},
"action": {
"choice": "pay",
"confidence": 0.94
}
}豆包再继续整理付款材料。
为什么不做成 MCP 连接器
这里有个细节很重要。
豆包工作虽然支持"新建自定义连接器"，但目前这个 HTTP 连接器入口主要面向 MCP 服务，并不能简单把 TypeSafe 的普通 REST 地址填进去就完成接入。现阶段如果只是自己使用 Jev，没有必要先开发一个 MCP Server。
直接放进 Skill，用脚本调用 TypeSafe API，会少很多中间工作。豆包工作目前的自定义连接器确实支持 HTTP MCP 和本地 STDIO 服务，如果后面要给整个公司使用，再把 Jev 包成一个内部 MCP 服务会更合适。
TypeSafe 自己也提供了 Agent Skill，里面已经写好了 Jev 的三种问题类型、API 使用方式和设计原则。官方针对其他 Agent 的安装方式是：
npx skills add typesafe-ai/skills --skill typesafe-ai所以开发这个豆包 Skill 时，甚至可以把 TypeSafe 官方的 Skill 当作参考，让 Agent 帮你生成调用代码。
我特意没有写成"直接把 Jev URL 填进豆包自定义连接器"，因为那样其实不严谨：豆包的 HTTP 自定义连接器目前走的是 MCP，Jev 暴露的是普通 REST API。现阶段最容易真正跑通的就是：豆包 Skill → 本地脚本/curl → Jev API。
收尾
这样 Jev 才算真正进入了豆包工作的流程。
用户仍然只需要说一句：
"帮我审核这张发票。"
后面的资料读取、Jev 判断和状态处理，都固化在 Skill 里面。
跑通发票以后，再把同一套方式复制到合同审核、报销审核或者客户邮件分类里，就不需要重新研究怎么接 Jev 了。
