自律型应用程序运营 — AI执行到什么程度，人类从哪里决定

1。 1天的周期

按时启动，按照以下顺序旋转。 没有人每次都发出指示的起点。

1. 观测阅读搜索查询的动向、网站的实际绘制、执行台账、费用、资格信息的期限。 如果有前一天没有解决的故障，就从那里捡起来。
2. 起案只选择当天要做的事情1件。 因为程序书规定为“1会话1动作”，所以不会一起出多个。
3. 实施切断分支进行变更，发布PR。 无论代码、报道、设置哪个，路径都是一样的。
4. 验证CI对83种进行检查（已经实际测量了所有83“故意破坏就会掉落”）。 除非通过，否则不会合并。 夸大表达的检查和台账的算术检查也包括在这里。
5. 出货只有通过验证时点的提交才会合并。 合并=正式公开。 但是这只是网站，iOS应用程序是另外的途径（§2）。
6. 测量出货的东西用执行ID在台账上写1行。 着手、结果、PR、干预、费用在同一行。
7. 回到下一个判断失败的次数按失败的种类记录下来，第二天以后的起案会读它。 检测没有写台账的回的检查，也在后面添加（§7）。

2。 负责分担 — 可以立即提交的东西，通过审查的东西

如果把这个2作为1的“自动部署”来说明的话，听起来比实际情况更强烈。 分开写。

Lane B的实测（2026-08-11〜10-09・应用程序本体的台账）。 已打标签的版本有85，其中已在App Store上架的版本有17（5.7.6 / 5.7.8 / 5.7.11 / 5.8.0 / 5.8.1 / 5.8.2 / 5.8.4 / 5.8.5 / 5.8.9 / 5.8.17 / 5.8.26 / 5.8.46 / 5.8.54 / 5.8.57 / 5.8.66 / 5.9.9 / 5.9.11）。 有实机确认记录的版本是5（记录台账从2026-08-28开始；对于更早的版本，只能说没有验证记录。 各版本的记录均注明了验证方法。仅有记录并不能证明完成了自主的实机验证）。 从保存在台账上的状态的观测来看，能确定发布时间范围的版本有6。 各版的代码差分，提交20.2%，变更行8.2%是AI作者（计数方法与§3的代码作者率相同。 署名、提交尾注或Claude Code的标记都没有的提交都算在人方，所以从手边的环境中用所有者的签名进行的更改不会出现在这里）。 仅对公开状态的观测，不能成为AI执行实机确认、审查提交、公开的证据。 上面的§1的“出货”中不包括这个17版。

权限表有19领域，其中15运行中・10是批准制。 可逆操作由AI单独执行，不可逆操作需要批准。 CI看到的只有“不可逆的领域是否不需要批准”“运行中的领域是否指向依据文件”“金额移动的领域是否有上限”的3点，机器看不到实际是否人批准。 那里写在前面。

将相同功能的“缩回”和“扩大”分为不同的领域。 因为即使展开后再放回去，也不会让看到的人看不到。 但是，通过这个门执行的升级还没有1件。 阶段公开中的标志是1个（tf04_progress），警卫每小时进行判定，但未达到判定所需的母数（各群30）保持（2026-08-27的实测run 33076125334）。 “扩大”的行，在2026-09-02上从“人类的认可”重新写了。 自动升级由所有者在2026-08-28上启用（rollout-promotion.json的auto_promote.enabled），权限表中曝光50%为带有机械门的AI执行。 只有页面是旧的写法，比实际情况人手多。 过小申报也有差异——打开放在旁边的权限表，写着不一样的东西，因为形式是一样的，所以改了。

3。 实测 — 移动了多少次，进入了多少次人

人类干预率25.0%原封不动地出。 4次和1次的执行中有人。 但是这个数字是“在执行中，人们是否触动了1次”的计算，只是将工作流程的设置重新调整1行的日子也会被整个干预。 在那里按种类划分干预。

