xiaohack's Blog - 代码审查
type: channel
link: https://blog.xiaohack.org/tag/%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5/
items: 架构评审与技术债治理——质量属性、演进式重构与风险评估框架
items: 发布了多个常用skill，codex审核，搜索/爬虫工具（完全不依赖mcp）
items: SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具
items: 一醒来就吃了个大瓜
items: 大家都来分享一下自己的 vibe coding 技巧
items: AI Coding与单元测试的协同进化：从验证到驱动
items: Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
items: 分享一下我的 ClaudeCode 工作流：Kitty + Zed + superpowers，可以减少和 AI 的反复拉扯，一次做对

架构评审与技术债治理——质量属性、演进式重构与风险评估框架
type: item
date: 2026-02-04T06:30:00+08:00
description: 写在前面，本人目前处于求职中，如有合适内推岗位，请加：lpshiyue 感谢。优秀的架构不是一次性的设计杰作，而是通过持续评审、债务治理和渐进式重构形成的有机体系在构建了高可用的容灾体系后，我们面临一个更根本的挑战：如何确保系统架构本身具备持续演进的能力？架构评审与技术债治理正是连接短期交付压力与长期架构可持续性的关键桥梁。本文将深入探讨架构质量属性、演进式重构方法论与风险评估框架，帮助企业构建既满足当前需求又适应未来变化的弹性架构体系。1 架构可持续性：从静态设计到动态演进1.1 架构治理的范式转变传统架构观将系统设计视为一次性活动，而现代架构实践强调持续演进的理念。根据行业数据，拥有成熟架构治理体系的企业在系统维护成本上比缺乏治理的组织低40%，新功能交付速度快35%。架构可持续性的三大支柱：质量属性守护：通过明确的质量标准防止架构腐化技术债主动管理：将债务治理融入日常开发流程演进式重构机制：在保证业务连续性的前提下持续优化这种转变使架构工作从项目制活动转变为产品全生命周期的核心实践，确保了系统在整个生命周期内保持健康状态。1.2 架构评审的价值重估有效的架构评审不是障碍而是赋能，其核心价值体现在三个维度：风险防控价值：提前识别设计缺陷，降低后期重构成本。数据表明，架构阶段发现的问题修复成本是编码阶段的1/10，生产环境的1/100。知识传递价值：通过评审过程促进团队间架构共识，减少认知偏差。质量内建价值：将架构原则和质量要求植入设计阶段，而非事后修补。2 架构质量属性：可持续性的衡量基准2.1 核心质量属性体系架构质量属性为评审提供客观标准，避免主观判断的随意性。完整的质量属性体系涵盖多个维度：运行期质量属性关注系统执行时的表现：性能：响应时间、吞吐量、资源利用率可靠性：故障率、可用性、容错能力安全性：数据保护、访问控制、漏洞防护演进期质量属性影响系统变更和维护成本：可维护性：代码清晰度、模块化、文档完整性可扩展性：水平/垂直扩展能力、耦合度可测试性：单元测试覆盖率、集成测试便利性// 可测试性设计示例：依赖注入提升可测试性 public class OrderService { private final PaymentGateway paymentGateway; private final InventoryService inventoryService; // 通过构造函数注入依赖，便于测试时mock public OrderService(PaymentGateway paymentGateway, InventoryService inventoryService) { this.paymentGateway = paymentGateway; this.inventoryService = inventoryService; } public boolean processOrder(Order order) { // 业务逻辑 return true; } }依赖注入设计提升可测试性2.2 质量属性的优先级权衡不同业务场景下，质量属性的优先级需要差异化设置。一刀切的标准往往导致过度设计或质量不足。系统类型关键质量属性次要质量属性权衡考量电商交易一致性、可用性、性能可扩展性、可维护性强一致性可能降低性能大数据平台可扩展性、吞吐量实时性、一致性最终一致性提升吞吐量IoT边缘计算可靠性、安全性可维护性、性能离线能力优先于实时性质量属性权衡框架帮助团队基于业务上下文做出合理决策：# 质量属性权衡决策记录 decision_id: "perf-vs-maintainability" context: "订单查询服务需要优化响应时间" constraints: - "必须在200ms内返回结果" - "团队规模小，维护成本需控制" alternatives: - option: "引入缓存层" pros: ["性能提升明显"] cons: ["缓存一致性复杂化"] - option: "数据库查询优化" pros: ["架构简单"] cons: ["性能提升有限"] decision: "采用缓存层，但增加缓存失效策略" rationale: "业务要求性能优先，可通过工具降低维护成本"架构决策记录模板3 架构评审体系：多层次、全流程的质量保障3.1 分层评审机制有效的架构评审需要多层次覆盖，针对不同变更范围实施相应粒度的评审。战术级评审针对日常技术决策和代码变更，通过轻量级流程保障基础质量：代码审查：每个PR必须经过至少一名核心成员审查设计讨论：复杂功能在实现前进行团队内设计评审工具辅助：静态分析、代码规范检查自动化战略级评审针对系统级架构变更，通过正式流程保障一致性：架构委员会：跨部门专家组成，评审重大架构决策…

