Back to Details

self-learning-feedback

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Self-Learning Feedback

自学习反馈

Purpose

用途

Use this skill to create recursive learning after each completed task or cron job without disrupting user flow.
使用该Skill在每项任务或cron作业完成后开展递归学习，且不会干扰用户流程。

Defaults

默认配置

  • GOOD_APPROVAL_TARGET = 10
  • SLIGHT_MAX_ITERATIONS = 5
  • MEDIUM_MAX_ITERATIONS = 10
  • SEVERE_MAX_ITERATIONS = 20
If the user explicitly asks for a different threshold (for example 20 good approvals), update only 
GOOD_APPROVAL_TARGET
.
  • GOOD_APPROVAL_TARGET = 10
  • SLIGHT_MAX_ITERATIONS = 5
  • MEDIUM_MAX_ITERATIONS = 10
  • SEVERE_MAX_ITERATIONS = 20
若用户明确要求修改阈值（例如20次良好认可），仅更新
GOOD_APPROVAL_TARGET
的值。

When To Trigger

触发时机

Trigger after a clear completion point:
  • A discrete task was completed.
  • A cron job execution and response was completed.
Identify task type/context from the request (e.g. cron job name, report type, command, or goal) so that good-approval counters and issue signatures can be scoped correctly.
Do not trigger:
  • Mid-task.
  • During a multi-step process before a natural completion point.
  • More than once for the same completion event.
在明确的完成节点触发：
  • 独立任务已完成。
  • cron作业执行及响应已完成。
从请求中识别任务类型/上下文（如cron作业名称、报告类型、命令或目标），以便正确划分良好认可计数器和问题特征的范围。
以下情况不触发：
  • 任务进行中。
  • 多步骤流程尚未到达自然完成节点时。
  • 同一完成事件重复触发多次。

Non-Intrusive Feedback Prompt

非侵入式反馈提示

After completion, send one short feedback prompt:
Task completed. Was this good or does it need improvement?
Keep prompt length to 1-3 lines.
任务完成后，发送一条简短的反馈提示：
任务已完成。本次输出是否良好，或是需要改进？
提示长度控制在1-3行。

Feedback Branches

反馈分支

Branch A: User says "Good"

分支A：用户回复“良好”

  1. In the same turn, ask: 
    What was good about this output?
  2. Capture the user's positive signal (quality, format, style, speed, clarity, etc.).
  3. Increment the consecutive good-approval counter for this task type/context (e.g. same cron job, same report type, same command). If the user had said "Needs improvement" on a previous task, the counter for that context was already reset—only consecutive "good" answers count toward the target.
  4. Repeat this learning behavior on every future completion of the same task type until the counter reaches 
    GOOD_APPROVAL_TARGET
    .
  5. Once target is reached, treat pattern as learned and reduce prompt frequency:
    • Ask "what was good" only when task type changes, quality drops, or periodic recalibration is needed.
  6. Counter reset: If the user says "Needs improvement" for this task type/context, reset the good-approval counter to 0 for that context so that the next "good" answers start a new consecutive run toward the target.
  1. 在同一轮对话中询问：
    本次输出的哪些方面符合您的预期？
  2. 记录用户的正向反馈点（质量、格式、风格、速度、清晰度等）。
  3. 针对该任务类型/上下文（如同一cron作业、同一报告类型、同一命令）的连续良好认可计数器加1。若用户此前对该上下文的任务回复过“需要改进”，则该上下文的计数器已重置——只有连续的“良好”回复才会计入目标次数。
  4. 未来每次完成同一类型任务时，重复此学习行为，直至计数器达到
    GOOD_APPROVAL_TARGET
    。
  5. 达到目标后，将该模式标记为已学习，并降低提示频率：
    • 仅当任务类型变更、质量下降或需要定期重新校准，才询问“哪些方面符合预期”。
  6. 计数器重置规则：若用户对该任务类型/上下文回复“需要改进”，则将该上下文的良好认可计数器重置为0，后续的“良好”回复将重新开始累计，向目标次数推进。

Branch B: User says "Needs improvement"

分支B：用户回复“需要改进”

Run a structured learning loop using multiple-choice questions first, then free-text refinement.
  1. Collect improvement intent in three dimensions:
    • Why it needs improvement.
    • How it should be improved.
    • What context/styling should change.
  2. Ask for examples if possible.
  3. Classify severity and set iteration cap.
  4. Resolve with web research and iterative reasoning.
  5. Apply changes in the next similar output.
  6. Ask feedback again after completion.
运行结构化学习循环，先通过选择题收集信息，再通过自由文本细化需求。
  1. 从三个维度收集改进需求：
    • 为何需要改进。
    • 应如何改进。
    • 哪些上下文/样式需要调整。
  2. 尽可能请求用户提供示例。
  3. 划分问题严重程度，并设置迭代上限。
  4. 通过网络搜索和迭代推理解决问题。
  5. 在下次同类输出中应用调整。
  6. 完成调整后的任务后再次询问反馈。

