这家创业公司保留了 Claude 和 Codex，把文档工作交给本地 AI

一位开发者让编程智能体修复服务中的 bug。智能体首先要找到原工单，查阅几项产品决定，弄清哪些需求仍然有效。补丁完成后，还得有人把后续工作整理成设计师或客服负责人看得见的工单。改代码只是整个过程的一部分，却可能全由同一个付费模型来做。

不到 40 人的软件公司 Grayhat Developers 在 2026 年 11 月 5 日的一篇预印本中介绍了把这些工作分开后的情况。团队曾用自托管模型做开发，发现替换商用编程智能体后，一些仓库任务变慢或更难了。团队因此保留商用智能体处理复杂改动，把部分文档检索、准备工作和工单同步交给本地服务。

另一个小团队可以先搬走哪一项工作？Grayhat 的经历提供了一个具体起点、一组值得拆开看的估算，以及一个可能让试验在接触模型质量之前就失败的上手问题。

修 bug 还没碰到代码，就要先花时间找背景

Grayhat 用 Outline 管理文档，用 Plane 跟踪工作，用 ERPNext 管理组织信息。这些服务原本就运行在办公室的一台机器上，并通过 Authentik 接入身份认证。团队把模型上下文协议（MCP）连接器也部署在同一台机器上，另用一台机器负责模型推理。分开部署的目的很实际。模型工作进程在别处消耗算力时，文档和工单系统还能照常提供界面。

论文中的流程有人参与交接。同事使用内部模型从知识库或问题跟踪器取回材料并做摘要。相关内容可以放进仓库文件，交给编程智能体。完成仓库里的工作后，同事可以把后续步骤带回内部助手，生成工单草稿并发到跟踪器。论文把智能体之间直接通信列为未来方向。目前，人已经能看到跨越边界的信息，并决定哪些内容可以交给另一边。

Grayhat 工作流中的交接点。Telli.sh 根据 11 月 5 日的案例原创绘制。

假设客户报告导出结果有重复行，原始报告里包括私密的账户标识和与缺陷无关的对话记录。本地助手可以找到最新的导出规则、服务负责人和之前的临时办法。工程师再写一份简报，加入合成数据示例和预期行数。编程智能体拿到复现所需的信息。因为由人决定传递什么，敏感资料仍留在内部系统。

把原始链接附在内部草稿上。需求冲突时，审核者就能看出规则源于近期决策，还是过时的临时措施。本地生成的摘要如果把来源丢了，仍会制造另一种需要解决的问题。接手的同事不得不重新判断哪个说法可信。

团队购买了用量，并估算其中多少工作可以转移

作者报告，商用 AI 基线成本约为每月 325 美元，包括七个 Claude 席位约 175 美元、七份 Codex 订阅 140 美元，以及 10 美元额度。团队还报告各服务记录了超过 259.3 亿个词元。论文没有证明这批词元与 325 美元对应同一个账期。每个数字应按各自代表的内容使用，不能直接相除来推算词元单价。

Grayhat 估计，上下文传递、文档和项目协调占商用 AI 工作量的 30% 至 40%。作者推测，本地系统可以承担其中约 90%。两者相乘，得到商用工作量的 27% 至 36%。按 325 美元基线折算，相当于每月约 88 至 117 美元。工作量和成本等值都是 11 月 5 日案例中的估算。论文没有做受控的前后账单实验。

Grayhat 从工作量占比推算成本等值。Telli.sh 原创图解。

按席位计费时，这个区别格外重要。如果七位开发者仍然需要订阅来处理复杂工作，用量下降可能不会改变下一张账单。收益可能体现为有余量做另一批补丁、较少触碰限额，或减少额外购买。按请求计费的团队也许更早看到变化，但反复重试和排队会抵消部分表面上的节约。必须购买新 GPU 或请人维护时，这些支出也要算进去。

选择一个可以审查的分母。草稿数容易数，但项目负责人如果每张工单都要从头重写，就难以证明节省了什么。记录通过审核的简报和工单，以及改变任务含义的编辑。等审核者能用一致标准判断合格，再量化每件合格产出需要多少工夫。

第二套界面改变了由谁完成配置

首次上线时团队采用 LobeHub，给工程师发了说明，让他们自己把界面接到组织内部工具。作者说，演示看起来不错，日常用起来的人却不多。每个人都得知道用哪个连接器、到哪里找、如何认证。多一个选择，离第一次得到有用答案就远一步。

Grayhat 的第二套界面集中配置了工作工具。出自 Saad Ahmed Bazaz、Talha Amjad、Abdurrehman Subhani、Sohaib Ahmed Bazaz 与 Abdullah Aamir 的《Create Your Own Work Stack》图 2，CC BY 4.0。

