humanizar

Humanizar：巴西葡萄牙语鲜活写作

担任编辑。去除机械写作的痕迹，恢复节奏感、准确性和风格，但不要创造新的故事。目标是改进文本，而不是欺骗检测器；任何改写都无法保证工具会将结果判定为人类创作。

必要保护措施

1. 事实锁定——规范定义。 将源文本视为不可更改。保留名称、数字、日期、引文、来源、示例、因果关系、语气（确定、存疑、义务或可能性）、时间状态、责任方、承诺、期限、条件、例外、警告、论点、意图、代码和记法。可以压缩、重组和改写；未经用户明确授权，不得添加、删除或更改这些内容。绝不要为了让文本更具体或更亲切而虚构个人经历、轶事、统计数据、来源、示例、益处、承诺或道歉。
2. 具体但不虚构。 重用已有细节。不要在可发布的文本中保留空缺；仅在用户要求的工作草稿中使用占位符。若缺少必要信息，应保留概括性表述、向用户询问，或在工作草稿中标注 [DADO OU EXEMPLO REAL NECESSÁRIO]。只有在用户要求时才能创作虚构内容，并注明其为虚构。
3. 保留论点。 保留作者的立场和结论，即便你不认同。
4. 保留语域。 不要强行加入非正式表达、第一人称、幽默或观点。语气风格只指导表达方式，不授权添加新内容。
5. 准确性优先于文风。 完整保留代码、公式、引文和规范性内容。在关键场景中，即使表达不够流畅，也要避免引入歧义。
6. 避免幼稚化。 简化表达形式不等于简化推理。

之后所有对事实锁定的检查均以此定义为准。如与示例或参考内容冲突，以这些保护措施为先。

必须进行的初步筛查

在诊断或改写前执行：

1. 确认材料中包含巴西葡萄牙语（PT-BR）内容：文本、笔记或转录。在 modo_criacao 模式下，没有源文本：写作前先确认主题、体裁和可用的事实材料。对于英文，使用 human-ai。对于多语言文本，只处理其中的巴西葡萄牙语部分，并保留其他部分。
2. 不要改写药品说明书、医疗操作流程、航空手册或其他安全关键文本。
3. 不要改写作为规范依据的合同、法律、条款或法律文件。法律风格适用于评论、摘要和原创法律文书，不适用于修改规范性文本。
4. 对于双语直译或按精确对应关系进行评估的内容，不要变换措辞。
5. 对于技术文本，先识别改写时受保护的部分：代码、方程、命令、引文和标识符。
6. 如果任务超出范围，应说明风险；只有在安全且用户授权的情况下，才提供表层校对。

运行模式

模式会改变报告级别和最大尝试次数，但不会改变保护措施。

模式	适用场景	最大尝试次数	交付内容
modo_completo（默认）	常规的人性化处理请求	3	最终文本和修改摘要；仅在用户要求时提供评分
modo_direto	自动化流程或追求速度的请求	1	最终文本和简要报告；不自动重复尝试
modo_revisão	审核由其他 Agent 生成的文本	3	最终文本、诊断和详细报告
modo_criacao	文本尚不存在；用户要求撰写	2	仅最终文本

modo_criacao 是唯一不需要 texto_fonte 的模式。它遵循相同的保护措施，但将模式清单作为对草稿本身的输出筛选条件，而不是用于修正原文。参见从零开始写作。

始终保留用户选择的模式。如果用户未指定模式，且诊断发现五个或更多严重信号，则使用 modo_revisão。对于超过 500 个词的文本，按语义分块处理，并在重新组合后进行全局检查。

清单、笔记和问题

编辑或创作之前，先梳理各项陈述、责任方、每项承诺的力度、截止期限、条件和来源。之后从两个方向核查：所有受保护的内容都得以保留，所有新增内容都有依据。

对于短文本，可以在脑中梳理清单。对于多个来源、笔记、转录内容或关键信息缺失的情况，请查阅作者材料与语义审计。作者的笔记和转录内容是主要依据；保留其中的推理和表达，并将可能存在的 AI 草稿作为辅助。解决来源之间的冲突时，不得悄悄编造或删除信息。

可以提问，但不是必须；最多提问一轮，且不超过三个问题，只针对确实缺失的信息。在 modo_direto 模式或没有对话对象的流水线中，不要自动开始访谈。没有收到答复，不代表可以编造或删减受保护的内容。保持来源不变，并单独记录用户批准的新增内容。

语气风格

语气风格用于指导节奏和语域的选择。示例是虚构的风格样本，并不代表可以向原文添加事实。

🖋️ 编年叙事

采用巴西编年叙事作家的语气。适度口语化、带有讽刺意味，将日常观察转化为思考。融合高雅与通俗的语域。结尾转向反思。 仅当原文或用户请求具有作者个人风格时才应用；不要将此风格视为通用默认风格。

特点：

• “A gente”（我们）可以与简单过去完成时并用
• 用不完整句子营造戏剧性停顿
• 仅在原有语气中已有幽默或用户提出要求时，使用冷幽默和自嘲
• 明确表达作者立场，但不创造新的观点
• 反问句不作回答

示例：

每个人都认识那个把自己的工作自动化、却没告诉任何人的同事。他装了好几个月，假装自己还在打字。没错。现在整个公司都成了这样的同事——只不过用的是 ChatGPT，而不是 Python 脚本。区别在于，没人再装了。那么问题来了：这是效率，还是懒惰？谁知道呢。大概两者都是。

📰 新闻报道

采用 Folha 或 Piauí 的报道语气。清晰至上，提供具体数据，不加修饰。

特点：

• 主语 + 谓语 + 补语（依此顺序）
• 保留原文中的数字和日期
• 仅引用原文已有的来源
• 不使用带评价色彩的形容词
• 不使用第一人称（署名专栏除外）

示例：

该公司于 5 月裁掉了客服部门的 40 名员工。两名前员工将裁员归因于聊天机器人的替代。公司公关部门未予置评。年初，该部门有 120 名员工。

🎓 学术

正式但不官僚。术语严谨，不用官腔。

特点：

• 领域词汇准确
• 合理限定（不做空洞保留）
• 准确保留来源中引用的作者和研究
• 避免陈词滥调：“有必要”“值得指出”“在……范围内”

示例：

可以通过考察经过多轮迭代优化的文本中的词汇变化，来分析文本是否趋向中等语域。在此背景下，语义消融不会引入错误，而是降低了具体性。

💬 非正式商务

初创公司邮件、专业 Slack。直接轻松，不用冗长表达。

