---
title: "智能体经验合并请求"
date: "2026-08-09"
canonical: "https://raytally.com/ideas/2026-08-09-hexis/"
generator: "萤录 RayTally · dev-prompt-v4"
signal:
  query: "Hexis"
  observed_at: "2026-08-09T00:33:25.952Z"
sources:
  - url: "https://www.producthunt.com/products/bevel-4"
    boundary: "观测于 2026-08-09T00:33:25.952Z。"
  - url: "https://code.claude.com/docs/zh-CN/memory"
    boundary: "来源记录未提供发布时间。"
  - url: "https://docs.github.com/en/rest/pulls/pulls"
    boundary: "来源记录未提供发布时间。"
  - url: "https://docs.langchain.com/langsmith/analyze-an-experiment"
    boundary: "来源记录未提供发布时间。"
notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。"
---

[在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-09-hexis/)

使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。

你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。

## 灵感

智能体经验合并请求
智能体重复犯错时，把人的纠正做成可回放测试、可审核并能回滚的团队经验。

## 产品概念

工程师发现智能体又把同一个配置、测试习惯或权限边界理解错时，不必把纠正埋在下一轮聊天里。用户选中那段纠正，附上相关代码、工具调用和正确示例，提交一条“经验合并请求”。系统先把它整理成可读的规则：适用于什么仓库、遇到什么条件该做什么，以及哪些情况不能套用。 提交后，这条经验不会立刻广播给所有智能体。产品从团队已经完成的脱敏任务中抽取一组回放样本，让旧规则和新规则分别执行。页面把新规则修复的错误、引入的退步和无法判断的案例并列出来，审核者能查看触发它的原始上下文，而不是只看一个通过率。 通过审核的经验带着版本号进入指定仓库和任务类型。某条经验在后续任务里造成回归时，负责人可以定位受影响的会话，一键退回上个版本，并留下新的改进请求。团队逐渐拥有一套像代码一样能审查、测试和回滚的智能体工作手册。 第一版只接收人工明确提交的纠正，覆盖常见的代码修改和工具调用任务。它不偷偷提取所有私聊内容，也不让模型自行把一次偶然成功扩张成全局规则。

## 为什么是现在（有事实支撑）

截至 8 月 9 日观测，Hexis 位于 Product Hunt 新品流第 1 名，主打用 Git 管理智能体技能、工具和上下文。 这让团队更容易看到：共享规则已有载体，眼下缺的是把纠正先回放验证，再审批分发。

## 方向判断（以下为模型推断，未经独立验证）

目标用户：面向同时使用编码智能体的工程团队，尤其是负责代码审查、开发规范或内部平台的人。当同一种错误再次出现在合并请求里，口头提醒已经显得低效。此时他们手上既有失败会话，也有正确代码和测试结果。把这些材料立即沉淀，成本最低，也最容易说清规则边界。

最小切入点：入口放在编码智能体的会话记录旁，提供“提交纠正”动作。用户选中对话片段，再附上相关文件、工具调用和正确结果。系统生成结构化规则草稿，字段包括适用仓库、触发条件、预期动作和例外。规则与样本都存进 Git 分支，并通过 GitHub REST API 创建合并请求。 回放器先支持可重复运行的命令行编码任务。它在隔离环境中分别加载旧版与新版规则。结果页逐例展示修复、退步和无法判断，不先压成单一分数。早期评判以确定性测试和人工复核为主，暂缓自动推广。

最强反方：回放结果很容易受模型版本、依赖状态和外部工具变化影响。同一条规则可能只是碰巧让一次任务通过。为了区分规则效果与随机波动，团队要固定环境并保留完整轨迹。历史任务还可能包含密钥、客户代码和员工对话，脱敏会增加接入阻力。许多纠正无法写成确定性测试，只能依赖人工判断。评审者若要逐例查看长会话，审批会变成新的工作负担。错误规则一旦广泛分发，会让多个智能体以更稳定的方式犯错。产品必须先证明回放证据能减少评审时间，否则普通 Git 文件更省事。

以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。

## 以小博大（模型推断）

首批用户可从维护 CLAUDE.md、AGENTS.md 和仓库规则的工程团队中寻找。发布一个开源命令行工具，把现有规则文件转成带样本的经验请求。再提供常见模板，例如测试命令、包管理器选择和权限限制。用真实的前后回放差异写技术案例，投放到编码智能体社区和工程团队内部工具讨论区。

## 竞品与缝隙（模型推断）

- Hexis：Hexis 已把技能、工具和上下文放在 Git 之上。它提供版本、友好的变更建议界面和访问控制。团队成员还能通过 MCP 在不同智能体中使用内容。 这已解决规则存放、共享和审批门槛。公开页面的重点仍是内容治理与分发。它没有展示从一段人工纠正生成规则候选的流程。页面也未说明如何用历史任务比较新旧规则。因而可把 Hexis 当作下游规则仓库，而非重复建设整个治理层。
- Claude Code 记忆与 CLAUDE.md：Claude Code 已支持 CLAUDE.md、项目规则和自动记忆。自动记忆会从更正与偏好中积累笔记。团队也能用版本控制共享项目级指令。 这些能力贴近“别再犯同一个错”的直接诉求。短板是自动记忆更偏个人工作树，且由模型自行维护。CLAUDE.md 的审查可借助普通 Git 流程，却没有专门的纠正提交流程。官方文档也未提供新旧规则的任务回放对照。产品机会在于补上证据、审核和回归定位，而非再做一种记忆文件。
- LangSmith：LangSmith 已能把生产轨迹整理成数据集。数据集可版本化，并能比较不同实验结果。界面可查看输入、输出、反馈和完整轨迹。它也支持把一次实验设为基线，识别改动后的退步。 这套能力足以承载部分回放与评估工作。缺口在于它面向通用智能体评测，而非团队经验的变更治理。工程师仍需自行把聊天纠正改写成规则和样本。评估通过后，也要另建规则发布、适用范围和回滚链路。新产品可用它作评测后端，把体验聚焦于经验合并请求。

## 怎么赚钱（模型推断）

按团队工作区订阅收费，包含成员席位、规则仓库和基础回放额度。超出额度后按回放任务量计费。自托管、单点登录、审计导出和长期留存放入企业套餐。

## 来源背景

主题：Hexis：面向AI智能体的Git技能、工具与上下文
触发的 Product Hunt 新品：Hexis — Git-backed skills, tools & context for AI agents

以上只记录新品出现在 Product Hunt 公开 feed 与被观测的事实；该 feed 不提供票数，不要把 feed 顺序描述成热度或市场需求。

## 来源清单

- Hexis — Git-backed skills, tools & context for AI agents（https://www.producthunt.com/products/bevel-4）
- Claude 如何记住你的项目（https://code.claude.com/docs/zh-CN/memory）
- REST API endpoints for pull requests（https://docs.github.com/en/rest/pulls/pulls）
- LangSmith: Manage datasets and analyze experiments（https://docs.langchain.com/langsmith/analyze-an-experiment）

## 交付要求

- 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。
- 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。
- 页面或接口里不要展示未经验证的市场数字。
- 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。
- 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。
- 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。
- 完成后说明改了什么、如何运行、如何验证。
- 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。