菜单
用“系统工程 + 工程控制论 + 总体设计（GDA）”的方法做软件工程闭环控制。 适用：真实代码库中的 bugfix、feature、refactor、性能、迁移、事故复盘、测试设计、架构审计、门禁验证。 尤其适合：问题复杂、跨模块、需要最小可验证变更、需要离线/在线双层验证、需要防止“测试全绿但真实环境失败”的任务。 不适用：纯知识问答、翻译、创作、一次性聊天建议、无需验证的单句结论。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
用"系统工程 + 工程控制论 + 总体设计（GDA）"的方法做软件工程闭环控制。 路由式三层加载：薄入口 → 按任务类型匹配自包含协议 → 按需深读。 覆盖工程语义闭环、性能与并发控制、遗留代码安全变更的完整军火库。 适用：真实代码库中的 bugfix、feature、refactor、性能、迁移、事故复盘、测试设计、架构审计、门禁验证。 尤其适合：问题复杂、跨模块、需要最小可验证变更、需要离线/在线双层验证、需要防止"测试全绿但真实环境失败"的任务。 不适用：纯知识问答、翻译、创作、一次性聊天建议、无需验证的单句结论。
将复杂开发任务放入“harness 优先”的执行框架，规范代理在真实工具链中的自主执行、人机协作与主动求助。用于需要在代码库中持续迭代并以测试/日志/CI 为证据交付的场景，尤其适合长链路排障、跨模块修复、权限受限环境、CI 失败修复和需要明确“何时请求人工决策”的任务。
| name | cybernetic-systems-engineering |
| description | 用“系统工程 + 工程控制论 + 总体设计（GDA）”的方法做软件工程闭环控制。 适用：真实代码库中的 bugfix、feature、refactor、性能、迁移、事故复盘、测试设计、架构审计、门禁验证。 尤其适合：问题复杂、跨模块、需要最小可验证变更、需要离线/在线双层验证、需要防止“测试全绿但真实环境失败”的任务。 不适用：纯知识问答、翻译、创作、一次性聊天建议、无需验证的单句结论。 |
把软件开发当作一个闭环控制系统来做：
本 skill 的目标不是“让你会用控制论术语”，而是让你在复杂工程任务中：
CSE 不只处理“当前这一条任务怎么修”，还要先回答“这个项目由谁控制、在哪一层控制、跨模块如何协调”。
从控制层级看，CSE 默认同时存在两套闭环：
如果只建立任务级闭环，而没有项目级控制拓扑，常见结果是：
因此在以下场景，必须先补项目级控制拓扑，再进入具体修复：
项目级控制拓扑至少要回答四个问题：
为了避免“看起来只是改一行代码，实际上改穿了整个系统”，复杂任务开始前必须先识别本次改动主要落在哪一面：
默认要求：
一个典型例子：
如果主落点都判断不清，默认先不要改实现，而是先补控制结构说明。
复杂性不会凭空消失，只会被下沉、上浮或转移到别处。
因此每次声称“系统更简单了”时，都应至少记一条复杂性转移账本：
| 字段 | 说明 |
|---|---|
| 复杂性原位置 | 复杂性原来压在哪一层、哪个模块、哪条链路 |
| 新位置 | 复杂性被转移到了哪里 |
| 收益 | 本次转移换来了什么 |
| 新成本 | 新增了什么依赖、运维成本或观测成本 |
| 失效模式 | 转移后最可能新增什么故障模式 |
典型例子：
项目级控制拓扑的默认治理协议如下：
| 角色 | 默认职责 | 有权决定什么 | 无权单独决定什么 |
|---|---|---|---|
| 总体设计部 | 维护项目级参考输入、关键边界、升级路径与最终裁决 | 跨模块优先级、冻结边界、变更窗口、最终 gate 口径 | 直接跳过模块 owner 的局部约束与证据 |
| 模块 owner | 维护本模块不变量、主链入口与回归边界 | 模块内部实现、局部回归、局部重构 | 擅自改共享接口、共享状态、共享门禁 |
| 共享边界 owner | 维护共享 API、schema、队列、缓存、统一门禁等共享事实源 | 共享契约演化节奏、兼容窗口、迁移前置条件 | 在未通知受影响模块时直接改共享契约 |
按风险从低到高，默认这样升级：
以下任一对象在本轮默认视为冻结边界，不能顺手改写：
要解冻这些边界，至少要同时满足：
凡是跨模块变更，最终裁决责任默认不属于“谁先改代码”，而属于总体设计部。
它至少要回答：
如果这些问题答不出来，默认结论不是“继续改”，而是：
后续章节中的 Control Contract、GDA 四步法、传感器工程与验证分层，都是建立在这层项目级控制拓扑之上执行的。
以下任一场景，优先使用本 skill：
如果任务时间跨度长、步骤多、存在中断恢复需求，应同时配合 harness 使用。
执行任务时必须同时考虑以下五个维度：
第一性原理
公理化思维
多模型思维
类比迁移
反馈与验证
详细方法论与例子见：
references/gda-framework.md在真正改代码前，先产出一个极短的控制合同 v2（可在回复、计划或审计文档里）：
如果用户没给验收标准，先从：
中提炼；仍缺失时，补最小合理验收。
开始前必须回答：
至少同时建立以下三个模型中的两个，复杂任务必须三个都建：
复杂任务还应显式补一个黑盒输入-输出影响矩阵：
如果系统是多变量耦合的，再补一个解耦矩阵：
一个典型例子：
默认规则：
一次只施加一个最小控制输入：
如果出现振荡：
验证必须分层：
原则：
默认顺序：
git status / git diff如果信号不稳定：
凡是涉及以下任一因素：
PG_CH / 真实 broker / 真实文件系统 / 真实扩展加载都必须明确区分：
禁止把：
直接写成：
性能和稳定性问题默认先审查观测质量，而不是先改实现。
必须显式检查：
默认规则：
很多系统不是“控制能力不足”，而是“控制动作太频繁”。
默认要检查四种抑振手段：
执行规则：
当系统已经进入震荡区，继续叠加控制器通常只会把问题放大。
默认规则：
任何性能或稳定性优化，默认都要先拿到观测基线。
最小入场券：
默认规则：
当多个方案都能修时，优先：
特别注意：
默认优先设计“生成策略的机制”，而不是把人的经验直接硬编码成静态策略。
默认禁止把以下对象直接写死成“经验常数”后就当作稳定设计：
优先选择的机制包括但不限于：
裁决规则：
例外条件：
对现代复杂系统，默认优先级不是“尽量永不出错”，而是“出错后多快回到安全状态”。
默认裁决：
执行规则：
Recovery Target 不是装饰项，必须给出恢复时间预算或安全回退时限特别注意：
抽象的默认目标不是“减少重复”，而是“减少错误耦合”。
默认原则：
判定规则：
反过来说：
复杂系统默认不是被一次性设计出来的，而是从简单可用系统逐步长出来的。
默认原则：
执行规则：
桥接期协议：
如果一个方案：
那它默认不是成熟的演进式架构方案
假收敛
双真相
影子实现
弱断言
is_ok()，没有行为语义断言测试驱动代码偏离职责
pub 面把离线测试当 gate
最终交付优先按下面结构组织：
其中：
如果是长任务，还应同步：
如果需要更完整的理论和场景化方法，请按需读取：
references/gda-framework.md
references/README.md
assets/quickstart.md