我为什么给Codex接上AIS：一次让AI从“临时聪明”走向“长期协作”的实践

最近，我一直在尝试解决一个问题：怎样让 Codex 不只是完成眼前的一次任务，而是真正理解我长期在做什么，并能在下一次工作中接着上一次继续。

我遇到的麻烦，不是 AI 不够聪明

这段时间，我用 Codex 做了很多事情：写需求和设计文档、整理项目周报、制作报价方案、研究产品方向、分析客户需求，也让它处理 Word、PPT、Excel、PDF 和本地文件。

它在单次任务里的表现常常很好，只要我把背景、参考资料、格式和要求讲清楚，它能够很快进入状态。但我也越来越明显地感到：每次新任务开始，我都在重新解释自己。

我的资料散落在几个地方：common 目录里放着经常使用的产品资料和模板；不同项目目录里有需求、方案和交付物；聊天记录里藏着一些很关键的判断；还有不少经验只存在于我的脑海里。它们都很有价值，却没有形成一套能够被 AI 稳定调用的长期上下文。

我逐渐意识到，问题并不是模型不够强，而是缺少一套持续的上下文系统。于是，我开始尝试用 AIS-Skill（参见：https://torchv.com/docs/skill/ais-skill/） 把 Codex 和 TorchV AIS 知识引擎连接起来。

连接过程并非一次成功。我先后排查过域名、Open Key 权限和请求配置，一度连续遇到 AccessDenied；最后发现 Open Key 的生效时间还受到时区问题影响，下次再也不乱改系统配置了。第二天重新验证时，Codex 已经能够正常列出知识库、读取目录并识别权限。这个小插曲反而让我更清楚地看到：企业级知识连接不仅是“接口通了”这么简单，身份、权限、生效时间和审计同样重要。

现在，我这样理解三者的分工：

• AIS 是长期知识中枢：保存资料、Prompt、项目状态、决策、成果和可复用经验，并提供目录、权限、检索和版本能力；
• Codex 是智能执行引擎：理解任务，读取本地与远程资料，分析问题，生成代码、文档、表格和演示材料，并把值得长期保留的成果写回 AIS；
• AIS-Skill 是连接协议：告诉 Codex 如何定位、搜索、读取、新建、修改、上传、下载和返回 AIS 文档链接。

对我来说，这不是给 AI 增加一个网盘，而是在搭建一套“知识可以积累、项目可以延续、方法可以复用”的工作系统。

接通之后，我能让它做什么？

接通之后，我先做的不是批量写入，而是从只读能力开始验证。我发现 AIS-Skill 已经覆盖了一套比较完整的知识协作闭环。

我不需要记忆底层命令，只要直接告诉 Codex：

使用 AIS，在“AAAA知识库”中搜索房产权属证书相关材料，读取最相关的内容，形成一份带来源的总结。只读分析，不修改知识库。

或者：

把我们刚才确认的项目结论整理成决策记录，保存到 AIS 的项目目录中，保存后返回文档链接。

我现在如何让 AIS 和 Codex 配合？

我认为，两者最有价值的合作方式并不是“临时查询一次资料”，而是形成一个持续循环：

1. 任务开始前恢复上下文：Codex 从 AIS 读取项目说明、最新进展、历史决策、约束条件和优秀样例；
2. 任务执行中组合上下文：同时使用 AIS 的长期知识、本地工作文件、当前对话和必要的外部资料；
3. 形成可审阅成果：Codex 在本地生成并验证 Markdown、Word、PPT、Excel、PDF 或代码；
4. 任务结束后沉淀知识：将确认过的结论、Prompt、交付物、经验和下一步计划写回 AIS；
5. 下一次从上次结束处继续：新的会话不再从零开始，而是从最新项目状态继续推进。

我把这套循环概括为：

读取上下文 → 执行任务 → 人工确认 → 回写知识 → 持续复用

这与我对 Skill 的理解也一致：一套已经跑通的工作流程，不应该在每次新对话中重新粘贴长篇 Prompt，而应该逐步固化为可以反复调用的能力。OpenAI 官方也建议把成功对话、规则、命令、脚本和优秀样例沉淀为可复用 Skill，参见：Save workflows as skills。

我的第一个计划：把 common 从“文件堆”变成公共知识底座

我的本地 common 目录保存了产品资料、客户案例、功能清单、模板、方法论和许多经常引用的文件。它很重要，但随着文件越来越多，也逐渐像一个“熟悉的仓库”：我大致知道东西在那里，却不一定能快速找到，也不一定知道哪个版本最新。

