摘要：GPT-6 Astra 发布那天，朋友圈又被刷屏了。但说实话，模型越来越强，真正决定效率的反而不是模型本身。这篇文章不讲参数和跑分，只聊我用 Codex、Claude Code 这些工具写了三个月代码后的真实感受 —— 哪些地方真的香，哪些地方是坑，以及我踩过的那些教程不会告诉你的雷。

一、别让 Agent 从零开始写，给它半成品效果好 10 倍

这是我踩过最大的坑。

最开始用的时候，我喜欢把需求描述得特别详细，然后让 Agent 从零生成整个文件。结果呢？代码能跑，但结构永远不是我想要的。它会引入我不需要的依赖，会用它熟悉但我团队不接受的写法，改起来比自己写还累。

后来我换了个方式：自己先搭好骨架 —— 文件结构、函数签名、关键注释写好，然后把具体实现丢给 Agent。效果立竿见影。

原因其实很简单：Agent 最擅长的是 "在已有上下文中填充细节"，而不是 "从零做架构决策"。你给它一个空文件，它只能靠训练数据里的 "常见模式" 来猜，而那些模式不一定适合你的项目。你给它骨架，它就有了锚点，生成的代码贴合度完全不是一个量级。

现在我的工作流是：我画骨架，Agent 填肉，我来 review。分工明确，效率最高。

二、上下文管理比选哪个模型更重要

GPT-6 Astra 很强，Claude Opus 也很强，但如果你上下文塞得乱七八糟，什么模型都救不了。

我见过最夸张的一次：朋友把整个项目的 README、三个配置文件、报错日志、还有他自己的碎碎念全塞进一个对话里，然后问 "为什么报错"。Agent 给了一个看似合理但完全错误的答案，因为它根本不知道哪些信息是关键的。

我的经验是：

• 每次对话只聚焦一个任务，别在一个会话里又修 Bug 又加功能又重构
• 报错信息给完整的，但无关的日志别塞
• 涉及多文件修改时，先告诉 Agent 文件之间的关系，而不是让它自己猜
• 对话太长了就开新的，别舍不得 —— 上下文污染比重新描述一遍代价大得多

模型能力是上限，上下文管理是下限。下限没守住，上限再高也没用。

三、它写的测试用例，比它写的业务代码靠谱

这个发现挺意外的。

让 Agent 写业务逻辑，经常需要反复调整。但让它基于已有代码写测试用例，质量出奇地高。它会自动考虑边界条件、异常路径、空值处理，覆盖面比我自己写的还全。

我现在的习惯是：业务代码自己写或者和 Agent 协作写，写完之后把代码丢给 Agent，让它出测试用例。它生成的测试我再 review 一遍，补一些业务特有的场景。这样一轮下来，测试覆盖率和质量都比以前高不少。

反过来，让 Agent 先写代码再补测试，效果就差很多 —— 它会倾向于写 "能通过自己测试" 的代码，而不是 "正确的代码"。

四、重构是 Agent 的主场，但别让它一次重构太多

Codex 并入 ChatGPT 之后，我试了几次大重构。结论是：小步快跑，别贪多。

有一次我让它一次性重构一个 2000 行的模块，拆成三个文件、改命名、加类型注解。结果它改到一半开始丢逻辑，某个分支的处理被静默删掉了，跑测试才发现。

后来我拆成了五步：先提取函数、再移动文件、再改命名、再加类型、最后清理。每一步单独一个对话，每一步跑完测试。慢是慢了点，但再也没出过丢逻辑的问题。

Agent 做重构的优势是不知疲倦、不怕重复劳动。但它的 "全局观" 其实很弱 —— 它看不到你整个项目的约束，只能看到你给它的那部分代码。所以重构的范围和顺序必须你来定，它只负责执行。

五、它会一本正经地胡说八道，尤其是在不熟悉的领域

这个不用多说，但值得反复提醒。

有一次我问它一个比较偏的库的 API 用法，它给了一段看起来非常合理的代码，参数名、返回值都像模像样。我直接粘进去跑，报错。查了官方文档才发现，那个 API 根本不存在 —— 是它 "编" 出来的，而且编得特别像真的。

从那以后我养成了一个习惯：Agent 给出的任何我不熟悉的 API、配置项、命令参数，必须查文档验证。尤其是涉及基础设施、安全、支付这些领域，盲目相信它的输出等于埋雷。

它不是故意骗你，它只是在 "预测最可能的下一个 token"，而预测和事实是两回事。

六、Prompt 不是越长越好，结构化描述比自然语言管用

早期我写 Prompt 喜欢写小作文，把背景、需求、约束全用自然语言描述。后来发现效果不好 —— 它会漏掉我写在第三段的某个约束。

现在我用固定格式：

任务：一句话说清楚要干什么
输入：相关代码/文件/报错
约束：
- 必须xxx
- 不能xxx
- 保持xxx风格
输出：期望的格式/结构

就这么简单的四段式，效果比小作文好得多。因为 Agent 在处理结构化信息时，不容易遗漏关键约束。

还有一个小技巧：约束条件按重要性排序，最重要的放最前面。它对前面的信息注意力更高。

七、真正的效率提升不是 "写得更快"，而是 "敢做以前不敢做的事"

这是最深的一点感受。

以前看到一个祖传的、没人敢碰的模块，我的反应是 "尽量别改"。现在我的反应是 "让 Agent 先读一遍，给我出个重构方案和风险评估"。虽然最后还是我来决策和执行，但门槛低了很多。

以前写一个新工具脚本，要纠结 "值不值得花这个时间"。现在直接让 Agent 出初版，10 分钟搞定，不好用就扔。

Coding Agent 最大的价值不是把你已有的工作加速 30%，而是让你愿意去做那些以前因为 "太麻烦" 而不做的事 —— 清理技术债、写工具、做实验、探索新方案。这些事累积起来，对项目质量的提升比单纯的编码速度大得多。

写在最后

GPT-6 Astra 发布那天，很多人在讨论 "AGI 是不是来了"。我觉得对普通开发者来说，这个问题太远了。更近的问题是：你有没有把手里的工具用到极致？

模型会越来越强，这是确定的。但怎么用、用得好不好，差距会越来越大。三个月前我和同事用同样的工具，效率差不多；现在差距已经很明显了 —— 不是因为我更懂模型，而是因为我踩的坑更多，总结的经验更多。

这篇文章里的 7 条，没有一条是关于 "哪个模型更强" 的。因为到最后，决定效率的永远是使用工具的人，而不是工具本身。

如果你也在用 Coding Agent，欢迎评论区聊聊你的体验和踩坑经历。