导语：问到第三个问题，场面安静了

下面这个场景，几乎是内网工具选型的固定剧本，每次只是细节不同。

三个厂商各讲四十分钟。第一个讲模型能力，第二个讲代码生成准确率，第三个直接开了 Demo，现场改了一个 bug，全场鼓掌。

轮到技术负责人提问。他问了三个问题：

模型是跑在内网还是调用外部服务？断网之后还能不能用？如果一个人让它执行删除命令，事后能不能查出来是谁批的？

第一个问题，两家说"支持私有化部署"，追问具体形态时开始含糊。第二个问题，一家说"主要功能不受影响"，另一家说"需要联网做许可校验"。第三个问题，三家都没太听懂在问什么。

会议室安静了几秒。不是尴尬，是所有人同时意识到：前面两个小时的 Demo，回答的都是另一个问题。

这篇文章把那次会上该问的问题整理成一份清单。十二个问题，六类边界。你可以直接拿去用，哪怕最后不选我们的产品。

一、Demo 展示的是上限，采购买的是下限

Demo 有一个结构性特点：它总是发生在最理想的条件下。一个用户，一台联网的机器，一个干净的项目，一次顺利的执行，一个不会失败的命令。

而内网的真实条件是：二十个用户，一台断网的服务器，一个注释不全的历史工程，一次会超时的构建，以及一个三天后会来查日志的安全员。

AI 编程工具的能力上限主要由模型决定，这一层差异在半年内会被拉平——今天最强的那家，明年可能排第三。但下限由工程设计决定，包括身份怎么做、权限怎么收、记录怎么留、离线怎么交付。这些东西一旦定下来，换工具的成本极高。

所以选型会上真正该花时间的，不是"它能不能写对这段代码"，而是"它在最差的情况下会怎么表现"。下面六类边界，每一类都可能单独让项目停下来。

二、六类边界

数据边界：代码和上下文去了哪里。内网环境里这不是一个"隐私偏好"问题，而是硬性要求。要问的不只是"能不能私有化"，而是"断网之后哪些功能会失效"——很多产品在离线状态下会降级：模型不可用、许可校验失败、插件市场打不开，甚至直接拒绝启动。

身份边界：操作归属于谁。这一条在多用户环境下是所有审计能力的前提。账号和人对不上，后面所有记录都只是"某台机器上发生过什么"。

权限边界：谁能让 AI 做什么。高危操作的批准粒度、策略谁能改、改了有没有记录。这一条决定了这套工具是"可控"还是"能用但不敢放手"。

审计边界：事后能不能还原。记录存在哪、能不能导出、导出的东西审计人员看不看得懂。注意"有日志"和"能被审计"是两件事。

并发边界：十个人用的时候是什么体验。并行还是排队、资源怎么分配、长任务会不会把别人饿死。

交付边界：装得进去、升得上去、算得清楚。内网无外网，安装包怎么进、升级怎么进、授权按什么计。

六类边界的关系不是并列的。数据边界是前提，身份边界是地基，权限和审计是同一件事的两面，并发决定使用体验，交付决定这项目能不能验收。任何一类出问题，其他几类做得再好也没用。

三、十二个问题

每类两个问题。每条给三种东西：怎么问、什么回答算过关、什么回答要警惕。

第一问：模型是完全跑在内网，还是需要连外部服务？断网之后哪些功能会失效？

过关的回答会明确区分"核心推理"和"辅助功能"，并且能给出断网状态下的功能清单。要警惕"支持私有化部署"这种笼统表述——它可能意味着"可以部署在你的服务器上，但仍然要出网调用模型 API"。

第二问：有没有任何形式的联网校验或数据回传？怎么证明？

过关的回答是能被验证的：给出网络出口清单，或者同意在完全隔离的环境里跑一次给你看。要警惕"我们没有收集数据"——这是承诺，不是机制。真正可靠的是"拔掉网线它也能启动"，这件事五分钟就能验。

第三问：用户是内置账号，还是能对接单位已有的身份体系？

过关的回答是支持对接，人员入转调离能跟着组织架构自动生效。要警惕"可以手动建账号"——短期能用，半年后你会维护一份谁也不敢删的花名册，而且离职人员的账号往往会活很久。

第四问：账号停用之后，他的会话、文件、产物怎么处理？

这个问题很少有人问，但它决定了两件事：可追溯性和空间治理。过关的回答是有明确策略并且可配置（保留、归档、转移给接手人）。要警惕"停用后数据自动删除"——这会直接破坏历史可追溯性。

第五问：删文件、执行命令、访问工作区外的目录，批准粒度是什么？

