后开发时代AI把代码写完了那我干啥

大家好，我是灵造哥。

这篇不讲内核、不说嵌入式，聊聊最近半年我每天都在打交道的东西——AI Code Agent。

先交代背景，不让大家误会：我目前在 AI Code Agent 上的月开销大概 1000 美金左右。公司提供的大头 token 额度，用来做公司项目——代码 review、产品原型设计、模型测试、算法 POC 验证。我自己也掏了点钱，订阅了 Claude Pro、Opencode 的 coding plan。

不是富哥，也不是在炫技。只是想说明一件事：这 1000 美金不是一次性的 benchmark 跑分，是连续烧了半年、从 100 涨到 1000、每个月真金白银花出去换来的体感。

半年下来，我最深的感受不是「AI 真牛逼」，恰恰相反——我想明白了一个问题：

AI 把代码写完了，那我干啥？

第一个月 | 100 美金/月 —— 试水期

一开始我是抗拒的。

去年 Claude Code 刚出的时候，我还在跟同事说：「不就是个能跑命令的 ChatGPT 吗？花这钱干嘛。」

当时公司还没有开放 token 额度，我用的是自己的免费配额。写个小函数、补个注释、格式化一下代码——感觉也就那样。一个月 token 费不到 100 美金，大部分还是浪费的——问了个问题觉得回答不满意，换种问法再来一遍，反复烧钱。

也没觉得有啥离不开的。

转折点是那天 review 了一个 PR。

那个 PR 改动不大，大概 200 行，改了一个消息队列的超时逻辑。我看了两遍，觉得逻辑是对的——超时时间配上了，超时后的清理动作也做了，日志也打了。边界情况想了几个，也觉得没问题。

合之前顺手丢给 Claude Code 过了一遍，当实验。

它花了几十秒，回了一句话：「超时后释放的缓存没有清空引用计数，下游仍有可能访问已释放内存。」

我盯着那句话愣了大概十秒钟。

然后仔细去看代码——还真是。有个引用计数字段在另一个结构体里没有归零。消息体虽然释放了，但在另一个路径上，这个引用计数还会被读取，导致访问已释放内存。正常流程永远不会触发，只有「超时 + 重传 + 异常路径」三连击才会出现。测试覆盖不到，静态分析扫不出来，人 review 了两遍也没发现。

你说巧不巧。

从那之后我的态度变了。

不是因为它有多智能，而是我想明白了一个事：模型在「找漏洞」这件事上，和人脑的思维方式是互补的。

人看代码久了会疲劳，会默认「这里应该没问题」。但是模型没有这种惯性——它不会累，不会跳过，会老老实实把每一条路径都扫一遍。我漏掉的不是技术问题，是注意力问题。

第一个月结束的时候，我看了眼账单——不到 100 美金。我心想：还行，这个钱花得不冤。

第二~三个月 | 300 美金/月 —— 上瘾期

人一上瘾，就容易上头。

第二个月开始，我恨不得把所有活都往 Agent 上丢。改 bug——丢给 Agent。搭新项目——让 Agent 出第一版。写设计文档——也让 Agent 来帮忙。

公司的 token 额度也在那时候开放了，比我个人的宽裕不少。我开始把 Agent 嵌入工作流里：

• • 代码 review：每个 PR 先让 Agent 过一遍，我再看它的意见。不是完全相信——它有时候会给出假阳性，说「这里有问题」但实际上没问题——但作为一个「第二双眼睛」的角色非常称职。
• • 原型设计：新功能先让 Agent 出第一版代码，我在此基础上改。效率提升很明显——以前搭一个原型要两天，现在半天就差不多了。
• • 算法 POC 验证：要验证一个思路是否可行，写个脚本跑一下数据。以前得自己写数据生成器、写测试桩、写可视化脚本。现在给 Agent 描述一下需求，它一口气全给你搭好。

效率确实上来了。账单也上来了——从不到 100 涨到了 300 左右。

但也开始踩坑了。而且是连续踩。

第一个坑：任务定义不清晰，Agent 就跑偏。