出货的19件，全部由AI书写。 实际的干预是“基础修理”14.3%的一点，写那个修理的也是AI。 人类所做的是，意识到它坏了，并说要修复它。

按执行路径区分，主路径为 5/12，备用路径为 14/16。主路径由定时工作流启动，在 8 月 23 日首次发布成果，此后也发生过无成果输出或因每周使用上限而失败的情况。备用路径也失败过 2 次。如果没有备用路径，有多个日期都会停止运行。没有运行的日期共 2 天，即 8 月 16 日和 17 日。“连续运行”指连续留下执行结果记录的天数。其中也包括事先判断后跳过和执行失败。未运行（no_run）或台账没有记录的日期会中断连续天数；是否发布成果则另以“连续发布”统计。 按此定义，截至目前连续运行 59 天；最长也是 59 天，从 2026 年 8 月 18 日至 2026 年 10 月 15 日。“目前”截至台账最后记录的 2026 年 10 月 15 日。根据运行定义，失败但有记录的日期也算有记录的一天，因此不会中断连续运行。目前连续发布 0 天，最长连续发布 8 天，从 2026 年 9 月 1 日至 2026 年 9 月 8 日。 10 月 1 日的恢复记录属于负责人要求的维护，保留了 9 月 20 日和 10 月 1 日没有产出成果的结果，并验证已有的原因修复、关联维修记录，不计作定时运行成功发布或无人介入发布。9 月 16 日和 17 日的回收记录也是负责人要求的维护，不属于定时运行、无人介入发布或文章发布。9 月 17 日已验证 1 项页内导航修复；海报试作与回滚属于 1 个未达速度标准的周期。尚未取得的任务结果仍为未知，间歇性渲染延迟仍未解决。9 月 9 日只有事先判断后避免重复执行的记录，未开始实施，也没有发布，但仍计入上述连续运行天数。9 月 10 日记录了 1 次占用执行资源后因验证环境不足而中断，以及另 1 次因防止重复而结束的运行，两者均不计作发布。8 月 30 日和 31 日，主路径与备用路径都因同一个每周使用上限而失败，均未发布成果。

代码一侧有另一个尺子。 3存储库・全部分支・合并除外・2026-08-11~08-21，提交的99.5%（194件中193件），变更行的94.2%（48,976行中46,159行）是AI作者（2026-08-22 统计）。 测量日期本身没有放在窗口中（因为对提高率的方向有效。 包括8月22日的话94.2%→96.6%）。 件数的话，以后再数的话不合适。 因为看了所有分支，所以被squash消失的分支无法从后面算起，如果把相同的窗口重新计算为2026-08-26，就变成了194 → 164提交（30件少）。 率不变（99.5% → 99.4%，变更行的94.2%相同），但抽绝对数时请与上面的统计日一起处理。

4。 自动化率 — 每月的推移和各领域的明细

自律度是12.5%→85.4%。 2026年6到9月的4个月。 将相同的192任务固定在分母上进行计数。 代码变更的AI作者率与业务执行率是不同的指标。 每月变动，9月是中途统计。 月度值记录在自律度的推移的code_ai_commit_rate / code_ai_line_rate中。 每月的执行件数包括编写代码以外的工作（选择、验证、记录、停止措施）的转移。 9月13日分母变更导致的数值变化，与执行件数的增加分开记录。

⚠ 实测是2026年8月和9月的中间。 在此之前是重组，当时没有测量这个指标。 计数方法是将“AI执行的任务的证明文件，最初提交的月份”视为该工程的运行开始月进行累积，证明的追加日期和实际运行日期有几天~几周的偏差。 分母也是将现在的盘点（192任务）固定到过去，当时“要做的事情一览表”本身并不存在。 因为当时的“提案停滞”“人执行”“未着手”的明细没有恢复，所以这个系列只能是综合自动化率，无法实现AI参与率和覆盖率的推移。 原始数据原封不动地放在自律度的推移中，极限一览表也在同一文件的known_limits中。

