三份文档与方法论沉淀
FEATURES / CHANGELOG / RELEASE_NOTES 各管一个维度，METHODOLOGY 沉淀产品品味
本页解决的问题
先给结论「三份文档与方法论沉淀」要解决的关键问题是什么？
FEATURES / CHANGELOG / RELEASE_NOTES 各管一个维度，METHODOLOGY 沉淀产品品味
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
核心分工：FEATURES 回答「这个功能怎么来的」，CHANGELOG 回答「这次改了什么」，RELEASE_NOTES 回答「用户得到了什么」，METHODOLOGY 回答「我们是怎么想的」。四个问题各有归处，决策才能跨越对话存活。
功能的完整生命周期
功能点的唯一事实来源。状态流转 🟡 规划中 → 🔵 开发中 → 🟢 已完成 / ⚪ 已取消，每个功能带「历史沿革」，记录初始需求、方案变更及原因、最终实现。取消的功能也不删，标 ⚪ 并注明原因。
每次改动的技术细节
按时间倒序，每条用表格记录问题/需求、根因/方案、改动范围、影响面、状态，类型标签 BUG / FEAT / REFACTOR / PERF / DOCS。写之前必须读系统时间，禁止凭记忆填时间戳，禁止积压补写。
用户能感知的变化
面向真实用户，语言风格与 CHANGELOG 完全不同。每条描述必须能回答「这对我有什么用」。红线：禁写调试功能、技术细节和用户无感知的改动。
产品决策与品味
AI 主动识别对话中的产品思路、决策逻辑和取舍偏好，提炼后直接写入，新对话自动继承。四段结构：产品原则、设计决策记录、用户体验偏好、反模式。
项目里每天都会产生各种信息，分诊能力决定文档体系能不能跑起来。下面逐条给出 8 条真实信息，判断每条该写进哪份文档。
FEATURES 里每个功能都带一条「历史沿革」。它靠状态流转自动生长：每次状态变更、方案调整都追加一条带日期的记录。点击按钮，亲手把一个功能从规划推到上线。
记录里的日期读的是你设备的系统时间。规则原文要求：时间必须读取系统当前时间，不能凭记忆填写；方案没变过也要写一条「初始需求」。
每条改动用固定字段的表格记录，AI 按格填写就行，不需要每次想该写什么。
## YYYY-MM-DD HH:MM
### [类型] 标题 类型：BUG / FEAT / REFACTOR / PERF / DOCS
| 字段 | 内容 |
|-----------|--------------------------------------------|
| 问题/需求 | 触发这次改动的原因（用户反馈 / Bug 表现 / 新需求）|
| 根因/方案 | Bug 填根因分析，功能填技术方案概述 |
| 改动范围 | 涉及的文件或模块列表 |
| 影响面 | 这次改动可能影响哪些已有功能 |
| 状态 | ✅ 已完成 / ⏳ 进行中 / ⚠️ 需观察 |- Debug / 调试相关功能
- 技术实现细节：模块名、文件路径、重构
- 用户无感知的改动
- 开发者术语和技术原理解释
- 用户能感知到的变化，每条能回答「这对我有什么用」
- 新功能：一句话说明用户能做什么新事情
- 修复：之前什么问题，现在解决了
- 每条不超过 3 句话，版本号遵循 SemVer
四段结构
- 产品原则：反复出现的核心信念和产品理念
- 设计决策记录：[日期] 决策内容，附理由与上下文
- 用户体验偏好：对 UI/UX 的品味、倾向、审美标准
- 反模式：明确拒绝过的方案，附拒绝理由
写入原则
- 提炼本质，同类合并，新条目标注日期，避免照搬对话原文
- 不记技术实现细节（那是 CHANGELOG 的事），不记一次性临时决定
- 触发时机：用户解释了「为什么这样做」、否决了方案并给出理由、表达了明确的 UI/UX 偏好、复盘时总结了经验
- AI 识别到就直接写入，写完简要告知，无需每次征求许可
为什么放在仓库里：设计决策写在 Notion 或飞书里也没用，AI 读不到外部文档。放在项目仓库内的 Markdown 文件是唯一能让 AI 自动获取上下文的方式。
提交物：docs/ 目录 + 3 条方法论。① 在一个进行中的项目里建 docs/ 目录，让 AI 按模板初始化三份文档，把现有功能补进 FEATURES.md；② 把文档维护规则加入 Rule 文件，做一次小改动，验证 AI 是否自动更新 CHANGELOG；③ 回顾最近的产品讨论，手动往 METHODOLOGY.md 写 3 条你确认过的设计决策。
素材来源：开源仓库 itshen/xs_vibe_rules 中 rule-opensource.mdc 第九章「版本记录与文档维护」、第十二章「产品方法论沉淀」。
从「功能的完整生命周期」把感觉变成判断
「核心分工： FEATURES 回答「这个功能怎么来的」，CHANGELOG 回答「这次改了什么」，RELEASE_NOTES 回答「用户得到了什么」，METHODOLOGY 回答「我们是怎么想的」。四个问题各有归处，决策才能跨越对话存活」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「功能点的唯一事实来源。状态流转 🟡 规划中 → 🔵 开发中 → 🟢 已完成 / ⚪ 已取消，每个功能带「历史沿革」，记录初始需求、方案变更及原因、最终实现。取消的功能也不删，标 ⚪ 并注明原因」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
- 用户能感知到的变化，每条能回答「这对我有什么用」
- 每条不超过 3 句话，版本号遵循 SemVer
- 设计决策记录 ：[日期] 决策内容，附理由与上下文
漂亮不等于容易用
把「提交物：docs/ 目录 + 3 条方法论。① 在一个进行中的项目里建 docs/ 目录，让 AI 按模板初始化三份文档，把现有功能补进 FEATURES.md；② 把文档维护规则加入 Rule 文件，做一次小改动，验证 AI 是否自动更新 CHANGELOG；③ 回顾最近的产品讨论，手动往 METHODOLOGY.md 写 3 条你确认过的设计决策」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「功能的完整生命周期」走到「每次改动的技术细节」
「功能的完整生命周期」先把问题落在「功能点的唯一事实来源。状态流转 🟡 规划中 → 🔵 开发中 → 🟢 已完成 / ⚪ 已取消，每个功能带「历史沿革」，记录初始需求、方案变更及原因、最终实现。取消的功能也不删，标 ⚪ 并注明原因」上；到了「每次改动的技术细节」，讨论继续推进到「按时间倒序，每条用表格记录问题/需求、根因/方案、改动范围、影响面、状态，类型标签 BUG / FEAT / REFACTOR / PERF / DOCS。写之前必须读系统时间，禁止凭记忆填时间戳，禁止积压补写」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「功能的完整生命周期」：功能点的唯一事实来源。状态流转 🟡 规划中 → 🔵 开发中 → 🟢 已完成 / ⚪ 已取消，每个功能带「历史沿革」，记录初始需求、方案变更及原因、最终实现。取消的功能也不删，标 ⚪ 并注明原因
- 「每次改动的技术细节」：按时间倒序，每条用表格记录问题/需求、根因/方案、改动范围、影响面、状态，类型标签 BUG / FEAT / REFACTOR / PERF / DOCS。写之前必须读系统时间，禁止凭记忆填时间戳，禁止积压补写
- 「最后的要点」：提炼本质，同类合并，新条目标注日期，避免照搬对话原文
最后的「最后的要点」把讨论落到「提炼本质，同类合并，新条目标注日期，避免照搬对话原文」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。