嵌入式
系统全景

0.1.1 产品里的计算

先问什么：“产品里的计算”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是把温度、按键、门锁、风扇等功能还原成输入、状态与输出的闭环，目标是把它拆成可以复述的对象、条件和结果。围绕“以门锁从读卡、验证、开锁到重新上锁的过程为例”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“以门锁从读卡、验证、开锁到重新上锁的过程为例”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“产品里的计算”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.1.2 它不是什么

先问什么：“它不是什么”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是区分嵌入式系统、裸机程序、桌面程序、云端服务和开发板演示，目标是把它拆成可以复述的对象、条件和结果。围绕“比较网页刷新、云端重试与执行器误动作的不同后果”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“比较网页刷新、云端重试与执行器误动作的不同后果”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“它不是什么”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "嵌入式是什么", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“嵌入式是什么”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.1.3 设备、固件与应用

先问什么：“设备、固件与应用”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是把用户看到的产品、芯片上的固件和外围应用放在不同层级，目标是把它拆成可以复述的对象、条件和结果。围绕“用空调的温度控制和手机配套应用说明职责如何分开”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用空调的温度控制和手机配套应用说明职责如何分开”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“设备、固件与应用”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.1.4 输入、状态与输出

先问什么：“输入、状态与输出”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是把一个模糊功能改写成可以回放和检查的状态机，目标是把它拆成可以复述的对象、条件和结果。围绕“从按键电平、候选值、稳定值到 LED 事件逐步展开”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“从按键电平、候选值、稳定值到 LED 事件逐步展开”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“输入、状态与输出”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.1.5 时间和后果

先问什么：“时间和后果”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是理解嵌入式软件为什么必须在具体时间内影响真实对象，目标是把它拆成可以复述的对象、条件和结果。围绕“对照门锁、充电保护和电机停止三个截止时间不同的场景”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“对照门锁、充电保护和电机停止三个截止时间不同的场景”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“时间和后果”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.1.6 能力、行为与可靠性

先问什么：“能力、行为与可靠性”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是区分系统能做什么、一次运行表现如何以及失败时是否可控，目标是把它拆成可以复述的对象、条件和结果。围绕“用板载 LED 一次点亮不能证明长期可靠的反例来说明”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用板载 LED 一次点亮不能证明长期可靠的反例来说明”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“能力、行为与可靠性”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.1.7 写一张系统卡

先问什么：“写一张系统卡”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是用对象、输入、状态、输出、约束和证据六列描述设备行为，目标是把它拆成可以复述的对象、条件和结果。围绕“把一个陌生传感器功能写成下一位读者可以复核的卡片”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把一个陌生传感器功能写成下一位读者可以复核的卡片”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“写一张系统卡”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.1.8 阅读陌生设备

先问什么：“阅读陌生设备”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是建立从产品说明、用户手册、原理图到主机模型的阅读顺序，目标是把它拆成可以复述的对象、条件和结果。围绕“面对没有接触过的开发板时先列出已知、未知和停止条件”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“面对没有接触过的开发板时先列出已知、未知和停止条件”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“阅读陌生设备”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.1.9 本节练习：画自己的系统坐标系

先问什么：“本节练习：画自己的系统坐标系”不是孤立的步骤，而是观察家电、交通工具、仪器和可穿戴设备的入口。本小节的焦点是把一个日常设备放进输入、状态、输出、约束和证据五个坐标，目标是把它拆成可以复述的对象、条件和结果。围绕“选择手表、门锁或风扇，写出一条可观察的最小行为”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“它处理什么输入，改变什么现实对象？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对嵌入式是什么而言，嵌入式系统、微控制器（MCU）、固件、边界和产品行为不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“选择手表、门锁或风扇，写出一条可观察的最小行为”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：桌面程序追求通用资源，云端服务追求弹性，嵌入式系统必须把软件行为落到固定的电源、传感器、执行器和时间约束中。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把芯片型号、开发板照片或宣传参数当成嵌入式系统本身，忽略供电、复位、采样和执行器边界。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下产品说明、对象清单、输入输出系统卡和一个可以在主机上回放的最小行为模型。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。用对象、输入、输出、约束和证据描述一个陌生设备，而不是先背 SDK API。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：画自己的系统坐标系”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.2.1 输入和输出

先问什么：“输入和输出”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是说明传感器、按钮、通信帧如何进入系统，以及动作、指示和日志如何离开系统，目标是把它拆成可以复述的对象、条件和结果。围绕“沿着温度传感器到风扇控制的路径列出每个数据形态”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“沿着温度传感器到风扇控制的路径列出每个数据形态”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“输入和输出”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.2.2 硬件边界

先问什么：“硬件边界”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是把电平、极性、引脚复用、供电和外设寄存器集中在边界层，目标是把它拆成可以复述的对象、条件和结果。围绕“比较同一个按键在上拉和下拉两块开发板上的实现差异”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“比较同一个按键在上拉和下拉两块开发板上的实现差异”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“硬件边界”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "物理与软件层", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“物理与软件层”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.2.3 启动、时钟与复位

