Agentic Coding变革：从代码补全到自主任务执行

还记得"AI 辅助编程"意味着自动补全建议、猜测变量名的时代吗？那些日子已经一去不复返了。不知从何时起，这些工具不再只是提建议，而是开始真正做事。它们阅读你的代码库、运行测试、创建 Pull Request，有时还会修复你甚至不知道存在的 Bug。欢迎来到 Agentic Coding 时代——如果你还没有围绕它重新调整工作流程，这篇文章就是你的速成班。

真正改变了什么？

从代码助手到编程 Agent 的转变，归结为一个能力：自主性。传统的助手等待你敲击键盘。Agent 接收一个目标，然后自己想办法实现。

对我帮助最大的思维模型是：不要把 Agent 看作自动补全，而是把它想象成一个可以访问你代码库的初级开发者。你不会把一个没有文档说明、没有验收标准的任务交给初级工程师。那为什么要交给 Agent 呢？

提示词差距就是新的调试

这是我在每天使用 Agentic 工作流程几个月后发现的一个令人不安的事实：Agent 失败不是因为它们笨，而是因为我们的指令太模糊。

考虑一下这两个请求：

❌ Bad: "Make the app faster"

✅ Good: "Reduce p95 latency of the /search endpoint (currently 1.2s)
   to under 300ms. Focus on the database query layer first.
   Keep existing API contracts unchanged. Add a benchmark
   comparing before/after."

第二个版本有可衡量的目标、约束边界、初步假设和完成定义。Agent 恰恰在这种精确的指令形式下表现出色。同样的原则也适用于你给它们的上下文——一个失败的测试比十段解释更有价值。

经验法则：如果一个人类同事在阅读你的任务描述后仍然需要问三个澄清问题，你的 Agent 也需要——只是它会选择猜测，而且会猜错。

我的 Agent 增强工作流程

经过实验，我建立了一个尊重速度和安全的流程。Agent 处理繁琐的工作，我处理需要判断的决策。

先定义契约。 在调用 Agent 之前写出失败的测试、API 规范或验收标准。这将"让它工作"转化为可验证的结果。

以有限的块为单位委托。 每次给 Agent 一个范围明确的任务——一个端点、一次重构、一个 Bug。多目标提示是质量崩溃的地方。

让它为工作辩护。 要求 Agent 解释其更改并运行测试套件。没有理由说明的 diff 是无法审查的。

认真审查。 阅读实际的 diff。Agent 有时会生成表面上通过但在边缘情况下失败的自信废话——这是经典的"只在快乐路径上工作"的问题。

以小、可审查的单元提交。 大型 Agent 生成的 PR 难以阅读，而小型的则能展示 Agent 学到了什么。

Agent 仍然让我紧张的地方

让我们不要假装这一切都是阳光明媚。三种失败模式让我保持警惕：

自信的重构。 Agent 喜欢为了"清晰"而重构代码。结果代码通常看起来更干净，但行为会悄悄改变。总是通过 diff 测试，而不是美学测试。

依赖膨胀。 被要求添加一个功能，Agent 可能会拉取半个 npm。密切关注进入你 lockfile 的内容。

测试幻觉。 Agent 为自己的代码编写测试可能会建立一个舒适的气泡，一切都会通过。有在更改之前就存在的测试，并让 CI 运行它们。

最重要的技能

每个人都在问哪个技能会在 Agentic 转变中存留下来。我的答案是：品味——无需运行代码就能判断一段代码是优雅还是摇摇欲坠的能力。Agent 放大了你的产出，但你仍然是质量把关人。那些在 Agentic 时代蓬勃发展的开发者不会是委托最多的人，而是那些委托得好、审查得更出色的人。

就是这样。我很想听听你是如何将 Agent 整合到你的工作流程中的——你有什么绝对不打破的规则？在下面留言。👇

如果你觉得这篇文章有用，一个 ❤️ 和关注能让这些帖子继续更新。感谢阅读！