自律型應用程式運營 — 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能自己透過自己的超額的話，上限是“拜託”。 這個停止是正式的，一次也沒有起火。