Skip to content

MEMORY.md

Latest commit

 

History

History
149 lines (114 loc) · 5.45 KB

MEMORY.md

File metadata and controls

149 lines (114 loc) · 5.45 KB
Raw
summary 操作记忆 — 通用规则与项目地图（模板）
version 2.0

MEMORY.md — 操作记忆

跨项目通用 | 按层级组织 | 只记非显而易见的实操细节

身份信息见 USER.md，此处仅保留操作级别的规则、决策、项目地图。

⚡ P0 强制规则

凭据安全

  • 所有密码/API Key/Token -> 环境变量读取，禁止明文出现在任何文件中
  • 本地: .env 文件（不提交）+ .env.example 占位符
  • 服务器: {{服务器 env 文件路径}}（权限 600，唯一含真实凭据的文件）
  • 读取: Python os.getenv() | Node.js process.env
  • 改密码 -> 只改 {{env 文件名}} 一个文件；配置变更后须同步本地+服务器

核心环境变量清单

变量 用途
LLM_API_KEY/URL/MODEL 大模型配置
{{数据源1}}_URL/HOST_HEADER/USER/TOKEN {{数据源1，如 Zabbix}} API
{{数据源2}}_URL/TOKEN/DB {{数据源2，如 InfluxDB}}
SSH_HOST/PORT/USER/KEY_FILE 跳板机
{{推送渠道}}_WEBHOOK/WEBHOOK_KEY {{推送渠道，如 企微}} 推送
{{私有仓库}}_USERNAME/PASSWORD {{私有仓库，如 Docker}} 私有仓库

HTML 报告规范

  • 生成后必须部署公网可访问链接，禁止仅存本地
  • 推送/分享用 URL，不用文件

自动化铁律（实战踩坑记录）

  • 发现手动操作 -> 立刻追问能否自动化
  • 识别流程缺口 -> 要求统一脚本，反对冗余功能堆砌
  • 修改脚本不自动推送；确认可行后立即停定时任务
  • {{特定端口}} 不可达只报一次；{{特定场景}} 改用 {{备选方案}}

Feature Flag 规范

所有自动化脚本支持环境变量开关，无需改文件：

变量 用途 示例
PUSH_WEBHOOK 推送开关 PUSH_WEBHOOK=false 禁用推送
DRY_RUN 干跑模式 DRY_RUN=true 不执行副作用
DEBUG 调试模式 DEBUG=true 打印详细日志

应用范围：{{脚本列表}} 代码写法：const ENABLED = process.env.FEATURE_VAR !== 'false';（默认为 true）

开发流程：改 -> 审 -> 验

  1. 修改 -> 先要求专家审查（senior-dev / code-reviewer / 运维专家）
  2. 审查通过 -> 直接执行修复（P0 确认后全部修复，P2 回复"继续"即全量执行）
  3. 验证 -> 完成后实际运行验证，确认正常工作后再标记 completed
  4. 报告 -> 验证通过后明确陈述结果，不模棱两可

协作模式

  • 模拟专家角色协作完成任务分解
  • 审核代码后偏好让 AI 代为执行修改
  • 危险操作前先列清单确认，不直接执行
  • 自动化需前置沙箱检测

📊 项目地图

活跃项目

项目 路径 数据源 推送时机 关键依赖
项目A {{路径}} {{数据源}} {{时机}} {{依赖}}
项目B {{路径}} {{数据源}} {{时机}} {{依赖}}

已创建 Skills

Skill 用途
{{skill1}} {{skill1用途}}
{{skill2}} {{skill2用途}}

🔧 技术决策库

浏览器自动化

统一方案: {{方案描述}}
已弃用:   {{弃用方案}}
等待策略: {{等待策略}}
脚本模式: 含完整 try/catch/finally

SSH 方案

  • {{SSH 工具}} + 本地 {{密钥名}} 密钥
  • 禁止 {{不兼容工具}}

{{特定工具}} 配置

  • 密钥: {{密钥路径}}
  • 端口: {{端口号}}
  • URL: {{URL 模板}}

🛠️ 工程规范

1. 技能积累与反思

  • 多步任务完成后（>=8 次工具调用）：自动创建/更新 Skill
  • Skill 反思循环：用过的 Skill -> 检查是否过时/错误 -> 发现即修复
  • 只存"非显而易见的坑"，不存 README/文档已有内容

2. 测试策略与回归预防

  • 修复 bug 时：必须附带回归预防措施
  • 区分根因 vs 症状：修复要触及数据源头
  • 关键路径：所有异步调用、外部 API、DB 操作有可观测的失败路径
  • 验证方法最小化：修复前用最少的代码改动验证假设

3. 上下文感知与恢复

  • 缺失关键上下文时：先问，不猜测
  • 复杂请求：先用 AskUserQuestion 澄清
  • 上下文压缩恢复：长对话压缩后主动从 daily log 和 MEMORY.md 恢复

4. 关键 Prompt 模板（运维场景版）

场景 阶段流程
排查告警 Phase1: 环境审计+证据映射 -> Phase2: 假设生成+魔鬼代言人 -> Phase3: 最小化验证 -> Phase4: 根因修复+回归预防
重构脚本 Phase1: 逻辑审计 -> Phase2: 拆解路线(3-4里程碑) -> Phase3: 接口预览 -> Phase4: 实施+完整性检查+功能对等验证
设计新模块 Phase1: 需求合成 -> Phase2: 多架构对比 -> Phase3: 蓝图 -> Phase4: 自我挑战 -> Phase5: 实施路线图

👥 团队（可选）

姓名 角色 姓名 角色
{{姓名1}} {{角色1}} {{姓名2}} {{角色2}}

📝 记忆管理规则

  1. 每次会话提炼核心需求，更新此文件
  2. 高频信息直接写入，不依赖 daily log
  3. 定期清理 30 天前过期记忆，保留身份/风格/规则
  4. 不记未经证实/主观猜测/涉密内容
  5. 任务完成后立即 TaskList 自查
  6. Skill 优先于记忆：可重复的工作流 -> 创建 Skill
  7. 不存冗余：不保存代码结构、git 历史、README 已有内容