发布了多个常用skill，codex审核，搜索/爬虫工具（完全不依赖mcp）
type: item
date: 2026-01-25T08:03:33+08:00
description: 从上次说起用cc skill调用codex做代码审核 开发调优自从用了opus 4.5，codex是真用不上了，最近看到很多人用codex做代码审查还不错，但是我也不想挂一个mcp增加cc的昂贵上下文，就试了一下用新出的skill，果然效果很不错。 只需要输入“审核代码”cc就会自动按照流程处理changlog并调用codex review，然后返回codex审核的结果。 有时候cc可能还是会用自己的代码审核，这时就强调“用技能审核代码”，或者说“发动技…我的skill都可以在这里看到 skills.sh Skills by benedictkingDiscover and install skills for AI agents. 安装也是非常的简洁npx skills add BenedictKing/codex-review npx skills add BenedictKing/tavily-web npx skills add BenedictKing/context7-auto-research npx skills add BenedictKing/exa-search npx skills add BenedictKing/firecrawl-scraper 上下文占用非常少，主打的就是一个省钱还好用📌 转载信息来源： https://linux.do/t/topic/1510449原作者： Foward转载时间： 2026/1/25 08:04:37

SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具
type: item
date: 2026-01-21T12:05:28+08:00
description: SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具SonarQube Server 2025 Release 6 (macOS, Linux, Windows) - 代码质量、安全与静态分析工具Self-managed static analysis tool for continuous codebase inspection请访问原文链接：https://sysin.org/blog/sonarqube/ 查看最新版。原创作品，转载请保留出处。作者主页：sysin.orgSonarQube Server代码质量和安全性由您掌控之前称为 SonarQube，本地部署的用于持续代码库检查的静态分析工具保持 AI 生成的代码干净释放 AI 编码助手的强大功能，而无需承担不良、不安全代码的风险。SonarQube Server 是您的干净代码解决方案，可以部署在任何地方、本地或云环境中。受到 700 万开发者和 400,000 多个组织的使用和喜爱提高代码质量的代码质量工具您的代码是一项商业资产。通过 SonarQube Server 达到干净代码状态，实现代码的最高价值。SonarQube Server 功能：代码智能利用 SonarQube 的深度洞察，更全面地了解您的代码库。通过减少认知负荷来提高开发人员的生产力。与顶级 DevOps 平台集成轻松加入项目。与 GitHub Actions、GitLab CI/CD、Azure Pipelines、Bitbucket Pipelines 和 Jenkins 集成，以自动触发分析并显示您工作地点的代码运行状况。代码审查通过 SonarQube 的质量阈值，防止不符合策略的代码进入生产环境。消除人工编写和 AI 生成代码中的问题，从而降低后期修复成本。高性能和可操作性按照您的方式进行部署，无论是在本地、在云中、作为服务器、使用 Docker 或 Kubernetes。多线程、多个计算引擎和特定于语言的加载可提供最佳性能。顶级分析速度和准确性在几分钟而不是几小时内收到可操作的清洁代码指标 (sysin)。Clean as You Code 会在您工作时检查较小的代码片段，为您提供有关新代码质量的准确反馈。重要语言的关键安全规则在您的开发工作流程中，在正确的时间和正确的位置无缝地发现编码问题。受益于 6,000 多个规则以及行业领先的 Java、C#、PHP、Python 等污点分析。共享、统一的配置设置特定的编码标准，使您的团队在代码健康方面保持一致并实现您的代码质量目标。另外，“边编程边学习” 可将开发人员的技能提升到同样高的水平。用于 IDE 的 SonarQube添加 SonarQube for IDE 扩展并将其连接到 SonarQube 服务器，以便在编码时动态查找编码问题，并确保您的团队遵循单一受监管的编码标准。测量代码覆盖率查看测试执行的代码库的百分比，以获得有关代码运行状况的宝贵见解。引导您到覆盖率低的领域进行改进。Sonar 的人工智能AI 辅助编码，由 SONAR 改进新的 AI 代码保证Sonar AI 代码保证是一个强大且简化的流程，用于通过结构化和全面的分析来验证 AI 生成的代码。这确保了每一段新代码在投入生产之前都符合最高的质量和安全标准。AI CodeFix 简介Sonar AI CodeFix 是一项强大的功能 (sysin)，可为代码分析解决方案 SonarQube Server 和 SonarQube Cloud 发现的问题提供代码修复建议。只需单击一下，您就可以获得有关如何解决一系列问题的建议，从而简化问题解决流程。笔者提示：此类功能通常需要有效服务合同。安全漏洞检测增强的开发人员安全工具 | 安全与机密信息检测静态代码分析Sonar 的静态应用程序安全测试 (SAST) 引擎可检测代码中的安全漏洞，以便在构建和测试应用程序之前消除这些漏洞。使用 SAST 为复杂项目实现强大的应用程序安全性和合规性。机密信息检测SonarQube Server 包含一个强大的机密信息检测工具，这是用于检测和删除代码中机密信息的最全面的解决方案之一。与 SonarQube for IDE 一起使用，它可以防止机密信息泄露并成为严重的安全漏洞。安全标准合规性SonarQube Server 可帮助您遵守通用代码安全标准，例如 NIST SSDF。将 SonarQube Server 与 SonarQube for IDE 结合使用，可以自动检查项目代码是否存在安全漏洞，并提高整体代码质量。基于开源，满足所有需求的版本SonarQube Server 版本：Community Build免费开源，可提高开发效率和代码…

