1. 项目概述一个为ChatGPT打造的“磨刀石”如果你经常使用ChatGPT进行编程、写作或数据分析可能会遇到一个共同的痛点当任务稍微复杂一点需要多轮对话才能完成时ChatGPT的表现就开始变得不稳定。它可能会忘记你几分钟前提到的关键约束或者在长篇对话的后半段输出的代码格式变得混乱逻辑也开始跑偏。这感觉就像用一把钝刀切肉费力且效果不佳。johniwasz/whetstone.chatgpt这个项目就是为解决这个问题而生的一把“磨刀石”。它的核心定位是一个ChatGPT 的“记忆”与“状态”管理框架。你可以把它想象成给ChatGPT配备了一个智能的“对话秘书”和“项目进度看板”。这个秘书会帮你记住整个长对话中的所有重要细节、用户偏好、任务上下文以及中间生成的各种“工件”比如代码片段、数据表格、设计草图并确保ChatGPT在每一次回复时都能精准地调用这些信息保持对话的一致性和深度。简单来说它让ChatGPT从一个“健忘的天才”变成了一个“严谨的合作伙伴”。无论是开发一个需要数十个步骤的软件模块还是撰写一篇结构严谨的长篇报告whetstone.chatgpt都能通过结构化的记忆管理显著提升复杂、多轮对话任务的质量、可靠性和效率。它非常适合开发者、技术写作者、数据分析师以及任何需要与ChatGPT进行深度、结构化协作的用户。2. 核心设计思路从“线性对话”到“有状态的会话工程”要理解whetstone.chatgpt的价值首先要明白标准ChatGPT API交互的局限性。默认情况下我们与ChatGPT的对话是一个线性的、无状态的“消息列表”。我们将整个对话历史包括用户提问和AI回复作为上下文发送给模型模型基于这个上下文生成下一个回复。这种方式存在几个根本性问题上下文长度限制所有模型都有token上限如GPT-4 Turbo是128k。长对话会迅速耗尽额度导致最早的历史信息被“挤出”上下文窗口造成事实上的“遗忘”。信息检索效率低即使上下文未满让模型从一大段杂乱的历史对话中精准定位几小时前提到的一个特定参数或代码片段也如同大海捞针容易出错或遗漏。缺乏结构化记忆对话中的关键决策点、生成的重要成果如最终确定的API接口定义、用户的明确偏好如“所有代码用Python 3.9编写”都散落在文本中没有被打上标签、分类存储无法被高效复用。状态管理缺失复杂的任务往往有多个阶段如需求分析、架构设计、编码、测试。标准对话难以清晰标记当前阶段也难以在中断后如第二天继续快速恢复到精确的进度。whetstone.chatgpt的设计哲学正是为了突破这些限制。它引入了“会话工程”的概念将一次复杂的对话视为一个可管理的“项目”或“会话”其核心思路包括2.1 结构化记忆体超越原始文本项目没有将整个对话历史原样保存而是从中提取、归纳并结构化存储关键信息。这通常包括事实与参数用户明确指定的要求如“项目名称叫demo”、“使用FastAPI框架”、“数据库用PostgreSQL”。决策与约束共同达成的共识如“采用RESTful风格设计API”、“用户认证使用JWT”。生成工件对话中产生的有价值输出如一段核心算法代码、一个数据库Schema定义、一份API文档草稿。会话状态当前任务进展到了哪一步如“已完成需求梳理正在设计数据库模型”。这些信息被组织成一个个可查询、可引用的“记忆单元”并附上元数据如创建时间、重要性标签、关联的任务阶段。当ChatGPT需要生成回复时whetstone.chatgpt会根据当前对话的意图从记忆库中智能检索最相关的结构化记忆并将其作为精准的上下文注入而不是塞入整个原始历史。2.2 动态上下文构建按需供给精准制导这是项目的核心技术优势。在每次调用ChatGPT API前它会进行以下操作分析当前用户查询理解用户本轮问题的意图和可能需要的背景信息。从记忆库中检索根据意图查找相关的结构化记忆单元。例如用户问“那我们之前定的API响应格式是什么”系统会直接检索标记为“API设计决策”或“响应格式”的记忆。构建优化后的提示将检索到的关键记忆与必要的、最近的原始对话片段用于保持语言连贯性组合构建一个新的、更精简、信息密度更高的提示上下文。注入系统指令可以附加一些持续有效的系统级指令如“你是一位资深Python后端工程师”确保AI角色的一致性。这种方式极大地减轻了上下文窗口的压力并确保了提供给模型的信息都是高相关、高价值的从而直接提升回复的准确性和一致性。2.3 会话持久化与恢复实现“长期协作”通过将结构化的记忆和状态保存到数据库或文件如SQLite、JSON文件whetstone.chatgpt使得会话可以随时保存、中断并在之后任意时间点精确恢复。你可以在今天下班前保存一个进行到一半的复杂代码编写会话明天打开后AI能立刻知道昨天写到了哪个函数遇到了什么未解决的问题并接着往下进行。这为真正的“人-AI长期协作项目”奠定了基础。3. 核心功能模块拆解与实操了解了设计思路我们来看whetstone.chatgpt具体提供了哪些“武器”。根据其公开的文档和设计我们可以将其核心模块分解并模拟其实现逻辑。请注意以下实现是基于常见模式和该项目目标的反推与补充用于展示其工作原理。3.1 记忆管理引擎这是框架的心脏负责知识的获取、存储和检索。1. 记忆提取器它的任务是从每一轮对话中识别并提取出值得长期存储的结构化信息。实现上这本身就可以借助一个“管理者”ChatGPT调用来完成。# 伪代码示例使用一个专用的提取提示 def extract_memory(turn_history, current_response): extraction_prompt f 你是一个记忆提取助手。请从以下对话回合中提取出需要长期记住的结构化信息。 对话历史最近几轮: {turn_history} AI的最新回复: {current_response} 请以JSON格式输出提取到的记忆项每个记忆项包含 - type: 类型如 [fact, decision, artifact, constraint] - content: 记忆内容 - key_entities: 涉及的关键实体如 [User, API, Database] - importance: 重要性等级 (1-5) # 调用ChatGPT API使用gpt-3.5-turbo等轻量模型即可 extracted_json call_chatgpt(extraction_prompt, modelgpt-3.5-turbo) return parse_json(extracted_json)2. 记忆向量化与存储提取出的文本记忆需要被存储并支持语义检索。通常的做法是使用文本嵌入模型将其转换为向量存入向量数据库。# 伪代码示例使用ChromaDB和OpenAI Embeddings import chromadb from openai import OpenAI client OpenAI() chroma_client chromadb.PersistentClient(path./memory_db) collection chroma_client.get_or_create_collection(namesession_memories) def store_memory(memory_item): # 为记忆内容生成向量嵌入 response client.embeddings.create( modeltext-embedding-3-small, inputmemory_item[content] ) embedding response.data[0].embedding # 存储到向量数据库元数据包含类型、重要性等 collection.add( embeddings[embedding], documents[memory_item[content]], metadatas[{ type: memory_item[type], importance: memory_item[importance], entities: ,.join(memory_item[key_entities]) }], ids[fmemory_{uuid.uuid4()}] )3. 记忆检索器当新问题到来时需要根据问题查找相关记忆。这里结合了语义搜索和元数据过滤。def retrieve_relevant_memories(query, memory_typeNone, top_k5): # 首先将查询语句也向量化 response client.embeddings.create(modeltext-embedding-3-small, inputquery) query_embedding response.data[0].embedding # 构建元数据过滤器 where_filter None if memory_type: where_filter {type: memory_type} # 在向量数据库中搜索 results collection.query( query_embeddings[query_embedding], n_resultstop_k, wherewhere_filter ) # 返回记忆内容和元数据 relevant_memories [] for doc, meta in zip(results[documents][0], results[metadatas][0]): relevant_memories.append({content: doc, metadata: meta}) return relevant_memories实操心得记忆的“保鲜期”与权重在实际使用中并非所有记忆都同等重要。我通常会为记忆设计一个“衰减权重”或“访问热度”。例如最近被频繁检索的记忆权重更高而一些一次性的事实如“用户说今天天气不错”可以设置较短的过期时间或较低的重要性等级避免无关记忆干扰核心任务。whetstone.chatgpt的理想状态是能自动管理这种记忆的生命周期。3.2 会话状态机为了管理复杂任务的进度框架需要维护一个会话状态。这可以是一个简单的状态标记也可以是一个复杂的工作流定义。# 定义一个简单的任务状态枚举和数据结构 from enum import Enum from dataclasses import dataclass from typing import Any, Dict class TaskPhase(Enum): REQUIREMENTS 需求分析 DESIGN 架构设计 IMPLEMENTATION 编码实现 TESTING 测试验证 REVIEW 代码审查 dataclass class SessionState: session_id: str current_phase: TaskPhase phase_progress: Dict[TaskPhase, float] # 各阶段完成百分比 artifacts: Dict[str, Any] # 阶段产出物如 {api_spec: {...}, core_module_code: ...} blockers: List[str] # 当前阻塞问题 # ... 其他自定义字段状态机的作用是引导对话根据当前阶段系统可以自动在提示中加入阶段性的目标或检查清单。例如在“设计”阶段提示开头会加上“当前目标完成数据库ER图设计”。持久化与恢复将会话状态与记忆一起保存。恢复时首先加载状态AI就能立刻知道“我们之前在进行数据库设计并且遇到了关于是否使用UUID作为主键的讨论”。提供进度概览为用户提供一个可视化的任务进度看板。3.3 智能提示词组装器这是将记忆、状态和当前查询融合成最终发送给ChatGPT的提示词的关键组件。它的质量直接决定AI回复的质量。def build_enhanced_prompt(user_query: str, session_state: SessionState) - str: # 1. 检索相关记忆 relevant_memories retrieve_relevant_memories(user_query) # 2. 构建记忆上下文字符串 memory_context ## 项目相关记忆供参考\n for mem in relevant_memories: memory_context f- [{mem[metadata][type]}] {mem[content]}\n # 3. 构建状态上下文 state_context f ## 当前会话状态 - **阶段**{session_state.current_phase.value} - **当前目标**{get_phase_goal(session_state.current_phase)} - **已生成工件**{, .join(session_state.artifacts.keys()) if session_state.artifacts else 无} if session_state.blockers: state_context f- **待解决问题**{.join(session_state.blockers)}\n # 4. 构建系统角色指令可根据状态动态调整 system_role get_system_role_by_phase(session_state.current_phase) # 5. 组装最终提示 final_prompt f {system_role} {state_context} {memory_context} ## 当前对话 用户{user_query} 请基于以上项目状态和记忆进行回复。确保你的回复与当前阶段目标一致并充分利用已有的记忆信息。 return final_prompt注意事项提示词的长度与成本平衡虽然结构化记忆很高效但检索到的记忆过多也会导致提示词过长。在实践中我会设置一个token上限例如2000 tokens给记忆上下文并优先选择重要性高、相关性强的记忆。同时对于“工件”类记忆如长代码可以采用“摘要引用”的方式只存储代码的摘要和唯一ID当AI需要查看细节时再通过ID从存储器中完整加载并插入上下文。这需要更精细的记忆管理策略。4. 实战演练用Whetstone框架协作开发一个API服务让我们通过一个模拟场景看看如何在实际中使用whetstone.chatgpt的思路来管理一个从零开始创建用户管理API的会话。4.1 会话初始化与需求锚定用户“我想创建一个用户管理系统的后端API使用Python和FastAPI。”框架动作创建新的SessionStatecurrent_phase设为TaskPhase.REQUIREMENTS。调用记忆提取器提取关键事实{type: fact, content: 项目目标创建用户管理系统后端API。技术栈Python, FastAPI., importance: 5}。将此记忆存入向量库。组装提示时加入系统指令“你是一位经验丰富的Python后端工程师擅长使用FastAPI和SQLAlchemy。”AI回复提供初步的技术选型建议如数据库、认证方式等。用户“同意使用SQLite开发JWT认证。需要用户注册、登录、查询个人信息和注销接口。”框架动作提取关键决策记忆{type: decision, content: 数据库使用SQLite开发环境。用户认证采用JWTJSON Web Tokens。, importance: 5}。提取需求清单记忆{type: constraint, content: 必需API端点1. POST /register 2. POST /login 3. GET /users/me 4. POST /logout, importance: 5}。更新会话状态可能将进度标记为“需求已明确”。4.2 设计阶段与工件生成用户“好我们先设计用户模型和数据库表。”框架动作检索到之前关于“SQLite”和“用户管理系统”的记忆。将SessionState的current_phase更新为TaskPhase.DESIGN。在提示词中明确加入“当前阶段架构与数据库设计。目标定义User模型和数据库迁移脚本。”AI回复生成Pydantic模型定义和SQLAlchemy ORM模型代码。用户“模型看起来不错。把created_at字段加上。另外JWT的secret key我们应该从环境变量读取。”框架动作提取关于模型的工件记忆将AI生成的完整代码块存储为artifact类型ID为user_model_v1。提取新的决策/约束记忆{type: constraint, content: User模型需包含created_at时间戳字段。JWT密钥必须从环境变量SECRET_KEY中读取。, importance: 4}。当用户后续说“把刚才的User模型代码再给我看一下”时检索器能通过“user_model”相关查询直接定位到user_model_v1这个工件并将其内容精准地放入上下文而不是让AI去回忆一段可能已经模糊的对话历史。4.3 实现阶段与上下文连贯性考验用户“现在开始实现注册接口/register。密码需要哈希存储。”框架动作检索到“必需API端点”记忆和“JWT认证”决策记忆。检索到user_model_v1工件。状态阶段更新为TaskPhase.IMPLEMENTATION。提示词中强调“当前任务实现POST /register端点。要求密码哈希处理例如使用bcrypt。需参考已有的User模型。”AI回复生成包含密码哈希、依赖注入的/register端点代码。用户过了很久或第二天继续“登录接口/login呢它应该验证密码并返回JWT。”框架动作会话恢复加载之前的SessionState和所有记忆。AI立刻知道当前在IMPLEMENTATION阶段刚完成/register。检索到“JWT认证”、“密码哈希”等关键记忆。检索到之前生成的/register端点代码作为参考工件。构建的提示词天然包含了所有必要上下文AI可以无缝衔接生成风格一致、逻辑连贯的/login接口代码而不会忘记之前关于密码哈希算法或JWT结构的决定。4.4 问题排查与记忆调优用户“我运行代码时/login接口返回‘密码无效’但我确定密码是对的。帮我看看。”框架动作识别到这是一个“调试/排查”类查询。除了检索常规的项目记忆可能会优先检索类型为artifact的代码工件/login实现和相关的constraint密码哈希。在提示词中可以主动加入一个“调试模式”的系统指令“请扮演调试助手仔细分析以下代码找出可能的逻辑错误。”AI在精准的上下文出问题的代码相关决策记忆下更容易指出问题例如“在/register中你使用了bcrypt.hashpw但在/login中比较密码时你错误地直接比较了明文和哈希值应该使用bcrypt.checkpw。”整个过程中whetstone.chatgpt框架在后台默默工作确保了对话的深度、一致性和高效性将一次可能杂乱无章的长对话变成了一个结构清晰、可追踪、可恢复的协作项目。5. 常见问题、挑战与优化策略实录在实际应用类似whetstone.chatgpt的思路时你会遇到一些典型问题。以下是我在构建类似系统时踩过的坑和总结的经验。5.1 记忆提取的准确性与噪音问题自动提取的记忆可能不准确或包含大量无关信息噪音。例如把AI的一句客套话“当然我很乐意帮助你”也提取为fact类型记忆。解决策略分层提取不要试图从每一轮对话都提取记忆。只在检测到用户明确下达指令、做出决策、或AI生成了完整代码块/文档时触发提取。置信度过滤在提取提示中要求模型输出一个“置信度”分数。只有高置信度的提取结果才存入长期记忆库。人工确认关键点对于非常重要的决策如技术选型可以设计一个交互环节向用户确认“我将‘使用GraphQL而非REST’作为一项关键决策存入记忆对吗”这虽然增加了交互步骤但保证了核心记忆的绝对准确。5.2 记忆冲突与版本管理问题用户可能在对话中修改之前的决定。例如先说“用MySQL”后来说“不还是用PostgreSQL”。记忆库中会存在冲突的事实。解决策略记忆关联与废止为每个记忆单元增加parent_id或superseded_by_id字段。当检测到新记忆与旧记忆冲突时通过实体识别和语义相似度判断将旧记忆标记为“已废止”并建立新记忆与旧记忆的关联。检索时默认过滤掉被废止的记忆。基于时间的权重简单场景下可以为记忆附加时间戳。在检索时如果发现关于同一实体的多个记忆优先采用时间最新的一个。但这无法处理“改回旧方案”的情况。5.3 检索效率与精准度平衡问题单纯的向量语义检索有时会“找偏”。比如用户问“登录接口的密码比较逻辑”向量检索可能返回一堆关于“密码哈希”的通用讨论而不是具体的/login端点实现代码。解决策略混合检索结合关键词检索从查询和记忆中提取“登录”、“密码”、“bcrypt”等关键词和向量检索。先用关键词快速缩小范围再用向量做语义精排。元数据强化检索为记忆精心设计元数据字段type,entity,phase,artifact_name。检索时允许用户或系统自动添加元数据过滤器。例如当问题明显是关于代码时添加where_filter{type: artifact}。查询重写在检索前先用一个小模型对用户的原始查询进行重写和扩展使其更符合记忆库的表述方式。例如将“登录那块代码”重写为“用户登录端点/login的Python实现代码”。5.4 成本与性能考量问题频繁调用嵌入模型向量化记忆、调用大模型提取记忆和组装复杂提示会增加API调用成本和响应延迟。优化策略异步与批处理记忆提取和向量化操作不必实时完成。可以在每轮对话后异步进行避免阻塞主交互流程。缓存热点记忆对于被频繁检索的核心记忆如项目技术栈可以缓存在内存中避免每次查询都走向量数据库。轻量级模型分工用低成本、高速的模型如gpt-3.5-turbo处理记忆提取、查询重写等任务。只在最终生成回答时使用gpt-4等强大但昂贵的模型。记忆摘要对于长文本工件如一篇生成的设计文档同时存储其全文和由小模型生成的摘要。在大多数检索场景下只使用摘要仅当AI明确需要引用细节时才加载全文。5.5 状态机设计的复杂性问题为所有类型的任务预定义一个完美的状态机TaskPhase几乎不可能。写代码、写文章、做数据分析的任务流程截然不同。实用建议提供轻量级默认状态框架提供一个简单的、通用的状态定义如未开始、进行中、已暂停、已完成。支持自定义状态允许用户或开发者为特定类型的会话定义自己的状态枚举和工作流。whetstone.chatgpt的核心价值在于管理记忆和上下文状态机可以作为一个灵活的可选组件而不是僵化的必选组件。状态即记忆另一种更灵活的思路是将“当前状态”本身也视为一种特殊的记忆。例如存储一条记忆{type: state, content: 我们正在实现用户注册接口的密码哈希部分, importance: 3}。这样状态管理也融入了统一的记忆检索体系更加动态和自由。johniwasz/whetstone.chatgpt所代表的方向是人机交互走向深度协作的必然。它不再满足于单次的、孤立的问答而是致力于构建一个能够积累知识、维持状态、进行复杂项目管理的持续性AI伙伴。虽然完全实现这样一个框架需要处理诸多工程细节但即使你在自己的项目中只采纳其核心思想——有意识地对长对话进行结构化记忆和状态管理——也足以让你使用ChatGPT的效率和产出质量提升一个数量级。你可以从手动整理关键对话要点开始逐步尝试用简单的脚本自动化部分过程最终向着构建你自己的“智能磨刀石”迈进。