基于历史记忆&场景融入Bugfix流程

放在前面:

skill地址在文章最后

当前文档主要分享近期ai coding 的开发经验分享 ,并且总结了某些通用&固定的工作流程, 并行成项目通用性skill(轻量)

需要提醒的是, skill 旨在解决特定场景的特定问题, 其有效性与LLM大模型本身推理能力有着密切关系, 分两类情况 1.专业化指导性skill(特异化处理流程),推理引擎越强大,其成效越好

2.通用性skill, 例如指导如何排查问题, 这个会随着推理引擎的优化迭代而被淘汰,这是当前很多skill 的通病 ,例如我2026年初下载的skill基本上没有再使用, 除了极个别skill, 本身也在不断根据推理引擎迭代. 因为现在最前沿的gpt5.6/fable5/Kimi K3/Grok/GLM5.2&GLM5.5 已经足够聪明, 其推理能力完全覆盖了某些相对简单的skill,或skill的部分功能

以下涉及的skill, 属于通用性指导/固定工作流文档,可能也会在未来某个时间被淘汰,因此这里仅通过skill的 设计思路和经验总结 ,来分享在日常开发中如何节约更多的开发时间

解决的问题

1.频繁向agent介绍说明当前项目现状 和历史变动

2.每次Agent解决了一个问题之后,尤其是某些关键改动, 没有进行记录 ,导致后续修改踩雷

3.团队协作多人开发时,信息同步不到位导致,没有固定的信息同步渠道

4.没有固定的修改流程, 仅靠agent 开发工具提供的plan 模型给出计划再修改, 不能保证长链路改动的中间状态可追踪和可见性, 尤其是一些任务,AI无法有效验证,而进行尝试性的改动(例如UI设计, 图片生成,不可重复执行的请求/任务/sql等, ), 需要和用户多轮交互才能实现.

基础原理:

1.状态机 + loop 实现bugfix的状态流程

2.自动化的项目记忆文档查阅/梳理/沉淀

3.基于gotchas场景为基础单位的记忆存档

该工作流程的场景/如何解决问题:

bugfix loop 示意图:

project-memory目录结构规范示意图

WHY??

  1. 为什么使用md文档的形式存储记忆,他和obsidian应用型(文件类型)记忆存储 以及codex自带的记忆功能的区别?

    • project-memroy 该skill 注明了change 目录作为历史改动目录, 在时间上是有序的 , codex提供了强力且标准的记忆持久化文档, 但是难以在跨项目/跨git分支/跨长时间维度 进行有效区分和鉴别, 因此每个项目/分支以文档的方式, 设立私有的记忆文档更加合适.

    • 使用md作为存储,兼容性非常好,可读性高,容易迁移和调整等, 不需要任何依赖环境

  2. 为什么规则约束文档(AGENTS.md), 记忆文档(MEMORY.md)中使用索引的方式, 注册其他文档

    1. project-memroy 以md文档 + md使用相对位置相互索引的方式建立记忆网络有几个原因

      • codex开发者日志,明确推荐使用主文档+子文档的实现方式 个人认为有一定参考价值🤨🤨 https://openai.com/zh-Hans-CN/index/harness-engineering/

      • 参考anthropic 25年12月11日提出的skill 规范, 使用reference在SKILL.md中注册,实现需要时使用,避免token浪费和上下文占用

      • 增加用户可读性,因为大部分时间 我们在查阅文档的时候不需要查看内部细节,只关心名称和简述, 内部工作流需要审查的时候再进入文档查阅

  3. 基于gotchas场景的历史记忆有什么好处(如图)

实现效果

因为这两个skill本质还是提示词工程和规则约束, 不方便给出各种测评指标, 因此只能凭借我这1个月以来的开发经验和感受来推荐这个AI工作模式. 以此激起大家对自己的工作模型进行总结的热情

以下给出skill 的实际落地约束效果

gotchas记录

备注

  1. 这两个skill 可以单独使用, 也可以两个结合使用(我在内部写明了拓展索引)

  2. 我提供了中英文两个版本 ,适配国产各推理引擎, 并且中文方便大家自己个性化调整

  3. AI 行业大量术语存在"一词多义",需要按场景分层理解。以 "agent" 为例:产品层的 agent 是配置出来的角色 ------系统提示词+知识库封装成的领域问答 Bot;而 harness 工程中的 agent 是跑出来的执行体------模型在 agent loop 里自主决策、调用工具、根据观察结果持续行动,直到完成任务。类似的跨层歧义词还有 Loop、Memory、Context、Tool 等。

参考和引审

https://openai.com/zh-Hans-CN/index/harness-engineering

https://learn.chatgpt.com/blog

放在最后

文章内容为个人主观理解, 可能存在认知偏差和理解错误, 欢迎指正

skill链接地址

JHJ1848/bugfix · GitHub JHJ1848/project-memory · GitHub

相关推荐
糖墨夕42 分钟前
理解大语言模型:Agent 的“大脑”
前端·agent
冬奇Lab1 小时前
一天一个开源项目(第209篇):holaOS - Agent 原生的本地工作台
人工智能·开源·agent
夏文强2 小时前
DeepSeek Harness 权限与审批:给 Agent 上一把 human-in-the-loop 的安全阀
人工智能·开源·大模型·agent·deepseek
loong_XL3 小时前
生产级 Agent 开发方法论:速度、质量、价格与工程化
ai·大模型·agent·loop·智能体·vibe
jimidou4 小时前
子 Agent 能并行,却不能互相说话:Claude Code 里哪些活不该委派
agent·ai编程
DeepAgent4 小时前
AI Agent 项目赏析:DeerFlow 2.0 —— 一个真正“长跑“的 SuperAgent 是怎么设计出来的?
github·agent
Haooog4 小时前
Agent 开发中的 Memory:State、短期记忆、长期记忆与 Memory Retrieval
java·agent·memory
多学一分钟5 小时前
讲清 Agent:闭环、工具调用、记忆,以及 MCP 和 A2A
agent
每天都是不一样的太阳5 小时前
别让 AI Agent 先画靶再射箭:一套「结论忠于数据」的证据链工作流
agent·工作流引擎
静开5 小时前
模型没换、提示词没动,成功率从不到 70% 干到 95% —— 改的到底是什么
agent