一醒来就吃了个大瓜
type: item
date: 2026-01-20T14:15:55+08:00
description: 公司的 im 有水印，就不发图了，简单总结一下 大数据/医疗部门因使用 ai 生成代码导致生产环境服务器负载拉爆且历史数据被大范围覆盖 it 部门排查开发电脑的 ai 相关软件，禁止 ai 自动代码生成 所有研发部门安排时间重新 review 近半年所有代码 对应研发部门的开发和测试绩效当月为 D(意味着 2026 年没有年终奖了，但是 2025 还是可以有的) 哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈（先笑一下🤣他们怎么敢的啊，又不是自己的项目，我用 ai 都只拿当搜索引擎，代码都是我自己的测试确认后才写到项目里面去我一直强调，ai 真的不能帮你背 D 绩效啊喂！

大家都来分享一下自己的 vibe coding 技巧
type: item
date: 2026-01-20T11:49:59+08:00
description: 我先来推荐做法 引导 AI 出方案你来 review, review 通过了以后，先让 AI 先写测试用例，让测试用例失败，让 AI 自动修复测试用例，你来 review 修复方案和代码。 多用 plan 模式，确认没问题了才让 AI 生成代码，不要一把梭不停的让 AI 修改代码 ，改来改去可能越改越奇怪，最好是把计划做好，这样效率和准确率更高。 不推荐 你来出方案，让 AI 实现，你来测试，让 AI 修复代码。

