semantic-stitching-guard
Skill0 starsChanged 4 months agoApache-2.0View on GitHub
防止跨证据层熔合、虚假因果与事实推论错误拼接,事实与推论必须严格分置。
In this repository6 other files it gives its agents.
- archiveSkill
- bifrostSkill
- context-guardSkill
- kernel-securitySkill
- origin-thinkingSkill
- safe-path-migrationSkill
The file
Files
语义拼接防护
拼接是大语言模型的通病。 不是 unwilling,而是 statistical completion 的结构性副作用: 模型倾向于把最近相关的两个证据"合流"成一句看似连贯的陈述。 本 skill 用操作纪律对抗这个倾向。
核心原则
- 事实与推论分置 — 不能在同一个句子里用"说明 / 体现 / 意味着 / 暗示"连接不同来源或不同层级的内容。
- 单句单证 — 每个事实独占一句,来源挂在句尾。
- 证据边界即句 boundary — 引用不同于当前句的证据时必须断开(分号、新段、或明确标签)。
- 原材料不进上下文 — 只留结论和来源,原始文本丢弃。这条与
context-guard直接协同。
操作规则
1. 事实 / 推论层分置
任何包含因果或推断的陈述,必须拆成两层:
事实层格式:[具体事实] [来源名](url)
推论层格式:推论:[你的推导,使用当前事实层作为唯一前提]
错误示例(熔合):
环形熔断器被列为 P0,说明之前的花哨功能里埋了架构债。
正确示例(分置):
环形熔断器与速率限制重构被列为 P0;同期 changelog 显示 5-7 天一个功能发布。来源 推论:在功能覆盖面快速扩展期间,并发控制与 API 可靠性的工程投入相对不足。
为什么要分置:
- 事实可能对,但推论可能错——分开才能分别验证
- 读者可以选择信事实、不信推论,而不是被迫打包接受
- 推论错了可以单独修正,不影响事实的可信度
2. 单句单证
一个句子里只挂一个来源 URL。多个来源必须拆成多个句子。
错误示例:
跨平台桌面/网关已交付,且 run_agent.py 纤细化已交付,但 #10445 证明并发可靠性仍有债。
正确示例:
跨平台桌面 App 已交付:v2026.6.5 Surface Release。来源 run_agent.py 从 16,000 行重构为模块化组件:v2026.5.28 Velocity Release。来源 Issue #10445 仍为 Open,证明并发可靠性相关修复未关单。来源
为什么要单句单证:
- 一个来源错了,不连累其他事实
- 读者可以逐条验证,而不是囫囵接受
- 便于后续更新——某条事实变了,只改那一句
3. 证据变更必须断开
当前句和上一句引用的是不同版本、不同 Issue、不同文章时,必须用分号或新段。
禁止跨层连接的词:
- 这说明 / 这体现 / 由此可见 / 因此
- 证明了 / 意味着 / 暗示着
- 因为 A,所以 B(除非 A 和 B 来自同一来源)
触发断开的场景:
| 场景 | 示例 |
| 从 A 版本跳到 B Issue | changelog → Issue 讨论 |
| 从官方文档跳到社区文章 | 官方说明 → 用户吐槽 |
| 从事实跳到推论 | 数据陈述 → 因果推断 |
| 从用户信息跳到公开信息 | 用户说的 → 搜索到的 |
断开方式:
- 用分号
;分隔 - 用新段落分隔
- 用明确的标签标注(如
事实:/推论:)
4. 与 context-guard 协同
| context-guard | semantic-stitching-guard |
| 控制读什么、读多少 | 控制写出来的推理结构 |
| 防止数量溢出 | 防止质量熔合 |
| 少读 → 省空间 | 分置 → 防幻觉 |
协同铁律:
没读过的不开口,不确定的不下结论。
为什么原材料不进上下文:
- 上下文里没有原材料,就不会有"原材料熔合"的冲动
- 每一个结论都必须能追溯到具体来源
- 自然减少拼接——没有原料就没法乱拼
自检清单(输出前必做)
输出前逐句检查,四项全过才算合格:
第 1 项:事实与推论是否分离?
- 这句话里是否同时存在事实和推论?
- 是否用了"说明/体现/意味着/暗示"连接?
- → 是 → 拆成两句,推论句前加
推论:标签
第 2 项:是否单句单证?
- 这句话挂了几条来源 URL?
- → ≥2 条 → 拆成多句,每句一个来源
第 3 项:证据变更是否断开?
- 这句话和上一句话的来源是否不同?
- 是否用了"这说明/由此/因此"跨层连接?
- → 是 → 断开,改用分号或新段
第 4 项:来源是否真实读过?
- 这个来源 URL 是我实际读过的吗?
- 还是从别处看到、自己没验证过?
- → 没读过 → 删除或换成真实来源;没有来源就标注为推论
输出格式规范
| 层级 | 格式 | 示例 |
| 事实层 | [具体事实] [来源名](url) | XX 项目已发布 v2.0。[官方博客](url) |
| 推论层 | 推论:[推导过程] | 推论:从迭代频率看,团队进入了快速迭代期。 |
| 猜测层 | 猜测:[未证实的推测] | 猜测:可能是为了应对 Q3 的用户增长预期。 |
| 存疑 | ⚠️ 存疑:[不确定的点] | ⚠️ 存疑:该数据来自第三方,未交叉验证。 |
常见错误速查表
| 错误类型 | 错误示例 | 正确做法 |
| 熔合式 | "A 说明 B" | 拆成事实句 + 推论句 |
| 堆砌式 | 一句话塞 3 个来源 | 拆成 3 句话 |
| 跳跃式 | "根据 A,所以 B" | A 和 B 不同来源就断开 |
| 无源式 | "行业专家认为" | 要么给来源,要么标推论 |
| 打包式 | "以上数据证明..." | 逐条对应,不打包 |
| 模糊式 | "据报道" | 具体哪个报道?给 URL |
不适用场景
以下场景不适用本防护规则:
- 纯代码:写代码、调试代码、代码审查
- 系统管理:运维操作、配置管理
- 创造性写作:小说、诗歌、创意文案
- 纯对话:日常聊天、非正式讨论
规则是死的,判断是活的。核心是"不让读者把推论当事实"。
最小执行单元
输入:
- 待输出结论、对应来源、需要区分的事实与推论。
执行:
- 将事实句、推论句、猜测句分层。
- 每个事实句只绑定一个来源。
- 跨来源或跨层级时断句或换段。
输出:
- 可追溯的事实层。
- 明确标注的推论层。
- 存疑或未验证信息的边界说明。
完成标准:
- 事实和推论没有熔合。
- 每个事实都能追溯到真实读过的来源。
- 无来源内容不伪装成事实。
失败处理:
- 来源不足:降级为推论或存疑。
- 多来源冲突:并列呈现,不强行合并。
- 不确定:明确说不确定,不补全。
禁止事项
- ❌ 同一句子里同时存在事实和推论,用"说明/体现/意味着"连接
- ❌ "根据 A,B 成立" — 除非 A 和 B 来自同一来源、同一层级的直接陈述
- ❌ 跨来源熔合(把 A 文章的事实和 B Issue 的推论连成一句)
- ❌ 省略来源 URL,用"据说/有人说/专家认为"代替
- ❌ 用"行业观察者说 / 专家认为"垫付无来源的推论
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

