一名业务人员和 AI，如何完成一套企业 AI Token 平台

过去开发一套企业内部系统，通常要经过一条很长的链路。业务部门提出需求，产品经理整理方案，几轮会议确认边界，后端设计接口和数据表，前端根据原型实现页面，测试人员准备用例，最后再进入联调和验收。每个环节都有明确分工，也意味着信息要在不同角色之间不断转述。一个需求即使本身并不复杂，也可能因为排期、沟通和返工经历数周甚至数月。

这次项目走了另一条路。

项目要解决的是真实企业需求：公司希望统一管理大模型渠道和 API Token，为员工分配独立密钥，按个人和部门统计用量与费用，控制额度，在员工离职时及时停用访问，并让 Claude Code 这类 AI 编程工具能够通过企业网关运行。它不是为了展示 AI 能写代码而临时搭建的样品，而是一套需要在企业内部实际使用的软件。

本文讨论的范围也只限于纯软件类企业开发，包括企业管理系统、Web 平台、SaaS 业务、数据应用、API 集成和内部工具。这些项目的需求、代码、配置、数据结构、测试和文档都可以被数字化表达，开发过程能够在计算机环境中形成完整反馈。芯片、硬件、嵌入式、工业控制以及必须依赖物理环境验证的工程不在本文判断范围内。

这个项目最值得记录的地方，是它的第一版并非由传统开发团队完成，而是由一名纯业务人员借助 AI 搭建。第一版当然粗糙，代码结构、视觉细节和异常处理都谈不上成熟，但它已经形成了一套逻辑自洽的产品原型：用户能够登录，系统里有员工和部门，有个人 Token、模型渠道、用量与费用，还有一个能够调用 Claude Code 的浏览器工作台。

这件事改变了后面的全部开发方式。过去业务人员通常先制作流程图、表格或静态原型，再把想法交给开发人员翻译成系统。这里的业务人员直接交付了一个可以运行的软件。需求不再只存在于会议纪要和页面标注中，而是落实成了真实的数据流、交互和代码。后续工作也不再是从零猜测业务想要什么，而是面对一个已经跑起来的版本，分析哪些设计成立、哪些边界需要加固，然后持续迭代。

从能运行的原型开始，而不是从需求会议开始

项目最终包含两个代码仓库：ai-token-manager 和 studio。它们看起来是两个应用，实际是同一套产品的两面。

Token Manager 负责企业控制面和模型数据面。飞书身份、员工与部门、个人 API Key、上游渠道、模型路由、协议转换、额度、用量、费用、告警和审计都属于它。Studio 负责用户侧的本地 AI 编程体验。它把 Claude Code 的运行过程放进浏览器，让用户选择工作目录、发起任务、查看思考与工具调用、批准文件修改、恢复会话、配置 MCP 和 Skills。

两边的边界可以概括为：Token Manager 管“谁能用什么模型、可以用多少、最后如何记账”，Studio 管“Agent 在本地怎样工作、怎样与用户交互”。真正执行任务的 Claude Code 不需要理解企业部门、账单或飞书组织；它只接收 Studio 投影出来的标准模型地址、凭证、模型和运行配置。模型请求经过 Token Manager 记录一次用量，Studio 展示运行过程，但不重复提交账单。

这个边界并不是第一版原型自动形成的。开发开始后，AI 首先对两个仓库做了系统性的静态分析。认证从哪里进入，Token 怎样保存，Proxy 怎样选择渠道，usage 在什么时机落库，Studio 的会话如何恢复，工具审批怎样与一次运行关联，这些问题被逐个沿着代码路径检查。分析结论再写入 CONTEXT.md、DEPLOYMENT_CONTEXT.md、实施计划、协议兼容报告和问题记录。

文档在这个过程中不再是开发前写完、随后很少更新的形式材料。每一轮开发都会先记录现状、范围、风险和验收条件，完成后再补充实际验证结果和工程决策。AI 既读取文档形成上下文，也在实现后维护文档。需求、代码、测试和交接记录因此处在同一条迭代链路里。

最初几天的工作很好地说明了这种方式。Studio 在 7 月 27 日已经能够通过 React、Node 和 WebSocket 驱动 Claude Agent SDK，把回复、thinking 和工具调用显示成卡片。Token Manager 在 7 月 28 日也已经具备飞书登录、管理后台、渠道、额度、告警和代理服务。如果沿用传统开发习惯，很容易从页面上继续补功能。但静态分析首先发现，真正需要处理的是系统地基。

