vault backup: 2026-07-22 18:33:29

.obsidian/workspace.json

@@ -20,8 +20,23 @@
               "icon": "lucide-file",
               "icon": "lucide-file",
               "title": "使用说明"
               "title": "使用说明"
             }
             }
+          },
+          {
+            "id": "9e12cc0466efde53",
+            "type": "leaf",
+            "state": {
+              "type": "split-diff-view",
+              "state": {
+                "aFile": "Claude.md.md",
+                "bFile": "Claude.md.md",
+                "aRef": ""
+              },
+              "icon": "diff",
+              "title": "Diff: Claude.md  (Working Tree)"
+            }
           }
           }
-        ]
+        ],
+        "currentTab": 1
       }
       }
     ],
     ],
     "direction": "vertical"
     "direction": "vertical"
@@ -193,14 +208,15 @@
       "obsidian-git:Open Git source control": false
       "obsidian-git:Open Git source control": false
     }
     }
   },
   },
-  "active": "56785e597f159884",
+  "active": "9e12cc0466efde53",
   "lastOpenFiles": [
   "lastOpenFiles": [
+    "Claude.md.md",
+    "使用说明.md.md",
+    "2、工作规划/使用说明.md",
     "1、产品现状/使用说明.md",
     "1、产品现状/使用说明.md",
     "0、《官网》",
     "0、《官网》",
-    "使用说明.md",
     "4、系统设计/使用说明.md",
     "4、系统设计/使用说明.md",
     "3、需求及UI设计/使用说明.md",
     "3、需求及UI设计/使用说明.md",
-    "2、工作规划/使用说明.md",
     "7、会议纪要/会议纪要模版.md",
     "7、会议纪要/会议纪要模版.md",
     "8、个人工作/杨泽辉/使用说明.md",
     "8、个人工作/杨泽辉/使用说明.md",
     "8、个人工作/赵作文/使用说明.md",
     "8、个人工作/赵作文/使用说明.md",

Claude.md.md

+# 产品单元知识库 AI 工作约定
+
+> 状态：已审核 ｜ 维护人：杨泽辉 ｜ 日期：2026-07-20 本文件是 AI（Claude）在本仓库工作时自动加载的团队约定。修改需经杨泽辉评审。
+
+---
+
+## 一、你在哪里工作
+
+本仓库是一个**产品单元**的唯一事实源与团队记忆，服务于一个 2–3 人的 AI 增强小组。团队的分工方式是：**AI 承担产出（文档、设计稿、代码、测试的初稿），人承担判断（对不对、能不能用、该不该上）**。你产出的一切内容都是草稿，最终以人的确认为准。
+
+团队背景：北京金色华勤数据服务有限公司人事服务事业部，业务围绕亲亲企服与亲亲小保展开。本库对应的产品单元见产品现状/产品概述.md`。
+
+---
+
+## 二、目录导航：读什么、写到哪
+
+|目录 / 文件|作用|你的权限|
+|---|---|---|
+|`CLAUDE.md`|本约定|只读，不得修改|
+|`使用说明.md`|人的入口，库的用法|只读|
+|`产品现状/`|**当前有效的全部规则与逻辑，唯一可信来源**|读；仅在人明确指示时修改|
+|`产品现状/产品概述.md`|产品定位、边界、核心概念|同上|
+|`产品现状/业务规则/`|规则条目，一条主题一个文件，带编号|同上|
+|`产品现状/核心流程/`|流程与状态机，一条流程一个文件|同上|
+|`工作规划/工作规划.md`|什么时间完成什么，用版本号串起需求与设计|读；按指示更新|
+|`需求及UI设计/`|按版本号建目录（如 `V2.0（2026-06-20）【进行中】/`）|读写|
+|`系统设计/`|技术方案（研发维护）|读；按指示写|
+|`测试/`|测试用例与记录|读写|
+|`决策记录/`|决策档案，**只增不改**|只可新增，禁止修改已有文件|
+|`会议纪要/`|会议档案，**只增不改**|只可新增，禁止修改已有文件|
+|`个人工作/{姓名}/`|个人过程产物，不代表单元成果|读写（写入当前使用者的目录）|
+|`附件/`|图片、物料等非文本附件|读；压缩后的图片放这里|
+
+**产出位置规则**：未经确认的探索性产出，先放 `个人工作/{使用者姓名}/`；经人确认要成为单元成果的，才写入对应正式目录。不确定放哪时，先问。
+
+---
+
+## 三、六条核心约定（不可违反）
+
+1. **以产品现状为准**。回答任何"现在的规则/流程是什么"的问题，只依据 `产品现状/`。发现 `产品现状/` 与需求文档、会议纪要或其他材料冲突时，**报告冲突，不自行选边**，更不要擅自修改任何一方。
+2. **不执行任何 git 命令**。不 add、不 commit、不 push、不 pull。你只读写文件；版本操作由人在 GitHub Desktop 中完成，commit 前的 diff 预览是人审你产出的固定关口。
+3. **只增不改**：`决策记录/` 与 `会议纪要/` 中的已有文件一律不得修改。结论被推翻时，新增一篇并在文首注明"取代 D-XXXXXXXX-XX"。
+4. **引用编号，不复述内容**。在需求、测试等文档中引用业务规则时，写规则编号（如 QF-R-001），不要把规则原文抄一遍。
+5. **草稿要声明**。引用任何头部标注"状态：草稿"的文档内容时，必须向使用者明确声明"该内容尚未评审"。你产出的所有新文档，头部状态一律标"草稿"。
+6. **敏感数据红线**：社保业务数据、客户个人信息（姓名、身份证号、手机号、社保账号等）一律不得写入本仓库的任何文件。发现使用者提供的材料中含有此类数据时，提醒并在产出中脱敏。
+
+---
+
+## 四、文档格式规范
+
+**所有新建文档的头部**：
+
+```
+> 状态：草稿 ｜ 撰写：Claude（{使用者姓名}发起）｜ 日期：YYYY-MM-DD
+```
+
+经人评审后由人改为"已审"并署审核人。
+
+**编号体系**：
+
+- 决策记录：`D-{YYYYMMDD}-{序号}`，如 D-20260720-01
+- 业务规则：`{产品缩写}-R-{三位序号}`，如 QF-R-001；每条规则须标注生效日期与来源（关联的决策记录或会议纪要）
+- 文件命名：决策记录与会议纪要为 `YYYY-MM-DD-主题.md`；禁止"最终版-v3-改2"式命名，同一文档保持同一文件名，修订靠 Git 留痕
+
+**模板**：新建决策记录、会议纪要必须复制对应目录下的 `_模版.md`，不得自创结构。模板中标注"必填"的字段（会议"结论"、决策"需更新的事实源文件"）不得留空——留不出内容说明该会议不该入库或该决策没想清楚，如实告知使用者。
+
+**语言与风格**：一律使用中文；表达简洁直接，结论先行；不堆砌修饰。产出文档时遵循团队"最小格式"偏好：能用短句和小节说清的，不用长篇结构。
+
+---
+
+## 五、常见任务的操作规程
+
+**1. 撰写/修订需求（PRD）**
+
+- 输出位置：`需求及UI设计/V{版本号}（{日期}）【进行中】/` 目录下
+- 动笔前先读：`产品现状/` 全部相关文件 + `工作规划/工作规划.md` + 上一版本需求
+- 涉及既有规则变化的，在文档中明确标注"本需求变更规则 XX-R-XXX"，并提示使用者：验收通过后需同步 `产品现状/` 并撰写决策记录
+
+**2. 会议纪要提炼**
+
+- 输入：录音转写稿或聊天记录；输出：按 `会议纪要/_模版.md` 成文
+- 入库标准：产生决策、变更规则、或分配带截止日期任务的会议才入库；不满足的，告知使用者本次不建议入库
+- 纪要中识别出的决策，提醒使用者是否需要另行撰写决策记录
+
+**3. 更新产品现状**
+
+- 仅在人明确指示时进行；一次改动对应一条决策或一个已验收需求
+- 修改规则文件时保留规则编号不变，更新内容与生效日期，来源链接指向对应决策记录
+- 完成后向使用者列出改动清单，提醒产品单元负责人评审（产品现状与决策记录的变更必须经产品单元负责人批准）
+
+**4. 每周核对（产品单元负责人发起）**
+
+- 扫描本周新增的 `决策记录/` 与 `会议纪要/`
+- 逐条对照 `产品现状/`和进行中的需求，输出本周项目变更的清单：决策编号、结论摘要、当前是否已响应、当前进展、应更新的文件、。
+- 清单输出到 `个人工作/{产品单元负责人姓名}/` 下，供人处理，不自行代改
+
+**5. 测试用例生成**
+
+- 输入：指定版本的需求文档 + `产品现状/业务规则/` 相关条目
+- 输出到 `测试/` 对应目录，用例中引用规则编号
+- 需求变更时，基于变更点做增量更新，列出受影响的既有用例
+
+---
+
+## 六、术语表
+
+| 术语      | 含义                                                        |
+| ------- | --------------------------------------------------------- |
+| 产品单元    | 一块独立、完整、能自己闭环的产品功能，对外只暴露一份契约（目的/输入/输出/触发/边界），由 2–3 人小组负全责 |
+| 事实源     | 即 `产品现状/` 目录，当前有效规则与逻辑的唯一可信来源                             |
+| 入库      | 文件提交进本仓库并 push。只有入库的才算团队成果，聊天记录里的产出不算                     |
+| 产品单元负责人 | 负责冲突处理、MR 评审、规范抽查、每周核对的角色                                 |
+| 亲亲企服    | 面向企业的服务平台（平台底座 + 官网 + 客户端）                                |
+| 亲亲小保    | 面向个人的事业发展顾问(面向灵活就业者、自由职业者、想搞副业的人)。                        |
+| 自动申报员   | RPA 底座之上的社保/公积金申报自动化产品                                    |
+| 亲亲创客    | 合伙人推广平台                                                   |
+
+（各产品单元可在此追加自己的专属术语，或维护于 `产品现状/` 下的术语文件。）
+
+---
+
+## 七、禁止事项清单
+
+- 修改 `CLAUDE.md`、`使用说明.md`、`决策记录/` 与 `会议纪要/` 中的已有文件
+- 执行任何 git / 网络推送类命令
+- 在未被指示的情况下改动 `产品现状/`
+- 把规则原文复制到其他文档（应引用编号）
+- 编造不存在的规则编号、决策编号或文件引用——引用前必须确认目标文件真实存在；找不到依据时明确说"库中没有相关记录"，不得虚构
\ No newline at end of file

使用说明.md

-# 亲亲企服平台产品单元 · 知识库使用说明
-# 亲亲企服平台产品单元 · 知识库使用说明
-> 状态：已审 ｜ 审核人：杨泽辉 ｜ 日期：2026-07-20
-
-## 1. 这个库是什么
-本库是某一个产品单元的唯一事实源与团队记忆。
-查「现在的规则是什么」——只看 产品现状/；
-查「这次要改什么」——看 需求及UI设计/。
-
-## 2. 目录速览
-- CLAUDE.md：AI 工作指令，工具自动加载，勿手改
-- 产品现状/：当前有效的全部规则与流程（唯一可信）
-- 需求及UI设计/：按版本号归档的需求与原型
-- 决策记录/、会议纪要/：只增不改，按 _模版.md 写
-- 个人工作/：个人过程产物，不代表单元成果
-
-## 3. 日常动作
-1. 开工先 Pull，收工必 Push
-2. 提交摘要格式：[产品线] 动作 对象
-3. 决策 / 纪要写完即入库，口头结论不算数
-4. 遇到冲突交仓库守门人处理，不自行合并
-
-## 4. 三条铁律
-- 事实源唯一：规则只写在 产品现状/，别处引用编号、不复述
-- 只增不改：决策 / 纪要提交后不改，被推翻就新增并注明「取代 XX」
-- 入库才算数：没进库的成果不算团队成果
\ No newline at end of file

使用说明.md.md

+# 产品单元知识库 · 使用说明
+# 产品单元知识库 · 使用说明
+
+> 状态：草稿 ｜ 维护人：杨泽辉 ｜ 日期：2026-07-22 本文档是给人看的入口。AI 的工作约定见根目录 `CLAUDE.md`（工具自动加载，请勿手改）。
+
+---
+
+## 1. 这个库是什么
+
+本库是一个**产品单元**的唯一事实源与团队记忆。三句话记住它的用法：
+
+- 查「**现在的规则是什么**」→ 只看 `产品现状/`
+- 查「**这次要改什么**」→ 看 `需求及UI设计/` 下【进行中】的版本目录
+- 查「**当初为什么这么定**」→ 翻 `决策记录/` 和 `会议纪要/`
+
+我们的工作方式：**AI 承担产出**（文档、原型、代码、测试的初稿），**人承担判断**（对不对、能不能用、该不该上）。所以这个库既是给人看的档案，也是 AI 干活的上下文——库的质量直接决定 AI 产出的质量。
+
+## 2. 目录速览
+
+|目录 / 文件|放什么|维护人|
+|---|---|---|
+|`CLAUDE.md`|AI 工作指令，工具自动加载|产品单元负责人，勿手改|
+|`使用说明.md`|本文档|产品单元负责人|
+|`产品现状/`|当前有效的全部规则与流程（唯一可信）：产品概述、业务规则（一条一文件、带编号）、核心流程|产品单元负责人|
+|`工作规划/`|什么时间完成什么，用版本号串起需求与设计|产品单元负责人|
+|`需求及UI设计/`|按版本建目录，如 `V2.0（2026-06-20）【进行中】/`：PRD、HTML 原型、UI 设计图（只存设计平台链接）、相关物料|产品经理 + UI 设计师|
+|`系统设计/`|技术方案|研发负责人|
+|`测试/`|测试用例与记录|研发负责人|
+|`决策记录/`|决策档案，按 `_模版.md` 写，**只增不改**|全员均可新增|
+|`会议纪要/`|会议档案，按 `_模版.md` 写，**只增不改**|全员均可新增|
+|`个人工作/{姓名}/`|个人过程产物、AI 探索性草稿|每位成员|
+|`附件/`|压缩后的图片、物料等非文本附件|全员|
+
+**个人工作/ 与正式目录的关系**：没确认的东西先放自己名下的文件夹；经确认要成为单元成果的，才移入对应正式目录。正式目录里不应出现半成品。
+
+## 3. 每天怎么干活
+
+```
+开工 → GitHub Desktop 点 Pull（拿到同事最新成果）
+     → Cowork 指向本仓库文件夹，正常工作（AI 产出直接落盘）
+     → GitHub Desktop 逐文件预览 diff（这一步就是你审 AI 的关口，不许跳过）
+     → 勾选要提交的文件，写摘要，Commit
+收工 → Push（不 Push 同事看不到，等于没干）
+```
+
+- 提交摘要格式：`[产品线] 动作 对象`，例：`[自动申报员] 更新异常通知需求：增加短信渠道`
+- 给 AI 布置任务时说清输入和输出位置：「读 产品现状/业务规则/，把测试用例写到 测试/V2.0/」
+- **遇到合并冲突：停手，群里喊产品单元负责人，不要自行解决**
+
+## 4. 三条铁律
+
+1. **事实源唯一**：规则只写在 `产品现状/`，别处引用编号（如 QF-R-001）、不复述原文。改了决策必须当天同步产品现状。
+2. **只增不改**：决策记录、会议纪要提交后不修改；结论被推翻时新增一篇并注明「取代 D-XXXXXXXX-XX」。
+3. **入库才算数**：聊天记录、个人电脑里的产出不算团队成果，提交进库并 Push 才算。
+
+## 5. 十条管理规范（速查）
+
+1. **AI 约定**：以事实源为准、冲突报告不选边、不执行 git 命令、每周核对「已决策未同步」清单（详见 CLAUDE.md）
+2. **同步纪律**：开工先 Pull，收工必 Push；commit 前逐文件预览 diff
+3. **事实源唯一**：只存结论不存过程，每条规则带编号、生效日期、来源链接
+4. **需求与事实源的边界**：需求 = 增量（这次改什么），事实源 = 全量（现在是什么）；需求验收通过时，规则条目合并进产品现状，版本目录标注【已完成并归档】
+5. **评审机制**：`产品现状/` 和 `决策记录/` 的变更必须走 GitLab MR，reviewer 批准后合并；其余目录初期可直推
+6. **只增不改**：见铁律二
+7. **状态标记**：所有文档头部标注 `状态：草稿/已审 + 审核人 + 日期`；AI 产出一律先标草稿
+8. **会议入库标准**：产生决策、变更规则、或分配带截止日期任务的会议才入库，「结论」为必填项
+9. **冲突处理**：非技术成员遇冲突交产品单元负责人；事实源文件按主题拆细以降低冲突率
+10. **文件类型**：仓库只收文本成果（md/html/svg/代码）；图片压缩后入 `附件/`；设计源文件和视频放网盘留链接；**敏感业务数据（客户个人信息、社保数据）一律不入库**
+
+## 6. 角色分工
+
+|角色|职责|
+|---|---|
+|产品单元负责人|对单元目标、计划、交付负全责；维护产品现状与工作规划；晨会发言、周会汇报；处理冲突、MR 评审、规范抽查、发起每周 AI 核对|
+|产品负责人|需求分析、产品设计、原型与 UI、验收标准、对接业务与事实源|
+|研发负责人|技术方案、开发实现、测试联调、质量与运行环境|
+
+## 7. 常用操作对照
+
+|我想……|怎么做|
+|---|---|
+|了解产品现在的规则|读 `产品现状/`，或直接问 Cowork（它以产品现状为准）|
+|开一版新需求|在 `需求及UI设计/` 建 `V{x.x}（日期）【进行中】/`，让 AI 按模板起草 PRD|
+|记录一个决策|复制 `决策记录/_模版.md`，填全必填项（尤其「需更新的事实源文件」），入库|
+|整理会议纪要|把录音转写稿丢给 Cowork，按 `会议纪要/_模版.md` 提炼，人确认后入库|
+|需求验收通过了|规则条目合并进 `产品现状/`（走 MR），版本目录改标【已完成并归档】|
+|找某条规则当初为什么这么定|看规则条目里的来源链接 → 对应决策记录|
+|看某文件的修改历史|GitHub Desktop → History 标签|
+
+## 8. 新成员接入清单
+
+1. 找 IT 申请 VPN 账号（注明需访问 GitLab），安装客户端，验证能打开 GitLab 页面
+2. 安装 Git + GitHub Desktop，clone 本仓库到统一路径 `~/Work/{仓库名}`
+3. 终端执行一次：`git config --global core.quotepath false`（否则中文文件名显示为转义码）
+4. 安装 Claude 桌面版，切到 Cowork 模式，「Work in a folder」指向仓库文件夹
+5. 通读本文档 + `产品现状/产品概述.md`
+6. 在 `个人工作/` 下建自己的文件夹，做一次完整的 Pull → 改动 → Commit → Push 演练
+7. 有疑问先问产品单元负责人，不要凭感觉往正式目录里放东西
\ No newline at end of file