TL;DR

  • opus 4.8 > GPT 5.5/opus 4.6 >= GLM 5.2 >= dpskv4pro/gpt5.4mini
  • claude code > codex > cursor »»» copilot（好吧其实我主要用cc和codex）
  • 优质代码 = 先写文档后开发 + 全量review
  • 完全自动化把需求转为代码的时代还没到

写的时候还没出5.6，之后可能会试（大概吧……）

引子

终于是从做题区毕业了的我开始了实习搬砖生涯，当我在公司第一次打开codex并且输入了我的需求，只用copilot自动补全的我被吓到眩晕瘫坐，那一刻就像看到原子弹爆炸（并没有）

然而在燃烧了大量token后我发现，很显然我还是比agent稍强一点

2026/7的agent能力

其实跟2026/4没什么区别

因为LLM coding能力的快速提升和Agent harness开始流行，今天已经没有人会质疑Agent能不能进入生产环境了，从各个维度上看：

  • 写代码：在完整的上下文和正确的指引下，可以写出正确且干净的业务代码，并且比大部分初级程序员强
  • 读代码：比人读快多了，而且几乎没有幻觉
  • 自动化：搭配Skill/MCP能完成大部分的日常工作

这样看来貌似程序员确实没什么用了，然而呢

  • 以上（尤其是写代码）指的是opus4.8/GPT5.5的能力，差一些的模型很容易写出漏洞百出的代码
  • 完整的上下文在任何一个软件工程项目中，都不存在
  • 除非需求一定不变，不可能在一开始就提出正确的指引

所以程序员实际上还是能够在AI大人的帮助下发挥一些作用的，包括但不限于记住项目中大量的潜规则，和需求方扯皮，最重要的是你比Fable便宜呀

Agent其实也是条做题区

使用Agent的过程中发现最大的问题就是，LLM作为一个端到端系统，它只关心写出来的东西看起来对不对。Agent看代码对不对无非两个途径——编译有没有错误，测试是不是全绿

这就引入了两个问题，首先Agent写出来的东西很多时候会有一些隐含的非常不容易被注意到的bug（当然更好更贵的模型现在不那么容易发生），更有甚者会通过改编译流程/测试代码来寻求通过；另一个问题更加致命——目前的Agent几乎没有软件架构设计的概念，如果在完全不规范接口，不设计抽象分层的情况下，代码会极快地膨胀，最后变成人类完全无法维护的屎山

此外项目中常常有各种各样的潜规则和若干种实现同一个逻辑的方法，如果任其自由，Agent很可能用已经废弃的API或是大量的重复造轮子，生产各种各样的一次性代码和胶水代码，更改这些添加额外的心智负担，而且并不能达到提效的目的

那怎么办

为了更好的利用Agent，我的工作流大概如下

潜规则和项目约定

为了应对项目中已经存在和可能产生的大量潜规则，我们必须在项目中包含一些文档给Agent保存跨会话的约定。（注意这些文件应该进git）

那当然要使用每家Agent都有的类似AGENT.md的特殊文件了，在codex中是AGENT.md，cc中是CLAUDE.md。注意，为了防止Agent在自己上下文里面塞乱七八糟的内容产生噪声，coding场景使用的Agent应该关闭memory，自己维护一个项目集的记忆。Agent每个会话开始都会自动把文件添加到自己的上下文

写什么

这是我目前使用的模板

# 这是 PROJECT.md 示例模板；如果在实际项目中看到这行文字，应按该项目的真实情况覆写本文件。

# 前序要求

`PROJECT.md` 应使用中文书写，除非命令、路径、代码标识或外部规范必须保留原文。

`PROJECT.md` 不应包含任何不能上传到云端的内容，包括但不限于 token、密钥、凭据、内网地址、敏感本地路径、个人信息、设备信息、客户数据或未公开业务信息。

# 项目结构

描述项目的整体结构，以及每个主要目录、模块或文件负责什么。

只记录后续 agent 理解项目和定位代码时必须知道的信息。不要虚构不存在的目录、模块或职责。

# 规则

记录项目中必须遵守的稳定规则。

可以包含编码规则、技术选择、模块边界、运行约定、测试约定、隐含副作用，以及代码中没有明确写出但修改时必须考虑的行为。

只写已经存在或已经确定的规则。不要把猜测、临时方案或尚未落地的设计写进来。

# 更新规则

修改代码后必须实时检查并更新 `PROJECT.md`，但只记录后续 agent 必须知道的稳定信息。

不要把设计文档、临时讨论、实现过程、一次性排查记录或过长背景写进来。

更新应保持最小化：新增必要信息，删除过期信息，避免重复描述代码本身已经清楚表达的内容。

其实主要就三点：把潜规则写里面，每次修改同步更新，其他内容一律不进。你会发现这个文件很简单，几乎没有任何开发相关的内容，别急，还有第二关：

# 软件工程指引

这是软件工程类型的指引文件。

如果 agent 在实际项目中看到这个文件，应按 `PROJECT.md` 的要求，将本文件中仍然适用于该项目的稳定规则整理并填充到 `PROJECT.md` 中，然后删除 `software.md`。迁移时不要照搬无关内容，也不要写入任何不能上传到云端的信息。

# 开发流程

软件开发流程按以下顺序进行：

1. 先确定需求文档。
2. 再撰写开发文档。
3. 最后根据开发文档写代码。

每个步骤在写入或实施前，都必须先确认用户同意。

文档命名统一为：

- 需求文档：`<name>.req.md`
- 开发文档：`<name>.dev.md`

