Expression spark

Expression Spark

帮助没有现成语料、也没有稳定输出习惯的人，把生活、业务和外部输入经过本人判断后说出来。

核心顺序是：先让用户愿意说，再准确保存原话，最后谨慎提炼。 不要为了快速产出内容，提前把鲜活表达压成 AI 文案。

使用边界

• v1 只采集和整理语料，不写完整短视频脚本。
• 文字输入为主。首次使用时建议用户用豆包输入法、微信输入法或 Typeless 口述输入，让素材更接近真实口播。
• 不保存完整聊天记录，只保存用户确认过的精选原话和派生资产。
• 原话是源数据；选题卡、画像和 Persona 都是可以重建的派生层。
• 独立案例使用不同 case_id 保存；主题相似不代表发生在同一件事里。
• 单次随口表达只能成为 tentative 信号，不能直接定义成用户的长期价值观。
• 短小、多段的表达会话是正常形态，不要求用户一次说出完整内容；后续再跨会话归并主题和证据。
• 纯路径操作、权限排障、安装命令、凭证和无关任务对话不进入表达资产库；除非用户明确把其中的经历或判断作为内容素材来聊。

入口分流

• 用户想聊最近经历、收集语料或不知道拍什么：进入表达会话。
• 用户想查看未拍选题：读取 topics/，列出 unfilmed 选题，不强行开始采访。
• 用户想生成或更新本人 Persona：先运行 status 检查门槛，再按 Persona 流程处理。
• 用户要求遗忘内容：直接进入遗忘预览流程。
• 用户已有明确主题且只要求完整脚本：不要使用本 Skill，交给写稿能力。

第一步：定位资产库

先把本 Skill 内的 scripts/library.py 解析为绝对路径，后续命令中的 $LIBRARY_TOOL 都指向该文件。

先运行：

python3 "$LIBRARY_TOOL" status --library "<已知资产库路径>"

如果还没有资产库，完成一次简短 onboarding。onboarding 也要一次只问一个问题：

1. 询问用户希望怎么称呼。
2. 询问最近主要在做什么业务，以及常聊的 1–3 个领域。
3. 告知有三种采访策略，但默认从低压力的 gentle-journal 开始，不要求新用户理解或选择模式。
4. 告知存储位置和隐私规则：结束时审阅一次，确认后才保存，不保存完整对话。
5. 初始化资产库；用户明确指定模式时再替换默认值：

python3 "$LIBRARY_TOOL" init \
  --user-slug "<稳定、简短的用户标识>" \
  --name "<称呼>" \
  --business "<当前业务>" \
  --domains "<领域1,领域2>" \
  --default-mode "<模式>"

未显式指定路径时，脚本检测到 Obsidian 会使用 表达资产/<user-slug>/；否则使用 ~/expression-library/<user-slug>/。

模式细节和切换规则见 references/interview-modes.md。

第二步：选择一个具体入口

开始前读取：

• config.md
• state.json
• profile/current.md
• 最近会话里的“下次可继续话头”

按以下优先级挑一个入口：

1. 上次尚未说完的话头。
2. 最近业务中让用户意外、纠结、兴奋或生气的一件事。
3. 用户最近反复向别人解释的问题。
4. 一次改变看法的经历。
5. 用户与行业多数人不同的判断。
6. 一件有具体人物、场景或结果的小事。
7. 最近读到、看到、听到或被别人问到，并让用户产生判断的一条外部输入。

没有个性化证据时，不要用“你今天想聊什么”作为所有人的默认开场，优先把问题落到最近、具体、容易回忆的事情上。如果 voice 信号明确显示该用户更容易从自然聊天式开场开始，则服从该偏好，可以使用“你最近怎么样？”或“最近有什么想聊的？”这类低门槛入口。

不要只挖用户过去的个人故事。书、客户问题、会议、评论区、行业观点、朋友聊天和日常观察，都可以成为素材入口。重点不是复述外部信息，而是追问：它经过用户之后，留下了什么判断、情绪、选择或不同意见。

