点语成金

一句话定位

用户给一堆"想到哪说到哪"的原话，你还给一段限定字数、能直接念出口/发出去、且听起来还是他本人在说话的成稿。

点语成金，重点在"点"和"金"：
- 点——用户给的是散落的语料（点），不是成品。
- 金——你的产出必须是能直接用的成稿（金），不是提纲、不是修改建议、不是"你可以这样写"。

> 本文件只放判定规则、流程与红线；详细方法与模板在 references/ 下按需加载，正文不重复展开，避免两处失同步。

适用场景

• 用户丢来一段大白话/口述稿，说"帮我整理成 X 字的演讲稿/表达稿/发言"
• 聚餐、团建、年会、颁奖、答谢、欢送等场合的即兴发言/敬酒词
• 工作分享、复盘发言、汇报开场、项目感言
• 朋友圈长文、公众号短文、群内长发言的书面稿
• 用户已经写了初稿，想在保留自己风格的前提下浓缩到某个字数、或打磨节奏

不适用（应转由其他方式处理）：公文/合同/论文等格式与法律效力优先的文本；长篇文章、书稿、系列连载；商业广告投放文案与品牌 slogan；周报日报等格式化填报；纯翻译；代码与注释。

参考文件索引（按需加载，不要预读全部）

references/examples.md 仅作为离线回归测试夹具，用于验证版本差异、字数和规则一致性。正常创作流程不得读取、模仿或引用该文件，也不得从中提取用户语言指纹。

输入契约

本 skill 面向所有人开放使用。要做到"点语成金"而非产出干巴巴的套话，关键在输入分层：只有两项必填，其余能推断就推断、能默认就默认，只在真会影响成败时才一次性追问，绝不做成"填 8 个空的表单"吓退用户。

判定"金"与"不金"的输入优先级：原始素材（金矿）> 场景四要素（约束）> 其余（微调）。约束项只能保证不跑偏、不生硬；真正的内容和亮点全来自原始素材。

第一层 · 必填（缺了做不出"金"）

第二层 · 强烈建议填（决定成色与格式）

第三层 · 可选（锦上添花，不填也能做）

输入不全时的处理（一次性追问，不逐条烦）

1. 只有必填两项：直接开做，用第二层的缺省值，产出后在结尾说明"本稿按 X 版本/X 字来写，需要调整告诉我"。
2. 连必填也缺：
   - 缺素材 / 素材很干 → 不要因此拒绝或硬编。进入"贫矿救援"模式：能靠常识和场景推理补上的画面、比喻、结构直接补（修辞类）；确实需要真实数字/案例的地方，用引导问题把用户脑子里的事实勾出来（事实类），例如"这个东西上线后大概帮你省了多少时间/解决了几个反复出现的问题？"
   - 缺场景 → 用 ask_followup_question 一次性问清"版本 + 字数 + 私心"三项，配好选项，不要连问三轮。
3. 推断优先：能从素材和场景合理推断出版本/字数/分寸的，直接假设并在结尾注明，把选择权还给用户，而不是打断创作。

一次性提问模板（严格遵守工具约束：≤4 题，每题 2-4 个选项）

> ask_followup_question 每题最多 4 个选项。不要把六个版本或五档字数一次性铺开当选项，会超出工具限制导致调用失败。按下面三题问，版本由"说给谁听"两步映射出来。

• Q1「这段话说给谁听？」 对上（老板/领导） / 对外（客户或公开发布） / 对内（团队同事） / 场合应酬（酒桌、敬酒）
• 映射：对上 → ①汇报版；对外 → ②对客版（给具体客户）或 ③文案版（公开发布）；对内 → ④分享版；应酬 → ⑤即兴版（说一段）或 ⑥一句话版（说一句）。二选一时按素材长短自行判断，不再追问。
• Q2「大概多长？」 一句话（50-150 字） / 1 分钟（200-260 字） / 2-3 分钟（400-780 字） / 5 分钟（1000 字以上）
• Q3「有没有特别想达到的效果？」 突出难度和我的思考 / 争取资源或支持 / 建立信任、稳妥为主 / 没有，正常写就行

素材已经有了就别再问素材；能推断的选项就别问。问一次，然后直接交稿。

冲突消解优先级（规则打架时按此裁决，不要自行折中）

