Open Code Review
确定性规则在前、LLM 在后的混合代码评审,这是唯一能过企业安全评审的顺序。
确定性规则在前、LLM 在后的混合代码评审,这是唯一能过企业安全评审的顺序。
给并行编码 Agent 用的 git worktree 命令行工具,让多个 Agent 不再互相踩工作区。
一套给编码 Agent 用的可复用技能集——决定 Agent 是「完成任务」还是「按你的方式完成任务」。
让 Agent 编码走向主流的终端原生工具,也是现在所有其他编码 Agent 的参照系。
并行跑一堆编码 Agent,同时继续用你已经在付费的订阅——成本模型本身就是产品。
一层路由,让某个供应商限流时你的编码 Agent 还能继续跑——光是自动回退这一项就值。
去掉生成文本里那些「一眼 AI」的节奏特征——有用,同时也提醒你这些特征现在已经众所周知。
一份明确可读的清单,列出二十来种让文本「读起来像生成」的模式——当检查清单比当过滤器更有价值。
从 pip install 到能用的检索器,距离最短——这也是为什么几乎所有 RAG 教程都从这里开始。
用 schema 校验模型输出,而不是祈祷——校验失败还会带上错误重新问一次。
给 Agent 跨会话的连续性——当用户开始期待「它记得我」时,缺的就是这块。
把 LLM 追踪变成标准 OpenTelemetry span——这样它们就能落进你已经在付费的那套可观测性栈里。
自托管只有在利用率超过某个门槛后,才在每 token 成本上赢过 API。而几乎没人达到那个门槛——低于它时,你在为闲置算力和工程师注意力付费,只有前者会写进表格。
微调编码的是行为,检索提供的是事实。问「哪个更好」是问错了问题——该问的是底层知识多久变一次,以及你是否需要引用来源。
每个多租户 RAG 最终都会发现同一件事:检索之后过滤结果不是隔离。过滤必须约束搜索本身,而不是裁剪它的输出。
公开的跑分表比的是公开数据集上的召回率,而那不是你的数据集、你的过滤条件,也不是你的查询分布。真正决定结果的是四个运维层面的问题。
风险不在于模型说错了什么,而在于 Agent 做错了什么——而且是带着凭证,在一个没有撤销按钮的系统里做错。
两年来的建议都是「把提示词写好」。这条建议在模型变得能稳定遵循指令之后,基本就不再产生收益了。它至今仍然做不到的事情是:推断出你根本没给它的信息。
切分策略、重排配置、评测方案,以及让每个 RAG 演示在第三周死掉的七个失效模式。