LB623/no-negative-echo · 上手攻略

仓库：LB623/no-negative-echo
链接：https://github.com/LB623/no-negative-echo
分类：AI Agent · 交付质量
作者：Tom
更新：2026-08-25

是什么

no-negative-echo 是一个 Agent Skills 格式的 Skill（技能插件），用于解决 Agent 在迭代修正过程中产生的「负面残留」问题——Agent 在多轮对话里否定了某些方案、尝试或措辞，但最终交付的标题、commit 信息、PR 说明里仍然残留了被否内容。

典型症状：

- 标题：番茄炒蛋（没有东坡肉）
+ 标题：番茄炒蛋

说白了：Agent 交付了「最终结果」，却把「过程」里的被否方案也一起打包进去了。no-negative-echo 要求 Agent 从「已采用、已验证的最终状态」重新生成所有交付文案，并逐面（commit/PR/文章标题/UI 文案）检查会话残留。

解决什么问题

标题污染：多轮修改后，标题里还留着「不用 XX」「不含 YY」之类的否定表述。
commit 残留否决内容：commit message 里写着「remove previously suggested approach」之类暴露内部讨论的内容。
PR 描述暴露中间过程：PR 里列举了「我们考虑过 A/B/C，最后选 B」，读者其实不需要这些。
文档/文章开篇泄露决策过程：文章开篇花篇幅解释「为什么没有采用XX方案」。

核心目标：只交付结果，不交付过程。

快速安装

方式一：远程安装（推荐，Codex/兼容 Agent）

让有网络和终端权限的 Agent 自动安装：

请安装 no-negative-echo Skill：
https://raw.githubusercontent.com/LB623/no-negative-echo/main/INSTALL.md

安装完成后 Agent 会告知结果，以及是否需要开启新会话。

方式二：本地手动安装

git clone https://github.com/LB623/no-negative-echo.git
cd no-negative-echo
python3 -I -m unittest discover -s tests -p 'test_*.py'

# 安装 Skill
python3 -I scripts/install_skill.py \
  --expected-provenance-sha256 d42280b21f519ea00e417c68f31c68ca3d7faae607faf6dcb6e04beeff9c5ed6 \
  --discovery-root "$HOME/.agents/skills" \
  --agent codex

安装后可在 ~/.agents/skills/no-negative-echo/ 找到 Skill 文件。

方式三：仅追加 AGENTS.md（轻量级）

如果只需要核心约束而不需要完整 Skill 检查流程，可以把以下内容追加到项目根目录的 AGENTS.md（不存在就新建，不要覆盖已有内容）：

## No Negative Echo

生成最终产物及其包装时，包括标题、文件名、正文、注释、标签、commit、
PR 和交付说明，只描述最终采用的状态，假设读者没看过本次会话。

- 会话里的否决、中间尝试和措辞纠正，只当作控制信息，不要让它们成为最终产物的命名或叙述中心。
- 对每个交付面分别判断：不知道本次会话的读者需要这条信息吗？省略会不会导致不准确、不安全、误导或兼容性信息缺失？它是不是任务开始时已提交或用户确认状态中的真实变化，而且当前交付面需要解释它？
- 「不要提 X」不是让你写「无 X」。标题、文件名、开篇和标签应从正向目标重新生成，不要逐词修改被否文案。

核心用法

显式调用（重要交付前）

使用 no-negative-echo Skill。
根据最终 diff 写 commit subject、PR 标题、PR 正文和交付说明。

文章/文案场景：

使用 no-negative-echo Skill。
根据最终保留的正文重写标题和开篇。

AGENTS.md 方式（持续生效，轻量）

追加上述约束段落后，Agent 在每次运行时自动遵守，不需要显式调用。但无法触发 scripts/check_surface.py 高保障检查脚本。

高保障模式（可选）

需要严格验收时，Skill 会读取 references/high-assurance-finalization.md 中的增强流程，包括更多检查项和脚本验证。

交付前检查三问（无需 Skill 的核心判断原则）

对每个输出位置单独判断：

这条信息，读者不知道本次对话的前提下，需要吗？ → 不需要就删
省略会造成事实错误、安全风险、误导或兼容问题吗？ → 会就保留
它是否是权威基线中的真实变化，且当前交付面需要解释它？ → 是才保留

仅仅「出现过」或「被否过」不是保留理由。

内容处理对照表

内容类型	处理方式
只在会话中讨论、从未进入最终基线的方案	省略
助手草稿、中间尝试、用户的措辞纠正	省略
已发布的 API 删除、迁移与外部操作	如实说明
安全、法律、兼容性、审计所需事实	保留
用户明确要求的对比、引用或决策记录	保留
任务开始前已有的用户改动	保留归属，不算本次成果

典型适用场景

代码提交：多轮 Review 后，用最终 diff 重新生成 commit message，不暴露被否方案
PR 描述：避免「我们尝试了 X/Y/Z，最后选了 Z」这类过程描述
技术文章/博客：标题和开篇只说「最终做了什么」，不解释「没做什么」
产品文案：UI 文案不写「不支持XX功能」而写「支持YY功能」
长对话多轮修改后的最终交付：确保最终交付物干净，不残留中间态

坑与注意

⚠️ Skill 被安装 ≠ 已激活：重要交付应显式调用，不应只依赖安装状态。

⚠️ 不是确定性过滤器：这是提示词层的缓解措施，不能清除模型已读上下文，也不能控制工具日志或宿主 UI 的展示。

⚠️ 内置扫描器只做文本/文件名检查：PASS 不代表语义检查完成，不能作为唯一验收手段。

⚠️ 不要为通过检查而修改：API 变更、迁移说明、测试快照、已有用户改动不要删除或篡改。

⚠️ 凭据和隐私问题：这类内容应交给专门工具处理，不要依赖 Skill 过滤。

⚠️ 安装时需验证 SHA256：INSTALL.md 中的 expected-provenance-sha256 用于校验脚本完整性，防止供应链攻击。

与同类对比

	no-negative-echo	直接在 Prompt 里写「不要写被否内容」	项目内 CI 检查
原理	提示词约束 + 可选脚本检查	单一 Prompt 要求	确定性文本规则
覆盖场景	标题/文件/正文/commit/PR/交付说明	取决于 Prompt 表述	仅文本匹配
误报率	低（基于语义判断原则）	高（容易产生矛盾指令）	低（但只能检测固定模式）
部署成本	Skill 安装一次，持续生效	每次写 Prompt	需配置 CI 脚本
误删风险	低（保留真实变化）	高	低

no-negative-echo 的核心优势是「从最终状态重新生成」而非「删除否定词」——这避免了「不提 X」变成「写无 X」的负向表述问题。

一句话推荐结论

多轮迭代的 Agent 项目必备：no-negative-echo 解决的是交付物里残留被否方案的「负面回音」问题，核心原则是「只交付结果不交付过程」，适合所有重视交付质量和对齐规范的 AI 编程场景。 ⚠️ 注意它本质是提示词层缓解而非确定性过滤器，重要交付仍需人工复核。