本文永久链接 – https://tonybai.com/2025/06/03/provocation-about-ai-assisted-programming

大家好，我是Tony Bai。

最近，fly.io 博客上该公司开发者 Thomas Ptacek 的一篇题为《My AI Skeptic Friends Are All Nuts》的文章，在开发者社区掀起了不小的波澜，一度登顶HN。Ptacek 以一位自称“严肃开发者”（从C语言到Go、Rust均有涉猎）的口吻，向那些对 AI 辅助编程持怀疑态度的“聪明朋友们”发出了略带“挑衅”的宣言：“即使 LLM 今天停止所有进展，它仍然是我职业生涯中发生的第二重要的事情” 。

这篇文章的观点之鲜明、论证之犀利，让我印象深刻。恰逢 前期Google I/O 2025 大会再次展示了 Gemini 等 AI 模型在编码领域的惊人进展，我们不禁要问：AI 编码工具，究竟是能极大提升生产力的“真香”利器，还是又一轮被过度炒作的“智商税”？作为开发者，特别是 Gopher，我们又该如何看待和应对这场正在发生的变革？

在这篇文章中，我就和大家一起来看看 Thomas Ptacek 对AI辅助编程演进的犀利观点以及他的反思。看看你是否认同他的想法。

误区澄清：现代 AI 辅助编程早已不是“复制粘贴”

Ptacek 在文章开篇就点出了一个关键问题：很多人对 AI 辅助编程的印象，还停留在半年前甚至两年前的水平。他写道：“如果你在6个月前（或者，天哪，两年前用Copilot的时候）尝试使用LLM编码并失败了，那么你并没有在做大多数严肃的LLM辅助编码者正在做的事情”。

那么，现在“严肃的LLM辅助编码者”在做什么呢？Ptacek 强调，他们使用的是 Agent (智能体)。这些 AI Agent 不再仅仅是根据提示生成代码片段让你复制粘贴，它们能够：

• 自主地在你的代码库中进行探索。
• 直接创建和修改文件。
• 运行各种工具， 如编译器、测试框架、linter、formatter 等。
• 与 Git 等版本控制系统交互。
• 根据编译和测试结果进行迭代和修正。
• 通过 MCP 或类似机制调用你设置的任意工具。

Ptacek强调：如果你对 AI 编码的印象还停留在 ChatGPT 网页上简单问答然后手动复制代码，那么你可能真的低估了当前 AI Agent 所能达到的自动化和智能化水平。

AI Agent 如何提升编码效率？Ptacek 的“积极案例”

Ptacek 认为，LLM（通过 Agent）能够极大地提升编码效率，主要体现在以下几个方面：

1. 处理“乏味代码”： LLM 可以编写你需要编写的大部分乏味代码。而大多数项目中的大多数代码都是乏味的。这能让开发者从重复性的工作中解放出来，更快地进入“调整代码并立即看到效果更好”的“黄金时刻 (golden moment)”，获得即时反馈的“多巴胺冲击”。

2. 克服项目启动的“惯性”： 面对一个新项目，繁琐的初始设置、依赖管理、基础架构搭建等往往令人望而却步。LLM Agent 可以被指示去“搞定这些破事，直接将你带到“事情几乎可以工作”的阶段。

3. 自动化“苦差事”： 那些你不想做但又必须做的“脏活累活”，比如大规模的单元测试重构，完全可以交给 AI Agent 在虚拟机里折腾几个小时，然后带着一个 PR 回来。这反而会“逼迫”你去做“真正的工作 (real work)”。

回应常见的质疑：Ptacek 的“辩护”

Ptacek 在文章中也针对开发者对 AI 编码的常见质疑进行了犀利的回击，这些回应也为我们思考 Go 语言在 AI 时代的定位提供了新的视角。

• 关于代码质量与审查责任——“你根本不知道它写的是什么！”

Ptacek强调，开发者始终对合并到 main 分支的代码负责，无论是否使用 LLM。 LLM 生成的代码是“可知的”，你需要阅读它，甚至花时间将其调整为你自己的风格。如果连 LLM 生成的“乏味、重复”的代码都难以理解和消化，那可能是开发人员的“技能问题”。

