Jie Ma · 2026-09-13 · 研究笔记
为什么 AI 辅助开发在专业能力成熟之前就需要治理
AI 改变了软件开发的门槛和速度。现在，开发者可能还没有经历足够多的设计、审阅、失败和修复，就已经能够借助 AI 把一个想法变成可以运行的功能。
这确实扩大了人的能力，但也带来了新的问题：开发速度可能增长得很快，开发者判断架构、安全、测试、集成和发布后果的能力却未必能同步提高。
最需要治理的人，可能还不知道应该问什么
传统的工程管理通常假设，团队里已经有人知道风险在哪里。例如，开发者知道某项数据库迁移可能破坏数据，审阅者知道哪些边界涉及安全，发布负责人也知道上线前还缺少哪些证据。
对于经验还不充分、但已经在使用高能力 coding agents 的开发者来说，这些假设往往并不成立。AI 的回答又常常非常流畅，即使某个重要问题根本没有被提出，答案看起来也可能像是完整的。
因此，面向 AI 辅助开发的治理工具不能等到用户已经成为专家之后才发挥作用。它应该主动观察项目状态，指出用户可能还没有意识到的问题，解释这些问题为什么重要，并给出安全的下一步。
每一项 finding 都应该说明：系统观察到了什么、依据哪条规则、判断中还有哪些不确定性、用户可以怎样恢复，以及现有证据不能证明什么。工具的目的不只是阻止一次危险操作，还要让用户能够理解背后的判断过程。
治理工具应该帮助用户成长，而不是让用户一直依赖它
这要求用户以渐进的方式使用 MetaAware。在早期，工具可以主要帮助用户学习和审计项目状态；当项目已经明确自己的政策，证据也变得更可靠之后，再逐步加入操作辅助和与风险程度相称的执行限制。
解释也应该分成不同深度。用户首先可以看到一段用于立即采取行动的简短说明；如果需要继续检查，还可以查看底层事实和具体规则；如果希望真正理解问题，则可以进一步阅读相关案例和参考资料。
MetaAware 不能把自己说成专业经验的替代品。它无法掌握每一项产品约束、团队讨论和现实后果。人类仍然需要制定政策、质疑 finding、批准例外并承担风险。风险足够高时，外部审阅和领域专家仍然不可替代。
因此，我们不能只用“规则是否抓住了一个已知错误”来检验治理效果。还要看用户能否理解理由、选择合适的恢复方法、在以后识别类似问题，以及在工具判断错误时提出质疑。
只有当治理工具既能降低眼前的风险，又能帮助用户逐渐形成自己的判断能力时，“在专业能力成熟之前提供治理”才算真正成功。
Jie Ma · 2026-09-13 · 研究笔记
治理应该增加理解，而不只是增加合规
“通过”或“失败”只回答了一个很有限的问题：某条规则有没有被触发。
它没有告诉开发者，系统究竟观察到了什么、这个情况为什么重要、判断有多大把握，以及做到什么程度才算真正恢复安全。
如果治理工具只给出结论，用户很容易形成表面合规：他们知道应该按哪个按钮、填写哪个字段，却仍然不理解背后的风险。
一次通过不等于真正具备治理能力
好的治理应该让用户在下一次遇到类似情况时，更有能力自己发现问题、分析原因并验证结果。
这对 AI 辅助开发尤其重要。AI 可以快速提高实现功能的速度，但开发者评估后果所需的经验不会自动以相同速度增长。工具不能假设新手已经知道应该问什么，也不应该让新手永远依赖工具替自己判断。
因此，一项有用的 finding 不能只有状态。它还应该说明观察到的事实、适用的规则、为什么需要关注、判断的认识状态、下一项安全操作，以及怎样验证问题已经恢复。
它还应该明确告诉用户：现有证据不能证明什么。界面可以先显示简短结论，再允许用户或审阅者逐层查看完整的证据和判断过程。
应该测量用户是否学会了，而不只是是否服从了
工具阻止了多少次操作，并不是衡量治理质量的好指标。
更有意义的问题包括：用户能否选择合适的下一步，能否用自己的话解释原因，能否把学到的判断方法用在新场景中，能否发现并质疑错误的 finding，以及是否减少了重复犯同类错误的次数。
误报和漏报当然仍然重要，但解释是否清楚、用户的行为是否发生了改善，也同样重要。
理解问题不能保证用户一定作出正确决定，工具的解释本身也可能出错。这里的主张更加有限：治理工具既应该作为控制系统来设计，也应该作为学习系统来评估。
如果工具只让用户完成了这一次合规操作，却没有改善用户今后的判断能力，那么它治理了这一次操作，但没有真正增强开发者的治理能力。
Jie Ma · 2026-09-13 · 研究笔记
AI 不应认证自己的工作
AI 可以生成代码、测试、解释、审阅意见和发布建议。人们很容易因此把第二次 AI 判断，当成对第一次 AI 判断的独立保证。
例如，一个模型编写了变更，另一个模型表示同意，然后系统把两个模型的一致意见包装成“高可信度”。第二个模型可能提供了有价值的批评，但两个模型意见一致，并不会自动产生独立的事实依据。
两个模型意见一致，不代表得到了独立验证
不同模型可能使用相似的训练模式、prompt、工具和上下文，也可能遗漏同样的信息。它们甚至可能只是用不同的措辞，重复同一个听起来合理的错误。
模型还可能检查自己参与生成的证据。例如，它先写出一套实现，再生成一套正好能够通过该实现的测试。
如果治理流程中的每个阶段只接受上一个阶段给出的总结，而不再检查底层事实，整个验证链条就会非常脆弱。
因此，一个可靠的治理架构需要把不同职责分开：机器负责观察可复现事实；具名且版本化的规则只根据事实能够支持的范围作出判断；AI 负责解释 finding、不确定性和恢复方法；人类负责制定政策、批准例外、接受重要风险并承担最终责任。
任何组件都不应该仅仅因为能够流畅地解释自己的判断，就获得更大的权威。
最终保证必须落在模型信心之外
可以用来终止保证链条的证据包括：可复现的仓库状态、独立规定的测试、确定性 oracle、签名审阅记录、外部观察结果，以及人类对主张边界的检查。
这些证据都不一定绝对正确。它们的重要价值在于，它们有能力反驳 AI，而不是只能重复或支持 AI 已经给出的答案。
AI 在这个过程中仍然很有价值。它可以寻找不一致之处、比较变更与政策、生成对抗场景、把技术 finding 解释成日常语言，也可以帮助审阅者检查更多证据。
但 AI 不能静默修改规则、自行批准例外、把 unknown 改成 pass，也不能因为自己的解释听起来很连贯，就宣布自己的工作是安全的。
“AI 不应认证自己的工作”并不意味着绝对不能用 AI 审阅 AI。独立的模型和 prompt 可以增加审阅视角，就像多名人类审阅者也能改善覆盖范围一样。
更准确的原则是：AI 审阅可以成为保证流程中的一项证据，但不能成为最终权威。真正的认证需要一条边界清晰、可以检查的证据链，并且这条证据链最终必须落在模型自身信心之外。
Jie Ma · 2026-09-13 · 研究笔记
公开 Git 历史是证据，不是 ground truth
公开仓库保存了大量软件开发记录。通过 commit、branch、review、release、revert 和 issue 链接，我们可以看到许多仅靠代码快照无法还原的变更过程。
对于治理工具来说，这些记录可以帮助我们发现可能的失败模式，并检验规则能否识别真实存在的项目状态。
Git 只记录被保留下来的内容，而不是发生过的一切
Git 无法展示团队的每一次讨论、被放弃的本地实验、生产事故、组织约束或开发者当时的真实意图。
Commit 也可能经过 squash、rebase、导入或事后补写。有些记录只是为了符合某种规范而产生。测试可能在外部系统中运行，而这些结果现在已经无法访问。
因此，一段整洁的 Git 历史可能来自一个实际问题很多的开发过程；一段看起来混乱的历史，也可能属于一个治理良好的项目。
公开仓库还存在选择偏差。开源项目和私人团队的工作方式并不完全相同；公开可见的失败不能代表所有失败；热门项目拥有的资源，也可能远多于普通小型项目。
后来出现了修复，不能单独证明之前的变更属于失职；没有找到事故记录，也不能证明之前的变更一定安全。
研究时必须把观察、推断和参考判断分开
每个负责任的研究案例都应该保留来源，包括仓库、revision、时间、可以直接观察到的事实、使用的工具和规则版本，以及复现案例所需的最少材料。
研究者还必须区分直接观察和进一步推断。例如，“某个 release tag 不包含之后的修复”是可以直接检查的事实；至于这是否说明当时存在安全风险或流程失误，则属于需要更多证据支持的判断。
如果案例本身存在歧义，就应该继续标记为“有争议”或 unknown，直到获得合适的证据或专家裁决，而不是为了方便评估而强行给出答案。
因此，我们应该把公开 Git 历史整理成经过审查的开发事件，而不能把它直接当成已经拥有正确标签的训练数据。
案例可以按照语言、技术生态、团队规模、项目阶段和失败类型进行分类。其中一部分可以公开成为开发 fixture；另一部分则应该保留用于盲测，避免规则作者根据所有已知答案反复调优。
通过这种方法，公开 Git 历史可以在创始人自己的项目之外挑战 MetaAware，并帮助我们发现 oracle、adapter 或政策规则在哪些情况下无法推广。
但公开历史本身仍然不能证明 MetaAware 普遍有效。负责任的研究结论必须说明：我们观察到了什么、这些证据支持什么解释、还存在哪些其他可能，以及下一步需要补充什么证据。
Jie Ma · 2026-09-13 · 研究笔记
AI 能否治理 AI 辅助开发？
AI 可以参与治理，但不应该成为拥有最终权威的一方。
用 AI 为 AI 辅助开发创建并执行标准，这种做法确实有价值。AI 可以寻找模式、把技术证据解释成自然语言、生成挑战场景，并帮助人们以更接近现代软件开发速度的方式进行分析。
但如果我们允许一个 AI 的信心去验证另一个 AI 的产出，这种做法也会变得危险。
先把不同角色负责什么说清楚
一个可靠的治理模型应该把责任分开。
人类负责确定项目目标、价值取向、风险承受范围和权威边界；机器负责观察可复现事实；版本化规则只根据事实能够支持的范围作出判断；AI 负责解释 finding、不确定性和可能的下一步；人类则负责批准例外、接受重要风险并承担最终责任。
这种分工并不意味着确定性规则永远不会出错，也不意味着人类总能作出明智决定。
它的作用是让错误可以被定位：观察可能不完整，规则可能表达了错误政策，AI 的解释可能误导用户，人类也可能作出错误选择。
当这些职责被清楚分开后，我们就能用不同证据检查不同环节，而不是把所有问题都隐藏在一个听起来很智能的统一答案里。
AI 应该改善交互，而不是成为证明的终点
对于已经在使用 coding agents 的开发者来说，自然语言是合理的治理界面。用户应该可以直接询问：“为什么这次发布不安全？”或者“下一步应该做什么？”
但回答必须来自可以检查的 finding，而不能只因为语言听起来合理就被接受。
AI 可以解释用户意图、总结上下文、比较不同选择并帮助用户学习。它不能静默改变政策、自行批准例外、认证自己的工作，也不能把不确定性转化成许可。
治理系统本身也需要接受治理。冻结的测试场景、独立确定性 oracle、多样化的公开历史、盲测保留案例、志愿者的前瞻性使用、真实事件结果和版本化规则变更，都可以从不同角度挑战系统。
这些证据没有任何一种可以单独成为最终的 ground truth。但把它们结合起来，可以让没有证据支持的自信更难长期存在。
因此，答案是有条件的：如果 AI 的权威受到限制、它的主张能够追溯到证据、不确定性清楚可见，而且最终判断落在独立检查和承担责任的人类决策上，那么 AI 可以帮助治理 AI 辅助开发。
如果缺少这些条件，所谓的 AI 治理就可能只是 AI 用听起来合理的解释确认自己的判断，而且整个过程会以机器速度不断重复。
Jie Ma · 2026-09-13 · 研究笔记
自然语言治理界面和确定性引擎如何共存
使用 coding agents 的开发者已经习惯通过日常语言表达自己的意图。
如果要求他们把每一个治理问题都改写成严格的命令，就会失去自然语言界面带来的重要价值。用户应该能够直接问：“这项变更为什么有风险？”“为什么系统阻止了我？”或者“现在还缺少什么证据？”
对话负责理解问题，但不能自行产生裁决
自然语言适合处理不完整的问题、解释陌生概念，并根据不同用户调整说明的详细程度。
但它不适合作为可重复治理判断的唯一来源。同一个 prompt 可能被模型作出不同理解，模型行为也可能随版本变化。即使证据不足，模型仍然可能生成一段听起来很完整的回答。
因此，合理的架构应该把对话层和决策层分开。
AI 首先把用户的问题转换成范围明确的查询。确定性引擎随后收集事实，并应用具名、版本化的规则。得到结构化 finding 后，AI 再负责解释判断、不确定性和可能的恢复步骤。
AI 可以建议用户执行某条命令或修改某项政策，但不能把建议说成已经得到批准的决定。
每个回答都必须能够追溯到可检查的状态
界面应该告诉用户：系统观察了哪些事实、使用了哪个规则版本，以及回答中的哪些内容来自确定性输出，哪些内容属于 AI 的解释。
如果用户的问题含糊，系统应该缩小问题范围、要求补充信息，或者返回 unknown，而不能静默选择一个最方便的解释。
通过这种设计，自然语言可以成为更容易使用的治理入口，但不会取代治理本身。
用户仍然可以采用对话式的使用方式，而底层判断则继续保持可复现、可测试和可质疑。
Jie Ma · 2026-09-13 · 研究笔记
如何测量治理工具的误报与漏报？
只有当一项治理 finding 在正确的时间发现了真正有意义的问题时，它才有价值。
误报是指风险实际上不存在，工具却发出了警告或阻止操作。漏报是指问题本来应该被发现，工具却没有把它呈现出来。
两种错误都很重要，但它们在不同情况下造成的成本并不一样。
先明确要检验什么，并建立可以审查的参考判断
我们不能只是让工具扫描一些任意仓库，然后根据输出数量判断它是否有效。
每个评估案例都需要明确记录所使用的规则版本、可以观察到的输入、期望检验的具体主张，以及带有来源说明的参考判断。
公开 Git 历史可以提供证据，但它不会自动成为正确答案。如果一个案例本身存在歧义，就应该把它标记为“有争议”或 unknown，而不是强行归入通过或失败。
混淆矩阵只能作为分析的起点。我们还应该按照具体规则、严重程度、仓库类型、项目阶段、证据是否充分以及用户群体，对结果进行分类。
发布完成后才出现的警告，与提交之前出现的警告，价值并不相同。一个频繁出现但影响较小的提示，与一次错误阻止发布的 finding，造成的成本也不同。
不只测量错误数量，还要测量错误造成的后果
精确率、召回率、误报率和漏报率可以描述工具发现问题的表现，但还不足以衡量治理效果。
评估还应该包括：用户理解判断需要多少时间、恢复需要多少时间、用户多频繁地选择 override、重复警告是否造成疲劳、漏报是否带来实际伤害，以及用户能否正确质疑工具的结果。
我们还可以根据严重程度赋予不同权重。漏掉一次可能破坏生产环境的部署，其影响可能远大于多次低风险警告。
没有任何一个分数能够单独证明治理工具的质量。
真正有用的评估结果应该是一份错误画像，其中包括置信区间、具体案例、已知盲区，以及产生这些结果的规则版本。
这份画像应该用来增加回归 fixture、修订规则。如果证据仍然不足，则应该缩小能力主张，或者明确返回 unknown。
Jie Ma · 2026-09-13 · 研究笔记
为什么 unknown 是合法结果
治理系统经常被期待给出明确答案。pass 和 fail 看起来容易采取行动，unknown 则容易让人觉得系统不够有能力。
但如果现有证据根本无法支持结论，那么给出确定答案并不是果断，而是在编造确定性。
Unknown 帮助我们区分“不存在”和“没有观察到”
如果仓库中没有测试记录，可能是因为测试根本没有运行，也可能是结果保存在其他系统里，还可能只是当前 adapter 无权访问。
这几种情况并不相同。
如果系统把缺失证据当成 pass，就会制造虚假的安全感。如果系统自动把它当成 fail，又会把“没有看到证据”错误地说成“已经证明存在问题”。
一个诚实的 unknown 不应该只有模糊的一句话。它应该明确说明：哪个问题还没有答案、系统已经检查了哪些证据、为什么这些证据仍然不足、还需要什么信息才能消除不确定性，以及在得到这些信息之前是否需要人类作出决定。
unknown 仍然可能触发保守的政策措施，例如暂缓发布。但系统必须明确区分两件事：暂缓发布是一项政策决定；证据不足则是对当前认识状态的描述。
Unknown 也可以帮助我们发现系统缺少什么
如果某一类 unknown 反复出现，往往说明 adapter、项目声明、证据契约或团队实践中存在缺口。
记录这些 unknown 出现的原因，以及它们最终如何被解决，可以帮助团队决定下一步应该改进什么，而不需要假装缺失的信息已经存在。
成熟的治理工具并不是一个永远都能给出答案的工具。
真正成熟的工具应该知道现有证据能够支持什么结论，能够清楚说明判断边界，并帮助用户取得下一项必要证据。
Jie Ma · 2026-09-13 · 研究笔记
Agentic AI 的审批与责任边界
Agentic AI 可以规划、编辑、测试、部署、对外沟通，并且能够在有限监督下持续工作。
因此，审批机制不能只是执行前出现的最后一个确认框，而应该成为整个系统架构的一部分。
真正需要回答的问题不是 agent 是否“自主”，而是：它可以在谁的授权下采取行动、依据什么证据、产生哪些影响，以及出现问题后怎样停止或恢复。
应该根据行动后果划分权限
只读检查、本地可逆编辑、对外发送信息、修改生产环境、作出财务承诺、访问凭据和执行破坏性操作，应该属于不同的权限等级。
每一次审批都应该明确绑定执行者、具体操作、目标、影响范围、有效时间和证据快照。
用户批准了一次发布，不应该被系统静默解释为今后所有发布都已获得长期授权。
Agent 在执行重要操作之前，应该让用户看到将要发生的变更，并明确说明哪些内容会受到影响。执行后，它还应该保留审计记录并验证结果。
有时限的例外需要明确的责任人和理由。如果项目状态在批准之后、执行之前发生了变化，系统就应该重新评估原有批准是否仍然有效，而不是机械地继续使用。
人类承担最终责任，但系统必须让这种责任真正可行
如果界面隐藏了不确定性、把无关操作捆绑在一起，或者让用户很难拒绝，那么一句“人类已经批准”并不能证明审批是有意义的。
要让人类真正承担责任，系统必须提供容易理解的证据，设置与风险相称的确认成本，允许用户质疑建议，并明确执行之后由谁负责处理后果。
工具设计者也不能把所有责任都推给最终点击批准的人。对于审批系统中可以预见的失败方式，设计者同样负有责任。
目标既不是让系统不断打断用户，也不是允许 agent 不受限制地行动。
更合理的方式是分级自主：当操作范围和恢复方法都很明确时，允许系统自动执行；当后果或不确定性增加时，把决定升级给人类；同时确保任何 agent 都不能仅仅因为能够解释“扩大权限会更方便”，就自行扩大自己的权威。
Jie Ma · 2026-09-13 · 研究笔记
治理能力是否可以被量化？
治理能力并不是一种单一能力。
它包括能否发现相关问题、准确解释问题、支持合理决策、从错误中恢复、调整规则，以及帮助用户学习。
把这些内容全部压缩成一个“成熟度分数”看起来很方便，但也可能隐藏治理系统本来应该暴露的弱点。
应该建立测量模型，而不是追求一个好看的数字
比较可靠的评估方法，是把治理能力拆成多个维度，例如覆盖范围、发现准确性、发现是否及时、解释质量、恢复成功率、例外管理、可追溯性、用户理解、把经验应用到新场景的能力，以及外部有效性。
每一个维度都需要明确说明具体测量什么、数据来自哪里，以及结果中还存在多大的不确定性。
有些指标可以直接测量。例如，工具是否发现了确定性 fixture 中的问题，或者恢复检查是否通过。
另一些指标则需要专门设计人类评估。例如，用户是否真正理解了理由，或者以后是否作出了更好的决定。
如果使用代理指标，就应该明确说明它只是代理指标。规则数量、警告数量和批准次数，只能说明系统发生了多少活动，不能直接证明治理结果变得更好。
量化结果应该帮助我们改进系统
分数只有在定义保持稳定时才适合比较。例如，我们可以比较同一条规则的不同版本、比较不同受控群组，或者把结果与冻结的基准进行比较。
如果用同一个分数排列彼此完全不同的项目，或者根据这个分数声称系统具有普遍安全性，结果就很难令人信服。
汇总结果还应该同时展示置信区间、缺失数据比例、不同群体之间的差异，以及有代表性的失败案例。
因此，治理能力确实可以被测量，但测量结果应该是一份多维、受证据约束的能力画像，而不是一个代表绝对权威的单一分数。
量化的目的，是帮助我们决定系统还应该改进什么，以及当前证据允许我们提出哪些主张，而不是制造一个看起来客观的认证徽章。
Jie Ma · 2026-09-13 · 研究笔记
开源治理规则如何避免成为创始人个人习惯的编码？
每个治理项目都会从某些人的经验出发。这些经验非常有价值，但个人习惯也很容易被包装成适用于所有人的最佳实践。
例如，创始人偏好的分支策略可能被写成强制规则；某一种部署流程可能被当成安全的唯一标准；创始人经常遇到的错误，也可能被误认为每个用户都会遇到的风险。
把可以普遍复用的机制和项目自己的选择分开
MetaAware 的核心应该负责那些可以跨项目复用的观察和评估机制。
policy packs 应该保存适用于特定场景、同时允许人们提出质疑的政策选择。项目配置负责表达本项目自己的约束。面向人的指南则负责解释规则为什么存在，以及还可以有哪些替代方案。
把这些内容分开后，其他团队就可以复用 MetaAware 的引擎，而不必同时接受创建者的每一项个人偏好。
每条规则都应该说明自己的目的、证据要求、适用范围、严重程度、已知例外、恢复方法，以及它不能证明什么。
规则的来源也应该清楚可见。例如，它来自一次真实事件、某项标准、社区经验，还是尚待验证的设计假设。
版本化提案和变更记录应该把分歧公开保留下来，而不是让维护者静默地按照自己的偏好作出决定。
多样性必须真正影响规则，而不能只体现在参与人数上
来自不同生态的公开仓库和维护者、新手与专家用户、安全从业者、发布工程师，以及使用不同工作流程的团队，都应该能够用反例挑战 MetaAware 的规则。
贡献模板可以要求提交者同时提供具体场景和预期行为。盲测和前瞻性使用则可以检验一条规则能否在创建者熟悉的环境之外继续成立。
开源本身不会自动产生多元治理。维护者仍然需要透明的决策过程、利益冲突披露、申诉机制和规则弃用路径。
如果证据不能支持一条规则在不同项目中使用，维护者就应该愿意让它保持可选，或者直接将它移除。
创始人的经验应该作为规则来源清楚地展示出来，而不能被包装成适用于所有人的普遍真理。