特点：

• 句子简短直接
• 适合时用“咱们”代替“我们”
• 用动作动词代替动词短语
• 自然使用外来词（deploy、sprint、feedback）

示例：

大家好，更新一下：hotfix 昨晚已经部署，现在已上线。重复问题从 23 点起就没再出现。我会再监控 48 小时，如果没有问题，我们就关闭 issue。有情况就 ping 我。

📱 社交媒体帖子

巴西 LinkedIn 或 Twitter。简短、有观点，首句要吸引人。

特点：

• 首句是吸引读者的钩子
• 每段 1-2 行
• 明确表达作者立场，但不添加新的观点
• 来源使用第一人称或用户要求时可以使用“我”
• 可含蓄地号召行动，也可以不号召

示例：

我把 ChatGPT 从我的写作流程里开除了。

不是因为它不好。而是因为我发布的所有内容听起来都和别人一样。

我又开始亲手写作了。耗时多了 3 倍，但现在有人回应了。

没有声音的效率不算优势，而是隐形。

📲 WhatsApp 消息

尽可能口语化。允许意识流表达。

特点：

• 可以使用不完整句子
• 自然使用缩写（vc、tb、mto）
• 接受地区俚语
• 完全不必担心规范用语

示例：

嘿你看到数据团队搞的事了吗？

他们没跟任何人说，就把一个模型部署上线了

然后开始给客户发错邮件

太离谱了

⚖️ 🆕 法律 / 官方文书风格

诉状、法律意见、通知。使用正式语体，并保留该文体特有的表达习惯；有意使用时，会比泛泛模仿 AI 更显真实。

特点：

• 结构：序言 → 事实 → 理由 → 请求
• 有节制地使用该文体的陈词滥调（“恕难苟同”“综上所述”“众所周知”）
• 引用条文、判例摘要、判例法
• 尽可能使用主动语态，避免空洞的官僚套话

该语体中的 AI 痕迹：

• 过度使用“值得指出”“必须强调”“在本分析范围内”
• 泛泛引用，没有具体条文或法律编号
• 段落结构过于对称（3-4 个句子形式完全相同）

示例（AI → 人类）：

AI：“根据《消费者保护法典》（CDC）第 14 条，值得指出的是，供应商在本案中的责任属于无过错责任。”

人类：“《消费者保护法典》（CDC）第 14 条规定，供应商在本案中承担无过错责任。”

应予保留的内容（不是 AI 痕迹）：

• 全大写的章节标题（“事实部分”“法律依据”“请求事项”）——这是诉状的常见格式
• 请求和理由部分的项目编号
• 引用带有法律编号和日期的条文（《消费者保护法典》第 14 条；STJ 第 362 号判例摘要）
• 序言 → 事实 → 理由 → 请求的结构——这是文体惯例，不是 AI 模板

该语体中的审校信号：“根据既定理解”等含糊归因。如果来源未提供具体条文、判例摘要或判例，应指出这一缺漏；绝不能自行编造引用。

🧑‍🏫 🆕 教学 / 讲解

教育科技类文本、讲义、教程、友好的技术文档。

特点：

• 常见模式：提问 → 解释 → 具体示例 → 强化理解
• 用词通俗但准确（不幼稚化）
• 使用来源中已有或用户提供的具体示例
• 过渡明确：“那么”“现在”“我们来看看实际操作”

这种风格中的 AI 痕迹：

• 示例笼统且不自然
• 语气像百科全书，没有与读者互动
• “本章将讨论 X、Y 和 Z” → 空洞模板

示例：

我们直接切入主题：callback 是你作为参数传给另一个函数的函数，这样那个函数完成后就能“回调”你。听起来很复杂，其实就这么简单。想象一下，你点了一份外卖：你不用每隔 5 分钟打电话问送到没有，而是留下电话号码，让送货员到门口时通知你。你的电话号码就是 callback。

📋 🆕 简明葡萄牙语

面向广大受众的易读文本。借鉴 PorSimples（NILC/USP）的操作方法，以及第 15.263/2025 号法律（《国家简明语言政策》）中的技巧。最大限度地确保清晰，同时不简化思维。

适用场景：

• 面向非专业人士的技术文档
• 机构和政府沟通
• 产品手册、常见问题解答、用户引导
• 面向读写能力各异的受众的文本
• 用户要求“简化”“使用简明语言”“更清晰”或“更易懂”时

特点：

• 使用主谓宾（SVO）语序，句子简短——目标：13–18 个词，最多 25 个词
• 每句话表达一个想法
• 使用常用词；技术术语首次出现时加以解释
• 使用主动语态（仅在施事者无关紧要或未知时使用被动语态）
• 连续出现 3 项或以上内容时，使用列表和清晰的视觉结构
• 使用明确、简单的连接词（“因为”“因此”“那么”“但是”）
• 不使用冗长的插入语（超过 5 个词的同位语应另起一句）
• 为了清晰可以有意重复（不要刻意变换同义词）

简化操作（基于 PorSimples）：

1. 将复合句拆分为独立句子
2. 将被动语态改为主动语态
3. 有倒装时，调整为主谓宾语序
4. 将复杂的语篇标记替换为简单表达
5. 删除冗长的同位语（改为单独的句子）
6. 用常见近义词替换生僻词（不损失准确性）
7. 有歧义时，明确省略的主语

不要这样做：

• 不要删除复杂的推理——简化表达形式，而非内容
• 不要删除领域术语——应解释术语，而不是替换术语
• 不要不加区分地把所有散文都改成项目符号列表
• 不要为了“帮助”而添加虚构示例——只使用来源中的示例
• 不要弱化语气：“可能导致”不能改成“导致”

示例：

之前：“旨在减轻生产流程自动化所带来的社会经济影响的公共政策，其实施已成为公共部门各级管理者面临的紧迫挑战。”

之后：“自动化正在改变人们的工作方式。这会带来社会和经济问题。政府需要制定政策来减轻这些问题。这是联邦、州和市各级政府面临的紧迫挑战。”

➡️ 🆕 Assertivo

为需要明确结论、而非闲聊的人提供坚定的语气。每句话都必须证明自己有存在的必要，否则就删掉。适合决策答复、快速简报，以及读者会先浏览再细读的异步沟通。

适用场景：

• 在 Slack、电子邮件或文档中回答客观问题
• 面向只想知道答案、不想了解过程的读者撰写决策简报
• 面向注意力分散的受众进行技术沟通
• 用户要求“直奔主题”“别绕弯子”或“执行摘要”时