• 关于“幻觉 (hallucination)”问题——“它会编造不存在的API！”

Ptacek 认为，对于编程而言，Agent 通过工具链（linting、编译、运行测试）形成的闭环反馈，已经（或多或少地）解决了“幻觉”问题。“如果它们的LLM编造了一个新的函数签名，Agent会看到错误。它们将其反馈给LLM，LLM会说‘哦，是的，我完全是编造的’，然后重试”。这里不能不提到** Go 语言的快速编译特性，使得这种“试错-反馈-修正”的闭环能够非常高效地运转。同时，Go 强大的标准库和清晰的 API 设计，是否也能减少 LLM“编造”API 的概率，或者使其更容易被工具链检测出来。

• 关于“代码像初级开发者写的”——“质量太差！”

Ptacek 回应：“一个实习生一个月要花20美元吗？因为 Cursor.ai 就是这个价钱”。他认为，高级开发者的职责之一就是让能力稍逊的编码者（无论是人类还是“智能体”）变得高效。使用好 Agent 本身就是一项技能和一项涉及提示、索引和（尤其是）工具链的工程项目。 LLM 只有在你允许的情况下才会产生劣质代码。

• 关于“不擅长特定语言 (如 Rust)”——“它写不了我的 Rust！”

Ptacek 认为这更多是语言生态和工具链成熟度的问题，而非 LLM 能力的根本缺陷。他特别指出：“我主要用 Go 工作……Go 恰到好处的类型安全、广泛的标准库以及推崇（通常是重复性）惯用法的文化。LLM 在生成 Go 代码方面表现出色。” 想必很多Go开发者也有着与Ptacek相同的感受，这是 Go 语言在 AI 辅助编程时代的一个显著优势！ Go 的简洁性、明确性、强大的标准库覆盖、以及社区对代码规范和惯用法的重视（例如 Effective Go），使得 Go 代码的模式相对统一和可预测，这为 LLM 的学习和生成提供了极大的便利。

对“手工艺精神”与“平庸代码”的再思考

Ptacek 对软件开发中的“手工艺精神”和对“平庸代码”的过度排斥也提出了批判。

• 他认为：专业软件开发者的工作是用代码为人们解决实际问题。在日常工作中，我们不是工匠。过度追求代码的“优雅”而忽视实际产出，可能是“自我安慰的yak-shaving（指做无关紧要的琐事）”。

• 对于“平庸代码”，他认为：开发者都喜欢对代码自吹自擂。他们担心LLM降低了质量的“天花板”。也许吧。但它们也提高了“地板”。LLM 生成的“平庸但彻底”的代码，可能比人类开发者“抖机灵”但引入缺陷的代码更有价值。

这也引发我们思考：在追求卓越工程的同时，我们是否也应该更务实地看待不同场景下对代码质量的不同要求？LLM 是否能帮助我们更高效地处理那些“允许平庸”但又耗时耗力的部分，从而让我们能将精力投入到真正需要人类智慧和创造力的核心工作中？

Go 开发者如何拥抱 AI Agent 的时代？

Ptacek 的文章，无论你是否完全认同其所有观点，都为我们描绘了一个 AI Agent 深度参与软件开发的未来图景。作为 Gopher，我们应该如何应对？

1. 更新认知，拥抱变化： 首先要认识到，现代 AI 辅助编程已经远超简单的代码补全。应该主动去了解和体验基于 Agent 的编码工具。
2. 学习与 AI Agent 高效协作： 掌握提示工程技巧，学会如何清晰地向 Agent表达需求、提供上下文、引导其生成和修改代码。
3. 发挥 Go 语言的优势： 利用 Go 的简洁性、强大的标准库、快速的编译和测试工具链，为 AI Agent 构建高效的开发和反馈环境。思考如何让 Go 代码对 AI 更“友好”。
4. 提升自身的核心价值： 将精力更多地投入到 AI 难以替代的领域：复杂系统设计、架构决策、需求理解与抽象、创新思维、以及对 Go 底层原理和并发模型的深刻理解。
5. 参与构建 Go 的 AI Agent 生态： Go 语言本身非常适合构建 CLI 工具和后端服务。我们是否可以利用 Go 来创建更强大的、针对 Go 开发的 Agent 辅助工具或平台？

