构建软件公司的 JARVIS：AI Native 研发中枢的方法论

新一代 Agentic BI，衡石科技，北京。

摘要

本文提出一种将 AI 从辅助工具转变为软件公司研发核心成员的方法论框架。通过在衡石科技，一家拥有 10 年历史、5.7 万个 issue 的 BI 软件公司中的实践，我们验证了“产品知识库”作为 AI 研发中枢 JARVIS 记忆基座的可行性。

核心发现是：AI 参与研发的瓶颈不是模型能力，而是组织记忆的结构化程度。本文从理论层面阐述为什么需要这样做、做什么、以及这样做的价值，但不涉及具体实施步骤。

一、问题：为什么 Copilot 不够

大多数软件公司对 AI 的使用停留在“代码补全”层面：GitHub Copilot、Cursor、各种 IDE 插件。这些工具在战术层面有效，但存在一个根本性缺陷：

它们没有记忆。

当一个工程师面对一个 bug 时，他不只是在“写代码”。他需要知道：

• 这个模块 3 年前为什么这样设计，即设计决策。
• 类似的 bug 之前是否出现过，即历史模式。
• 改了这里会影响哪些其他模块，即跨模块依赖。
• 哪些方案曾经被否决过以及为什么，即被否决需求。
• 这个功能的测试覆盖盲区在哪里，即质量地图。

这些知识存在于老员工的脑子里，散落在 GitLab 评论中，埋在 Slack 历史消息里。当老员工离职，这些知识就消失了。

Copilot 能帮你写一个函数，但它不知道这个函数为什么不应该被写。

二、论点：AI 研发中枢需要“记忆”

我们提出一个核心论点：

要让 AI 从“工具”升级为“团队成员”，必须先解决组织记忆的结构化问题。模型能力是充分条件，结构化记忆才是必要条件。

类比人类：一个新入职的天才工程师，等价于最强的 LLM，如果没有人给他讲公司产品的历史、设计决策、踩过的坑、被否决的方案，他也只能写出“技术上正确但业务上错误”的代码。

JARVIS 不是一个更好的 Copilot。JARVIS 是一个拥有公司完整产品记忆的研发团队成员。

三、框架：三层时态架构

产品知识库的核心架构是按时态组织的三层结构。

History：历史，已发生的一切

History 覆盖产品从第一行代码到今天的所有关键事实：

• **模块深度文档：**每个功能模块的架构、代码路径、已知问题模式、设计决策、测试覆盖。
• **跨模块依赖矩阵：**模块 A 改了什么会影响模块 B。
• **破坏性变更索引：**历史上所有 breaking changes。
• **被否决需求索引：**所有被拒绝的功能请求及其原因。

History 回答的核心问题是：“这件事以前发生过吗？结果如何？”

Present：现在，当前状态快照

Present 实时或近实时反映产品的当前状态：

• **Backlog 快照：**所有未完成的 issue，按模块、优先级、版本分类。
• **版本计划：**当前和未来版本的排期。
• **团队配置：**谁负责什么模块。

Present 回答的核心问题是：“现在是什么状况？”

Future：未来，AI 的判断产出

Future 是 JARVIS 真正产生价值的层，基于 History 和 Present 的知识做出产品经理级别的判断：

• **去重检测：**新 issue 是否与历史 issue 重复？
• **根因分析：**这个 bug 的本质原因是什么？是设计缺陷还是实现失误？
• **跨模块影响评估：**修复这个 bug 会影响哪些其他模块？
• **实现复杂度估算：**根据历史类似修复的工时推算。
• **历史教训检索：**以前类似的决策是否踩过坑？

Future 回答的核心问题是：“应该怎么做？”

四、关键洞察

被否决的需求是最有价值的知识

在我们的实践中，5.7 万个 issue 里有 7,311 条被否决的需求，包含 by design、wontfix、not a bug、duplicate 等类型。

这些被否决的需求蕴含了比已实现功能更重要的知识：它们记录了“为什么不做”。一个不知道“为什么不做”的 AI，会反复提出已经被否决的方案，浪费所有人的时间。

94 个 bug 可能来自同一个设计缺陷

我们对“过滤器快照”功能做了一次深度分析：这个功能自 2022 年上线以来累计产生了 94 个 bug。但这 94 个 bug 的根因可以归结为同一个设计缺陷：功能上线时没有定义清晰的边界，例如哪些场景支持、哪些不支持、字段删除或重命名后快照如何失效。

