265 lines
10 KiB
Markdown
265 lines
10 KiB
Markdown
## 1. Codex 与智能体有什么区别？为什么 Codex 能满足需求？
|
||
|
||
首先要纠正概念：
|
||
|
||
> “智能体”是一类技术架构，Codex 是具备智能体能力的具体产品和工作平台，两者不是并列关系。
|
||
|
||
普通对话式 AI 主要是“一问一答”；智能体通常能够：
|
||
|
||
- 理解目标并拆解任务
|
||
- 读取多个文件和项目上下文
|
||
- 调用工具、程序及外部系统
|
||
- 连续执行多个步骤
|
||
- 检查中间结果
|
||
- 生成文件、代码、表格或报告
|
||
- 在授权范围内完成实际操作
|
||
|
||
Codex 的价值不只是生成文字，而是能在项目工作区中处理文件、数据、代码和多步骤流程，并把反复使用的方法沉淀为规则、Skills、模板和自动化工作流。官方展示的场景已经覆盖数据清洗、表格分析、文档生成、质量检查、知识工作和自动化等，并非只有写代码。[OpenAI Codex 使用场景](https://developers.openai.com/codex/use-cases)
|
||
|
||
但不能承诺“只要买了 Codex，就能满足秋田微全部需求”。准确说法应当是：
|
||
|
||
> Codex提供通用执行能力；秋田微的业务资料、部门规则、标准模板、审核机制和系统接口，才共同构成最终解决方案。
|
||
|
||
解决动作：
|
||
|
||
1. 制作《Codex能力边界说明书》。
|
||
2. 将方案中的需求分为：
|
||
- 可直接完成
|
||
- 需要配置工作流
|
||
- 需要连接企业系统
|
||
- 必须人工决策
|
||
- 暂不建议使用
|
||
3. 选择三个标杆场景做实际演示：
|
||
- 客户规格书 → 内部需求矩阵
|
||
- 测试数据 → 测试报告
|
||
- 客诉资料 → 8D 初稿
|
||
4. 对输出进行人工复核，统计准确率、遗漏率和修改率。
|
||
|
||
最终交付：
|
||
|
||
- 《需求—能力映射矩阵》
|
||
- 《Codex能力边界及人工审核清单》
|
||
- 三个场景的 PoC 报告
|
||
|
||
---
|
||
|
||
## 2. 类似产品有哪些？为什么选择 Codex？
|
||
|
||
同类产品包括但不限于：
|
||
|
||
- Anthropic Claude Code
|
||
- Google Gemini CLI
|
||
- GitHub Copilot CLI／cloud agent
|
||
- Cursor
|
||
- Cline、Roo Code 等工具
|
||
- 基于通用大模型自建的企业智能体平台
|
||
|
||
例如，Claude Code、Gemini CLI 和 GitHub Copilot 都具备读取文件、执行工具或命令、处理复杂任务等智能体能力；GitHub Copilot cloud agent 还可以在独立环境中修改代码、运行测试并形成 PR。[Claude Code 官方文档](https://docs.anthropic.com/en/docs/claude-code/getting-started)、[Gemini CLI 官方文档](https://github.com/google-gemini/gemini-cli/blob/main/docs/get-started/index.md)、[GitHub Copilot cloud agent 官方文档](https://docs.github.com/en/enterprise-cloud%40latest/copilot/concepts/about-assigning-tasks-to-copilot)
|
||
|
||
因此，不要用“只有 Codex 能做”作为选型理由。应建立评分表，同场比较：
|
||
|
||
| 评估维度 | 建议权重 |
|
||
|---|---:|
|
||
| 秋田微三个标杆场景完成质量 | 30% |
|
||
| 多文件、表格、文档及代码处理能力 | 15% |
|
||
| 工作流固化与企业定制能力 | 15% |
|
||
| 安全、权限、审计和数据政策 | 15% |
|
||
| 企业系统及外部工具连接能力 | 10% |
|
||
| 使用体验和人员学习成本 | 5% |
|
||
| 三年总体成本 | 10% |
|
||
|
||
Codex 可作为优先 PoC 对象，理由是它同时覆盖文件、数据、代码、工具调用、可复用 Skills 和跨业务知识工作。但最终选择应该以 PoC 数据为依据。
|
||
|
||
解决动作：
|
||
|
||
1. 选择 Codex 加一至两个备选产品。
|
||
2. 使用完全相同的脱敏样本和验收标准。
|
||
3. 不允许供应商各自挑选有利案例。
|
||
4. 比较准确率、遗漏率、人工修改率、耗时、费用和安全能力。
|
||
5. 形成评审结论，而不是宣传性结论。
|
||
|
||
最终交付：
|
||
|
||
- 《企业 AI 产品选型评分表》
|
||
- 《同场景 PoC 对比报告》
|
||
- 《产品选型建议书》
|
||
|
||
---
|
||
|
||
## 3. Codex 后续如何升级？
|
||
|
||
需要拆成三层回答。
|
||
|
||
第一层是产品升级：
|
||
|
||
- Codex 云端模型和服务由 OpenAI 持续更新。
|
||
- 本地客户端或 CLI 按官方版本机制更新。
|
||
- 企业不需要自己训练或维护基础模型。
|
||
|
||
第二层是企业工作流升级：
|
||
|
||
- AGENTS.md、Skills、模板、术语库由秋田微自己管理。
|
||
- 所有规则进入 Git 或其他版本库。
|
||
- 修改需经过测试、审核、发布和回滚。
|
||
- 每季度依据业务变化和产品更新进行一次复评。
|
||
|
||
第三层是升级风险控制：
|
||
|
||
不能因为产品自动升级，就直接把新版本用于正式流程。应建立：
|
||
|
||
> 新版本测试环境 → 历史样本回归测试 → 业务负责人确认 → 小范围发布 → 正式推广
|
||
|
||
解决动作：
|
||
|
||
1. 建立“开发、测试、正式”三套工作区。
|
||
2. 建设一批具有标准答案的历史评测样本。
|
||
3. 每次升级验证准确率、格式、术语和费用变化。
|
||
4. 保留旧版本工作流和回滚机制。
|
||
5. 合同中明确培训方后续维护周期、响应方式和收费边界。
|
||
|
||
最终交付：
|
||
|
||
- 《Codex版本与工作流升级管理办法》
|
||
- 《升级回归测试清单》
|
||
- 《Skills及模板版本台账》
|
||
|
||
---
|
||
|
||
## 4. 部署 Codex 的费用是多少？
|
||
|
||
这里不能只报一个软件账号价格。应拆成四部分：
|
||
|
||
1. 产品许可和使用量费用
|
||
2. 企业实施和场景开发费用
|
||
3. 安全、接口和基础设施费用
|
||
4. 年度维护、培训及持续优化费用
|
||
|
||
截至目前，OpenAI 官网显示 ChatGPT Business 为每用户每月 20 美元（年付）或25美元（月付），Enterprise 为定制报价；Codex 的额外使用还可能按 credits／token 消耗。官方说明 Codex 实际成本与模型、任务规模、并发、自动化和快速模式有关，因此必须通过 PoC 测量，不能仅按账号数推算。[OpenAI Business 定价](https://openai.com/business/pricing/)、[Codex rate card](https://help.openai.com/en/articles/20001106)
|
||
|
||
另外，自 2026 年6月24日起，新 ChatGPT Business 工作区不再提供新的 Codex-only 按量席位，但标准 Business 席位仍包含一定的 Codex 使用能力；企业大规模使用最好直接取得 Enterprise 正式报价。
|
||
|
||
建议不要一开始给40～60人全部开通。可分三期：
|
||
|
||
- 第一期：10～15名内部教练进行 PoC
|
||
- 第二期：20～30名部门关键用户
|
||
- 第三期：根据使用率和 ROI 扩展到40～60人
|
||
|
||
三年 TCO 计算方式：
|
||
|
||
> 三年TCO＝席位费用＋使用量费用＋实施费用＋接口开发＋安全治理＋培训＋年度维护＋内部人员投入
|
||
|
||
最终交付：
|
||
|
||
- 《三年 TCO 测算表》
|
||
- 《分阶段账号与预算方案》
|
||
- 《单场景、单用户和单份交付物成本基线》
|
||
|
||
报价前必须确认：
|
||
|
||
- 试点和正式用户数
|
||
- Business 还是 Enterprise
|
||
- 是否调用 API
|
||
- 是否连接 SAP、MES、PLM、OA
|
||
- 是否需要 SSO、SCIM、RBAC、日志和数据驻留
|
||
- 每月任务量及文件规模
|
||
|
||
---
|
||
|
||
## 5. 使用若干年后更换其他 AI，难度和费用如何？
|
||
|
||
不能承诺“零成本迁移”，但可以从第一天降低锁定风险。
|
||
|
||
把核心资产做成厂商无关格式：
|
||
|
||
- 原始文档：Word、Excel、PDF、Markdown
|
||
- 业务规则：Markdown、YAML、JSON
|
||
- 处理脚本：Python、JavaScript
|
||
- 知识库：可导出的结构化数据
|
||
- 标准接口：API、MCP或企业自有接口层
|
||
- 评测样本：输入、标准答案、评分规则
|
||
- 工作流说明：不要只保存在某个产品的聊天记录中
|
||
|
||
真正容易锁定的不是基础资料，而是：
|
||
|
||
- 只适用于某个平台的提示词和插件
|
||
- 厂商内部格式的知识库
|
||
- 无法导出的会话与记忆
|
||
- 直接耦合在产品里的系统接口
|
||
- 没有标准答案的隐性业务经验
|
||
|
||
建议合同和技术方案中加入“退出条款”：
|
||
|
||
- 数据可完整导出
|
||
- 模板和脚本归秋田微所有
|
||
- Skills 有独立说明文档
|
||
- 接口通过适配层隔离
|
||
- 每年进行一次替代平台迁移演练
|
||
|
||
迁移成本应通过演练测量，而不是拍脑袋报价。可以选择一个工作流，尝试迁移到备用产品，记录：
|
||
|
||
- 规则转换工时
|
||
- 接口改造工时
|
||
- 重新测试工时
|
||
- 用户培训工时
|
||
- 迁移后的质量差异
|
||
|
||
最终交付：
|
||
|
||
- 《AI平台退出与迁移方案》
|
||
- 《企业AI资产可移植标准》
|
||
- 《替代平台迁移演练报告》
|
||
|
||
---
|
||
|
||
## 6. 数据安全如何解决？
|
||
|
||
这是客户最重要的问题，必须从“承诺”升级成“制度＋技术＋审计”。
|
||
|
||
OpenAI 对 Business、Enterprise 和 API 的官方承诺是：默认不使用企业输入输出训练模型；数据在传输和存储时加密。Enterprise 还提供更高级的权限、保留期、区域存储和企业密钥等能力。[OpenAI企业数据隐私与安全](https://openai.com/business-data/)
|
||
|
||
但这不代表企业可以把所有数据直接上传。秋田微仍需建立自己的控制体系。
|
||
|
||
建议采用八道控制：
|
||
|
||
1. 数据分级
|
||
将数据划分为公开、内部、敏感、高敏感。
|
||
|
||
2. 使用边界
|
||
未公开财务、核心图纸、完整 BOM、个人信息等原则上禁止或专项审批。
|
||
|
||
3. 数据最小化
|
||
只提供完成任务必需的字段，并对客户名、料号、价格等脱敏。
|
||
|
||
4. 企业账号
|
||
禁止员工使用个人账号处理公司资料，启用 SSO、MFA、权限和离职回收。
|
||
|
||
5. 工作区隔离
|
||
按部门、产品线和项目建立隔离工作区，避免跨项目资料混用。
|
||
|
||
6. 工具权限
|
||
文件系统、网络、命令和外部系统遵循最小权限；高风险操作必须人工确认。
|
||
|
||
7. 输出审核
|
||
产品定型、测试结论、质量放行、财务确认、公告和正式客户承诺不得由 AI 决定。
|
||
|
||
8. 日志与追溯
|
||
记录操作者、输入类型、调用工具、输出版本、审核人和最终用途。
|
||
|
||
针对秋田微在中国经营、涉及海外客户和泰国基地的情况，还必须做跨境数据专项评估。OpenAI 当前披露的数据驻留区域包括美国、欧洲、英国、日本、新加坡等，但不包括中国大陆，因此“具备数据驻留”不等于自动满足秋田微的中国数据合规要求。应由法务或合规人员结合实际数据种类判断是否涉及个人信息或重要数据跨境。
|
||
|
||
实施顺序沿用原方案中的原则：
|
||
|
||
> 脱敏文件试点 → 只读查询 → 小范围授权 → 人工审批 → 日志审计 → 再评估是否连接正式系统
|
||
|
||
第一期不要让 Codex 直接写入 SAP、MES、PLM 或正式质量系统。
|
||
|
||
最终交付：
|
||
|
||
- 《Codex安全使用规范》
|
||
- 《数据分类分级表》
|
||
- 《禁止与审批场景清单》
|
||
- 《权限及账号矩阵》
|
||
- 《AI使用日志和审核表》
|
||
- 《数据跨境及供应商安全评估表》
|
||
|