我准备在 AIS 中建立一个对应的公共资料库：

Common公共资料库/
├── 01-产品资料
├── 02-功能清单
├── 03-客户案例
├── 04-解决方案
├── 05-报价与合同模板
├── 06-项目文档模板
├── 07-研究与方法论
├── 08-Prompt资产
└── 90-历史版本

我不会把 AIS 当作本地目录的机械镜像。本地 common 仍然承担原始文件和编辑工作区的角色；AIS 则承担知识化管理、全文检索、版本确认和跨项目复用。我的原则是：本地加工，AIS 沉淀；本地保留工作现场，AIS 保存长期资产。

典型提示词：

读取本地 common 目录中的 AIS 功能清单，并在 AIS 的 Common公共资料库中搜索已有版本。对比差异后生成更新建议，暂时不要覆盖任何文件。

从 Common公共资料库检索银行业客户案例、功能清单和产品架构，结合当前客户需求形成一份售前方案提纲，每个关键结论注明来源。

我的第二个计划：让每个项目拥有自己的长期上下文

我希望一个项目不再只有散乱文件，而是拥有自己的“项目大脑”。为此，我准备给每个项目建立统一目录：

项目名称/
├── 00-项目导航
│   ├── 项目说明.md
│   ├── 当前状态.md
│   └── 关键联系人.md
├── 01-需求与输入
├── 02-Prompt
├── 03-Codex生成内容
├── 04-决策记录
├── 05-会议纪要
├── 06-日报与周报
├── 07-交付成果
├── 08-问题与风险
└── 90-归档

其中，我最看重的是“项目导航”。以后 Codex 每次进入项目时，不必遍历所有文件，只要先读取项目说明、当前状态和关键决策，就能快速恢复上下文；需要深入时，再搜索具体资料。

一个完整的项目启动提示词可以这样写：

使用 AIS，为“XX项目”建立标准项目目录。把我提供的原始需求保存到“01-需求与输入”，把本次有效 Prompt 保存到“02-Prompt”，把你生成并经我确认的成果保存到“03-Codex生成内容”。同时维护“当前状态”和“决策记录”。新建前先检查是否已经存在同名项目。

项目恢复提示词则更简单：

使用 AIS 恢复“XX项目”的上下文。读取项目说明、当前状态、最近三条决策、未关闭风险和最新日报，然后告诉我今天最应该推进的三件事。只读，不修改。

我的第三个计划：建立 Skill 资产库，让成功经验真正复用

我越来越确信，很多高质量工作并不是靠一个神奇 Prompt 完成的，而是依赖一组稳定的规则、参考资料、脚本、模板和验证步骤。这样的工作流非常适合沉淀为 Skill。

因此，我准备在 AIS 中建立 Skill 资产库：

Skills资产库/
├── rag-capacity-planner/
│   ├── SKILL.md
│   ├── references/
│   ├── scripts/
│   ├── examples/
│   └── CHANGELOG.md
├── bank-solution-writer/
├── project-weekly-report/
└── proposal-generator/

这里有一个很容易误解的边界：AIS 可以保存、检索和版本化 Skill 文件，但 Codex 运行时仍需要把 Skill 安装到本地技能目录，才能自动发现和执行。因此，我设想的流程是：

AIS 保存 Skill 主版本 → Codex 下载到本地 → 安装并验证 → 使用中积累反馈 → 更新 AIS 主版本

典型提示词：

回顾我们这次成功完成的银行业 RAG 硬件测算过程，把输入要求、计算规则、报告结构、检查项和优秀输出整理成一个 Codex Skill。先生成草案和目录结构，不要直接覆盖现有 Skill。

从 AIS 的 Skills资产库读取“项目周报”Skill，与本地安装版本比较差异，列出升级建议；我确认后再更新。

这样，我的经验就不再只存在于某次聊天中，而会逐渐变成可以重复执行、验证和升级的数字化能力。

我的第四个计划：让每天的项目工作自动留下“可继续的现场”

我经常同时推进多个项目。真正消耗精力的，不只是做事本身，还有第二天重新回忆“昨天做到哪里”。所以，我希望项目日报不只是记录“今天做了什么”，还要回答：完成了什么、产生了什么成果、做出了什么决定、遇到了什么风险、有哪些待办、明天优先做什么。

我可以让 Codex 综合当天的本地文件变化、AIS 文档更新、会议纪要和当前对话，形成结构统一的日报：

项目日报｜YYYY-MM-DD