有次我想搭一个简单的配置解析模块，给 Agent 的描述是：「帮我实现一个 YAML 配置解析器，支持嵌套结构。」它花了大概 5 分钟，生成了 800 行代码。我打开一看：

class ConfigParser:
    def __init__(self):
        self.schema = {}
        self.validators = {}
        self.cache = {}
        self.lock = threading.Lock()

    def parse(self, text):
        # 支持嵌套结构、参数校验、schema 推导
        # 支持默认值、类型检查、递归验证
        # 支持并发安全、缓存优化
        ...

等等，我只是需要一个配置解析器啊。

不是我想要 150 行代码，它给我整了 800 行：参数校验、schema 推导、错误码体系、并发安全锁、缓存优化……它甚至还自动生成了一个 DSL 用于定义配置格式的约束。我全部读完就花了 20 分钟。

后来我总结了一个教训：Agent 没有「这个项目需要什么程度的设计」这种判断力。

它不知道我们团队的习惯是什么，不知道这个模块的生命周期预期是多久，不知道接手的人是什么样的水平。它只会按照 prompt 的字面意思最大化输出。

你让它「支持嵌套结构」，它就给你递归解析 + schema 校验 + 类型推导。但在我们这个项目里，其实只需要两层嵌套就够了，三层以上的情况不可能出现。

从那之后，我养成了一个习惯：prompt 最后一定会加一句话。

保持简单。参考项目中已有的类似模块风格。不要过度设计。两页代码以内能搞定就行。

第二个坑：Agent 写的代码能跑，但不一定能上线。

还是上面那个配置解析器。我偷懒了——觉得它生成的代码测试都过了，就没仔细 review，直接合进去了。

上线第三天，运维找我：有个任务跑到一半挂了，日志显示递归深度超限。

我一看——它用了递归解析嵌套结构，深度超过平台限制的递归层数，直接炸了。而我们的目标平台栈空间有限，这是个嵌入式环境。

能跑的代码 ≠ 能上线的代码。

AI 不知道你的目标平台有什么限制，不知道你的代码要在什么样的资源约束下运行，不知道十年后接手这个项目的人能不能看懂你用了什么花哨的写法。

这些是你需要关心的。

账单涨到 300 美金的时候，我一边享受着效率提升带来的快感，一边开始认真想一个问题：我到底是在用它提高生产力，还是在用它给自己挖坑？

第四~五个月 | 600 美金/月 —— 膨胀期

如果你觉得第三个月我就顿悟了，那你太看得起我了。真正的膨胀期在第四个月。

那时候我已经比较熟练了。每天的工作流变成了：

1. 1. 早上到公司，先看一下 Agent 昨晚跑的任务结果（有些耗时长的丢给它通宵跑）
2. 2. review Agent 生成的代码，改注释、改命名、调整结构
3. 3. 把新的需求拆成可以喂给 Agent 的任务粒度
4. 4. 下午集中处理那些 Agent 做不了的事——跨团队沟通、架构评审、性能调优

看起来很美了对吧？

但膨胀期的问题就是——你觉得自己已经驾驭了工具，于是开始琢磨更复杂的玩法。

然后我就犯了一个典型的工程师错误：过度工程化。

当时觉得单 agent 不够酷。一个人指挥一个 agent，这有什么意思？搞个多 agent 系统，架构师 agent + 开发者 agent + 测试者 agent，各司其职，自动流转，那才叫生产力革命。

说干就干。

我花了两周时间搭这套东西。架构设计、prompt 拆分、上下文传递流程、输出校验机制……每一步都认真设计。

结果呢？

问题一：通信上下文碎片化。

架构师 agent 输出了一份设计文档，包含了完整的模块划分和接口定义。我把这份设计喂给开发者 agent——它说：「上下文太长，请分段提供。」

分段提供之后，开发者 agent 说：「缺少上下文 B 无法理解上下文 A。」我又得把架构师 agent 的输出摘要一遍再喂过去。

开发者 agent 终于写完了代码，喂给测试者 agent——它说：「缺少架构师的设计文档，无法判断这段代码是否符合作业需求。」