Token Manager 的 Compose 会启动两个 Proxy 实例，部分数据和会话逻辑却仍保留文件数据库或进程内状态的思路。单实例时这些实现都能正常工作，请求一旦在两个 Proxy 之间轮询，会话、限频、渠道和用量就可能看到不同结果。这不是再增加几个接口可以解决的问题，而是原型运行模型与企业部署模型之间的根本差异。

第一轮重构因此没有从界面开始，而是把数据后端切换到 MySQL 8，把登录会话、分布式限频、渠道配置修订和用量投递接入 Redis。Web 和每个 Proxy 使用有界 MySQL 连接池，两个 Proxy 放在 Nginx 后面轮询。验证时不仅运行 TypeScript 编译，还实际检查 MySQL、Redis、容器健康、请求轮询和单实例停机后的流量切换。

完成迁移后，项目又删除了 sql.js、文件数据库路径、驱动选择和进程内降级，一次移除四千多行代码。表面上看，Vibe Coding 最擅长快速增加代码；这次开发却很早证明，AI 同样可以帮助识别哪些代码不应该存在。生产环境既然要求多实例一致性，继续保留一套无法满足这一约束的单机后端，只会制造一种虚假的灵活性。

真正复杂的不是页面，而是协议和运行状态

数据库稳定以后，Token Manager 面临的下一个问题是模型协议。早期 Proxy 主要提供 OpenAI Chat Completions，这对普通聊天调用已经够用，但 Claude Code 原生使用 Anthropic Messages，Codex 使用 OpenAI Responses。编程 Agent 发送的不只是文本，它们还包含 thinking、工具调用、结构化输出、流式增量和不同格式的 usage。

把所有请求都转换成 Chat，可以快速跑通简单对话，却会在工具和推理语义上不断丢失信息。网关因此被改造成三种客户端协议与三种上游协议之间的 3×3 路由矩阵。OpenAI Chat Completions、OpenAI Responses 和 Anthropic Messages 可以原生直通，也可以互相转换。渠道配置随之增加协议、鉴权方式、公开模型到上游模型的映射、能力声明、超时和转换策略。路由器不再只看模型名称，而是同时判断入口协议、公开模型和能力要求。

协议转换的第一版形成得很快。AI 根据现有结构拆出请求准备、能力判断、上游分发、非流响应和流式状态机，补上九条请求与响应路径以及六条跨协议 SSE 路径。文本、thinking、tool call 参数拼接、Anthropic content block 生命周期、Responses output index、终止事件和 usage 都进入了统一结构。

如果只看代码量，这时已经很像“功能完成”。项目没有停在这里，而是继续用白盒方式把 TypeScript 实现与成熟开源项目的转换器、状态机和 golden fixture 逐项核对。核对很快发现，路由数量完整不代表协议语义完整。Claude 与 Responses 如果都借道 Chat，中间格式会损失专有字段；Responses 的状态字段、媒体和结构化输出需要更明确的转换；Anthropic thinking、缓存和 usage 也不能只做表面字段替换。

转换层随后被进一步拆细，为不同方向增加有类型的专用桥，并加强 reasoning 与流式事件处理。真实 GLM 调用又发现两个静态检查没有暴露的问题：一处注册表把响应转换方向写反；另一处 Responses 的命名工具选择送到 Chat 上游时结构不符合供应商要求，GLM 直接返回 HTTP 400。修复后，普通平台 Token 经负载均衡完成了 Chat、Responses、Anthropic 的流式与非流式请求，以及 count_tokens 和强制工具调用。数据库能够保存入口协议、上游协议、转换路径、状态与 usage，两个 Proxy 实例都实际处理过请求。

Studio 的难点与网关相似，也不在页面本身，而在长时间运行的状态。第一版已经能调用 Agent SDK，却没有严格回答几个问题：工具调用和结果怎样稳定关联，一次运行如何保证只有一个终态，审批超时或 WebSocket 断开后怎样清理，服务重启后怎样恢复 Claude 会话，中断后的迟到事件是否还能修改当前界面。

7 月 29 日以后，原先集中在一个 SDK Bridge 中的逻辑被拆成 Query Runner、事件桥、工具跟踪器和审批管理器。Query Runner 管启动、中断、失效事件抑制和清理；事件桥处理文本、thinking、工具与 usage；工具跟踪器使用 tool_use_id 把 pending、approved、running、done、error、denied、cancelled 串成同一张卡的生命周期；审批管理器负责 ID 映射、超时、重复响应、AbortSignal 和断线清理。