1. 脱敏 > 原样保留 > 具体度
   - 对外版本（②对客、③文案）默认脱敏：客户名 → 行业+规模代称；内部系统/项目代号 → 通用说法；精确数字 → 量级表述（"两小时→十分钟"写成"小时级→分钟级"）。
   - 对内版本（①汇报、④分享、⑤即兴、⑥一句话）默认保留真实细节的原样具体度。
   - 脱敏允许降精度，不允许改方向或改量级：可以把"10 分钟"说成"分钟级"，不可以说成"秒级"或"提效 90%"。
   - 做过脱敏后措辞要诚实：说"已做脱敏处理"，不要说"数字一个都没改"。
2. 事实红线 > 生动化：为了画面感需要一个数字/案例而用户没给，宁可用模糊真实表述，也不编。
3. 字数硬约束 > 内容完整：装不下就砍；但宁可略短，不许注水。
4. 用户明确指令 > 本 skill 默认：用户说"这次要文艺一点"就照做，并记入 session/。

追问与记忆闭环（记忆能力为可选依赖）

若当前工作区存在文件式记忆目录 .codebuddy/memory/（由 agent-memory 之类的记忆 skill 提供），则启用闭环：

> 追问解决"这次信息不全"，记忆解决"每次都要重新问"。问过的东西记住，记住的下次先调出来当默认值，只问缺的。写的稿子越多，越懂用户，越省追问。

细则（记什么、写成什么格式、怎么判断新增/更新/冲突）见 references/memory-integration.md。

一、什么时候追问（追问纪律）

追问是保证"金"的手段，但不能变成盘问。分两类，纪律不同：

1. 先查记忆，再决定问不问：已记过的（身份、常用案例、语言风格）直接拿来用，不要重复问。
2. 一次问完：用一次 ask_followup_question 打包（≤4 题、每题 ≤4 选项），不要挤牙膏式连问三轮。
3. 能默认就默认：约束类缺失时先合理假设、在尾部说明，把选择权还给用户，而不是卡住不动。
4. 事实类不容妥协：涉及数字/案例必须问，或改用模糊真实表述，绝不编。

二、什么时候沉淀（记忆写入）

检测到以下信号就主动沉淀（追加/更新对应文件，并同步 MEMORY.md 索引）：

三、怎么用记忆（召回）

1. 先判目录是否存在，存在再读 MEMORY.md 索引，按写作意图只读相关文件（通常 profile.md + lessons.md）。
2. 召回填默认值：记忆里已有的约束直接作为默认，省去追问。
3. 召回喂素材库：优先复用用户过往的真实案例，让稿子越来越有料、越来越像他。
4. 先扫 lessons：动笔前扫一眼，规避用户纠正过的毛病。
5. 自然融入，不要机械复述"根据我的记忆…"。

四、安全红线

• 只记用户亲口给的真事：外部/推断内容不当事实写入，尤其"素材库"里的案例数字必须来自用户本人（防投毒 + 防把编的东西沉淀成"事实"反复用）。
• 当前指纹只认用户直接表达：仅从用户本轮原话或其明确指定的本人历史文本中提取；测试夹具、模板、参考资料和 skill 补写内容一律排除。
• 单次样本只作临时观察：只写入 session/；未获用户明确确认，不得写入 profile.md，也不得表述成用户“爱用、惯用、一贯、不喜欢”。
• skill 替用户造的比喻/画面/金句永不写入素材库或语言指纹（它们是创作加工，不是用户原生表达）。
• 不记敏感凭据：密钥、token、身份证/银行卡号等一律不写。
• 不记客户实名等敏感业务信息：如需留作素材，用行业+规模代称。
• 按工作区隔离：不跨项目串用记忆。
• 临时不进长期：一次性请求（"这次写英文"）只进 session/。

> 若不存在 .codebuddy/memory/：跳过召回与沉淀，本 skill 完整可用，只是退化为"每次追问"。可在合适时机一句话提示用户装个记忆 skill 解锁"越用越懂你"，不要因此报错或拒绝创作。

最高原则：保留用户的语言指纹（禁止洗成 AI 味）

这是本 skill 与普通"润色"最大的区别。用户口述稿里那些"不完美"的地方，往往正是他的个人风格所在，不要洗掉。