小结：保持开放，主动实践，与 AI 共舞

AI 编码工具究竟是“真香”还是“智商税”？或许答案因人而异，也因我们如何使用它而异。但 Thomas Ptacek 的“挑衅”至少提醒我们，不能用静止的眼光看待飞速发展的技术。

AI 辅助编程的浪潮已然到来。对于我们 Gopher 而言，Go 语言的特性使其在这波浪潮中具有独特的优势。与其固守过去的经验和偏见，不如保持开放的心态，主动去实践和探索，让 AI Agent 成为我们提升自身能力、加速项目交付、并最终能专注于更有创造性工作的强大伙伴。

毕竟，正如 Ptacek 所说，当他那些“聪明的怀疑论朋友们”最终接受并开始使用这些工具时，他们将会让编码 Agent 比今天强大得多。

而我们，又怎能置身事外呢？

聊一聊，也帮个忙：

• 你目前在工作中使用 AI 辅助编程工具（如 Copilot, Cursor.ai, Gemini Code Assist，Trae等）的体验如何？它在哪些方面帮助了你，又有哪些不足？
• Ptacek 文章中对 AI 编码的哪个观点让你印象最深刻？你同意还是反对？为什么？
• 你认为 Go 语言在 AI 辅助编程时代，还有哪些可以进一步优化的方向，以更好地与 LLM Agent 结合？

欢迎在评论区留下你的思考和经验。如果你觉得这篇文章提供了一个值得探讨的视角，也请转发给你身边的开发者朋友们，一起参与这场关于 AI 与编程未来的讨论！

想与我进行更深入的 Go 语言、AI 赋能开发与技术趋势交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

我们星球见！

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

本文永久链接 – https://tonybai.com/2025/05/26/monitor-design-with-red

大家好，我是Tony Bai。

随着业务的快速发展，越来越多的应用开始拥抱云原生。我们享受着微服务带来的解耦、容器带来的标准化、Kubernetes带来的弹性伸缩。但与此同时，一个灵魂拷问也摆在了每一位开发者和运维工程师面前：我的服务还好吗？用户用得爽吗？出问题了能快速定位吗？

传统的只盯着CPU、内存、磁盘的监控方式，在高度动态和分布式的云原生环境下，常常显得力不从心，就像“瞎子摸象”，难以窥得全貌。我们需要一种更直接、更面向用户体验、更标准化的方法来衡量服务的健康状况。

今天，我就结合一个通用的示例和大家说一套被业界广泛认可的服务监控黄金法则——RED方法，谈谈如何按照RED方法设计出简单又好用的监控指标与告警。

什么是RED方法？

RED方法并非什么高深莫测的理论，它非常简洁，由三个核心指标的首字母组成：

• R – Rate (请求速率)
• E – Errors (错误率)
• D – Duration (响应时长)

这“三板斧”虽然简单，却直击服务质量的核心。它是由Grafana Labs的VP Product，同时也是Prometheus和OpenMetrics早期贡献者Tom Wilkie于2018年提出的，旨在为现代服务（尤其是微服务）提供一套简单、一致且以服务为中心的监控指标集。

让我们逐一拆解：

R – Rate (请求速率)

• 它是什么？ 指服务在单位时间内（通常是每秒）处理的请求数量，我们常说的QPS (Queries Per Second) 或RPS (Requests Per Second) 就是它。
• 为何重要？ 它是服务负载的直接体现。请求速率的异常波动（骤增或骤降）往往预示着潜在的问题，比如突发流量、上游故障、甚至是恶意攻击。同时，它也是容量规划和弹性伸缩策略的重要依据。
• 关注什么？ 我们不仅要看服务的总请求速率，还应该关注：
  • 按API端点/服务接口划分的速率： 了解哪些接口最繁忙，哪些接口流量异常。
  • 按客户端类型划分的速率： 识别不同调用方的行为模式。