Claude session ID、累计用量和最后运行状态写入本地存储。服务重启后，遗留的 running 状态会被转换为 interrupted，界面不会继续显示一个已经不存在的任务。发送消息前同步扫描完整工作目录的旧逻辑也被移出热路径，避免项目越大，用户等待越久。

真实 Agent SDK 调用在这里提供了一个很典型的黑盒结果。模型不可用时，SDK 可能先发送带 model_not_found 的 assistant 消息，随后给出 subtype: success，同时又设置 is_error: true 并抛出异常。如果只判断 subtype，界面会把失败显示成成功。最后的实现不相信单个表面字段，而是根据完整事件和异常语义判断终态，并抑制中断后的迟到成功、无效 resume 和旧运行事件。

一轮一 Query 的运行方式稳定后，Studio 又增加 Persistent Query。持续存在的异步输入队列和输出泵可以跨多轮复用运行时，也可以接住后台 Agent 的自主任务。文本多轮、Read、Write、Bash 成功与失败、审批允许与拒绝、中断后继续提问、进程重启恢复和后台任务都被纳入同一组验证。Claude 原生 history、Checkpoint 和 rewind 也接入运行时，让文件回退与 Claude 自己的会话边界保持一致。

这段开发过程说明，Vibe Coding 并不意味着只描述一个大概方向，然后接受模型生成的第一版结果。模型的确能够以很高速度建立完整结构，但工程质量来自另一件事：把“看起来能运行”继续追问成“每一种状态如何开始、如何结束、失败时留下什么证据”。

把快速迭代变成可以交付的工程闭环

协议和运行时稳定后，项目开始补齐真实企业规则。Token Manager 增加多 Key 管理，每个用户可以创建多把有名称、可独立撤销的 Key。明文只在创建时返回一次，数据库保存加密密文和可检索哈希。历史用量保留 Key 名称快照，即使密钥后来撤销，旧账仍有清楚归属。

请求观测也从“调用结束后写一条日志”变成完整链路。生成请求、鉴权拒绝、fallback 尝试、流完成、上游错误和客户端取消都进入统一观测模型，再通过 Redis Streams 消费组写入 MySQL。真实联调发现，Hono 的 Anthropic 通配中间件同时匹配基础 Messages 路径，使同一请求被观察两次。删除重复注册以后，一次模型生成只对应一条 usage 和一个选中 attempt。主动断开的流则被准确记录为 499/cancelled/partial。

飞书同步暴露的是另一类企业风险。如果某次部门或成员接口只返回部分数据，旧逻辑可能把未出现在结果中的员工识别成离职，然后批量停用账号。系统随后增加保护：只有同步结果完整时才执行破坏性清理，并单独处理空部门树和根部门成员。用户被禁用时，API Key 与登录会话同时撤销；管理员修改渠道、额度、价格、权限和用户访问时，操作进入结构化审计记录。

这些规则没有 3×3 协议转换那么显眼，却最能说明业务人员为什么仍然处于开发中心。模型可以快速写出同步代码，但“信息不完整时是否允许删除旧数据”不是语法问题，而是企业风险决策。AI 可以分析调用链、生成测试和实现保护，最终边界仍然来自对业务后果的理解。

Studio 这时也从“能够对话”变成了完整工作台。运行期间继续发送的消息进入顺序队列，不会丢失；底层 SDK 的文本、thinking、工具和结果被投影成以会话为中心的时间线；权限可以记忆，但 plan 模式仍保留人工确认。MCP 从手工配置进入界面，用户可以添加、探测、启停服务，并热更新运行时。项目级与全局 Skills 随后接入，Skill 重载与 MCP 状态、权限模式和 Claude session 放在同一条回归链路中验证。

附件功能也没有停在“增加一个上传按钮”。浏览器先探测模型视觉能力，服务端再验证工作区路径、文件类型、大小、存储位置和工具返回结果。依赖特定上游能力的 server tools 则按实际能力显式控制，避免把供应商差异变成用户运行到一半才看到的模糊错误。