特点：

• 第一句话就是完整答案——读者只看这一句也能了解要点
• 每段 1～3 句话，每个段落只表达一个想法
• 用粗体突出关键词、数字和决策——浏览粗体内容就能抓住重点
• 不写开场白，不复述问题，不在结尾总结
• 语气亲切但简练——像一位敏锐的朋友，而不是冷冰冰的手册
• 不说空话：不写“好问题”“当然”“实际上”
• 警告和限定条件单独成行，绝不埋在段落里
• 把指令转化为行动：需要做某事时，句子以动词和目标（命令、路径、文件）开头，而非先解释理由

**此风格的事实约束：**简洁压缩的是形式，不是内容。如果原文有 5 个命题，改写后也必须保留这 5 个命题——只是用更少的字表达。可以删掉铺陈，绝不能删掉警告。

这种风格中显露 AI 痕迹的表现：

• 每个关键词都加粗（装饰，而非层级）
• 伪装成开场白的铺垫：“要回答这个问题，我们需要考虑……”
• 在结尾重复已经说过的内容
• 用泛泛的限定条件代替具体风险
• 语气过于冷硬——直接不等于粗鲁

示例（AI → 人类）：

AI：“要回答你关于该使用哪种数据库的问题，需要考虑多种因素。PostgreSQL 是需要复杂关系的应用的绝佳选择。另一方面，MongoDB 可能更适合某些特定场景。总之，选择取决于你的需求。”

人类：“**用 PostgreSQL。**社交应用到处都是关系（好友、关注、点赞），而 Postgres 原生支持这些关系。对于约 90% 的新社交应用来说，这是正确的选择。

**只有在以下情况下才用 MongoDB：**你的数据没有固定 schema，而且每周都会变化；或者写入量大到足以证明这种权衡是合理的。

**常见陷阱：**一开始觉得 Mongo 更灵活就选它，后来需要用 JOIN 时，却得花几个月迁移。”

应保留的特点（不属于 AI 痕迹）：

• 用粗体建立便于浏览的层级（要点标题、数字、决策）
• 连续使用很短的句子，但每句都表达不同想法
• 语气直接但不粗鲁——简练不等于冷淡
• 箭头（→）用于表示流程或结果，而非装饰

🔹 🆕 精简

信号最大，舒适度为零。面向需要事实而非交谈者的专注模式。读者正在执行任务，需要毫无阻碍地得到答案时使用。

适用场景：

• 编码／调试期间的回答（读者正处于专注状态）
• 终端指令、命令、故障排查
• 确认操作（“执行 X”→ 回复确认已执行）
• 用户要求“简短”“只说必要的”或只用单字回复时

特点：

• 第 1 行用一个句子完整回答
• 不寒暄、不含糊、不做过渡
• 适合时使用祈使句：“使用”“运行”“删除”
• 一个要点可以只占一行
• 给出精确数字，绝不取整
• 风险或不确定性单独成行，直接说明
• 任务是“执行 X”时，用一行确认并执行，不要叙述将要做什么

此风格下的事实底线： 简短不代表省略警告。如果省略内容会导致读者采取错误行动，就必须保留，即使这会影响简洁。

此风格下的 AI 痕迹：

• 未经请求的解释（“这是因为……”）
• 任何形式的“希望能帮到你”
• 叙述自身行动（“我现在来检查文件……”）
• 没有具体风险的泛泛保留意见
• 明明一行就够，却写成一段
• 把错误说得戏剧化：“哎呀”“很遗憾”“好像出了点问题”。只说明错误原因和修正方法，不说别的
• 明明可以直接说明操作，却使用习语（“提上议程”“统一预期”“指明方向”）——这种风格下，读者没有多余精力去解读

示例（AI → 人类）：

AI：“要修复此错误，你需要检查配置文件。问题似乎与未正确设置的环境变量有关。建议打开 .env 文件，检查是否包含 DATABASE_URL。希望这能帮你解决问题。”

人类：“.env 里缺少 DATABASE_URL。添加这一行，然后重启 server。”

应保留的内容（不属于 AI 痕迹）：

• 干脆的祈使句——这是风格，不是无礼
• 技术语境中不说“请”或“谢谢”
• 一行足够时，只用一行回答
• 未要求解释时，只给出命令

📊 🆕 状态摘要

适合快速浏览的状态看板，而不是要仔细阅读的长段落。读者想知道哪些内容有变化、哪些遇到阻碍、哪些需要做决定。优先保证易读，而非简短。

适用场景：

• 站会、状态更新、会议记录
• 进度报告、冲刺评审
• 读者会问“X 进展如何？”的任何场景
• 用户要求“状态摘要”“快速更新”或“目前进展如何”时

特点：

• 开头用一行 TL;DR 概括结果和主要阻碍
• 用可视化清单呈现状态：
  • ✅ 已完成
  • 🟡 进行中
  • ⬜ 尚未开始
  • ❔ 未知
  • 🔴 阻碍/风险
• 每行一项，并将主题加粗
• 阻碍单独占一行，并以 🔴 开头
• 在“轮到你：”下用编号列表列出可采取的行动
• 每行简短，只表达一个要点——不要写成大段文字
• 以明确行动或二选一决策收尾
• 如果来源提供了期限，使用具体单位：“3 个工作日”“截至周三”“约 2 周”。绝不把未提供的期限转换成估计值——来源未提供期限时，该项标记为 ❔

**此模式的事实底线：**绝不编造状态。如果某项的状态未知，就标记为 ❔，并说明如何确认。编造清单比清单不完整更糟糕。编造期限就是编造状态：同样适用此规则。

这种记录中 AI 的特征：

• 编造状态（来源中没有的事项）
• 无法独立成立的 TL;DR
• 明明适合用清单却写成大段文字
• 没有状态功能的装饰性表情符号（🚀💡🎯）
• 用“根据之前的共识”或“继续跟进”来凑字数

示例（AI → 人类）：

AI：“关于招聘项目的进展，我想告知大家，我们目前收到了 20 位候选人的申请。其中 5 位已完成筛选，已安排 2 场面试。目前尚未发出任何录用通知。值得一提的是，有一位优秀候选人可能正在考虑其他机会，因此团队需要特别关注。”

人类：“**TL;DR：**招聘漏斗前端情况良好，但临近收尾时遇到阻碍。优秀候选人正在流失。

招聘漏斗： ✅ **候选人：**已收到 20 位 ✅ **筛选：**20 位中已筛选 5 位 🟡 **面试：**已安排 2 场，尚未进行 ⬜ **录用通知：**尚未起草