E – Errors (错误率)

• 它是什么？ 指服务在处理请求时，发生错误的请求所占的百分比，或者单位时间内的错误请求总数。在HTTP服务中，我们通常重点关注服务器端错误，即HTTP状态码为5xx的请求。
• 为何重要？ 错误率是服务可靠性的“晴雨表”，直接关系到用户体验。没有人喜欢看到“服务器开小差了”的提示。持续的高错误率是P0级故障的典型特征。
• 关注什么？
  • 整体服务错误率： 快速判断服务是否处于“亚健康”或故障状态。
  • 按API端点/服务接口划分的错误率： 精准定位是哪个功能出了问题。
  • 按错误类型/状态码划分的错误率： 帮助我们理解错误的性质，是代码bug、依赖问题还是配置错误。

D – Duration (响应时长/延迟)

• 它是什么？ 指服务处理单个请求所需的时间，也就是我们常说的“延迟”。
• 为何重要？ “天下武功，唯快不破。” 响应时长是用户体验的生命线。没有人愿意为一个需要加载半天的页面或应用买单。
• 关注什么？ 平均延迟很容易被少数极端慢请求“平均掉”，因此我们更关注延迟的百分位数 (Percentiles)，特别是：
  • P99 (99th percentile): 99%的请求都比这个值快。代表了体验最差的那1%用户的感受。
  • P95 (95th percentile): 95%的请求都比这个值快。
  • P50 (50th percentile / Median): 中位数延迟，代表了典型用户的体验。
  • 同时，也应关注不同API端点/服务接口的延迟分布。

RED方法 vs. 其他监控方法论

你可能会问，业界还有USE方法、Google SRE的“四个黄金信号”等，RED方法和它们是什么关系呢？

• USE方法 (Utilization, Saturation, Errors): 由性能大神Brendan Gregg提出，它更侧重于分析单个系统资源的健康状况，比如CPU使用率、内存饱和度、磁盘错误等。它是RED方法的重要补充，当RED指标显示服务异常时，USE指标能帮助我们判断是不是资源瓶颈导致的。
• 四个黄金信号 (Latency, Traffic, Errors, Saturation): Google SRE实践的精华。RED方法可以看作是对前三个信号（延迟、流量、错误）的一种更聚焦、更易于落地的诠释。RED中的Rate对应Traffic，Duration对应Latency，Errors对应Errors。RED巧妙地避开了相对抽象和难以标准化的Saturation（饱和度），使其更具普适性。

简单来说，RED方法是在前人智慧的基础上，针对现代分布式服务架构，提炼出的一套“最小完备”且“以用户为中心”的服务健康度量标准。

云原生时代，为什么RED如此重要？

微服务架构中，RED方法（Rate、Errors、Duration）为每个微服务提供了独立的监控手段，使得在故障发生时能够迅速定位问题服务。这种方法能够通过服务之间的调用链，清晰地衡量每一跳的性能，从而构建出完整的端到端视图。

在动态环境中，容器和实例的频繁创建与销毁，以及弹性伸缩的特性，使得传统基于单机资源的监控变得复杂。然而，服务级的RED指标能够稳定地反映服务的整体健康状况，无论其背后有多少实例在支撑。

此外，RED指标直接关系到用户体验。Rate、Errors和Duration三个指标分别反映了用户能否正常快速地使用服务。因此，这些指标对于提升用户满意度至关重要。

RED方法还提供了一套标准化的监控语言，适用于不同类型的服务，如HTTP API、gRPC服务和消息队列处理等。这种通用的监控词汇有助于团队的协作与知识传递。

最后，基于RED指标设置的告警能够更精准地反映真实的用户影响，降低误报率，使告警变得更加可操作。这种精准的监控和告警机制不仅提升了服务的可靠性，也增强了团队对服务健康状况的把控能力。

RED简单又强大，那么我们如何将它落地呢？下面我们就用一个服务的通用指标和告警设计为例，来看看RED方法下常见的服务指标和告警都有哪些。

