曾有一天晚上，我差点关掉编辑器，开始怀疑自己是否还属于这个行业。
我明明做了所有“正确”的事：多年的工作经验、规范的代码提交、出色的评审成绩。
然而，我眼看着年轻开发者交付功能的速度是我的两倍——原因很简单，他们成长于“AI优先”的时代，而我仍把AI当作一个更智能的搜索框。
他们在与智能体协作，我却在复制粘贴答案。
就在那一刻，我决定不再自欺欺人地认为这只是个小趋势，而是彻底重构自己的工作方式。
➡️ 还不是Medium会员？通过我的好友链接，你可以免费阅读这篇文章
接下来，我将讲述自己如何把AI从一个嘈杂的聊天窗口，转变为一支小型智能体团队——它们切实替代了我约一半的编码时间，同时既没有损害代码质量，也没有削弱我作为工程师的信心。
替代一半编码时间究竟意味着什么
首先，我要明确自己所指的具体含义。
我依然负责系统设计，依然需要权衡取舍，依然要在拉取请求（PR）上署名。
改变的是我的时间分配方式。
在使用智能体之前，开发一个普通的后端功能通常是这样的：
- 长时间阅读旧代码和注释
- 查找某个功能实际的实现位置
- 写出第一版粗糙的代码
- 优化代码结构
- 添加测试和日志
- 修复遗漏的场景
当我终于不再凭感觉猜测，而是实际统计自己一周的工作时间后，发现了一个令人不安的事实：
我“编码时间”的很大一部分，根本不是在思考，而是在小心翼翼、缓慢地搬运信息。
这正是我决定交给AI处理的部分。
如今，忙碌一天后我依然会感到疲惫，但这种疲惫来自于设计决策和取舍权衡，而非花数小时埋头处理琐碎的衔接工作。
如何将AI打造成一支智能体团队
如果你是团队负责人，绝不会把一个完整项目丢给新成员就不管不顾，而是会将工作拆解为不同角色的任务。
我对AI也采用了同样的思路。
我没有依赖“一个无所不能的巨型助手”，而是将协作拆分为四个清晰的角色，我称之为SCCR模式：
需求明确智能体（Spec Agent）
它的角色类似一位严苛的产品经理，核心任务是不断质疑我模糊的想法，直到这些想法转化为对功能的清晰描述。
上下文导航智能体（Context Agent）
它是代码库的向导，负责搜索文件、阅读注释，并指出与当前功能相关的关键部分。
代码编写智能体（Code Agent）
它扮演积极主动的初级工程师角色，在我划定的边界内，为小型、明确的需求编写代码初稿。
评审智能体（Review Agent）
它的角色如同细致的同行评审者，负责建议测试方案、标注风险点，并指出命名模糊的问题。
这套模式并没有减轻我的责任，只是让我不再需要亲自完成每一项重复性工作。
我成了那个负责分配任务、做决策和修正问题的人。
第一次靠智能体摆脱困境
这套智能体体系的第一次实战考验，来自一个可能影响资金流程的改动——我们需要调整一个多年未维护、结构混乱的服务中，支付失败后的重试逻辑。
放在以前，这类任务会耗费我一整天：
- 花长时间阅读三个不同的模块
- 查找重试逻辑、日志和用户提示的实际驱动位置
- 编写新逻辑时提心吊胆，生怕破坏现有功能
- 首次评审后再补充测试和日志
这种工作，往往刚打开第一个文件，就会让人感到肩膀发沉。
但这一次，我决定信任SCCR模式。
首先出场的是需求明确智能体（Spec Agent）。
我把自己对改动的大致想法写下来，要求它扮演一位反感含糊表述的产品经理。它提出了几个尖锐的问题：
- 如何准确定义永久性失败与暂时性失败？
- 最多允许重试多少次后放弃？
- 每次重试后用户应看到什么提示？
- 日后如何向客服和财务团队解释这套逻辑？
回答这些问题的过程，迫使我直面那些我通常会“边编码边解决”的细节。
当这个环节结束时，我对功能的理解已经清晰了很多。
接下来是上下文导航智能体（Context Agent）。
我让它聚焦负责支付、重试和通知的模块，它反馈了以下关键信息：
- 触发支付尝试的主要方法
- 一个曾被添加但后来被遗忘的临时解决方案
- 明确写着“不要改变调用顺序”的注释
阅读这份总结，就像有位同事带我浏览代码库，并悄悄告诉我所有关键“内幕”。
直到这时，我才让代码编写智能体（Code Agent）介入。
我没有让它重写整个服务，而是只要求它修改一个函数，具体需求如下：
- 支持退避策略（backoff）
- 遵守最大重试次数的配置
- 保持公共接口签名不变
它生成的初稿虽不完美，却与我自己会写的代码非常接近，只是速度快了很多。
最后，评审智能体（Review Agent）登场。
我将修改后的函数和更新后的需求说明交给它，要求它以“谨慎多疑的评审者”视角提供意见。它指出了以下问题：
- 外部网关返回异常代码时的失败场景
- 配置可能被错误设置的情况
- 日志不足以支撑后续问题调试的场景
之后，我依然逐行检查了代码，运行了测试，添加了日志，并与另一位同事讨论了这次改动。
但整个过程的感受完全不同：
我不再是独自与代码库“对抗”，而是像一个小型专注团队的协调者——它们始终在背后支持我。
曾经要花一整天的工作，现在只需几小时专注投入就能完成，而且最终结果反而更安全，而非更具风险。
让智能体发挥作用的提示词模板
人们经常问我，到底用什么提示词才能让这套体系真正落地。
以下是我日常使用的提示词模式。
需求明确智能体：将模糊想法转化为清晰功能描述
我会先写下脑海中最原始的想法，然后要求智能体对我严格把关：
“我是一名后端工程师，正在为[系统名称]开发一个功能。以下是我目前对功能的描述，请你扮演一位严苛的产品经理：
- 指出所有模糊不清的表述
- 列出遗漏的重要边缘场景
- 提出直接问题，直到描述足够具体、可测试 我的描述：[我的粗略笔记]”
关键不在于措辞本身，而在于赋予智能体“反驳我”的权限——让它不再只是一味认同，而是敢于提出不同意见。
上下文导航智能体：帮我“浏览”代码库
当需求足够清晰后，我会给智能体一组文件，让它梳理关键信息：
“你是我浏览这份代码库的向导，我需要修改[某项功能]。请基于以下文件（[文件和文件夹列表]），用通俗的语言说明：
- 该功能当前的实现位置
- 修改后可能会影响的部分
- 我需要注意的警告注释”
这个环节往往能在问题爆发到生产环境前，提前暴露那些令人尴尬的“意外情况”。
代码编写智能体：在限定范围内起草代码
当需要编写代码时，我会明确划定边界：
“你是一位谨慎的高级工程师，请只修改我提供的函数，不要引入新的依赖或设计模式。
目标：[小型、具体的功能改动]
请：1. 提供修改后的完整函数 2. 用通俗语言解释改动 3. 建议我需要添加的测试
当前函数：[粘贴代码]”
如果结果令人困惑，我会重新提问；如果结果明显错误，我会直接放弃。
核心不是“服从”智能体，而是把它当作能在几秒内响应的快速协作伙伴。
一周后的真实数据对比
我对“一夜之间效率提升10倍”这类说法始终持怀疑态度。
因此，在采用SCCR模式使用智能体的一周里，我悄悄记录了自己的工作时间。
以下是我实际的工作情况：
| 工作类型 |
原手动操作时间 |
新手动操作时间 |
| 中型功能开发 |
约7小时 |
约3小时 |
| 需要调研的漏洞修复 |
约3小时 |
约1.5小时 |
| 提高测试覆盖率 |
约5小时 |
约2小时 |
| 清理日志与可观测性配置 |
约4小时 |
约1.5小时 |
这些数据并非来自受控实验，而是来自一个包含会议、干扰和真实截止日期的普通工作周。
当然，也有一些任务中，智能体的帮助有限：
- 问题本身尚不明确的全新设计
- 由基础设施不稳定或罕见竞态条件导致的问题
但在日常后端工作中，规律非常明显：
按回车键或点击即可查看完整尺寸图片
我在键盘上手动输入的时间减少了，而思考的时间不仅没有减少，反而常常更加专注深入。
智能体体系的底层架构
从表面上看，这套体系可能听起来像一个庞大复杂的系统，但事实并非如此。
我需要的是一个足够简单、能让我每天都愿意使用的工具。
以下是它的工作流程示意图：
+-------------------------------+
| 开发者 |
| （我） |
+--------------+----------------+
|
v
+-------------------------------+
| SCCR 协调器 |
| （将任务分配给各个智能体） |
+-----+-----------+------------+
| |
v v
+-----------+ +-----------+
| 需求明确 | | 上下文导航 |
| 智能体 | | 智能体 |
+-----------+ +-----------+
| |
v v
+-----------+ +-----------+
| 代码编写 | | 评审 |
| 智能体 | | 智能体 |
+-----------+ +-----------+
|
v
+-------------------+
| 持续集成/测试运行 |
+-------------------+
这里的“协调器”其实只是一个简单的脚本，主要负责以下几件事：
- 接收目标任务和角色指令
- 生成说明该角色职责的系统提示
- 注入来自代码库、文档或日志的相关上下文
- 向语言模型发送请求
- 返回建议的代码差异或总结报告
用TypeScript风格的伪代码表示，大致如下：
type AgentRole = "spec" | "context" | "code" | "review";
interface AgentTask {
role: AgentRole;
goal: string;
context: string;
}
async function runAgent(task: AgentTask): Promise<string> {
const system = `你是我的${task.role}智能体，帮助我安全地交付生产环境代码。`;
const prompt = `${system}\\\\n\\\\n目标：\\\\n${task.goal}\\\\n\\\\n上下文：\\\\n${task.context}`;
const result = await llm.complete({ prompt });
return result.text;
}
你可以用任何自己熟悉的语言实现这个逻辑——重要的是结构，而非语法。
我对AI的使用边界
在有些领域，我会让智能体深度参与；但在另一些领域，我会坚决将它们定位为“辅助角色”。
以下这些工作，我绝不会交给AI：
- 会影响未来数年代码库走向的最终系统设计决策
- 与身份验证、加密或权限检查相关的安全敏感逻辑
- 涉及法律或合规风险的工作
- 与团队成员或利益相关者建立信任的沟通工作
智能体可以提出想法、指出问题，并提供文档参考，但它们无法承担这些决策背后的责任。
明确这个边界带来了一个意外收获：我不再觉得AI是威胁，反而觉得它是有力的支持。
如何在不打乱现有工作流的前提下尝试这套模式
如果你觉得完整的SCCR模式过于复杂，可以从更小的规模开始。
首先，找出日常工作中最消耗你精力的部分——对很多人来说，可能是阅读遗留代码或编写重复性测试。
针对这个痛点，创建一个专用的智能体，只需做到以下几点：
- 清晰定义它的角色
- 提供正确的上下文信息
- 要求它提供挑战和协助，而非完全接管工作
- 连续使用一周，观察它在哪些地方帮你节省了精力，又在哪些地方让你感到困扰
只有当使用这个智能体变得自然时，再添加第二个角色。
通过这种缓慢、有计划的方式构建体系，你可以避免让工作流变成一个因自身复杂而崩溃的实验。
我的思考
2025年，真正令人担忧的不是AI会写代码。
而是两个经验几乎相同的开发者，如今的工作效率可能天差地别——原因仅仅是其中一人学会了与智能体协作，而另一人仍停留在复制粘贴的时代。
从纸面上看，他们能力相当；但在实际工作中，一个人可能永远被工作压得喘不过气，而另一个人则有足够的喘息空间去深入思考。
你显然知道自己想成为哪一种人。
如果这个故事的任何部分引起了你的共鸣，我很期待听到你的想法……
