多部门不是把同一个工具买七遍七个部门一套底座，新的工作内容配一个 Agent 就能接上
覆盖部门
财务 · 人事 · 研发 · 销售 · 电商 · 设计 · 门店
交付含
提示词库 + 到场陪跑
新的工作内容
配一个 Agent 接上
报价方式
按部门范围核定
你现在卡在哪
试点做成了，然后就推不动了
各部门各买各的
财务买了张票据识别，人事买了个简历筛选，电商用着另一家的客服机器人。每一个单看都还行，合起来是七份对不上的数据和七笔按人头的月费——而部门之间那段最费人的搬运，谁也没接走。
试点做完就停住了
一个部门做成了，第二个部门不认：数据不一样、规矩不一样、人也不一样。于是每个部门都得从零谈一遍，第三个部门那时候预算的耐心已经耗光了。
IT 排期排到明年
业务部门想到一个能省半天的小东西，提上去、排期、等。等到做出来的时候，那件事的做法已经变了。真正的瓶颈不是开发能力，是「每一件小事都必须经过同一个队列」。
这三条指向同一件事：缺的不是某个部门的工具，是一层能被所有部门共用、而且业务自己能往上加东西的底座。
七个部门
每个部门接走什么，留下什么
财务
- 发票、单据、对账单抽取入表
- 两边数据自动比对，只把对不上的那几条推给人
- 费用合规预审：超标、缺票、重复报销当场标出
- 应收账龄与回款提醒，按客户分级催
- 月结数据汇总与报表草稿
留给人：付款与放账的批准、税务口径的判断、差异是录错了还是真出事了——一件都没交出去。
人事
- 简历初筛与信息结构化，按岗位要求排序
- 面试安排与候选人状态同步
- 入离职手续清单自动派发，各部门各收自己那一条
- 考勤与假期异常自动挑出
- 制度问答：假期怎么算、报销怎么交、社保怎么补
留给人：录用、定级、绩效、谈话，以及涉及人的例外——人事这一摊几乎全是例外，那部分留在人手里。
研发
- 需求与反馈收敛成工单：归类、去重、关联到已有模块
- 技术文档与接口说明随代码更新
- 代码与配置初稿、测试用例、迁移脚本
- 故障日志聚类，翻出相似的历史问题与当时怎么解的
- 发布说明与变更记录自动成稿
留给人：架构决策、技术选型、取舍排序、线上故障的定性与回滚——评审这一步一分钟都没省。
销售
- 线索整理、去重与打分排序
- 客户背景资料自动汇总成一页纸
- 个性化首轮触达，不是群发模板
- 跟进节奏管理，不再有忘记跟进
- 报价单与合同文书起草
留给人：谈判、让价、关系维护，以及最后签出去的那一版报价——对外承诺永远由人按发送键。
电商业务
- 商品上新管线：成稿 → 配图 → 上架，人工只做终审
- 多语种内容与术语同步
- 客服首轮应答，答不上来转人工
- 订单异常与站点健康度自动预警
- 投放与站内数据归集成一张看板
留给人：定价、活动、渠道策略，以及客诉里需要让步的那一类——机器不替你做让步的决定。
设计开发
- 产品图批量重绘、去背、换场景、统一光影
- 主图 / 详情 / 社媒多尺寸一次导出
- 场景效果图与短视频素材批量生成
- 按品牌视觉规范锁定风格，整批不跑偏
- 素材归档与按属性检索，找图不再靠翻文件夹
留给人：定视觉规范本身、每批挑片、实物拍摄——机器只能执行规范，不能定规范。
门店管理
- 每日营业数据汇总与异常提示：客流、成交、退换
- 到店接待记录结构化，跟进任务自动派到人
- 样品与库存盘点清单、调货申请自动流转
- 巡检照片与整改项归档，逾期自动提醒
- 导购随时能问的产品知识与话术，答案带出处
留给人：现场接待与议价、排班裁量、陈列与活动的决定、投诉的现场处理。
不必七个都做。多数合作从其中一两个部门起步——底座只建一次，所以从第二个部门开始会明显轻， 但先做哪个、要不要做第三个，用第一个部门跑出来的记录决定，不用现在拍。
这条线的差异点
有了新的工作内容，就可以给它配一个 Agent
先把这个岗位每天做什么讲一遍
不用填表单，用大白话讲清楚就行：什么时候开始、要看哪些数据、按什么规矩处理、结果交给谁、哪一步需要人点头。讲得顺，这个 Agent 就立得住；讲的过程中卡住了，往往说明这件事本身还没定型——那更值得先聊聊，而不是急着上。
在平台上把它配起来
触发条件、数据来源、处理规则、出口与人工卡点，在界面上逐项选，不需要写代码。业务数据在交付时已经接好，新的 Agent 直接复用同一套接口，你们自己的人就能配。
先陪它跑一段
刚配好的 Agent 默认只给建议、不动真数据。跑几天，看它的判断准不准、有哪些情况还没想到，调顺了再放开写入。这一步是默认打开的——先看准，再放手，对谁都轻松。
上线，并留下记录
谁配的、什么时候配的、改过几版、每一次做了什么，都在运行记录里。哪个 Agent 判断得不对，回头查得到，也随时可以先停下来调——比「配得快」更要紧的是心里有底。
哪些适合你们自己配，哪些值得我们一起看
自己配就很顺手的
有明确触发、规则讲得清、出口也明确的那类活儿——查、比、整理、起草、提醒、按规矩分派。部门日常里最占时间的大多是这些，配起来通常一两个小时的事。
值得一起看一眼的
要接一个还没接过的外部系统，或者想要平台目前还没有的能力。这类不是不能做，只是超出了配置能覆盖的范围——我们会一起评估怎么做最省，范围与计价在动手前谈妥。
还有一条默认就开着，我们也建议一直留着：新配好的 Agent 先只给建议、不动真数据，跑一段时间确认判断稳了再放开写入。 先看准、再放手，上手的人心里有底，这件事才铺得开。
提示词工程
既是交付物，也是我们到你公司陪跑的一段
岗位提示词库
按部门、按岗位整理成册：每一条写明用在什么场景、要喂什么信息、输出长什么样、什么时候更适合交给人。交付时进你自己的仓库，跟源码放在一起，随时可查、可改。
教的是改法，不是模板
我们希望你们的人看懂「这句话为什么这么写」——哪一段是角色、哪一段是规矩、哪一段是不能动的边界。看懂了，日常的调整自己就顺手做了；真遇到拿不准的，再一起看。
陪着跑一段，线上就能跑完整
按部门分场，拿他们手上当天真实的活儿当例子，一起写、当场跑、调到能用——共享屏幕就能做，不必为它专门安排出差。需要看现场作业的场合我们也可以到场。第一轮之后还会跟一段时间，等各部门自己转起来了再退到后面。
留一份能自己维护的规矩
命名、版本、谁能改、改完谁复核。有了这一层，半年后翻出来还认得出哪条该用；没有它，提示词很容易越攒越乱——这是我们见得最多的一种慢性问题。
这一档可以单独计，也可以并进项目里一起谈。范围、场次与陪跑的时长在诊断阶段定—— 按部门分场，一个部门一场，人数不宜太多，因为每一场都要拿他们手上真实的活儿现场写。第一轮结束后我们会再跟一段：各部门真正转起来了，我们再退到后面。
先说不做的
这条线不包含什么
不替代你现有的业务系统 ERP、OA、人事、仓储仍是各自数据的主人，这一层叠在上面。
不替你制定制度与流程 规矩得你定。流程还在天天变的部门，我们会建议先别动它。
不做代管 系统跑在你自己的服务器上，源码与数据都在你手上。需要我们搭把手的时候，开权限、办完事、再收回。
不承诺减编制 这套东西划走的是动作，不是人。我们也不建议把「减 N 个人」写进项目目标。
不含法务与合规审查 入库内容、对外文案的合规判断由你的法务把关。
不含 7×24 值守与 SLA 关键业务需要值守的，范围与计费在诊断阶段单独谈，不含在标准交付里。
你会拿到什么
交付清单
跑起来的部门 Agent
交付当天就在产出，不是待调试的半成品。先交的那个部门不必等后面几个。
统一知识库与权限
制度、话术、产品资料与业务数据收拢成一份，答案带出处、权限跟着组织走。它是这条线的地基，含在交付里，不另计。
平台与全部源码
平台这一层是我们自己写的，源码、数据库结构与文档一并进你的仓库。底座是标准技术栈，招得到人。
提示词库 + 现场陪跑
按部门成册，加上到你公司分场的那几天，以及之后跟着的一段——等各部门真正转起来了我们再退到后面。
运行记录与运维手册
每一次触发、每一次人工确认都入表，可查可导出；手册写的是我们踩过的坑。
关于报价：按部门范围核定，不挂标价—— 同样是「财务这一块」，有现成接口和只能导表格，工作量能差三倍。 先做一次诊断，结束时你拿到的是按你自己情况排好的部署清单：先做哪个部门、要接几个系统、各自落在哪一档，都是确定的。
常见问题
推这件事的人通常会问的几个问题
七个部门一起上，会不会太重？+
会，所以我们不建议一起上，实际也很少这么做。通常先挑一个部门——挑的是重复量最大、而且做错了能改回来的那个，多数企业是财务的对账或者电商的上新。第一个部门顺起来之后，你手上会多两样东西：一份真实的运行记录，和一批愿意帮你说话的同事。第二个部门是拿这两样去推的，比拿方案书顺得多。底座只建一次，所以后面几个部门会明显轻一些；具体轻多少，等第一个部门的记录出来再说，我们不先给数字。
我们已经有 ERP、OA、人事系统了，这套会不会打架？+
不会，它是叠在上面的一层：从那些系统里读、把结果写回去，中间原本靠人搬运的那一段由它接走。那些系统仍然是各自数据的主人，我们不去动它们。员工那边也不用多记一个入口——需要人拍板的那一步，会推到他本来就在用的沟通工具里。唯一需要提前看清楚的是接口：哪些系统开得出接口、哪些只能靠导表对接，这在诊断阶段一项一项过，看清楚了再报价。
岗位 Agent 是不是最后没人会配？+
这确实是这类平台常见的结局，所以我们把它当成交付的一部分来做，而不是给你一个界面就算完。一是刚配好的 Agent 默认只给建议、不动真数据，试错没有代价，人才敢上手；二是交付时我们和你们的人一起配两三个真实的——用他们自己部门手上的活儿配。自己配成过一个的人，后面基本不用再教。之后也不是就断了：日常的增减你们自己顺手做，遇到拿不准的随时找我们看一眼。
以后想加东西，是不是每次都要重新立项？+
日常那些不用。在平台上配一个岗位 Agent、改规则、调话术、补知识库，这些你们自己就能做，也是我们希望你们能自己做的——毕竟每加一件小事都要等排期，这套东西的意义就少了一半。确实需要单独谈的是另一类：接一个还没接过的外部系统，或者要平台目前还没有的能力。这类我们会一起评估怎么做最省，范围和计价在动手之前谈妥，不会等你先撞上去。
提示词这一项，发一份文档不行吗？+
文档我们照给，但只发文档效果确实有限——我们试过。业务同事卡住的地方往往不是「看不懂模板」，而是「我手上这件事该怎么写成一条」。所以那几场都拿他们当天真实的活儿当例子，当场写、当场跑、当场调到能用——共享屏幕就够，不必为它专门安排出差。一个人亲手把自己每天做三遍的事变成一条能用的提示词之后，后面就顺了。第一轮之后我们还会跟一段时间，等各部门真正转起来了再退到后面——这一档是按「陪跑」安排的，不是讲完就走。
数据会不会出内网？+
系统装在你自己的服务器或私有云里，业务数据、知识库、运行记录都留在你的边界内，不经过我们的设施。模型这一层可以选：调用外部接口，或者用本机部署的开源模型——后者的推理也留在你自己控制的服务器里。合规上有要求的就走后者；换过去主要是配置工作，但要用同一套测试集重跑评估、确认达标再上线，提示词通常也要重调一轮。财务和人事这两块最常触发这条要求，所以我们习惯在诊断阶段就把它定下来，免得临近上线才发现。