过关的回答能说清三种粒度：仅本次、本会话内按模式允许、拒绝，并且说明每种的作用域边界。要警惕"有确认弹窗"——弹窗只是交互，粒度才是权限模型。

第六问：权限策略谁能改？改了之后有没有记录？

过关的回答是策略变更本身也进记录，包括谁放宽了范围、放宽到什么模式、何时回收。要警惕"管理员在配置文件里改"——配置文件的变更通常不在审计范围内，这会造成一个看不见的口子：策略被悄悄放宽，而所有操作记录看起来都合规。

第七问：操作记录存在哪里？能导出吗？导出格式审计能直接用吗？

过关的回答是服务端持久化、可按用户/项目/时间检索、可导出结构化格式（CSV、JSON 之类）。要警惕"日志在服务器上，需要的话可以查"——不能导出的记录，在审计场景里约等于不存在。

第八问：只看记录，能不能还原"谁让它做了什么、谁批准的"？

这一问是压力测试。过关的回答是能给出四个字段：主体、动作、对象、授权。建议现场要求对方导出一段真实（脱敏）记录，你亲自读一遍。要警惕只演示界面里的漂亮时间线——界面是给人看的，审计要的是能带走的数据。

第九问：十个人同时用，是并行还是排队？资源怎么分配？

过关的回答会说清并发上限、超限后的行为（排队还是拒绝）、以及上限由谁配置。要警惕一个漂亮的数字——任何没有在你目标环境里验证过的并发数，都只能当作参考。

第十问：两个人同时改同一份东西，冲突了会不会静默覆盖？

过关的回答是有冲突检测和明确提示，或者有版本机制可以回溯。要警惕"后保存的生效"——这在文档协作里只是烦人，在代码和配置场景里会丢工作。

第十一问：内网无外网的机器上，安装和后续升级怎么进去？

过关的回答是一套完整的离线物料：运行时、依赖、校验清单，以及可重复执行的安装步骤。要警惕"打个压缩包拷进去就行"——依赖闭包不全的话，你在机房里会待六个小时。

第十二问：授权按账号、按并发还是按机器绑定？加人怎么算？

过关的回答是计费维度清晰、扩容路径明确、且离线状态下能完成授权更新。要警惕"到时候再说"——内网环境的授权更新往往比安装还麻烦，因为它需要一张新的授权文件穿过同样的审批流程。

四、把回答变成当场能做的动作

清单的价值在于它能被验证。每一类边界都有一个五分钟内能做完的动作：

这六个动作加起来不到半小时，能筛掉大部分"PPT 上支持"的方案。它们也不需要你懂实现细节——你只需要看结果。

特别值得做的是"拔网线"和"同时点同意"这两个。前者能戳破绝大多数私有化的模糊表述，后者能暴露状态一致性的真实水平。而这两件事，恰恰是最少被现场验证的。

五、这份清单，我们自己的答案

写这份清单的人当然也要接受它。以下是我们对自己产品的回答，能演示的写"可演示"，不能的一律标出来，不模糊处理。

四行标了【待确认】。这不是留白，是我们认为在一个负责任的清单里，不确定就该写不确定。任何一家在十二个问题上全部答"完美支持"的供应商，建议你反而要多问两遍。

六、结语：清单比答案更有价值

这类场合里，提问方真正想知道的往往不是答案，而是"你有没有想过这个问题"。

一家厂商如果在你问出"策略变更有没有记录"时愣了一下，然后说"这个我们回去确认"，那至少说明它承认这是个问题。另一家如果立刻说"完全支持"，并给出一段漂亮的界面演示，你反而要小心——因为这类问题通常没有简单答案，回答得太快，多半是没听懂。

所以这份清单最好的用法不是逐条打分，而是看对方在哪些问题上开始含糊。含糊的位置，就是项目半年后出事的位置。

如果只能记一个问题，记第五个：删文件、执行命令，批准粒度是什么。

因为这个问题同时牵着权限、审计和多用户三条线，一家能把它讲清楚的厂商，其他问题通常也差不到哪里去。

资料来源

1. 内部：webui/README.md（多用户认证、审批流程、多线程并发、CAS 防冲突、终端断线重连）
2. 内部：webui/docs/auth.md（JWT/session、可选 TOTP、机器 API Key 白名单）
3. 内部：webui/docs/approval.md（审批粒度与沙箱策略）
4. 内部：webui/docs/docker.md（部署方式）
5. 内部：scripts/package-webui-windows.py、tools/license-issuer（离线打包与离线授权路径）