工程 → 知识库：项目沉淀入口设计（Scope v1）

一、当前定位（Scope 确认）

本设计仅覆盖：

工程项目如何被沉淀进入知识库。

不包含：

skills 体系设计
技术能力抽象体系
未来赋能闭环
agent 工作流设计

这是知识体系的第一层入口。

二、目标定义

建立一个稳定的工程沉淀流向，使：

代码变更
功能演进
架构调整

能够进入知识库，形成结构化资产。

当前阶段关注：

存量项目如何沉淀
增量项目如何持续沉淀

三、知识库入口结构

每个项目在知识库中拥有如下结构：

knowledge-base/ └── 项目名/ ├── commits/ ├── features/ ├── architecture/ └── decisions/（可选）

四、四类目录职责说明

1️⃣ commits/（时间型）

作用：

记录每一次工程变更。

来源：

commit message
commit date
diff（可选）

特点：

一条 commit 对应一个文件
只记录“发生了什么”
不承载长期能力描述

本目录用于：

支撑存量回溯与增量沉淀。

2️⃣ features/（功能型实体）

作用：

描述系统对外提供的功能能力。

特点：

每个功能一个文件
持续更新
不按时间组织

当发生：

功能新增
功能优化
功能规则变更

应更新对应功能文件，而非新增时间文件。

3️⃣ architecture/（结构型实体）

作用：

描述系统的结构能力。

包括：

模块划分
数据流模型
缓存机制
消息机制
数据模型
安全机制（如签名）

当发生：

架构调整
技术改造
数据流变化
新机制引入

应更新对应架构文件。

4️⃣ decisions/（可选）

作用：

记录重大决策。

非强制目录。

仅在：

架构转折
关键技术选型
重要策略变化

时生成文件。

五、存量与增量的处理原则

存量处理（历史项目）

原则：

不追求全量回溯
优先构建 architecture 与 features
再回溯关键 commit

目标：

形成当前系统的结构画像。

增量处理（未来变更）

每次工程变更：

生成 commit 文件（时间记录）
判断是否影响 feature
判断是否影响 architecture
必要时新增 decision

六、核心设计原则

时间型与结构型分离
commit 是事件，不是能力
feature 与 architecture 是长期实体
不强制决策文档完整
允许逐步完善

七、本设计的边界

本文件仅定义：

工程项目如何进入知识库。

后续可能扩展为：

知识库 → skills 抽象 skills → 技术决策赋能

但不在当前 scope 内。

八、阶段目标

当前阶段的目标不是完美沉淀。

而是建立一个：

可持续执行的工程入口结构。

2026-03-03-工程到知识库-项目沉淀入口设计