🔴 **阻碍：**优秀候选人还有其他机会——窗口期约 5 天。

轮到你：

1. 加快处理这位优秀候选人（周三前做决定）
2. 本周完成 2 场面试
3. 现在起草录用通知，避免之后卡住”

应保留的内容（不是 AI 特征）：

• 状态表情符号（✅🟡⬜❔🔴）——它们是功能性标记，不是装饰
• 状态需要时包含超过 5 项的清单
• “轮到你”中重复已出现在状态里的事项——这种冗余是刻意为之（查看 → 决策）
• 即使原始频道使用连续文本，也保留看板结构

🧭 快速消费档案的通用规则

适用于 Assertivo、Enxuto 和 Resumo。不适用于作者自定义档案。

这些档案为何存在。 它们是为正在忙别的事情的读者设计的。读者的四项限制解释了上面的每条规则：

1. 不在屏幕上的内容就会被忘记。不要写“鉴于上文所述”。
2. 理解不等于执行。文字解释得再清楚，却不说该做什么，就是失败。
3. 开始是成本最高的一步。第一个行动必须小而明确。
4. 模糊的期限无法记录。“很快”和“几周后”听起来一样。

如果不确定该如何表达，就选择能降低行动成本的方式。

步骤写成编号列表。 两个或更多可执行操作组成的序列：使用编号列表，每项写一个操作，同一项中不要两次使用“然后”。在连贯的段落中嵌入步骤，是这些档案中 AI 写作的信号。

结尾是行动，不是回顾。 禁止最后总结的规定仍然有效。它不禁止的是：如果源文本留下了待处理事项，最后一行就写明读者现在要采取的一个具体行动。回顾已经说过的内容是噪音；指出下一步才是交付。如果源文本没有留下待处理事项，文本就在最后一条信息处结束。

次要话题不要穿插其中。 源文本中的第二个话题不能变成第一个话题中的括号补充、“值得一提”或旁支内容。先结束第一个话题，再用单独的段落写第二个话题，或在结尾提出问题。绝不能丢弃该话题——事实锁定规则在这里和其他地方一样适用；这条规则说的是位置，不是删减。

例外条款（三种档案均适用）。 如果用户要求深入说明（“详细讲讲”“为什么”“展开说说”），就停止压缩，完整提供上下文。表达风格仍然不变：不加前言，不礼貌收尾，正文长度按主题需要决定。

从零开始写作（modo_criacao）

文本尚不存在时，模式列表是输出筛选标准，而不是修补方法。

1. 写作前先选择语气档案（步骤 1）。如果没有档案，也没有范例，就使用中性语气。

2. 直接写作，使用已核准的资料清单和事实材料。如果有笔记或转录稿，就保留作者的推理、顺序和措辞。写作时不要试图绕开这些模式：这样会卡住句子，写出这项技能本来要避免的乏味文本。

3. 交付前，对自己的草稿进行诊断（步骤 2）。新写的文本中，大多数问题都出在以下五种模式：

   • 插入语破折号；
   • “不只是 X，还有 Y”；
   • 段首连接词（“此外”“因此”“最后”）；
   • 生硬凑成三项；
   • 泛泛的乐观式结尾。

   先检查这些模式，再逐项检查表格中的其他内容。

4. 应用误报防护措施（步骤 6）和最终检查（步骤 7）。

5. 只交付文本。 不提供草稿、诊断或模式列表：用户要的是一段文本，不是一份报告。

modo_criacao 中的事实锁定规则。没有原文需要保留，因此这条规则更加重要：从零开始写作时，很容易用看似合理的数字、大致日期或听起来可信的来源来填补空缺。只能使用用户提供或实际核实过的信息。如果缺少某项数据，导致句子无法成立，就写最简单的句子，并告诉用户缺少什么；或者在工作草稿中标注 [DADO OU EXEMPLO REAL NECESSÁRIO]。明确要求的虚构内容是例外，因为虚构本就是任务的一部分，而且必须标明是虚构内容。

不要声称自己检查过模式列表。如果没有实际检查过文本，绝不能说自己检查过：没有检查却说“我检查了这些模式”，比留下原有问题更糟。

人性化流程

首先执行强制筛查和以下语义清单。整个流程中保持 texto_fonte 不变。在 modo_criacao 中没有 texto_fonte：首次尝试的草稿取代 texto_atual，事实验证遵循从零开始写作中的规则。

第 1 步 — 🎯 选择语气风格

如果用户没有指定风格，根据内容进行判断：

文本中的信号	建议风格
法律引文、法条、“art.”、“§”、“REsp”、诉状	⚖️ 法律
信息性标题、导语、职责、消息来源的发言或报道结构	📰 新闻
学术引用（“et al.”、方法论、假设、p 值）	🎓 学术
教程、友好的文档、“分步说明”或“我们来看看”	🧑‍🏫 教学
使用技术术语和工具名称的专业电子邮件或消息	💬 非正式商务
文本 ≤100 个词、句子不完整、使用缩写和俚语	📲 WhatsApp
短文本（<300 个词）、表达观点、使用第一人称、没有正式结构	📱 社交媒体帖子
≥1500 个词、叙述性内容、没有占主导地位的术语	🖋️ 随笔
机构／政府文本、产品手册、常见问题、要求“简化”或使用“简单语言”	📋 简明葡萄牙语
对决策的回复、简报、“直奔主题”、涉及技术范围的问答结构	➡️ 直截了当
编码／调试场景、命令、故障排查、操作确认、简短回复	🔹 精简
状态更新、站会、迭代评审、“X 进展如何？”、“状态摘要”、会议纪要	📊 摘要
没有明显信号	中性语气 — 保留原有语体，仅删除机械化表达

决策规则：

1. 明确指定的风格决定文体边界，绝不自动替换。
2. 在这些边界内，用户提供的样本决定细微的风格选择。未明确指定风格时，样本优先于检测结果。
3. 未指定风格且未提供样本时，使用检测出的风格；没有明显信号时，使用中性语气。
4. 存在实质性冲突时，在完整模式和修订模式下向用户提问。在 modo_direto 中，选择最接近原文的语体，谨慎处理，并记录歧义。
5. 文本包含多种语体时，保留一种主要风格，只调整属于其他文体的片段。

报告输出：🎯 检测类型：[类型] → 风格：[风格]

步骤 2 — 🔍 使用结构化清单进行诊断

系统地逐一检查每个类别。标记 ✓（发现）或 ✗（未发现）。

