近一天浏览数排行。
近三天浏览数排行。
从文章库里持续更新，保留摘要和分类，方便判断是否值得点开。
Andrej Karpathy宣布半年未亲手写代码，转而使用AI Agent驱动开发，标志软件工程进入新纪元。他提出软件3.0概念：LLM作为新型计算机，编程通过提示实现，产生‘参差不齐的智能’。行业趋势显示AI编程工具从Copilot到Claude Code快速进化，效率提升数百倍。然而，AI放大工程缺陷，Vibe Coding可能导致技术债务，而Agentic Engineering强调人类在架构、验证和责任感上的核心作用。方法论如Matt Pocock的Skills系统、Spec-Driven Development、Ralph Loop的自主循环和Garry Tan的gstack虚拟团队，共同应对验证差距。Harness Engineering聚焦Agent运行环境，确保可靠性。文章指出，当开发速度不稀缺，工程化成为壁垒，人类需提升品味、判断力和系统审美。作为卷首语，它引出本书对AI时代软件工程方法论的系统探讨。
goal-workflow 是一套AI驱动的研发工作流系统，旨在自动化从需求分析到代码交付的整个软件开发生命周期。系统通过四个标准化步骤实现端到端闭环：首先，/prd 命令利用AI生成结构化PRD文档和Issue卡片，通过交互式问题澄清需求并拆解任务；其次，/goal 命令基于Issue实现功能代码，AI代理自动分析代码库、编写实现并运行测试；然后，/review-it 命令进行可信代码审查，遵循验证后执行、拒绝噪音、迭代修复原则，确保代码质量；最后，/ship-it 命令自动化提交流程，包括git操作、创建PR、合并代码和关闭Issue。工具兼容Claude Code、Codex等多种AI代码编辑器，提供双语支持和灵活部署，集成GitHub Issues、本地Markdown等平台。其核心理念是让AI处理重复性、规则性工作，释放开发者专注于创造性任务，提升团队研发效率和个人开发速度，减少需求理解不一致和返工问题。
Google在2026年I/O大会上发布Antigravity CLI，正式取代Gemini CLI，整合进Antigravity产品家族。该工具与Antigravity 2.0桌面版共享统一Agent引擎，支持自然语言交互，用户可通过对话指令Agent完成代码编辑、工作流编排等任务。核心特性包括Subagents（子智能体），允许主Agent派生子Agent并行处理后台任务如文档查询、构建验证，并拥有完整工具权限；终端沙箱利用操作系统原生能力（macOS sandbox-exec、Linux nsjail、Windows AppContainer）实现安全隔离，零启动开销；插件系统提供打包命名空间，可部署技能、智能体、规则等组件。安装通过一键脚本跨平台完成，认证支持本地和SSH环境。三大核心斜杠命令：/goal启用深度工作模式，自动执行复杂任务直到目标达成，使用独立模型评判；/schedule设置定时或循环任务，基于Cron调度实现自动化检查和报告；/grill-me用于方案对齐，确保AI输出准确。Antigravity CLI定位终端优先、键盘效率，与桌面版互补共享设置，提供统一AI开发工具链。
本文探讨了AI驱动的代码审查工具链Clawpatch与codex-review skill，旨在解决传统代码审查中审查者缺乏完整上下文的核心矛盾。Clawpatch通过`clawpatch map`命令将代码仓库映射为包含入口点、归属文件、上下文文件和关联测试的语义特征单元，突破了传统逐文件扫描的局限。它支持主流技术栈的自动识别，并基于这些语义单元调用AI进行审查，生成结构化的findings，包含分类、严重程度、置信度和证据。其修复流程设计保守，通过`clawpatch fix --finding `进行显式修复，并严格执行格式检查、类型检查、lint和测试的验证流水线，确保安全性。`deslopify`模式则专注于清理可本地验证的代码质量问题。codex-review skill为基于Codex CLI的审查定义了一套标准化的SOP，强调审查输出仅为建议、需验证、拒绝不切实际的边缘案例、修复精准且需闭环验证，并推荐使用subagent以避免上下文污染。文章最后通过一个Next.js项目的实战演示，从初始化、构建语义映射、执行审查到逐条处理findings，完整展示了该工具链的工作流程。这篇文章属于工具介绍与实战教程类型，详细阐述了如何结合自动化工具与规范化工作流，实现高效、安全且可追溯的AI辅助代码审查。
CLIProxyAPI 是一个轻量级 AI API 代理服务器，核心功能是实现 OpenAI Responses API 与 Chat Completions API 之间的双向格式转换，从而解决 OpenAI Codex CLI 仅支持 Responses API 而国内模型如 DeepSeek、GLM、Kimi 等仅提供 Chat Completions API 的兼容性问题。工作原理涉及请求方向的格式映射（如将 instructions 转换为 system message）和响应方向的流式 SSE 数据支持。安装通过 Git 克隆和 Go 编译完成，配置灵活，支持多 Provider 和模型别名设置，配置文件采用 YAML 格式并支持热加载。路由机制允许通过 prefix 前缀或 alias 自动匹配指定 Provider，避免重名冲突。文章提供了详细的配置示例，包括添加新 Provider 和模型，以及关键配置项说明。此工具简化了 Codex CLI 与国内 AI 模型的集成，适用于有 API 代理需求的开发者。
在软件开发中，产品需求文档（PRD）和技术规格说明书（SPEC）是两个关键文档，分别对应需求分析和系统设计阶段。PRD由产品经理主导，聚焦于“做什么及为什么做”，从用户与商业视角定义产品功能，包括用户故事、业务目标和信息架构，旨在转化商业需求为具体功能描述。SPEC则由技术主管或工程师负责，回答“怎么做及做成什么样”，关注技术实现细节，如数据库设计、API接口规范和系统边界，将PRD中的抽象需求落地为结构化标准。文章通过建造房屋的类比生动阐释：PRD如同业主需求清单（如“别墅两层”），SPEC则类似施工图纸（如“客厅面积45平方米，承重墙使用C30混凝土”）。此外，文章指出行业正从“看PRD写代码”转向规范驱动开发（SDD），因AI能高效执行高度结构化的SPEC，凸显其在自动化开发中的价值。在敏捷流程中，PRD先用于需求评审，SPEC随后指导编码和测试，确保从概念到实现的连贯性。
在软件研发流程中，方案设计与SPEC（规格说明书）是两个关键但易混淆的文档类型。方案设计处于技术调研与评审阶段，核心是开放式的论证与权衡，通过对比多种备选方案（如缓存vs分库分表）来探索技术可行性，目的是暴露问题、达成共识，内容动态且可修改。SPEC则位于最终确认与开发阶段，作为闭环式的施工图，定义精准的技术细节，如API接口格式、数据库表结构和边界条件，提供静态、确定的执行标准，直接指导前端开发、测试用例编写等任务。例如，造桥场景中，方案设计讨论悬索桥与斜拉桥的选型理由，而SPEC规定斜拉索直径、混凝土标号等具体参数。实践中，团队可能将两者合并使用，前半部分写架构分析，后半部分写接口设计，以兼顾灵活性与确定性。理解区别有助于在不同研发阶段选择合适文档，提升协作效率与交付质量。