AI 生成的图片（概念与提示由作者撰写）
某个深夜，我几乎要关闭代码编辑器，开始质疑自己是否还属于这个行业。
我遵循了所有“正确”的实践：多年的经验、整洁的提交记录、扎实的代码评审。然而，我却目睹着更年轻的开发者以快我一倍的速度交付功能。原因在于，他们天生采用了一种“AI优先”的工作方式，而我仍将AI视为一个更聪明的搜索框。
他们在与“代理”结对编程。我却在复制粘贴答案。
那一刻，我决定不再将这一切视为一个短暂的趋势，而是彻底重塑我的工作方式。
本文旨在分享我如何将AI从一个嘈杂的聊天窗口，转变为一支“小型代理小队”，在不牺牲代码质量或工程师自信的前提下，实际替代了我大约一半的编码时间。
“替代一半编码时间”的真正含义
首先需要澄清。
我仍然负责系统设计、技术权衡，并在最终的Pull Request上署名。真正改变的是我时间的分配。
在使用代理之前，一个典型后端功能开发的流程通常是：
* 长时间阅读旧代码和注释。
* 搜索特定行为的具体实现位置。
* 写出第一个“丑陋”的初始实现。
* 逐步进行重构和清理。
* 补充测试和日志。
* 修复最初遗漏的边界情况。
当我最终不再凭感觉，而是实际记录了一周的时间后，我意识到一个令人不安的事实：
我大量的“编码时间”并非用于思考，而是耗费在信息搬运上——小心翼翼、缓慢地移动代码和逻辑。
正是这部分工作，我决定将其“外包”出去。
现在，一天工作结束后我依然会感到疲惫。但这种疲惫源于“设计决策与权衡”，而非在繁琐的“胶水代码”中浸泡数小时。
如何将AI构建为一支代理小队
如果你是团队负责人，你不会将一个完整项目丢给新同事然后消失。你会将工作分解为不同的角色。
我对AI采用了同样的策略。
与其依赖一个“万能助理”，我将协作过程拆分为四个清晰的角色，称之为SCCR框架：Spec（规格）、Context（上下文）、Code（代码）、Review（评审）。
- Spec Agent（规格代理）：扮演苛刻的产品经理角色。其职责是将我模糊的想法，通过追问转化为清晰、可执行的行为描述。
- Context Agent（上下文代理）：扮演代码库向导。负责搜索文件、阅读注释，并指出与当前特性真正相关的部分。
- Code Agent（代码代理）：扮演积极主动的初级工程师。在明确定义的边界内，为小而具体的变更编写第一版代码草稿。
- Review Agent（评审代理）：扮演谨慎的同行评审者。负责建议测试用例、高亮潜在风险，并指出令人困惑的命名。
没有任何一个步骤替代了我的最终责任。这意味着，我不再需要亲自执行每一个重复性动作。我转变为那个“分派任务、做出决策、纠正错误”的协调者。
第一次实战考验：从危机中解救
这套方法的第一次真正考验，是一个可能“牵动资金”的敏感改动：我们需要调整一个历经多年、结构已显混乱的服务中的支付失败重试逻辑。
在过去，这类任务会耗尽我一整天：
* 在三个不同模块中进行长时间的代码阅读。
* 追踪重试、日志和用户通知究竟由哪部分逻辑驱动。
* 一边编写新逻辑，一边祈祷不要破坏现有功能。
* 在第一次评审后，再回头补充测试和日志。
这种工作，光是打开第一个文件就让人感到沉重。
这一次，我决定信任SCCR框架。
首先登场的是Spec Agent。 我写下了对改动的粗略想法，并要求它像一位讨厌空话的产品经理一样“盘问”我。它提出的问题直击要害：
* 如何明确定义“永久失败”与“临时失败”？
* 最多允许尝试多少次后才最终放弃？
* 每次尝试后，用户应该看到什么信息？
* 事后我们如何向支持和财务团队解释这一行为？
回答这些问题迫使我直面那些通常“边写边想”的细节。完成后，我脑中的特性设计变得坚实了许多。
接着是Context Agent。 我将与支付、重试、通知相关的模块路径提供给它。它返回了一份总结：
* 实际触发支付尝试的核心方法。
* 一个被添加后就被遗忘的历史性临时解决方案。
* 一条写着“不要改动这些调用的顺序”的警告注释。
阅读这份总结，感觉就像有一位队友带我快速熟悉了代码库，并悄悄告知了所有重要的内部信息。
然后才请出Code Agent。 我没有让它重写整个服务，而是要求它修改一个具体的函数：
* 增加退避重试支持。
* 遵循最大尝试次数的配置。
* 保持对外的函数签名不变。
它给出的第一版代码虽不完美，但已非常接近我亲自编写的风格，而且速度更快。
最后由Review Agent审核。 我将修改后的函数和更新后的规格交给它，并要求它以“偏执评审者”的视角进行审视。它指出了：
* 当外部网关返回非标准状态码时的失败处理模式问题。
* 配置可能被错误设置的情形。
* 现有日志不足以在未来有效定位问题。
我仍然亲自检查了每一行代码。我仍然运行了测试、补充了日志，并与另一位同事讨论了此次改动。
但整个过程已经改变。我不再是独自与整个代码库角力，而像是在协调一支专注的小型团队在背后支持我。过去需要一整天的工作，现在只需几个小时的高强度投入，并且最终结果更加“安全”，而非更具风险。
让代理真正发挥作用的提示词范式
许多人会问，真正有效的提示词究竟是什么样子。以下是我日常使用的范式。
Spec Agent：将粗略想法锤炼为清晰行为
我先写下脑中的想法，然后让代理对我“严格”起来：
“我是一名后端工程师，正在为 [系统名称] 开发一个功能。以下是我当前的描述。请你扮演一位苛刻的产品经理：
1. 指出任何含糊不清之处。
2. 列出缺失的重要边界情况。
3. 提出直接的问题，直到这个描述变得可测试。描述：[我的粗略笔记]”
这里的“魔法”不在于具体的措辞，而在于赋予代理“与我争论”的权限，而非让它一味附和。
Context Agent：替我探索代码库
当规格明确后，我向代理提供一组文件，让它绘制“地图”：
“你是我在这个代码库中的向导。我想修改 [具体行为]。
从这些文件中：[文件与文件夹列表]
请用简单的语言解释：
* 当前这个行为是如何实现的？
* 如果修改它，可能会破坏什么？
* 有哪些警告性的注释需要我特别注意？”
许多令人尴尬的“意外”往往会在这一阶段提前暴露，而不是在生产环境中爆发。
Code Agent：在限定范围内起草代码
当需要动手编码时，我会设定非常清晰的“围栏”：
“你是一名谨慎的高级工程师。只修改我提供的函数。不要引入新的依赖或设计模式。
目标：[具体而微小的行为变更]
1. 给出更新后的函数代码。
2. 用简单语言解释所做的更改。
3. 建议我应该补充的测试用例。当前函数：[粘贴代码]”
如果答案令人困惑，我会继续追问。如果答案不正确，我会直接丢弃。关键不在于服从代理，而在于将其视为一个能在几秒钟内响应的快速协作者。
一周实践的真实基准
我对“一夜之间效率提升十倍”的说法持怀疑态度。因此，我悄悄记录了一周内使用SCCR框架协作的时间开销。
现实情况大致如下：
| 工作类型 | 旧方式手工耗时 | 新方式手工耗时 |
|---|---|---|
| 中型功能变更 | ~7 小时 | ~3 小时 |
| 需要调查的缺陷修复 | ~3 小时 | ~1.5 小时 |
| 提升测试覆盖率 | ~5 小时 | ~2 小时 |
| 清理日志与可观测性代码 | ~4 小时 | ~1.5 小时 |
这些数字并非来自严格的对照实验，而是源于一个充满会议、干扰和真实截止日期的普通工作周。
当然，代理在某些任务上效果不佳：
* 涉及全新设计、问题本身尚未明确时。
* 由基础设施不稳定或罕见竞态条件引发的问题。
但在日常的后端工作中，规律反复出现：
我在键盘前的“动手时间”减少了。我的“思考时间”得以保留，甚至变得更加敏锐。
代理方案背后的简易架构
从外部看，这可能像一个庞大复杂的系统。实则不然。我的目标是足够简单，以确保我每天都会实际使用它。
大致的工作流程示意如下：
+-------------------------------+
| 开发者 (我) |
+--------------+----------------+
|
v
+-------------------------------+
| SCCR 协调器 |
| (将任务路由至各代理) |
+-----+-----------+------------+
| |
v v
+-----------+ +-----------+
| Spec代理 | | Context代理|
+-----------+ +-----------+
| |
v v
+-----------+ +-----------+
| Code代理 | | Review代理 |
+-----------+ +-----------+
|
v
+-------------------+
| CI / 测试运行 |
+-------------------+
“协调器”只是一个简单的脚本，负责以下几件事：
* 接收一个目标和一个角色。
* 构建解释该角色的系统消息。
* 注入来自代码库、文档或日志的相关上下文。
* 将请求发送给大语言模型。
* 返回建议的代码差异或摘要。
用TypeScript风格的伪代码表示，大致如下：
type AgentRole = "spec" | "context" | "code" | "review";
interface AgentTask {
role: AgentRole;
goal: string;
context: string;
}
async function runAgent(task: AgentTask): Promise<string> {
const system = `You are my ${task.role} agent.
You help me ship safe production code.`;
const prompt = `${system}nnGoal:n${task.goal}nnContext:n${task.context}`;
const result = await llm.complete({ prompt });
return result.text;
}
你可以用任何熟悉的语言实现它。结构远比具体的语法重要。
我与AI的协作边界
在某些领域，我放心地让代理提供帮助；而在另一些领域，我则明确划定界限，让它们保持在辅助位置。
我不会外包的工作包括：
* 影响未来数年代码库走向的最终系统设计决策。
* 涉及身份验证、加密或权限检查的安全敏感逻辑。
* 任何带有法律或合规风险的内容。
* 建立与团队或利益相关者信任的关键对话。
Agents 能够提出想法、指出潜在问题、并提供文档线索，但最终做出决策并承担责任的，并非它们。
明确划定这条责任边界，带来了一个意想不到的效应：我对 AI 的威胁感降低了，而对它的支持感增强了。
如何在不打乱现有工作流的前提下尝试
如果觉得完整的 SCCR 框架过于庞大，可以从一小步开始。
从你日常工作中最“消耗心力”的部分入手。对许多开发者而言，这通常是理解遗留代码库或编写重复性的测试用例。
针对这个具体的痛点，创建一个专用的 Agent：
- 明确其角色：清晰地定义它的职责范围。
- 提供充分上下文：给予它完成任务所需的背景信息和知识。
- 定位为挑战者与辅助者：让它来质疑和辅助你的工作，而不是接管你的工作。
持续使用一周。观察它在哪些地方为你节省了精力，又在哪些地方可能让你感到效率受阻。
只有当第一个 Agent 的使用变得自然而流畅后，再考虑引入第二个角色。
通过这种缓慢、谨慎的方式逐步构建你的系统，可以避免将现有工作流变成一个因过度复杂而难以维持的实验。
你怎么看
2025年真正令人警醒的，或许不是AI能够编写代码。
而在于两位经验背景相似的开发者，如今可能在完全不同的效能层级上工作——仅仅因为其中一位学会了如何与Agents协同，而另一位仍停留在手动复制粘贴的模式中。
在简历上，他们看起来可能一样。但在现实中，一位可能疲于应付繁重任务，另一位则拥有足够的认知余裕去进行深度思考和创造。
你已经知道自己希望成为哪一类开发者。
如果这段分享中的任何部分引起了你的共鸣，我很乐意听听你的想法……
关注“鲸栖”小程序，掌握最新AI资讯
本文由鲸栖原创发布，未经许可，请勿转载。转载请注明出处：http://www.itsolotime.com/archives/13410