这里逐渐形成了一套稳定的 AI 开发方法。第一层是静态分析：让模型阅读完整仓库、类型定义、Git 历史和现有文档，沿数据流找到设计矛盾。第二层是白盒测试：使用单元测试、fixture、状态机测试和性能基准检查内部行为。第三层是真实集成：连接 MySQL、Redis、模型上游和 Agent SDK，验证协议与数据落库。第四层是浏览器黑盒测试：从用户角度操作登录、会话切换、审批、导入、滚动和长历史。最后一层是持续文档：把每次判断的前提、验证证据和结果写回仓库。

这些层次彼此不能替代。类型检查能发现接口不一致，却发现不了 GLM 对工具选择格式的真实要求；转换 fixture 能证明状态机按预期运行，却不能代替真实 Agent SDK；后端接口返回 200，也不能证明浏览器中的导入、滚动和会话切换体验正确。Vibe Coding 提高的是每一轮“分析、实现、验证、修正”的速度，而不是取消验证。

最后一公里同样由代码、配置和测试组成

8 月 4 日以前，Token Manager 与 Studio 主要依靠手工填写 Base URL 和 Token 联调。两个仓库接通以后，登录用户可以从自己的 API Key 页面启动 Studio，并导入一把属于自己且仍然有效的 Key。Web 在导入前再次验证会话、Key 归属和启用状态，再把 Key 名称、一次性明文、Anthropic/OpenAI 网关地址、后台地址和用量地址编码进 sparkloom-studio://v1/open payload。明文不进入公共配置和日志，Studio 校验来源后以私有权限保存到本机用户目录。

这条用户路径第一次把企业身份、个人 Token、模型网关和本地 Agent Runtime 串成完整闭环.

Studio 随后进入 Portable 分发。发行包不只是前端静态文件，还包含 Node Runtime、Agent SDK 平台二进制、本地服务、启动器、协议注册和默认配置。Windows、Linux 和 macOS 都使用单实例 supervisor：第一次启动本地服务，之后的自定义协议请求转发给已运行实例，凭证导入后完成安全重启。

跨平台打包又发现 pnpm 依赖布局问题。Linux 开发环境中的 .pnpm 和符号链接能够工作，归档解压到 Windows 后，Agent SDK 的 MCP 模块却无法解析 eventsource-parser。最后改用 hoisted 生产依赖布局，并在解压后的归档里真实 import streamableHttp.js。如果验证只检查文件是否存在，这个问题会被漏掉；只有真正执行模块导入，才能验证目标运行时的解析路径。

8 月 5 日以后，系统又处理了并发额度与长会话性能。早期限额是在请求前查询当月累计费用，并发请求可能同时看到“尚未超额”。Redis 实时计数随后接管个人、部门和公司的周期额度，配合 epoch 基线、Stream 排空、初始化、上线与 reconcile 流程。系统在周期基线不存在时 fail closed，并明确区分已结算计数、安全余量和严格预留模型。这种准确描述系统语义的能力，本身就是工程交付的一部分。

浏览器测试同时发现，800 张卡片会形成约 8 万像素的滚动区域，200 条权限规则会把菜单撑到一万六千多像素。长菜单搜索、滚动限制、会话创建锁和延迟布局下的自动跟随随后加入。原生 Claude 历史搜索使用后台 Worker 增量维护 MiniSearch 索引，只索引用户和 assistant 的可见文本。事件桥也只在出现可见文本或 thinking 后创建卡片，避免只有元数据的空 assistant 消息进入时间线。

最后加入的能力模板把 MCP、Skill Plugin 和运行配置组合成可安装配置，第一份模板用于 API 研究。Token Manager 的视觉体系也与 Studio 品牌完成统一。到这个节点，用户可以从企业登录开始，获取个人 Token，启动 Studio，导入配置，选择项目并执行任务，再回到企业平台查看用量。两个仓库已经形成完整的产品与工程闭环。

当代码生产不再稀缺，开发人员还剩下什么

回头看这段开发，最明显的变化并不是某个框架用得更快，而是过去分散在多个岗位中的工作，被 GPT-5.6 SOL xhigh 放进了同一个连续上下文。模型能够阅读需求和 Git 历史，跨前端、后端、数据库、网关与打包脚本修改代码，生成测试，操作浏览器，分析失败日志，再把结论写回开发文档。它承担的已经不是代码补全，而是传统纯软件开发流程中多个细分岗位之间的执行和转换工作。