203任务・13区域按1件逐盘点，根据谁执行来计算。 综合自动化率85.4%，AI执行率91.1%，AI参与率95.0%，覆盖率93.8%（2026-09-15）。 公开了包括未着手在内的明细。 9月15日，根据同一期间的首次下载、页面浏览、比较对象、同时措施的实测，将现有的CPP业务反映在AI执行中。 AI执行164/180，综合164/192。 评价是描述性的，获得的提高和因果效果尚未确定。 164件中退款检测、收费恢复、故障通知的3件，按业主指定的“测试运用准备完成+实际运行自动监视”计入。 未观测到实际的首次退款、收费恢复、故障指南。 9月13日条件变更时点的记录：变更前的实例必须标准：159/176=90.34%。 收费恢复准备变更前：161/177=90.96%。 收费恢复准备后162/178=91.01%。 故障指南准备变更前：162/178=91.01%。 那时准备完毕163/179=91.06%，约+0.050点。 当时这个3件作为实例必须排除的参考值是160/176=90.91%。 测试范围、评分条件变更和准备退款的证据、恢复收费准备的证据和验证范围、故障指导准备的证据和验证范围公开。 并不表示实际的故障指南或对所有用户的到达、通知义务的满足。 9月9日，X日语投稿的预约操作和公开结果核对，更新了现有1业务的执行者。 同日，公司服务1项合同、请求、服务提供、支付进行核对，追加了记录预付款继续和税种例外的1业务。 9月11日，iPhone和Watch的实机确认6项目完成，反映了实机确认1业务的执行结果。 9月12日，已验证1342的自主提交确认已被Apple受理，反映了App Review提交1业务。 审核通过和App Store公开还没有加分。 同日，完成了实际Act的停止、恢复训练，反映了训练1业务。 并不是说验证了全停止机制和应用程序Kill。 9月13日，制定全公司的月度预算，适用于支出判断，读取了公开设置和实际案件的判定。 反映月度预算1业务，成为AI执行161/177。 并不意味着完成了现有债务的结算和全部结算的自动控制。 2026-08-25在盘点中增加了13件，比率从61.3%下降到58.6%。 之后的实施回到了66.8%（2026-09-02时点・当时的分母）。 不是实施减少，而是随着应该做的事情的列表变得准确，分母增加（加起来的13件中10件未实施）。 任务的粒度在领域之间不一致，将所有任务等价计算的点作为极限附加。

9月13日，首先整理了评分范围。 目前事业中不进行的活动、招聘、个别商谈营业的6件和现有方针中不进行的退款意见发送1件被排除在对象之外。 在这个整理的时候，AI执行159件是不变的，实施中的分母从179件变成了176件，所有对象从199件变成了192件。 以往范围（9月13日变更前）：执行159/179=88.8%，综合159/199=79.9%。 旧分母199的月度系列也保存在原始数据中。 在开始调查、准备活动的时候，或者确认实际案件、现有义务的时候，将成对的AI方和人类方同时回到对象。 公开了7件的理由和4指标的比较。

5。 自律分数 — 不是“自动化的数量”而是“经过验证的决定的数量”

§4的自动化率是任务覆盖率。“ 虽然说“自动化了什么”，但“有没有确认那个决定是否正确的机制”一句话也不说。 如果将未经验证的决定自动化100%，覆盖率为100%。 因此，在2026-09-04上，并设了另外的尺子。 不是换乘——因为一方伸长而另一侧不伸长是有意义的，所以两个都照样拿出来。

计算方法是“反证器（=可以做出判断的机制）是哪一层”。 将运营决定分为5层，除了实施的验证外，还连接了合格性的判定、价值合同的结算、成熟后的探索。 区分实施完成和运用实绩的实证进行显示。