1. 今日完成
2. 今日新增或更新的交付物
3. 关键决定及依据
4. 问题与风险
5. 未完成事项
6. 明日优先计划
7. 相关文档链接

可以直接使用下面的提示词：

使用 AIS 和当前本地项目目录，为“XX项目”生成今天的工作总结。先读取昨日总结和当前状态，再检查今天新增或修改的文件、会议纪要和对话结论。区分“已完成”“进行中”和“待确认”，不得把计划写成完成。生成后保存到“06-日报与周报/YYYY-MM/”，并局部更新“当前状态”。

如果以后配合定时任务，我还可以在每天固定时间生成日报草稿，再由我确认后写入正式项目记录。我追求的不是完全无人值守，而是让信息收集和结构化过程自动完成，把自己的精力留给判断和确认。

真正让我看重 AIS 的，是它背后的企业知识工程

最开始，我关注 AIS-Skill（虽然是公司小伙伴们搞出来的，但我是真的第一次用），主要是想解决自己的上下文问题：把资料存好，让 Codex 找得到，让项目能够接着做。

但继续了解 AIS 之后，我发现个人知识管理只是一个很好的切入口。对企业而言，更困难的问题不是“有没有地方存文件”，而是：成千上万份文件怎样持续进入系统，怎样被加工成 Agent 真正能用的知识，又怎样长期保持正确、最新和安全。

这也是我认为 AIS 与普通网盘、传统文档库和简单向量库最不一样的地方。它试图构建的不是一次性知识库，而是一条持续运转的企业知识供应链。

TorchV 把这条主线概括为“接入—加工—入库—治理—检索—应用—反馈—优化”，并明确区分“知识接入”和“知识准入”：文件进入平台，不代表它已经有资格被 Agent 使用。

第一步：让企业知识自动进入，而不是靠人反复上传

企业知识不会只存在于某个文件夹。它可能在本地文件、NAS、OSS、S3、MinIO、FTP/SFTP、飞书、Confluence、SharePoint、Office 365、数据库、OA、CRM、ERP、工单系统或网页中。

我设想中的企业接入方式，不是项目上线前集中导入一次，而是建立持续同步：

• 存量文件通过批量上传、文件夹或压缩包完成初始化；
• 对象存储、文件系统和办公平台按照周期增量同步；
• 数据库按限定 SQL、数据视图和字段映射接入结构化数据；
• 业务系统通过 OpenAPI、Webhook 或适配器推送变化；
• 文件上传、定时任务、数据变更或外部事件可以自动触发后续知识加工。

但自动接入不能等于盲目同步。来源系统是否权威、删除如何处理、更新频率多高、失败是否重试、权限是否同步，都需要在接入阶段定义清楚。否则，自动化速度越快，错误知识传播得也越快。

第二步：把“文件”加工成 Agent 可以使用的知识

一份 PDF 或 Word 被上传，并不意味着 Agent 已经理解它。文档可能有复杂表格、扫描图片、页眉页脚、目录、附件、印章，也可能混有乱码、重复段落、敏感信息和失效内容。

AIS 的知识加工可以把这些工作编排成可视化知识流：

1. 对 PDF、Word、Excel、PPT、网页、图片、音频、视频等内容进行解析；
2. 通过 OCR、版面识别、表格识别、ASR 或多模态模型提取结构；
3. 清除噪声、统一格式、识别重复段落，对隐私和敏感字段进行审核或脱敏；
4. 按语义、章节、固定长度或业务规则切片；
5. 自动补充标题、摘要、目录路径、来源、责任人、有效期、标签和其他元数据；
6. 根据场景生成标准问答、相似问法，或抽取条款、参数、风险、实体和关系；
7. 经过规则校验、模型复核或人工审批后，再写入正式知识库并建立索引。

我很认同“知识准入”这个概念。对普通内部资料，可以采用自动准入；对监管制度、对客口径、财务数据和高风险操作规则，则应该在发布前让业务人员复核。AI 可以承担大量机械加工，但不能替代知识责任人做最终裁决。

第三步：版本合并不是覆盖文件，而是确定“当前有效知识”

企业知识最麻烦的场景之一，是同一主题同时存在多个版本。新制度已经发布，旧制度还在知识库；不同部门各自上传了一份稍有差异的产品说明；同一个项目方案经过多人修改，却没人说得清哪一份可以正式使用。

我理解的“版本合并”，不是简单地拿新文件覆盖旧文件，而应该是一条可追溯的治理流程：

