从能写代码到可治理的 AI Coding

AI 可以持续修改文件之后，工程里的一个问题变得更具体了：怎样知道它改了什么，为什么这样改，以及出现问题时能退回哪里？

我会先把这些问题落在一次任务上，而不是马上设计一个庞大的管理平台。

边界不能只看文件夹

目录能够提供线索，但不能独立决定风险。一份 Markdown 也可能保存发布规则，一段测试代码也可能访问真实环境。反过来，业务源码中的小修正未必需要与数据迁移一样的流程。

更有用的判断是：修改影响什么行为，有没有外部写入，会不会接触敏感数据，恢复代价有多大。再据此决定需要哪些检查和授权。

验证要对应原来的目标

构建通过能回答一部分问题，不能说明用户行为正确。还要检查原始要求是否满足，修改有没有扩大范围，以及失败路径是否被考虑。

有些结果可以用确定性检查判断，有些仍需要人工阅读和比较。把它们分别列出来，比笼统要求 Agent “自我反思”更容易执行。

回退需要事先想好

能够查看差异、保留变更记录，有助于解释发生了什么。涉及外部系统时，还要单独考虑恢复方式；撤回代码并不一定能撤回已经执行的操作。

因此，我更倾向于让任务保持可检查的大小。一轮修改完成后留下结果和证据，再决定继续，而不是累积到最后才一次性判断。

怎样知道治理有用

规则越多，不代表系统越可靠。可以检查重要操作是否有明确边界、结果是否有对应证据、失败后能否定位与恢复。

这仍然不能给出一个简单的安全百分比。它至少能让团队看清：哪些地方已经有检查，哪些地方仍依赖假设，以及下一项最值得补上的机制是什么。