摘要
本文提出一种将 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（历史）--- 已发生的一切
覆盖产品从第一行代码到今天的所有关键事实：
- **模块深度文档：**每个功能模块的架构、代码路径、已知问题模式、设计决策、测试覆盖
- **跨模块依赖矩阵：**模块 A 改了什么会影响模块 B
- **破坏性变更索引：**历史上所有 breaking changes
- **被否决需求索引：**所有被拒绝的功能请求及其原因
History 回答的核心问题是："这件事以前发生过吗？结果如何？"
Present（现在）--- 当前状态快照
实时（或近实时）反映产品的当前状态：
- **Backlog 快照：**所有未完成的 issue，按模块、优先级、版本分类
- **版本计划：**当前和未来版本的排期
- **团队配置：**谁负责什么模块
Present 回答的核心问题是："现在是什么状况？"
Future（未来）--- AI 的判断产出
这是 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 能力随知识库增长而增强：不依赖更强的模型，而是更丰富的记忆
- 研发决策从"经验驱动"变为"数据驱动"：每个决策都有历史依据
六、前提条件
这个方法论不是适用于所有公司的银弹。它有明确的前提条件：
- **产品必须有足够的历史：**至少 3-5 年的 issue 追踪数据。如果你的产品刚起步，先把 issue 管理做好。
- **必须有结构化的 issue 管理：**标签体系、模块分类、milestone 管理。垃圾进垃圾出。
- **必须有人懂产品和技术：**知识库的初始构建需要同时理解产品逻辑和技术实现的人来引导 AI。纯靠 AI 自动生成的知识库是垃圾。
- **组织必须愿意改变工作流：**知识库维护必须融入日常研发流程，而不是额外负担。
七、方法论的层次
我们将这个方法论抽象为三个递进的层次，适用于不同阶段的公司：
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