先问什么：“启动、时钟与复位”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是理解启动文件、时钟树、复位原因和初始化顺序怎样决定后续行为，目标是把它拆成可以复述的对象、条件和结果。围绕“从上电到 main 函数画出最小启动时间线”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“从上电到 main 函数画出最小启动时间线”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“启动、时钟与复位”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.2.4 驱动与 HAL

先问什么：“驱动与 HAL”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是区分寄存器操作、驱动接口、硬件抽象层和应用规则各自的职责，目标是把它拆成可以复述的对象、条件和结果。围绕“把 GPIO 读取封装成可在主机模型中替换的接口”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把 GPIO 读取封装成可在主机模型中替换的接口”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“驱动与 HAL”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.2.5 应用状态机

先问什么：“应用状态机”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是让业务规则只依赖稳定接口，而不是散落在中断和寄存器访问中，目标是把它拆成可以复述的对象、条件和结果。围绕“用门锁或按键示例说明状态转移和输出动作如何分开”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用门锁或按键示例说明状态转移和输出动作如何分开”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“应用状态机”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.2.6 日志、测量与诊断

先问什么：“日志、测量与诊断”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是建立从底层故障到上层现象的可观察路径，避免只留下一个成功截图，目标是把它拆成可以复述的对象、条件和结果。围绕“为通信超时设计错误码、时间戳和最后正常状态”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为通信超时设计错误码、时间戳和最后正常状态”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“日志、测量与诊断”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.2.7 层间合同

先问什么：“层间合同”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是给每层写输入、输出、单位、错误值和所有权，明确什么事实不能跨层假定，目标是把它拆成可以复述的对象、条件和结果。围绕“把 ADC 原始计数转换成应用温度时列出校准和范围边界”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把 ADC 原始计数转换成应用温度时列出校准和范围边界”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“层间合同”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.2.8 本节练习：画数据流

先问什么：“本节练习：画数据流”不是孤立的步骤，而是观察从传感器和电源到应用状态的完整设备链的入口。本小节的焦点是画一张从物理输入到产品输出的分层图，并为每层指定一个证据，目标是把它拆成可以复述的对象、条件和结果。围绕“选择一个公开开发板功能，标出主机可验证和目标机才可验证的部分”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“设备中的每一层分别负责什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对物理与软件层而言，硬件、启动代码、驱动、硬件抽象层（HAL）、应用和观测接口不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“选择一个公开开发板功能，标出主机可验证和目标机才可验证的部分”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：同一业务动作可能经过电气网络、寄存器、驱动接口、状态机和用户可见输出多个层次。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把应用层的布尔值当作引脚真实状态，或把驱动返回成功当作传感器已经可信。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下分层图、输入输出表、边界接口、日志字段和按层定位的失败记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先定位问题所在层，再决定查原理图、数据手册、驱动、应用状态还是测量记录。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：画数据流”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.3.1 时间预算

先问什么：“时间预算”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是把及时、快速和实时改写成采样周期、响应上限、截止时间和超时动作，目标是把它拆成可以复述的对象、条件和结果。围绕“为按键、通信和电机停止分别写一条带单位的时间约束”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为按键、通信和电机停止分别写一条带单位的时间约束”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“时间预算”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.3.2 内存与存储

先问什么：“内存与存储”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是区分 Flash、RAM、栈、堆、缓冲区和日志空间，并为它们保留余量，目标是把它拆成可以复述的对象、条件和结果。围绕“用一次大报文和多个并发事件说明缓冲区为什么会耗尽”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用一次大报文和多个并发事件说明缓冲区为什么会耗尽”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“内存与存储”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "时间、资源与故障", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“时间、资源与故障”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.3.3 功耗与热

先问什么：“功耗与热”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是理解待机、唤醒、峰值电流、散热和电池寿命如何进入软件需求，目标是把它拆成可以复述的对象、条件和结果。围绕“比较周期采样、外部中断和持续轮询对能量账本的影响”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“比较周期采样、外部中断和持续轮询对能量账本的影响”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“功耗与热”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.3.4 并发与吞吐

先问什么：“并发与吞吐”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是把事件频率、服务时间、队列长度和处理能力放在同一条时间线上，目标是把它拆成可以复述的对象、条件和结果。围绕“分析传感器生产速度超过任务消费速度时会发生什么”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“分析传感器生产速度超过任务消费速度时会发生什么”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“并发与吞吐”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.3.5 故障与降级

先问什么：“故障与降级”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是为超时、资源不足、输入异常和外设失联定义可接受的退化行为，目标是把它拆成可以复述的对象、条件和结果。围绕“说明网关断网时缓存、重试、只读和停止分别适用于什么场景”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“说明网关断网时缓存、重试、只读和停止分别适用于什么场景”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“故障与降级”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.3.6 把形容词改成数字

先问什么：“把形容词改成数字”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是学会追问稳定、低延迟、省电和高可靠背后的测量口径，目标是把它拆成可以复述的对象、条件和结果。围绕“把‘低功耗’改成平均电流、峰值电流、唤醒周期和测试时长”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把‘低功耗’改成平均电流、峰值电流、唤醒周期和测试时长”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“把形容词改成数字”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.3.7 约束表与取舍

