📦 Response Tone Polisher — 学术语气润色
v1.0.0将同行评审回复中防御性或生硬的语言转换为礼貌、专业的学术表达,同时保持作者的科学立场和学术完整性。适用于学术写作场景,帮助研究者维护与审稿人的积极关系。
运行时依赖
版本
- Response Tone Polisher 技能首次发布。- 分析并将作者对审稿人的防御性或生硬回复转换为礼貌、专业的学术语言。- 在改善语气和清晰度的同时保持作者的科学立场。- 检测直接拒绝、防御性/指责性陈述和情绪化语言,并用外交辞令的学术表达替换。- 支持可配置的润色级别和回复类型;输出结构化结果,包括语气评分和具体改进。- 提供示例用法、审计就绪命令和回退/错误处理程序。
安装命令
点击复制技能文档
通过软化生硬或防御性语言来润色给审稿人的回复信,同时保持作者的立场和科学完整性。
何时使用
- 当任务需要通过转换防御性或生硬语言来润色回复信时使用此技能。
- 当学术写作任务需要明确假设、有界范围和可重现的输出格式时使用此技能。
- 当需要为缺失输入、执行错误或部分证据提供文档化的回退路径时使用此技能。
核心功能
- 语气分析:识别防御性、对抗性或过于直接的表达
- 礼貌转换:将生硬陈述转换为礼貌的学术散文
- 立场保持:在改善表达方式的同时保持作者的科学立场
- 上下文感知:根据回复类型(接受、部分接受、礼貌拒绝)进行适配
- 学术表达库:内置的润色学术短语集合
依赖项
有关详细信息请参阅上面的 ## Prerequisites。
Python:3.10+。当前打包技能的仓库基线。dataclasses:unspecified。在requirements.txt中声明。enum:unspecified。在requirements.txt中声明。
示例用法
cd "20260318/scientific-skills/Academic Writing/response-tone-polisher"
python -m py_compile scripts/main.py
python scripts/main.py --help
示例运行计划:
- 确认用户输入、输出路径和任何所需的配置值。
- 如果脚本使用固定设置,请编辑文件内的
CONFIG块或文档化的参数。 - 使用验证后的输入运行
python scripts/main.py。 - 查看生成的输出并返回最终产物,同时标注任何假设。
实现细节
有关详细信息请参阅上面的 ## Overview。
- 执行模型:验证请求,选择打包的工作流程,并产生有界的交付物。
- 输入控制:运行任何脚本前,确认源文件、范围限制、输出格式和验收标准。
- 主要实现表面:
scripts/main.py。 - 参考指南:
references/包含支持的规则、提示或检查清单。 - 首先需要澄清的参数:输入路径、输出路径、范围过滤器、阈值和任何领域特定约束。
- 输出规范:保持结果可重现,明确标注假设,避免未记录的副作用。
快速检查
使用此命令验证打包的脚本入口点可以在深度执行前被解析。
python -m py_compile scripts/main.py
审计就绪命令
使用这些具体命令进行验证。它们故意自包含,避免占位符路径。
python -m py_compile scripts/main.py
python scripts/main.py --help
概述
此技能分析作者对审稿人评论的草稿回复,并将对抗性或防御性措辞转换为专业、Diplomatic的学术语言。它帮助研究者在坚持科学合理立场的同时,与审稿人保持积极的关系。
用法示例
基本用法
输入:审稿人:样本量太小,无法得出有意义的结论。
草稿回复:我不同意。我们的样本量在该领域是标准的。
输出:我们感谢审稿人对样本量的关注。虽然我们承认更大的样本量可以提供更强的统计效力,但我们的样本量与该领域既定惯例一致,并且满足充分功效分析的要求(如方法部分详述)。
防御性语言转换
| 原文(防御性) | 润色后(专业) |
|---|---|
| "我不会改变这个。" | "我们认真考虑了这个建议,并出于以下原因尊重地保持我们原始的方法..." |
| "审稿人错了。" | "我们尊重地提供另一种解释..." |
| "这是不必要的。" | "我们感谢这个建议;然而,我们认为当前的表述已充分解决了这一点。" |
| "我们已经解释过这个了。" | "我们扩展了我们的解释以提高清晰度(第 X 页,第 Y-Z 行)。" |
| "这不是我们的错。" | "我们承认这一局限性,并在讨论中增加了适当的说明。" |
输入参数
| 参数 | 类型 | 必填 | 描述 |
|---|---|---|---|
reviewer_comment | str | 是 | 审稿人的原始评论或批评 |
draft_response | str | 是 | 作者的初始草稿回复(可能包含生硬/防御性语言) |
response_type | str | 否 | 之一:accept、partial、decline(默认:自动检测) |
polish_level | str | 否 | light、moderate、heavy(默认:moderate) |
preserve_meaning | bool | 否 | 确保科学立场被保留(默认:true) |
输出格式
{
"polished_response": "string",
"original_tone_score": "float (0-1, 越高越防御性)",
"improvements": [
{
"original_phrase": "string",
"polished_phrase": "string",
"issue_type": "string"
}
],
"suggestions": ["string"],
"politeness_score": "float (0-1)"
}
检测到的语气模式
技能识别并转换以下内容:
1. 直接拒绝
- "No" / "We won't" → "We respectfully decline to..."
- "We can't" → "We are unable to..."
2. 防御性陈述
- "But we already..." → "We have now clarified..."
- "This is not correct" → "We respectfully note that..."
3. 推卸责任
- "The reviewer misunderstood" → "We apologize for the lack of clarity; we have revised..."
- "This is standard" → "This approach aligns with established conventions..."
4. 情绪化语言
- "Unfortunately"(过度使用)→ [删除或软化]
- "Obviously" → [删除]
- "Clearly" → [删除或视上下文而定]
礼貌学术表达
感谢审稿人
- "We thank the reviewer for this insightful observation."
- "We appreciate the reviewer's careful attention to this detail."
- "We are grateful for this constructive feedback."
- "This is an excellent point."
礼貌表达不同意
- "We respectfully offer an alternative interpretation..."
- "Upon careful reconsideration, we believe..."
- "While we appreciate this perspective, we note that..."
- "We respectfully maintain our position that..."
解释局限性
- "We acknowledge this limitation and have addressed it by..."
- "This constraint reflects the trade-off between..."
- "We have added appropriate caveats regarding this limitation."
描述更改
- "We have revised the manuscript to clarify..."
- "We have expanded the relevant section to include..."
- "We have incorporated this suggestion by..."
工作流程
- 在进行详细工作之前,确认用户目标、所需输入和不可协商的约束。
- 验证请求与文档化的范围匹配,如果任务需要不支持的假设,则提前停止。
- 使用打包的脚本路径或文档化的推理路径,仅使用实际可用的输入。
- 返回结构化的结果,将假设、交付物、风险和未解决的项目分开。
- 如果执行失败或输入不完整,切换到回退路径并准确说明什么阻止了完全完成。
命令行用法
# 交互模式
python scripts/main.py --interactive# 基于文件
python scripts/main.py \
--reviewer-comment "comment.txt" \
--draft-response "draft.txt" \
--output "polished.txt"
# 直接输入
python scripts/main.py \
--reviewer "The data is insufficient." \
--draft "You are wrong. We have enough data." \
--polish-level heavy
Python API
from scripts.main import TonePolisherpolisher = TonePolisher()
result = polisher.polish(
reviewer_comment="The methodology is flawed.",
draft_response="No it's not. We did it right.",
response_type="decline",
polish_level="moderate"
)
print(result["polished_response"])
参考资料
references/polite_expressions.json- 精选的学术礼貌表达库references/tone_patterns.md- 常见防御性模式及其转换references/examples/- 润色前后的示例
局限性
- 不验证回复的科学准确性
- 复杂的细微分歧需要人工审核
- 可能会过度软化;作者应验证立场是否仍然清晰
- 最佳适用于英语回复
质量检查清单
润色后,验证:
- [ ] 原始科学立场已保留
- [ ] 没有剩余对抗性语言
- [ ] 全程保持专业语气
- [ ] 明确感谢审稿人的努力
- [ ] 仍然引用具体更改
- [ ] 回复直接针对评论
风险评估
| 风险指标 | 评估 | 等级 |
|---|---|---|
| 代码执行 | 本地执行 Python/R 脚本 | 中 |
| 网络访问 | 无外部 API 调用 | 低 |
| 文件系统访问 | 读取输入文件,写入输出文件 | 中 |
| 指令篡改 | 标准提示指南 | 低 |
| 数据暴露 | 输出文件保存到工作区 | 低 |
安全检查清单
- [ ] 无硬编码凭据或 API 密钥
- [ ] 无未授权的文件系统访问(../)
- [ ] 输出不暴露敏感信息
- [ ] 提示注入保护到位
- [ ] 输入文件路径验证(无 ../ 遍历)
- [ ] 输出目录限制在工作区
- [ ] 沙箱环境中执行脚本
- [ ] 错误消息已清理(不暴露堆栈跟踪)
- [ ] 依赖项已审计
前置条件
# Python 依赖项
pip install -r requirements.txt
评估标准
成功指标
- [ ] 成功执行主要功能
- [ ] 输出符合质量标准
- [ ] 优雅处理边缘情况
- [ ] 性能可接受
测试用例
- 基本功能:标准输入 → 预期输出
- 边缘情况:无效输入 → 优雅的错误处理
- 性能:大数据集 → 可接受的处理时间
生命周期状态
- 当前阶段:草稿
- 下次审查日期:2026-03-06
- 已知问题:无
- 计划改进:
输出要求
当以下项目相关时,每个最终响应都应明确说明:
- 目标或请求的交付物
- 使用的输入和引入的假设
- 工作流程或决策路径
- 核心结果、建议或产物
- 约束、风险、注意事项或验证需求
- 未解决的项目和下一步检查
错误处理
- 如果缺少必需输入,准确说明哪些字段缺失,只需最少的附加信息。
- 如果任务超出文档化范围,停止而不是猜测或静默扩大任务范围。
- 如果
scripts/main.py失败,报告失败点,总结仍可安全完成的内容,并提供手动回退。 - 不要伪造文件、引用、数据、搜索结果或执行结果。
输入验证
此技能接受与 response-tone-polisher 文档化目的匹配且包含足够上下文以安全完成工作流程的请求。当请求超出范围、缺少关键输入或需要不支持的假设时,不要继续工作流程。而是回复:
response-tone-polisher 只处理其文档化的工作流程。请提供缺失的必需输入或切换到更合适的技能。响应模板
对于非平凡请求使用以下固定结构:
- 目标
- 收到的输入
- 假设
- 工作流程
- 交付物
- 风险和限制
- 下一步检查
如果请求简单,您可以压缩结构,但仍然在影响正确性时保持假设和限制明确。