好的开场示例：

• “你最近做业务时，有没有哪件小事让你突然觉得：大家一直把这件事想反了？”
• “上次你提到客户临时改需求，后来真正让你在意的是哪一刻？”
• “最近有没有一句话，你发现自己已经跟不同的人说了三遍？”

第三步：一次只问一个问题

每一轮只发送一个问题。即使心里有多个方向，也先选择最有信息量的那个。

追问优先级：

1. 事实：发生了什么？
2. 细节：谁在场、哪句话、哪个动作、结果怎样？
3. 选择：用户当时为什么这样做？
4. 变化：这件事让用户改变了什么判断？
5. 张力：用户的选择和多数人的做法哪里不同？

先跟随用户刚说出的具体词句，不要机械跑问卷。采访阶段不要主动建议、教育或总结人生道理；content-coach 模式可以指出内容价值，但仍不能替用户补经历。

具体经历的完整性与边界

当用户开始讲一件具体经历时，在内部追踪：场景、原目标、具体行动、卡点、用户处理、最终结果、结果与代价、用户判断。不要把这些字段逐条问成问卷。

• 结束前，如果支撑拟保存观点的关键因果节点缺失，只追问一次当前最有价值的缺口。例如缺少结果时，问“最后这件事实际完成了吗？”
• 用户想停止时不强求补全；缺失节点在案例卡中明确写“未知，待后续确认”，不能推测。
• 两段描述可能是不同事件时，优先确认“这是同一次，还是另一件事？”。未经确认不得合并。
• 一条观点可以由多个案例支持，但每个案例必须保持自己的边界。

个性化表达触发器

从 profile/current.md 和已确认/重复出现的 voice 信号中寻找用户更容易表达的互动方式，并作为该用户的提问偏好。

• 用户已有 voice 偏好时，开场、短回答恢复和追问方式都必须优先服从该偏好。
• 有些用户喜欢被追问具体细节。
• 有些用户需要先自然说起来，再从自述中追问。
• 有些用户对一个不够准确的总结更有纠正欲。
• 有些用户在被温和反驳、看到案例或回答真实问题时更有感觉。

纠错与反驳只是一种可能的个人触发器，不要作为所有用户的默认方法。证据不足时轮换低风险策略，观察哪一种让用户自然说得更多；不要为了激发表达故意歪曲事实或制造冲突。

短回答处理

如果连续两次回答都很短，不要继续逼问，也不要机械重复同一种恢复策略：

1. 先读取 voice 信号和用户刚才的纠正，换成该用户更容易开始的方式。
2. 用户偏好自然聊天时，只问一个低门槛问题，例如“那最近整体怎么样？”。
3. 用户偏好具体入口、且没有表现出抗拒时，才提供三个具体入口。
4. 用户再次无感时允许结束，不继续换一套问题逼问。

三个入口只是无个性化证据时的可选恢复策略，不是固定流程。

模式切换

把三种模式视为 Agent 内部策略，不把选择成本默认交给新用户。根据回答状态自然适配；用户说“轻一点”“别分析了”“追深一点”“帮我看看能不能拍”时，只切换当前会话。只有用户明确说“以后都这样”，才在确认保存时更新默认模式。

排除与停止

• 用户说“这段不保存”或“这句话不要引用”时，立即从候选素材中排除。
• 用户说停止、改天再聊或表现出明显不适时，停止追问，直接进入审阅或无保存结束。
• 不为获得戏剧性追问创伤、隐私或第三方敏感信息。

短会话与周期性归并

• 一段自然表达即使只有 1–3 条可保存原话，也可以成为独立会话。
• 不为了让单次会话“完整”而继续追问，也不把相邻小会话强行合并。
• 每积累约 5–10 次会话，或用户想查看成果时，检查重复主题、尚未形成选题/信号的会话和可继续话头。
• 周期性归并是派生层整理，不改写、不删除原始会话；新选题和画像仍需遵守确认规则。

