夜雨聆风适合谁看
这篇适合三类人：
• 已经在用 Cursor、Claude Code、Codex、GitHub Copilot，但还停留在“让 AI 补代码”的人。 • 想看懂美国大厂为什么突然都在讲 coding agent、review agent、long-running task 的人。 • 负责团队工具、研发流程、AI 提效的人，尤其是正在纠结“要不要让 AI 进代码仓库”的人。
太长不看版
• AI 编程的主战场正在换位置。 过去比的是“单次补全准不准”，现在比的是“能不能接住一个工程任务，读仓库、改代码、跑测试、解释风险”。 • 美国大厂不是在做更聪明的输入框，而是在做可委托的执行层。 OpenAI 的 Codex、GitHub Copilot 的 code review、Claude Code 这类产品，本质都在把 AI 塞进软件生产流程。 • 真正的门槛不是模型会不会写代码，而是工程控制系统够不够硬。 权限、上下文、测试、回滚、费用、团队规范，决定了 coding agent 是生产力，还是一个会批量制造麻烦的自动化实习生。
先从一个小变化说起
我最近看 AI 编程新闻时，最明显的感觉是：大家不再满足于“AI 能写一段代码”了。
两年前，一款 AI 编程工具只要 autocomplete 做得顺手，能在你打 useEffect 的时候猜出下一段，就已经很像未来。现在不行了。现在大家问的问题变成：
“我能不能把一个 issue 直接丢给它？”
“它能不能自己读 repo？”
“它改完能不能跑测试？”
“它能不能知道哪些文件不能碰？”
“它能不能像人一样写 review comment？”
这不是小功能升级，而是工作位置变了。
以前 AI 坐在你的光标后面，像一个很会抢答的输入法。现在它开始坐到任务流里面，像一个可以被分派工作的执行层。这个变化一旦发生，软件团队要讨论的就不只是“哪个模型更聪明”，而是“我们敢把什么工作交给它”。
我倾向于把这轮变化叫做：AI 编程从补全时代，进入工程代理时代。
事实层：美国大厂正在把 AI 放进工程流程
我把最近公开资料里比较确定的事实整理成一张表。这里不追求把每条新闻都列全，只抓能说明趋势的点。
AGENTS.md，并改进 UI | |||
这里我最在意的不是某个模型分数，而是几个关键词反复出现：repo、task、review、agent、workflow、rules、credits。
这些词连起来，已经不是“写代码”本身，而是“软件生产流程”。
补全时代：AI 只是在帮你敲键盘
先把旧时代讲清楚。
补全型 AI 编程工具的价值很直接：减少打字，减少查 API，减少样板代码。你写一半函数，它接着写；你写一行注释，它补出实现；你忘了某个库的用法，它帮你凑出来。
这个阶段的用户体验很像开了一个超级自动补全。它有用，但责任边界非常清楚：
• 你决定任务； • 你决定文件； • 你决定架构； • 你决定要不要采纳； • AI 只是给候选代码。
也就是说，AI 的工作发生在“光标附近”。
这种模式最适合确定性任务：写一个 helper、补一个测试、生成一段 SQL、把一个函数翻译成另一种语言。问题是，真实工程里的麻烦通常不在这里。
真实工程里的麻烦是：
• 需求不完整； • 历史代码有债； • 改一个地方会牵动三个模块； • 测试没覆盖； • README 过期； • 团队有自己的隐性规则； • 线上事故不是因为少写了十行代码，而是因为边界条件被忽略。
补全工具能帮你写得快，但不一定能帮你少犯系统性错误。
这也是为什么很多人用了一阵 AI 编程后会有一个微妙的落差：一开始觉得它很神，后来发现真正耗时间的不是“写”，而是“确定该怎么改、改完怎么证明没坏”。
工程代理时代，恰好是往这个方向走。
工程代理时代：AI 开始接任务，而不是只接句子
一个 coding agent 如果只是“聊天框里能生成代码”，我不觉得它有多新。真正的新意在于它必须同时具备几类能力。
第一，能读上下文。
不是读你复制进去的一段文件，而是理解一个 repo 的结构、依赖、测试方式、命名习惯、错误处理风格。没有这个能力，它每次都像临时外包，只能写看起来像样的片段。
第二，能执行动作。
它要能改文件、跑命令、看测试失败、继续修。没有执行层，它就是一个建议生成器；有执行层，它才可能变成“接任务的人”。
第三，能受规则约束。
GitHub 支持 AGENTS.md 这件事，我觉得比很多“模型分数上涨”更值得看。因为软件团队真正需要的不是一个天才型 AI，而是一个遵守仓库规则的 AI。
第四，能留下证据。
改了什么、为什么改、测试跑了什么、哪里没跑、风险是什么，都要能交代。否则团队没法 review，也没法追责。
第五，成本可控。
GitHub 的 premium requests / AI credits 把一个现实问题摆上台面：agent 越会干活，越可能消耗更多模型调用、更多工具调用、更多云端执行时间。以前我们讨论“准不准”，以后还要讨论“值不值”。
这五件事合在一起，才叫工程代理。少一件，都容易变成演示视频里的魔法，实际项目里的麻烦。
YouTube 上的热闹，说明开发者真正关心什么
我这次特意看了一些 YouTube 上关于 Codex、Copilot、Qwen/Kimi coding agent 的介绍和演示。YouTube 不是事实的最终来源，我不会用它来确认模型规格或产品能力；但它很适合看“开发者的注意力在哪里”。
我看到的共同点是，大家已经不太兴奋于“AI 又写了一个 Todo App”。这种演示太多了，刺激阈值早被拉高。
更能引发讨论的是这几类内容：
• AI 能不能读一个真实代码库，而不是空项目； • AI 能不能修一个测试失败； • AI 能不能解释它为什么这么改； • AI 能不能在多轮执行后不跑偏； • AI 能不能把过程 record/replay，让人类检查； • AI 的上下文和权限怎么控制。
这和官方资料是互相印证的。
官方文档讲的是产品能力，YouTube 演示讲的是开发者焦虑。两边合起来看，结论更清楚：大家真正想要的不是更会聊天的编程模型，而是更可靠的工程执行单元。
我有时觉得，YouTube 上那些“AI 写完整项目”的标题虽然夸张，但评论区反而更诚实。很多开发者不是真的怕 AI 写不出来，而是怕它写出来以后没人知道哪里会炸。
一张表：补全工具和工程代理的区别
这个表里最重要的一行是“失败方式”。
补全工具失败，通常是局部失败。工程代理失败，可能是流程失败。它一旦拿到更多权限，犯错半径也会变大。
这就是为什么我不太赞成把 coding agent 简单吹成“程序员替代品”。它更像一个新的工程流程节点。流程节点好不好，不只看智商，还看接口、约束和审计。
OpenAI 数据给了一个很有意思的信号
OpenAI 那篇关于 agents 如何改变工作的报告里，有几个数据值得单独拎出来。
公开资料显示，OpenAI 用模型估算任务时长，把 Codex 任务按“人类需要多久完成”分层；报告里提到一些 Codex 任务可对应数小时甚至更长的人类工作。报告还讨论了内部员工使用 Codex 生成大量输出 tokens 的情况。
我不会把这些数据直接理解为“AI 替人完成了多少小时工作”。这里面有很多限制：任务时长是估算的，输出 token 不等于有效工作，内部使用环境也和普通公司不一样。
但它至少说明一件事：OpenAI 自己已经不把 Codex 当“帮程序员补一句”的工具来衡量，而是在用“任务规模”和“工作流占比”来衡量。
这很关键。
指标变了，产品方向就会变。以前看补全率、接受率、延迟；以后可能看任务完成率、回滚率、测试通过率、review 修改量、每个成功任务的成本。
如果一个团队还在用“这玩意儿能不能帮我写一个函数”来评估 coding agent，就有点像用打字速度评估一个项目经理。
GitHub 的两个动作更接地气
相比 OpenAI 的宏观报告，GitHub 的动作更像工程团队会马上遇到的现实。
第一，Copilot code review 支持 AGENTS.md。
这个文件本质上是在告诉 AI：这个仓库里怎么做事。哪些命令要跑，哪些风格要遵守，哪些目录要小心，哪些改法不推荐。以前这些规则可能写在 README、贡献指南、团队聊天记录，甚至只存在老员工脑子里。
AI 要进工程流程，就必须把这些隐性规则显性化。
第二，Copilot 进入 premium requests / AI credits 体系。
这个动作不好听，但很真实。模型能力越强，调用成本越高。团队以后不会只问“AI 能不能做”，还会问：
• 这个任务值不值得用高级模型？ • 自动 review 每次都跑是否划算？ • coding agent 重试 5 次的成本谁承担？ • 免费额度耗尽后，团队怎么分配？
我觉得这是 AI 编程从玩具走向基础设施的标志之一。玩具时代大家只关心好不好玩；基础设施时代一定会算账。
可以直接拿走的一段仓库 AI 工作守则
如果你还没有 AGENTS.md，不用一开始就写得很宏大。先写一份能约束 AI 的“小宪法”就够了。
下面这段可以直接改成你自己仓库的版本。
# AGENTS.md## 项目边界- 先阅读 README、包管理文件、入口目录和最近相关的测试文件。- 默认只修改本次任务相关文件，不做顺手重构。- 不要改数据库 schema、权限、支付、数据迁移和发布脚本，除非任务明确要求。## 常用命令- 安装依赖：写清楚 npm / pnpm / uv / poetry 等实际命令。- 单元测试：写清楚最小测试命令。- 类型检查 / lint：写清楚合并前必须跑的命令。## 改动流程- 先给出改动计划，再动代码。- 一次只解决一个明确问题。- 改完必须说明：改了哪里、为什么改、跑了哪些检查、哪些没有验证。## 代码风格- 遵守现有命名、错误处理、日志和测试风格。- 新增逻辑优先补测试，不要为了通过测试删除断言。- 不确定时先提问，不要猜业务规则。这段东西看起来很朴素，但它能把 AI 从“会写代码的人”往“懂这个仓库怎么做事的人”推一步。
我建议个人开发者先从这类短规则开始，不要急着搞复杂 agent 平台。因为很多失败不是模型不够聪明，而是它根本不知道你的项目边界在哪里。
这件事对普通开发者意味着什么
如果你是个人开发者，我建议不要急着把所有活都交给 agent。
现在最值得练的是三件事。
第一，写清楚任务边界。
不要只说“帮我修这个 bug”。要说：
“先读这三个文件，只改登录流程，不改数据库 schema；改完跑 auth 相关测试；如果测试跑不起来，说明原因，不要自行改测试配置。”
这类表达会越来越值钱。
第二，给仓库写 AI 工作守则。
不一定非要叫 AGENTS.md，但你需要有一份面向 AI 的工程说明：项目结构、常用命令、测试方式、不要碰的东西、提交前检查。以前这叫文档，现在它会变成 AI 的操作手册。
第三，学会验收 AI 的工作。
以后问题不是“AI 有没有写代码”，而是“它写的代码是不是可以被合并”。你要看 diff、测试、日志、边界条件、回滚风险。不会验收的人，用越强的 agent 越危险。
对团队来说，真正要建设的是“AI 可执行工程环境”
团队层面更麻烦。
一个 coding agent 真正好用，背后需要一套环境：
• 代码结构清楚； • 测试能稳定跑； • CI 不要三天两头假红； • 文档不至于完全过期； • 权限分层； • 关键模块有 owner； • 回滚路径明确； • 代码 review 规则可见。
说得不好听一点：AI 会放大一个团队的工程卫生状况。
本来测试就乱、文档就烂、模块边界就糊，agent 进来不会自动变好，反而会更快地把混乱复制到更多地方。
所以我对 coding agent 的乐观，是有条件的。它不是来拯救烂工程的，它更像是奖励那些已经把工程流程整理得比较清楚的团队。
我现在的判断
我倾向于认为，AI 编程接下来一年最重要的竞争，不是“谁的模型多 2 分”，而是三件事：
第一，谁能拿到更深的工程上下文。
代码、issue、PR、设计文档、错误日志、部署记录、团队规范，这些上下文比单次 prompt 更重要。
第二，谁能把执行过程管住。
沙箱、权限、测试、审计、回滚，是 coding agent 进入团队的门票。
第三，谁能把成本讲清楚。
如果一个 agent 能省人一天，但花 2 美元，那很便宜；如果它为了修一个小 bug 反复调用高级模型，最后还要人类重写，那就不是提效，是绕远路。
所以，这轮美国大厂抢的不是“代码生成”这个单点，而是未来软件生产流程里的控制入口。
我不认为程序员会因为这件事立刻消失。但我觉得，程序员的工作重心会变：从亲手写每一行代码，逐渐转向定义任务、约束环境、审查结果、维护系统。
这听起来没那么科幻，但更像真实世界。
现在该怎么做
如果你现在就想行动，我建议分四档：
• 现在可以用：让 AI 写测试、解释代码、整理 issue、生成迁移计划、做低风险重构草案。 • 可以试，但别重投入：让 agent 自动修小 bug、自动补文档、自动做 PR review。 • 暂时观望：让 agent 独立处理跨模块核心逻辑、数据库迁移、权限系统、支付链路。 • 不建议跟风：在没有测试、没有文档、没有 review 的项目里，直接让 AI 大规模改代码。
我最想提醒的是：不要把 coding agent 当神，也不要把它当玩具。
它更像一个新来的执行同事。你不给它任务边界，它会猜；你不给它测试，它会自信；你不给它规则，它会照着互联网上的平均代码风格办事。
而平均，通常不是工程质量的朋友。
资料来源
• OpenAI：How agents are transforming work / Codex internal adoption datahttps://openai.com/index/how-agents-are-transforming-work/ • GitHub Changelog：Copilot code review: AGENTS.md support and UI improvementshttps://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements/ • GitHub Docs：About premium requests / AI creditshttps://docs.github.com/en/copilot/managing-copilot/monitoring-usage-and-entitlements/about-premium-requests • GitHub Docs：About GitHub Copilot cloud agent / usage costshttps://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent • GitHub Docs：Configuring runners for GitHub Copilot code reviewhttps://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-runners • Qwen：Qwen3-Coder official bloghttps://qwenlm.github.io/blog/qwen3-coder/ • Kimi K2：Open Agentic Intelligencehttps://moonshotai.github.io/Kimi-K2/ • YouTube：Codex Record & Replay 演示https://www.youtube.com/watch?v=7f4n6h1gzdA
本文由 AI 整理素材，鲍什修改定稿。