Multiple-Choice Collection Template

选择题收集模板

Use 
AskQuestion
when available.
若支持
AskQuestion
工具，可使用该工具。

Why It Needs Improvement

为何需要改进

Options:
  • Incorrect or incomplete result
  • Wrong format or structure
  • Too slow or inefficient
  • Wrong tone or style
  • Missing context or assumptions
  • Other (user specifies)
选项：
  • 结果不正确或不完整
  • 格式或结构有误
  • 速度过慢或效率低下
  • 语气或风格不符
  • 缺少上下文或假设条件
  • 其他（用户自行说明）

How It Should Improve

应如何改进

Options:
  • More detail/depth
  • Less detail/more concise
  • Different structure/order
  • Different method/tooling
  • Stronger validation or checks
  • Other (user specifies)
选项：
  • 增加细节/深度
  • 简化内容/更简洁
  • 调整结构/顺序
  • 更换方法/工具
  • 加强验证或检查
  • 其他（用户自行说明）

What Context/Styling Should Improve

哪些上下文/样式需要调整

Options:
  • Code style/conventions
  • Output format (markdown, JSON, table, prose)
  • Terminology/domain language
  • Length/scope boundaries
  • Audience/tone expectations
  • Other (user specifies)
Then ask:
If you can share an example of the desired output/style, please provide one.
选项：
  • 代码风格/规范
  • 输出格式（Markdown、JSON、表格、 prose）
  • 术语/领域语言
  • 篇幅/范围边界
  • 受众/语气预期
  • 其他（用户自行说明）
随后询问：
如果您能提供期望的输出/风格示例，请分享给我们。

Severity Metric And Iteration Control

严重程度指标与迭代控制

Classify the issue from the user's why/how/what (or ask briefly if unclear):
  • Slight: minor wording/format/style adjustments -> max 5 iterations
  • Medium: structural/depth/method changes -> max 10 iterations
  • Severe: fundamental or repeated failures -> max 20 iterations
Track learning loops per issue signature (
why + how + what + context
). One iteration = one full cycle: apply the learning → deliver revised output → ask "Good or needs improvement?" again. If the user then says "Good," that improvement issue is closed (and the good-approval path applies for that task). If they say "Needs improvement" again for the same issue, that counts as the next iteration.
  • If under cap: continue iterative refinement (apply → ask feedback again).
  • If cap reached: summarize lessons learned, stop iterating on that issue, and continue normal feedback prompts (still ask "Good or needs improvement?" after subsequent tasks).
根据用户反馈的原因、改进方式和调整方向（若不明确可简短询问）划分问题严重程度：
  • 轻微：措辞/格式/风格的微小调整 → 最多5次迭代
  • 中等：结构/深度/方法的变更 → 最多10次迭代
  • 严重：根本性或重复性失败 → 最多20次迭代
针对每个问题特征（
原因+改进方式+调整方向+上下文
）跟踪学习循环。一次迭代指完整的周期：应用改进 → 交付修订后的输出 → 再次询问“是否良好或需要改进？”。若用户回复“良好”，则该改进问题关闭（后续该任务将遵循良好认可路径）。若用户针对同一问题再次回复“需要改进”，则计入下一次迭代。
  • 未达上限：继续迭代优化（应用改进 → 再次询问反馈）。
  • 达到上限：总结已学到的经验，停止针对该问题的迭代，后续任务仍会正常发送反馈提示（完成后仍询问“是否良好或需要改进？”）。

Why-How-What Resolution Requirement

原因-方式-方向改进要求

When implementing improvements, always state:
  • Why this change is needed.
  • How it will be changed (concrete steps).
  • What context/styling constraints are being applied.
Use web search when external references improve correctness. Use iterative thinking to test and refine assumptions before final output.
实施改进时，必须说明：
  • 为何需要进行此变更。
  • 具体将如何调整（明确步骤）。
  • 应用了哪些上下文/样式约束。
若外部参考能提升正确性，可使用网络搜索。在生成最终输出前，使用迭代思维测试和细化假设。

UX Safety Rules

用户体验安全规则

  • Never spam feedback prompts.
  • Never interrupt active user workflows for feedback.
  • Keep prompts concise and predictable.
  • Do not require UI or product changes; this is a conversational behavior layer.
  • 切勿频繁发送反馈提示。
  • 切勿在用户活跃工作流程中插入反馈请求。
  • 提示需简洁且可预测。
  • 无需修改UI或产品；这是一个对话行为层。

Lightweight Output Pattern

轻量化输出模式

After task completion:
  1. Completion line.
  2. Single feedback question.
  3. Optional one follow-up block only if user chooses "Needs improvement."
任务完成后：
  1. 任务完成提示行。
  2. 单个反馈问题。
  3. 仅当用户选择“需要改进”时，才显示可选的后续内容块。

Additional Resources

额外资源

  • Detailed question sets and example forms: reference.md
  • 详细问题集和示例表单：reference.md