01一页纸摘要

Executive Summary

GeekWork 卖的不是软件，是「把 AI 装进你业务里」这件事。 底座是我们建的标准件，业务承载是给客户定制的部分——两者一起交付，才叫一站式。 客户买的不是一套系统，是一个能跑起来的状态。

02问题定义

Problem Statement

企业现在不是「没有 AI 用」，而是「AI 已经在用了，但没人管得住」。这是采购动机的起点—— 我们卖的不是能力增量，是失控之后的收口。

为什么是现在

• Agent 从玩具变生产工具：过去是「问一句答一句」，现在是「让它跑半小时、改一堆文件、调用十几个工具」。一旦进入生产，治理必然被提上桌。
• 成本从「可忽略」变「科目级」：重度用户单月 Token 消耗已能到几百到几千元量级，几十人的团队就是一笔需要立项的支出。
• 合规开始查 AI 使用记录：金融、医疗、政务类客户在供应商尽调里已明确要求「AI 工具清单 + 数据流向说明」。
• 模型可替换已成共识：没人愿意把底座绑死在一家模型上，中间那一层的价值反而被确认了。

03目标客户与决策链

ICP & Buying Committee

客户分层

决策链：三个角色，三套语言

04产品定位与边界

Positioning & Scope

GeekWork 是什么

一套为企业定制的 AI Agent 底座，加上把它装进客户业务里的交付能力。 它运行在客户自己的网络边界内，模型、账号体系、数据都接在企业自己手里；员工在底座上完成问答、写码、文档、分析、自动化任务， 而所有调用都经过控制面——被授权、被计量、被记录。

但客户真正买的不是这套系统，是一句话：「你们帮我把 AI 用起来。」 这句话拆开是三件事——底座要建（不然没有承载）、流程要改（不然用不起来）、人要带（不然没人用）。 任何一件缺了，项目就变成一套躺在机房里的软件，第二年续费时客户会问：「这东西谁在用？」

所以我们的交付不是「交一套系统」，而是交一个能跑起来的状态：系统上线、场景跑通、有人会用、成本可算。 这四件事同时成立，才叫一站式。

三端形态：员工端做生产，企业管理员端做治理，平台端做运营

这套系统有三个端，对应三种使用者、三种作用域。混在一起讲，权限模型一定会做错： 员工端管自己，企业管理员端管一家企业，平台端管所有企业。三者共用同一个服务端与同一条模型网关，但权限域互不重叠。

一句话分工：员工端负责「干活的体验」，企业管理员端负责「一家公司的秩序」，平台端负责「所有公司的运营」。 把管理功能塞进员工端，员工会看见不该看的组织与成本；把干活能力做进网页，大量场景根本跑不起来； 把平台能力放进企业管理员端，客户第一个问题就是「你们是不是能看到我们所有数据」。

为什么必须是桌面 App，而不是又开一个网页

这不是技术偏好，是能力边界。下面六件事在浏览器里做不到或做不好，而它们恰好是 Agent 真正能替人干活的前提：

三条权限域：谁能看到谁

三个端不是三套系统，而是同一套服务端上的三个权限域。授权判定只认域，不接受「他是管理员」这种模糊说法—— 「企业管理员」和「平台管理员」听起来都叫管理员，能碰的东西完全不一样。

端到端的四条链路

离线怎么办：客户端持「预授权配额令牌」，断网时可继续消耗已预扣的额度上限，联网后对账； 超出预扣额度即停，不是断网就免费无限用。私有化客户第一周一定会问这条，答不出来就丢单。

底座内部结构（L1）

控制面是产品的商业内核。工作台决定「好不好用」，控制面决定「能不能卖给企业」——前者可以抄，后者要靠交付磨。 这一层是 L1，对任何客户都长得一样；不一样的部分在 L2 / L3。

交付分层：卖 L3，赚 L1

