本文永久链接 – https://tonybai.com/2025/07/15/the-agentic-software-engineer

大家好，我是Tony Bai。

最近，如果你和身边的程序员朋友聊天，很可能会感受到一丝寒意。是的，软件工程行业正在经历一个自 2008 年以来最冷的冬天。职位空缺大幅减少，大厂裁员的新闻不绝于耳。

很多人将矛头指向了 AI：“是 AI 抢了我们的饭碗！”

然而，一篇来自 DoltHub 的深刻文章《The Agentic Software Engineer》提出了一个更本质的观点：别怪 AI，杀死软件工程师黄金时代的，是互联网的普及。

过去 25 年，从互联网到移动互联网的浪潮，创造了海量的工程需求，软件工程师也因此成为了时代的宠儿。但现在，这波巨大的增长红利期已经结束。

那下一个浪潮是什么？文章给出了答案：Agentic AI (智能体 AI)。

这不仅仅是一个新技术，它将彻底重塑我们的工作方式，重写“软件工程师”这个岗位的核心要求。这不是一次普通的更新，这是一场彻底的进化。

告别“代码工人”，拥抱“智能体工程师”

文章预言，软件工程师不会被淘汰，而是将进化，去“驾驭”这波新的 AI 浪潮。我们将成为所谓的 “智能体软件工程师” (Agentic Software Engineer)。

在这个新角色下，我们的工作不再是整天埋头编写成千上万行代码。AI Agent 可以比我们更快、更不知疲倦地完成这项任务。我们的核心职责，将转变为：

一个指挥、协调、审查和运维 AI Agent 军团的专家。

我们从亲自下场比赛的“运动员”，变成了运筹帷幄的“教练”。

AI 时代的生存指南：你的技能升级清单

那么，要成为一名合格的“智能体软件工程师”，我们需要点亮哪些新的技能树？文章为我们梳理了一份极其宝贵的“技能升值/贬值清单”。

技能升值 (Skills++)：这 6 项能力将是你未来的护城河

• 版本控制 (Version Control)

Git 不再仅仅是你个人的代码管理工具，它将成为协调你与成百上千个“AI 码农”协同工作的核心骨干。你需要用它来管理 Agent 的并行工作流、审查 Agent 提交的 PR、以及在 Agent 犯错时进行回滚。精通 Git 模型，将是从业基础。

• 产品思维 (“Product”)

AI Agent 擅长执行，但前提是指令必须清晰。任务分解、需求定义、接口设计等产品经理的核心技能，将成为每个工程师的必备能力。如果你无法将一个模糊的想法拆解成 Agent 可以处理的、足够小的任务块，你将无法与 Agent 高效协作。

• 代码审查 (Code Review)

这是未来我们耗时最多的日常工作。当 Agent 可以在 10 分钟内生成 500 行复杂的代码时，你的价值就体现在审查这些代码的正确性、可维护性和安全性上。接受吧，你正在从一个 Code Writer 变成一个 Code Editor。

• 测试 (Testing)

文章说：“We’re all SDETs now.”（我们现在都是软件测试开发工程师了）。面对一个可能会“创造性”地修改代码以绕过测试的 Agent，编写精准、全面的测试用例，是约束和指导 Agent 行为的最有力工具。 那些热衷于寻找边界条件、享受“破坏”代码乐趣的工程师，将在新时代中变得极其宝贵。

• 系统设计 (System Design)

未来的系统设计，需要更多地考虑如何容纳和管理不那么可靠的 Agent。你需要设计出具有清晰边界、强健接口、高度可测试性的系统，这样即使 Agent 的某个部分出错，也不会导致整个系统崩溃。

• 运维 (Operations)

我们都将成为 “智能体可靠性工程师” (Agent Reliability Engineer)。你需要设计、部署、监控和调试由无数 Agent 组成的复杂网络。当仪表盘上警报响起时，你需要快速定位问题是出在哪个 Agent 的行为上。学习大规模系统的运维之道，宜早不宜迟。

技能贬值 (Skills–)：这些技能正在被 AI 替代

• LeetCode 式算法题： AI 已经能在瞬间解决大部分算法题。
• 语言语法熟练度： Agent 知道所有语法细节，你只需能读懂代码即可。
• 打字速度： AI “思考”和“打字”的速度，是人类无法企及的。

现在，立即开始行动

这篇文章给我们的不应是焦虑，而是行动的路线图。我们应该如何开始？

1. 亲自使用 Agent： 去尝试 Claude Code、Gemini CLI 等领先的编码智能体。找一个终端窗口，看着它工作 15 分钟，感受一下未来的工作形态。
2. “外包”你的日常工作： 在你现有的开发流程中，寻找那些可以“委托”给 Agent 的任务。比如：“为我刚才的提交补充单元测试”，或者“重构这个函数，让它更具可读性”。
3. 刻意练习新技能： 将你的学习时间，有意识地投入到上述 6 项“升值技能”上。

小结：浪潮已至，要么驾驭，要么被吞没

软件工程师的“25年黄金时代”或许已经落幕，但这不意味着职业的终结。

一个由 AI 驱动的、充满无限可能的新时代正在开启。这场变革是不可避免的，拥抱 Agent 的公司，必将“碾压”那些固步自封的公司。而能够驾驭 Agent 的工程师，也必将成为这些公司的核心。

角色的转变或许是痛苦的，甚至会像文章所说的那样，变得有些“无聊”。我们可能会失去一些亲手创造的“流心”时刻。但这是进化的代价，也是我们保持价值的唯一途径。

现在，拿起你的冲浪板，开始学习如何驾驭这波巨浪吧。

成为一名“智能体软件工程师”，从今天开始。

