Communitygithub.com

HusDev/preferences-logger

在项目中维护一份实时更新的 PREFERENCES.md 文件,记录用户在协作过程中做出的每项决策和偏好(产品、设计、技术、工作流程、写作等),并附上日期,确保后续会话遵循这些记录而不再重复询问。

preferences-logger 是什么?

Preferences Logger 是一款 AI 助手技能,旨在解决开发协作中常见的信息丢失问题:用户在会话中做出的大量小决策(如颜色选择、库偏好、命名规则等)往往不会被记录下来,导致下次会话时重新询问或无意中推翻。该技能通过在项目根目录维护一个 PREFERENCES.md 文件,在用户每次做出、更改或撤销决策时自动记录,包括偏好表述(如“我更喜欢”、“以后都这样”)、选项选择、纠正意见等。它支持在第一次操作前读取该文件,并在有冲突时以用户最新明确的声明为准。该技能适用于任何支持自定义指令的 AI 代理平台(如 Claude Code、Cursor 等),通过简单的文件格式和变更日志机制,确保决策持久化且易于追溯。其设计遵循极简原则:单行决策条目、按主题分组、就地编辑并保留历史、保留用户原话、注明理由和链接,有效降低了重复沟通成本,提升了协作连续性。

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/HusDev/preferences-logger/tree/HEAD/skills/preferences-logger

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

偏好记录器

人们在跟助手一起工作时会做出几十个小决定:一种颜色、一个库、一条命名规则、“不要做 X”、“选 B”。大多数决定从未被记下来,所以下次会话又会问一遍,或者悄悄把它们推翻。这个技能维护一个文件 PREFERENCES.md,在每次做出决定的那一刻就记录下来,因此它能跨会话、跨工具、跨协作者保留。

何时行动

读取 PREFERENCES.md,在你对包含此文件的项目进行第一次改动之前,以及在你提出设计方案、选项或任何该文件可能已经决定的内容之前。遵循其中的内容。除非用户主动提起,否则不要就文件中已记录的事项再次询问。

写入 该文件,在与工作同一轮的回复中,当用户:

  • 陈述偏好或规则(“我更喜欢标签页”、“始终使用英式拼写”、“绝不直接提交到 main 分支”);
  • 在你提供的选项中做出选择(“A”、“选第二个”、“把 A 和 C 混起来”);
  • 纠正或拒绝某事完成的方式(“这样看起来不好”、“不,把它放到右边”、“那样不对,只有当...”),前提是纠正内容说明了应该如何做;
  • 更改或撤销先前的决策;
  • 尝试性地做事(“试试这个”):记录时标记为试用。

不要记录:

  • 仅适用于当前任务的一次性指令(“重命名这个变量”);
  • 代码或历史已包含的事实(文件结构、安装了哪个库);
  • 密钥、凭证、令牌或任何人的个人数据(地址、身份证号、健康信息)。记录决策本身,而非私有数值:“在页脚使用用户的真实姓名”,如果名字敏感,绝不能写下名字本身;
  • 你自己提出但未被用户接受的建议。

如果你不确定某件事是否为持久决策,记录下它:多写一行短信息的成本远低于遗忘一个选择的代价。

文件位置

PREFERENCES.md 位于项目根目录,除非项目的代理指令文件(CLAUDE.md、AGENTS.md 或类似文件)指定了其他路径。如果没有项目(一次性聊天),不要创建文件;只需跟随用户所说的话。

如果文件还不存在,从 templates/PREFERENCES.md(位于此文件旁边)创建它,并写下第一个决策。然后,如果项目有 CLAUDE.md 或 AGENTS.md,在靠近顶部的位置添加一行,以便将来的每个会话都能读取它:

首先读取 PREFERENCES.md 并保持更新:每当做出或更改决策时,编辑对应行并添加带日期的变更日志条目,在同一轮操作中完成。

格式

# <项目名称> — 决策

一行说明这个文件是什么。

## <主题>
- **<决策的简短名称>:** 用平实的语言说明决策内容。为什么,以及当用户说明原因时也要记下。(之前:被替换的内容及其时间。)

## 变更日志
- 2026年10月17日 — <一行说明什么决策被做出或更改>(用户原话:“...”)。

保持文件有用的规则:

  1. 每条决策一行,按主题分组。 选择适合项目的主题(产品、设计、技术栈、工作流程、写作……)。开始时少一些,当某个决策不属于任何现有主题时再添加新主题。
  2. 就地编辑。 当决策变更时,重写对应行以说明当前状态,并在“之前:……”的简短注释中保留旧的选择。绝不能让两行相互矛盾。
  3. 每次变更都添加一条变更日志, 最新的在最下面,使用绝对日期(“2026年10月17日”,绝不用“今天”或“昨天”)。写入时转换相对日期。
  4. 保留用户的原话,针对重要部分,引用并尽量简短:这有助于日后明确当时的意思。不要曲解用户的意图,也不要让表述听起来比实际更强烈。
  5. 说明原因,当用户给出理由时。理由能让后续会话处理规则未预见的情况。
  6. 链接决策所指的内容: 设计稿、问题、原型、提交记录。
  7. 标记试用和不确定项: “(正在尝试)”、“(尚未最终确定)”。在确定后移除标记。
  8. 简洁地写。 用短句子,不使用用户未用过的术语。使用“用户”或“他们”,除非用户指定了想用的代词;不要根据姓名猜测。

当请求与文件冲突时

最新的明确声明优先。如果用户现在要求的某个事情与文件中规定的相悖,按用户要求执行,并更新对应的行和变更日志。如果存在模棱两可的情况:用户是否打算更改规则,用一个简短的问题询问,并引用文件中相关的行。

简要告知用户

在你更新文件后,在回复末尾用一句简短的话提及(“我已将此记录在 PREFERENCES.md 中”),而不是总结文件内容。只有在被问到时才展示完整文件。

示例

用户在你看待的三种侧边栏设计中选择了“A,但按钮应该用图标”。在构建的同一轮回复中,你写下:

## 设计
- **侧边栏:** 紧凑菜单;文件夹列表填充剩余高度并可以滚动;设置和隐私开关在最下面一行用图标按钮呈现(从三个选项中选了 A,并用图标按钮)。

## 变更日志
- 2026年10月17日 — 侧边栏:选择了选项 A,底部操作改为图标按钮(用户原话:“A,但按钮应该用图标”)。

一周后用户说“把那些按钮的标签加回来”:

- **侧边栏:** …… 设置和隐私开关在底部一行用带标签的按钮呈现。(之前:仅图标,2026年10月17日。)

- 2026年10月24日 — 侧边栏底部按钮恢复标签(用户原话:“把那些按钮的标签加回来”)。

相关技能