先问什么：“约束表与取舍”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是用预算表表达性能、成本、复杂度和安全之间的取舍，而不是只追求单项最优，目标是把它拆成可以复述的对象、条件和结果。围绕“比较提高采样率、增加缓存和降低频率三种方案的连锁影响”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“比较提高采样率、增加缓存和降低频率三种方案的连锁影响”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“约束表与取舍”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.3.8 本节练习：写一张预算卡

先问什么：“本节练习：写一张预算卡”不是孤立的步骤，而是观察有限 RAM、固定时钟、低功耗目标和不能无限重试的控制回路的入口。本小节的焦点是为一个小型控制功能写出时间、资源、功耗和故障四类预算，目标是把它拆成可以复述的对象、条件和结果。围绕“明确每项预算的证据、余量和超过上限后的停止或降级动作”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么嵌入式需求必须写成约束？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对时间、资源与故障而言，deadline、延迟、吞吐、内存预算、功耗预算、降级和故障状态不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“明确每项预算的证据、余量和超过上限后的停止或降级动作”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：电脑程序常可等待资源或扩容，设备却可能在下一次采样、通信窗口或安全动作前必须完成。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只写“要快、要稳定、要省电”，没有单位、窗口、上限、失败动作和验证方法。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下约束表、时间预算、资源预算、异常路径和最小可接受行为。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。把形容词改写成可以观察、计时、计数或复盘的判据。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：写一张预算卡”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.1 输入声明

先问什么：“输入声明”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是写清数据来源、格式、单位、有效范围、极性和缺省值，目标是把它拆成可以复述的对象、条件和结果。围绕“把‘按下按钮’改成带采样周期和有效电平的输入条款”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把‘按下按钮’改成带采样周期和有效电平的输入条款”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“输入声明”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.2 状态建模

先问什么：“状态建模”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是用有限状态和明确转移条件表示跨周期保存的事实，目标是把它拆成可以复述的对象、条件和结果。围绕“用锁定、等待、打开和故障四个状态描述门锁行为”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用锁定、等待、打开和故障四个状态描述门锁行为”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“状态建模”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "行为合同", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“行为合同”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.4.3 输出语义

先问什么：“输出语义”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是说明输出是动作、指示、记录还是对外接口，并注明极性和持续时间，目标是把它拆成可以复述的对象、条件和结果。围绕“区分 LED 亮、继电器吸合和日志记录这三种完全不同的结果”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“区分 LED 亮、继电器吸合和日志记录这三种完全不同的结果”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“输出语义”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.4 时序规则

先问什么：“时序规则”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是把顺序、等待、超时、重复触发和取消写进合同，而不是留给实现者猜，目标是把它拆成可以复述的对象、条件和结果。围绕“为一次通信请求写出发送、等待、重试和放弃的时间线”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为一次通信请求写出发送、等待、重试和放弃的时间线”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“时序规则”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.5 错误路径

先问什么：“错误路径”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是为非法输入、资源不足、断线、复位和内部错误指定状态与可观察线索，目标是把它拆成可以复述的对象、条件和结果。围绕“说明温度传感器返回越界值时应拒绝、降级还是关闭执行器”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“说明温度传感器返回越界值时应拒绝、降级还是关闭执行器”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“错误路径”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.6 验收断言

先问什么：“验收断言”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是让每个需求都能转成输入、预期输出和可复核的断言，目标是把它拆成可以复述的对象、条件和结果。围绕“为正常、边界、错误和恢复四类样例各写一个最小断言”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为正常、边界、错误和恢复四类样例各写一个最小断言”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“验收断言”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.7 版本化合同

先问什么：“版本化合同”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是把板卡型号、固件版本、配置、依赖和合同变更一起记录，目标是把它拆成可以复述的对象、条件和结果。围绕“解释为什么同一功能换一块板或一个引脚极性就需要新版本”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“解释为什么同一功能换一块板或一个引脚极性就需要新版本”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“版本化合同”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.8 一个完整合同示例

先问什么：“一个完整合同示例”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是把按键到 LED 的规则整理成一张可以直接测试的行为表，目标是把它拆成可以复述的对象、条件和结果。围绕“同时列出原始采样、稳定事件、输出动作和复位默认状态”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“同时列出原始采样、稳定事件、输出动作和复位默认状态”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“一个完整合同示例”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.4.9 本节练习：让另一个人复述

先问什么：“本节练习：让另一个人复述”不是孤立的步骤，而是观察按键、温度、门锁或通信输入进入状态机后触发输出的入口。本小节的焦点是把一项功能交给没有上下文的读者，只凭合同判断能否实现和验收，目标是把它拆成可以复述的对象、条件和结果。围绕“保留对方提出的歧义，把它们改写成合同字段而非口头解释”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样让需求变成可验证的固件行为？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对行为合同而言，输入、前置条件、状态、输出、超时、错误处理、验收判据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“保留对方提出的歧义，把它们改写成合同字段而非口头解释”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：“按下后亮灯”只是愿望；合同还要说明极性、去抖、时限、复位默认值和异常时的安全动作。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把成功路径写得很清楚，却没有定义浮空、超时、断线、复位或输入不可信时怎么办。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下合同表、状态转移表、正常/边界/错误样例和行为日志。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。任何功能先写输入—状态—输出—失败—证据五列，再写实现代码。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：让另一个人复述”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.5.1 构建