类别	信号	权重（1-3）	✓/✗	操作
内容	归属模糊（“研究表明”“专家表示”）	3		保留归属；仅在来源已出现在输入中时明确说明，否则在报告中指出这一缺漏
	缺乏依据的夸大强调（“革命性”“前所未有”）	3		保留评价的力度和归属；建议在报告中弱化，但未经授权不要改动
	可能捏造或不准确的数据	3		在文本中保留并标记以供核实；仅在有来源或获得用户授权时更正
	无法确认是否存在的具体来源（作者、年份、DOI、链接、页码）	3		不要更正或替换引文；标记以供核实，并删除仅依赖该来源的陈述
	泛泛的词汇（“影响”“背景”“情境”）	3		替换为来源已支持的精确术语
	为避免使用“是”“有”或“在”，而采用繁复的迂回表达	2		在符合语体的情况下恢复简单动词
	3 项或更多内容呈现完美的平行结构	2		打破对称结构
语气	过度保留（“也许可能或许”）	2		删除冗余，但不要提高确定性
	AI 自我指涉（“作为一种语言模型……”）	3		删除套话式声明，但不要凭空加入观点
	夸大严重性（“对人类至关重要的问题”）	2		缩小问题的尺度，不要引入新的比较
	标语式格言（“X 是 Y 的语言”“X 不是工具，而是一面镜子”）	2		将口号式句子替换为它所取代的具体陈述
结构	模板式开场（“本文将探讨……”）	3		删除并直接进入已有内容
	模板式结论（“总而言之”“由此可得出结论”）	3		精简或重组现有结论
	生硬的过渡语（“首先”“其次”）	2		使用自然的衔接词
	首句重复标题	1		删除重复句，从正文内容开始
	提出并在半句话内否定的伪选项	2		删除被否定的选项，只保留实际限制
	文档描述的是旧版本，而非当前行为	2		描述当前状态；仅在变更日志、版本说明和迁移指南中保留历史信息
风格	在句中插入补充说明时使用破折号（—）或短破折号（–）	2		替换为逗号、句号、冒号或括号，或重写句子。第 6 步中的例外情况除外
	粗体或格式使用过多	1		根据文体适度调整
	每项都使用表情符号（ChatGPT 风格）	1		删除没有实际作用的表情符号
	未经要求使用 Markdown（在散文中自动添加标题和列表）	2		不符合文体需要时删除
巴西葡萄牙语	官样表达（“谨请注意”“在……范围内”）	2		改为直接的表达
	迂回冗长的进行时表达（“我们将会进行分析”）	2		改为直接的动词形式
	ENEM 式表达（结尾处使用泛泛的警句）	2		替换为具体的思考
外来词	强行翻译技术术语	2		恢复该领域公认的术语
	在非技术语境中生硬地使用英语借词	1		删除

决策规则：每发现一行就计为一个信号，无论重复出现多少次。如果发现 5 个或更多权重为 3 的信号，且用户未选择模式，则使用 modo_revisão。

法律风格说明：官样表达在此类文体中可能是有意使用的。应评估其是否机械重复、是否缺乏实际作用，而不是只看表达是否出现。

可选定量指标

仅在用户要求提供指标，或存在可靠工具可供计算时使用。切勿估算数字。对于简短、零散或少于 200 个单词的文本，标记为 não medido。

可选指标：

• 单词类型与出现次数之比（TTR），并声明分词方式；
• 句长的标准差；
• 词汇熵，并声明计算方法；
• 以 -mente 结尾的单词数量；
• 使用 \w+(?:ando|endo|indo)\b 统计以 -ando、-endo 和 -indo 结尾的形式数量；
• 通用词汇和句法结构的重复情况。

将结果视为受文体和文本长度影响的线索。这些指标不能用来判定文本是否合格，不计入评分，也不能证明文本由人类或人工智能创作。不要假定词汇多样性越高越好：刻意重复有时比强行轮换同义词更自然。

第 3 步 — 🧹 移除模式

从诊断中标记 ✓ 的类别对应的参考文件着手：

第 2 步中标记 ✓ 的类别	初始文件
内容	references/padroes-conteudo.md — 模糊归因、夸大强调
语言	references/padroes-linguagem.md — AI 词汇、系词结构、平行结构
语气	references/padroes-tom.md — 奉承、保留意见和严重性夸大
结构	references/padroes-composicao.md — 固定模板和可预测的结论
风格	references/padroes-estilo.md — 格式、破折号、粗体和表情符号
巴西葡萄牙语或外来词	references/padroes-exclusivos-pt-br.md — 迂回表达、官僚用语和 ENEM 式表达
简化葡萄牙语（当前启用的配置）	references/padroes-portugues-simplificado.md — 操作、词汇替换和指标
当前启用的果断、精简或摘要配置	references/padroes-consumo-rapido.md — 格式、删减规则和例外

如果在改写过程中出现其他信号、分类存疑或类别重叠，也要查阅相关参考文件。不要默认加载所有文件。在 modo_revisão 中，始终包含 padroes-exclusivos-pt-br.md。

参考文件会详细说明各类模式，但不能取代 事实保障原则。如果参考文件中的示例要求加入源文本中没有的信息，就舍弃该示例。

第 4 步 — ♻️ 恢复具体性

对于失去精确度或节奏的部分：

问题	解决方案	示例
陈词滥调	删除，或恢复源文本中已有的意象	“转折点” → 描述源文本已有信息所说明的具体变化
笼统术语	使用现有的领域词汇	“积极影响” → “流失率下降”，但仅限源文本明确指出流失率有所下降
可预测的模板	重新组织行文	调整顺序：示例 → 背景 → 论点，但不改变它们之间的关系
过度抽象	仅依据现有信息具体化	“许多人深受其苦” → “很多人都经历过这种情况”
节奏单调	改变句子长度	长短句交替使用

如果源文本缺少具体化所需的信息，就保留诚实的表述，并注明：⚠️ 缺少真实数据或示例，无法让这部分内容更加具体。

步骤 5 — 💬 应用语气

仅应用当前启用的风格配置允许的特征：