AI Coding与单元测试的协同进化：从验证到驱动
type: item
date: 2026-01-19T21:55:46+08:00
description: AI生成代码质量难以把控！本文分享来自美团的技术实践，三大策略破解AI编程痛点。单测快速验证逻辑正确性，安全网保护存量代码演进，TDD模式精准传递需求。告别「看起来没问题」的错觉，构建AI时代的代码质量保障体系。一、引言目前，国内外很多AI Coding助手能在几秒钟内生成完整代码块，大大提升了开发效率，但这种高速开发模式也带来了潜在风险——与人工编码不同是，AI Coding助手生成代码存在两个特殊风险：其一，AI Coding助手依赖于上下文与模型自身的能力，输出的代码质量相对不可控。其二，AI生成的代码虽然逻辑通顺、结构完整，但可能隐藏着难以察觉的边界问题或逻辑缺陷。核心问题：我们如何快速的验证AI生成代码的质量和可靠性？本文旨在分享如何借助单元测试，让AI编程合作更高效可靠，主要解决三个常见痛点：肉眼审查困境：AI一次性生成大量代码时，难以快速准确判断逻辑完备性；存量代码信任危机：如何验证AI修改老代码时，不会产生非预期的结果；需求传达难题：如何精准向AI表达复杂需求并快速验证。针对上述三个常见痛点，本文提出采用不同的单元测试策略来应对以上问题。每个策略都针对一个特定痛点设计：策略一通过测试解决肉眼审查的局限性；策略二构建单测安全网应对存量代码的信任问题；策略三则采用TDD模式优化需求传达与验证流程。下文将依次展开说明，希望能对大家有所帮助或启发。二、策略一：单测检验AI代码逻辑正确性2.1 问题背景传统的人工代码审查在AI生成的大量代码面前显得低效且不可靠。在软件测试实践中，有着测试左移（Shift Left Testing）的概念，本质上是借助工具和测试手段更早地发现问题和预防问题。在AI Coding时代，这一理念尤为关键：跳过单元测试直接集成测试看似”抄近路”，实则是将风险后置——开发阶段几分钟能发现的Bug，在集成测试环境可能需要较长定位修复，这中间包含了代码部署、环境准备、测试条件的准备、问题定位、开发人员修复、再次部署验证等一系列漫长的环节。相比之下，单元测试具有独特的优势：它能够独立运行、快速验证结果，并且可以无限次重复执行。这种测试方式就像是为项目进行的一次性投资，却能为整个开发周期构建起一张可靠的“安全网”。它不仅能实时验证AI Coding生成的代码是否正确，更能持续保障未来代码的质量稳定性，让开发团队始终对代码库保持信心。2.2 案例：分页查询接口的隐蔽Bug任务背景：实现一个支持多条件筛选的复杂分页查询接口pageQueryRobotAI生成了如下核心查询逻辑：public List<AgentRobotE> pageQueryRobotsByCondition(List<Long> shopIds, String chatSceneCode, Boolean enabled, Integer pageNo, Integer pageSize) { // ... 前置校验代码 ... // 分页查询机器人基础信息 int offset = (pageNo - 1) * pageSize; List<AgentRobotEntity> entities = robotIds.stream() .skip(offset) .limit(pageSize) .map(robotId -> agentRobotDAO.getRobotById(robotId, false)) .filter(Objects::nonNull) // 问题代码：类型不匹配的隐蔽Bug .filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled ? 1 : 0)) .filter(entity -> Objects.equals(entity.getChatSceneCode(), chatSceneCode)) .collect(Collectors.toList()); return entities.stream() .map(this::convertToModel) .filter(Objects::nonNull) .collect(Collectors.toList()); } 问题分析：这段代码看起来逻辑完整，但第8行的过滤逻辑包含了多个复杂元素：三元运算符 enabled ? 1 : 0Objects.equals 的使用Boolean到Integer的隐式逻辑转换仅凭肉眼很难发现其中的类型不匹配问题。单元测试发现问题：通过AI编写了17个全面的单元测试用例，覆盖：正常场景：各种有效参数组合边界场景：null值、空集合处理参数组合：enabled为true/false/null的不同情况@Test pu…

Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
type: item
date: 2026-01-19T20:03:41+08:00
description: 整理 | 华卫、Tina过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。一年多时间，编码 Agent“翻天覆地”Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。 Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。 Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？ Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。 在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。 展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。 Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？ Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。 此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。最顶尖工程师的干活秘诀：全靠 Agent？Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？ Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常…

Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
type: item
date: 2026-01-19T19:55:10+08:00
description: 整理 | 华卫、Tina过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。一年多时间，编码 Agent“翻天覆地”Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。 Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。 Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？ Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。 在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。 展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。 Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？ Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。 此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。最顶尖工程师的干活秘诀：全靠 Agent？Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？ Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常…

AI Coding与单元测试的协同进化：从验证到驱动
type: item
date: 2026-01-18T12:45:56+08:00
description: AI生成代码质量难以把控！本文分享来自美团的技术实践，三大策略破解AI编程痛点。单测快速验证逻辑正确性，安全网保护存量代码演进，TDD模式精准传递需求。告别「看起来没问题」的错觉，构建AI时代的代码质量保障体系。一、引言目前，国内外很多AI Coding助手能在几秒钟内生成完整代码块，大大提升了开发效率，但这种高速开发模式也带来了潜在风险——与人工编码不同是，AI Coding助手生成代码存在两个特殊风险：其一，AI Coding助手依赖于上下文与模型自身的能力，输出的代码质量相对不可控。其二，AI生成的代码虽然逻辑通顺、结构完整，但可能隐藏着难以察觉的边界问题或逻辑缺陷。核心问题：我们如何快速的验证AI生成代码的质量和可靠性？本文旨在分享如何借助单元测试，让AI编程合作更高效可靠，主要解决三个常见痛点：肉眼审查困境：AI一次性生成大量代码时，难以快速准确判断逻辑完备性；存量代码信任危机：如何验证AI修改老代码时，不会产生非预期的结果；需求传达难题：如何精准向AI表达复杂需求并快速验证。针对上述三个常见痛点，本文提出采用不同的单元测试策略来应对以上问题。每个策略都针对一个特定痛点设计：策略一通过测试解决肉眼审查的局限性；策略二构建单测安全网应对存量代码的信任问题；策略三则采用TDD模式优化需求传达与验证流程。下文将依次展开说明，希望能对大家有所帮助或启发。二、策略一：单测检验AI代码逻辑正确性2.1 问题背景传统的人工代码审查在AI生成的大量代码面前显得低效且不可靠。在软件测试实践中，有着测试左移（Shift Left Testing）的概念，本质上是借助工具和测试手段更早地发现问题和预防问题。在AI Coding时代，这一理念尤为关键：跳过单元测试直接集成测试看似”抄近路”，实则是将风险后置——开发阶段几分钟能发现的Bug，在集成测试环境可能需要较长定位修复，这中间包含了代码部署、环境准备、测试条件的准备、问题定位、开发人员修复、再次部署验证等一系列漫长的环节。相比之下，单元测试具有独特的优势：它能够独立运行、快速验证结果，并且可以无限次重复执行。这种测试方式就像是为项目进行的一次性投资，却能为整个开发周期构建起一张可靠的“安全网”。它不仅能实时验证AI Coding生成的代码是否正确，更能持续保障未来代码的质量稳定性，让开发团队始终对代码库保持信心。2.2 案例：分页查询接口的隐蔽Bug任务背景：实现一个支持多条件筛选的复杂分页查询接口pageQueryRobotAI生成了如下核心查询逻辑：public List<AgentRobotE> pageQueryRobotsByCondition(List<Long> shopIds, String chatSceneCode, Boolean enabled, Integer pageNo, Integer pageSize) { // ... 前置校验代码 ... // 分页查询机器人基础信息 int offset = (pageNo - 1) * pageSize; List<AgentRobotEntity> entities = robotIds.stream() .skip(offset) .limit(pageSize) .map(robotId -> agentRobotDAO.getRobotById(robotId, false)) .filter(Objects::nonNull) // 问题代码：类型不匹配的隐蔽Bug .filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled ? 1 : 0)) .filter(entity -> Objects.equals(entity.getChatSceneCode(), chatSceneCode)) .collect(Collectors.toList()); return entities.stream() .map(this::convertToModel) .filter(Objects::nonNull) .collect(Collectors.toList()); } 问题分析：这段代码看起来逻辑完整，但第8行的过滤逻辑包含了多个复杂元素：三元运算符 enabled ? 1 : 0Objects.equals 的使用Boolean到Integer的隐式逻辑转换仅凭肉眼很难发现其中的类型不匹配问题。单元测试发现问题：通过AI编写了17个全面的单元测试用例，覆盖：正常场景：各种有效参数组合边界场景：null值、空集合处理参数组合：enabled为true/false/null的不同情况@Test pu…

分享一下我的 ClaudeCode 工作流：Kitty + Zed + superpowers，可以减少和 AI 的反复拉扯，一次做对
type: item
date: 2026-01-15T20:52:26+08:00
description: 我的工作流是一个围绕 superpowers 插件 的 Loop，superpowers 的理念是：先思考再动手。当你提出一个需求，不会急于写代码，而是先退一步问你"你真正想要实现什么"，通过对话梳理出完整的设计方案，再分步执行。核心设计是 master 和 worker 分离。脑暴会话 (master)：专注于思考和设计，输出高质量的设计文档和执行计划执行会话 (worker)：专注于代码实现，执行详细的计划1、需求录入 - 首先我会在 Zed 上进行需求录入，采用 md 格式。这一步非常重要，我大概有 30% 的时间花在需求录入上，我会把能想到的关于此需求的背景、最终目标、可行的技术方案、风险点、外部 API 文档等等一切资源，都在需求文档中说明。对于需求文档，我不会太在意格式，会有比较多口语化的表达。2、脑暴阶段 - 把需求 MD 喂给 Claude，调用 /superpowers:brainstorm 和 claude 进行思维碰撞。这个阶段不写任何代码，只讨论设计方案和实现细节，最终输出 design.md 和 implement.md，保证最终的实现方案是完美符合我的预期的。3、 执行阶段 - 这里我会选择新起一个 ClaudeCode 会话，而不是在脑暴会话中进行代码实现。新会话的好处：一、原先脑暴会话已经经过多轮对话了，一般情况下上下文会比较满，新会话响应更快，并且不会“犯傻”；二、implement.md 足够详细，无需额外上下文4、 CodeReview - 在 Zed 中进行代码审查和功能验收。关于代码审查，对于一些代码细节和实现原理，这里我会使用 zed-agent 来辅助我进行代码 review，当然，你也可以在终端新建一个 ClaudeCode 会话或者使用 Zed 的 Claude Agent。原则是尽量不在脑暴和执行会话中引入太多不必要的问题，保持这两个会话的「干净」。发现问题后，将改进项写入新的需求 MD5、 LOOP - 改进项 MD 喂回脑暴会话，开始下一轮脑暴迭代非常简单，但是效果超群。充分的前期设计可以提升 AI 的效率和质量，避免多次的来回拉扯。举个真实案例：我用这套工作流将个人博客从 Quarz 框架迁移到 Astro 框架。脑暴阶段确认好设计方案后，我让 Claude 执行计划，然后就去睡午觉了。醒来发现 Claude Code 已经完美完成任务——中间零中断，一次成功，共计 5000+ 行代码变更。