先问什么：“构建”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是区分源代码检查、编译、链接、生成制品和测试各自提供的证据，目标是把它拆成可以复述的对象、条件和结果。围绕“从一个 Python 主机模型类比到 Cortex-M 固件的构建阶段”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“从一个 Python 主机模型类比到 Cortex-M 固件的构建阶段”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“构建”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.5.2 链接与制品

先问什么：“链接与制品”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是理解 ELF、BIN、HEX、map、链接脚本和地址布局之间的关系，目标是把它拆成可以复述的对象、条件和结果。围绕“说明一个构建成功的二进制为什么还不能证明它适合当前板卡”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“说明一个构建成功的二进制为什么还不能证明它适合当前板卡”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“链接与制品”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "构建、烧录与启动", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“构建、烧录与启动”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.5.3 烧录

先问什么：“烧录”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是把调试器选择、目标识别、擦除、写入、校验和复位分成独立步骤，目标是把它拆成可以复述的对象、条件和结果。围绕“为一块官方开发板写出可重复的烧录记录字段”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为一块官方开发板写出可重复的烧录记录字段”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“烧录”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.5.4 调试器与复位

先问什么：“调试器与复位”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是解释连接成功、暂停 CPU、复位运行和程序行为之间的证据差别，目标是把它拆成可以复述的对象、条件和结果。围绕“分析下载后停在断点、看门狗复位和冷启动三种现象”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“分析下载后停在断点、看门狗复位和冷启动三种现象”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“调试器与复位”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.5.5 启动阶段

先问什么：“启动阶段”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是观察向量表、时钟、内存初始化、外设配置到应用入口的先后顺序，目标是把它拆成可以复述的对象、条件和结果。围绕“用 LED 默认关闭和串口首条日志判断启动是否越过某个阶段”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用 LED 默认关闭和串口首条日志判断启动是否越过某个阶段”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“启动阶段”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.5.6 目标机观察

先问什么：“目标机观察”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是选择板载 LED、按钮、串口或调试寄存器作为低风险观察点，目标是把它拆成可以复述的对象、条件和结果。围绕“把‘灯亮了’补充成带固件、板卡、输入序列和时间条件的记录”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把‘灯亮了’补充成带固件、板卡、输入序列和时间条件的记录”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“目标机观察”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.5.7 证据链与失败复盘

先问什么：“证据链与失败复盘”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是让构建、制品、烧录、启动和合同验收各自留下可交接的证据，目标是把它拆成可以复述的对象、条件和结果。围绕“把一次失败定位到链路中的断点，而不是重复点击按钮”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把一次失败定位到链路中的断点，而不是重复点击按钮”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“证据链与失败复盘”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.5.8 本节练习：写一次交付记录

先问什么：“本节练习：写一次交付记录”不是孤立的步骤，而是观察源代码经过编译、链接、生成制品，再被调试器写进目标板的入口。本小节的焦点是从干净目录记录命令、版本、输出、失败和限制，形成陌生读者可照做的流程，目标是把它拆成可以复述的对象、条件和结果。围绕“同时写出主机路径和没有目标板时的停止边界”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“工具链每一步究竟证明了什么？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对构建、烧录与启动而言，编译、链接、ELF、BIN、HEX、map、烧录、复位和调试不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“同时写出主机路径和没有目标板时的停止边界”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：构建成功是软件制品证据，烧录成功是传输证据，启动和合同才是目标机行为证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 IDE 的绿色提示当成程序已运行，或跳过目标选择、链接脚本、启动文件和复位条件。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下命令、版本、构建日志、制品哈希、烧录日志、复位现象和行为记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。沿着制品和证据链定位失败，而不是重新点击 Build/Flash 直到偶然成功。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：写一次交付记录”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.6.1 上电前检查

先问什么：“上电前检查”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是在任何动作前确认对象、供电路径、参考点、工具额定范围和停止条件，目标是把它拆成可以复述的对象、条件和结果。围绕“用一张检查卡决定一块开发板是否具备低压观察条件”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用一张检查卡决定一块开发板是否具备低压观察条件”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“上电前检查”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.6.2 供电和参考点

先问什么：“供电和参考点”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是理解 USB、VIN、3V3、GND、外部模块和仪器地之间的能量与参考关系，目标是把它拆成可以复述的对象、条件和结果。围绕“说明为什么‘接上 USB’不能授权使用所有排针”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“说明为什么‘接上 USB’不能授权使用所有排针”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“供电和参考点”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "安全与可观察性", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“安全与可观察性”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.6.3 默认状态

先问什么：“默认状态”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是为复位、启动、断线和输入未知时的输出定义安全状态，目标是把它拆成可以复述的对象、条件和结果。围绕“比较电机停转、阀门关闭和 LED 熄灭在不同产品中的默认含义”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“比较电机停转、阀门关闭和 LED 熄灭在不同产品中的默认含义”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“默认状态”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.6.4 未知条件与停止

先问什么：“未知条件与停止”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是把不确定的电压、引脚、极性、版本和外部连接明确写成禁止继续的条件，目标是把它拆成可以复述的对象、条件和结果。围绕“展示如何保存现场并回到手册，而不是用试错填补空白”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“展示如何保存现场并回到手册，而不是用试错填补空白”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“未知条件与停止”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.6.5 仪器、接线和地