定制化最容易走到的结局是变成人力外包：客户提什么就改什么，改到最后底座被拆得七零八落，下一个客户从零开始。 所以必须先把交付切成三层，并且把纪律写死。

员工端导航结构：左上角两个新板块

平台主入口固定在左侧栏顶部——品牌之下、动作入口之上，并且按问题分组：上排是「我要干什么」 （新建任务、工作台、定时任务、资料库），下排是「我手上有什么」（SkillHub 公司资产库、 应用中心 业务系统入口）。两组回答的不是同一个问题，所以不混排——混排的后果是用户每次都要在几百条历史里找技能。

▶ 可点击原型：demo.geekwork.ai —— 一台 Mac 里跑着这套系统（员工端开在桌面窗口里，管理员端与平台端开在浏览器窗口里）。 按 1 / 2 / 3 切三端，F 全屏；不想看电脑外壳，直接开 demo.geekwork.ai/demo.html 裸屏版。建议照这条线点：员工端 · 工作台，空着点「发送」， Agent 跑一条跨系统查订单的活，中间有一次调用被 403 拦下、它降级继续干 → 换身份（右上角：创始人 / 研发 / 市场），另一个圈子的 Skill 与应用整片消失、左侧计数当场变 → 员工端「申请接入」，切到企业管理员端「待审批」通过，再回员工端，那张卡从「待接入」变成「可调用」， 审计里多一行 → 平台端「用量聚合」，所有租户的用量都在，业务内容一列全是「不可见」。 最后这一条不用讲，让客户自己点一遍，比讲十页都管用。

员工端 · 工作台会话 + 工具调用 + 权限拦截 企业管理员端 · 审批与审计申请→审批→生效闭环 平台端 · 多租户用量看得到用量，看不到内容

三张都是原型实拍（1920×1080），点开即进对应端；要原图直接右键存 PNG，贴方案书、公众号都够用

圈子：虚拟组织，第二套归属

组织树（部门）解决的是「谁花谁的钱」，圈子解决的是「谁能用谁的招」。这两件事在企业里从来不是一回事： 一个后端工程师在研发部，但他真正需要的资产可能来自「数据产品圈」。所以圈子不是权限的替代品，而是权限模型里新增的一根轴。

因此一个成员的最终可见性由三根轴取交集决定，而不是任何单一规则：

应用中心：三种接入形态别混在一起

企业里的「系统」不是一类东西。把跳转型和连接型混在一张卡片里，产品会立刻变糊。所以每个应用必须同时标注三件事： 能不能单点进去、Agent 能不能调、谁能看见。

同一个应用可以同时具备两种形态：ERP 既能单点进去手工开单，也能被 Agent 读取当月在制订单——这不是重复登记，而是同一份权限下的两个使用面。

我们做什么，不做什么

05核心价值主张

Value Proposition

四条主张：前三条对应三大底座能力（防），第四条对应资产层（涨）。每一条都必须能被客户「摸到」，不能停在概念。

06竞品与差异化

Competitive Landscape

企业客户真正在比较的，不是「哪个模型更聪明」，而是「这套东西能不能进我的机房、能不能进我的账、能不能进我的管理制度」。

● 明确具备　◐ 部分具备 / 取决于版本　○ 不构成能力。判断依据为公开资料与实测，随版本变化。

真正的对手：不是 Agent 工具，是方案商

客户在立项会上比较的从来不是「哪个 Agent 好用」，而是「这活交给谁干」。所以真正的对手是下面四类： 他们都不做底座，但都能拿走这个项目。

我们的位置

在工具维度上，市面上要么是好用但不可控（个人 Agent 工具），要么是可控但不好用（自建脚手架）， GeekWork 卡在中间那个空档。而在方案维度上，我们比咨询公司多一个能跑的底座，比集成商多一个自己的产品， 比大厂云多一份贴身定制——这四类对手各缺一块，我们四块都在。

07功能需求

