一个"周报生成"功能上线后，用户最常做的动作是"重新生成"——平均按三次才满意。而三次生成的成本是"三倍的 token + 三倍的等待"，而用户想要的往往只是"把第二段改成正式一点"。
AI 输出的"可编辑性"是个被低估的设计维度：它决定了"修正的粒度"。这个"抽卡 vs 编辑"的分野很实际："抽卡"的成本全在服务方（token 与延迟），而"编辑"的成本全在用户（几分钟）——于是"哪边更贵"决定了产品形态。
粒度粗（只能重生成），用户就用"抽卡"；粒度细（能改一句），用户就用"编辑"。
1. 三种"修正"的粒度
| 粒度 | 成本 |
|---|---|
| 整段重新生成 | 高（token × 次数） |
| 局部重写（选中一段） | 中 |
| 直接编辑（用户自己改） | 低（零 token） |
第三项最便宜，而它常被"产品设计"排除掉——因为"输出是一段只读的文本"，用户只能"复制出去改"。第三项的"前提"是"输出是"可编辑的载体"（表单、富文本、结构化字段）**"——而"一整段 Markdown 文本"在多数界面里是不可编辑的，于是"最便宜的修正路径"被界面设计挡掉了。
而"复制出去改"会带来一个问题：改完的版本回不到系统里，于是"下次生成又是不满意的版本"，用户每次都要重改。
2. "只读输出"的三种代价
| 代价 | 表现 |
|---|---|
| 抽卡行为 | 反复重生成 |
| 一致性丢失 | 每次生成措辞不同 |
| 反馈缺失 | 系统不知道"哪不满意" |
第三项的"后果"是"每次都是新版本"：用户"喜欢的那一版"再也回不来，于是"抽卡"变成了"碰运气找一版能用的"。
第三项最关键："重新生成"这个动作不携带"哪里不好"的信息，于是模型只能"整体随机变化"。
而"编辑"自带信息：用户改了哪一句，就是"哪里不好"的证据。
3. 三种"可编辑"的设计
| 设计 | 说明 |
|---|---|
| 编辑后再导出 | 最简单（但无反馈） |
| 分段编辑（每段可"重写这段"） | 中（有局部反馈） |
| 编辑即反馈（记录 diff） | 强（可训练/可评测） |
第三项是"数据闭环"：用户的编辑就是"偏好数据"——于是"下次生成更接近他的风格"。第三项的"前提"是"编辑量不能太大"：如果用户"每次都改掉 80%"，那不是"偏好"，而是"输出没用"——这类样本要分开。
第三项的"存储成本"也要算：diff 比原文小得多（只存改动部分），于是"存一年"通常是可行的——而"存全文"才是隐私与成本的主要来源。
代价是"隐私与存储"：diff 里可能含敏感内容，需要脱敏与保留期管理。
// 三种设计的"成本-收益"（同一功能）
1 只读 + 复制：零开发，但"抽卡"持续消耗 token
2 分段重写：开发小，token 省一半（只重写不满意的那段）
3 编辑 + diff：开发中，长期可训练/可评测
// 建议：先做 2（立刻省成本），再做 3（长期收益）
4. "分段重写"怎么落地
| 要素 | 做法 |
|---|---|
| 段落可寻址 | 生成时给每段一个 id |
| 重写请求带上下文 | 只带"这段 + 全局要点" |
| 结果替换原位 | 保持其它段不变 |
第二项是"省钱的关键"：只重写一段时，不必把整篇塞进上下文——于是 token 消耗大幅下降。第二项的"量化"很直接：整篇 800 字重写 ≈ 1200 token；一段 150 字重写 ≈ 300 token——于是"三次重写整篇"与"三次重写一段"差四倍。
第三项的"典型问题"是"语气漂移"：重写的那段更正式，其余段还是口语——于是"读起来像两个人写的"。所以"tone 约束"必须随请求一起给。
第三项要注意"接口一致性"：重写后的段落"长度/语气"要与其它段协调，否则"整体读起来断裂"。
// 分段重写的请求（只带必要上下文）
{"action":"rewrite_segment",
"segment_id":"s2",
"current":"本周完成了接口联调。",
"instruction":"更正式，并说明结果",
"context":{"title":"周报","tone":"正式","other_segments_summary":"三段，共 200 字"}}
// 关键：不带"整篇原文"，只带"这一段 + 全局约束"
"分段"的切法要"与人怎么改"对齐——而不是"按字数切"：
// 三种切法（按"用户会怎么改"选）
按"语义段"切：开头/主体/结尾（用户常改开头与结尾）
按"字段"切：标题、摘要、要点（结构化输出天然可分）
按字数切：每 100 字一段（最差：切断句子，重写后不连贯）
// 判据：用户改的时候"选中范围"通常是什么
5. "编辑即反馈"的三种用法
| 用法 | 说明 |
|---|---|
| 存 diff（不做处理） | 用于人工抽查 |
| 存 diff + 打标 | 形成"偏好对"（原文 vs 改后） |
| 定期用于评测 | 检查"同类问题的修改率" |
第二项是"最有价值"的："原文 → 用户改后"是一对天然的偏好样本第二项的"用途"有两类：训练（继续微调/DPO）与评测（哪类修改最常见）——而后者不需要训练管线，几周就能出结论。
，而它比"人工标注"便宜得多。
第三项的"读法"要注意"分母"：某类输出"修改率高"可能是"它本身难写"，而不是"模型差"——所以要对比"人工写作的修改率"。
第三项是"验收"："某个字段的修改率"能定位"哪类输出最不受欢迎"——而它比"满意度评分"更细。
"修改率"是个便宜且有用的指标，值得先埋上：
// 三个可算的数（按输出类型分）
1 重生成次数 / 会话数 （抽卡强度）
2 编辑字符数 / 输出字符数 （不满意程度）
3 编辑后再重生成的比例 （改不动 → 放弃）
// 用法：1 高 2 低 → 只是"想换一版"；1 高 2 高 → 输出确实不合用
6. 排错：五种"可编辑性设计问题"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 用户反复重生成 | 只能整体重写 | 加"分段重写" |
| 改了但下次还错 | 无 diff 记录 | 记录 + 打标 |
| 重写后风格不一致 | 缺全局约束 | 带 tone/长度约束 |
| 成本高 | 每次全量重写 | 只带必要上下文 |
| 不敢存 diff | 隐私顾虑 | 脱敏 + 保留期 |
第五项是"常见阻碍"：因为"怕存敏感内容"而完全不做 diff第五项的"折中"是"只存"修改位置 + 长度变化"，不存原文与改后文"：它足够回答"哪段常被改"，而不泄漏内容。
——折中是"只存"修改位置与长度"，不存原文。
最后一个"载体"视角：输出是"结构化字段"还是"一坨文本"，决定了可编辑性的实现成本。
// 两种载体的成本差
结构化（标题/摘要/要点分字段）：可编辑几乎免费（表单）
纯文本（Markdown 一整段）：可编辑要"富文本编辑器 + 分段寻址"
// 建议：生成时就让模型"按字段输出"，而不是"写一整篇"
7. 边界：什么情况"只读"就够
| 场景 | 为什么 | 做法 |
|---|---|---|
| 一次性的探索（找灵感） | 不追求可用 | 只读 |
| 输出不落地（只是看看） | 无"修改"需求 | 只读 |
| 极度敏感（不可留痕） | 不能存 diff | 只读 + 复制 |
| 格式固定（如填表） | 修改由表单承担 | 只读 |
最后一条与"成本"有关的边界：可编辑性把"改进成本"从服务方转移到用户，所以它只在"用户愿意花几分钟"时成立。而"用户很急"的场景，正确做法是"提高一次生成的质量"，而不是"让用户改"。
判断口径一句话："用户拿到输出后，会不会"改一改再用"。会（周报、邮件、文案），就必须可编辑；不会（一次性查询、探索），只读更简单。
8. 自测
- 三种"修正"粒度里，哪一种成本最低？为什么"复制出去改"会让改进回不到系统？
- "重新生成"为什么不携带"哪里不好"的信息？"编辑"为什么自带信息？
- "分段重写"省钱的关键是什么？"不带整篇原文"会带来什么风险？
- "编辑即反馈"的三种用法里，哪一种最有价值？为什么"原文 → 改后"是天然偏好样本？
- "不敢存 diff"的折中是什么？
- 判断"是否需要可编辑"的那个问题是什么？