先问什么：“仪器、接线和地”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是区分万用表、示波器、逻辑分析仪能回答的问题，并记录量程和探头设置，目标是把它拆成可以复述的对象、条件和结果。围绕“为一次 GPIO 波形观察写出参考地、倍率、带宽和测量目标”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为一次 GPIO 波形观察写出参考地、倍率、带宽和测量目标”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“仪器、接线和地”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.6.6 可观察性

先问什么：“可观察性”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是让系统在不扩大风险的前提下暴露状态、错误码、时间戳和最后正常动作，目标是把它拆成可以复述的对象、条件和结果。围绕“设计一条不泄露敏感数据但能定位启动失败的诊断线索”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“设计一条不泄露敏感数据但能定位启动失败的诊断线索”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“可观察性”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.6.7 恢复与责任

先问什么：“恢复与责任”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是规定异常断电、拆线、回滚、报告和再次上电的顺序，避免责任落在猜测上，目标是把它拆成可以复述的对象、条件和结果。围绕“把一次未知板卡异常写成可交接的停止记录”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把一次未知板卡异常写成可交接的停止记录”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“恢复与责任”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.6.8 本节练习：做安全闸门

先问什么：“本节练习：做安全闸门”不是孤立的步骤，而是观察未知电源、未确认引脚、仪器地夹和板卡复位状态的入口。本小节的焦点是把‘可以开始’改成一组必须全部满足的检查项，并给每项指定证据，目标是把它拆成可以复述的对象、条件和结果。围绕“练习只允许电脑 USB、官方板载器件和手册确认的低压接口”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“为什么安全和观测要先于第一次上电？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对安全与可观察性而言，唯一供电入口、参考点、断电条件、停止条件、可观察性和故障记录不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“练习只允许电脑 USB、官方板载器件和手册确认的低压接口”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：软件安全状态不能替代保险、限流、隔离、正确接线和板卡手册；看见现象也不能扩大证据。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把 USB 当成绝对安全、把 GND 当成任意地夹、把保护器件当成可以试错的许可。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下上电前检查卡、对象与资料清单、停止记录、板载观察和失败现场。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。条件不清先停止，先保存状态和证据，再回到文档与主机模型。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：做安全闸门”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.7.1 轮询

先问什么：“轮询”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是理解固定周期读取输入的可预测成本、空等浪费和响应上限，目标是把它拆成可以复述的对象、条件和结果。围绕“为低频按钮和高频采样比较轮询间隔对延迟的影响”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为低频按钮和高频采样比较轮询间隔对延迟的影响”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“轮询”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.7.2 中断

先问什么：“中断”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是理解事件到来时打断主线的优势，以及共享状态、优先级和最坏时延风险，目标是把它拆成可以复述的对象、条件和结果。围绕“说明中断服务程序为什么不应执行不可界定的打印或阻塞操作”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“说明中断服务程序为什么不应执行不可界定的打印或阻塞操作”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“中断”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "轮询、中断与 deadline", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“轮询、中断与 deadline”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.7.3 定时任务

先问什么：“定时任务”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是用周期任务、软件定时器和硬件定时器表达重复工作与采样节奏，目标是把它拆成可以复述的对象、条件和结果。围绕“把去抖、超时和心跳分别放到合适的时间基准上”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把去抖、超时和心跳分别放到合适的时间基准上”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“定时任务”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.7.4 deadline

先问什么：“deadline”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是把截止时间、完成时间和超时动作写成可以测量的约束，目标是把它拆成可以复述的对象、条件和结果。围绕“为控制输出、通信应答和日志落盘分别定义最迟完成时刻”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为控制输出、通信应答和日志落盘分别定义最迟完成时刻”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“deadline”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.7.5 抖动与最坏情况

先问什么：“抖动与最坏情况”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是区别平均延迟和最坏延迟，识别抢占、缓存、临界区和总线竞争带来的抖动，目标是把它拆成可以复述的对象、条件和结果。围绕“用同一输入在空闲和高负载下的两条时间线做对照”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用同一输入在空闲和高负载下的两条时间线做对照”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“抖动与最坏情况”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.7.6 背压与丢失策略

先问什么：“背压与丢失策略”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是当事件产生速度超过处理速度时，选择排队、合并、丢弃、降级或停止，目标是把它拆成可以复述的对象、条件和结果。围绕“比较按键边沿、传感器样本和报警消息的不同保留策略”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“比较按键边沿、传感器样本和报警消息的不同保留策略”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“背压与丢失策略”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.7.7 机制选择

先问什么：“机制选择”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是先写频率、预算、优先级和失败代价，再决定轮询、中断或任务调度，目标是把它拆成可以复述的对象、条件和结果。围绕“用一张选择表解释为什么同一个项目会同时使用多种机制”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用一张选择表解释为什么同一个项目会同时使用多种机制”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“机制选择”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.7.8 本节练习：画时间线