Functional Requirements

按底座三层 + 资产层拆成 9 组需求。P0 为 v1.0 必须交付（缺一不可签约）；P1 为 v1.5；P2 为 v2.0 或按单定制。

端归属：每组功能先归到一个端

端归属决定开发排期与验收方式，也是拆团队的依据。员工端 = 员工电脑上的 App；企业管理员端 = 浏览器里的企业后台；平台端 = 我们自己的运营后台；服务端 = 三端共用、没有界面。 每组标题右侧都标了端，不允许出现「两边都能改」的功能——那种功能最后一定是两边数据打架。

F1　组织管理 P0后台

目标：让「一家公司」在这个系统里有完整、可运维、能自动跟随人事变动的结构。

F2　权限管理 P0后台

目标：把「Agent 能碰到什么」变成可声明、可审批、可追溯的策略，而不是散落在各个客户端的信任。

F3　Token 统一管控 P0服务端

目标：这是产品的商业命门。企业主买这套系统的第二个理由（第一个是安全），就是「终于能算清这笔账」。 这一组需求做不扎实，产品就退化成「又一个套壳客户端」。

F4　工作台与运行 P0桌面

目标：不好用就没人用，没人用就收不到钱。这一层是「采用率」的唯一保障。

F5　管理后台 P0后台

六个一级页，不许多：概览（今日消耗 / 活跃人数 / 异常）· 组织 · 权限 · 成本 · 审计 · 设置。 企业主的耐心只够点进三层，任何功能找不到就是没做。

F6　部署与运维 P0服务端

目标：私有化交付是拉开差距的地方，也是最容易翻车的地方。必须做成「可重复的工序」，不能每次现场救火。

F7　SkillHub：企业资产库 P0桌面 + 后台

目标：把「某个骨干电脑里的好 prompt」变成「公司账上的资产」，同时用圈子管住谁能看见。 这个板块的价值不在功能多，而在它让前三个主张从「省成本」变成「涨能力」——客户续费时说服董事会的，往往就是这一条。

F8　应用中心：业务系统入口 P0桌面 + 后台

目标：让企业已有的 ERP、CRM、设计系统在 Agent 时代重新变成「可调用的能力」，而不是各自为政的孤岛。 我们不做这些系统，只做它们的统一入口、身份与连接。

F9　租户运营 P0平台

目标：让「一家企业 = 一个租户」成立——我们能在一个界面里看清所有客户的用量与健康度，同时看不到他们的内容。 这一组不做，平台就退化成「给每个客户单独装一套」，客户数一上两位数，运维立刻崩。

版本归属汇总

08关键用户流程

Key Flows

三端之后，流程不再只有「在系统里点」，而是三个端来回接力：客户先在我们平台端有个租户，企业管理员在后台配好组织与策略，员工在桌面端干活。下面每条都标了它发生在哪个端。

流程零 · 从 IT 分发到员工第一次跑通 桌面 + 后台

这是桌面 App 带来的新流程，也是私有化项目最容易卡住的一步——客户端发不下去，后面所有功能都等于没做。

1. IT 在后台开通席位并绑定部门同时生成该部门的安装配置（服务端地址、初始策略、模型白名单），员工端不需要填任何服务器信息。
2. 推送安装包走企业已有的软件分发（MDM / 域推 / 内网下载页）。macOS 需签名与公证，Windows 需代码签名，否则会被系统直接拦截——这条不提前做，现场必翻车。
3. 员工首次启动，走企业身份登录钉钉 / 企微 / 飞书 / OIDC 免登；客户端拿到短期令牌与设备证书，模型密钥不下发。
4. 客户端拉取策略并自检可用模型、可见技能、目录授权范围、命令白名单，5 分钟内拉到；网络不通时报出具体缺哪一项，而不是白屏。
5. 授权工作目录员工自己选目录（如项目文件夹）建索引；未授权目录一律不可访问，密钥与证件类路径默认拉黑。
6. 跑通第一个任务并确认计量随手问一句或调用「代码评审助手」，后台立刻能看到这条调用归属到人、部门、圈子——第一次就让他看见「有记录」，后面才不会抵触。

