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

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

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

我现在越来越不想讨论“提示词怎么写得更聪明”了。不是 prompt 不重要，而是很多 agent 项目一旦进入第二周，真正拖垮迭代速度的通常不是提示词，而是你根本不知道它上一次为什么成功、这一次为什么失败、换个模型以后到底退化了多少。 说得直接一点：没有 traces 和最小 eval 集，很多所谓的 agent 调优其实只是情绪化开发。今天觉得它…

这两年很多人都在说“别绑死单一模型厂商”。这句话本身没错，但我越来越觉得，很多团队把它理解得过于轻巧了。模型切换当然重要，可一旦你真的开始同时接多家模型、多条 fallback、多套预算和日志，问题就不再是 SDK 调用层那点事，而是一个标准的基础设施治理问题。 也就是说，真正难的不是把 provider 名字从 openai 换成 anthrop…

我一开始以为，做 agentic coding 最烦的是模型会不会理解项目上下文。后来发现，更麻烦的问题其实是：你到底让它在什么边界里动手。 上下文不够，最多是改不对；运行边界不清，才会把事情真的搞乱。尤其是当工具开始能主动跑命令、改文件、串联多步操作以后，“权限提示太频繁”并不只是体验问题，它其实在提醒你：这件事本来就不该被轻易跳过。 为什么我觉…

我原本以为 AI 编程工具进入“agent 模式”以后，团队最先感受到的会是开发速度明显提升。后来我发现，很多仓库里先被放大的不是编码效率，而是审查效率。 原因不复杂：当工具还只是补全时，它主要影响一个人写代码的速度；当它开始自己起分支、改多文件、跑测试、做自检时，瓶颈就从“写得快不快”转成“你有没有能力把它审得明白”。如果审查链路没准备好，age…

我最近越来越不想看那种“多 Agent 协作架构图”了。不是因为它们完全没用，而是很多团队在真正跑起来之前，连最外层那层壳都没搭对：任务怎么启动，状态怎么收敛，工具怎么限权，日志怎么回放，失败后怎么继续。这个阶段谈一堆 Planner、Researcher、Reviewer，通常只是在给未来的维护成本提前贷款。 这也是我为什么会重新看 OpenAI…

我看到 GitHub Copilot 在 JetBrains 相关更新里支持全局自定义 Agent，可以把 .agent.md 放到 ~/.copilot/agents 下面，让多个工作区复用。第一反应是：这东西对个人开发者很方便。第二反应是：它也很容易变成新的配置债。 开发工具一旦支持“全局规则”，就会诱惑我们把所有个人偏好都写进去。短期确实省事…

很多人期待长任务编程 Agent，是因为它看起来能把“我想要一个功能”直接变成 PR。我对这个期待比较谨慎。Agent 能跑更久，能自己读文件、改代码、跑测试，当然是进步。但它越能自主执行，越暴露一个老问题：需求如果写得像聊天，最后就会得到一个像聊天一样含糊的实现。 OpenAI 在 Codex 相关技术文章里讲过 agent loop、工具调用、…