--- title: "与 AI 共事一年，我从\"甩手掌柜\"变成了\"掌舵人\" | 行开心的颠倒世界" description: "与 Coding Agent 协作将近一年的真实心得：从把 AI 当外包甩手、到凌晨被 oncall 叫醒的教训，到建立\"先聊再写\"、分步验证、保持怀疑的协作习惯，工程师的核心价值在于设计、判断与掌舵。" canonical: "https://xingkaixin.me/posts/coding-agent-almost-1-year/" language: "zh-CN" --- # 与 AI 共事一年，我从"甩手掌柜"变成了"掌舵人" 与 Coding Agent 协作将近一年的真实心得：从把 AI 当外包甩手、到凌晨被 oncall 叫醒的教训，到建立"先聊再写"、分步验证、保持怀疑的协作习惯，工程师的核心价值在于设计、判断与掌舵。 2026年3月24日·3,443 字·9 分钟 [Coding Agent](https://xingkaixin.me/tags/Coding%20Agent/)[AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[工程实践](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/)开发效率 ![与 AI 共事一年，我从"甩手掌柜"变成了"掌舵人"](https://xingkaixin.me/cover/coding-agent-almost-1-year.webp) 去年12月的一个晚上，和几个朋友在视频会议里聊起 AI 编程。小陈兴奋地说他用 Claude Code 三天就写完了一个微服务，语气里带着”以后再也不用自己写代码了”的得意。小李却在另一边苦笑：“我还是只敢让它补全几行，真让它写个完整函数，review 的时间比自己写还长。” 那次聊天让我琢磨了好久。我们明明用着同样的工具，怎么出来的效果差别这么大？后来想明白了：问题不在工具，在用工具的人。 这篇文章不是什么”十步速成”的教程，就是我这快一年来和 Coding Agent 磕磕碰碰、互相试探着建立起来的一些想法。有些做法现在回头看觉得挺笨的，有些却是意外的好用。 * * * ## 交朋友，不是请保姆 刚开始用 Agent 那阵子，我犯过一个很蠢的错误：把它当外包团队使唤。 去年9月接了一个紧急需求，要在三天内给用户系统加个权限管理模块。我心想这不正好试试 AI 的能耐吗？于是写了份详细的需求文档扔给 Claude Code，等它”交作业”。 两天后它真的交了——1200 行代码，结构清晰，注释完整。我大喜过望，随便扫了几眼就提交了 PR。结果上线当晚就出了事：有个边缘情况没处理好，权限判断逻辑在特定条件下会返回错误结果。凌晨两点被报警叫醒时，我看着那堆自己都不完全理解的代码，突然意识到：哦，原来 AI 不会在凌晨三点接 oncall 电话。 那是我第一次明白，责任这东西是没法外包的。不管代码是谁写的，最后兜底的都是你。 后来慢慢想通了：与其说是外包，不如说 Agent 更像是刚入职的实习生。它有很强的执行能力，但对业务上下文、历史包袱、那些”约定俗成”的潜规则一无所知。你得带着它，而不是扔给它。 这个认知转变之后，整个协作方式都变了。不再是”帮我写完这段代码”，而是”我们一起把这个问题解决好”。听起来只是措辞不同，但参与深度天差地别。 * * * ## 别当甩手掌柜 我见过太多人（包括我自己早期）把 Agent 用成了这样：打开编辑器，粘贴需求，等它输出，复制粘贴，提交。整个过程快则几分钟，慢则十几分钟，一气呵成。 但这不是协作，这是甩手掌柜。 真正的协作是什么样子的？让我说几个具体的场景。 上个月重构用户模块时，我花了一个下午先在白板上画出了大概的架构图，然后才去找 Agent。我说：“这是我想的架构，但这里有个性能瓶颈我拿不准，你觉得怎么优化比较好？” Agent 给了三个方案，我们来回讨论了半小时，最后选了一个折中的。那个下午我学到的关于数据分片的知识，比看两天教程还多。 还有一次，Agent 实现了一个缓存模块，用了我不熟悉的装饰器模式。我没直接接受，而是问它：“为什么要用装饰器？简单的函数包装不行吗？” 它解释了半天，最后我发现自己其实在问一个更本质的问题：这种场景下该用结构型模式还是行为型模式？那次对话之后，我对设计模式的理解深了一层。 协作的另一个关键是知道什么时候叫停。Agent 有时候会钻牛角尖，在一个不太重要的细节上纠缠不休。这时候你得果断说：“停，这个方向不对，我们回到主线上来。” 这种干预能力，是委派时不会用到的。 说到习惯，我现在养成了一个”先聊再写”的流程。不急着要代码，而是像跟同事 pair programming 一样，先把问题边界、约束条件、可能的方案都聊透。这个前置的探索过程，看着浪费时间，实际上避免了很多后续的”生成—废弃—重来”循环。 另一个好习惯是善用”Plan 模式”。让 Agent 先输出执行计划，你在计划阶段就做充分的质疑和修正。这比在代码阶段反复返工高效得多——改计划比改代码便宜太多了。 * * * ## 别让代码变成黑盒子 去年有一次惨痛经历：Agent 帮我写了一个复杂的报表生成模块，800多行代码。我看着它流畅地运行测试用例，心想”稳了”。结果上线后第三天，客户报了个诡异的问题：特定时间段的报表数据会重复计算。 我盯着那 800 行代码，突然发现自己像个外人——我看得懂每一行在做什么，但看不懂它们组合起来为什么会出这个 bug。那种感觉，就像你借别人的车开，结果半路抛锚了，你连引擎盖都不敢打开。 后来我给自己定了个规矩：提交任何代码之前，先做”费曼测试”——假装向一个完全不懂技术的朋友解释这段代码在做什么。如果解释不清，就说明我自己也没真懂。 掌控感这东西，得靠一些具体的工程实践来维持。 先说 PR 管理。Agent 写代码又快又多，很容易一口气产出几千行改动。但大 PR 是 review 的噩梦——reviewer 面对海量代码容易浮于表面，只挑些格式问题。我现在尽量把单个 PR 控制在 600 行以内。实在拆不开时，我会附上一份简短的设计说明，不用代码级别的 spec，就是站在高处说清楚”这次改动做了什么、为什么这样做”。有趣的是，这个习惯逼着我在写代码之前就得想清楚设计，反而提升了代码质量。 还有个看似矛盾但很好用的做法：用 AI 写代码，再用 AI 来 review。这两个阶段的 prompt 目标完全不同。写代码时，Agent 在”生成”；review 时，我让它扮演”挑剔的 reviewer”，专门找逻辑漏洞、边界情况、安全隐患、过度复杂的设计。这种前置自查能过滤掉很多低级问题。不过说实话，这个方法也有局限性——AI 很难发现那些需要业务上下文才能识别的问题。 测试覆盖是另一个底线。AI 生成的代码如果没有测试，就是在裸奔。代码 review 发现不了运行时才会触发的 bug。我现在会明确要求 Agent 在实现功能的同时生成测试用例，形成”验证→修复→验证”的闭环。上周有个函数，Agent 写了三个测试用例都通过了，但我在手动补充测试时发现了一个边界情况，它漏了。这提醒我：AI 的测试也不能全信。 另外，我发现 Agent 有个习惯：喜欢自己造轮子。去年它给一个简单的日期格式化功能写了个 80 行的实现，我看了直摇头——这明明用 dayjs 两行代码就能搞定。后来我学乖了：遇到常见问题，先问自己”有没有现成的库？” 这个判断 Agent 做不了，得你来。 ## 几个让我少走弯路的小习惯 聊完了大的思路，说几个具体的操作习惯。这些习惯都是踩过坑之后才养成的。 第一个习惯是”分步骤验证”。别把复杂任务一股脑塞给 Agent。我吃过亏：有一次让 Agent 一口气实现一个完整的用户注册流程，结果它在密码加密环节用了一个不安全的算法，我到很晚才发现。现在我会把任务拆成小步骤，每步验证通过再继续。比如上周重构用户模块，我拆成了数据库迁移、API 接口更新、前端适配三步，每步单独验证。这样做虽然慢一点，但心里踏实。 第二个习惯是”保持怀疑”。Agent 给的答案往往是”最有可能成立”的，但不一定”最适合你”。我现在会主动问它：“这个方案有什么潜在缺点？有没有更简单的替代方案？如果将来要扩展功能，会不会有问题？” 这种反问常常能暴露出意想不到的权衡。有次 Agent 建议用 Redux 管理局部状态，我问它 Context 会不会更轻量，最终我们选了一个简单得多的方案。 第三个习惯有点反直觉：别被 Agent 带跑偏。它的输出太流畅、太有说服力了，有时候你会不知不觉顺着它的思路走，忘了自己最初的判断。我现在养成了一个前置思考的习惯：开始任何任务前，先花十五分钟自己想清楚大致方向，再去问 Agent。有了自己的预期后，对 Agent 方案的鉴别力会明显提升。 最后一个习惯是”好奇心驱动”。遇到 Agent 用了你不熟悉的库、模式或写法，别直接跳过。打破砂锅问到底：这个模式叫什么名字？什么场景下适合用它？有什么副作用？每一次这样的追问，都是一次真实的学习。我去年通过这种方式学会了至少五个设计模式，比刷教程印象深刻得多。 * * * ## 当 AI 能写代码了，我们还能做什么？ 最近我常想一个问题：当 Agent 能承担越来越多的”写代码”工作，我们这些工程师的价值还剩下什么？ 想了很久，我觉得答案可能是三个词：**设计、判断、和掌舵**。 Agent 很擅长在明确的框架下做具体的实现。给它一个函数签名和需求描述，它能写出漂亮的代码。但它不擅长回答这些问题：“这个系统该用什么架构？""这两个方案哪个更符合我们项目的长期利益？""这个设计会不会在用户量翻十倍时崩溃？” 这些问题需要的是对领域的深度理解、对项目历史的熟悉、对那些”非功能性需求”的敏感——安全、可维护性、并发安全、扩展性。这些东西，Agent 在默认状态下很容易忽视。 有趣的是，AI 时代反而让一些”老派”做法变得更重要了。比如读官方文档。Agent 的知识有截止日期，存在幻觉问题。去年我想深入学 GraphQL，让 Agent 给我讲，它讲得头头是道，但我总觉得心里没底。后来还是硬着头皮把官方文档啃了一遍，才发现 Agent 漏掉了好几个关键细节。那种”慢下来读文档”的踏实感，是 AI 给不了的。 设计模式、架构知识这些也需要主动补充。不是说要成为架构师，而是当你脑子里有了这些概念，和 Agent 协作时会顺畅很多。你能更清楚地描述你想要的结构，也更能判断 Agent 的设计是否合理。上个月设计一个消息队列模块，我脑子里有”发布-订阅模式”的概念，和 Agent 讨论时效率高了很多。 还有一点我最近才想明白：做正确的事，比做快更重要。Agent 能在错误的道路上极速狂奔，你让它优化一个不该存在的功能，它能给你优化得极其漂亮。但方向错了，速度越快，离目标越远。在 AI 时代，“我们要解决的真正问题是什么”这个问题，价值被放大了十倍。 不过说实话，这个问题我还没完全想清楚。有时候看到 Agent 流畅地写出我可能需要半天才能实现的代码，我也会焦虑：我的技能会不会过时？但转念一想，工具进步了，我们的角色也在进化。就像汽车取代了马车，马车夫消失了，但司机、机械师、设计师这些新角色出现了。 * * * 写到这里，突然想起去年刚开始用 Agent 时，我总想找到一个”完美的工作流”。现在明白了，没有什么完美的工作流，只有不断调整的协作方式。 和 Coding Agent 一起工作，有点像学骑自行车——刚开始歪歪扭扭，怕摔倒，后来慢慢找到平衡，再后来就能单手骑了。但不管骑得多熟练，你都得保持专注，因为随时可能遇到坑洼。 我最想说的是：别退缩成一个”需求传话人”。你在代码这件事上的参与深度，决定了你能从这套工作流里拿走多少。**Agent 是拓展你能力边界的工具，而不是替代你判断力的系统。** 这些只是我个人的一些摸索，肯定不全面，也可能不适合你的场景。如果你有不同的实践或看法，或者发现了更好的协作方式，我很想听听。说到底，我们都在摸索怎么用好这把新工具，互相交流或许能走得更快些。 ![illustration-02](https://xingkaixin.me/posts/images/coding-agent-almost-1-year/illustration-02.webp) ## 版权声明 作者 XingKaiXin 标题 与 AI 共事一年，我从"甩手掌柜"变成了"掌舵人" 发布时间 2026年3月24日 文章链接 [https://xingkaixin.me/posts/coding-agent-almost-1-year/](https://xingkaixin.me/posts/coding-agent-almost-1-year/) 本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。 导览 展开导览