好，那我再改——把所有 agent 的上下文对等复制一份。

然后 token 消耗直接翻三倍。

问题二：互相等待。

A agent 等着 B agent 的输出才能继续，但 B agent 因为上下文太长处理超时了。等 B 终于输出完了，A agent 的连接已经超时了。重试之后，B agent 的输出变了——同样的输入，B 在不同时间给出的输出不一样（模型本身就有随机性）。A 拿到新的输出，规划好的下一步不适用了，得重新规划。

这个循环一旦开始，人工介入的频率比直接用单 agent 还要高。

问题三：出了 bug 不知道是谁的锅。

终于调通了，跑了几个任务。有个任务出了问题——测试没过。我先看架构师 agent 的设计——设计没问题。再看开发者 agent 的代码——代码好像也没问题，逻辑对得上设计。再看测试者 agent 的测试用例——啊，测试用例写的边界条件和设计文档里定义的不一致。

那是谁的锅？架构师 agent 没把这个边界条件写清楚？开发者 agent 实现的时候忽略了？测试者 agent 自己猜了一个边界？我花了两个小时才定位到根因。

本来是想省事，结果更累了。

两周后我把多 agent 系统拆了，回到单 agent + 人工审查的模式。世界清净了。

账单到了 600 美金。多 agent 那两周的 token 消耗占了 1/3。

能用单 agent 解决的问题，不要上多 agent。

不是多 agent 完全没用——如果真的有上下文隔离的需求，比如安全审查 agent 不能看到源码细节，那做隔离是必要的。但大多数项目，一个 agent 加一个人就够了。多 agent 带来的复杂度、成本、调试困难，远大于收益。

不要为了用而用。

题外话：模型选择的真相

账单从 300 涨到 600 的那段时间，我开始认真研究一个问题：这些钱到底花在哪了？

一拆账单发现：

• • 50% 花在御三家（Anthropic Claude、OpenAI GPT-4o、Google Gemini Pro）
• • 30% 花在国内模型（DeepSeek V4、MiniMax 2.7、GLM 5.1）
• • 20% 花在 retry 和试错（包括我自己没定义清楚任务导致的重来）

这个比例让我开始思考：不同模型到底适合干什么？

御三家确实是最好的，但得用在刀刃上。

它们的强项是什么？复杂推理 + 长上下文理解 + 精准的指令遵循。所以要我用在：

• • 架构设计——跨模块的调用链分析、依赖关系梳理、方案对比
• • 任务拆解——一个大需求怎么拆成可执行的小任务，每个任务的边界在哪
• • 复杂代码 review——跨文件的 refactor、逻辑关联性的判断

举一个具体例子：要让模型分析一个跨 5 个文件的 refactor 方案，御三家能理清楚调用链，能发现「你在 A 文件改了接口，B 文件的调用方也受到影响，C 文件中的某个条件分支可能永远不会被触发了」。国内模型在这个场景下的出错率明显更高——不是说做不到，是你需要花更多时间去验证它的结论。

国内模型呢？在具体任务上完全够用。

DeepSeek V4 写一个 utils 函数、写测试桩、生成文档——效果和 GPT-4o 差不了多少，但便宜很多。MiniMax 2.7 写 SQL 查询也很稳。GLM 5.1 做一些数据处理的脚本完全可以。

但关键区别在于：国内模型做复杂任务时，它不会告诉你「我不确定」，它会给你一个看起来正确的答案，但这个答案可能有隐含的问题。

所以你花在验证上的时间，可能抵消了省下来的钱。

后来我的策略变成了混合调度：

• • 架构阶段：用御三家（贵但准，不能省）
• • 实现阶段：用国内模型填代码（便宜，效率高，错了也好修）
• • Review 阶段：用回御三家（需要全局判断力）

整体 token 费大概省了 30-40%，而且质量没降。

这个策略不是拍脑袋想出来的，是一个月一个月烧出来的。

第六个月至今 | 1000 美金/月 —— 成熟期

现在每个月差不多稳定在 1000 美金左右。