如果把传统开发人员定义为接收已经整理好的需求，按照既定技术栈完成编码、接口联调、常规测试和文档，那么这部分工作已经具备被 AI 端到端替代的条件。受到冲击的也不只是初级程序员。产品经理依靠整理需求和编写文档建立的优势，会被“业务描述直接转成可运行系统”的能力削弱；前端与后端以技术栈划分的边界，会被跨栈 Agent 削弱；测试岗位中重复编写用例、准备数据和执行回归的部分，会被自动生成的白盒与浏览器黑盒测试替代；标准化部署、配置检查和常规故障排查，也会越来越多地交给 Agent。

最先失去稀缺性的，是把明确方案翻译成代码。过去企业增加开发人员，是为了增加代码生产能力。模型把代码成本大幅压低后，继续增加只负责局部实现的人，未必能提高整体速度，反而可能重新引入会议、交接和上下文丢失。纯软件内部系统的常见团队形态，很可能从完整配置产品、前端、后端和测试，转为一名真正理解业务并对结果负责的人，配合一个或多个开发 Agent，再由少量高水平工程人员维护公共平台、复杂架构和生产风险。

所有细分岗位都会受到冲击，但这不等于软件开发从此不需要人。变化在于人的价值不再由代码产量决定。模型可以生成权限系统，却不能替企业决定财务人员应该看到什么；可以实现员工同步，却不能自行承担错误停用全体员工的业务责任；可以写出协议转换，却不能替企业决定哪些语义降级可以接受；可以生成测试报告，却不能自动获得代表企业签署上线结论的权力。

这次项目中真正稀缺的判断，几乎都不在“代码怎么写”。是否删除单机数据库降级，是对生产一致性的判断；部分飞书结果能否触发清理，是对组织风险的判断；Redis 计数应该承诺到什么程度，是对系统语义的判断；静态归档结果和目标环境运行结果如何区分，是对证据边界的判断。AI 可以快速分析、实现和验证不同方案，但必须有人选择边界，并对选择造成的结果负责。

因此，未来纯软件企业开发人员的核心价值会集中在几个连续动作上：识别真正值得解决的问题，把模糊业务目标变成可验证的约束，设计失败时仍然成立的系统边界，判断现有证据是否足够支持上线，以及承担系统运行后的业务责任。这些能力过去分散在资深产品经理、架构师、技术负责人和业务负责人身上，未来可能集中到更少的 AI 原生项目负责人身上。

所谓“会使用 AI”，也不会长期停留在提示词技巧。真正有效的是构建上下文和验证闭环：让模型读到正确的代码、数据结构、需求记录和历史决策；把目标拆成可以独立验收的阶段；要求每轮实现留下测试和运行证据；发现方向偏离时及时修改约束，而不是继续堆积功能。模型能力越强，人越不需要逐行指导它编码，越需要负责目标、边界、验收和裁决。

软件团队的组织方式也会随之变化。过去团队围绕专业分工建立，信息通过需求文档、接口文档、测试单和会议在岗位之间流动。未来团队会更多围绕产品结果组织：业务负责人直接维护目标和验收标准，Agent 持续实现、测试和记录，工程负责人维护权限、数据、安全、可观测性和 AI 开发基础设施。前端、后端和测试仍然是知识领域，但不再必然对应三个需要串行交接的全职岗位。

衡量开发效率的方式也需要改变。人天、需求数量和代码行数会逐渐失去解释力。更有意义的问题是：从业务问题到可验证版本需要多久，一轮迭代需要多少人工干预，自动验证覆盖了多少关键风险，上线后的问题有多少来自错误需求或错误边界。代码产量会越来越像计算资源消耗，而不是人的核心成果。

这个项目的第一版虽然粗糙，却已经证明纯业务人员可以借助 AI 跨过静态原型，直接构建具有真实数据流和交互逻辑的软件。随后的开发又证明，GPT-5.6 SOL xhigh 不只能快速生成原型，也能承担跨栈重构、静态分析、白盒测试、浏览器黑盒测试、部署验证和持续文档，把业务原型推进成完整企业系统。

Vibe Coding 因而不只是给传统流程增加一个更快的编码工具。它正在重新安排纯软件生产中的权力和责任。业务人员可以绕过漫长的需求转译，直接参与软件形态的构建；工程人员也不能再依靠掌握某种语言或框架维持不可替代性。未来真正稀缺的，不是把方案写成代码的人，而是能够理解业务、提出关键约束、建立验证闭环，并对最终结果负责的人。