作者：黑夜路人

时间： 2026年2月

最近这段时间，深度学习了 ClawdBot（OpenClaw） 创始人 Peter Steinberger 的“Agentic Engineering（代理工程）”理念。

因为正处于从 AI Enable（辅助提效） 向 AI Native（原生驱动） 转型的深水区。Peter 的实践证明，通过重构工作流，我们完全有能力指挥一支“Agent 军队”。这不仅是工具的升级，更是软件工程逻辑的根本性重构。

01

CORE THOUGHT

一、 核心思维：Agentic Engineering 的三个支柱

核心逻辑非常简单，但极具颠覆性：人类不再是砌砖工，而是指挥官。

1. 角色转变：Commander vs. Coder

过去： 我们的核心能力是手速、语法记忆、对 API 的熟悉程度。

现在： 我们的核心能力是系统架构设计、任务拆解以及指挥 Agent 的能力。开发者从“逐行编写代码”转变为“并行指挥 5-10 个 Agent”。

2. 信任建立：The Feedback Loop（闭环即信任）

我们敢让 AI 独立干活的前提，不是 AI 不犯错，而是建立“生成-测试-报错-修正”的自动化闭环。只要验证手段（Lint/Test/Build）足够强，实现过程可以“黑盒化”。AI 写的代码不可信，除非你能自动验证它。

3. 哲学回归：CLI > Complex Protocol

相比于复杂的协议，CLI（命令行） 才是 Agent 最好的接口。Agent 天生擅长写 Bash 脚本，擅长处理文本流。我们的基础设施必须提供极简的 CLI 接口，让 Agent 能像搭积木一样调用我们的能力。

必须铭记的“金句”

“这些模型，本质上是人类知识的幽灵。它们不可能一次就对，所以你必须有反馈闭环。”

“PR (Pull Request) 应该改名叫 Prompt Request。 我读 Prompt 的时间比读代码还多，因为那是更高信号的信息。”

“我现在的动作不是写代码，而是把 AI 生成的功能 ‘织入’（Weaving） 进现有的架构里。”

“真正的魔法在于把复杂度隐藏到让人觉得‘理所当然’。”

02

STRATEGY

二、 我们的范式升级：团队落地策略

现在的关键是“人怎么用这些工具”。需要在以下三个维度进行工作模式的升级：

1. Code Review 制度变革：关注“意图”

旧模式： Reviewer 纠结变量命名、纠结三元表达式的写法。

新模式（Prompt Request）：提交代码时，需附带生成这段代码的 Prompt 链路。Reviewer 核心审查：你的 Prompt 是否清晰描述了架构意图？你设计的测试用例是否覆盖了边界？如果代码有问题，不要手动去改，而是优化 Prompt 让 Agent 重写。这能倒逼工程师提升“指挥能力”。

2. 架构师职责下沉：从“画图”到“编织”

每个后端开发和架构师要掌握 “Weaving（编织）” 技巧。Agent 生成的代码往往是“混合体”。架构师的职责是提供清晰的骨架（Skeleton）和上下文（Context），让 Agent 填充血肉。动作： 分配任务时，先写好核心接口定义（Interface Definition）喂给 Agent，让它“填空”，而不是让它“自由发挥”。

3. 基础设施 CLI 化运维

SRE 和运维开发： 不要只沉迷于做复杂的 Web 控制台。我们要把部署、回滚、日志查询等能力封装成 CLI 工具，在安全可靠的情况跟 AI 进行更方便的交互。场景： 工程师指挥 Agent：“去查一下昨晚的报错日志，并回滚服务”，Agent 可以直接调 CLI 完成。

03

WORKFLOW

三、 深度落地：打造“单兵全闭环”的 AI+TDD +APITest开发流

这是本次范式升级的核心实操环节。

我们要彻底改变“先写业务，后补（甚至不补）测试”的陋习。我们要利用 Agent 极强的生成能力，推行 “单兵全闭环” 开发模式。

核心变革： 研发交付的标准不再是“代码写完了”，而是“代码写完 + 业务逻辑自测完（API Test） + 测试用例全部通过”。QA 的自动化测试是最后的系统级兜底，不负责发现基础逻辑错误。

具体的五步工作流如下：

第一步：需求拆解与架构对齐（Blueprint Phase）

