资产组合盘点 · 决策呈现
资产组合盘点(双市场 × 双知识库) · 2026-09-06

治理降档、引擎共享、载体收敛四个 AI 资产(个人/团队 插件市场 + 个人/团队 知识库)的方向性重构

一句话结论:基础设施都在健康演进,但两个知识库处于「流程已建、内容为零」的空转状态,两个市场处于「标准分裂、统一方案挂起一个月」的悬置状态。最大的问题不是缺规范,而是质量门禁与实际使用强度严重错配——门禁应后置(分级+盘点),不该前置(入库评审)。
4
盘点资产(2 市场 + 2 知识库)
29
团队知识库 pending 积压(从未晋升)
0
团队知识库正式层(查询侧空转)
1
个人知识库两周实际卡片量(无 agent 接入)
6
待决策事项(D1–D6)
Landscape · 01

四资产现状

左侧为个人侧(品牌系命名),右侧为团队侧。团队侧具体插件名与内部代号已脱敏,完整版见源报告。

资产形态规模健康信号病灶
个人插件市场自建编译型(一源 → 4 运行时)15 自研 + 3 镜像包✓ 重构后常驻成本 4192→1173 tokens;validate / quality / feedback 工具链完整✗ 夹带设计产物入库;两项内部待定悬置
团队插件市场运行时原生平铺9 插件 / 40+ 技能✓ 触发表机制与个人市场对齐;有过一轮技术合规评估✗ 与个人市场双轨标准;旧评估的元数据/版本问题未整改;工作区当运行区用
团队知识库分层治理库(目录→分类→条目渐进披露)正式层 0 / pending 29✓ ID 体系、成熟度三级、冲突策略、lint 设计完整晋升环节从未发生;维护人仅 1 名,三处目录手工同步是主要摩擦
个人知识库PARA + 管家规则1 卡片 + 1 素材✓ 八套规则自洽(守门 / 回流 / 盘点 / 活档案)✗ 无插件接入、无输入流;位置与定案不符;与笔记库双 PARA 撞车

✗ 治理错位链路:团队库的查询技能从 catalog 逐级下钻,正式层为空意味着 29 条知识在库里却查不到——技能加载、触发行、lint 的成本每天都在付,复用收益为零。

Diagnosis · 02

四个根本性质疑

不针对执行细节,针对设计前提本身。

Q1 · 治理强度与治理对象错配
论证

治理成本应与「污染风险 × 贡献者数」成正比。团队库维护人 1 名、贡献者主要是 agent,前置门禁(评审+三处目录同步)零收益纯摩擦,结果是 29 条知识排队一个月、正式层空转。个人库同理:四套方法论融合、八套规则、两周 1 张卡片——没有输入流的系统,规则越完备沉没成本错觉越强。

Q2 · 「团队市场按个人市场架构整体重构」定案本身值得重审
论证

个人市场编译层的存在理由是「一源多运行时」(4 个目标);团队市场真实运行时只有 1 个。为未发生的需求引入 build 步骤,是拿个人场景的药方治团队场景的病。且该定案制造了长依赖链:KB 插件迁移 → 等市场重构 → 等个人市场成熟,边界错位被制度化。真正该共享的是引擎与质量标准,不是仓库目录结构。

Q3 · 知识库放在 projects/ 下是分类错误
论证

projects/ 的语义是「工程仓库」:有交付物、有生命周期、可被 clone。知识库三者皆无——它是长期的活资产。个人库按目录规范应归 knowledge/(既有定案也是如此,实际未执行)。位置错不只是美学:它决定 agent 在哪个目录语境下「顺手」检索它。

Q4 · 笔记库与知识库的边界从未真正切分
论证

定案说「笔记库留随手记录、知识库收沉淀」,但两边结构同构(各有一套收集箱/资源分区),没有一条规则说明同一段内容在两边如何区别对待。两个入口 + 相似结构 + 无边界规则 = 内容必然散落两边。连输入流是否成立都未验证。

Plan · 03

六项重构方案(D1–D6)

每项给出与现状的差异和代价;完整论证见源报告。