没有产品知识库的 AI 会逐个修复这 94 个 bug。有产品知识库的 AI 会指出这是一个结构性设计缺陷，需要从根本上重新定义功能边界。

这就是“工具”和“团队成员”的区别。

知识库必须与代码共同演进

产品知识库不是一次性文档工程。它必须：

• 与 Git 仓库同源管理，纳入版本控制、MR 审核和分支策略。
• 在每次 bug 修复后自动更新 known issues。
• 在每次设计决策后记录 decisions。
• 定期从 issue 系统同步 backlog 快照。

如果知识库和代码脱节了，AI 读到的就是过时的信息，做出的判断比没有知识库还危险。

五、价值模型

对工程师

对产品经理

对组织

• 知识不随人员流动而流失：所有设计决策、历史教训都结构化存储。
• AI 能力随知识库增长而增强：不依赖更强的模型，而是依赖更丰富的记忆。
• 研发决策从“经验驱动”变为“数据驱动”：每个决策都有历史依据。

六、前提条件

这个方法论不是适用于所有公司的银弹。它有明确的前提条件：

1. **产品必须有足够的历史：**至少 3 到 5 年的 issue 追踪数据。如果你的产品刚起步，先把 issue 管理做好。
2. **必须有结构化的 issue 管理：**标签体系、模块分类、milestone 管理。垃圾进垃圾出。
3. **必须有人懂产品和技术：**知识库的初始构建需要同时理解产品逻辑和技术实现的人来引导 AI。纯靠 AI 自动生成的知识库是垃圾。
4. **组织必须愿意改变工作流：**知识库维护必须融入日常研发流程，而不是额外负担。

七、方法论的层次

我们将这个方法论抽象为三个递进的层次，适用于不同阶段的公司。

Level 1：被动记忆

• 将现有文档、issue、代码注释整理成结构化知识库。
• AI 能搜索和引用，但不主动参与。
• **价值：**加速信息检索，减少重复劳动。

Level 2：主动参与

• AI 能自动对新 issue 进行分类、去重、影响评估。
• AI 参与 Code Review，基于历史知识提出审查意见。
• 知识库与 CI/CD 集成，自动更新。
• **价值：**AI 成为研发流程的一环。

Level 3：自主演进

• AI 能自主维护和扩展知识库。
• AI 能发现知识盲区并主动补充。
• AI 对产品方向提出数据驱动的建议。
• **价值：**AI 成为产品演进的核心参与者。

我们的实践处于 Level 1 到 Level 2 的过渡阶段。Level 3 是长期目标。

八、与现有范式的区别

关键区别：**本方法论强调“记忆”而非“检索”。**记忆是有组织的、有因果关系的、会自我更新的。检索只是从一堆文本中找相似片段。

九、结论

软件行业正在经历从“AI 辅助编码”到“AI 参与研发”的转型。但大多数公司卡在了中间：他们有了强大的 LLM，却没有让 LLM 真正理解自己产品的结构化记忆。

**JARVIS 不是一个产品，不是一个工具，不是一个 SaaS。**它是一种组织能力。它的核心不是选哪个 LLM 或用哪个框架，而是如何把十年的组织记忆变成 AI 可以理解和推理的结构化知识。

模型会迭代，框架会更替，但结构化的产品记忆只会越来越有价值。

本文来自 Thomas Chan（衡石科技高级工程师陈俊豪）的 Blog。

相关推荐

• 业界首发：HENGSHI CLI 正式发布，开启 Agentic BI 自动驾驶时代
• 你的产品在哪个象限？横轴：产品 AI 化深度 vs 纵轴：商业化高度
• 风暴眼中，回归本质｜衡石科技关于 AI 时代的思考与行动

关于衡石科技

衡石科技致力于在 Data+AI 的数据智能时代开创性定义新一代 Agentic BI，旗下产品 HENGSHI SENSE 作为企业级的数据智能引擎，赋能客户伙伴零代码构建垂直领域的 AI 分析智能体应用。

衡石科技成立于 2016 年，是国内数据分析平台领域唯一专注赋能企业级应用软件 SaaS 伙伴的产品厂商，服务 WPP、宝马、广汽本田、阳狮集团、蓝色光标、国药集团、亚马逊云科技、太太乐、元气森林等大型集团企业客户，同时也和菲尼克斯电气、Synagie（新加坡）、中国航信、深信服、金蝶云、浪潮云、致远互联、天润融通、宝尊电商、纷享销客、六度人和、明道云、北森酷学院等超过两百家企业应用软件 SaaS 落地深度合作，让 built-in 的商业智能分析即刻上线。