再说一遍这个构成：公司提供的 token 额度占了大头，用于公司项目——代码 review、原型设计、模型测试、算法 POC。这部分是公司研发效能投入的一部分。我个人花的其实不多，主要是 Claude Pro 和 Opencode 的固定订阅费，加上偶尔跑一些个人项目。

但从 100 到 1000 这个数字曲线，反映的不是预算变多了，而是我知道钱该花在哪了。

举一个现在日常的例子你就明白了：

这周有个任务——给一个机器人控制算法做性能分析和优化建议。

以前我怎么做：读代码 → 自己写分析脚本 → 跑 benchmark → 手动定位瓶颈 → 写优化建议。

现在怎么做：

第一步（御三家）：把整个代码库喂给 Agent，让它分析模块结构和数据流。「帮我理清这个算法的 pipeline 是什么样的，数据哪个环节流转最频繁。」Agent 花了几分钟，出了一份模块级分析——把主循环、子模块调用频次、数据依赖关系都梳理清楚了。

第二步（国内模型）：生成 benchmark 脚本和 profiling 工具。「帮我写一个 benchmark 脚本，测量每个模块的执行时间，输出统计结果。」DeepSeek V4 几分钟就写好了。

第三步（御三家）：把 benchmark 结果喂回去做分析。「基于这个 profiling 数据，哪些模块是瓶颈？优化优先级怎么排？」Agent 给出了排序和具体建议。

第四步（人工）：我来验证和决策。Agent 建议优化 A 模块，但我看过代码，知道 A 模块的算法复杂度已经是 O(n) 了，真正的问题在 B 模块的 I/O 等待。这就是 Agent 看不出来的东西——它没有业务直觉。

整个流程下来，我以前三天的工作量，现在一天半搞定了。而且质量不低于以前——Agent 的分析确实覆盖了我可能漏掉的点，而我的业务判断覆盖了 Agent 看不到的维度。

这是我现在理解的「人机协作」：不是谁替代谁，是互相补位。

所以，Code Agent 到底是什么？

说了这么多经历，该说说原理了。

但我不想搞得太学术。用人话讲，就是：

传统聊天模型是：「你问一句，我答一句。」两者之间没有持续的行动能力。

Code Agent 是：「你给一个任务，我有一双手（读写文件）、一双眼睛（跑命令、看结果）、一个脑子（推理和规划），我帮你一步步做完。」

核心流程四步：感知 → 规划 → 行动 → 观察，然后循环。

用一段伪代码来表示：

def agent_loop(task):
    context = perceive_environment()  # 看文件结构、读代码
    while not task_complete(context):
        plan = model.reason(context)       # 决定下一步做什么
        result = execute_action(plan)      # 写文件/跑命令
        context = observe(result)          # 看执行结果
        if detect_error(result):
            plan = plan_recovery(context)  # 出错了就修正
    return context

这个机制决定了它的长处和短处：

长处：能做多步推理。 不是一次生成完，是走一步看一步——写了一个文件，跑一下测试，发现有问题，回头改，再验证。

长处：能跨文件操作。 它能看到整个项目的文件结构，可以在不相关的文件之间建立联系。

短处：token 消耗大。 每一步都在调模型，每一步都是钱。

短处：容易跑偏。 每一步的规划都是基于当前上下文做的局部最优决策。走三步之后可能已经偏离了最初的目标。你得像放风筝一样时不时拉一下。

短处：深度有限。 目前 Agent 在「广度」上很强——它能覆盖很多文件、很多路径。但在「深度」上——比如需要深入理解一个算法的时间复杂度、需要权衡不同的架构取舍——它还是不行。

所以理解 Agent 的原理，不是为了写一个 Agent，而是为了知道什么时候用它、什么时候不用它。

后开发时代，开发人员该注意什么

前面讲了半年的经历、踩的坑、花的钱、悟的道理。现在说点真正重要的事。

1. vibe coding 是事实，我不说好坏，只说后果

Vibe coding 这个词最近很火——描述一种工作方式：想到什么功能，描述给 AI，复制粘贴，能跑就行。不用想架构，不用管测试，不用关心性能。

