volcengine-feedback

Volcengine 反馈

帮助用户分享使用 Agent 管理云服务的实践经验：带来的益处、遇到的困难，以及希望使用的功能。简要描述场景即可；诊断或实现方案均为可选。

提交至 GitHub 上的 volcengine/volcengine-agent-toolkit。 反馈表单 · 社区与隐私指南。

继续推进主要任务

• 遇到错误或结果不完整时，可以选择邀请用户反馈，但绝不意味着可以发布反馈。先继续执行已获授权的诊断、恢复和剩余工作。只在自然的总结环节提及反馈；在所有技能中，每次对话最多提及一次。如果用户拒绝、忽略了邀请或已经收到邀请，就不要再次提醒。常规成功无需征求反馈；用户表示有兴趣时，再帮助分享成功案例。
• 主动邀请反馈时，用一句简短的话附上表单链接。不要等待回复，也不要仅为邀请反馈就开始起草内容、搜索问题、收集日志、安装工具或技能、登录或打开浏览器。示例： “如需反馈本次未解决的问题，可通过 Feedback 说明使用场景和改进建议；反馈不影响当前任务继续。”
• 用户提出反馈后，将其作为可选的附带任务处理。信息缺失、无法访问 GitHub、用户拒绝发布或提交失败，都不能成为开展云服务工作的前提。保留对话中的草稿，并继续处理剩余工作。绝不要为了获取反馈证据而重复执行会修改云服务状态的操作，也不要重现事故。

一句话 → 一个预览 → 一个结果

用户可以说“我希望反馈使用中遇到的问题：……”或“分享本次成功部署的实践”，也可以在其宿主中调用 volcengine-feedback。此技能不会添加原生的 /feedback 或 ve feedback 命令；请使用宿主实际的技能调用方式。保持对话自然：

1. 根据上下文起草。 重用用户的句子和相关对话。推断可选类别（技能问题、能力请求、场景需求或成功案例）、标题，以及已知的产品／技能详情。只有在没有可用经历可描述时，才最多提出一个简短问题。否则省略缺失详情；绝不要把这变成问卷。
2. 展示一个简洁的预览。 提供 [Feedback] <short title> 和一段简短文字，说明目标、体验及期望的改进或价值（仅限已知信息）。只有在已有的脱敏证据有帮助时，才添加可选的“详情”段落。不要求提供版本、复现步骤、日志或单独的情绪评分。使用用户所用语言，措辞清晰、专业，并准确保留用户报告的体验和顾虑。不要编造根本原因、结果、节省的时间或维护者的承诺。
3. 提供一个发布决定。 在精确预览旁注明公开仓库，并链接社区／隐私指南，提醒用户公开分享时注意相关事项。用户可以发送、修改或留作草稿。请求起草并不代表授权发布；若已有明确授权且涵盖此确切内容和目标位置，则可依照授权操作。否则只询问一次是否发布，同时不要因此暂停无关的主要工作。

当对话支持以下事实时，预览示例：

[Feedback] 建议在部署完成后增加服务可用性验证

使用 Agent 部署测试应用时，已完成资源创建，但尚未验证服务可用性。 建议继续执行可用性检查，并提供明确的验证结果。

将公开发布到 volcengine/volcengine-agent-toolkit，仅包含以上脱敏内容。 发布前请检查敏感信息，并遵守反馈约定。 你可以确认发送以上内容、修改或先留作草稿。

对于正在处理的故障，请继续排查或联系官方支持；公开问题不保证响应时间或解决结果。

检查公开分享内容

在搜索问题、预填 URL、添加附件或提交之前，请尽量减少并脱敏数据。该问题将是公开的。只包含理解场景所必需的信息：

• 删除 AK/SK、令牌、Cookie、授权标头、签名 URL、密码、个人／客户数据、私有端点、本地绝对路径和机密业务内容。将账户 ID 替换为 <account-id>，将资源 ID 替换为保留前缀的形式，例如 vpc-<id> 和 clb-<id>，并将真实 TRN 替换为 <resource-trn>。也要检查标题、截图和附件。
• 尽量提供简短的脱敏摘录，而不是完整的对话记录、配置文件或日志。不要检查凭据存储，也不要为了反馈收集更多云数据。如果无法确定能否安全脱敏，就省略相关详情。安全漏洞或疑似凭据泄露应通过项目提供的私密安全报告渠道或 Volcengine 官方支持渠道处理，不要编造私密联系渠道，也不要上传漏洞利用详情。
• 遵守 GitHub 社区准则。欢迎报告使用中遇到的问题并提出改进建议。聚焦事实、证据和影响。人身攻击、骚扰、歧视、仇恨言论、威胁以及披露他人隐私信息均不可接受；维护者会直接关闭包含此类违规内容的问题。如果草稿包含攻击性内容，请提供保留核心顾虑的事实性改写；不要发布攻击性文本。

提交或发送

根据上方的发布决定，使用可用且已获授权的 GitHub 集成或浏览器。 不强制依赖可执行文件或环境变量。表单中的公开分享指南仅供参考，没有复选框或单独的同意步骤。仍需获得对确切内容及公开提交的授权。无需搜索 issue。如果已知有匹配的 issue，或用户要求查找，请仅搜索经过净化的关键词；在现有讨论串中发表评论，也需要获得对该目标的授权。

结果	完成反馈附带任务
已通过返回的 URL 或回读验证提交	简短确认已作出贡献，并返回 issue 链接。
仅有草稿、无法访问 GitHub，或确定提交失败	标记为“未提交”；返回可复制的草稿和表单链接，无需要求登录、安装或开启新对话。只有在用户提出请求时，才协助设置访问权限。
创建操作超时，可能已成功	重试前先检查是否存在匹配的 issue。如果无法验证，标记为“提交状态未确认”，保留草稿，并停止本次尝试以避免重复。

立即继续其余已获授权的主要工作。任何结果都不需要等待维护者。