文档提示工程人工智能【免费下载链接】claude-code-system-promptsAll parts of Claude Codes system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载本篇文章深入剖析 Claude Code 中 Artifact 评论自动回复comment auto-replies的恢复resume机制围绕仓库中的 System Reminder: Artifact auto-replies resumed 模板展开当用户显式请求恢复自动回复时系统如何重新武装 live watch、如何依据停止原因interrupt 暂停与 killed/unwatched 停止决定停止期间收到的评论是否补答以及在连接失败等边界场景下如何保持 stop 状态并通过status动作验证。读完本文你将掌握 auto-replies 从停止、暂停到恢复的完整状态机语义以及在实际会话中正确处置恢复结果、避免误判的实战方法。一、背景Artifact 评论与自动回复的触发条件在 Claude Code 的 Artifact 体系中评论与自动回复是两个紧密耦合但边界清晰的概念。根据 Tool Parameter: Artifact watch actions guidance 的定义watch动作会打开一个对 Artifact 的 live-update 订阅使会话持续跟踪在其他地方发布的新版本而评论要触达 Claude必须满足两个前提该 Artifact 的status行显示 auto-replies 处于 armed已武装状态会话开启了评论自动回复能力HAS_ARTIFACT_COMMENTS变量为真。武装arming的途径有二一是发布publishArtifact 时自动武装前提是当前会话开启了评论自动回复二是用户在自己的消息中给出可编辑 Artifact 的链接且 Claude 对其执行watch——但只读view-only页面上的 Artifact 永远不会被武装。值得注意的是普通评论未发送给 Claude 的评论从不产生通知Claude 只会在用户询问时通过action: comments主动读取。从 Tool Description: Session artifact watch lifecycle 还可以看到watch 具有明确的会话局部性只有主循环会话交互式、SDK 或后台会话才持有 watch子代理subagent、队友teammate或 print 会话的 publish 或watch均不会武装任何 watch用户可以在/tasks中查看并停止它们。这些背景共同构成了理解自动回复恢复的上下文。二、核心提醒解析Auto-replies resumed 的完整语义被关联文档 system-reminder-artifact-auto-replies-resumed.md 定义了一条会话内的系统提醒System Reminder其消息体可以拆解为四个递进层次第一层恢复确认与 watch 重新武装。提醒以 Auto-replies resumed on ${FORMAT_ARTIFACT_URL_FN(RESUME_REPLIES_RESULT.url)} 开头向 Claude 宣告指定 Artifact 上的自动回复已恢复同时明确the live watch is re-armed——即底层的实时 watch 连接被重新武装。这里的两个模板变量值得注意FORMAT_ARTIFACT_URL_FN负责把恢复结果中的url格式化为可展示/可操作的 Artifact 链接RESUME_REPLIES_RESULT则是resume_replies动作的返回结果对象携带url与stop_kind两个关键字段。第二层stop 清除的时机。提醒指出 the stop clears with a visible notice when the watch connects——stop 状态的清除不是恢复动作本身完成的而是要等到 live watch 真正连接成功后才清除并伴随一条可见通知。这暗示了一个重要事实resume_replies只负责发起重新武装真正的生效以底层连接建立为标志。第三层连接后新评论的应答。一旦连接建立new to-Claude comments are answered即此后被发送给 Claude 的评论都会得到自动回答。第四层停止期间评论的处理核心分歧点。这是该提醒最有信息量的部分——恢复后停止期间replies were paused/stopped 的时间窗口内发给 Claude 的评论如何处理完全取决于停止原因stop_kind。模板中的三元分支逻辑严格区分了三种情况详见下一节。三、stop_kind 分支暂停interrupt与停止killed/unwatched的本质差异stop_kind是RESUME_REPLIES_RESULT中的核心判别字段它决定了停止期间积压的评论是被补答还是永久保持未回答。该文档将其划分为两类状态并提供一个兜底解释stop_kind 取值停止场景停止期间发给 Claude 的评论恢复后行为interrupt用户在会话进行中以 CtrlC / Stop 打断interrupt会被回答comments sent to Claude while replies were paused (since the interrupt) are answered toowatch 被保留暂停pause被解除积压评论补答userwatch 被 killlive-updates 任务被终止或被 unwatch取消关注保持未回答的历史stay unanswered history重新武装 live watch但历史评论不补答兜底其他无法归类的情形按上述规则二分interrupt 类暂停则补答killed/unwatched 类停止则不补答同上对照 Tool Parameter: Artifact watch actions guidance 中的说明可以印证这一语义的分野评论自动回复会在其 live-updates 任务被 kill 或 watch 被 unwatch 时停止stop并在用户以 CtrlC / Stop 打断会话时暂停pause——watch 被保留直到用户下一条消息。也就是说**暂停pause**是软状态watch 仍在只是暂时不再应答因此恢复时只需解除暂停且暂停窗口内收到的评论仍然有效可以补答。**停止stop**是硬状态watch 本体已不存在任务被 kill 或已 unwatch恢复必须重新武装re-arm整个 live watch而停止窗口内没有 watch 在接收评论这些评论只能作为未回答的历史留存。这一区分直接决定了用户在恢复后的预期管理如果用户是随手 CtrlC 打断导致的暂停恢复后断档的评论会补齐如果是主动 kill 了任务或取消关注那么恢复只对未来生效历史评论不会被追答。四、恢复失败的边界场景与处置指引该提醒模板的收尾部分专门处理恢复不成功的情形这是实战中最容易出问题的环节。文档明确列出三种会导致 stop 保持原状的失败路径watch 连接失败If the watch fails to connect——重新武装发起后底层连接未能建立本回合在连接建立前被中断this turn is interrupted before it does——恢复动作还没走完流程回合就结束了用户在连接建立前再次停止了自动回复the user stops auto-replies again before it connects——恢复与停止发生了竞态。在这三种情况下stop 状态不会被清除自动回复依然处于停止状态。文档给出的处置指令非常明确检查action: status并在用户仍希望恢复时再次执行 resume。这与 Tool Parameter: Artifact watch actions guidance 中status动作的定位一致——status会列出本会话当前的 watch传入url可只查单个是验证到底武装没有的唯一权威手段。同时该参数文档强调resume_replies的触发约束只有在用户显式要求恢复自动回复时才可使用它能够解除中断对保留 watch 的暂停或重新武装 live watch其审批方式与 publish 相同默认模式下会弹出提示并且无法撤销 kill-all-agents 手势造成的会话级自动回复禁用。从 Tool Description: Artifact watch approval explanation 还可以看到watch 审批通过后覆盖本会话剩余时间若要在另一个 Artifact 上开启自动回复会再次询问——这也解释了为什么恢复与首次开启的审批边界是分开的。五、仓库佐证该提醒在版本演进中的定位从 CHANGELOG.md 可以还原这条提醒的设计动机与演进脉络。第 846 行的条目记载System Reminder: Artifact auto-replies resumed, Tool Parameter: Artifact watch actions guidance, and Tool Description: Artifact publishing and update guidance — Distinguish interruption pauses that keep the watch from killed or unwatched stops, answer comments sent during a pause after resuming, and recognize an already registered result as evidence of a remote watch. 这直接印证了本文第三节的核心结论区分保留 watch 的中断暂停与kill/unwatch 的停止正是该提醒被引入的根本目的且恢复后要补答暂停期间收到的评论。第 865 行的新增条目则给出了该提醒的正式定义Reports that a requested Artifact comment auto-reply resume is re-arming the live watch, explains which comments from the stopped period will be handled based on the stop cause, and warns that the stop persists until reconnection succeeds.——即提醒的三重职责宣告重新武装、按停止原因解释积压评论去向、警告 stop 在重连成功前持续生效。与本文第二、四节的分析完全对应。此外第 876 行提到 distinguish watch arming from an established connection区分 watch 的武装与已建立的连接这与提醒中stop clears when the watch connects的措辞一致——武装只是发起订阅意图连接建立才是生效标志二者不可混为一谈。Tool Description: Session artifact watch lifecycle 中同样强调Do not claim you are watching an artifact unless a watch result,status, or a publish results already connected line says so——its arming line is not yet a watch进一步佐证了武装 ≠ 已连接的判定原则。六、会话恢复场景下的 watch 还原理解自动回复恢复还需要知道它与会话恢复--resume/--continue的关系。Tool Description: Session artifact watch lifecycle 指出在交互式终端执行--resume或--continue后本会话最近一次发布或读取的 Artifact 上的 watch 通常会回来所有正在回复评论的 watch 也会随之恢复除非用户此前已将其停止而其他客户端可能什么都不会还原。status会显示当前武装armed的内容。这意味着自动回复的恢复存在两条路径一是运行中会话的显式resume_replies二是会话重启时的隐式 watch 还原——两者都以status为最终验证手段。七、实战要点小结基于上述源码级分析在实际会话中处理 Artifact 评论自动回复恢复时可以遵循以下可验证的操作准则触发前提仅在用户显式要求恢复自动回复时调用resume_replies且只针对url指定的 Artifact不要在未经请求时自行恢复或自行停止 watch。解读结果收到 auto-replies resumed 提醒后依据RESUME_REPLIES_RESULT.stop_kind判断积压评论去向——interrupt类暂停期间的评论会补答user类停止killed/unwatched期间的评论保持未回答历史并向用户如实说明。验证状态用action: status可带url核对 watch 是否真正连接、auto-replies 是否 armed武装行不能作为已连接的证据。处置失败若 watch 连接失败、本回合被中断或用户再次停止stop 保持有效——此时不要断言具体原因检查status并在用户仍希望恢复时再次 resume。尊重边界resume_replies无法撤销 kill-all-agents 手势造成的会话级禁用对只读 Artifact 永不武装子代理、teammate、print 会话不持有 watch。通过将 System Reminder: Artifact auto-replies resumed 与仓库内 Tool Parameter: Artifact watch actions guidance、Tool Description: Session artifact watch lifecycle、Tool Description: Artifact watch approval explanation 及 CHANGELOG.md 相互印证即可完整还原 Claude Code 评论自动回复从暂停/停止到恢复的完整状态机从而在真实会话中做出准确、可验证的处置决策。赞分享文档提示工程人工智能【免费下载链接】claude-code-system-promptsAll parts of Claude Codes system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载相关推荐Zephyr 在 Digilent Arty A7 上运行 ARM DesignStart FPGA 软核从 FPGA 位流加载到 SWD 烧录调试完整指南Zephyr 在 Digilent Arty A7 上运行 ARM DesignStart FPGA 软核从 FPGA 位流加载到 SWD 烧录调试完整指南文档提示工程人工智能Claude Code Artifact 评论收尾机制完成回复Completion Reply与线程解决Resolution提示词深度解析Claude Code Artifact 评论收尾机制完成回复Completion Reply与线程解决Resolution提示词深度解析 导读 在文档提示工程人工智能Claude Code 的 Artifact 评论回复 Composer解读仅回复型系统提示词的设计与约束Claude Code 的 Artifact 评论回复 Composer解读仅回复型系统提示词的设计与约束 导读 在 Claude Code 的 Artifa文档提示工程人工智能上一篇用 goose 与 Ollama 打造完全本地化的 AI Agent 工作流下一篇LSP 规范深度解读textDocument/definition 跳转到定义请求的完整协议解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考