Search: #软件开发

  1. 《Uncle Bob 的 ub-mode:给 AI 编程助手装上"纪律开关"》

    《Uncle Bob 的 ub-mode:给 AI 编程助手装上"纪律开关"》

    标签:
    #软件工程 #AI编程辅助 #TDD #代码质量门禁

    总结:
    这是 Robert C. Martin(Uncle Bob)发布的一个 AI 智能体技能(agent skill),用于在 AI 编写或修改代码时强制执行严谨的软件工程纪律。它部分借鉴了 poteto-mode 的规则体系并加以精简,同时配套一组确定性的质量门禁工具(复杂度、重复率、变异测试),让"先让它能工作,再让它正确,最后持续练习"的原则可度量、可落地。

    文章要点:
    1. 核心理念分三层:先让它能工作(懒惰协议、TDD、先减后加、领域建模、边界与类型纪律等),再让它正确(修复根因、测试行为而非实现、持续重构),最后落实到日常练习(记日志、守护上下文窗口、小而有序的提交)。
    2. 规则部分借鉴并精简自 poteto-mode:作者明确说明 ub-mode 是 @poteto 规则集的删减版,与确定性工具搭配使用。
    3. 配套四个质量门禁工具仓库:crapper 计算圈复杂度与 CRAP 分数(要求 CRAP < 10),dryer 检测结构重复(相似度 ≥ 0.8 即需消除),mutator 做变异测试揪出"测试杀不死的活口",uml-viewer 可视化组件、覆盖率与依赖方向。
    4. 安装方式极简:只需把 SKILL.md 复制到所用 AI 工具的 skills 目录(如 /.claude/skills/ub-mode/),然后输入 /ub-mode 即可调用。
    5. 目标很明确:把 Uncle Bob 倡导的软件工艺原则变成 AI 编码时可检查、可强制执行的硬约束,而不是口头建议。

    URL:https://github.com/unclebob/ub-mode GitHub - unclebob/ub-mode

  2. 《Thorsten Ball:我对软件开发未来的16条判断》

    《Thorsten Ball:我对软件开发未来的16条判断》

    标签:
    #软件工程 #AI编程 #代码审查 #单元测试 #终端工具 #Token计算范式 #开源生态 #软件开发未来 #ThorstenBall

    总结:
    2026年9月19日,知名开发者、《Writing An Interpreter In Go》作者、现供职于 Sourcegraph/Amp 的 Thorsten Ball 在 X 发布长文,抛出 16 条关于软件开发未来的判断。核心观点是:当 AI 写代码的可靠性足够高时,为人类防错而设计的整套工程实践(代码审查、单元测试、终端、命令行工具)都会逐渐失去必要性,工程师的价值将从"写代码的手艺"迁移到"理解业务、判断取舍、拿到反馈"上,而这一切需要一代人的时间完成。

    文章要点:
    1. 代码审查已死——人类不会再逐行 review 模型产出的代码,只会审查"系统与其组合方式"。
    2. 单元测试可能会消失——他让模型写 900 行 Arduino C 代码零错误一次通过,"摔不了跤就不需要护膝"。
    3. 写代码这门手艺会消失,但"造软件"(解决业务问题、判断何时上线、获取反馈)会比以往更重要。
    4. 大多数 bug 将不再是代码 bug,而是"你需求提错了"的 bug。
    5. 终端已死——Shell、编辑器、CLI 工具会被 token 冲刷,命令行知识将像 Perl 一行流一样变成"古老技艺"。
    6. Token 是新的计算范式,我们正在进入"后二进制时代",一切都会在它之上被重构。
    7. PM/设计/工程的铁三角和 Agile、Scrum 都会瓦解,只做"人肉代理"的工程师将不再有价值。
    8. 大小公司的工程差距会拉大——小团队比学大厂做法的初创公司跑得更快。
    9. "好代码"的标准(人类易读易维护)建立在人类要改代码的前提上,这个前提正在崩塌。
    10. 现有形式的开源不再合理——"众眼监虫"依然成立,但现在有了"人工眼睛"。
    11. 拿不到足够 token 的人会被排除在软件生产之外,token 是新的生产力门槛。
    12. 便宜模型未必有人用——更聪明的模型犯错少、轮次少,你未必愿意忍受它多错几次。
    13. 模型快到一定程度后,UI 会被实时生成,菜单、设置页、仪表盘这些"面向人类的 API"会大幅减少。
    14. 这场变革不会一夜发生——新旧范式更替需要一代人的时间,但反问是:"10年后还有写代码的工作,可你想要那份工作吗?"

    URL:https://x.com/thorstenball/status/2101305394190557466 Thorsten Ball (@thorstenball) on X

  3. 《我实测了11个HTTP弹性库的21个场景,结果如何?》

    《我实测了11个HTTP弹性库的21个场景,结果如何?》

    标签:
    #软件开发 #HttpResilience_对比测试_Retry_CircuitBreaker_Hedging_取消与超时正确性

    总结:

    作者在开发自己的 fetch 弹性封装库 ffetch 时发现了大量隐藏的正确性问题,于是搭建了一套覆盖 21 个场景的测试矩阵,对 11 个流行的 HTTP 弹性库(包括自己 ffetch 5.7.1)进行横向对比。结果显示:基础的"重试"行为在所有库中都表现良好,但 25 个失败几乎全部集中在组合场景——取消发生在退避等待中、超时与重试叠加、队列中的请求被取消、熔断器半开状态下迟到响应等。作者也坦承测试套件源自自己修过的 bug,存在确认偏差,且部分判定标准(如取消后必须立即停止派发)严于官方文档。矩阵每周自动重建并公开于 fetchkit.org/http-resilience。

    文章要点:

    1. 测试方法很扎实:21 个场景覆盖重试、超时、熔断、舱壁、对冲、请求去重,用脚本化 fetch + Vitest 假定时器精确控制中止时刻,jitter 固定 random=0.5,并附 2 个真实 node:http 集成场景。

    2. 全部 11 个库都通关的"共同强项"是基础重试类场景:重试恢复、重试耗尽、零重试、真实 HTTP 重试、请求体字节级回放,共 55/147 个实现单元。

    3. 失败高度聚类于"组合场景":典型如"重试 + 退避中取消",fetch-retry、ofetch、wretch、resilient-fetch-client、fetch-resilience、@resili/fetch 六库会延迟结算甚至取消后继续派发请求;fetch-retry 的源码问题暴露——退避用的是裸 setTimeout,从不读 init.signal。

    4. 舱壁队列几乎全军覆没:五家有队列的库中四家在"排队请求被取消"场景全挂——取消的调用方仍占着坑位不放,替换请求被拒,个别还照样派发了已取消的请求,ffetch 是唯一通过者。

    5. 重试 + 整体超时、Retry-After + 取消、hooks 抛错等场景暴露多家库"超时只罩单次尝试不罩重试循环"、回调拒绝后调用方永久挂起等问题,wretch 甚至会变成一个永远 await 的悬空 Promise。

    6. 对冲(hedging)是最不成熟的表面:仅三个库提供带可配置启动延迟的对冲;flowshield 在所有超时设置下都失败,超时后仍启动对冲分支且分支不收手,等于白发给服务器一个没人等的请求。

    7. 熔断器组合场景里作者自己的 ffetch 也栽了:半开状态下迟到成功响应会错误清除新开启状态(缺代次计数器);fetch-smartly 和 ts-retry-circuit 更严重,新冷却期被误清导致下一个请求吃掉本应给健康调用方的恢复响应。

    8. 作者最后强调方法论局限:无性能基准、无 API 设计评价,场景源于自己修过的 bug 存在确认偏差;建议读者不要只看"功能有没有",而要按自己应用的真实组合方式去测。

    URL:
    https://blog.gaborkoos.com/posts/2026-10-04-I-Tested-11-Http-Resilience-Libraries/

  4. 《在 GitHub Copilot 应用中流畅渲染超大 Pull Request》

    《在 GitHub Copilot 应用中流畅渲染超大 Pull Request》

    标签:
    #软件工程 #前端性能优化 #PullRequest #虚拟化渲染 #React #测量调度 #滚动锚定 #性能监控

    总结:
    文章介绍了 GitHub Copilot 应用如何重构 Pull Request 视图,使其能够流畅处理包含 2,200 个文件、超过 100 万行代码变更和 400 多条内联评论的超大型 PR。核心挑战在于评论高度的动态性——与代码行不同,评论高度取决于 Markdown 换行、可展开区块、回复框和图片加载等渲染时才能确定的因素。团队通过分离确定性与动态几何、实现智能测量调度器、采用滚动锚定技术,并建立自动化测量循环来解决这一问题,最终实现了百万行 diff 的流畅浏览体验。

    文章要点:

    1. 代码与评论的几何分离:代码行高度固定且可预先计算,而评论高度动态变化。团队将文档高度分为确定性代码高度(精确前缀和)和动态块高度(估算后测量),两者独立管理,避免评论调整时重建整个代码几何。

    2. 智能测量调度器:放弃每块一个 ResizeObserver 的方案(会触发反馈循环),改为单一的空闲和滚动门控测量通道。仅在视口附近约 2400px 范围内进行测量,屏幕上的块优先批量读取,离屏块最多做一次有限渲染,超过视口高度的块跳过测量。

    3. 滚动锚定技术:当测量高度与估算不符时,通过身份而非像素来校正——记录用户锚定的行或块,应用高度增量后,将同一锚点解析到新像素位置并滚动,确保用户视线不跳动。区分用户滚动与程序滚动,避免侧边栏切换等操作误触发保护机制。

    4. 数据管道优化:流式传输结构优先于内容,文件树和元数据在文档加载时即可渲染;语法高亮在主线程外运行,行先以纯文本显示;释放文档时保留最近几个 diff 的缓存,平衡内存与返回时的加载速度。

    5. 自动化测量循环:建立"变更→测量→改进"的无人值守循环,包括无头探针车道(声明式流程 + 生产环境插桩)和自动驾驶仪(驱动真实桌面应用),通过健康信号(如无未填充间隙、评论块非空)自动检测问题,实现机械式调试而非人工复现。

    URL:
    https://github.blog/engineering/user-experience/rendering-huge-pull-requests-in-the-github-copilot-app/ Rendering huge pull requests in the GitHub Copilot app

  5. 《我们现在都是产品工程师了》

    《我们现在都是产品工程师了》

    标签:
    #软件开发 #AI与编程 #职业转型 #产品工程 #就业市场

    总结:

    文章要点:

    1. 作者提出了两个核心假设:AI智能体将吞噬整个软件开发生命周期,以及软件需求没有上限。基于这两个假设,他对未来10年软件行业进行了预测。

    2. 软件开发成本正在发生结构性变化:编写代码的成本已经崩溃,代码审查和维护即将被自动化,运维和扩展将是下一个被攻克的领域。

    3. 未来软件开发的剩余核心工作是:发现人们真正想要什么、精确定义"好"的标准、让产品变得令人愉悦。这些成本无法规模化转移,将成为新的职业重心。

    4. 初级程序员岗位正在消失:22-25岁AI暴露岗位就业率比预期低19%,科技巨头入门级招聘自2019年下降65%,因为智能体已经能够完成初级开发者的工作。

    5. 代码审查和维护即将被自动化:前沿模型在真实代码库修复bug的基准测试上,两年内从50%提升到95%,更难的测试上达到59%。

    6. 产品工程师(Product Engineer)成为新职业形态:Palantir创造的"前线部署工程师"岗位在2025年增长800%,平均薪资约24万美元,职责是理解客户需求并定义"好"的标准。

    7. 培训体系存在巨大缺口:市场急需具备上下文理解和品味的人才,但目前每年只有约50人通过Google APM等项目接受正式培训,而传统的初级开发者培养管道已经断裂。

    8. 编程作为一门手艺正在消亡:许多程序员热爱的是编程本身,但未来的工作将主要是与客户沟通、提取需求,这对很多人来说是一个巨大的转变。

    9. 未来10年将充满动荡:初级岗位消失、新岗位培训体系尚未建立、许多热爱编程的人需要适应新角色。但10年后,行业将发展为更大规模、薪资相当、以产品工程为主形态的职业。

    10. 软件需求实际上是无限的:当前许多软件糟糕不是因为没人会做好,而是因为需求方付不起高价。当开发成本趋近于零时,这些需求将被释放。

    URL:
    https://seldo.com/posts/we-are-all-product-engineers-now/

  6. 《与 AI 协作的五种软件工程角色》

    《与 AI 协作的五种软件工程角色》

    标签:
    #编程 #AI协作 #软件工程 #人机协作 #开发者角色 #技术管理 #AI编程 #团队协作

    总结:

    这篇文章由资深软件工程师 Nicholas C. Zakas 撰写,系统性地梳理了 AI 编程时代下人类开发者与 AI 协作的五种角色模式。作者将传统软件工程中的协作关系映射到人机协作场景中,为开发者提供了从深度参与到完全托管的完整光谱,帮助团队根据信任程度、风险等级和技术背景选择最合适的协作方式。

    文章要点:

    1. **观察者(Observer)模式**:这是最基础的人机协作方式,开发者像结对编程中的观察员一样实时监控 AI 写代码。虽然能确保代码质量,但会面临严重的"审查疲劳"——AI 生成代码的速度远超人类阅读速度,导致效率瓶颈。

    2. **技术负责人(Tech Lead)模式**:开发者负责编写技术规格说明书,设定自动化检查(代码格式化、Lint、测试覆盖率),然后让 AI 并行执行多个工作流。这种模式能成倍提升生产力,但核心挑战在于需要大量自动化投资来减轻人工审查负担。

    3. **架构师(Architect)模式**:开发者只关注高层系统设计、组件接口和基础设施选型,不再审查具体代码实现。风险在于过度脱离代码细节——当系统出问题时可能缺乏底层知识来诊断和修复,因此需要定期抽查生成的代码和测试。

    4. **工程经理(Engineering Manager)模式**:开发者专注于搭建"软件工厂"流程,定义从 PRD 到技术规格再到实现计划的完整生产流水线,将任务分配给不同 AI 代理并设定验收标准。挑战在于流程失败时,过度依赖流程重构可能不如直接介入解决问题高效。

    5. **产品经理(Product Manager)模式**:开发者完全脱离技术实现,只关注用户体验和产品功能。虽然能完成产品级工作,但最大风险是技术债务——当 AI 造成问题时,往往只能贴创可贴式的临时修复而非根治,导致系统长期依赖外部维护。

    6. **动态选择策略**:没有绝对最优的角色,关键在于根据任务风险、对 AI 的信任度和技术上下文灵活切换。探索陌生代码库时当观察者,协调多任务时当技术负责人,追求用户体验时当产品经理。随着对 AI 能力信心的增强,可以沿光谱向更轻量的角色移动,但始终要对最终结果负责。

    URL:
    https://humanwhocodes.com/blog/2026/09/five-roles-working-ai/ Five software engineering roles for working with AI - Human Who Codes

  7. 《框架还重要吗?》

    《框架还重要吗?》

    标签:
    #编程 #Web开发 #AI编程 #前端框架 #React #软件工程 #技术趋势 #VibeCoding

    总结:

    这是一篇探讨在 AI 编程时代 Web 框架是否仍然重要的深度分析文章。作者 Brooks Lybrand 作为拥有三年开源框架开发经验的前端工程师,针对"模型已经足够好,框架选择不再重要"的流行观点进行了系统性反驳,论证了框架在提供抽象、结构和约束方面的核心价值,并呼吁行业继续创新和构建新框架。

    文章要点:

    1. **对"React 已赢"论的质疑**:作者指出当前流行观点认为由于 LLM 训练数据中 React 代码最多,模型最熟悉 React,因此无需尝试其他框架。但他认为这种逻辑存在矛盾——如果框架真的不重要,那连 React 都不需要,直接用 Web Components 或让 AI 生成原生代码即可。

    2. **框架的本质价值**:作者将框架的价值精炼为三点:**提供抽象(Abstractions)、结构(Structure)和约束(Constraints)**。这些价值不仅适用于人类开发者,对 AI 编程同样关键——良好的抽象能避免 AI 重复造轮子或创建混乱的临时方案;清晰的结构帮助 AI 生成可维护的代码;明确的约束(如类型检查、测试)能防止 AI 在迭代中破坏系统。

    3. **AI 时代框架的隐性存在**:引用 React 核心团队成员 Ricky Hanlon 的观点"你要么使用框架,要么构建框架",作者强调即使不显式选择框架,AI 在生成代码时也会隐式地创建框架。与其让 AI 生成一个缺乏维护、充满临时补丁的"隐性框架",不如使用经过实战检验、文档完善的开源框架。

    4. **开发者体验(DX)的重构**:通过分析 HMR(热模块替换)、TypeScript 和 useEffect 等具体技术,作者说明某些传统 DX 功能对人类开发者的价值正在转变,但对 AI 编程仍至关重要。例如 TypeScript 的类型约束能有效防止 AI 在复杂应用中引入错误,而 useEffect 这类强大但易误用的抽象则应该避免让 AI 随意使用。

    5. **框架战争的终结与新机遇**:作者认为 2013-2024 年的"框架战争"已经结束,人们不再渴望为框架争论,但这不意味着框架不再重要。他指出当前框架领域仍存在明显不足,特别是缺乏真正全栈、基于 Web 标准、易于 AI 协作且代码可理解的 JavaScript 框架。

    6. **对未来的呼吁**:尽管承认 AI 正在重塑软件开发,且没人知道其长期影响,作者仍坚持认为认为"所有问题都已解决"是一种颓废的态度。他呼吁继续构建新框架,探索更好的抽象和模式,而不是停留在"现有框架足够好"的舒适区。

    URL:
    https://brookslybrand.com/posts/do-frameworks-matter-anymore/

    > 个人觉得有点片面化,remix 脱离 react 转而用 preact 自创轮子

  8. 《AI 正在重演前端的"失落十年"吗?》

    《AI 正在重演前端的"失落十年"吗?》

    标签:#前端 #AI编程 #职业发展 #软件工程 # craftsmanship #Bauhaus

    总结:
    作者将 AI 对编程行业的冲击与前十年 JavaScript 框架对前端的"去技能化"(deskilling)进行类比。框架把浏览器当作编译目标,让通用开发者无需理解 HTML 语义、无障碍、性能等底层知识就能"搞定"前端;AI 编码则进一步将手工写代码的技能消解为"操作半熟练工人使用的技术"。文章认为这降低了从业者议价能力、牺牲了质量,但也承认这是效率提升和抽象层级升高的必然趋势。作者借用 Bauhaus 运动的启示——不是对抗工业化,而是让工匠与工厂协作、以用户为中心重新设计——呼吁在 AI 时代依然需要"懂材料"的人,同时指出商业成功与软件质量本就很少相关,真正的 craft 只会成为更小的切片。

    文章要点:
    1. "去技能化"正在从特定领域扩散到整个编程行业:框架让前端从专精技能变成通用技能,AI 让编程本身面临同样命运
    2. 现代"全栈开发者"往往不是前后端都精通,而是能用框架两边都糊弄的通才,企业因此获得成本节省和人员灵活调配
    3. AI 编码是"非确定性抽象"——不像编译器那样稳定,输入或模型的微小变化会导致截然不同的结果,更像是"不会学习的初级工程师"
    4. LLM 是 Stack Overflow 复制粘贴的终极进化:让懂行的人更快,让不懂的人也能凑出"能跑"的东西,但抽象泄漏时依然需要有人深入理解并修复
    5. 商业成功与软件质量几乎不相关,糟糕的网站对转化率影响有限,且"没人因为选了 React 而被解雇"
    6. Bauhaus 运动的启示:不复古也不对抗工业化,而是让设计师回到工坊、与材料共事,最终产出兼顾批量生产和用户体验的设计
    7. 前端 craft 不会消失,但会成为更小的切片;就像字体设计不再是全职工作、塑料垃圾泛滥但好工业设计依然存在
    8. 快速迭代和 MVP 有其价值,但需要知道自己在验证什么;性能和无障碍等基础如果一开始没做对,后期很难补救
    9. AI 只是工具箱里的又一件工具,但 hype 周期内我们会看到丑陋的代码、破碎的沟通和借 AI 之名裁员
    10. 作者自己的框架 Mastro 倡导"从简单栈开始、后续再添加功能",反对先上重型框架再试图优化

    URL:https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/

  9. 《AI辅助工程师正在倦怠,这真的没问题吗?》

    《AI辅助工程师正在倦怠,这真的没问题吗?》

    标签:#软件工程 #AI辅助编程 #职业倦怠 #心理健康 #开发者体验 #生产力陷阱

    总结:

    文章揭示了AI辅助编程带来的隐性危机——AI倦怠。尽管AI让代码产出速度翻倍,但工程师们实际工作强度更高、成就感更低。文章通过"Ben和Alice"的认知负荷对比分析,指出AI将编程从"计划→ crafting→结果"的愉悦循环,变成了高强度审查和调试的消耗模式。同时探讨了失去代码库上下文、被动思考时间被挤压、虚假期望膨胀等日常 burnout 诱因,并提供了五条可落地的自救建议:认可自身价值、重构AI工作流、保留手工编码时间、严守工作边界、探索新兴趣领域。

    文章要点:

    1. AI让产出翻倍,却让工作强度翻倍——Alice用2小时完成Ben 4小时的活,但认知负荷极高且停不下来,最终4小时内做了2倍高强度工作,成就感反而更低

    2. 编程的快乐循环被打破了——以前"计划→写代码→看到结果"的过程很治愈,现在变成"计划→直接看AI生成的结果",跳过了最享受的crafting环节,只剩下累人的审查工作

    3. 你的代码库正在"离开你"——AI代理帮你记住了架构和边界情况,你不再需要在脑中维护整个系统,久而久之直觉判断力下降, supervising一个自己不懂的系统超级累

    4. 被动思考时间被AI偷走了——以前洗澡、散步时大脑后台会默默解题,现在跟AI几分钟来回就"搞定"了,但往往是次优解,后面还要返工

    5. 虚假期望是个陷阱——AI初期进展顺利,客户/老板把冲刺速度当成基线,等瓶颈出现时你反而要拼命维持那个不可能的节奏

    6. 审查瓶颈在转移压力——AI生成代码量远超单人审查能力, senior工程师被迫承担不成比例的风险和认知负荷,维护系统 sanity 越来越吃力

    7. 五条自救建议超实用——包括写胜利日志、Plan模式优先、不连续做AI任务、保护手工编码时间、到点就停不补任务等,帮你把AI从"消耗品"变回"助手"

    URL:

    https://evilmartians.com/chronicles/ai-assisted-engineers-are-burning-out-is-this-fine AI-assisted engineers are burning out, is this fine?—Martian Chronicles, Evil Martians’ team blog

  10. 《AI重塑软件行业:从稀缺到泛滥的四大影响》

    《AI重塑软件行业:从稀缺到泛滥的四大影响》

    标签:#科技趋势 #AI变革 #软件行业 #SaaS #VibeCoding

    总结:
    AI让软件开发门槛骤降,软件正从"高壁垒高尊重"的稀缺品变成"人人可评判"的日用品。行业将经历薪资压缩、选择过剩导致用户忠诚度下降、中层产品消亡等剧变。未来赢家不再卖工具,而是直接卖服务结果;个人需成为领域专家或超级个体,才能在幂律分布中存活。

    文章要点:
    1. 软件行业正在"营销化":门槛降低+可见性提高=尊重崩塌。就像没人敢评判数学证明,但人人能对落地页配色指手画脚一样,VibeCoding让外行也能"看懂"软件,开发者薪资分布将从当前最紧的2.65倍向写作/设计行业的3.5倍扩散
    2. 选择悖论杀死用户忠诚度:当项目管理工具有3个时你会选定一个,有300个时你会不断寻找"完美匹配"甚至自己Vibe一个。软件将从差异化卖点变成像水一样的基础资源
    3. 中层SaaS即将灭绝:App Store里1%的App拿走95%收入,SaaS也将幂律化。中等规模公司(收费高但无网络效应)会被免费AI工具和大平台两头挤压,同时超长尾的"一次性个人工具"将爆发式增长
    4. 卖服务而非卖产品才是未来:企业每花1美元买软件,花6美元买服务。AI时代的机会是用软件成本做服务生意——不是卖更好的记账软件,而是直接帮你把账做完。专家可以服务200个客户,AI处理琐事,人只做判断

    URL:
    https://www.terezatizkova.com/writing/software-abundance Software is becoming marketing

  11. 《Vibe_Coding已死:Agent工程取而代之》

    《Vibe_Coding已死:Agent工程取而代之》

    标签:#AI #Agent #软件工程 #VibeCoding #多Agent协作

    总结:

    本文作者Collin Wilkins指出,"Vibe Coding"(凭感觉编程)这一由Karpathy提出的概念已被其本人"杀死"——现在的开发者99%时间不是在写代码,而是在编排Agent。作者分享了自己工作方式的转变:从一年前80%代码手写,到现在主要分解问题、分配Agent并审核输出。文章强调,2026年2月的四大模型发布都将多Agent编排作为核心能力,真正的差距在于工作流而非工具。

    文章要点:

    - Vibe Coding的致命缺陷:它只优化了代码生成速度,却忽视了后续环节——SonarSource调查显示AI代码占提交量的42%,但96%的开发者不完全信任它,仅48%会在提交前验证,审查负担真实存在且大多数团队根本没做
    - Agent工程的新范式:先规划和设计系统,定义边界和契约,再让Agent在约束内执行,像分布式系统工程一样处理Agent编排——同样的分解、组件间契约、可观测性
    - 多Agent成为主流:Claude的Agent团队用2000次协调会话构建了10万行C编译器,Kimi K2.5单个任务可运行100个子Agent进行1500次工具调用
    - 工作方式的彻底转变:作者现在每天的工作是分解问题、分配Agent、审核输出,"写代码"已不能描述他的日常工作
    - AI是动力工具而非替代品:会用AI的工程师交付更快,但只会用AI的工程师交付垃圾,关键是知道何时该提示、何时该思考
    - 瓶颈已转移:写代码不再是慢的部分,思考要构建什么、如何组合、什么会在规模下崩溃——这些才是耗时的地方
    - 文档化决策:LLM不存储上下文,如果想让AI助手在现有代码库上快速移动,它需要加载已记录的决策

    文章URL:

    https://buttondown.com/collinwilkins/archive/vibe-coding-is-dead-heres-what-replaced-it/ Vibe coding is dead. Here's what replaced it

  12. 《编程 Agent 如何重塑工程、产品和设计》

    《编程 Agent 如何重塑工程、产品和设计》

    标签:#AI #编程Agent #软件开发 #产品经理 #系统设计 #VibeCoding

    总结:

    编程 Agent 正在颠覆传统的 EPD(工程、产品、设计)协作模式。当代码生成变得轻而易举,团队的核心价值从"写代码"转向"评审代码"。PRD 不再是流程起点,而是与原型并行的意图说明文档。这场变革让通才价值飙升,也让角色边界变得模糊——你要么是能用 Agent 独立完成功能的建设者,要么是具备顶级系统思维的专业评审者。无论出身产品、设计还是工程,拥有跨领域认知和清晰心智模型的人,将在这个新时代占据绝对优势。

    文章要点:

    - **PRD 的角色正在蜕变**:传统的"PRD → 设计稿 → 代码"线性流程已终结,但描述产品意图的文档依然重要。未来的 PRD 可能是结构化的、带版本管理的 Prompt,与可运行的代码原型共同构成评审基础。

    - **瓶颈从实现转向评审**:当任何人都能快速生成代码原型时,工程、产品和设计的核心价值转变为把关质量——评估架构合理性、用户价值与体验流畅度。评审能力成为新的稀缺资源。

    - **通才迎来黄金时代**:能同时驾驭产品思维、设计直觉和工程实现的"多面手"比以往更有影响力,因为他们省去了跨部门沟通的成本,可以直接与 Agent 协作完成端到端的交付。

    - **角色分化为建设者与评审者**:团队将呈现两极分化。建设者擅长用 Agent 快速落地想法;评审者则是各领域的系统思维专家,负责把关复杂项目的质量。中间地带的从业者面临最大挑战。

    - **产品意识成为全员必修课**:无论是工程师还是设计师,都需要具备判断"该做什么"的能力,否则会产生大量需要他人评审的"垃圾原型",拖累团队效率。

    - **AI 放大 PM 的能力差距**:优秀的产品经理能借助 Agent 快速验证洞见,而思考不清晰的 PM 会产生更多低质量原型,造成资源浪费并增加"半成品上线"的风险。

    文章URL:

    https://baoyu.io/translations/2026-03-11/coding-agents-reshaping-epd 编程 Agent 如何重塑工程、产品和设计

  13. 《从写代码到管 Agent:斯坦福首门 AI 软件开发课的启示》

    《从写代码到管 Agent:斯坦福首门 AI 软件开发课的启示》

    标签:#AI #Agent #软件工程 #斯坦福 #职业发展 #人机协作 #代码质量

    总结

    本文是对斯坦福讲师 Mihail Eric 访谈的解读,他是全美首门 AI 原生软件开发课程 CS146S 的负责人。文章分析了初级开发者面临的"三重风暴"(裁员潮、毕业生激增、AI 替代压力),提出 AI 时代工程师的核心竞争力已从写代码转向"管理 Agent"——即编排多个 AI Agent 完成复杂任务的能力。同时强调 Agent 友好的代码库需要充分的测试覆盖、一致的文档和清晰的设计模式,这些本质上也是对人友好的工程实践。文章还指出资深开发者往往因路径依赖抗拒 AI 工具,而初级工程师的"无知无畏"反而成为快速适应新范式的优势。

    文章要点:

    - **初级开发者的三重困境**:COVID 后企业裁员 20-30%、CS 毕业生十年翻倍、雇主倾向"少招人+AI"策略,叠加导致新人求职难度激增
    - **Agent 编排是顶级技能**:能同时管理多个 Agent 的工程师属于顶尖 0.1%,但应从单个 Agent 开始逐步增加,避免盲目追求数量
    - **上下文切换是核心挑战**:管理多 Agent 需要频繁切换注意力并记住各任务进度,这与管理人类团队的能力高度相似
    - **Agent 友好代码库三要素**:充分的测试覆盖(作为显式合约)、README 与代码一致性、统一的设计模式,Agent 会在错误基础上快速复合错误
    - **品味决定软件质量**:功能性软件与卓越软件的分界在于"最后一公里"的打磨,顶尖工程师在发现可能性时加速而非完成任务即停止
    - **初级工程师的独特优势**:没有历史包袱,学习 AI 工具更快;"无知无畏"的特质使其敢于挑战行业难题,这是创业所需的完美品质
    - **避免过度工程化陷阱**:AI 让构建变得太容易,可能导致造出精美但无人需要的产品,需先验证需求再动手开发

    文章URL:https://baoyu.io/blog/2026-02-27/from-writing-code-to-managing-agents 从写代码到管 Agent:斯坦福首门 AI 软件开发课的讲师说,大多数工程师还没准备好