识别来源和版本
→ 对比正文、元数据和权限差异
→ 检测重复、冲突和替代关系
→ 由规则或责任人决定合并、替换、并存或驳回
→ 保留旧版本和处理记录
→ 重新解析、切片、生成摘要与索引
→ 将新版本纳入正确的应用和 Agent 范围

AIS 已具备在线文档多版本、差异对比、历史回滚和编辑记录等基础能力；结合知识健康对重复、冲突和过期内容的识别，可以把版本问题转化为治理任务。对于可以明确判断的变化，流程可以自动完成合并和替换；对于制度口径、业务冲突和高价值文档，系统更适合给出差异和建议，由责任人确认哪个版本生效。

这里最重要的不是“保留了多少份文件”，而是 Agent 在执行任务时能否清楚地知道：哪一份当前有效，哪一份已经失效，为什么发生替换，旧版本是否只用于审计。

第四步：权限必须进入检索和生成链路

如果知识库只在页面上做权限控制，而检索服务把全部内容都召回给模型，所谓企业级安全就只是表面安全。

AIS 支持从组织、部门、团队和个人维度管理知识库及文档权限，文档可以继承知识库权限，也可以按照需要设置只读、编辑、下载等更细粒度的访问范围。对我来说，更关键的是权限不仅决定用户能否打开文件，还应该继续作用于检索、问答和 Agent 上下文：

• 用户无权查看的文档，不应该出现在检索候选中；
• Agent 代表谁执行，就只能使用这个身份有权调用的知识；
• 应用配置权限不应自动等于全部知识读取权限；
• 下载、导出、权限变更和高敏感操作应留下审计记录；
• 人员调岗或离职时，知识资产需要交接，原权限需要及时回收。

这也是为什么我不会把日常 Open Key 开成“全库、全权限”。个人资料、项目资料和生产知识应该分区管理，读、写、发布和删除权限也应该分开。

第五步：用知识健康让知识长期“保鲜”

知识库在刚建好时通常比较整洁，真正困难的是半年以后。新文件不断进入，制度持续变化，多个部门共同维护，解析模型和切片规则也会升级。如果没人持续治理，RAG 效果会在不知不觉中下降。

AIS 的知识健康关注的不只是文件数量，而是知识是否适合被长期调用。典型问题包括：

• 重复知识：多份内容相同或高度相似的资料同时参与召回；
• 冲突知识：不同文档对同一问题给出不一致口径；
• 过期与失效：制度到期、产品下线或文档已被新版本替代；
• 低质量解析与切片：表格错位、标题丢失、片段缺少上下文；
• 来源与引用失效：答案片段无法回到权威原文；
• 知识缺失：用户频繁提问，但库中没有足够资料覆盖；
• 责任缺失：知识没有维护人、确认时间或有效期。

这些问题可以通过定期巡检或数据变化触发，形成问题清单，再分派给责任人处理。处理动作可能是重新解析、调整切片、补充标签、合并版本、标记失效、限制调用、补充标准问答或重新发布。用户点踩、低命中问题、引用率和问答日志也可以反向推动知识优化。

在我看来，知识健康真正改变的是企业对知识库的认识：知识库不再是“建完就结束”的项目，而是一项需要指标、责任人和持续运营的业务能力。

最终目的：为 Agent 提供可信的企业级上下文

Agent 与普通问答最大的区别，是它会根据知识做判断，甚至进一步调用工具和执行业务动作。如果上下文过期、冲突或越权，问题就不再只是“回答得不好”，而可能变成错误办理、错误审核或错误决策。

因此，我认为高质量的企业级上下文至少应该具备五个特征：

• 正确：内容经过加工和必要复核；
• 当前有效：版本、状态和有效期清楚；
• 权限匹配：用户和 Agent 只获得被授权的内容；
• 可以溯源：结论能够回到原文、来源和处理记录；
• 可以行动：知识被结构化为规则、步骤、参数、模板或可调用能力。

当这条链路真正跑起来，Agent 获得的就不只是更多文档，而是一套经过加工、授权、治理和持续优化的企业上下文。模型可以不断更换，但企业积累下来的知识、权限、流程和反馈会成为长期资产。

沿着这条路，我还想继续做什么？

当公共资料、项目上下文和 Skill 资产逐渐积累后，我觉得 AIS 与 Codex 还能衍生出更多高价值场景。

1. 建立企业 Prompt 资产库

我想保存的不只是 Prompt 文本，还包括适用场景、输入要求、优秀样例、失败案例、版本和评价。Codex 可以根据任务选择最合适的 Prompt，并把实际效果写回评价记录。

2. 自动生成项目驾驶舱