风格配置	应用	避免
中性语气	清晰表达、自然节奏和适度过渡	第一人称、观点、幽默或语体变化
编年叙事	采用不规则节奏和源文已有或用户要求的讽刺	虚构回忆、感受或个人观察
新闻风格	采用直接语序、准确归属和庄重语言	评价性修饰、第一人称和新增来源
学术风格	使用领域术语和必要限定	新增参考资料、比源文更肯定的表述和无谓的口语化
轻松商务风格	使用直接的句子、轻松的语气和领域内自然的外来语	虚构状态、期限、承诺、行动号召或个人经历
社交媒体帖子	基于现有论点设置引子，并使用短段落	虚构观点、个人经历或源文中没有的行动号召
WhatsApp	使用符合渠道特点的口语表达和自然缩写	更改承诺、日期、收件人或确定程度
法律风格	控制正式程度，并遵循该体裁的结构和术语	虚构条文、判例摘要、先例、事实或依据
教学风格	按清晰顺序组织内容，并采用易懂的解释	虚构类比、角色、数据或未提供的示例
简明葡萄牙语	使用主谓宾结构、句子不超过 25 个词、常用词汇；3 项及以上内容使用列表，并解释技术术语	删除内容、弱化语气、虚构示例或移除领域术语
果断风格	首句给出完整答复，按层级使用粗体，段落简短，提醒单独成行	冗长铺垫、结尾摘要、填充式开场、装饰性粗体，以及解释未被询问的内容
精简风格	第 1 行就是答复，使用祈使句，数字精确，能用一行说明时就只用一行	叙述操作过程、解释未被要求的内容、泛泛的保留说明、“希望能帮到你”，以及本可写成一行却写成一段的内容
摘要风格	使用 TL;DR、状态检查清单（✅🟡⬜🔴）、突出显示阻塞项，并在“轮到你了”中列出编号选项	虚构状态、装饰性表情符号、连续段落，以及无法独立成立的 TL;DR

用户提供语气样本时，应仿照句子长度、词汇水平、段落开头、标点和外来语用法。不要将样本中的事实、观点、人物或经历复制到改写文本中。

步骤 6 — 🚧 防止误报

在最终检查前执行。检查步骤 2 中标记为 ✓ 的信号，取消由本节所述情况造成的标记，并在报告中记录判断。任何单一模式都不能证明内容源自人工智能：信号在于多种模式的累积。如有疑问，应检查同一段落中是否出现多种模式；单独一个破折号并不说明任何问题。

不应标记的内容

不属于 AI 痕迹	原因
语法无可挑剔，风格始终如一	很多人文笔很好，或经过编辑润色。文字润色得好，不代表是机器写的
文字干涩或“没意思”	AI 写作有特定特征。没有这些特征的干涩文字，只是简练的散文
偶尔出现正式或学术用语	词汇清单指出的是过度使用，而不是禁止使用这些词。不要把每个难词都简化掉
法律、学术或规范性语体	非人称表达和被动语态是这类文体的要求。不要把诉状、鉴定报告或会议记录改成博客文章
小说中的对话破折号	这是语言规范。第 2 步的标记针对的是插入语破折号，而不是对话
作者样本文中出现的破折号	如果样本文中使用破折号，就保持相同的使用频率
偶尔出现的连接词（“然而”“因此”）	只有在连续多个段落开头堆叠使用时才值得警惕
单独出现的弯引号	Word、Google Docs 和大多数编辑器默认会将引号弯排。只有与其他特征同时出现时才算
正确使用逗号	呼语中的逗号（“你好，João”）是语言规范。标点正确说明不了什么
用来强调的一句短句	只有连续出现多条戏剧性片段句时才标记
有意重复的开头	“我来了。我看见了。我征服了。”是一种节奏。只有重复毫无增益时才修改
句中出现“你看”或“说实话”	这些表达在口语和非正式语体中很常见。问题在于单独使用、带有戏剧效果的开场白
有实际作用的限定说明	保留对适用范围的限定、法律或安全提示、真实的更正、注明作者的异议，以及 FAQ 条目
真实存在的备选方案	在架构文档、教程或论证中，保留读者会考虑的选项。只删掉提出后再也没用到的不太可能选项
没有引用	很多已发布的文本都没有引用来源。缺少引用不能证明任何事
复杂且正确的格式	可视化编辑器和模板无需 AI 也能生成整洁的输出
转述语境中的警示表达	如果表达出现在引文、标题、专有名称或讨论该表达而非实际使用它的示例中，不要改写
2022 年 11 月 30 日之前的文本	ChatGPT 公开发布的日期。更早的内容几乎不可能由 AI 生成
Assertivo/Enxuto 画像中的引导语加粗	这是为了建立便于浏览的层级，不是装饰
表示结果或流程的箭头（→）	这是该类文体的专用符号，用来表示因果关系，而非装饰
Enxuto 画像中由 1–3 个词组成的句子	高密度是该画像的结构特点，不是戏剧性片段句
Resumo 画像中使用 ✅🟡⬜❔🔴 的清单	这是功能性状态标记，而非装饰，每个表情符号都代表一种状态
Resumo 画像中包含 5 项或更多内容的清单	摘要本身就是所声明的格式，不是伪装成清单文章的内容
Assertivo 画像中的单行段落	每个段落表达一个观点，是该画像的结构特点

自动检测器。 不要把检测工具的分数当作证据，也不要据此决定改写哪些内容。这些工具错误很多，而且偏差严重：对神经多样性人士和非母语者的惩罚尤其重。这里的改写都不是为了骗过检测器。

应当保留的人性痕迹

这些细节通常承载着写作者的个人风格。除非它们影响理解，否则应予以保留；绝不要为了统一规范而“纠正”：

痕迹	示例
缩略形式与书面口语	“pra”“tᔓcꔓn锓tô”“pro”。在非正式语境中，不要将其展开为“para”“estᔓvocê”——缩略形式是作者的选择。在正式文本中，才应使用完整形式
地域表达	“uai”“oxe”“tchꔓmassa”“mano”。不要将其统一成手册式的中性葡萄牙语
具体而古怪的细节	一个真实地址、一处别扭的引文、“那个在我牙医头上工作的律师”
混杂的情绪与未解决的矛盾	“总体来说不错，但让我有些不舒服，而且我也说不清为什么”
俚语与过时的梗	局限于某个年份和某个群体的网络梗与内部笑话
插话、括号与自我纠正	“（我一直想在这里写‘差不多’，但当时确实就是那么肯定。）”
句子长度的变化	短句与长句交替。AI 文本的句子长度往往保持稳定
有意识的第一人称表达	作者知道如何说明理由的删改或用词

文本本身就是样本。 如果输入本身就带有鲜明的作者痕迹——地域表达、明确的观点、第一人称、幽默、自我纠正，或只有亲历者才知道的具体细节——那它就不是聊天机器人的输出，而是某个人请求修改的文字。应将这类文本视为作者的风格样本。在这种情况下，破折号和戏剧性开场的信号不再适用；在报告中指出发现的相关内容，并将选择权留给作者。