#方案核心动作与现状的差异代价
D1市场引擎统一:抽「引擎」而非复制「架构」把 build / validate / quality 工具链 + schema 抽成独立共享引擎,个人市场第一个消费者;团队市场按需接入 validate/quality 子集,不强制引入编译结构原定案是「团队市场变成个人市场的形状」;本方案是「两边共享同一台发动机,各自保持适合自己的车身」抽取 1–2 天;团队接入另计
D2团队知识库治理降档:贡献即入库① 一次性批量晋升 29 条 pending → 正式层(成熟度 draft)② 贡献技能改为直接写正式层+脚本自动登记目录 ③ 晋升技能改为「成熟度升级」,靠使用留痕+定期盘点驱动,不再作为入库必经保留 ID 体系、证据溯源、成熟度分级、lint(查询侧价值全保);砍掉的是前置门禁与三处手工同步半天–1 天
D3个人知识载体收敛:先回答「谁在用」推荐:个人知识库整体并入笔记库(既定的「统一笔记」答案),管家规则随迁;KB 插件建到笔记库上让查询入口先跑起来。独立成库推迟到卡片量过百、随手记录与沉淀知识互相干扰时备选:保持独立库则立即归位 knowledge/ + 当周建插件 + 写死边界规则半天
D4KB 插件先行搬迁:拆掉依赖链团队知识库技能(当前在个人市场)以原生形态直接迁入团队市场并按团队系改名;两份触发表同步增删。不等 D1消除「公司团队技能由个人市场供给」的边界错位,个人市场纯净化1–2 小时
D5仓库卫生:市场 = 分发物,不是工作区个人市场移出入库的设计产物、补齐运行时文件的 gitignore;团队市场的需求拆解交付物迁出到对应项目、评估文档归 docs/;两仓各加一条「运行时产物不入库不入工作区根」约定现状是「本地摆放问题为主、少量已入库」;整改后边界成文1–2 小时
D6命名规范:只对新建物执行不主动回改任何旧名(破坏路径引用/记忆/触发表的代价 > 命名美学收益);新规则:个人系前缀=个人 / 团队系前缀=团队 / 公司产品线代号不再作为顶层前缀出现命名洁癖的收益低于搬迁成本,只防新债不还旧债≈ 0
Roadmap · 04

执行顺序(按价值密度)

P0 两项当天可完成且立刻解锁存量价值。

优先级动作对应预估解锁价值
P0批量晋升 29 条 + 治理降档D2~1 天团队库从空转变为可查询,29 条知识立刻可复用
P0KB 插件迁团队市场D4~2 小时消除跨边界错位,个人市场纯净化
P1双市场仓库卫生D5~2 小时边界清晰,git 历史干净
P1个人载体收敛(需先拍板 D3 方向)D3~半天消灭双入口,agent 查询入口成立
P2引擎抽取(第一阶段纯抽取,不动团队市场)D11–2 天质量标准同源,一次修复两边受益
P2命名规范写入 AGENTSD6≈ 0防新债
Acceptance · 05

验收标准

每项决策完成后的可验证状态。

D2 完成
团队库目录统计非零;pending 区清空;用任一积压期主题能命中正式层条目
D4 完成
团队触发表含 KB 行;个人市场清单无 KB 包;双市场构建校验通过
D3 完成
个人知识入口唯一(或双入口边界规则成文,且各有一条被 agent 实际执行的查询记录)
D1 / D5 完成
个人市场从引擎仓消费工具,tests 全绿;两仓入库清单无设计产物/运行时文件
Risks · 06

风险与对策

风险等级对策
批量晋升 29 条未经逐条评审,可能混入低质量条目全部标成熟度 draft(查询时降权);下次盘点集中复核;置信度靠使用留痕演进,不靠入库前评审
个人知识库并入笔记库后,失去 PARA 结构独立性,长期可能再撞车预设再分家条件(卡片量过百 / 干扰可感),届时由真实内容反推结构,而非预设结构等内容
引擎抽取引入跨仓依赖,个人市场工具链升级可能破坏团队市场引擎打 tag 锁版本;团队市场接入是独立决策,默认只消费稳定子集
治理降档后贡献量上升,低质条目涌入正式层lint 保持强制;冲突进专门区;盘点规则保留(超期未引用 → 提示归档)
Decisions · 07

待你决策的 6 件事

每项都给推荐与理由;确认或改定后即可执行。团队侧细节与本页脱敏差异见本地源报告。

① D2 · 团队知识库是否砍掉入库门禁(贡献即入库,成熟度后置把关)?
推荐

是。先批量晋升 29 条(draft),再改贡献技能直写正式层。单人维护场景门禁零收益。

② D1 · 双市场统一走「抽共享引擎」还是维持原定案「团队市场整体重构为编译型」?
推荐

抽共享引擎。团队市场暂只有 1 个真实运行时,编译层收益不存在;引擎+质量标准共享已覆盖痛点。

③ D3 · 个人知识库:并入笔记库(推荐)还是按定案独立归位+立刻建插件?
推荐

并入笔记库,独立时机推迟到卡片过百。若无输入流就继续建结构,是在给空房子还房贷。

④ D4 · 团队 KB 插件是否立即从个人市场迁走(不等市场重构)?
推荐

立即迁。1–2 小时的事,不应被 1–2 天的重构前置条件锁死一个月。

⑤ D5 · 仓库卫生是否本轮一并执行(含需求拆解产物迁出团队市场)?
推荐

一并执行。迁移去向需要你确认(对应交付项目 or 团队库关联区),其余动作无歧义。

⑥ D6 · 命名:接受「不回改旧名、只约束新建物」的原则?
推荐

接受。回改旧名的路径引用破坏成本大于收益;写进两市场规范即可。