先问什么：“本节练习：画时间线”不是孤立的步骤，而是观察周期采样、突发按键、通信接收和必须在期限内完成的控制动作的入口。本小节的焦点是把一个输入、处理、输出和超时动作画成带单位的时间线，目标是把它拆成可以复述的对象、条件和结果。围绕“标出最早响应、最迟响应、允许丢失和下一次可接受事件”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“什么时候轮询，什么时候用中断或定时任务？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对轮询、中断与 deadline而言，轮询、中断服务程序（ISR）、周期任务、抖动、deadline、背压和优先级不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“标出最早响应、最迟响应、允许丢失和下一次可接受事件”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：轮询的成本可预测但可能浪费等待，中断响应快却带来共享状态、抢占和最坏时延分析。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是用忙等掩盖 deadline，或在 ISR 中做不可界定的工作、打印日志和等待外设。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下时间线、事件队列、预算表、丢失策略、超时日志和负载测量。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先写事件频率、服务时间、允许延迟和丢失策略，再选调度机制。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：画时间线”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.8.1 原始输入

先问什么：“原始输入”不是孤立的步骤，而是观察一个输入事件经过采样、稳定判定后改变一个板载输出的入口。本小节的焦点是把按键抖动、重复边沿、浮空和采样误差视为真实输入，而不是异常例外，目标是把它拆成可以复述的对象、条件和结果。围绕“列出一段按下和释放时的原始 0/1 样本序列”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把按键、去抖和状态机变成低风险实验？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对第一次可验证控制而言，原始样本、去抖、稳定状态、事件、状态机、主机模型和目标机证据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“列出一段按下和释放时的原始 0/1 样本序列”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机模型能验证状态转移与边界序列，目标机才能验证具体引脚、极性、时间和板载现象。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只测试一次按键，忽略复位、浮空、重复边沿、输入丢失和输出默认状态。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下状态轨迹、正常/抖动/超时输入、测试输出和四层目标机记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先用无硬件模型把状态机跑通，再在官方板卡允许范围内增加观察。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“原始输入”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.8.2 去抖状态机

先问什么：“去抖状态机”不是孤立的步骤，而是观察一个输入事件经过采样、稳定判定后改变一个板载输出的入口。本小节的焦点是让候选值、连续计数、稳定值和事件输出各有明确含义，目标是把它拆成可以复述的对象、条件和结果。围绕“逐步解释一个阈值为三次采样的按键状态转换”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把按键、去抖和状态机变成低风险实验？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对第一次可验证控制而言，原始样本、去抖、稳定状态、事件、状态机、主机模型和目标机证据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“逐步解释一个阈值为三次采样的按键状态转换”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机模型能验证状态转移与边界序列，目标机才能验证具体引脚、极性、时间和板载现象。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只测试一次按键，忽略复位、浮空、重复边沿、输入丢失和输出默认状态。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下状态轨迹、正常/抖动/超时输入、测试输出和四层目标机记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先用无硬件模型把状态机跑通，再在官方板卡允许范围内增加观察。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“去抖状态机”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "第一次可验证控制", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“第一次可验证控制”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.8.3 边界样例

先问什么：“边界样例”不是孤立的步骤，而是观察一个输入事件经过采样、稳定判定后改变一个板载输出的入口。本小节的焦点是用刚好达到阈值、差一次、连续抖动和快速重复四类样例检验规则，目标是把它拆成可以复述的对象、条件和结果。围绕“预测每个样例会产生几个 pressed/released 事件”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把按键、去抖和状态机变成低风险实验？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对第一次可验证控制而言，原始样本、去抖、稳定状态、事件、状态机、主机模型和目标机证据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“预测每个样例会产生几个 pressed/released 事件”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机模型能验证状态转移与边界序列，目标机才能验证具体引脚、极性、时间和板载现象。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只测试一次按键，忽略复位、浮空、重复边沿、输入丢失和输出默认状态。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下状态轨迹、正常/抖动/超时输入、测试输出和四层目标机记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先用无硬件模型把状态机跑通，再在官方板卡允许范围内增加观察。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“边界样例”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.8.4 主机实验

先问什么：“主机实验”不是孤立的步骤，而是观察一个输入事件经过采样、稳定判定后改变一个板载输出的入口。本小节的焦点是先用标准库在电脑上验证纯状态逻辑，再保存命令、输入和测试输出，目标是把它拆成可以复述的对象、条件和结果。围绕“说明主机测试能证明什么，不能证明哪一条电气事实”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把按键、去抖和状态机变成低风险实验？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对第一次可验证控制而言，原始样本、去抖、稳定状态、事件、状态机、主机模型和目标机证据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“说明主机测试能证明什么，不能证明哪一条电气事实”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机模型能验证状态转移与边界序列，目标机才能验证具体引脚、极性、时间和板载现象。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只测试一次按键，忽略复位、浮空、重复边沿、输入丢失和输出默认状态。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下状态轨迹、正常/抖动/超时输入、测试输出和四层目标机记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先用无硬件模型把状态机跑通，再在官方板卡允许范围内增加观察。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“主机实验”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.8.5 测试输出如何阅读