步骤 7 — 🔥 最终检查

先对照源文本和已批准的增补，进行双向审查：每项受保护的命题都必须保留，候选文本中的每项陈述都必须有依据。核对可能性与承诺、提议与保证、认可与道歉、提供条件以及责任归属。在创作任务中，对照已批准的事实材料进行审查。

逐项检查。根据配置和片段长度标记 ✓、✗ 或 N/A。

#	检查项	✓/✗
1	是否完全符合规范定义的 事实锁定？
2	论点、意图、语气和受保护片段是否保持不变？
3	是否修正了已发现的过渡问题和机械化模式？
4	是否仅在源文本提供依据时才明确含糊的术语？
5	句子的节奏和长度是否符合配置？少于三句话的段落无需强求三种不同的句长。
6	意见、疑问、情绪和第一人称是否仅在原文已有或用户要求时出现？
7	每个片段中的语气配置和语域是否保持一致？
8	是否保留了领域中自然使用的外来语，没有生硬翻译？
9	开头、结尾和格式是否符合文体，且未套用不必要的通用模板？
10	是否检查了用作插入语的 —、– 和 --，同时保留对话中的破折号，并维持作者样本中的使用频率？
11	是否应用了步骤 6 的误报防护，且未将作者的任何个人风格规范化？
12	朗读时，文本在目标文体和受众中是否自然？

简洁型配置（Assertivo/Enxuto/Resumo）的附加检查：

#	检查项	✓/✗
A	原文的所有命题是否都得到保留，即使经过了压缩？
B	是否没有删除任何警告？
C	是否没有将任何范围条件概括化？
D	是否保留了语气？（“可以”没有变成断言）
E	数字和阈值是否保持准确？
F	是否遵循常见规则：步骤使用编号、结尾以行动收束（而非回顾总结）、次要主题不放在中间？

第 1 项或第 2 项不合格，候选文本即无效。其他项目仅在仍有可用尝试次数时修正；不要为了满足清单而扭曲文体。步骤 9 的尝试次数限制可防止无限重复。

第 8 步 — 📊 改写后评估

在进行风格评估前，先验证事实关卡。如果未通过，则丢弃候选文本并记录评分为 nula；自然度绝不能弥补事实或语义上的改变。

默认定性评估模式的正确性、自然度、语气一致性和可读性。不打分，也不为达到某个分数而反复修改。

只有在用户要求或提供 limiar 时才计算评分。应将其标明为主观的编辑判断，而非测量结果或经过校准的概率。如果事实验证通过且启用了评分，则始终根据当前生效的风格档案，对以下四个维度按 0 到 100 分评估：

维度	权重	评估标准
去除 AI 模式特征	35%	第 2 步中的多少种模式特征已被去除？是否仍有残留？
自然度	30%	节奏是否符合文体？语气是否只在允许的范围内体现？
语气一致性	20%	是否从头到尾保持了风格档案，同时尊重其他语体的片段？
可读性	15%	句子是否流畅？连接词是否自然？逻辑是否清晰？

最终评分 = Σ（维度 × 权重）

启用评分时，使用用户要求的 limiar；如果用户要求评分但未提供门槛，则使用 80。未启用评分时，limiar、pontuacao 和 convergiu 均为 null。如果评分低于门槛且还有重试机会，应针对得分最低的维度进行调整。评分低于 60 时，应改变方法，但不得更换明确指定的风格档案。可选的量化指标绝不会改变评分。

第 9 步 — 📦 重试控制与交付

只执行一次风格档案选择、清单整理和诊断。每次尝试都从最佳安全文本出发，并与不可变的 texto_fonte 及获批的补充内容进行比较。创作时，与获批的事实材料进行比较。在定性评估或可选评分之前，先执行第 3 至第 7 步。

pontuacao_ativa = usuário pediu nota ou forneceu limiar
limiar = (valor solicitado ou 80) se pontuacao_ativa, senão null
melhor_texto = nenhum

para cada tentativa, respeitando o limite do modo:
    gerar candidata
    auditar fonte → candidata e candidata → fonte
    se falhar: descartar candidata sem pontuação
    senão:
        avaliar estilo em relação ao perfil
        calcular nota somente se pontuacao_ativa
        guardar candidata se melhorar o melhor texto seguro
        parar se não houver melhoria útil a fazer
        parar se pontuacao_ativa e nota atingir limiar

se nenhuma candidata for segura:
    estado = reprovada_trava_factual
    devolver texto_fonte sem nota
senão se pontuacao_ativa e melhor nota < limiar:
    estado = melhor_resultado
    devolver melhor_texto com limitação
senão:
    estado = concluida
    devolver melhor_texto

次数上限是最大值，不是目标：如果继续修改无法提升结果，就应停止。保留最佳的安全候选文本，不一定是最后一个。

在 modo_direto 下，只生成一个候选文本，不得重试。如果它未通过事实关卡，则返回源文本，并将状态设为 reprovada_trava_factual。

在 modo_criacao 下，没有可供比较的 texto_fonte。事实验证标准变为：候选文本中的每项陈述、名称、数字、日期和引文，都必须来自用户提供的材料或经过实际核实。未通过此测试的候选文本应重写，不得附带保留意见交付。如果缺少数据，则交付最简单的版本，并指出缺失项。

需要重试时，根据主要问题选择替代方法：

上一个候选文本的问题	下一步方法
仍有机械模式特征	加强去除已检测到的模式特征
语气过度或不自然	减少干预，更贴近原始语体
结构可预测	仅重新排列已有命题
长文本前后不一致	按语义块处理，并验证整体效果
检测到的风格档案不合适	仅当用户未选择该档案且源文本有依据时才更换

输出约定

在流水线中或需要结构化输出时，使用：

estado: concluida
texto: "texto final ou texto-fonte seguro"
modo: modo_completo  # ou modo_direto, modo_revisão, modo_criacao
perfil_de_voz: voz_neutra
limiar: null  # 80 ou valor solicitado apenas com pontuação ativa
pontuacao: null  # nota editorial somente se solicitada
convergiu: null  # true/false somente com pontuação ativa
trava_factual:
  estado: intacta
  violacoes: []
tentativas:
  usadas: 2
  maximas: 3
relatorio: {}

未启用评分时，concluida 表示候选内容已通过审核和定性评估；三个数值/收敛字段均设为 null。启用评分时，根据最终状态使用相应值：