团队改用集中配置的 LibreChat。用户可以看到配好的工具，并在访问时认证。作者从首版的 11 次结构化访谈中统计到 8 条有关配置和上手的意见。第二版则通过非结构化的 Discord 反馈收到同类意见 3 条。两组数字的采集方式不同，可以帮助定位上手问题，却不能说明采用率上升了多少，或者有多少人不再遇到问题。

用最小的真实任务设计首次体验。项目负责人登录来查某个问题的验收标准，应该看得见跟踪器是否已连上，以及哪个账户在用。工程师要起草三张工单，应该能在发布前审查。要是团队先教大家怎么设置连接器，才能让人找到自己的工作，试验测到的可能只是耐心。

集中配置带来了新的责任。需要有人维护批准使用的连接器清单，轮换凭据，说明谁有权改权限。否则，一个人的配置错误可能变成所有人的问题。它的好处是，反复出现的设置问题只要修一次，同一服务的使用者都能得到修复。

把产出责任明确的任务交给本地系统

工单分流是务实的起点。内部助手可以把相似报告放在一起，带着原工单链接给出摘要建议。项目负责人决定两项报告是否真的重复，合并后的描述有没有漏掉某个条件。助手可以起草一条说明分类理由的评论。更新由谁负责看得见，人也就知道发生了什么。

文档维护是另一种任务。假设某个设置从一个页面移到了另一个页面，助手可以找到过时的帮助文章，识别适用的产品版本并起草修改。编辑核对当前的导航路径，再发布正确的内容。如果难点是访问最新的内部页面并维持文章原有范围，能力更强的远程模型也未必能多做什么。

复杂开发则是反例。一次数据库迁移可能要查明历史数据契约、修改多个服务并验证回滚。Grayhat 测过的本地方案在规模较大的仓库任务上表现吃力，尤其是需要较宽上下文和及时推理时。研究描述的是这支团队的设备、模型和经验。扩大分工前，可以先用自己的工作量试一遍。

如果任务混有简单格式转换和敏感数据，就使用受限的路径。原工具在本地运行，把草稿发到网络外面也仍可能泄露信息。必须向外部交接时，应先批准目的地，再为该处生成最小必要材料。内部结果未获批准时，就留在内部审核队列。超时应显示错误，不能意外触发外发。

用短期试验分清有效工作和基础设施杂务

1. 定义三类产出。 选一份带链接的工单简报、一项文档修改和一张问题草稿。分别写清谁验收、需要什么证据。除了好样例，也保留一份包含容易忽略错误的失败样例。
2. 测量现有流程。 用一个正常工作周记录完成件数、实质性修正和查找上下文用时。能按工作流记录商用使用情况就这样做。注明转走这些任务是否真的会改变付费席位数或超额支出。完全没做的事另行记录。
3. 连接一个内部工具。 从一个明确的项目和只读权限开始。确认授权员工能检索到已知问题，项目之外的人不能。只让少数原本就在做这类工作的人参与，并在工具失败时提供清楚的手工完成途径。
4. 先比较草稿，再开放写入。 让同一位审核者按同一标准接受或拒绝产出。记录链接指错工单、事实过时和结论缺乏依据等问题。给助手更新真实跟踪器的权限之前，加入预览、审批和可长期查阅的记录。
5. 检查实际转移了什么。 比较合格产出、审核时间、活跃使用和真实账单。加入设备维护、停机和连接器变更的时间，也计入直接给用户的配置帮助。每个人都要请专家指导十分钟才能上手，成本依然存在。

如果本来就在给开发者运行本地模型，就让试验与正常流量同时进行。几个人同时开始时会出现排队，一个提示词处理得快也可能让另外三人等待。给时效性强的工作提供进度提示和回到正常手工流程的入口。这样团队了解工作适配度的同时，试验也能继续用。

Grayhat 的附录提供了一个比较尺度。工具机器使用 16 GB 系统内存，独立推理机器有 32 GB 内存，以及配备 16 GB 显存的 RTX 4080。团队称，随着运行需要变得清晰，又加入了网络监控、调度和不间断电源。这些是试验预算的参考，也是运行一个同事要依赖的服务所需要考虑的事情，和单次模型回答成本不同。

决定下一小时的 AI 工作该放在哪里

可以复用的做法，是将上下文准备与专业推理分开，并为每次交接确定负责人。从经常重复、团队已经知道如何审核产出的任务开始。测量接受产出需要的工夫，再决定是否把另一项任务转到本地。Grayhat 的做法让团队能这样判断，同时继续保留仍有价值的编程工具。

来源

• Grayhat Developers 预印本，2026 年 11 月 5 日
• 论文全文，包括工作量估算、基础设施与图 2
• 图 2 原图
• 论文图片的 CC BY 4.0 许可

---

想让交接背后的讨论能在日后查到，可以创建 Telli.sh 账户。