engineering-cybernetics-user-habit-learning

name	engineering-cybernetics-user-habit-learning
description	从工程控制论学习用户习惯的建模、辨识、反馈、稳定性、能观测性、能控性、时滞、随机系统、自适应、容错和大系统方法出发分析对话，将稳定的用户习惯、产品规则与可验证架构事实分开，并生成带证据清单、生命周期和前向评估的候选 Skill。适用于复盘长期对话、学习工作方式、处理冲突反馈、建立闭环执行规则或生成和更新个性化 Skill 的场景。

工程控制论学习用户习惯

任务

• 把对话视为随轮次演化、存在噪声和时滞的受控系统，不把控制论只当作修辞类比。
• 先建立状态、观测、控制动作、扰动和验收信号，再决定哪些规则值得长期保存。
• 分开记录用户偏好、产品规则、架构事实、安全边界和待确认假设，避免不同生命周期的知识互相污染。
• 为每条长期规则保留脱敏证据摘要、反证、适用范围、验证方法和复审条件。
• 生成可供审查和前向测试的候选 Skill；获得明确写入要求且实际写入成功后，才能说明已经保存或安装。
• 默认使用中文说明；代码标识、文件名和协议字段按目标系统要求使用英文。

按需读取参考资料

• 需要定位全书 21 章的理论来源时，读取 references/engineering-cybernetics-core.md。
• 需要把理论转化为状态方程、控制表、稳定条件或容错路径时，读取 references/operational-control-model.md。
• 需要分析对话、证据强度、冲突反馈或隐私边界时，读取 references/dialogue-control-and-habit-learning.md。
• 需要记录知识类型、证据账本、偏好衰减和生命周期时，读取 references/evidence-and-lifecycle.md。
• 需要决定 Skill 目录、拆分粒度、目标格式和逐文件内容时，读取 references/skill-generation-spec.md。
• 需要评估生成结果是否真的改善执行时，读取 references/forward-evaluation.md。
• 当前调用环境无法读取参考文件时，仍执行下述主流程，但必须把缺少的验证标为未完成。

闭环分析流程

1. 选择样本和系统边界

1. 明确分析的是整段对话、选定轮次、单个项目还是跨项目历史。
2. 确定目标状态、受控对象、输入、输出、质量指标和停止条件。
3. 排除账号、路径、密钥、固定版本和临时故障等不可复用信息。
4. 不把系统边界扩大到未经用户授权的身份、人格和动机推断。

2. 建立可操作控制模型

对复杂任务先填写控制表：

字段	必须回答的问题
目标状态	用户最终能观察到什么结果？
状态变量	哪些进度、文件、进程、页面或规则会演化？
观测量	什么证据足以判断当前状态？
控制动作	哪些动作真的能改变目标状态？
扰动与噪声	哪些外部因素或弱信号不应误导规则？
时滞	动作之后多久才能获得可靠反馈？
稳定条件	什么现象说明系统不会再次偏离？
兜底路径	主通道失败时有什么独立替代方案？

先保证能观测和能控制，再自动化。不能用中间信号代替最终输出。

3. 分类知识和证据

把候选信息标为以下类型之一：

• preference：用户跨任务保持的工作偏好。
• product-rule：特定产品应维持的行为不变量。
• architecture：当前源码或环境中可验证、但可能随版本变化的事实。
• safety-policy：保护数据、权限、发布和外部影响的边界。
• hypothesis：尚未达到长期规则门槛的推断。

按 A/B/C 证据等级评估，并同时查找反证。重复发送、沉默、网络断开和同一事件的重复描述不能计算为独立证据。

4. 估计稳定习惯

满足以下任一条件才进入活动规则：

• 用户明确声明长期偏好，且没有后续冲突。
• 同一规律在至少两个独立场景中重复，并能转化为可执行动作。
• 高风险纠偏得到用户明确要求，并具有清晰验证信号。

每条活动规则必须记录：适用范围、证据摘要、置信度、反证、验证方法和复审条件。没有证据账本的规则只能作为候选假设。

5. 处理冲突、时滞和概念漂移

• 最新明确指令控制当前任务，但不自动抹除旧证据。
• 相反要求可能是场景差异时，形成带条件的分支规则，不强行选出全局偏好。
• 同一长期规则连续出现两次明确反向反馈时，将其降级为 stale 并请求或等待新的稳定证据。
• 架构事实在源码结构、依赖、打包方式或数据格式变化后必须重新验证。
• 用户尚未看到结果或工具仍在运行时，把反馈记为延迟状态，不提前判定成功。

6. 设计 Skill 和控制策略

1. 先选择能产生清晰反馈的最小动作，再根据结果更新下一动作。
2. 用长期目标、阶段目标、当前动作和验证信号形成分层控制。
3. 把用户偏好放在主 Skill，把易变化的产品与架构知识放在 references，把确定性操作放在 scripts。
4. 一个主题过宽、子流程能独立触发或生命周期明显不同时，拆成多个 Skill；不要生成无法维护的项目百科全书。
5. 为核心失败准备独立兜底，重复失败后改变控制路径而不是机械重试。

7. 生成、评估和维护

• 生成目录、SKILL.md、目标系统配置、按需资源以及 extras/generation-manifest.json。
• 使用目标平台实际支持的 frontmatter 和配置目录；记录兼容性，不声称未经测试的平台可用。
• 先做结构和隐私检查，再用至少三个代表性场景进行前向评估。
• 比较首次正确率、纠正次数、未验证声明、越界动作和验收覆盖率。
• 只有达到质量门槛时才标为 active；否则保持 candidate 并列出失败场景。
• 新证据只更新对应规则和清单；规则失效时标为 stale 或 deprecated，不要静默删除历史判断。

输出顺序

1. 系统目标与样本边界
2. 控制状态表
3. 知识分类
4. 稳定证据、反证与冲突
5. 当前任务约束和被过滤信号
6. 候选 Skill 目录与逐文件内容
7. 证据清单和生命周期状态
8. 前向评估结果
9. 仍需确认或复审的规则

不要把分析过程伪装成磁盘结果。只有工具确认写入、校验和目标应用扫描成功后，才能报告已经创建或覆盖。

隐私和安全边界

• 删除密钥、令牌、密码、账号、邮箱、电话、精确路径和私人身份信息。
• 不保存大段原始对话；证据清单只保留改变规则判断所需的脱敏摘要。
• 不根据语言风格推断敏感属性、人格或动机。
• 不把平台政策和工程安全边界伪装成用户个人偏好。
• 不因一次满意形成永久规则，不因一次失败形成永久禁止。

质量检查

• 是否建立了目标、状态、观测、控制、扰动、时滞、稳定条件和兜底路径。
• 是否区分了五类知识及其不同复审周期。
• 每条活动规则是否有证据、反证、范围、验证和复审条件。
• 是否将相互矛盾的要求转换为条件规则或待确认项。
• 是否选择了合适的 Skill 粒度并避免主文件过度膨胀。
• 是否完成隐私过滤、结构校验和代表性前向测试。
• 是否能让另一个没有当前对话背景的 AI 独立执行并知道何时停止。