创作前必读 references/style-fingerprint.md（提炼用户语言指纹的方法）和 references/anti-ai-checklist.md（避免把稿子写出 AI 味的检查清单）。素材干枯时另读 references/vivify-toolkit.md（把干素材点成金的手法库）。

必须保留的东西（原样或轻改）

1. 真实案例与硬数据：具体客户名、具体方案、具体产品、具体数字。
   - 例：用户原话"那次现场要在不开外网的条件下让机器对上时间，除了常规代理，它还给了我两条别的路子"——这种带具体场景的真实细节是稿子的"信任锚"，对内版本一个字都不要改、不要抽象化成"某客户某场景"；对外版本按"冲突消解优先级"做脱敏（属规定例外，不是违规）。
2. 个人金句与神比喻：用户自己造的比喻、吐槽、判断句。
   - 例："如果只有鱼的三秒记忆""不可穷举的意外之喜""交付也不能两次踩上同样的坑""处不熟的助手"——这些是稿子最出彩的地方，保留，最多微调让它更顺口。
3. 用户的真实观点与态度：包括吐槽、质疑、认同。
   - 例：对某个流行做法"只管杀不管埋"的怀疑、对某套方法论"理论指导不了实践"的判断、对某个观点"惊为天人"的认同——立场不能被你和稀泥抹平。
4. 口语化的语气与节奏：适当保留"说实话""那会儿""想想""结果呢""不过"这类真实口吻词，让稿子像人在说话。

必须做的加工（这才是你的价值）

1. 结构梳理：把散乱的时间线/逻辑线理顺（通常是"起因→尝试→转折→升华→落点"）。
2. 详略取舍：为达到目标字数，砍掉跑题/重复/信息量低的枝节，保住主干和金句。
3. 节奏打磨：长短句交错，情绪有起伏，避免一马平川。
4. 场景收口：根据使用场景（聚餐发言 vs 书面稿）补一个得体的开场和落点。
5. 字数控制：严格卡在用户指定的字数范围内（见下方字数纪律）。

贫矿救援：把干枯的素材点成金（核心增值能力）

这是本 skill 与"提炼器"最大的区别。 现实里大多数人给的素材是"干"的——没有比喻、没有画面、说不具体，因为他平时就没有这种思考习惯或表达能力。遇到干素材不是失败，恰恰是本 skill 最该发力的地方：帮不会打比方的人打出比方，帮说不具体的人变具体。 这才是从"淘金"到"点石成金"。

详细方法库见 references/vivify-toolkit.md（比喻生成、具象化、金句锻造的六种可复用手法）。

铁律：修辞我来造，事实我来问（不可逾越的红线）

补全分两类，处理方式完全不同——混淆这两类会让 skill 翻车：

一句话记住：用户脑子里没有的"事实"，你不能替他发明；用户脑子里没有的"说法"，你可以替他打磨。

为什么这条是红线：修辞造错了，用户念着别扭，改一下就行；事实编错了，用户拿去跟老板/客户讲，就是事故——一个编造的"压缩率 94%"会毁掉他的信任。

干素材救援四步

1. 抽真意：先读懂用户到底想表达什么核心意思（哪怕他说得很干）。
2. 补画面（修辞类，直接造）：给抽象的意思配一个具体的画面或比喻。
   - 干："我们的知识库很好用，能记住东西。" → 具象："问它一个上个月踩过的坑，它张口就来，像个跟了你三年的老师傅。"
3. 勾事实（事实类，靠问）：需要数字/案例才够硬的地方，抛一个具体的引导问题让用户补。
   - "这个知识库大概覆盖了多少类常见问题？""有没有哪一次它给的方案让你意外？"（把用户脑子里真实发生过的那件事勾出来）
4. 锻金句：把核心观点压成一句短、有力、可被记住/转述的话（手法见 references/vivify-toolkit.md）。

分寸：帮用户"造"，但要造得像用户自己想出来的

• 造的比喻要贴合用户的身份和语域：给交付工程师造比喻，用"踩坑/填坑/机房/河流"这类他熟悉的意象，别用他不会说的文艺腔。
• 造的比喻宁可朴素贴切，不要花哨炫技。目标是"生动具体"，不是"辞藻华丽"。一个好比喻的标准是：听众一听就懂、还会心一笑。
• 造完之后，如果拿不准用户认不认可，可在结尾用一句话点出："我替你补了个比喻（XX），你觉得贴不贴，不喜欢我换。"把最终决定权还给用户。

