闻过则喜。
两条产品线，一周发出去十个发布物。安装包背后是一条五段式链条：发布 → 升级 → 诊断 → 分析 → 答复。这周又往前走了一步：一块公开的进度板，分类即决策；一个无人值守的执行者，在隔离分支上交出测过的补丁，main 始终不动。
《孟子·公孙丑上》记下一笔：「子路，人告之以有过，则喜。」——有人告诉他错在哪里，他高兴。闻过则喜，不是修养上的谦辞，是信息上的算盘：每一条「有过」，都是别人替你付过费的现场勘测。这一周，这套算盘打成了两次发布。这既是一篇发布记录，也想把幕后的东西一并写下来。两条产品线同时赶工：MRRC（基于 Hamlib 的通用远程电台软件，走 Windows 线，v6.1.x）和 MRRC Modern（面向 FT-710、IC-7300 这类电台的姊妹产品线，更现代，Windows + macOS，v1.18.x）。2026 年 9 月 17 日前后的 48 小时里，发出去十个发布物。安装包只是看得见的那一半；另一半是背后的支持链：用户这边，一键升级、一键回退、一份脱敏诊断包；维护者这边，cron 每十分钟跑一轮初步研判，外加一个公开答复页，每条结论都附原始日志。这篇文章要记下发了什么、头几天的研判教会了我什么，也想讲清楚一件事：把判断和执行分开之后，仓库之外、用户身边，会长出什么东西。9 月 19 日起，链上又长出了公开进度板和无人值守的执行者，那是它的第四项闭环实践。
本文要回答的六个问题
- 事实一周里发出去多少个东西？
- 事实这条链的两端，各自自助到什么程度？
- 推断一次上报和反复出现的特征，区别在哪？
- 推断「环境≠缺陷」为什么不是官僚主义？
- 推断闭环够得着代码之后，长什么样？
- 论点支持为什么是最外侧的那个闭环？
一周，两条线，十个发布物
用户真正拿到手的，不是 changelog，是体验。
| 发布物 | 日期 | 用户拿到什么 |
|---|---|---|
| MRRC V6.1.15（安装版） | 9 月 17 日 | Windows 安装版会自动拉起 rigctld——电台 CAT 守护进程随安装包分发（vendor 内置 rigctld.exe + DLL），还支持机型名 → 编号解析：配置里写 FT-891 就行，不用再写 -m 1036。 |
| MRRC V6.1.16（安装版） | 9 月 17 日 | 加固：内置 rigctld 以 manager 的路径为准，兜底逻辑只让位、绝不阻塞启动——自启动不能反过来变成「起不来」。 |
| MRRC V6.1.18（安装版） | 9 月 18 日 | 第三种降噪引擎：NR3 —— RNNoise（Xiph 的神经降噪，v0.2，BSD-3），[WDSP] nr3 = plus|only|off；重建了 libwdsp，新开放 EMNR 的 alpha/npMax 两个调节参数；NR2 等级表整体下移（−6/−9/−12/−16）；外加一个门控修复：关掉降噪现在是真旁路。 |
| MRRC 热修 6.1.14 → 6.1.18 | 9 月 17–18 日 | 同一批修复也走热修通道：不用重装，重启 MRRC 就生效。自启动（6.1.14）、名字→编号（6.1.15）、兜底让位（6.1.16）、NR2 等级表（6.1.17）、NR3 + 门控（6.1.18）。 |
| MRRC Modern v1.18.0 | 9 月 17 日 | 首个正式 macOS 版（Apple Silicon DMG，macOS 11+），和 Windows 安装版同步发布，外加实时更新通道（latest.json，SHA-256 直接取自产物）和完整的支持链：🐞 诊断包、答复页、打包版日志落盘。 |
| MRRC Modern v1.18.1 | 9 月 18 日 | 两个 macOS 修复：应用签名了（不再「已损坏，无法打开」）；.bundle 正确申请麦克风权限（不再无声 RX）。Windows 包从同一份源码同步重建。 |
同一周进场的还有 Modern 线上的性能活儿：发射结束后 TX→RX 重新打开采集的时间，从约 270 ms 降到约 200 ms；PTT 按住期间，不再把已静音的 RX 帧广播出去；PTT 释放延迟在 SDD 里有了自己的版本行（V2.55）。这些没有一项光鲜，但每一项都可测。
闭环自己这周也发了版：9 月 19 日，MRRC Modern 上线 FDE 进度板，这个项目一脉相承的第四项闭环实践。一块公开的进度板，让每条分析带着分类落上去（bug / feature / noise），后面跟着一个无人值守的执行者，把排了期的条目变成隔离分支上的补丁，全量测试过了才算。它不是安装包，所以不进这张表；它是 §05 的主角。
每个安装版的 previous 都留在服务器上，而且必须 git 入库——部署用的是 rsync --delete，服务器上没入库的文件会被删掉（回退按钮就这么 404 过一次）。热修通道的版本号必须低于安装版；回退目标必须真实存在、不能是已知的坏版本；清单里的 SHA-256 要在服务器侧复核，因为本机下载链路不可信。跨项目可比的数字（测试数、约束数、各产品族版本）只放在一个地方：证据清单，子站和博客都链接过去，不复述。
「自助服务」和「自诊断」到底是什么意思
五段：发布 → 升级 → 诊断 → 分析 → 答复，把来回沟通都工程化掉。
大多数产品的支持链，说到底是一个邮箱别名，外加一声祈祷。这一条不是：它是两端各装了一套工具的流水线。用户侧的应用按一个目标设计：用户最常做的四件事，永远不用开工单：
⬆️ 升级，不用去找下载页
Web 界面点一个按钮（或者在启动器里按 U）。服务端先过 PTT 这关：电台正在发射，升级请求直接被 423 拒掉。下载先写 .part 文件，校验 SHA-256，原子改名，再静默安装，启动器干干净净地交接。
↩️ 成功判据造不了假
「安装器拉起来了」不算成功。唯一的成功判据是 state.json → lastResult.status == "ok"，而且要由新版本在自己启动时自证。新版本没开口之前，这次升级就不算发生过。一键回退走的是同一条静默安装路径，只是指向上一个安装包。
🐞 诊断，不用读日志
菜单里一个入口就能生成脱敏诊断包：日志尾部、按白名单脱敏的配置、环境快照（版本、平台、音频设备表、已生效的热修层），外加一份自动体检摘要 diagnostics/summary.txt，它按启动次数和时间跨度来区分「重启」和「崩溃」。密码、密钥、令牌、录音、存储信道、天调学习数据，永远不出这台机器。
📖 答复，不用写邮件
公开的答复页可以搜索、可以按上报编号直达。每张卡片的结构是固定的：编号 / 症状 / 诊断（附原始证据）/ 结论 / 你要做的 / 状态。缺陷修复发布后，卡片就翻成「已修复 · 版本号」。
维护者这边，同一条链跑在每十分钟一轮的 cron 上：取新包 → 生成摘要（复用客户端那个摘要器，两端对「摘要说明了什么」有共同语言）→ 模型按成文的纪律分析 → 结构化 JSON 结论 → 渲染答复卡 → 发布。默认不发布，要显式参数才发；按包 ID 幂等；不完整的包跳过；每轮最多处理两条。
以前的支持像一场访谈：一封邮件问一个问题，每个来回隔几个小时，用户全凭记忆回答。诊断包把访谈变成了测量：一次上传就是一个现场，带着采集健康度百分比、设备表、重启和崩溃的判别。这个转变不是 UX 上的润色，而是机器预检得以成立的前提。「访谈的第一轮」你没法交给机器做，「测量的第一轮」可以。
两个产品族现在跑的是同一条链。Modern 在 v1.18.0 把它整套继承了下来：包格式、摘要器、答复页、更新检查。它的前两条自动预检答复已经在 9 月 19 日发出，离第一批诊断包到达不到一天。
三起事故，三个已发布的功能
问题解决之后，怎么挖出新需求：讲机制，不喊口号。
同一堵墙，一个早晨撞了两次
9 月 17 日，两份 FT-891 上报在两小时内先后到达：20260917-073700-14ef（07:36）与 20260917-085736-ebd2（08:53）。症状相同（「电台连不上；音频同步正常」），诊断包给出的结论也相同：CAT 守护进程 rigctld 没在跑，配置正确，日志里三次超时，无崩溃。按判定表，两例都判为环境，两张答复卡教的是同一套 PowerShell 操作。
单独看，两例都能关掉。放在一起看，是产品上的一道裂缝：一个自称「通用遥控」的软件，要求每个新用户手工拉起守护进程，等于给所有人出了同一道题。重复本身，就完成了定性。当天：热修 6.1.14 加上自启动（rigctld_supervisor.py）；热修 6.1.15 修好机型名→编号解析（rigctld --list），并把 rigctld.exe 打进安装包（V6.1.15）；V6.1.16 让兜底路径只让位、永不阻塞启动。答复页新增一张公开卡：FT-891 用户升级即可。《左传·宣公二年》有言：「人谁无过？过而能改，善莫大焉。」——谁都会有过错，能改，就是最大的善。放在软件上，「善」是可以计时的：从墙现形到修复上线，不到一天。
判成「环境」，回答的是用户；几小时内连续两次「环境」，回答的就是路线图。真正值得盯的量从来不是单次判定，而是跨上报的故障特征，以及从特征出现到修复上线隔了多久——这一次，不到一天。
一条答复变成默认值；一个默认值变成引擎
上报 20260917-132643-020a：「NR2 开到 2 级后水声大、有失真」。诊断包里的数字让结论可以验证，而不只是听起来可信：音频采集健康度 99.9%、没有 Traceback、没有双重降噪叠加。答复卡据此判定，这是谱减法典型的音乐噪声副作用，并给出操作建议：级别 2→1、调整 AGC 模式和带宽。
接下来的三天里，产品分三步吸收了这条结论。改默认值：NR2 等级表整体下移一档（热修 6.1.17），再落到 −6/−9/−12/−16。开放参数：重建的 libwdsp 增加了 C 层的 alpha/npMax 设置接口，新默认值经过闭环实测（npmax 0.98，AE 20/0.50）。加引擎：NR3 —— Xiph 的神经降噪 RNNoise，可选 plus|only|off，随 V6.1.18 上线，同时带上让「关」成为真旁路的门控修复（此前有用户报告关掉降噪后仍然失真，这本身也是一条值得挖的上报）。
答复卡在几分钟内修好一部电台；改默认值，无声无息地修好以后所有的电台；新引擎改变的是可能性的边界。只走第一步的支持是成本中心；能把「答复 → 默认值 → 引擎」这条弧线走完的支持队列，才是需求流水线。
两次静默失败，与一套回归协议
Modern 的第一个 macOS 版撞上两个不吭声的失败，两个修复都堪称可观测性的教材。「已损坏」：此前所有 macOS 构建其实都没签上名——签名步骤一直在悄悄失败，于是 Gatekeeper 弹出一个点右键也绕不开的对话框。修复是双份的：按 codesign 的要求重新布局 bundle，并且签名一旦失败就直接中止构建。静默失败才是缺陷，对话框只是症状。无声 RX：bundle 没有声明音频输入权限，macOS 的对策是把采集流照常打开、往里填零，日志提示「检查电台」，CoreAudio 却不报任何错误。修复是正确申请权限，并把警告指向系统设置，而不是电台。
第三个案例，是预检系统咬到了自己的尾巴，还咬出了价值。诊断包 20260918-114118-9ad3 带着「录音掉块 / 队列满」的故障特征，跟 V2.44/V2.45 修掉的那个缺陷特征相同，但所有命中的日志行都落在 9 月 12 日，也就是修复发布之前。公开结论没有采信两个顺手的答案（「早就修了」/「回归了！」），而是走了一套流程：请用户录一段新 QSO 再回报。后续的包（20260919-085517-b3aa）关闭了这个问题——9 月 19 日的日志是健康的，旧日志行被确认为修复前的残留。让这一切成为可能的，是一条作为流程改动提交的东西（ecb2652）：模型在写结论之前，必须先读项目自己的事故史——SDD 版本史、CHANGELOG、精确到行的代码位置，这些是输入，不是事后补的注解。
Modern 的两条结论都逐行引用了证据：server.py:348 _ensure_rec_writer()（修复本体，已在当前代码里）、SDD V2.44/V2.45 的记录行、带时间戳的摘要行、健康的 9 月 19 日会话日志。材料不够的时候，卡片会明说，而不是猜——MRRC 最早的七条答复里，有一条至今停在「需要补充信息」。那是一个诚实的台阶，不是失败状态。
机器的初步判读，人的判定
预检靠的是契约，不是感觉：结构化输出、白纸黑字的判定规则、出错就停手的护栏。
分析器的输出是一份固定的 JSON 契约——verdict、status（answered | needs_fix | need_more_info）、category、diagnosis[]、solution[]、evidence[]、keys[]、needs_code_change、code_hint——原样渲染进答复卡，证据行一并呈现。判定规则写成表格，不凭感觉：Traceback 或同一处异常反复出现 → 缺陷；多次启动而没有 Traceback → 不是崩溃；-9996 且设备表为空 → 环境（没声卡的虚拟机）；rigctld 未运行 → 环境；采集健康度低于阈值 → 性能；证书告警 → 正常噪声。
判定规则就是筛子
「环境 ≠ 缺陷」是一个需求决策，不是较真。把环境误判成缺陷，路线图会被幽灵需求填满（「自动拉起用户从没要求过的东西」）；把缺陷误判成环境，用户就被晾在一个永远变不成修复的变通办法里。这张表让两种错误都代价高昂。
按规则保守
材料不足 → need_more_info。没有 Traceback → 永远不叫崩溃。环境类 → 永远不算缺陷。结论必须落成用户能执行的动作——「去系统设置里重选音频设备」——绝不写「等维护者修」。答复页是公开页面：只发可公开的结论，不带用户数据。
出错就停手的护栏
默认拒绝发布（显式参数才发布）。按包 ID 幂等。不完整的包和非 zip 载荷，直接跳过、不重试。每轮两条上限、九分钟模型超时、cron 用绝对 venv 路径。自动化允许「什么都没做」，不允许「做错了什么」。
分工
机器做初步判读：便宜、一致、不知疲倦，十分钟一轮，每个论断都挂在某一行日志上。人握着 needs_code_change：改不改代码、发不发版、答复能不能照原文发布，都由人定。产品是维护者构建的；智能体负责预检、起草和渲染。
MRRC 答复页：7 条预检答复——6 条给出了可执行的步骤（4 条环境、1 条音频调参、1 条无需修复），1 条退回补证据。另有 1 张已知问题卡，按用户看得见的现象来写（「页面按钮点不动」），它的根因（6.1.12 的内联 JS 语法错误）变成了 tests/test_web_inline_js.py：如今每次发布，所有内联脚本都要过 node --check。MRRC Modern：上线 48 小时内出了 2 条答复，都引用了代码位置和版本史。没有一条答复以「等维护者修」收尾。
从已答复到已实施
9 月 19 日，这条链长出了公开进度板和无人值守的执行者，闭环够到了代码。
分类即决策
9 月 19 日之前，这个闭环能读、能答；但分析出来的 bug/feature 分类没有去处，还是得靠人挑出要修的、动手修、手动收尾。进度板（vlsc.net/mrrc_modern/board）补上了缺的另一半。它的规则只有一句话：分类即决策。分析契约加了三个可选字段（kind：bug / feature / noise，外加 severity 和 title），分类从此变成调度：
| 分类 | 自动动作 | 依据 |
|---|---|---|
| noise——环境 / 误报 / 已修复的故障特征 | 答复用户；进度板上标「已答复」，终态，不动代码 | 答复页已答复，不需要改代码 |
| bug，可定位的产品缺陷 | 答复用户，同时自动排进无人值守的实施队列 | 修不修只是验证问题，不是产品取舍 |
| feature——新能力 / 新参数 | 答复用户；进度板上标「待决策」，等操作员 | 排不排期是产品决策，不交给自动化 |
| need_more_info | 永不闭环，留在「待决策」里跟进 | 没答复的上报，不许假装闭环 |
进度板和答复页共用同一个隐私过滤器（redact_public），互相链接。一次用户上报变成一张带状态的卡片：反馈不再躺在邮箱里，而是站在一个看得见位置的队列里。这也是一份公开承诺：什么闭环了、什么排期了、什么还在等，以及为什么。
一个测过的补丁落在分支上，而 main 在睡觉
同一条 cron 现在带着 --implement 在跑。对每条排了期的条目，一次只办一件——每轮一条，而且只在干净的 main 工作区上动手。流水线用只读工具（read,grep,find,ls）调用模型，要求它交出一份 JSON 契约：understanding、unified diff 补丁、test_plan、risk、commit_message——或者 no_action，后者带着理由落到进度板的 Rejected 里。模型没有写权限；补丁在流水线决定采纳之前，只是一段文本。
流水线拿到这段文本之后做的事，才是安全所在：
- 护栏先行——两个跨文件的工具护栏脚本、
certs/、win/、packaging/和安装器清单（.iss），一律拒绝；单个补丁最多 8 个文件。 git apply --check先跑；失败即终止，理由记进进度板。- 隔离分支——补丁只落在新拉出的
fde/<id>分支，永不落在main。 - 全量测试把关——绿了就提交到分支（进度板记下
branch@hash和测试结果行）；红了就删掉分支、还原工作区，记 failed 并附上日志尾部。 main永不移动。无人值守进程碰不到它；合入分支是人的动作。
设计思路和 PTT 把关一脉相承：机器可以提议，证据说了算，人来拍板。跟电台相关的部分没有任何东西被自动化掉，代码也没有一行能不经审查落地。变化在于：一条排了期的 bug，不再需要等有人坐到键盘前才能开工。
闭环自身的两次失败，以及它们证明了什么
无人值守的闭环有自己的失效模式，头一天就冒出来两个，每一个都比它耽误的那点功能更有价值。
跑不起来的模型运行器。cron 预检用的 pi 连续两天死于 SIGABRT。根因是一次 Homebrew 升级弄断了 bottled Node 的 dylib 链接（llhttp）——出问题的是模型的运行器，不是模型本身。修复不是加重试，而是加诊断：run_pi 现在会在死于信号时点名死因。一声不吭地失败和无事可做，从外面看一模一样；无人值守的闭环，必须解释得了自己的沉默。
混进生产环境的测试夹具。测试运行只改写了本地页面路径，却还是把夹具版的答复页/进度板页发到了线上服务器。能发现它，是因为生产进度板上突然冒出一个测试包编号。修复把页面发布收敛成唯一一个可拦截的口子（_ship_page()），但重头戏是验证：完整跑完一轮 1,299 项测试后，本地进度板状态和线上页面逐字节一致。闭环自己的发布路径，同样置于测试之下。
这两起事故之所以能被抓住，是因为这个闭环的产出是公开的、逐字节核对的。私有自动化可以悄无声息地失败好几个星期；公开的闭环会把自己的失败漏进和产品同一个证据面上。进度板上冒出测试编号很难看，但也正因如此，那个口子当天就修掉了。子贡早把这套机制说完了：「君子之过也，如日月之食焉：过也，人皆见之；更也，人皆仰之。」（《论语·子张》）过错像日食月食，人人看得见；改正了，人人仰望。公开，让「人皆见之」成为默认；「人皆仰之」的那一半，靠当天修掉来兑现。
人的工作压缩成两个动词
对照 §04 看，进度板改变了自动化的权限边界。之前：机器读、机器分类，人挑、人修、人发。之后：分类即调度——noise 自行闭环、bug 自行入队，人要做的事情压缩成两件：决策（每个 feature 写一条排期备注）和合入（接受一个测过的分支）。这和整个工程体系是同一套分工——判断归人、执行下放、证据把关——只是作用对象从源码树换成了产品自己的待办清单。
闭环的边界又挪了一次。它曾经止于一条已答复的工单，后来止于一个已发布的修复，现在止于一个已审查的分支——一份在没人醒着的时候产出、测过、可回滚的补丁，等人点头。最后一步留给人，不是机器不会合入，而是「算不算数」是这个项目唯一不肯交出去的动作。
截至写作时，线上进度板上只有两条已分类条目，都是 noise → 已答复；第一条真实的 bug 还在等它第一次真实的排期，第一份无人值守补丁还在等它第一次人工合入。端到端这条路径——上报 → 排期 → 无人值守实施 → 合入——有测试验证，但还没有真实案例验证；SDD 条目（V2.56）也写明了同一道边界：实施模型的探查预算和 diff 质量，有待真实样本来校准。这周流水线的门槛数字：9 月 19 日那次提交里的 1,299 项测试；持续维护的可比数字在证据清单里。
这条链对智能体工程说了什么
智能体工程把判断和执行分开。支持链，就是这套分法用在用户身边的样子。
闭环有边界，而仓库是错误的那一个
账本那篇（七十亿 token 的全程拆解）量的是内环：契约测试先红、智能体交付到绿、中位 19 分钟。那个闭环闭合在仓库内部。但如果产品的迭代单位不是 commit，而是没被解答的用户症状，那么一套全绿的测试，就是绕着错误边界闭合的环。产品完全可以连着几个月测试全绿，同时每个新用户都卡在同一堵墙上——因为仓库边界之内，没有任何东西看得见那堵墙。《资治通鉴》记魏征答唐太宗之问：「兼听则明，偏信则暗。」——多方听取就看得清，只听一面就糊涂。测试套件是「一面」，现场是另一面；只听仓库那一面的系统，注定暗在现场。支持链把环拉长了：现场 → 诊断包 → 判定 → 产品变更 → 发布 → 用户自助。只有当用户的下一次点击，在没有任何人工介入的情况下走通了，这个环才算闭合。
自助是带宽，不是客气
每往用户侧挪一步，环里就少一个来回：升级不用找下载页、回退不用重装、诊断不用读日志、答复不用写邮件。每一步的设计检验都是同一句话：用户看不懂日志，能不能完成这个动作？这就是「自诊断」不是营销词的原因。诊断包是放在用户侧的一件工具，为接收的人设计，而不是为发送的人：白名单脱敏、按「一眼能读完」写的摘要、重启与崩溃的判别、附上的设备表。这也是答复页公开原始证据行的原因：能自己核对推理的用户，在读下一条答复之前就已经信了。
自助就是闭环的带宽。每条消息都要人来中转的支持链，会把产品的总迭代速度封顶在一个人的注意力上。而一条用户自己能完成升级、回退、测量、查答复的链，让闭环的速度由最慢的那个自动化环节决定，而不是由人决定。
进路线图的是故障特征，不是单次判定
一次上报是案例，反复出现的特征才是需求。判定规则负责让人诚实——它是那个筛子，替路线图挡住幽灵需求（把环境误读成缺陷），也替用户挡住干等（把缺陷误读成环境）。但真正驱动迭代的量，是跨上报的特征，加上从特征出现到修复上线的时长。9 月 17 日：两条环境判定，相隔两小时 → 当天热修。9 月 17–18 日：一条调参答复 → 等级表 → 参数 → 第三种引擎。支持队列和路线图是同一本账，只是读的周期不同。
这是一整套节奏，不是一个环
| 闭环 | 周期（实测） | 捕捉什么 |
|---|---|---|
| 预检 | 10 分钟（cron） | 每个诊断包都能得到初步判读；没有东西在邮箱里排队 |
| 答复 | 当天 | 环境 / 使用 / 调参类问题，在用户侧就解决掉 |
| 实施 | 每条分钟到小时级（一次一件、测试把关） | 排了期的 bug 变成隔离分支上测过的补丁；合入仍归人 |
| 热修 | 小时级（6.1.14 → 6.1.16 一天之内） | 热修覆盖范围内的缺陷和缺口（www/**、应用模块、vendor） |
| 发布 | 天级（V6.1.15 → V6.1.18；v1.18.0 → v1.18.1） | 安装器级变更：内置引擎、签名、权限 |
| 免疫 | 事故 → 防线，永久有效 | 每起事故留下一道防线：内联 JS 检查、站点测试数与中英成对检查、签名失败即中止构建 |
一个系统的学习速度，取决于「能抓住每一类事故的最快那环」。支持链给这叠节奏补上了最外侧的一拍——它是唯一能抓住那些永远不会出现在仓库里的事故的环：没有声卡的虚拟机、USB 重枚举、macOS 权限弹窗、Gatekeeper。账本里那条事故链，从事故到机器强制的约束跑了 13 天、又 7 天；这一周的当天支持弧线，是同一个原理在不同半径上的又一次测量。
两本账的纪律同样适用于答复
「已答复」是过程证据：说明这个案例被读过、被分类、拿到了一个可执行的动作。「已修复 · 6.1.13」则是绑定在已发布产物上的产品主张。答复页把两者分开；need_more_info 是那个诚实的台阶，最早的七条答复里就有一条站在那儿。支持卡里的任何内容都不能升格为产品主张，能让它升格的只有发布记录里的版本行。这和主证据清单（/zh/agentic.html#evidence）是同一门纪律：过程徽章永远不升格为产品主张，边界永远白纸黑字写下来。
哪些环节故意留给人
这条链里有三件事，是刻意只留给人的。射频安全：升级路径拒绝触碰正在发射的电台（423 拦截），任何自动化都越不过 PTT 这道关，任何自动化结论也碰不了发射行为。隐私底线：密钥、密码、录音、存储信道，永远不离开用户的机器；脱敏靠白名单，不靠口头承诺。对代码的判定：needs_code_change、改动本身、发版决定，都归维护者，机器的边界到 diff 为止。深度硬件排障（挑剔的 USB 供电、CI-V 的怪癖）也依然是手工活。生命周期文档同样把自己的边界写得明明白白：基于摘要的预检，读的是摘要，不是完整环境——它不会暗示自己拥有并不具备的自动化能力。总纲把留给人的这一半叫作「意图、边界与裁决」，那条规则正是这一节存在的原因：智能体承担执行，不承担问责（分工）。
按论纲页的谱系，FDE——前沿部署工程——是第一个把现场证据带回设计的闭环：Echo → Delta → Product，由一名扎在现场的工程师承担。支持链没有改变这个环的形状，改变的是由谁来跑：现在它跑在 cron 上，两端各有一套工具，路径上那位「现场部署工程师」变成了一条流水线。同一个拓扑，换了一套经济账——这就是一门手艺从「靠英雄」毕业成「工程」的意思。
我主张什么，不主张什么
主张：这条链能把现场症状变成已发布的产品变更，每一步都有可引用的证据；多数类别的问题，用户不需要人工往返就能解决；每条已发布的结论都可以对着原始日志行逐条核对；预检自动化自身的失效模式是有界的、成文的。不主张：路线图的自主权——答复页由人读，一个特征值多少由人定；安全自动化——流水线里没有任何东西触碰发射路径；完备性——基于摘要的预检不可能看见完整环境的一切，need_more_info 作为一等结果存在，就是这个原因。产品是维护者的双手和流水线一起构建的；智能体的角色是预检、初步判读和发布机制。产品这一周变得更好，是因为闭环带回来的东西，而不是因为打字的是谁。
闭上那个够得着用户的环
一周，两次发布，一句留下来。
自助不是成本优化，它是产品的传感网络。只会回邮件的支持链是成本中心；能把反复出现的特征变成已发布功能的支持链——当天热修、改掉的默认值、新引擎——是需求引擎。够得着用户的那个环，决定产品会不会进化，所以要有意地把它闭上：先让故障可观测，再让答复自助化，让重复出现的特征自己走进路线图，而判定始终留在人手里。当闭环长出执行者，同一门纪律接着放大：分类即决策、机器提议、测试把关、合入归人。
先让失败可观测，再让答复自助化，然后让重复出现的特征自己走进路线图——判定，留给人。「人告之以有过，则喜」——两千三百年前的那句话，如今是这条链的名字，也是它的节拍。
去试试这几个入口：MRRC 答复页 · MRRC Modern 答复页 · MRRC 下载 · MRRC Modern 下载。跨项目可比的数字（测试数、约束数、版本）只在一个地方：证据清单。