我不评价这个方式好不好。我只说我看到的事实。

事实一：代码量上来了，但可维护性下去了。

有些同事的项目，一个月代码量翻了三倍，但代码质量肉眼可见地下降。模块职责不清晰——一个函数 300 行，什么逻辑都往里塞。错误处理不一致——有的地方抛异常，有的地方返回错误码，有的地方直接吞掉。命名更是五花八门——同一个概念，三个模块里用了三个不同的名字。

不是 AI 的问题。是没有人对这个代码库负责的问题。

事实二：能跑的代码，不一定能上线。

我前面讲的那个配置解析器的故事——递归深度超限——不是个例。Agent 生成的代码默认选择最通用的方案，而不是最适合你项目的方案。它不知道你的平台栈空间小，不知道你的数据量预期是多少，不知道你的团队习惯用什么样的错误处理模式。

事实三：出了问题，AI 复盘不了。

有个朋友的项目上线后出了一个性能问题——接口响应时间偶尔飙到 10 秒。他用 AI 分析了一整天，AI 给出了七八种可能的原因：数据库连接池不够、缓存失效、锁竞争、GC 暂停……每种听起来都有道理。

最后他自己逐行看代码，找到了根因：一个在热点路径上没注意的 O(n²) 循环。数据量小的时候没问题，数据量一上来就炸了。

AI 为什么找不到？因为它没有「这个问题在实际运行中的表现」的感知。它只能基于你给的信息做推理，但你给的信息永远是不完整的。

我不是说 vibe coding 不好。我是说你如果只 vibe coding，那出了问题怎么办？性能瓶颈怎么分析？什么样的设计符合项目需求？这些都需要判断力，而判断力 AI 给不了你。

2. 从「写代码的人」变成「审代码的人」

这是一个很大的转变，我花了半年才适应。

以前我的核心工作是写代码——每天大部分时间在敲键盘，创造新的逻辑、搭建新的模块。代码 review 只是辅助性的，看看别人的东西有没有明显的问题。

现在 AI 帮我写了 60%-70% 的代码，我的核心工作变了：判断 AI 写出来的东西好不好。

这个转变比我想象的难很多。

因为判断比创造更消耗脑力。创造的时候，你顺着自己的思路走，是顺滑的。判断的时候，你得理解别人的思路（AI 的思路），再和自己的标准做对照，找出偏差。

需要的能力：

• • 能判断设计方案的好坏。 Agent 给了两种方案，一种简单但扩展性有限，一种复杂但灵活。哪个更适合当前项目？你得权衡。没有标准答案。
• • 能识别潜在的性能缺陷。 Agent 写的代码逻辑是对的，但用了不合适的算法。测试通过了，上线后数据量上来才暴露。你能不能在 review 阶段就发现？
• • 能权衡成本和质量。 Agent 的方案可能「过于完美」——用了一个很酷的架构，但项目只需要一个简单的脚本。过度设计也是问题。你能不能识别并制止？
• • 能兜底。 上线出了问题时，Agent 可以帮你分析，但定位根因、制定修复方案、评估影响面——这些还是得你来。

AI 是你的 copilot，你才是 pilot。这句话不是鸡汤，是这半年的真实体感。

3. 给初级开发者的真心话

这一节我犹豫了很久要不要写——怕写成说教，怕像是在摆老资格。但我还是想写。

因为现在入行的新人，面临的诱惑比我当年大多了。

不会写？让 AI 写。
不会改？让 AI 改。
不会 debug？把日志丢给 AI，让它分析。
不会设计？让 AI 给你出几个方案。

看起来效率很高，什么都能做。但有个问题：你作为开发者的能力有没有在增长？

我见过一个初级的同事，用 Agent 写了一个完整的微服务模块——单元测试、集成测试、API 文档一应俱全。看起来很厉害。但当我问他「这个服务的性能瓶颈在哪」的时候，他答不上来。当我问他「为什么要用这个框架而不用另一个」的时候，他说「Agent 选的，看起来挺合适」。

工具让你走得快，但只有你自己知道往哪走。

给你几个具体的建议：

