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