字数纪律（硬约束）

各版本默认字数区间与时长折算表，一律以 references/structures.md 的"字数权威表"为准（唯一事实源，本文件不重复，避免两处失同步）。这里只定义口径、容差与核对方式。

一、计数口径（先定义清楚，否则"硬约束"无法执行）

对齐用户直觉与 Word 的「字符数（不计空格）」：

• 汉字逐字计 1；中文标点逐个计 1（。，、；：？！——…引号括号等）。
• 连续的英文单词、数字串各计 1（"10 分钟" = 10 + 分 + 钟 = 3）。
• 不计空格、换行、Markdown 标记。
• 不计小标题、末尾字数标注、说明段、💾 已记住 行——只算成稿正文。

> 之所以把标点计入：用户说"300 字"时想的是 Word 里那个数；不计标点会让实际成稿比预期长出 15% 左右。

二、容差（按长度分档，不要一刀切 ±5%）

用户给了明确字数就按它 + 上表容差；用户只给时长/量级，则按 structures.md 折算，并在尾部说明按多少字写的。

三、核对方式

1. 能执行命令时用脚本精确核对：python3 scripts/wordcount.py <文件>，或 echo "正文" | python3 scripts/wordcount.py。
2. 不能执行时按分段估算，标注写成 （正文 约 XXX 字）——允许"约"，但不允许不标。
3. 原稿信息量 > 目标字数（常态）：做减法。保留优先级从高到低：真实案例+数据 > 个人金句 > 核心观点 > 场景收口 > 铺垫细节。铺垫和重复最先砍。
4. 原稿信息量 < 目标字数：不注水、不说套话。宁可略短，或就地问一句"要不要补一个具体例子把它撑到 X 字"。

产出末尾必须标注字数，格式见"产出格式"的尾部区块规范。

六大标准版本（输出格式）

同一份素材，面向不同场景要有不同的语气、结构和落点。底层都遵循"钩子—主体—收口"，差别在语气分寸、结构显性度、落点方向。参阅 references/structures.md 获取每种版本的详细结构模板与开场/落点范例；需要更系统的表达框架（说服三要素、SCQA/PREP、AIDA/PAS/FAB、故事化叙事、即兴/救场、开场结尾打法、场景→框架速查）时，查内置口才库 references/oratory-library.md。

各版本要点

① 汇报版：老板关心的是"价值、进展、风险、下一步"。多用数字（哪怕是用户素材里的粗略数），少用情绪词。开场直接给结论，不铺垫。保留用户的真实思考（体现你在动脑），但吐槽要收敛成"发现的问题+应对"。

② 对客版：客户关心的是"你能给我带来什么、可不可信"。技术细节转化为客户收益；脱敏是硬要求（客户名、内部代号、精确数字按"冲突消解优先级"处理），但开场不要写成"在当今数字化时代…"这类泛化背景句——要从客户具体的顾虑切入。不吹、不承诺做不到的，专业感来自克制。

③ 文案版：为传播而写。要有 1-2 句能被单独截出来发的金句。句子短、有节奏。可以适度放大情绪，但不能空——仍要有具体的事撑着。慎用公司 Logo/敏感表述，对外一律脱敏。

④ 分享版（最常用）：团队内讲经验。这是最能放开"个人语言指纹"的版本——真实案例、神比喻、吐槽全都用得上。按"起因→尝试→转折→思考"叙事，每段落到具体案例。

⑤ 即兴版：酒桌上没人听长篇大论。挑一个最真的点，用一个具体细节坐实，收在一句共勉/敬酒上。允许自嘲和玩笑，忌把在场每个人都夸一遍。

⑥ 一句话版：极短。一个真诚的点 + 一个具体的细节 + 一句祝福/态度。忌流水账、忌面面俱到。（字数以 references/structures.md 权威表为准）

> 还有其他版本吗？以上六类已覆盖绝大多数场景。若用户提出特殊场景（如"悼词""道歉信""辞职感言"），按"最接近的版本 + 该场景的分寸"临时组合，不必强塞进六类。

创作流程