如何落地RED监控？（通用指标与告警设计）

虽然具体的工具选择（如Prometheus, Grafana, SkyWalking, OpenTelemetry等）多种多样，但RED指标的设计思路是通用的。我们以一个常见的HTTP服务为例，看看如何设计其RED指标（遵循Prometheus指标规范）：

通用服务RED指标设计 (HTTP服务)

• http_requests_total (Counter类型): 记录处理的HTTP请求总数。
  • 核心标签 (Labels):
    • service_name: 服务唯一标识，如 “order-service”。
    • path: API路径模板，如 “/api/v1/orders/{id}” (注意使用模板，避免基数爆炸)。
    • method: HTTP方法，如 “GET”, “POST”。
    • status_code: HTTP响应状态码，如 “200″, “404″, “503″。
• http_request_duration_seconds (Histogram或Summary类型): 记录HTTP请求的处理时长。
  • 核心标签: 同上，status_code也可以用status_code_class（如”2xx”, “5xx”）来减少基数。

基于这两个基础指标，我们就可以通过查询语言（如PromQL）派生出RED指标：

• Rate (QPS):

sum(rate(http_requests_total{service_name="<your_service>"}[5m])) by (service_name, path, method)

• Error Rate (5xx错误率):

(sum(rate(http_requests_total{service_name="<your_service>", status_code=~"5.."}[5m])) by (service_name, path, method)) / (sum(rate(http_requests_total{service_name="<your_service>"}[5m])) by (service_name, path, method))

• Duration (P99延迟):

histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service_name="<your_service>"}[5m])) by (le, service_name, path, method))

基于RED指标的通用告警设计

告警的目的是及时发现问题并驱动行动。以下是一些基于RED的通用告警规则思路：

1. Rate告警 (请求速率异常)：
   • 规则： 服务总请求速率在过去10分钟内，与1小时前同一时刻相比，骤降70%以上（或骤增数倍）。
   • 级别： P1/P2 (视业务敏感度)
   • 告警提示： “[服务名]请求速率异常波动！”
2. Error告警 (错误率超标)：
   • 规则： 服务整体5xx错误率在过去2分钟内持续高于5%。
   • 级别： P0
   • 告警提示： “严重：[服务名]5xx错误率飙升至[当前值]！”
   • 规则： 某个关键API端点的5xx错误率在过去3分钟内持续高于10%。
   • 级别： P1
   • 告警提示： “警告：[服务名]接口[API路径]错误率过高！”
3. Duration告警 (延迟超标)：
   • 规则： 服务整体P99延迟在过去5分钟内持续高于2秒。
   • 级别： P0
   • 告警提示： “严重：[服务名]P99延迟高达[当前值]，用户体验受损！”
   • 规则： 某个关键API端点的P95延迟在过去5分钟内持续高于1秒。
   • 级别： P1
   • 告警提示： “警告：[服务名]接口[API路径]P95延迟过高！”

RED并非银弹：构建全面的可观测性

虽然RED方法非常强大，但它也不是万能的。一个完善的云原生可观测性体系，还需要：

• USE方法： 监控底层基础设施和节点的资源使用情况。
• 业务指标： 监控与业务直接相关的指标，如订单成功率、在线用户数等。
• 分布式追踪： 理解请求在复杂调用链中的完整路径和每一跳的耗时。
• 日志管理： 详细的日志是问题排查的“最后防线”。

将RED指标与这些数据源关联起来，才能形成从宏观到微观、从用户体验到系统内部的完整排查路径。

小结

在纷繁复杂的云原生世界，RED方法为我们提供了一套简洁、有效且以用户为中心的“导航系统”。它帮助我们聚焦于真正重要的服务健康指标，快速发现问题，优化性能，最终保障并提升用户体验。

希望今天的入门RED分享能对你有所启发。不妨现在就开始思考，如何在你的服务中实践RED监控吧！

你对RED方法有什么看法？在你的监控实践中，还有哪些好用的“三板斧”？欢迎在评论区留言交流！

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