正在打开每日关注
正在打开每日关注
以函数级影响分析和 L1-L3 权限分级，降低 Agent 改码的合并风险。
𝗕𝗹𝗮𝘀𝘁 𝗿𝗮𝗱𝗶𝘂𝘀 i'm about to change [file/module]. don't write any code yet. use codebase memory to map the repo into one graph, read my uncommitted diff, map every change to the functions it touches, and return: each function, its downstream blast radius, and a risk level. once it's ranked by risk, 𝗮𝗰𝘁 𝗮𝘁 𝘁𝗵𝗿𝗲𝗲 𝗹𝗲𝘃𝗲𝗹𝘀 𝗼𝗳 𝗮𝘂𝘁𝗵𝗼𝗿𝗶𝘁𝘆: L1 low risk, just do it: local, covered by tests. L2 medium risk, isolate it: one revertible commit per change, with before/after. L3 high risk, propose only: anything touching an interface, data, or a shared dependency, give me the plan, don't touch it. then tell me where it's most likely to break before i merge. → i see which function will blow up before i merge, and which ones it can fix itself vs which ones wait for my call.
是什么 这条推文提出一套给编码 Agent 使用的“变更前评估—授权”协议。它要求 Agent 暂停写码，先借助代码库记忆把仓库抽象成依赖图，再读取未提交 diff，把每个改动映射到受影响函数，最后按风险决定可执行范围。重点不是生成代码，而是在生成代码前建立可审计的影响边界。
核心设计 L1 将局部且已有测试覆盖的改动交给 Agent 直接处理；L2 对中风险改动采用每项一个可回退提交，并保留前后对照；L3 对触及接口、数据或共享依赖的高风险改动只给方案，等待人工调用。这把权限从一次性全权委托改成按风险逐级收敛，兼顾自动化速度和人工控制。
关键洞察 “blast radius”把审查单位从文件扩展到函数及其下游消费者，能更早暴露合并后可能断裂的位置；“哪些可自修、哪些需等待”则把 Agent 的自治边界写成明确策略。
边界与风险 代码库记忆可能过期，静态依赖图也可能漏掉运行时反射、配置、迁移、外部服务和数据契约；测试通过不等于影响可控，“一个提交一个改动”也会增加提交管理成本。因此它更适合作为变更分流和审查清单，不能替代真实构建、集成测试、回滚演练及业务人工判断。