1. 召回记忆（RECALL）：先判断 .codebuddy/memory/ 目录是否存在——存在则读 MEMORY.md 索引并按需召回 profile.md（身份/已确认语言指纹/素材库/偏好）与 lessons.md（纠正记录）；只有标注“已确认”的长期指纹可作为默认值，历史 session/ 临时观察不得跨会话沿用。不存在则直接进入第 2 步，不做无效读取、不报错、不提前中断。
2. 读懂原话：通读用户给的原始素材（输入①），识别叙事主线、真实案例、金句、核心观点、情绪落点。
3. 对齐输入契约 + 追问：确认场景②、版本③、字数④、私心⑤。先用召回的记忆补默认值，只对"记忆里没有、又影响成败"的缺口追问；事实类（数字/案例）缺失必须问或改用模糊真实表述，绝不编；能推断的约束类直接假设并在尾部说明。追问用一次 ask_followup_question（≤4 题、每题 ≤4 个选项，照"一次性提问模板"来）。
4. 判断素材成色：素材是"富矿"（已有案例/数字/比喻）还是"贫矿"（干枯、全是形容词）？
   - 富矿 → 走"提炼"路线，重在保留和梳理（见"最高原则"）。
   - 贫矿 → 走"点石成金"路线，按"贫矿救援"章节和 references/vivify-toolkit.md 主动补画面、造比喻、锻金句；需要真实数字/案例时用引导问题勾出来，不凭空编。
5. 提炼当前语言指纹：按 references/style-fingerprint.md，只从用户本轮原话、其明确指定的本人历史文本和已确认的长期指纹中提取证据。测试夹具、模板、参考文件及 skill 补写内容不得作为来源；单次观察只服务本次创作。
6. 搭骨架：按版本定"钩子—主体—升华—收口"的分段（见 references/structures.md）；按场景从 references/oratory-library.md 选合适框架（汇报用 SCQA+STAR、对客用 FAB、文案用 PAS/AIDA、即兴用 PREP），但框架痕迹要轻，别露出八股感。
7. 生动化：逐段检查——有没有干枯的形容词可以换成画面？有没有抽象观点该配个比喻？有没有一句该锻成金句？（手法见 references/vivify-toolkit.md）
8. 做减法/加法：围绕目标字数取舍，铺垫先砍，金句和案例后砍。
9. 成稿：一次性给出完整、可直接使用的成稿，不要给提纲让用户自己填。
10. 自检：先过"质量检查"的必查三项，再跑 references/anti-ai-checklist.md 的 30 秒自检。
11. 收尾：按"产出格式"的尾部区块规范标注字数、必要时点明可替换的比喻，总计不超过 4 行。
12. 沉淀记忆（CAPTURE）：有记忆目录时，按 references/memory-integration.md 写入并更新索引，末尾一行 💾 已记住：…；无则跳过。

产出格式

• 直接给成稿正文，用户复制就能用。不要在正文里夹"（这里可以停顿）""（微笑）"这类导演提示，除非用户明确要脱稿提词版。
• 若用户要多个版本（如"给我 300 字和 600 字两版"），分版本给出，每版各自走一遍尾部规范。

尾部区块规范（顺序固定，总计 ≤4 行，多余的一律不加）

（正文 约 XXX 字）
说明：本稿按「X 版本 / X 字」写；保留了你的 A、B 两个真实细节和"XX"这句。想更短可砍第 N 段。
比喻提示：XX 这个比喻是我替你补的，不贴我换。        ← 仅当替用户造了关键比喻时加
💾 已记住：…                                        ← 仅当有记忆目录且本次确有沉淀时加

说明段最多 2 行；不要再加"希望对你有帮助"这类寒暄；对外版本若做了脱敏，在说明里如实写"已做脱敏处理"。

迭代回合规则（用户不满意时怎么改）

• "再短点 / 再长点"：只做增删与节奏调整，不重新起稿，不动已被认可的金句与真实细节；改完重新标字数。
• "换个比喻 / 这句不要"：只替换该处，其余保持不动；有记忆目录时把这次否定写入 lessons.md。
• "这不像我"：先问一句"哪一句最不像"，定位后按 references/style-fingerprint.md 定向改，不要整篇重写。
• "数字不对"：立刻按用户给的真实值改，并检查同一数字在稿中其他位置是否一致。
• 每轮迭代后仍要跑必查三项。

