KM Logo
←cd ..

harness 可沉淀的核心——知识与范式，论如何构建组织内的 SPEC

·5 min read·随笔·--
#SPEC#知识管理#工程效能#AI辅助开发#组织规范
SummaryAI

文章深入探讨了构建组织内SPEC的核心要素，强调知识与范式的沉淀是关键。值得关注的要点包括：基础设施与版本管理的系统化设计；记忆系统与多模态输入的渐进式整合；以及SPEC框架的自进化与评估机制。

  1. 基础设施
    1. 内部服务的 api,cli,mcp 能力——工单系统、编译系统、上线系统、灰度系统、日志系统、监控系统（指标相关）
    2. 各项服务的封装cli +skill 或 mcp
  2. 版本管理
    1. 整套规范与知识库支持版本管理
      1. 文件系统通过 git, memory 通过什么？
      2. 本规范评测指标持久化，并持续追踪
  3. 并行开发
  4. 多模态输入：知识包括腾讯文档、pdf、csv， 图片较多。聊天记录等等
    1. 文件系统的多模态不易检索
      1. 便捷的多模态上传入口（项目集知识与公共知识，supermemory 会支持）
      2. 文档库选型时，直接用支持 markdown 格式的文档——如飞书最好
  5. 记忆系统
    1. 本地文件记忆系统——主要是项目级
    2. 远端向量记忆系统——团队级别知识（supermemory, openmemory，还是其他的？ 注意最好支持本地部署而非远端服务订阅！）
    3. 实现 Cli 级别（cli+skill）的统一写入与读取，由 LLM 调用
      1. 写入公共知识时可接入权限管理与审批，CICD 流程（通过 cli 服务实现）
      2. 写入项目级知识则弱化审批流程，如增加不审批只 cr，修改或删除需要审批+cr
      3. 还有哪些
    4. 渐进式读入
      1. 本地文件系统分块、分层管理
      2. 使用 @ 语法
      3. 使用.claude/rules/ 语法(有必要使用么？)
    5. 强时序 depracated，墓碑机制
      1. 文件系统通过 json,yaml 执行
      2. 远端向量记忆自带时序标签，自动墓碑。
      3. 当无引用持续一段时间后——删除（通过定时任务）。
    6. ROT 解决
      1. 被动式（时间戳）
      2. 主动式（/command）
      3. 周期式（定时任务LLM）
      4. 远端式（强制介入 CICD，远端 CD部分引入 LLM 做二次校验）
  6. 组织内 SPEC（参考 bmad openspec 开发一套适合内部的 spec？ 或者还是说直接基于 openspec 与 bmad 或 gsd？ 通过插件式改造来实现内部的 spec）
    1. green field——从 0 到 1 项目，快速根据 tapd 单或者文档获取到业务信息，并构建开发流程
    2. brownfield——轻量级项目开发，适合大型项目的逐步演进
    3. bugfield——bug 级别修复的 spec（通过 callid 快速定位链路问题）
    4. SPEC 要可演进（通过旁路收集 spec 中存在的问题——怎么收集？）
  7. skill 在启动项目时（init 时），配套多种 skill 选型。——————这里怎么设计，有无最佳方案？我的理解可能是如下。（痛点：很多项目，不知道怎么选择合适的 skill，并且不知道选择哪些 skill， 而且还有一批内部维护的 skill）
    1. 全栈的 skill/go 的 skills/python 库的 skills: 包括前后端的
  8. 整个 SPEC 框架的评估方案，怎么设计？ （应该是要周期化离线评估。 评估集由人工确定——怎么尽量减少成本）
  9. 支持远程操控（claude cowork 貌似是直接支持？）
  10. 自进化能力
    1. cli 的自进化能力
    2. skill 的自进化能力

提问题

Bash
# 在200K 1M 下，skill 的默认载入数量（要控制在多少？）
## 单个 skill 占据的平均token
## 什么时候使用commands（避免侵占上下文窗口）? 什么时候用 skill(我理解需要模型一直指导的技能。)

# 什么时候使用MCP/CLI？
## CLI的迁移策略（考虑 CLI 是安装在个人的开发机上，如何管理 CLI？是直接封装在当前仓库，还是说有统一管理 npm(内部 npm 地址？)?）
## MCP的加载机制，以及其权限，目前是否处理的MCP当前的问题，如何选择MCP（比如 MCP 的方法数量？还有哪些影响因素）

# 什么时候要构建自己的 agents ？  agents 会在什么时候触发（subagents？）
## agents 触发机制
## agents构建方法

# CLAUDE.md  上下文管理方法

## CLAUDE.md的最佳实践比较（论官方最佳实践和第三方最佳实践）
## 什么时候用分层的 CLAUDE.md，什么时候用./claude/rules 中的 path-scoped rules，有什么区别？
## SSOT在上下文管理中的核心？
## @import 使用原则
保留 @import，当且仅当它满足这 2 条：

每次会话都大概率会用到（常驻知识）
内容短且稳定（不会频繁改、不会很长）
否则就别 @import，改成普通路径提示（按需读）。

## 设计原则
二、设计原则（来自调研报告 §1-§4）
目标行数：根 CLAUDE.md 在 60–180 行之间最佳；当前 21 行 → 计划提升到 ~70 行（仍远低于 200 行的硬上限）
DRY：不重复 .claude/rules/global/*.md 已有的内容（那两个文件已经在每次会话自动加载）
@import 只用于"每次会话都必须看"的内容；UI/导航等专题文档只用纯文本路径提示（不用 @），让 Claude 在需要时自行 Read
路径准确性：删掉 @AGENTS.md、修正 @BetaLine/BetaLine/... → BetaLine/Docs/...
"Pragmatic 优先级"：用 MUST / IMPORTANT 关键字给少数硬约束加权
每季度审计保留 HTML 注释，并补上 /context 与 /memory 双命令

# 记忆系统

## 为什么要使用第三方记忆系统，为什么不仅仅通过文件级上下文管理来实现记忆系统（优劣势）
比如文件类型(pdf,链接，等等)内容，无法快速的实现 markdown 化，让 Agent 理解。

ROT 解决
## 记忆系统的选型（supermemory等）

# SPEC

## 什么是SPEC，目前的发展阶段（v1.0->v2.0->v3.0(tessl?)）

## 为什么针对 greenfield brownfield bugfix 需要不同的 spec？

## 构建组织级 SPEC 的必要性？ 以及基于第三方构建组织级 SPEC 的必要性（从 SPEC 演进流程来看）

## 如何基于第三方 SPEC，构建内部组织级的 SPEC？
保留领域知识，基于领域知识做第三方 SPEC的快速替换或者进化。
比如当前我基于内部领域知识做了整合 SPEC 后，后续 SPEC发展会有 2 种情况：
- 逐步迭代
- 完全重构（有多种 SPEC 都经历过重构）

我理解，需要将内部的 SPEC 知识完全封装并维持版本管理， 不管外部 SPEC 如何演进，都可以基于 Agent 快速适配。如何做？

评论