跳到主要内容

KnowFlow 2025 年度回顾：一群中年程序员的创业之路

前言​

2025 年即将进入尾声。

这一年里，一种强烈的冲动始终在心里涌动—— 想把这一年的创业经历，以及过程中真实踩过的坑、做过的判断、得到的经验教训，完整地记录下来。

在这个时间节点上，给自己一个交代。

回头看清来路，才能更好地走向下一段。

背景​

我本人程序员出身，中年宅男一枚。

早些年在京东、讯飞、VIPABC 等公司工作， 技术路径也比较典型： 从 Android 移动端，到 软硬结合产品（翻译机、座舱等）， 再到后期聚焦 大数据领域的数据采集、治理和用户行为分析。

今年，在一个并非刻意规划的契机下， 我和几位同样背景的伙伴，开始投身 知识库产品 的研发。

团队规模不大，4～5 人， 几乎清一色都是程序员。

我对 "程序员" 的一个长期不适​

坦白说，我一直对一种常见的程序员画像感到不适：

  • 精通或熟悉某一端语言
  • 按产品经理、项目经理的规划推进需求
  • 追求技术细节的极致，却很少参与方向决策
  • 对产品成败没有真正的决定权

整个过程是被动的， 甚至连开发节奏都不是自己说了算。

我能理解，这在国内的组织结构里很常见， 但我始终不太认同。

在我理想中的状态里：

程序员是成年人，应该对产品负责，对方向负责，也对结果负责。

我们应该有能力、也有权利去：

  • 决定做什么功能
  • 决定产品原型和交互方式
  • 决定技术方案和研发节奏
  • 甚至自己去卖产品、聊客户、做售前售后

尤其是在 AI 时代， 工具在降低门槛，能力边界在被不断拓宽。

为什么要给自己设限？

于是，一群中年程序员的"浪漫之旅"，就这样开始了。

为什么选择知识库​

选择知识库，并不是追热点。

恰恰相反，这是一个相对冷门、但确定性很高的方向。

原因主要有三点：

第一，团队基因匹配。 我们长期从事数据采集与数据治理工作， 而知识库，本质上就是非结构化数据治理能力的延伸。

第二，对趋势的判断。 在 2024 年底，我们做过一次比较系统的判断： 2025 年，很可能是 Agent 集中爆发的一年。

但 Agent 强依赖行业 Know-how 和业务深度， 对于一个小团队来说，投入产出并不匹配。

第三，企业 AI 路径绑不开。 不论 Agent 如何发展， 企业最终都绑不开对自身数据的理解和利用。

知识库不是风口，但它是地基。

为什么选择基于 RAGFlow 二次开发​

方向明确之后，团队内部其实有过一轮不小的分歧：

  • 从 0 到 1 全自研：完全可控，但重复造轮子
  • 基于开源二开：效率高，但要承受黑盒和适配成本

最终促成共识的，是对产品定位的重新确认：

做私有化场景下，最准确的知识库。

围绕这个目标，我们做了非常现实的评估：

  • 从 0 到 1 做一个知识库 Demo，并不难
  • 但要做到业内较高的准确率，需要大量长期积累

在多个开源方案中，RAGFlow 在准确性上的口碑相对突出； 但同时也存在配置复杂、工程深度不足、企业级能力薄弱等问题。

这恰恰给了我们机会。

在横向对比了 QAnything、FastGPT、MaxKB 等方案后， 我们最终选择以 RAGFlow 为基础进行二次开发。

真实企业眼中的 RAG 痛点​

在立项之后，我们通过以往积累的人脉， 和多位企业负责人做了深入交流。

结论非常一致。

幻觉，本质是准确率问题​

在知识库场景下， 企业并不怕模型"不够聪明"， 怕的是答错了，还说得很确定。

尽管 RAGFlow 已在分块预览、引用标注等方面做了不少努力， 但受限于文档解析、分块策略、检索链路和上下文长度， 幻觉问题依然存在。

私有化部署，是系统工程​

RAG 系统对环境极其挑剔：

  • GPU 显存与架构
  • NVIDIA Driver / CUDA / PyTorch
  • nvidia-container-toolkit
  • x86 / ARM / 国产信创体系

很多问题，不是"能不能跑"， 而是 能不能在生产环境稳定跑。

工程化能力，决定能不能上线​

行业里有句话很真实：

RAG POC 无可挑剔，一上生产就废。

企业愿意花人力提升准确率、做人工修正， 但不接受粗糙的文档解析和不可评估的问答效果。

企业级能力不是"可选项"​

RBAC 权限管理、 企业微信 / 钉钉 / Dify 对接， 这些不应该只是解决方案， 而应该是产品本身的一部分。

KnowFlow 的产品取舍​

围绕上述问题，我们做了一些明确取舍。

  • 引入多种离线 OCR 引擎，提升文档解析质量
  • 针对不同文档结构，设计多种分块策略
  • 补齐工程化能力，而不是一味追模型
  • 多模态能力优先解决真实使用场景

产品定位也逐渐清晰下来：

做私有化场景下，准确、可靠、可落地的知识库产品。

从 MVP 到真实用户​

打磨 MVP​

2025 年 3～6 月，我们只做一件事： 把产品做到 可用、可卖、可规模化。

期间，有创投机构提出天使轮合作， 最终我们选择了婉拒。

不是排斥融资， 而是清楚地知道： 早期阶段，我们缺的不是钱， 而是对行业的理解、对产品的打磨，以及真实反馈。

开源，连接真实世界​

作为技术团队，我们选择了开源作为切入口。

KnowFlow 在 GitHub 开源后， 逐步积累了 4000+ 粉丝和 1500+ 社群用户。

早期我们几乎和社区深度互动， 后期受限于精力，也不得不有所取舍， 但始终心怀感激。

有开发者无偿提供建议， 甚至提供服务器资源和商业化思路。

那种被信任的感觉，很难忘。

第一笔订单​

第一笔订单金额并不大，只有 2000 元。

但那一刻， 我们第一次清晰地确认： 这件事是有价值的。

我至今记得团队成员当时的眼神， 那是一种"终于被现实验证"的感觉。

后来，一切开始慢慢滚动起来，正如武侠小说的主角光环。

截至目前，我们已服务 30+ 企业用户， 覆盖制造业、高校、研究院、国央企等多个领域。

总结与展望​

2025 年，是 KnowFlow 的萌芽期。

挑战依然很多：

  • Agentic RAG
  • 端到端多模态
  • 长上下文模型演进
  • 市场、售前、售后能力建设

但换个角度看：

如果这些问题都已经被完美解决， 可能也就没有我们的机会了。

未来，KnowFlow 会持续深耕：

  • 私有化知识库
  • 工程化能力
  • 多模态 RAG

并逐步联合硬件厂商、国产化生态， 提供更完整的一体化解决方案。

开源社区​

可关注公众号 「KnowFlow 企业知识库」 获取最新动态、商务咨询与技术支持。