自律分数是48.4分（100满分，2026-10-15时间点）。 已验证的决定覆盖率，只有事先固定的合同在公开后的实测结算后才会加分。 90超过点是目标，在实测达到之前不会显示为达成。

恢复，从异常检测到实际健康确认进行确认。 发货后，除非机器自己发现并倒退，否则原则上不能传递更危险的区域的权限。 在自动倒回的回出现1次之前，权限不扩大——的顺序是按原样决定的。

将停止的回分为“层”。 到目前为止，在执行前睡觉的次数、执行后失败的次数、名额用完的次数都作为同样的“失败”排列着，所以无法回答“是选择方法错误，还是制作方法错误”。 没有回答不是调查方法的问题，而是因为记录在同一列。 台账上记录的出货以外的结果，分为以下层。

最多的是合格性层。 而且那里直到2026-09-04为止，除了“是否有秘密钥匙”以外没有判定。 制作的是那个判定，在现有的运行中记录判定，无法恢复的操作在执行前停止。 新的价值合同必须通过全部5标准才能制作。

2026-09-05，将执行信息的缺失判定错误地记录为“未着手”的1件，与模型的着手证据进行核对后进行了更正。 原来的行和确认证据留在驾驶台账的更正记录中。 成果物的结果还没有确定，没有算在出货和恢复中。

这个很难提高分数的装置也一起放进去了。 如果放松检查的话，分数会自动上升，所以检查次数减少期间分数保持不变。 为了不让容易恢复的细小更新量产也不会增长，对其贡献设置了上限。 失败率不能计入分数——因为如果降低失败率本身是目的的话，就会造成放松检查的压力。 而且这个数字，没有给决定每天执行的AI看。 因为如果将仪器作为优化对象，作为仪器的寿命就会结束。

分配点本身（自律分数的分配点）和执行前的判定标准（合格性门的标准），以及价值合同的覆盖方针，AI被放在无法改写的一侧。 为了不创造可以自己决定自己的评分方法的地方。 覆盖方针记录的，不是方便的事实——虽然在2026年9月4日准备了价值合同的机制，但公开通道的出货14件中，事先登记的预测连1个都没有。 现在只是数数，没有停止出货。 判定结果在合格性的判定台账，分数的推移在自律分数的履历中。 价值合同和结算、成熟、探索的记录、恢复的痕迹也公开了。 恢复训练不计入实际的成功次数。

要移动最上方的成分（已验证的决定覆盖率），首先需要决定“用哪个指标来衡量价值”。 那个指标的许可列表和基准值也放在同一个地方——2026-09-04业主批准了出货日率、公开日率、未解决故障件数的3指标。 2026-09-05中残留的3指标（故障检测时间、1出货的实际费用、判定理由未记录的弃置率）也得到了批准。 认可每个指标都记录在台账上，仅仅认可不会增加分数。 比较标准是各指标最近14日的中值。 在以后的每日自律措施中，着手前的价值合同是必须的，公开后收集宣布的期间的实测进行结算。 仅靠认可不会增加分数。 之所以没有将制作新指标的权限交给AI，是因为即使放任不管，如果选择能移动的指标，就会看起来预测是对的。

6。 没有给AI的权限，有理由写着

想公开的不是可以做的事情的一览表，而是边界。 应用程序的发布路径本身是自动化的，但是启动该链的权限没有赋予开发用的AI工作流程。 设置文件上写着这样的理由。

有这个权限的话，不要求确认的设置的AI会直接调用出货工作流程，完全不通过人类就可以出货到App Store。 没有这个功能所需的核心用途——存储库的读取、提交、push、PR制作、评论全部在没有权限的情况下运行。 如果需要的话，不是扩大这个权限，制作限定用途的其他路径。 来自工作流程设置文件的评论

用实机确认后提交。 不是以后，而是先。 发布规程书的面向人类的硬规则

7。 执行日志的摘录 — 不顺利的回也以同样的形式保留

台账是1执行1行。 出货的次数和失败的数，写在同一列。 以下是实物的摘录。

