应用 AI
14 篇
RAG 不是一条必经流水线，而是一种按需取证的能力
先理解目标、先看当前源码，只有跨来源信息真的能改善判断时，才调用 Local RAG 去找证据候选。
一次代码命中为什么还不算答案
工程检索必须把结果绑到仓库、commit 和 symbol 上；缺失、过期或来自错误仓库的命中，只能当定位线索。
怎样把检索候选变成可以交付的工程结论
检索负责发现入口，原始来源负责确认事实；最终回答必须把已验证、推测和未知分开。
同一个问题，代码、Jira 和 Confluence 各能回答到哪里
跨来源检索真正难的不是找到更多文本，而是判断需求、设计和当前代码分别能证明什么。
什么时候值得调用 Local RAG，什么时候直接读源码更快
我缺的是事实，还是入口？这一个问题就能决定要不要检索。
从 Workflow Harness 到轻量 Prompt：Codex 5.6 之后我删掉了什么
当模型的原生流程已经够强，Harness 会从效率放大器变成上下文负担。这次重写保留了安全边界，同时大幅精简 Prompt 和运行时。
目标路由：「帮我改一下」和「帮我发个 PR」不该走同一条路
路由不是给请求贴标签，而是先确定这次授权了哪些副作用、什么证据才算完成。
上下文加载：解释「怎样加载上下文」本身也在消耗上下文
用证据优先级、可重建句柄与新鲜度指纹控制每一轮推理真正需要看到的材料。
阶段图：模型要先理解任务，还要再理解一张描述任务的图
用可验证的 DAG 表达节点依赖、执行权限、完成屏障、失败传播与恢复边界。
叫来一队 Agent，不等于做过多角度评审
用风险驱动选择、不可变执行计划、隔离上下文、完成屏障和证据化报告控制多 Agent 协作。
为什么 LLM Controller 最多只允许两轮检索
LLM 可以改写、重排和请求一次补充检索，但不能覆盖确定性证据校验，也不能无限搜索。
DocumentIR、Issue IR 与 CodeIR 为什么必须分流
文档、工单和代码拥有不同结构；先建立 Typed IR，才能正确分块、构图并保留可追溯位置。
顶层配置只留四条硬规则：Agent 在哪里必须停下来
模型可以越来越自主，但生产、持久化数据、成本和不可逆动作必须先经过明确授权。安全不是效率的对立面，而是自动化成立的前提。
我给自己的 AI 研发流程写过一套控制平面
拆解一套强调可追溯、可恢复和权限隔离的文件式 AI 研发控制平面。