## 需求文档

需求文档的职责是描述一个feature的实现路径和输入输出要求，以及可能的副作用。需求文档必须明确功能的技术栈、输入输出规范和功能与整体的关系

## 开发文档

开发文档必须细化到功能具体的实现步骤，具体来说至少要包括：
* 功能处于什么模块/需要新增什么模块，会影响到什么模块
* 功能需要依次添加/修改哪些代码，细化到具体的函数及其输入输出要求、副作用。
* 如果修改现有代码，明确修改目的和修改位置
* 如果添加新代码，明确添加位置和添加功能细节

## 代码实现

代码实现必须严格按照开发文档描述，如果有需要修改部分，先修改开发文档再修改代码，保证开发过程中开发文档和代码一致。
开发完成后，要检查开发文档和需求文档中是否有代码不能直接体现的内容（如潜规则、副作用），若有的话要添加到相关代码旁注释。
验收代码后，删除开发文档和需求文档

# 代码规则

写代码时，每个模块、类、函数都要写必要注释。

注释不要求非常详细，但至少要能看出该模块、类或函数在做什么。

# 测试方案

测试开发也参考开发流程：

1. 先撰写测试相关开发文档。
2. 确认用户同意后，再编写测试代码。

测试至少包含以下层次：

- 单元测试（测试所有纯函数）
- 模块层次 smoke 测试（对一个模块整个流程进行测试，编写时要拆分步骤）
- 全量 smoke 测试（对整个程序流程进行测试，编写时要拆分步骤）

这样，把两个文件都拖到项目根目录，然后告诉Agent按照它们说的做，Agent就可以产生一个项目独有的PROJECT文件。

跨平台

欸等等，PROJECT.md是什么，不是AGENT.md吗

这主要是为了跨平台，例如配套的CLAUDE.md：

请阅读`PROJECT.md`的内容，如果需要修改也在`PROJECT.md`中修改

reference库 vs 单一文件

在很多Agent相关的Blog以及某些工具的官方文档中，会建议我们在主markdown中添加索引，把文档放到其他的markdown里面，实现一个分层的结构从而节约上下文

然而我个人觉得这并不是一个好的实践：首先这意味着任何代码的修改都要同步更新文档，这带来了额外的token消耗和心智负担；其次文档这种东西主要是给人看的，因为人无法快速阅读整个代码库，然而AI大人没有这个局限，配合之后的方法论AI只要阅读源码就能拿到足够的上下文，这个约定文件主要为了规范AI产出的代码和记录不适合放到代码里的潜规则

结对编程！

接下来谈谈怎么给Agent打好下手，共同产出高质量，模块化，人类可读的正确代码

整个流程很简单，主要就是写需求文档-写开发文档-写代码-review-测试

需求文档和开发文档

Agent产出代码速度太快了，如果直接抛给他一个需求，常常会导致代码快速膨胀。在实际的开发中，多数情况下实现是在coding的过程中一步步成型的，边coding边思考才能产出合理且高质量的代码。

先写文档再开发已经是非常常见的Agent使用方法论了，这里的需求文档和开发文档实际上承担的作用是接近的，对于简单明了的需求实际上直接产出开发文档都行

  • 需求文档：主要描述开发的目标是什么，用什么技术栈/API/SDK，应该在哪个模块集成/新建什么模块，最后如何验收
  • 开发文档：根据需求文档细化要产出的文件/API接口，要使用的算法等等，开发文档要确保任何人看着文档写出来的代码在结构上都是差不多的

这个过程其实就模拟了传统coding边写边思考边重构的过程，而且这样开发你会发现LLM能力之间的差距并不大，有好的开发文档豆包都能给你写对！

这个方法论也解放了上下文，三个步骤完全可以在不同的上下文做，甚至可以用贵的模型写开发文档，便宜模型实现

全量review

不过AI写的代码仍然可能有诸多错误或者不够好的地方，所以完全的review是避免不了的，不要偷懒，可以开一个会话让AI和你一起看

（游戏）程序员头上的达摩克里斯之剑

差不多今年4月开始，程序员（尤其是未就业）圈子的焦虑开始膨胀，所有人都在担心AI是否会直接替代掉低级程序员的工作。我相对比较了解的也只有游戏业，后面的观点主要是面向游戏程序员的。

首先，目前最危险的并不是校招，而是年纪比较大的社招。大头兵现在要是丢了工作想再找就很困难了，我所观察到的是，在公司内部的AI焦虑是非常广泛的，不仅员工担心自己的工作会被AI取代，管理层级也担心在AI发展中掉队。不缺钱的公司比起老人的经验似乎会更加相信新人的创造力和可塑性。

其次，公司是否招人取决于公司的经济情况、开了多少项目/项目规格收入如何、股东是否想用AI降本增效，整体来说（游戏）大厂不太会用AI降本增效。看起来虽然游戏业逐渐度过了一个寒冬，25年开始慢慢回暖，但是未来3-5年的情况如何呢？我不知道，三个多月过去了我对未来游戏业的走向仍然非常迷茫。

游戏可以说是软件工程中最复杂的一种，同时游戏程序员的工作至少有一般是和策划斗智斗勇理解和实现策划天马行空的需求，AI没有办法一键解决需求，也没有办法一键帮你实现策划的想法（毕竟一开始策划恐怕都不清楚自己的想法是什么）。此外大型项目目前AI还不太能搞定（至少不是缺乏经验的程序员能解决的），而且游戏的代码嘛…充满了各种只有同事能告诉你怎么做的部分，整体上还是比较安全。