Dai Wei

把代码评审交给大模型，最难的不是让模型看懂代码，而是让整套流程稳定、可控、可负担。阿里开源的 Open Code Review（内部使用两年后对外发布，Apache-2.0）给了一个很有参考价值的架构答案：确定性流水线兜底流程，Agent 只做判断。 AI 代码评审的核心矛盾最直觉的做法是把 Git diff 整个丢给大模型，加一句”请评审这段代码”。做过的人都知道这条路走不远，问题出在四个地方： 漏报不可控：一次 diff 可能涉及几十个文件，塞不进上下文就得截断，模型评审了哪部分、漏了哪部分，你无从知晓 噪音淹没价值：模型自由发挥时倾向于”多报以示勤奋”，十条评论里九条是风格建议，真正的 NPE 风险被淹掉 定位漂移：模型说”这个变量可能为空”，但评论落在错误的行号上，开发者还得自己找 成本失控：全量上下文 × 每次提交 × 全部仓库，token 账单会迫使项目下线 这四个问题的共同根源是：把流程正确性也交给了概率模型。而流程恰恰是确定性工程最擅长的事。 混合架构：确定性兜底 + Agent 判断Open Code Review 的设计哲学是”确定性工程 × Agen...

Trae 是字节跳动推出的 AI 编程 IDE，基于 VS Code 生态，支持接入自定义大模型。本文以 MiniMax M2.7 为例（换其他模型流程一致），用两个场景走完整流程：一次线上接口超时的排查与止血，以及把 Redis 慢查询指令从 C 源码复刻到 Go。 背景与接入图形化 IDE 的价值在于把日志、断点、diff 审查和 Agent 对话放进同一窗口，适合偏好可视化验证的团队。接入自定义模型只需四步：下载安装 Trae；到模型平台创建 API Key；在设置里点”Add Model”选择”Other Models”；填入模型 ID（如 MiniMax-M2.7）与 Key，无报错即接入成功。 两个场景的选择有讲究：场景一考”在多处使用 Redis 的项目里快速定位根因”，场景二考”跨语言重构与源码理解”，都是日常后端开发中耗时但典型的活。 场景一：接口超时的止血与根因定位故障现场（脱敏复刻）：列表查询接口返回 500，异常堆栈的关键字是 Read timed out，对应代码段是一次普通的 get(key)。按经验这只是表象——项目里多处用到 Redis，逐一排...

Kimi K3 的卖点是长程 Agent 编程：1M 上下文、原生多模态，让 Agent 在长任务里持续读代码、看截图、跑工具、修问题。本文用三个递进的案例检验这套说法：从 0 到 1 的全栈热点追踪系统、存量 Java 项目的修复与加特性、以及一个可玩的第三人称动作游戏 Demo。 背景与接入K3 支持主流 Coding Agent 框架。最短路径是官方的 Kimi Code CLI：安装后在项目目录执行 kimi，/model 选择 k3 即可让它读代码、改代码、跑命令。已经在用 Claude Code、Roo Code 或 CC Switch 的，不必重搭工作流——创建 Kimi Code API Key 后通过兼容接口接入，K3 只负责模型推理，读文件、调工具、管权限仍由外层 Agent 框架处理。 正式开跑前建议先做一次只读小测试：”阅读当前项目的目录结构和核心代码，说明各模块职责，先不要修改文件”——确认上下文理解正常再放权。 案例一：HotPulse 热点追踪系统（长程交付）验收目标是一套能跑的 MVP：用户创建关键词 Monitor，系统定时或手动抓取 Hac...

测试开发是值得认真考虑的方向，但前提是你理解它和传统测试的本质区别，并接受它对编程的真实要求。这篇讲清测开做什么、学什么、前景如何。 测开与业务测试的区别传统业务测试回答的问题是「这个功能有没有问题」；测试开发（SDET）要往前多走两步：为什么这个问题会漏掉？以后能不能让机器自动发现？这类问题能不能沉淀成工具、平台或流程？ 落到日常工作上，区别很具体：业务测试的主要产出是用例执行和缺陷报告；测开的主要产出是自动化框架、测试工具、质量平台和定位问题的脚本。代码量未必比业务开发大，但对工程链路的理解要更完整——你测的是系统，用的也是系统工程。 所以别再把测开理解成「后端学不动后的退路」。只会手工测试加几条 Selenium 脚本没有竞争力；真正有竞争力的是能写框架、能接 CI/CD、能看日志定位问题的人。 技能栈拆解编程基础。 一门主语言必须扎实：Java 方向补 JUnit、Rest Assured、Spring Boot；Python 方向补 pytest、requests、Playwright。已有 Java 基础就别为了测开重学 Python，后端经验在测开岗位...

JetBrains 重度用户常有个纠结：主流 AI 编程工具大多基于 VS Code，切过去舍不得 IDEA 的调试与重构体验，CLI 工具又缺少直观的 diff 交互。Qoder 的 JetBrains 插件提供了”一体派”选项。本文用两个 Java 后端典型任务检验它：千万级订单表的深分页优化，以及一段 150 多行祖传退款代码的重构与迭代。 背景与上手后端开发者用 AI 工具大致分四类：纯 CLI 派、VS Code 派、”CLI 写 + IDEA 验收”的混合派、以及 JetBrains + 插件的一体派。Qoder 插件面向最后一类：心流不打断，一个窗口完成分析与改动。 安装很常规：Settings → Plugins 搜索 “qoder” 安装，登录后可在插件设置里切中文界面。一个值得提前做的可选配置是数据库连接：Qoder 支持 @database 上下文，能直接引用表结构与索引信息——注意它只能补充 Schema，不能替代线上执行计划和真实数据分布。 任务一：千万级订单表的深分页优化故障现场：运营报表接口 POST /api/report/orders，请求参...