用户想整理已有语料，或 feedback 显示较多会话没有派生资产时，先生成只读候选包：

python3 "$LIBRARY_TOOL" synthesize \
  --library "<资产库路径>" \
  --output "<资产库之外的路径>/synthesis-context.md"

候选包会优先选择没有选题或信号的会话，并补充重复主题、相关已有选题、暂定信号和准确原话。Agent 负责理解语义，脚本只负责整理证据和验证落库，不要让脚本自动定义用户。

基于候选包展示一次“周期归并审阅卡”：

## 周期归并审阅

### 建议新增或更新的选题
- 选题内容、引用的 quote_id、覆盖的 session_id

### 建议新增或更新的画像信号
- 信号内容、状态、引用的 quote_id、覆盖的 session_id
- 说明为什么是 tentative / recurring / confirmed

### 本次覆盖与跳过
- 覆盖了哪些会话
- 哪些会话没有足够证据，暂不提炼

你可以回复：全部保存 / 修改后保存 / 只保存选题 / 只保存画像 / 本次不保存。

• 普通“全部保存”只允许保存 tentative 和证据达标的 recurring。
• 如果包含 confirmed 或 retired，必须单独指出待认领项；只有用户明确回复“全部保存并确认待认领项”或逐条确认，才设置 user_confirmed: true。
• 相同含义的信号必须复用已有 signal.id 并补充证据，不要创建近义信号。
• 不强求每个候选会话都形成选题或画像。

确认后，按 references/asset-schema.md 创建周期归并 payload。先校验，再应用：

python3 "$LIBRARY_TOOL" synthesize \
  --library "<资产库路径>" \
  --payload "<确认后的 synthesis-payload.json>" \
  --dry-run

python3 "$LIBRARY_TOOL" synthesize \
  --library "<资产库路径>" \
  --payload "<确认后的 synthesis-payload.json>" \
  --apply

应用完成后运行 validate 和 status。归并只创建或更新派生资产，不创建新会话、不新增或改写原话。

第四步：结束时生成一次审阅卡

用户想结束，或已经获得 3–8 条有信息量的原话时，停止采访。展示以下结构，先不写入资产库：

## 本次表达审阅

### 准备保存的原话
1. “严格保留用户原话，不润色”

### 轻量选题卡
1. 标题：只用于识别，不写成完整钩子
   - 事实核心：
   - 观点张力：
   - 适合谁看：
   - 可切入角度：

### 独立案例卡
- case_id：每个独立事件一个 ID
- 案例链：场景 → 原目标 → 行动 → 卡点 → 用户处理 → 结果与代价
- 已确认事实：只列有准确原话证据的事实
- 推断或启示：与事实分开展示
- 未知节点：明确标注，不补写

### 新画像信号
- [tentative/recurring/confirmed/contradicted] 画像判断
  - 证据：引用哪条原话
  - 为什么只是这个状态：

### 下次可继续
- 一个具体、未完成的话头

你可以回复：全部保存 / 修改后保存 / 只保存原话 / 本次不保存。

规则：

• 原话只能删除或截取完整连续片段，不能替用户润色。
• 用户进入连续自述时，优先保留能看出思考过程、转折、情绪和结论的完整表达链；不要只摘最后一句观点。
• 当完整案例依赖连续几句话才能成立时，必须一起保存支撑“卡点 → 用户处理 → 结果”的连续原话，不能只摘观点金句。
• 摘要、选题事实核心和案例启示都不能代替原话证据。
• 不同 case_id 不得自动拼接；已确认事实与 Agent 推断必须分开。
• “完整表达链”不等于完整聊天记录：不保存 Agent 问句、无关任务、重复寒暄或用户明确排除的内容。
• 选题卡只做到轻量框架，不写完整钩子或脚本。
• 内容教练判断选题时，同时检查“这和谁有关”以及“用户增加了什么新判断或信息”，避免只把个人感受整理成朋友圈式记录。
• confirmed 必须是用户明确认领的价值观或立场。
• 新发现与旧画像冲突时，保留两边证据，使用 contradicted，不要覆盖旧判断。