流程一 · 新员工从入职到产出 后台 + 桌面

1. HR 在钉钉 / 飞书把人加进部门通讯录同步 5 分钟内推到 GeekWork，自动落位到对应组织单元。
2. 系统按部门策略自动发席位与配额模型白名单、可用技能、月度 token 额度由部门的策略模板决定，无需逐个配置。
3. 员工免登进入工作台不用申请账号、不用报备。看到的技能都是部门已授权的。
4. 干活产生调用每次请求经过模型网关，计量埋点在网关层完成，与客户端无关，无法绕过。
5. 配额临界与提额80% 提醒本人，100% 熔断；需要继续则走提额申请，主管审批后给临时额度。
6. 管理者月末看账部门管理员看本部门，CEO 看全公司；费用已按成本中心归好类。

流程二 · 一次「想装个 MCP」的审批 桌面发起 · 后台审批

1. 成员提交安装申请填写 MCP 用途、要访问的数据范围、是否联网。
2. 部门管理员初审判断业务必要性。
3. IT / 安全终审看数据范围与外部请求白名单，必要时要求改配置。
4. 通过后按组织级安装不是装在那个人电脑上，而是装在组织策略里，可批量授权给同类角色。
5. 全量留痕谁装的、谁批的、谁用过、调了什么接口，全在审计日志里。

流程三 · 离职交接 后台

1. HR 标记离职同步触发停用，60 秒内失去全部访问权限。
2. 资产盘点列出他创建的技能、模板、Agent、共享文件、未完成的编排任务。
3. 移交而非删除技能与模板指派继任者；会话归档只读保留（合规需要）。
4. 配额释放席位与额度回收，可立即分配给新人。
5. 出交接单一条审计记录，可导出给 HR 归档。

流程四 · 新人加入圈子，看到什么 后台 + 桌面

1. 入职自动进部门，但不自动进圈子部门决定预算与审批链，圈子决定他能看到哪些资产——两者刻意解耦，避免「进错部门就看不到该用的东西」。
2. 申请加入「研发圈」圈主审批（或由圈主设为部门内自由加入）。通过后立刻看到研发圈的全部 Skill 与内部工具入口。
3. 同时加入「数据产品圈」跨部门加入，不影响组织归属与预算；两个圈子的资产在他这里取并集。
4. 看不到别的圈子的东西市场圈的投放分析 Skill、财务圈的报表模板对他完全不渲染，搜索也搜不到。
5. 做得好的东西往上递他写的一个 Skill 在圈内被用了 200 次，圈主申请晋升为全组织可见——个人经验变成公司资产。

流程五 · 新客户从开通租户到第一台客户端上线 平台 → 企业管理员 → 员工端

这是三端架构下才有的流程：客户还没装任何东西时，先在平台端有一个租户。

1. 平台端创建租户填企业名、行业、套餐、初始席位与总配额；系统分配独立数据域与独立密钥，生成企业管理员邀请链接。
2. 平台端分配通道与配额模板指定这家企业可用哪些模型通道、优先级与限流；把配额模板（部门 / 成员默认额度）挂上去，企业管理员可在此基础上再调。
3. 企业管理员接受邀请首次登录走企业 IdP 登录并绑定管理员角色。首次进入是空租户，系统只给三件事的引导：接身份源、导组织、发策略。
4. 企业管理员接身份源并导入组织钉钉 / 企微 / 飞书 / OIDC 任选其一，通讯录同步后组织树自动成型；CSV 兜底。
5. 企业管理员发第一条策略并推客户端设定模型白名单、圈子、配额与目录授权范围；生成带企业配置的安装包，走内网分发。
6. 平台端确认租户「跑起来了」平台侧只看到该租户出现首条调用（用量可见、内容不可见），健康度从「新建」变为「活跃」——这是 POC 转落地的第一个客观信号。

