我一开始以为 AI Coding Agent 最大的价值，是把代码写得更快。后来越看越觉得，这个判断有点偏。 真正值得关心的不是“它能不能帮我写一个函数”，而是它能不能接住那些开发者不想亲手处理、但又必须有人处理的工程杂活：读一遍旧代码、改几个边界条件、补测试、跑命令、整理 PR、根据反馈再改一轮。 OpenAI 在 Codex 的介绍里，把它定义…

我最近越来越少把 AI 编程工具当成“更聪明的自动补全”来看。 这个判断可能有点反直觉。因为大多数人第一次用 Copilot、Claude Code、Codex 这类工具时，最直观的感受确实是：它能帮我写代码。写一个函数、补一段测试、改一个 CSS、生成一段 SQL，看起来都挺顺手。 但如果你真的把它放进一个已有项目，而不是在空白文件里让它表演，问…

我最近对 AI 编程 Agent 的看法有点变了。 以前我更关心它能不能写出可用代码：能不能理解项目结构，能不能改对类型，能不能自己跑测试。现在我觉得这已经不是最值得纠结的问题。真正麻烦的是：当 Agent 开始接入 GitHub、Playwright、MCP server、CLI、本地文件系统和云端环境以后，它不再只是一个“会补全代码的聊天框”，…

每次有更强的编码模型发布，讨论总会很快滑向排行榜、分数和“谁又第一了”。这些信息当然有参考价值，但我越来越觉得，对个人开发者来说，真正重要的问题不是模型又涨了多少分，而是你的工作流有没有跟着升级。如果工作流没变，模型再强，很多收益最后也只会停留在“写得更快一点”。这不是没用，但远远没有到值得大惊小怪的程度。为什么我现在不太执着 benchmark因…

我对 GitHub Copilot coding agent 的态度，最近变得比一年前更实际了：不是更兴奋，而是更明确它适合干什么。如果让我用一句话概括，我会说：它现在更像一个适合处理 backlog 的后台工程助手，而不是一个可以替你做系统设计的自动程序员。为什么我会改这个判断过去大家对 coding agent 最大的担心，是它做出来的东西“能…

很多人用 AI 写代码，第一反应是直接把需求丢进去，然后期待它吐出一个能跑的结果。我自己试得越多，越觉得这种方式在小 demo 里很好，在真实项目里却很容易把返工提前透支掉。这也是我现在更看重 spec-driven development 的原因：它看起来慢，但它其实是在把那些原本会在 review、联调、回归阶段爆出来的问题，提前拉到最前面。它…

我现在越来越愿意把背景编码 Agent 当成一个能消化 backlog 的工具，但我仍然不建议把核心架构改造、跨模块重构、关键业务规则迁移直接扔给它。原因不是它完全做不好，而是这类任务真正难的部分往往不在“写代码”，而在判断隐含约束、识别历史包袱、控制改动半径。这些地方，今天的 Agent 还远没有宣传里那么稳。为什么这个话题现在值得写过去一年里，…

我现在越来越不相信“这个编码代理看起来还不错”这种判断了。因为它通常只意味着两件事：要么演示做得顺，要么你刚好让它撞上了一个适合发挥的样例。真正进入工程环境之后，问题不是它能不能偶尔写出一段对的代码，而是它在重复任务里能不能稳定地走对流程、少犯同一类错、让审阅成本真的下降。 OpenAI 在 2026 年初公开的《Testing Agent Ski…

我原本以为，2026 年 Agent 这一波继续往前走，最值得追的是模型升级。后来越看越觉得不对。模型当然还在进步，但真正开始决定系统能不能长时间稳定工作的，越来越像是另一个层：上下文工程，以及围绕它长出来的技能层。 Anthropic 在 2025 年专门写了 Effective context engineering for AI agents…

我一开始以为，所谓云端编码代理，只是把 IDE 里的补全和对话面板搬到浏览器里。后来越看越觉得不是这么回事。真正的变化不在“能不能写代码”，而在它开始接管一整段原本需要人类持续盯着的工程流程：拉代码、看上下文、跑命令、修失败、继续尝试、最后给出可审阅结果。 这件事为什么值得单独写？因为它意味着开发者工具正在从“交互式助手”变成“可持续运行的任务执行…