先问什么：“测试输出如何阅读”不是孤立的步骤，而是观察一个输入事件经过采样、稳定判定后改变一个板载输出的入口。本小节的焦点是把测试通过、事件轨迹、错误断言和覆盖范围联系起来，而不是只看 OK，目标是把它拆成可以复述的对象、条件和结果。围绕“从一条失败输出反推是输入、状态、阈值还是期望写错”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把按键、去抖和状态机变成低风险实验？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对第一次可验证控制而言，原始样本、去抖、稳定状态、事件、状态机、主机模型和目标机证据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“从一条失败输出反推是输入、状态、阈值还是期望写错”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机模型能验证状态转移与边界序列，目标机才能验证具体引脚、极性、时间和板载现象。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只测试一次按键，忽略复位、浮空、重复边沿、输入丢失和输出默认状态。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下状态轨迹、正常/抖动/超时输入、测试输出和四层目标机记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先用无硬件模型把状态机跑通，再在官方板卡允许范围内增加观察。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“测试输出如何阅读”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.8.6 迁移接口

先问什么：“迁移接口”不是孤立的步骤，而是观察一个输入事件经过采样、稳定判定后改变一个板载输出的入口。本小节的焦点是保持状态机合同不变，只替换 GPIO 读取、时钟采样和 LED 写入边界，目标是把它拆成可以复述的对象、条件和结果。围绕“列出主机实现与目标板实现必须共享的字段和必须重查的事实”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把按键、去抖和状态机变成低风险实验？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对第一次可验证控制而言，原始样本、去抖、稳定状态、事件、状态机、主机模型和目标机证据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“列出主机实现与目标板实现必须共享的字段和必须重查的事实”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机模型能验证状态转移与边界序列，目标机才能验证具体引脚、极性、时间和板载现象。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只测试一次按键，忽略复位、浮空、重复边沿、输入丢失和输出默认状态。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下状态轨迹、正常/抖动/超时输入、测试输出和四层目标机记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先用无硬件模型把状态机跑通，再在官方板卡允许范围内增加观察。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“迁移接口”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.8.7 本节练习：主机到目标机

先问什么：“本节练习：主机到目标机”不是孤立的步骤，而是观察一个输入事件经过采样、稳定判定后改变一个板载输出的入口。本小节的焦点是交付一份无硬件可运行的实验记录，同时写出有板卡时的受控迁移步骤，目标是把它拆成可以复述的对象、条件和结果。围绕“把目标机未执行的部分标为未知，不用主机结果代替波形或极性验证”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把按键、去抖和状态机变成低风险实验？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对第一次可验证控制而言，原始样本、去抖、稳定状态、事件、状态机、主机模型和目标机证据不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把目标机未执行的部分标为未知，不用主机结果代替波形或极性验证”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机模型能验证状态转移与边界序列，目标机才能验证具体引脚、极性、时间和板载现象。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是只测试一次按键，忽略复位、浮空、重复边沿、输入丢失和输出默认状态。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下状态轨迹、正常/抖动/超时输入、测试输出和四层目标机记录。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。先用无硬件模型把状态机跑通，再在官方板卡允许范围内增加观察。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本节练习：主机到目标机”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.9.1 目标机边界

先问什么：“目标机边界”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是说明主机模型、官方资料、具体板卡和真实测量分别能证明什么，目标是把它拆成可以复述的对象、条件和结果。围绕“用按键去抖例子列出不能从 Python 输出推出的电气结论”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“用按键去抖例子列出不能从 Python 输出推出的电气结论”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“目标机边界”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.9.2 资料卡

先问什么：“资料卡”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是把板卡型号、芯片、手册、原理图、工具链、版本和许可整理成可追溯入口，目标是把它拆成可以复述的对象、条件和结果。围绕“记录链接、访问日期、章节和仍需确认的字段”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“记录链接、访问日期、章节和仍需确认的字段”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“资料卡”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

PYTHON · HOST MODEL复制
record = {"unit": "迁移与交付", "input": "declared", "output": "observable", "limit": "documented"}
assert all(record.values())
print(record)

这段主机代码只把“迁移与交付”的输入、输出和限制写成可打印记录。它不访问 GPIO、不测量电压，也不把一次成功输出包装成目标机结论。运行后请保存终端结果，再把一个字段改成未知，观察验收为什么必须停在证据缺口前。

PSEUDOCODE · EVIDENCE GATE复制
if not object_confirmed:
    stop("read manual and schematic")
elif not input_defined:
    stop("write input contract")
elif host_model_passed:
    report("host evidence only")
else:
    preserve_failure()

伪代码把对象、合同、主机验证和失败保留排成顺序。迁移到目标机时仍需补齐板卡、供电、工具链、构建、烧录、启动与行为证据；任何一层未完成，都不能用下一层的词覆盖。

0.9.3 运行说明

先问什么：“运行说明”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是让读者从干净目录开始，知道环境、命令、预期输出和常见失败处理，目标是把它拆成可以复述的对象、条件和结果。围绕“把实验包中的 run_all.py 变成不依赖作者电脑路径的步骤”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“把实验包中的 run_all.py 变成不依赖作者电脑路径的步骤”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“运行说明”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.9.4 证据包

先问什么：“证据包”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是把构建、烧录、启动、行为、测试和限制分成不同文件或记录，目标是把它拆成可以复述的对象、条件和结果。围绕“解释为什么一张板卡照片不能代替完整证据链”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“解释为什么一张板卡照片不能代替完整证据链”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“证据包”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.9.5 读者环境

