| name | objectivize |
| description | 把带"内心戏/出戏/主观立场"的内部文稿，改写成可对外发布（GitHub、知乎、公开报告、对外白皮书）的客观第三方分析。 Use whenever the user wants writing to read 客观 / 不出戏 / 去内心戏 / 去主观 / 第三方口吻；complains a doc reads like internal team chatter, a private memo, or a meeting post-mortem; references insiders by role (老板/领导/甲方/我方/对方); addresses the reader as "你"; speculates about someone's hidden motives; breaks the fourth wall ("本文档/这份答卷/我们这次"); or says things like 能不能直接发GitHub/知乎、要对外发布、去掉XX的话、客观化一下、depersonalize、make this publishable、 strip the insider voice / make it read like a neutral analyst wrote it. Also use proactively before publishing any internal analysis externally. This is a perception-first rewrite, NOT a find-and-replace word list — invoke it even when the leaks are subtle (loaded framing, in-group jargon, process meta) rather than an obvious banned word. |
objectivize — 把私稿改成公开稿
你不是在跑一张敏感词替换表。每份文稿"出戏"的方式都不一样——先感知这一份特有的主观泄漏形态，再让修法与之同构。形随功能（form follows function）。
下面的类别是火花，不是清单：缺了别硬套，多了就现场命名。把这份说明本身也当水看，别把它读成模板。
一、先感知，后动手（不可跳过）
通读一遍，回答三问：这份文稿写给谁、站在谁的立场、暴露了哪些"只有圈内人才会这么说"的东西？把泄漏点用你自己的话归类。常见的几束光：
- 指名道姓的圈内角色——老板/领导/甲方/我方/对方……对外读者不需要知道这是谁。
- 第二人称喊话——对读者说"你应该/你会/记住"，把读者当队友，是备忘录的味道。
- 把臆测当事实——揣测某人"隐性期待/真实动机/忠诚度"，却写得像已知。
- 打破第四面墙——自指"本文档/这份答卷/我们这次/录音拆解"，暴露生产过程。
- 圈内黑话与阵营情绪——内部缩写、站队口吻、内部梗。
- 过程元话语——交代怎么做出来的（用了什么工具/开了什么会/什么流程）。
产物是一张本文档专属的泄漏地图，不是通用规则。下一份重新画。
二、分清"泄漏" vs "证据"（本技能的心脏）
客观化最容易犯的错，是把证据也抹掉、或把真实数据也改了——那不是客观，是失真甚至造假。判据只有一条：它是被观察到的事实，还是写作者的口吻？事实留，口吻改。
- 直接引语 = 证据，保留（可改成中性归因）。受访者原话"我绝对不碰软件"留着，它支撑论点。
- 第一人称转述 = 泄漏，改写。"别给我天马行空"是替人配音 → "要求方案有据可循"。
- 真实数据神圣不可动——用户评论、日志、统计、截图原文。哪怕数据里正好出现了你要清理的那个词，也绝不改：改它=篡改证据。（真实教训：一条用户差评里写了"老板"，必须原样留下。）
三、改写，不是删除
换框架，别丢内容。"老板的真实意图"→"项目意图"：立场没了，信息还在。看到一句就想删时，先问"它承载的判断/事实是什么"，把那部分用中性语态留下来。
四、定一束镜，一以贯之
先选定一个对外视角（这份报告假装是谁、写给谁看？），据此给每个圈内角色定一个中性称谓，再全篇统一。
- 别在同一份里用三个词指同一个人（项目方/需求方/决策方），读者会以为是三方。顺序是：先定称谓 → 再扫替换 → 最后查一致。
- 章节的"内心戏骨架"也要换骨：把"他讲了什么 / 没讲什么 / 为什么这么讲"这种"复盘某人"式标题，换成"客观分析"式（已明确的决策 / 盲区与未决 / 深层动机与约束）。让结构同构于分析对象，而不是同构于那场会。
五、客观 ≠ 虚假自信
去主观不等于把"置信度/局限/存疑/推断层/需实测验证"也抹平。这些诚实标注恰恰是客观的标志，保留。
六、规模化的纪律（处理一整套文稿时）
- 术语统一可脚本化，但字典每次现建——先感知出本批的称谓集合，再写本批替换；不要复用上个项目的表。
- 机械替换后必查副作用——长词先于短词替换，否则造出"被已被""需求方需求方"这类病句；扫完 grep 一遍残留与畸形。
- 框架、语态、第二人称这类只能人工逐句，脚本碰不了。
- 下游产物要重建——源改了，渲染出的 HTML/PDF/索引/封面也要重生成，别只改源。
自检：把成品想象成被陌生人在公开平台读到
任一条没过，回第一步——但记住：每份文稿的过法都不同，别把这张自检表也变成新的模板。