资料链接：https://www.dolthub.com/blog/2025-07-02-the-agentic-software-engineer

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/07/14/writing-style-guide

大家好，我是Tony Bai。

作为一名开发者、架构师或运维专家，我们大部分时间都在与代码、系统和架构打交道。然而，我们同样在持续不断地进行另一种形式的“编码”——沟通编码。无论是撰写一个清晰的 README.md，提交一份详尽的 Pull Request 描述，编写项目内部的技术文档，还是在社区中回答一个问题，我们都在扮演着“技术作者”的角色。

代码的质量决定了软件能否运行，而沟通的质量则决定了项目能否高效协作、知识能否有效传承、社区能否健康发展。一份糟糕的文档，如同晦涩难懂的“面条代码”，会极大地消耗团队的精力和热情。

最近，Redhat公司发布了《Red Hat Technical Writing Style Guide》7.1版本。这份指南不仅仅是一系列规则的集合，它更像是一部由顶级开源软件公司沉淀下来的、关于如何通过清晰沟通来提升工程效率的哲学。

在这篇文章中，我将提炼其中的一些精髓，探讨那些能直接提升您和团队工程能力的写作原则，供大家参考。

写作的“第一性原理”：清晰、精确、用户至上

技术文档的首要目标是传递信息，任何模糊、冗长或模棱两可的表达都是工程效率的天敌。指南强调了几个核心原则：

1. 拥抱主动语态，指令明确无误

主动语态让指令更直接、更有力。在指导性文档中，这能显著降低读者的认知负荷。

对开发者的价值：当用户（或未来的你）阅读操作手册时，清晰的指令意味着更低的出错率和更快的解决问题速度。

2. 杜绝冗余，尊重读者的时间

避免使用不必要的填充词，让每一句话都言之有物。

3. 避免歧义：This 指的是什么？

在技术文档中，代词（如 this, that, it）是歧义的重灾区，尤其对于翻译和非母语阅读者。指南建议明确指出代词所指代的的名词。

- A site can use these to self-assign a private routable IP address space.
+ A site can use these unique local addresses to self-assign a private routable IP address space.

- This causes SSH to lose the recorded identities.
+ This action causes SSH to lose the recorded identities.

对开发者的价值：在复杂的配置说明或问题排查指南中，消除代词歧义可以防止因误解而导致的配置错误。

为全球化社区而写：包容性与可翻译性

开源项目和现代技术团队本质上是全球化的。我们的文档需要被不同文化背景的人阅读和翻译。

1. 使用包容性语言

这是现代技术社区的基石。避免使用可能带有偏见或冒犯性的术语，有助于建立一个更健康、更多元化的社区环境。

• master/slave -> 推荐使用 primary/replica, controller/worker, leader/follower 等。
• whitelist/blacklist -> 推荐使用 allowlist/denylist 或 blocklist。
• 性别代词 -> 避免使用 he/she，推荐使用中性的 they（可指代单数）或直接使用第二人称 you。

2. 为翻译而设计

糟糕的措辞会给机器翻译和人工翻译带来灾难。一些简单的规则可以极大地提升文档的可翻译性：

• 避免使用俚语和行话：eat your own dogfood (使用自己的产品), boil the ocean (范围过大) 等表达在其他文化中可能完全无法理解。
• 慎用 may 和 should：may 可能表示“可能性”或“许可”，should 可能表示“建议”或“期望”。使用 can (可以), might (可能), must (必须) 会更精确。
• 避免名词堆叠：Standard system log management configuration 这种连续名词的组合，在翻译时极易出错。可以调整为 Standard configuration of system log management。

工程师的文字“代码规范”：一致性与标准化

如同 eslint 或 gofmt 为代码提供规范一样，风格指南为我们的文字提供了“格式化”标准。这能确保整个项目文档风格统一，易于阅读和维护。

1. 统一命令语法文档

在展示命令行示例时，保持一致的格式至关重要。

# 一个清晰的命令语法示例
$ git clone [username@]hostname:/repository_filename [directory]

- 使用 $ 表示普通用户，# 表示 root 用户。
- 使用 [] 表示可选参数。
- 使用斜体或描述性词语（如 _filename_）表示 需替换的值。
- 在需要省略输出时，使用 ...output omitted... 标记，而不是随意删减。

2. 精确描述 UI 元素

当描述用户界面时，精确和简洁是关键。

• 直接了当：不说 Click the Save button，而说 Click Save。
• 名称匹配：文档中的 UI 元素名称（如按钮、菜单项）应与界面上显示的完全一致（包括大小写）。
• 导航路径：使用 -> 或 →清晰地表示导航路径，例如：Go to Monitoring → Metrics。

3. 避免产品名称的所有格

一个看似微小但能提升专业度的细节：

• 不推荐: Red Hat OpenShift’s Logging operator creates…
• 推荐: The Red Hat OpenShift Logging operator creates…

总结与展望：将沟通视为工程技艺

《红帽风格指南》带给我们的最大启示是：清晰、精确、专业的书面沟通不是一种“软技能”，而是工程技艺（Craftsmanship）不可或缺的一部分。它与编写高质量代码、设计健壮架构同等重要。

下一次，当你准备提交一个 Pull Request、更新一份 README，或撰写一篇技术博客时，不妨尝试运用其中的一两个原则：

• 将一个被动语态的句子改为主动语态。
• 检查是否有模糊的代词 it 或 this 可以被替换。
• 思考一下你使用的术语是否足够包容和全球通用。

投资于沟通，就是投资于整个团队的效率和项目的未来。正如一份优雅的代码令人赏心悦悦目，一份清晰的文档同样能带来极致的工程之美。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。