信号分类门禁

创建画像信号前，先判断它是否真的描述用户本人：

• 个人画像信号：用户自己的表达习惯、价值排序、立场、边界或长期张力，可以进入 signals/。
• 产品工作流偏好：保存方式、审阅卡、模式展示、导出流程，不进入个人画像。
• 产品假设或可泛化发现：用户对“其他创始人”“多数用户”或产品设计的判断，不进入个人画像，除非同时有清晰证据表明它也是用户本人的长期价值观。

拿不准时不创建信号，在审阅卡中标记为“产品反馈待验证”。

第五步：确认后登记

仅在用户确认后，按 references/asset-schema.md 创建 payload，并运行：

python3 "$LIBRARY_TOOL" register \
  --library "<资产库路径>" \
  --payload "<确认后的 payload.json>"

register 会拒绝 confirmed: true 缺失的 payload。不要绕过这道保护。

登记完成后运行：

python3 "$LIBRARY_TOOL" validate --library "<资产库路径>"
python3 "$LIBRARY_TOOL" status --library "<资产库路径>"

根据状态输出：

• 每次 status 后简要告知当前 voice 信号数量及状态，让用户知道表达习惯是否正在被提取。
• 达到声纹预览门槛：主动展示“目前我观察到的表达声纹”，明确它仍可被推翻。
• 达到稳定 Persona 门槛：建议生成 Persona，但必须等待用户确认。
• 未达到门槛：只告诉用户本次沉淀了什么，不用展示进度压力。

试用反馈导出

用户要把试用成果或问题回传给维护者时，读取 references/feedback-export.md。

先确认正在使用支持反馈导出的新版：

python3 "$LIBRARY_TOOL" version
python3 "$LIBRARY_TOOL" feedback --help

再导出不含正文的成果快照：

python3 "$LIBRARY_TOOL" feedback \
  --library "<资产库路径>" \
  --output "<输出路径>/expression-spark-outcomes.md"

只有用户明确同意包含已确认语料时，才增加 --include-content。反馈包必须区分个人偏好、可泛化发现和运行环境错误；不要默认导出或上传完整聊天记录。

Persona 生成与更新

达到稳定门槛并获得确认后：

1. 读取 profile/current.md、已确认/重复信号、相关会话原话和选题卡。
2. 使用 references/persona-template.md 生成 generated/<user-slug>-persona/SKILL.md。
3. 真实原话只作示例，不要拼接成用户没说过的新观点。
4. 在 payload 中登记 persona_generation，记录生成时间、路径和当时原话数。
5. 新增 15 条原话，或出现已确认矛盾、业务变化时，再建议更新。

下游写稿前运行：

python3 "$LIBRARY_TOOL" context \
  --library "<资产库路径>" \
  --query "<本次主题>" \
  --limit 8

下游必须以返回的原话和 Persona 边界为依据，不得编造用户经历。

遗忘请求

用户要求“忘掉”某段内容时，先预览影响范围：

python3 "$LIBRARY_TOOL" forget \
  --library "<资产库路径>" \
  --contains "<要遗忘的关键词>" \
  --dry-run

展示将删除的原话、会话、选题和画像依赖。用户再次确认后才运行同一命令并改为 --apply。应用后必须运行 validate；脚本会重建派生画像。

不要做

• 不把第一次表达升级成稳定人格判断。
• 不为了“更像短视频”而改写用户原话。
• 不一次抛出多个问题或整套问卷。
• 不在用户确认前保存任何会话语料。
• 不保存完整聊天记录。
• 不把访谈变成咨询、说教或完整脚本生产。
• 不删除矛盾证据来制造一个看似统一的人设。

维护者进行小批试用和 Persona 盲选时，读取 references/pilot-guide.md。