先问什么：“读者环境”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是考虑 Python 版本、操作系统、权限、依赖下载和没有目标板的替代路径，目标是把它拆成可以复述的对象、条件和结果。围绕“让读者知道哪些步骤只需主机，哪些步骤必须查自己的板卡”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“让读者知道哪些步骤只需主机，哪些步骤必须查自己的板卡”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“读者环境”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.9.6 版本与变更

先问什么：“版本与变更”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是记录源码、制品、实验数据和文档的对应关系，避免无声覆盖旧结论，目标是把它拆成可以复述的对象、条件和结果。围绕“为一次阈值变化写出变更原因、预期影响和回归测试”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“为一次阈值变化写出变更原因、预期影响和回归测试”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“版本与变更”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.9.7 复现失败

先问什么：“复现失败”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是把失败当成交付信息，保留触发条件、日志、最后正常状态和下一步，目标是把它拆成可以复述的对象、条件和结果。围绕“写一份陌生读者可以接手的失败报告，而不是一句‘运行不了’”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“写一份陌生读者可以接手的失败报告，而不是一句‘运行不了’”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“复现失败”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

0.9.8 本章结业练习：交付一张系统卡

先问什么：“本章结业练习：交付一张系统卡”不是孤立的步骤，而是观察同一行为从 Python/浏览器模型进入具体 MCU、板卡和工具链的入口。本小节的焦点是把本章对象、约束、合同、实验、目标机边界和资料入口合并成一页，目标是把它拆成可以复述的对象、条件和结果。围绕“读者只看这一页也能决定先运行什么、何时停止以及如何验收”这个场景，读者应先写清输入来自哪里、软件负责哪一步、最终改变了什么现实对象，再决定要读哪一份手册或运行哪一条命令。

机制怎样展开：围绕“怎样把主机模型迁移成真实板卡交付？”，先把输入放在时间线上，再说明状态如何保存、规则何时生效、输出通过什么接口被看见。对迁移与交付而言，主机证据、目标机证据、系统卡、板型、版本、制品和限制不是并列术语，而是一条因果链：上游给出事实，中间层作出判断，边界层承担设备差异，应用层才把结果翻译成产品行为。缺少其中一环时，不要用经验把空白补成确定结论。

放回具体场景：围绕“读者只看这一页也能决定先运行什么、何时停止以及如何验收”这个场景，同一个动作可能有多个合法状态，也可能在复位、超时、输入异常或资源不足时走另一条路径。桌面程序可以等待或重试，设备动作却可能改变温度、位置、功耗或安全状态，所以必须同时写出成功和不成功的结果。把“应该可以”改成带单位、带版本、带观察方式的句子，才能让读者在自己的环境中复现。

对照与边界：主机证明逻辑合同，目标机证明特定对象上的构建、启动、合同行为；两者不能互相冒充。这种差异不意味着嵌入式系统一定更复杂，也不意味着某种工具天然更可靠；它意味着证据的覆盖范围不同。主机模型可以隔离纯逻辑，官方资料可以确认具体接口，目标机观察可以确认记录条件下的物理现象。三者都很有用，但不能互相冒充，更不能把示例板卡的引脚和极性推广到所有设备。

失败路径：最容易犯的错误是把通用教程、他人板卡引脚、私有路径或一次成功现象直接复制为交付结论。一旦出现异常，先保存最后已知正常的输入、版本、输出和时间，再缩小变量；不要同时换板卡、换工具、换参数和换测试样例。一个好的失败记录要说明触发条件、已经排除的可能、仍然未知的事实和下一步停止在哪里，这比“重新运行直到成功”更有学习价值。

证据怎样落地：本单元建议留下系统卡、资料卡、运行输出、构建/烧录/启动/合同四层记录和限制清单。记录不只是截图，还应包含对象、条件、命令或操作、预期、实际、时间戳和限制。若证据来自官方页面，写出链接、章节、版本和访问日期；若证据来自代码，保留输入样例和完整输出；若证据来自目标机，写明供电、参考点、探头或观察方式。条件越明确，结论越容易被别人复查。

迁移到实现：把当前判断翻译到 C、Cortex-M、RTOS 或嵌入式 Linux 时，先保留行为合同，再替换与平台有关的边界。让陌生读者能在新目录运行，并能知道缺少目标机条件时如何停止和继续学习。这一步常常需要回到数据手册、用户手册、启动文件、链接脚本或工具链说明，而不是继续扩大代码量。迁移完成的标志不是“能编译”，而是每个共享字段都有实现、测试和限制。

小结动作：请把“本章结业练习：交付一张系统卡”压缩成一段可以交接的说明：先说对象和问题，再说机制和约束，最后说证据、未知项和停止条件。若一句话无法回答“谁在什么条件下观察到什么”，说明它仍然停留在宣传或印象层。完成本小节后，读者应能用同样的步骤阅读一个新设备，而不必依赖作者电脑里的隐含设置。

版本提示：引脚、电压、工具版本和开发板流程必须以读者当前使用的官方手册、原理图和稳定版文档为准。