DeepSeek V4 Preview 发布后即开源，并提供 Anthropic 兼容接口，Claude Code 无需协议转换即可对接。本文不看跑分，直接把它放进真实代码库：用五个任务检验 V4-Pro 和 V4-Flash 分别适合干什么、在哪里会掉链子。 背景：为什么拿到 Claude Code 里测对话和写作类能力，开源模型已经相当成熟；但 Agent Coding 是另一回事——自主分析项目结构、理解多文件依赖、给出能落地的工程方案，对代码能力和工具调用稳定性都有要求。技术报告和社区测试之外，更值得关注的是它进入真实仓库后的表现。V4 同时提供两款模型：V4-Pro 与 V4-Flash，均为 1M 上下文、MIT 协议；官方报告中的 Codeforces、SWE-bench 分数属于厂商公布的历史快照，不能替代自己代码库上的评测。 上手：两种接入方式配置文件法（推荐）：编辑 ~/.claude/settings.json，在 env 字段写入后端地址、模型名与 API Key——ANTHROPIC_BASE_URL 指向 DeepSeek 的 Anthropic ...

MiniMax M3 的官方定位是”1M 上下文、原生多模态、面向 Coding 的开放权重模型”，但榜单分数不代表真实工程表现。本文把它接进 Claude Code，用三个递进的任务检验：线上 Redis 故障排查、SCAN 游标算法的 C→Go 复刻、Redis 监控面板从零搭建。 背景：用真实故障代替跑分官方公布的基准（SWE-Bench Pro、Terminal-Bench 等）对应指定评测集与配置，不等于在你的代码库里的表现。更有说服力的检验方式是拿真实问题上手： 故障排查：复刻一次线上故障——大促期间”超时订单自动取消”的异步任务在跑，同时页面热点数据大面积超时，线索指向后台任务里的完整 Redis SCAN 循环； 底层复刻：把 Redis 源码中 SCAN 的游标算法从 C 移植到 Go 学习项目 mini-redis； 监控落地：从零搭建前后端的 Redis 监控面板。 接入走 cc-switch：添加模型配置、填入 API Key、拉取模型列表后把主模型设为 M3，回 Claude Code 对话面板确认生效即可。 任务一：故障排查，证据驱动而非一次定...

Claude Code 支持通过 Anthropic 兼容接口接入 GLM 等第三方模型：工具调用、权限模型保持不变，只换推理后端。本文用两个互补场景走一遍完整流程——从零搭建基于 Arthas 的 JVM 智能诊断 Agent，以及在百万级数据的订单系统里治理慢查询。 背景：为什么要换后端模型已经搭好 Claude Code 工作流的团队，常有成本或合规上的考量，不能使用默认模型。部分服务商会提供 Anthropic 兼容接口，配合环境变量即可把请求路由到自己的模型。 需要先建立两个认知： 接入方法不绑定具体模型：以 GLM-5.1 为例记录的流程，在后续版本或其他兼容模型上同样适用。 兼容不等于等价：兼容程度、可用功能和数据处理方式由服务商决定，不能默认与官方模型完全一致，能力边界要靠任务验证。 选这两个场景，是因为它们正好覆盖 AI 辅助编程的两种典型模式：场景一是”从 0 到 1”的工程交付，考验规划与批量编码能力；场景二面对既有代码库做增量优化，考验对旧架构的理解能力。 上手：接入与配置整体三步：先安装 Claude Code 本体；再用 cc-switch 这...

CC GUI 是一款 MIT 协议的开源 JetBrains 插件，为 Claude Code 和 OpenAI Codex 这两个终端 Agent 补上图形界面：会话、diff 审查、MCP 配置都在 IDEA 内完成。本文以 v0.4.7 为快照介绍安装、认证与典型用法，插件迭代较快，细节以项目 README 为准。 背景：它解决什么问题Claude Code、Codex 这类 CLI Agent 能力强，但看 diff、贴截图、管理会话在终端里都不够直观。JetBrains 体系内有两条补齐路线： ACP 路线：IDE 内置 Agent 集成、ACP Registry 中的 Agent、手动配置的 ACP Agent，复用 JetBrains 的 AI Chat 与 Diff 能力。这三者是不同层次的能力，不能统称”官方插件”，可用范围随 IDE 版本与账户变化。 CC GUI 路线：独立社区插件，专为 Claude Code/Codex 做会话管理、图片输入、Agent 与 MCP 的 GUI 封装。 两条路线不冲突，按偏好选择即可。以 v0.4.7 为...

Claude Code 里的多代理机制，本质上是一种上下文治理手段：主会话负责判断和落地，容易把上下文弄脏的支线工作拆给独立 worker，并行提速只是任务可拆分之后的副产品。本文梳理 Subagent、Subtask、Fork、Agent Teams 四种机制的差异、任务委派方式与协调成本。 为什么需要多个 Agent单会话处理跨模块任务时，麻烦集中在两点。一是过程信息膨胀：排查一个慢查询，搜索命中的无关文件、旧日志、被推翻的方案全留在上下文里，等真正动手改代码时，模型得从这堆过期材料里捞重点。二是任务惯性：刚分析完数据库问题，转头去审前端组件，上一轮的思考方式很容易被带过来。 多代理要解决的就是这个问题——保护主会话。主会话保留判断、计划和最终决策，搜索、验证、审查这些过程交给独立窗口执行，只回收结论。 四种机制按解决的问题区分： 问题 机制 说明 支线搜索污染主会话 Subagent 子代理独立工作，主会话只拿结果 想复用当前上下文做支线 /subtask 会话内派生，继承父会话上下文 复制对话后独立继续 /fork 创建可单独恢复的后台 Sessi...