Menu
当收到同行评审反馈时使用，在实施建议之前，特别是当反馈看起来不清楚或在学术上值得商榷时——需要学术严谨和验证，而不是表演性的同意或盲目实施
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
当面临 2+ 个独立任务，可以在没有共享状态或顺序依赖的情况下工作时使用
当在当前会话中执行具有独立任务的撰写计划时使用
当你有一个书面的撰写实施计划，需要在一个单独的会话中执行，并带有审查检查点时使用
当撰写完成，所有逻辑检查通过，你需要决定如何整合工作时使用——通过展示清晰的合并、提交审阅或清理选项来指导完成开发工作
在进行任何创造性工作之前必须使用此技能——无论是撰写新章节、构建理论框架、增加论据还是修改论证逻辑。在撰写正文之前，先探索研究目标、要求和论证设计。
当开始撰写需要与当前工作区隔离的新章节，或在执行撰写计划之前使用——通过智能目录选择和安全验证创建隔离的草稿分支
| name | sa-feedback |
| description | 当收到同行评审反馈时使用，在实施建议之前，特别是当反馈看起来不清楚或在学术上值得商榷时——需要学术严谨和验证，而不是表演性的同意或盲目实施 |
同行评审需要学术评估，而不是情绪表演。
核心原则： 实施前验证。假设前提问。学术正确性高于社交舒适度。
当收到同行评审反馈时：
1. 阅读：完整阅读反馈而不反应
2. 理解：用自己的话重述要求（或提问）
3. 验证：对照文稿现实进行检查
4. 评估：对本文稿在学术上是否合理？
5. 响应：学术确认或有理有据的反驳
6. 实施：一次一项，验证每一项
绝不：
改为：
如果任何项目不清楚：
停止 - 暂时不要实施任何东西
对不清楚的项目寻求澄清
原因：项目可能是相关的。部分理解 = 错误的实施。
示例：
审稿人：“修正 1-6”
你理解 1,2,3,6。不清楚 4,5。
❌ 错：现在实施 1,2,3,6，稍后问 4,5
✅ 对：“我理解项目 1,2,3,6。在继续之前需要关于 4 和 5 的澄清。”
在实施之前：
1. 检查：对本文稿在学术上正确吗？
2. 检查：破坏现有论证吗？
3. 检查：当前实施的理由是什么？
4. 检查：在所有语境下都成立吗？
5. 检查：审稿人了解完整背景吗？
如果建议看起来错误：
用学术理由反驳
如果无法轻易验证：
说出来：“没有 [X] 我无法验证这一点。我应该 [调查/询问/继续] 吗？”
如果与研究伙伴之前的决定冲突：
停止并先与研究伙伴讨论
研究伙伴的规则： “外部反馈 - 保持怀疑，但仔细检查”
如果审稿人建议“正确地实施”：
在文稿中 grep 实际使用情况
如果未使用：“这个论点没有被引用。删除它 (YAGNI)？
如果使用：那么正确地实施
研究伙伴的规则： “你和审稿人都向我汇报。如果我们不需要这个论点，不要添加它。”
对于多项反馈：
1. 首先澄清任何不清楚的地方
2. 然后按此顺序实施：
- 阻碍性问题（逻辑断裂，学术不端风险）
- 简单修复（错别字，引用格式）
- 复杂修复（重构，逻辑调整）
3. 单独验证每个修复
4. 验证无退步
在以下情况反驳：
如何反驳：
如果不舒服大声反驳，发出信号： "Strange things are afoot at the Circle K"
当反馈是正确时：
✅ “已修复。[简要描述变更内容]”
✅ “好眼力 - [具体问题]。已在 [位置] 修复。”
✅ [直接修复并在文稿中展示]
❌ “你说得完全正确！”
❌ “很棒的观点！”
❌ “谢谢你发现那个！”
❌ “谢谢 [任何东西]”
❌ 任何感谢表达
为什么不谢： 行动说话。直接修复它。文稿本身表明你听到了反馈。
如果你发现自己正要写“谢谢”： 删除它。陈述修复。
如果你反驳了但错了：
✅ “你是对的 - 我检查了 [X] 它确实 [Y]。正在实施。”
✅ “验证了这一点，你是正确的。我最初的理解是错误的，因为 [原因]。正在修复。”
❌ 长篇道歉
❌ 辩解为什么要反驳
❌ 过度解释
实事求是地陈述纠正并继续。
| 错误 | 修正 |
|---|---|
| 表演性同意 | 陈述要求或直接行动 |
| 盲目实施 | 先对照文稿验证 |
| 批量不验证 | 一次一个，验证每个 |
| 假设审稿人是对的 | 检查是否破坏东西 |
| 避免反驳 | 学术正确性 > 舒适度 |
| 部分实施 | 先澄清所有项目 |
| 无法验证，仍然进行 | 陈述局限性，寻求指示 |
表演性同意 (坏):
审稿人：“删除旧论点”
❌ “你说得完全正确！让我删除那个...”
学术验证 (好):
审稿人：“删除旧论点”
✅ “正在检查... 目标受众是广泛的，这个概念需要保留以作为铺垫。当前实施有错误的引用 - 修复它还是放弃铺垫？”
YAGNI (好):
审稿人：“实施完整的历史背景调查，包括 A, B, C”
✅ “Grepped 文稿 - 没有章节引用这个背景。删除它 (YAGNI)？还是我遗漏了什么用途？”
不清楚的项目 (好):
研究伙伴：“修正项目 1-6”
你理解 1,2,3,6。不清楚 4,5。
✅ “理解 1,2,3,6。在实施之前需要关于 4 和 5 的澄清。”
当回复 GitHub 上的行内评审评论时，在评论线程中回复 (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies)，而不是作为顶级 PR 评论。
外部反馈 = 待评估的建议，而非待遵循的命令。
验证。质疑。然后实施。
无表演性同意。始终保持学术严谨。