我可以从项目状态、日报、风险、决策和交付物中自动生成一页式项目简报，回答“做到哪里、卡在哪里、下一步是什么”，不用每次重新翻阅几十份文档。

3. 建立决策记忆

我经历过的一些返工并不是因为没有资料，而是忘记了“当时为什么这样决定”。将背景、选项、决定、依据、影响和责任人形成决策记录后，Codex 在提出新方案时就可以主动检查是否与历史决定冲突。

4. 做知识冲突和过期检查

我可以让 Codex 定期搜索同一主题的多份制度、方案和功能清单，识别版本冲突、过期描述和无人维护的知识，输出待确认清单，而不是擅自删除。

5. 从项目交付反哺产品

我还希望把不同客户项目中的需求、问题、定制功能和验收反馈进行聚类，形成产品共性需求、行业差异和升级建议。这样，项目知识就不会停留在一次性交付里，而会持续反哺产品路线。

6. 快速生成新的项目空间

新项目启动时，我可以让 Codex 复制标准目录和模板，从公共资料库选择相关案例、方案和 Prompt，再生成项目导航页。项目从第一天开始就具备结构化记忆，而不是结束时才补文档。

7. 建立个人数字工作台

除了客户项目，我还想用 AIS 保存研究主题、读书笔记、文章素材、产品思考、会议记录和年度目标。Codex 负责持续整理、连接和输出，AIS 负责长期保存和检索，逐步形成真正属于我的知识与能力体系。

我也给自己划了几条边界

使用得越深入，我越觉得权限和治理不能被当成附属功能。

第一，我不会把 AIS 当成 Codex 的本地磁盘。代码仓库、Office 文件加工、编译产物和临时文件仍在本地工作区处理；AIS 更适合保存可检索、可复用、可追溯的知识资产和正式成果。

第二，我不会把所有聊天自动写入 AIS。真正值得沉淀的是确认过的事实、决定、经验、Prompt、项目状态和交付物，而不是每一次临时推理。

第三，我会坚持最小权限。日常 Key 只开放必要的知识库和读写权限，删除、批量移动、组织管理等高风险权限不默认开放。生产资料和个人资料最好使用不同知识库或不同 Key 隔离。

第四，修改前先读取，写入后再复查。已有文档尽量做局部更新；移动、删除和发布必须经过我的明确指令；同名文档优先使用稳定 ID 定位。

第五，机器生成不等于事实成立。日报中的完成状态、项目决策、客户承诺和风险结论都要有来源或经过确认。AIS 解决的是知识持续性，不会自动替代我的责任判断。

接下来，我准备先跑通四个小闭环

我不准备一开始就设计一个庞大的知识体系，而是先从四件能够真实产生价值的事情开始：

1. 在 AIS 中建立 Common公共资料库，先迁移最常用的产品资料、功能清单和模板；
2. 选择一个正在进行的项目，按标准结构建立项目目录；
3. 把一个已经成功执行多次的流程沉淀为 Skill，例如项目周报或方案生成；
4. 连续一周让 Codex 生成项目日报，并在每天开始工作时从 AIS 恢复上下文。

一周之后，我再复盘：哪些内容真的被重复使用，哪些目录没人访问，哪些 Prompt 值得升级为 Skill，哪些写入动作需要更严格的审批。我更愿意让知识结构随着真实工作生长，而不是一开始就追求形式上的完美。

写在最后：我想要的不是一个“更会聊天”的 AI

单独使用 Codex，它是一位能力很强的执行者；单独使用 AIS，它是一套能够长期积累、加工和治理知识的引擎。AIS-Skill 把二者连接起来之后，我期待自己的工作方式发生这些变化：

• 我的资料不再只是被存放，而是可以被任务主动调用；
• 有价值的对话不再随会话结束消失，而是沉淀为项目记忆；
• Prompt 不再反复复制，而是逐渐演进为标准流程和 Skill；
• 项目不再只依赖我的脑海维持连续性，而是拥有可追溯的长期上下文；
• Codex 不再每次从零开始，而是能够站在过去成果之上继续工作。

所以，我真正想要的不是一个“更会聊天”的 AI，而是一位能够理解历史、遵守权限、引用证据、延续项目并沉淀方法的长期协作者。

这也是我目前对 AIS 与 Codex 组合最期待的地方：不是让 AI 多记住几份文档，而是把我个人以及企业积累的知识，真正转化成可重复、可审查、可持续改进的行动能力。

如果您觉得本文对您的企业AI落地有帮助，可以在公众号置顶文章中联系我，欢迎大家咨询交流。