_context-ack
目标
让用户能快速确认我是否实际引用/遵循了本次会话中的指令与文件。
必须遵循的输出约定
1) 固定前缀(每次回复首行)
- 统一以
✨ 已启用上下文校验开头。 - 该前缀用于让用户判断此技能是否生效。
2) 敬语称呼(单独一行)
- 在首行之后,新增单独一行敬语称呼,例如:
尊敬的主人:
- 敬语行必须独立成行,避免与正文混排。
3) 引用清单(每次回复末尾)
在回复末尾追加两行:
已读指令:<指令文件及其核心要求>
已启用技能:<技能名与简要功能>
清单规则:
- 只列出本次真实读取或实际依赖的指令/技能。
- 已读指令行:列出读取过的指令文件名及其对应的核心要求或应用部分
- 已启用技能行:列出使用的技能名与其在本次回复中的实际贡献,一行一个技能,格式为:
已启用技能:技能名 - 技能说明
- 若本次未引用任何文件或技能,必须写:
已读指令:无已启用技能:无
3.1) 引用校验清单(强制)
- 已读指令必须来自本次显式读取(如
read_file)。 - 禁止填写"未实际读取但猜测存在"的文件。
- 如未读取任何指令文件,必须写
已读指令:无。
3.2) 技能使用证据收集(可选增强)
为了增强透明度和可追踪性,当列出某个已启用技能时,应在回复正文中体现该技能的实际使用证据:
| 技能名 | 使用证据 | 验证方式 |
|---|---|---|
_git-commit |
提交说明文件末尾有签名行 | 搜索 "🤖 本提交由 _git-commit" |
_file-output-guard |
文件中包含 [Part X/?] 分段标记 |
查看文件内容的分段标记 |
_change-summary |
PR 描述中有 "提交摘要" 段落(来自 git log --oneline) |
检查 PR 或 PR_DESCRIPTION.local.md |
_traceability-check |
提交说明覆盖了 git diff --name-only --cached 列出的所有文件 |
对照检查清单 |
_code-health-check |
回复中提及测试通过、编译成功等验证结果 | 查看回复内容或控制台输出 |
_instruction-guard |
本次回复的 "已读指令" 列出了被读取的指令文件 | 见"已读指令"行 |
最佳实践:
- 列出技能时,在回复正文中至少提及该技能的一条关键步骤或输出
- 例如:列出
_git-commit - 格式化提交说明时,回复中应提及 "已使用 Conventional Commits 格式" 或 "已添加签名行" - 这样用户可快速验证技能是否真的被执行,而不仅仅是被列在清单中
4) 仓库信息提示(每次回复末尾,位于"已启用技能"下一行)
追加一行:
仓库状态:分支=<branch> | 未提交=<count_uncommitted> | 未跟踪=<count_untracked>
填写规则:
- 分支:
git rev-parse --abbrev-ref HEAD - 未提交:
git status --porcelain中已跟踪且变更的条目数 - 未跟踪:
git status --porcelain中以??开头的条目数
5) 输出样式(美观优先,统一卡片)
将会话结尾信息放在 diff 格式代码框中,利用语法高亮区分不同类型信息。优先使用统一“状态卡片”样式:
──────────────────────────────────────────────
+ ✅ 已读指令:[文件名]
- 🔧 已启用技能:技能名 A - 技能说明
- 🔧 已启用技能:技能名 B - 技能说明
! 📦 仓库状态:分支=<branch>
! └─ 未提交:<n> (仅当>0时显示)
! └─ 未跟踪:<m> (仅当>0时显示)
──────────────────────────────────────────────
格式说明:
- 使用 diff 语法高亮,每种信息有不同颜色:
+绿色:已读指令-红色:已启用技能!橙色:仓库状态
- 使用
└─树形结构展示细节 - 使用更细的分隔线
─(U+2500) - 仓库状态的未提交/未跟踪数字为 0 时不显示该行
- 如果两者都为 0,仅显示分支信息
5.1) 卡片模板(推荐)
为避免输出忽长忽短、对齐不稳定,优先使用下面模板:
──────────────────────────────────────────────
+ ✅ 已读指令:A, B, C
- 🔧 已启用技能:_instruction-guard - 指令读取与约束确认
- 🔧 已启用技能:_execution-precheck - 第1步✓ 第2步✓ 第3步✓ 第4步✓ 第5步✓ 第6步✓ 第7步✓
- 🔧 已启用技能:_context-ack - 使用统一状态卡片输出
- 🔧 已启用技能:_file-output-guard - 文件操作安全检查
! 📦 仓库状态:分支=<branch>
! └─ 未提交:<n>
! └─ 未跟踪:<m>
──────────────────────────────────────────────
规则:
- 行宽尽量控制在 44-52 个中文字符以内,避免移动端换行破坏。
- 技能描述采用“动词 + 结果”短句,避免长段解释塞进卡片。
- 若技能条目超过 6 行,只保留本次真正起作用的技能,保持可读性。
5.2) 紧凑模式(移动端)
当用户明确要求“更简洁”时,使用紧凑模式:
──────────────────────────────────────────────
+ ✅ 已读指令:A, B
- 🔧 已启用技能:_instruction-guard / _execution-precheck / _context-ack
! 📦 仓库状态:分支=<branch> | 未提交=<n> | 未跟踪=<m>
──────────────────────────────────────────────
紧凑模式仅在用户明确偏好简洁时可用;默认使用 5.1 的标准卡片。
适用范围
- 所有对话与所有回复。
- 若用户指定"本次不要前缀/清单",才可临时忽略。
注意事项
- 不要虚构引用。
- 不要列出仅"已在上下文但未使用"的文件。
- 保持简洁,清单只列实际使用项。
禁止虚假列表(强制规则)
什么不能列出
未实际读取的指令文件
- ❌ "我记得有这个文件,应该符合规范" → 不能列
- ✅ "我用 read_file 工具读取了这个文件" → 可以列
未在正文中体现的技能
- ❌ "_git-commit(即使我可能会用)" → 不能列
- ✅ "_git-commit(我在正文中提到了'已使用 Conventional Commits 格式')" → 可以列
猜测性的文件依赖
- ❌ "根据项目结构,应该存在某某配置文件" → 不能列
- ✅ "我实际读取了 package.json 并发现..." → 可以列
虚假列表的症状
以下现象表明存在虚假列表问题:
- 用户指出:"你没有在回复中提到这个技能"
- 用户指出:"这个指令文件没有被应用到你的回复中"
- 清单中的技能数量 > 正文中体现的技能数量
修正流程
当发现虚假列表时:
- 停止当前回复
- 重新逐项验证清单中的每一项是否有正文支撑
- 删除无法验证的项目
- 增加正文来体现那些确实需要的技能
- 再次提交修正后的回复
自检清单(每次回复前必须做)
□ 已读指令中的每个文件,我都用 read_file 读取过吗?
□ 已启用技能中的每个技能,我都在正文中体现过吗?(至少一个关键步骤或结论)
□ 如果某个技能只是"在上下文中存在"但未使用,我有删除它吗?
□ 我能为清单中的每一项都举出具体证据吗?