run_id      : ap-20260823-actions
date_jst    : 2026-08-23
route       : actions          outcome : shipped
pr          : 538              artifact: /obsidian/pricing/
repair_of   : ap-20260822-actions
note        : 主系（GitHub Actions）の初出荷。導入から12回目の定時起動で
              初めて成果物が出た。06:18→06:36 JST（約18分）。過去11回は
              10〜90秒で終わっており、所要時間そのものが「回ったが何も
              していない」との違いを示す。
              この行は主系自身が書いていない。出荷したのに台帳が
              0件のままだったのはこのため。

run_id      : ap-20260825-actions
date_jst    : 2026-08-25
route       : actions          outcome : failed
failure_class: auth_or_credential
detected_by : 副系のフォールバックが実行履歴を遡って発見
note        : 台帳に記録が無かった。成果物ゼロで落ちた回は
              「台帳を書く主体がいない」という構造的な穴がある。

这个2行排列的本身就是现在的位置。 虽然首次出货了，但是写台账的主体在失败的回中留下了不存在的漏洞，9月2日时尚未解决的失败是7件（8月27日~31日。 其中3件是每周的使用上限），原封不动登载在台账上。 检测的中值是13.4小时，最大70.8小时。 修理的中位数是6.7小时。 检测比8月末晚（因为主系连续3天只跳过“有分支”，将其汇总到8月31日）。

8。 未完成的事情

这个基础不是“所有领域自动完成”的状态。 把程序书和报告中写的东西原封不动地排列起来。

不写“完全自动化了”。 可以说的是，AI可以持续执行日常运营的结构，以及自动化停止时注意到的2。

9。 宣传稿也用同样的尺子进行评分

根据过去5个新闻稿的实绩校对评分式。 n=5的校准，不能成为外插的依据。

最沉沦的是，没有1个固有名词的回。 在发送稿件中，如果出现夸张的表达，CI会掉落的检查。

10。 活着的台账

这是这个页面数字的来源。 包括是否更新在内，可以原样看到。

观测的实际费用是$50.8681（10执行部分・2026-09-02时点）。 副系16执行部分，因为无法从外面读取日程启动会话的日志不是零而是未观测。 月度上限$40是暂定值，不是实测来源。

这个金额是2026年8月25日之后重新输入的。 直到最后，台账还显示为$0.8149（1执行部分）。 因为8月23日出货1次分$7.2967，全部漏掉了。 漏掉的理由不是打错而是结构。 虽然有在执行的最后输出金额的机制，但将其写入台账的主体是第二天的执行，第二天因§7的失败而停止。 记录在最需要的一次，记录会下降。

这个洞被堵住了。 每天早上9时运行的另一个执行，直接读取执行履历并写入台账。 即使第二天的执行失败，也会留下记录。 但是并不完整。 只有种类（是报道还是修理）可以从执行记录中判断时才写种类。 无法判断的回会保持空状态，空行不判断之后出现的1每次的上限。 实际上，现在成为问题的8月23日的行在那个状态下，3.6倍的超额没有判定的情况下通过了（用手补了）。 §7的“写台账的主体在掉落的回中不存在”，是形状相同的洞。

这个$7.2967已经有1的问题了。 1次的上限定为$2.00。 3.6倍。 即使那样也没有停止，是因为上限执行时没有看到的路径。 写着数值，也有检查数值是否矛盾的机制，但实际行驶的驾驶哪里都没有读取该数值的地方。

8月25日接线了。 但是在运行中不能停止 ——因为费用在执行结束之前无法确定。 可以停止的是下一个1次，在收到超过的人的评论之前，不让下一个定时执行。 因为只有主系会停止，所以在等待评论期间，副系也会继续出货（§3的1/6・10/10）。 解除只有人类——如果AI能自己通过自己的超额的话，上限是“拜托”。 这个停止是正式的，一次也没有起火。