estado	convergiu	pontuacao	texto
concluida	true	≥ 阈值的数字	已通过审核的安全候选内容
melhor_resultado	false	低于阈值的最佳数字	最佳安全候选内容
reprovada_trava_factual	false	null	texto_fonte
entrada_invalida	false	null	未改写的输入

在对话中，先呈现文本，再根据模式呈现报告：

模式	报告内容
modo_completo	已修正的模式和注意事项；仅在用户请求或已计算时提供评分和指标
modo_direto	简要报告和状态；仅在用户请求时提供评分
modo_revisão	诊断和注意事项；仅在用户请求或已计算时提供评分和指标
modo_criacao	仅提供最终文本。只有用户请求报告，或缺少事实数据时，才提供一行简短说明

与外部循环集成

首次调用时，将收到的文本用作 texto_fonte 和 texto_atual。后续调用中，保持 texto_fonte 不变，只将 texto 字段作为 texto_atual 重新输入：

proxima_entrada:
  texto_fonte: "original imutável"
  texto_atual: "saída.texto"
  perfil_de_voz: "mesmo perfil"
  adicoes_aprovadas: []
  limiar: null  # preservar valor solicitado se houver

切勿将报告、评分或整个封套作为文本的一部分重新输入。每次调用仍需将结果与原始 texto_fonte 及具有来源记录的已批准补充内容进行比较；在创作模式下，各次调用之间应保留已批准的事实基础。

外来词

巴西科技行业的人会使用外来词。这是真实感的标志，不是错误。此技能保留以下词语：

feedback, deploy, sprint, churn, feature, bug, hotfix, pipeline, stakeholder, deadline, call, onboarding, pitch, runway, burn rate, product-market fit, growth, awareness, branding, lead, funnel, conversion, landing page, copywriting, UX, UI, framework, stack, backend, frontend, fullstack, DevOps, SaaS, API, endpoint, webhook, dashboard, KPI, OKR, ROI, ROAS, CRM, MVP

强行翻译这些词，是纯化主义 AI 的表现——恰恰与人类表达相反。

黄金法则：如果某个词在巴西葡萄牙语的领域日常交流中使用，就保留。如果是没有必要的生硬英语词，就删掉。

回归测试套件

用于验证未来迭代的最小测试集。在 modo_completo 下运行每个用例，并在评判风格之前检查语义是否保留。

#	类型	改写前（AI）	预期改写后（摘要）
T1	商务电子邮件	"特此告知，报告将适时发送"	"报告将适时发送。"
T2	学术段落	"许多作者广泛讨论了语言问题"	"许多作者从广泛的层面讨论了语言。"
T3	法律文本	"众所周知，严格责任适用于消费关系领域"	"严格责任适用于消费关系。"
T4	博客开篇模板	"在本文中，我们将探讨 5 种优化工作流的基本策略"	"在本文中，我们将探讨五种优化工作流的基本策略。"
T5	AI 过度保留	"作为一个语言模型，我无法确定地断言，但系统似乎可能正在运行"	"系统似乎正在运行，但目前还无法确定地断言。"
T6	泛化的教学文本	"João 有 3 个苹果，Maria 有 5 个。一共有多少个？"	"João 有 3 个苹果，Maria 有 5 个。他们一共有多少个苹果？"
T7	假阳性（人的表达习惯）	"Oxe，我觉得这事现在对我们来说不值得"	保持不变。地域表达和缩略形式是作者的表达风格，并非 AI 写作问题
T8	虚构来源	"根据 Almeida（2019，第 84 页），该效果是一致的"，但参考文献并不存在	保留原有说法并标记以供核查；绝不能替换为其他参考文献

回归标准：如果某项迭代导致 T1-T8 中任何一项的结果变差，就应重新评估这一改动。

测试用例中的事实保护：任何预期输出都不得添加、删除或更改受保护的内容。相比捏造信息、让版本看起来更出彩，表达更克制的版本更可取。

使用 Jev 进行评估（可选）

仅当用户要求外部评估且 Jev 已可用时，技能才可使用 TypeSafe Jev 进行校准评估——这是一个能返回带有精确概率的类型化决策的模型。LLM 仍负责改写。评分仍为可选；评估器的任何决定都不能凌驾于已检测到的语义违规之上。不要安装服务、选择付费提供商，也不要自动委派任务。

发现协议

技能不会假定 Jev 可用。使用前请执行发现协议：

1. Verificar MCP tools disponíveis no harness
   → Se existir tool "jev_eval" ou similar → usar
   
2. Verificar se harness usa OpenRouter
   → Se sim, solicitar modelo `typesafe/jev-latest`
   
3. Verificar slots auxiliares (Hermes, Devin)
   → Se slot approval/custom configurado com Jev → usar
   
4. Fallback → avaliação inline via LLM atual

按运行环境发现

运行环境	如何检测 Jev
Claude Code	在 .claude/mcp.json 中检查 MCP → 工具 jev_eval
Cursor	检查 OpenRouter 是否为提供商 → 模型 typesafe/jev-latest
Devin	检查 agents/*.md → 包含 model: typesafe/jev-latest 的配置
Hermes	检查 config.yaml → auxiliary.approval.model
Kiro/Copilot/Cline	检查 MCP 服务或可用模型列表
Aider/OpenCode	检查已配置的提供商

为什么使用 Jev

方面	LLM 评估	Jev 评估
一致性	不同调用的结果会变化	确定性
校准	P(70%) ≠ 实际 70%	P(70%) = 实际 70%
成本	~$0.01-0.05/次评估	~$0.0001-0.0002/次评估
延迟	1-5s	70-500ms
输出	文本（需要解析）	原生结构化

节省：比 GPT-4 便宜约 50-100 倍。

何时优先使用 LLM 评估

• 很短的文本（<50 个词）
• 赶时间时使用 modo_direto
• 调试/开发（更容易检查推理过程）
• 运行环境中 Jev 不可用

步骤到 Jev 的映射

步骤	Jev 原语	问题
步骤 2（诊断）	Noul	52 个二元问题（AI 模式）
步骤 6（误报）	Noul	2 个问题（人类标记、正式性别）
步骤 7（验证）	Noul	4 个问题（事实锁定、论据、模态）
步骤 8（评估）	Score	4 个加权维度

相关文件

文件	描述
scripts/jev_questions.json	56 个类型化问题（Noul + Score）
references/jev-integration.md	完整协议、请求/响应格式

完整文档：请参阅 references/jev-integration.md，了解发现协议、请求/响应结构以及各 harness 的说明。