建议一：多看看经典代码是怎么写的。

Agent 生成的代码风格是「平均化的」——它学习了 github 上大量代码的平均水平。平均意味着不出错，但也意味着不出彩。

去看看 Linux 内核的代码是怎么组织模块的。去看看 Redis 的代码是怎么处理并发和内存的。去看看 SQLite 的测试是怎么写的。这些代码的质量是经过十几年甚至几十年的考验的。

看的时候问自己：如果让我来设计这个模块，我会怎么弄？哪些地方我会和作者做不同的选择？哪种选择更好？为什么？

然后可以试试：让 AI 重新实现这个模块，看看它的设计和经典设计差在哪。你给的 prompt 能不能让它接近经典设计的质量？

建议二：Agent 写的代码，先自己审一遍。

养成这个习惯。Agent 出完代码，你通读一遍，找出至少两个可以优化的点：性能的、可读性的、安全性的都行。

不是为了挑刺，是为了保持手感。如果你连审都不审，慢慢地你就看不懂代码了。

建议三：Agent 出 bug 了，先自己分析根因。

一个常见的坏习惯：Agent 写的代码出错了，把错误日志丢回给 Agent，让它自己修。Agent 修了，发给它跑，跑了又错。再来一轮。

我不是说不能这样，但不应该只这样。

先自己读代码、看日志、定位根因。找到真正的问题在哪——是指针越界？是数据类型不匹配？是并发竞态？定位清楚了，再让 Agent 改。这样你既修了 bug，又锻炼了 debug 能力。

建议四：纯粹的 coding 成本确实低了，但「怎么用」还是需要人来决断。

AI 能写 80% 的代码，但那 20% —架构决策、技术选型、模块拆分、接口设计、异常策略、性能优化——还是需要人来拍板。

而且这 20% 决定了那 80% 的质量。架构选错了，后面的代码写得再好也救不回来。

保持学习，保持判断力。别让工具把你架空了。

4. 拓展边界，而不是收缩舒适区

既然 AI 把编码的体力活接走了，那省下来的精力应该花在哪？

我的答案是：花在 AI 做不了的事情上。

• • 理解业务。 技术上怎么做才能真正解决问题？不只问「用户要什么」，多问「用户真正需要什么」。这是人的判断力，不是靠 prompt 能解决的。
• • 做技术决策。 知道什么时候该快（快速验证思路）、什么时候该慢（核心模块要稳）。知道什么样的设计适合什么样的场景。
• • 跨团队协作。 怎么把你的技术方案讲给非技术人员听？怎么推动各部门对齐？这些事 AI 帮不了你。
• • 定义问题。 很多时候，最难的不是解决问题，是定义问题。知道「我们真正要解决的是什么」——这个能力 AI 目前不具备。

不要把 AI 当作偷懒的工具，要把它当作拓展边界的工具。

以前你一天只能做一件事，现在可以做三件事。但前提是你知道这三件事里哪件是最重要的，哪件可以交给 AI，哪件必须自己来。

写在最后

半年时间，月 token 开销从 100 美金涨到了 1000 美金。

钱烧了，坑踩了，工具换了三轮，工作方式也彻底变了。

回头看，Code Agent 给我带来的最大改变不是代码写得快了——是让我重新思考了一个问题：在 AI 能写代码的世界里，一个开发者的价值到底在哪？

我的答案其实很朴素：判断力。

知道该写什么、不该写什么。
知道什么方案好、什么方案差、什么方案只是看起来好。
知道什么时候该用 AI 加速、什么时候该自己静下心来想清楚。
知道出了问题怎么定位、怎么修、怎么避免再犯。

这些能力，AI 给不了你。它只能帮你实现，不能帮你判断。

纯粹的 coding 成本已经很低了。如何在项目中应用，还是需要人来决断。

工具在变，但有两样东西没变：判断力和责任心。前者让你知道该做什么，后者让你把事情做好。

AI 能写代码了，但决定写什么代码的，还是人。

灵造哥出品｜聚焦机器人 × 嵌入式 × Linux 系统
关注公众号：灵造哥