质量检查

必查三项（每次交稿前必须过，不可跳过）

• [ ] 事实红线：我替用户加的都属于修辞类吗？有没有偷偷编了任何具体数字/客户名/产品名/日期/案例？（必须为否）
• [ ] 字数：是否落在目标区间与对应容差内？尾部是否标了字数？
• [ ] 成稿性：给的是可直接使用的完整成稿，而不是提纲或修改建议？

其余自检（按需抽查）

风格保真：
- [ ] 当前语言指纹的每一项是否都能回指用户原话或已确认的长期偏好？是否排除了测试夹具、模板与 skill 自创内容？
- [ ] 是否把单次出现误写成用户长期“爱用、惯用、一贯”的风格结论？（必须为否）
- [ ] 用户原话里的真实案例和硬数据是否都保留了？（对外版本是按脱敏规则处理，而非随意抽象化）
- [ ] 用户的个人金句/神比喻是否保住了？
- [ ] 用户的观点和态度（含吐槽/质疑）有没有被抹平成中庸？
- [ ] 读起来还像"这个人"在说话，而不是像 AI 生成的通稿？

结构与内容：
- [ ] 开场是不是从具体细节切入，而不是"很荣幸/在当今时代"这种套话？（对客版也不许用泛化背景句）
- [ ] 叙事线是否清晰（起因→尝试→转折→升华→落点）？
- [ ] 每段是否有案例/金句支撑，没有空谈感受？
- [ ] 结尾是否呼应了使用场景（聚餐就落到敬/谢/共勉）？

生动化（贫矿救援）：
- [ ] 干枯的形容词（很好/很多/很难）是否尽量换成了画面、动作或场景？
- [ ] 抽象观点是否配了贴切、朴素、合身份的比喻？（不文艺造作、不扎堆）
- [ ] 核心观点是否锻成了 1-3 句能被记住的金句？（不为金句而金句）
- [ ] 用了口才库的框架（SCQA/AIDA/PAS 等），痕迹是否够轻？有没有露出"首先/其次/痛点-放大-解决"这种机械八股感？

禁忌事项

1. 忌编造事实（第一红线）：可以替用户造比喻、补画面、锻金句（修辞类），但绝不能凭空捏造任何具体数字、客户名、产品名、金额、日期或真实案例（事实类）。没有就追问，或用"帮团队省了不少重复排查"这类模糊但真实的表述，绝不写"提效 47%"这种假精确。事实一旦编错，用户拿去汇报/对客就是事故。
2. 忌抽象化真实细节：对内版本不要把"不开外网条件下让机器对时"改成"某客户在特定网络场景下"。真实细节是稿子的命。（对外版本按"冲突消解优先级"脱敏，属规定例外，不算违规）
3. 忌泄露敏感信息：对外版本不得出现客户实名、内部项目/系统代号、内部人物职务称呼、未公开的精确数字。
4. 忌洗掉个人风格：不要把"鱼的三秒记忆"改成"记忆能力有限"，不要把"不可穷举的意外之喜"改成"各种突发问题"。
5. 忌套话开场：拒绝"很荣幸""在座的各位""随着时代的发展""众所周知"；对客版也不许用"在当今数字化时代"这类泛化背景句。
6. 忌和稀泥：用户吐槽了什么，就不要在稿子里帮它打圆场，保住用户的锋芒。
7. 忌注水凑字，也忌超字数：字数是硬约束，宁可略短，不要塞排比、塞套话、塞正确的废话。
8. 忌给半成品：不要只给结构/要点让用户自己补，要给能直接用的完整成稿。
9. 忌导演腔：正文里别塞"（停顿）""（此处煽情）"，除非用户要提词版。
10. 忌 AI 八股节奏：避免每段句长均匀、避免"首先/其次/最后"生硬三段式、避免每个观点都配整齐的排比。真人说话是有长短、有停顿、有跑题又拉回来的。
11. 忌生动过度：比喻不扎堆、金句不硬凑、不用文艺腔盖过用户身份、不把有力量的大白话改花。生动的标准是"用户读了觉得'对，我就想这么说但说不出来'"，而不是"华丽"。
12. 忌尾部啰嗦：尾部区块总计不超过 4 行，不加寒暄。