探讨利用Skills与RAG构建企业本地知识库及工作流

背景

随着大语言模型（LLM）在企业级应用中的深入，许多公司开始探索如何将过往的项目经验、技术沉淀转化为可复用的资产，以提升未来类似项目的开发效率和质量。这一需求的核心在于构建“公司本地知识库”或特定的“工作流（Workflow）”，旨在让大模型能够基于历史数据进行推理和辅助，从而在遇到相似场景时提供针对性帮助。

然而，在实际落地过程中，开发者面临着诸多困惑与选型难题。一方面，大型科技公司（大厂）通常对文档权限有严格管控，且其内部知识库建设往往不对外公开或难以直接复用；另一方面，开源社区提供了大量工具链（如 RAG、Skills、Subagent 等），但功能繁杂且适用场景各异，导致初学者或中小团队在选型时容易陷入“技术栈混乱”的困境。本文基于 LINUX DO 社区的一次技术讨论，梳理了一位开发者在构建本地知识库与工作流时的真实诉求、调研路径及遇到的瓶颈。

核心内容

该讨论围绕“如何将公司历史项目经验转化为大模型可复用的知识或技能”这一核心诉求展开。参与者首先明确了目标：利用已有项目经验，通过大模型辅助未来相似项目的开发。

在调研过程中，作者尝试了多种技术方案，并记录了各自的优缺点及疑虑：

1. Skills（技能模块）： 作者尝试将公司做过的项目经验编写为 Skills 格式。然而，实际体验发现效果并不理想，感觉“没那么好用”。这暗示了简单的技能封装可能无法有效承载复杂的项目上下文或深层逻辑。

2. Kerminal 与计算加速： 提到了一个名为 Kerminal 的工具，号称基于 CC（可能是指某种计算框架或编译器）进行计算加速。作者疑惑是否可以将工作流融入其中，但缺乏对该工具与工作流结合可行性的明确结论。

3. Workflow（工作流）： 作者担心传统的工作流定义过于固定，缺乏灵活性。虽然可以考虑将相关项目写成固定的步骤（Step），但这也限制了模型的动态适应能力。

4. ai-dynamo / aiconfigurator（仿真与寻优）： 这类工具侧重于仿真、寻优和执行。但作者指出，大多数公司项目并不具备复杂的寻优和仿真工具链。此外，如何确定“搜索空间”本身就是一个巨大的难题，使得这类重型工具在通用场景下难以落地。

5. RAG（检索增强生成）与 Wiki：

   • 技术陈旧感：作者认为传统的 RAG 技术可能显得“太旧”，并提到了 llm-wiki-agent 等具体实现。
   • RAGFlow 的集成难题：虽然 RAGFlow 是搭建知识库的热门选择，但作者困惑于如何将其与公司内部广泛使用的 Codex 等代码编辑器结合。目前看来，它更像是一个独立的网页端使用体验，与智谱清言等智能体并无本质区别。
   • 成本与收益：对于小公司而言，构建复杂的 RAG 系统是否属于“舍本逐末”存在争议。
   • Wiki 的倾向性：尽管 L 站（Linux DO）部分帖子指出大规模本地数据在 Wiki 支持上表现不佳，但甲方（客户）在本地知识库项目中仍倾向于选择 Wiki 方案。

6. Subagent（子智能体）： 作者质疑 Subagent 对自身诉求的价值。他认为 Codex 等工具已经在 GPT-5.5 等模型中很好地实现了多智能体任务分发，因此单独引入 Subagent 可能显得多余。

7. 运行时数据面板： 有人建议构建硬件参数接口面板以监控项目执行。但作者认为，让 GPT 直接分析执行时的数据即可，针对不同项目定制面板纯属浪费时间，因为面板需求因项目而异，维护成本高。

最终，作者感叹自己“学杂了”，调研过程混乱，难以理清头绪，并诚恳请求社区前辈指点迷津，优化问题表达。

关键要点

• 核心目标：将公司历史项目经验沉淀为可复用的知识库或 Skills，以辅助未来相似项目的开发。
• Skills 局限性：直接将项目经验封装为 Skills 效果不佳，可能无法有效处理复杂上下文。
• 工作流僵化风险：传统 Workflow 定义过于固定，可能限制大模型的动态推理能力；而基于仿真寻优的工具（如 ai-dynamo）因缺乏通用仿真工具和搜索空间定义难题，适用性受限。
• RAG 落地困境：
  • 虽然 RAG 是主流方案，但存在“技术过时”的感知。
  • 与现有开发工具（如 Codex）的集成体验割裂，缺乏无缝衔接。
  • 小公司自建复杂 RAG 系统的投入产出比（ROI）存疑。
  • 尽管技术社区对 Wiki 支持大规模数据持保留态度，但甲方市场仍偏好 Wiki 方案。
• 工具冗余质疑：
  • Subagent：鉴于 Codex 等工具已具备优秀的多智能体任务分发能力，单独引入 Subagent 必要性低。
  • 运行时面板：定制化硬件监控面板维护成本高且通用性差，建议直接利用 LLM 进行运行时数据分析，避免重复造轮子。
• 选型建议方向：避免陷入重型仿真或过度定制化的工具链，应关注知识库与现有开发环境（IDE/Codex）的深度融合，以及轻量级、高 ROI 的知识沉淀方案。

意义与影响

此次讨论反映了当前企业级 AI 应用落地中的一个典型痛点：技术选型过载与业务需求简化之间的矛盾。

1. 对中小企业的启示： 对于资源有限的小公司或团队，盲目追求复杂的 RAG 架构、仿真寻优或定制化数据面板往往是“舍本逐末”。应优先考虑轻量级、易集成、高 ROI 的方案。例如，与其构建复杂的本地知识库，不如优化现有代码编辑器（如 Codex）的插件生态，实现更自然的上下文注入。

2. 对技术选型的反思： 社区中流行的“最佳实践”（如 Wiki、Subagent、复杂 Workflow）并非放之四海而皆准。开发者需警惕工具链的过度工程化。当现有工具（如 Codex 的多智能体能力）已能满足基本需求时，无需引入额外的复杂组件（如 Subagent）来增加系统熵值。

3. 甲方需求与技术现实的错位： 甲方倾向于 Wiki 方案，而技术社区认为其在大规模数据支持上存在短板。这提示技术提供方需要在满足甲方偏好（易用性、规范性）与技术可行性（检索效率、数据规模）之间找到平衡点，可能需要通过混合架构或优化索引策略来解决。

4. 知识沉淀的新范式： 传统的“文档库”思维正在向“可执行技能（Skills）”和“智能工作流”转变。但如何确保 Skills 的通用性和准确性，以及如何将隐性项目经验显性化为模型可理解的指令，仍是亟待解决的关键问题。未来的方向可能在于更细粒度的上下文管理，而非单纯的知识堆砌。