动作： 读 PRD，摘取变动点，与 AI 确认“作战地图”。

流程：

投喂： 将 PRD 中的核心逻辑摘录给 Agent。

讨论： 跟 Agent 确认技术方案——“表结构怎么改？”“配置要动吗？”“现有架构有什么风险？”

产出： 一份经人工确认的《技术实现与架构变更文档》。

第二步：测试用例生成（The Contract Phase）

动作： 依据需求，先行生成测试用例。不要等 QA 给用例。

指令： “基于上述需求，生成核心业务逻辑的测试用例列表（含异常、边界）。”

确认： 研发确认用例覆盖了 PRD 逻辑。

产出： 一份待实现的测试清单（这是后续验收的唯一标准）。

第三步：AI 驱动的 TDD 循环执行（Red-Green-Refactor Detail）

这是高频交互环节，切忌一次生成所有代码。

红灯环节（Red - Agent 出考卷）：

指令： “基于接口定义，编写 Login 方法的单元测试。先测‘用户不存在’报错场景。”

验证： 运行测试，必须看到报错（Fail）。这一步验证了“考卷”的有效性。

绿灯环节（Green - Agent 答题）：

指令： “实现逻辑，使刚才的测试通过。”

循环： 如果失败，把报错日志直接丢回给 Agent 让它修（Feedback Loop）。直到测试变绿。

重构环节（Refactor - 注入规范）：

指令： “测试通过。现在请优化代码：提取常量、补充注释、检查 SQL 注入风险、符合我们团队的 Golang 规范。”

验证： 重构后再次运行测试，确保依然通过。

第四步：全量 API 自测（The Verification Phase）

动作： 研发必须自己完成 API 级别的业务验收。

流程：

脚本化： 让 Agent 根据第二步的用例，生成 API 测试脚本（如 .http 文件或 Postman 脚本）。

全覆盖： 测试必须包含输入校验、输出核对、数据库落库检查。

执行： 研发本地运行，确保每一个业务场景的 Response 都与 PRD 严丝合缝。

产出： 一份全绿的 API 测试执行报告。

第五步：准入提测（The Gateway）

标准： 只有拿到全绿的 API 测试报告，才允许提测。

意义： 提交给 QA 的版本，理论上核心业务逻辑是零 Bug 的。

04

ACTION ITEMS

四、 研发各个角色行动指南（Action Items）

为了让这套理念落地，一些建议到各个研发角色前进：

1. 服务端开发任务：试点先行，以点带面。

选人试点： 指派一名资深架构师，先选择一个非核心微服务模块，亲自跑通上述“单兵全闭环”流程。

验证与推广： 验证该流程的实际效率与质量提升效果，形成内部的 Best Practice（最佳实践文档），然后再向整个后端团队推广。

验收标准： 以后 Review 代码，优先看 Repo 里是不是先有了 Test Case，再有的 Business Logic。

2. 大前端开发任务： 建立视觉反馈闭环。

尝试建立一套流程：截图 -> 发给 Agent -> Agent 对比设计稿 -> Agent 修改代码。对于复杂的表单校验逻辑，同样适用上述 TDD 模式。

3. 测试 QA任务： 守门员升级为“训练师”。

自动化系统升级： 测试报错日志必须结构化，能被 Agent 直接读取。

验收标准升级： 如果后端提交的代码连基础 API 参数校验都没过（没有附带自测报告），直接打回，并记录为研发流程违规。

4. 运维 SRE任务： 基础设施 CLI 化。

为 Agent 提供安全的沙盒环境接口，允许开发阶段的 Agent 通过 CLI 进行环境验证，减少人工操作成本。

05

CONCLUSION

五、 结语

Peter Steinberger 说：“软件开发大致分四类：容易或困难，有趣或无聊。我们处在‘又难又无聊’的那一块。”

标准研发角色做业务开发、做企业级服务，往往就是这样。但 Agentic Engineering 给了一个机会，把那些“无聊”的体力活（写增删改查、写测试用例、写文档）交给 AI，让我们能重新专注于“难”且“有趣”的架构设计与业务创新。

按照这个思路方向，拥抱 AI，拥抱新的变成方式，把自己从 Coder（编码者） 变成 Commander（指挥官）。

---

【想要讨论AI编程和AI技术加群 VX 群，请从 VX 公众号联系】