09非功能需求

Non-Functional Requirements

三端的要求各不相同：员工端拼安装、资源占用与离线可用，企业管理员端拼权限准确与响应速度，平台端拼租户隔离与不漏。混在一张表里，验收时一定漏项。

员工端（桌面 App）

服务端与企业管理员端

平台端

平台端的技术要求不在「快」，在「不漏」——它是越权的最大风险面。

10商业模式与收入结构

Business Model

这一章只讲靠什么收钱，不写具体价格。金额、折扣与付款方式一律以单独报价单与商务合同为准， 任何对外材料都不出现数字——价格一旦印在说明书里，销售就失去了按客户情况议价的空间。

收入结构

三种合作路径

不是一次性签一个大合同，而是按客户的信心水平分三段进——每一段都能独立收口，也都能自然导向下一段。

计费与隔离的最小单位是租户：一个企业一个租户，一个租户一套数据域、一套密钥、一张用量账。 集团客户是多租户挂在一个主体下，OEM 伙伴的租户挂在伙伴名下——这两种在平台端都能一眼区分。

另有一条侧路：对集成商开放 L1 白标授权——我们只给底座与培训，不做他们的实施，避免变成他们的分包商。

报价原则

价格不写进产品文档，但报价的规则必须写死，否则每个销售会按自己理解去谈，最后把产品谈成外包。

• 私有化必须单列实施费。不能打包进底座授权费——否则第一个客户的交付人力就把首年收入吃掉。
• 定制必须有上限。客户定制体量一旦接近首年底座授权费，就必须打包成「行业方案包」再卖第二次，否则这单本质是项目外包。
• 运维与底座授权分开报价。合并会让客户觉得「买完就完事」，续费失去存在感。
• 模型成本默认 BYOK。让客户自己看见模型账单，涨价时怨气不会算在我们头上。
• 席位与能力分开卖。加席位不等于解锁能力，反之亦然——两者混在一起，客户永远算不清贵在哪。
• 试点可以便宜，但必须收费。免费 POC 会拖成无底洞，也会让客户不认真配合——收了钱，对方才会派得动人。
• L3 按方案边界报价，不做 open-end 人天。边界外的工作必须重新立项，否则一个客户能把团队拖死一整年。

11交付模式

Delivery Model

客户端分发与升级

桌面 App 让交付多了一个必须标准化的环节。这一环不做成工序，每个客户都要现场救火，而且救的是终端问题，不是产品问题。

交付纪律（沉淀自项目经验）

• 先定「谁看账」再谈功能。客户说不清成本要摊到哪一级，这个项目一定烂尾。第一周就必须确定成本中心口径。
• 权限先粗后细。一上线就设计 30 个角色，必然改到崩溃。先 5 个预置角色跑两周，再按真实诉求加。
• 定制必须回流。每个客户定制都要判断「能不能做成配置项」。不能回流的定制，报价必须覆盖两次的成本。
• 实施报告是资产。每次交付的验收清单直接变成下一单的售前材料。
• 客户端问题只认两件东西：版本号和日志包。不接受「我这边不行」这类描述——没有版本号与日志包，终端问题永远查不出根因。

12路线图与里程碑

Roadmap

13成功指标

Success Metrics

北极星指标：客户侧正在跑的 L3 业务场景数。它同时约束三件事——底座装上了（L1 生效）、流程改了（L3 落地）、人在用（不是摆着）。 只数席位，会把「买了没人用」算成业绩；只数合同额，会把「交完就烂尾」算成业绩。

14风险与对策

Risks & Mitigations

15待决事项

Open Questions

以下事项需在 v1.0 开发启动前定论，否则会影响架构或商业模式。