软件工程 | 锤子前端

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

Thu, 29 Oct 2026 01:22:56 GMT

《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

GitHub - unclebob/ub-mode

Contribute to unclebob/ub-mode development by creating an account on GitHub.

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

Fri, 23 Oct 2026 01:09:56 GMT

《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

X (formerly Twitter)

Thorsten Ball (@thorstenball) on X

Most predictions I see are still way too conservative.

Here's mine

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

Sat, 26 Sep 2026 23:54:52 GMT

《在 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/

The GitHub Blog

Rendering huge pull requests in the GitHub Copilot app

How we rebuilt the diff surface in the GitHub Copilot app to open a million-line pull request with hundreds of inline review comments.

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

Thu, 24 Sep 2026 12:29:24 GMT

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

标签：
#软件开发 #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/

seldo.com

We are all Product Engineers now

Just yesterday I published a very long post about the economics of open source. As part of that argument, I mentioned that the cost of writing software has collapsed, and that meant the variables in the equation had changed for the first time in thirty years.

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

Sun, 20 Sep 2026 07:02:41 GMT

《与 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/

Human Who Codes

Five software engineering roles for working with AI - Human Who Codes

Software engineers can work with AI in different ways, from observing every change to managing an entire software factory.

《框架还重要吗？》

Sun, 20 Sep 2026 02:45:28 GMT

《框架还重要吗？》

标签：
#编程 #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 自创轮子

《现代工程价值观：AI 时代的效率与品味》

Fri, 12 Jun 2026 01:47:25 GMT

《现代工程价值观：AI 时代的效率与品味》

标签：#软件工程 #AI编程 #代码审查 #团队管理 #技术栈 #开发者体验 #工程管理

总结：
作者 Christoph Nakazawa（cpojer）分享了他近半年完全依赖 AI 编码代理完成多个项目的实战经验，指出编程已从"手写代码"转向"指挥系统生成代码"。文章提炼了 AI 时代仍至关重要的五大工程价值观：强所有权、品味至上、严格约束与快速反馈、代码库即上下文、掌控技术栈，并强调管理需更技术化。作者用数据证明效率提升 3 倍，认为未来瓶颈不再是写代码，而是判断力与品味。

文章要点：
1. **AI 编码已成常态**：作者过去数月多个项目（Vite+、fate、Codiff、Athena Crisis 等）90%-100% 由 AI 编写，代码质量甚至超越手写，且能在几分钟内完成过去数周的工作
2. **Codex CLI 是最佳搭档**：使用 GPT 5.5 high 配合 Codex CLI，配合"先写失败测试再修复"的策略，能极大提高一次性正确率；多项目并行时建议每个项目独立窗口，利用空间记忆提升效率
3. **强所有权比代码更重要**：AI 放大了"懂行"与"不懂行"的差距，小团队（2-3 人）+ 清晰边界 + 独立仓库比大团队协作更高效，审查应聚焦对齐而非代码细节争论
4. **品味是防"垃圾"泛滥的护城河**：AI 能全天候生成大量平庸代码，工程师的核心价值转向判断"什么值得做"，团队应花更多时间思考方向而非盲目堆功能
5. **严格约束 = 速度**：把代码规范、自动化测试、快速验证等"护栏"做得越严，AI 迭代越快（1 分钟 vs 60 分钟的差距）；工具必须支持增量检查，避免随代码量增长而变慢
6. **代码库即唯一上下文**：将设计文档、产品行为、决策记录全部沉淀在仓库内，让 AI 和人类都能快速理解；代码越简洁、越易读，AI 修复和迭代越高效
7. **自研技术栈重新划算**：过去依赖第三方库是因为手写代码慢，现在 AI 降低了自研成本，掌控核心依赖能避免被外部框架绑架，获得完全的产品体验控制权
8. **保留选择权（Option Value）**：任何架构改动都应保留未来大幅调整的可能性，AI 虽让重构变快，但把自己逼进死胡同依然难以脱身
9. **管理必须更技术化**：执行成本降低后，管理者不能只做方向把控，必须保持领域 expertise，能亲自改代码、做技术决策，"技术型管理"（Tech Lead Management）将成为主流
10. **效率数据惊人**：近 30 天日均提交 770 次、修改 15k 行代码，是两年前的 3 倍；过去手写巅峰一天 1200 行，现在 AI 辅助可达 10 倍且质量更高

URL：
https://cpojer.net/posts/modern-engineering-values

cpojer.net

Modern Engineering Values

Modern engineering values.

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

Sat, 30 May 2026 00:35:22 GMT

《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/

mastrojs.github.io

Is AI causing a repeat of Frontend’s Lost Decade? | Mastro Blog

AI is doing to programming what framework-brain did to the frontend before. Deskilling, or just working at a higher level of abstraction?

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

Fri, 29 May 2026 08:29:31 GMT

《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

evilmartians.com

AI-assisted engineers are burning out, is this fine?—Martian Chronicles, Evil Martians’ team blog

AI-assisted code generation is not free. It comes with a hidden cost: burnout. Are we dangerously ignorant to this problem? And how can we cope with it? In this post, we discuss this question.

《垂直代码库：告别按类型分层，拥抱按业务域组织》

Sat, 18 Apr 2026 08:12:54 GMT

《垂直代码库：告别按类型分层，拥抱按业务域组织》

标签：#前端 #代码组织 #架构设计 #Monorepo #React #软件工程

总结：

本文主张前端代码库应从"水平分层"（按 components/hooks/utils 技术类型划分）转向"垂直切片"（按业务域/功能域组织）。作者以 Sentry 代码库十年演进为例，指出水平分层会导致代码分散、认知负荷高、耦合混乱；而垂直组织将同一业务域的组件、工具、类型内聚到一起，配合 Monorepo 的显式边界（exports/eslint-plugin-boundaries），能显著提升可维护性。虽然确定正确的垂直划分需要更多团队沟通，但这是支撑代码库长期演进的必要投资。

文章要点：

- 水平分层的隐患：把代码按 components / hooks / utils / types 分类虽然上手简单，但随着项目膨胀，同一业务逻辑会被拆得七零八落——比如 PageFilters 的组件、类型、工具函数散落在三个目录，改一个小需求要跳来跳去， cognitive load 直接拉满
- 垂直切片的核心思想：不按"技术类型"而按"业务域"分组，把同一个功能域（如 dashboard、profiling、billing）相关的组件、Hook、工具、类型全部收进一个目录；就像当年我们把 HTML/CSS/JS 从三层文件合并成组件一样，这次是更高维度的"关注点内聚"
- 与团队结构天然对齐：现代产品团队通常是端到端的功能团队（dashboard 团队、replay 团队），垂直代码结构让 CODEOWNERS 和包边界直接对应团队职责，谁负责什么一目了然
- 解决跨域复用焦虑：不是所有代码都严格属于某个页面，像 PageFilters 这种被多页面使用的通用能力，完全可以作为独立垂直域存在；关键是按"逻辑关联"而非"物理位置"来划分
- 用边界守护架构：垂直化后还需降低耦合，推荐通过 Monorepo + package.json#exports 显式暴露公共 API，或借助 eslint-plugin-boundaries 禁止深路径导入，把"私有实现"真正保护起来
- 没有银弹，但值得投入：确定合理的垂直域确实比"丢进 utils"更难，也可能出现不同团队重复造轮子；但作者认为这恰恰促进了团队沟通，而沟通本就是软件工程最难也最重要的部分

文章URL：

https://tkdodo.eu/blog/the-vertical-codebase

tkdodo.eu

The Vertical Codebase

Let's take a look at why the common, horizontal code structure is not ideal, where it breaks down, and what we can do about it.

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

Mon, 30 Mar 2026 07:00:31 GMT

《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/

Buttondown

Vibe coding is dead. Here's what replaced it

What I actually do now instead of writing code.

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

Wed, 18 Mar 2026 11:23:17 GMT

《编程 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

baoyu.io

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

编程 Agent 让写代码变得异常简单，EPD 的角色定位会怎么变？PRD 已死、瓶颈从实现转向评审、通才比以往更有价值。

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

Mon, 02 Mar 2026 08:48:45 GMT

《从写代码到管 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

baoyu.io

从写代码到管 Agent：斯坦福首门 AI 软件开发课的讲师说，大多数工程师还没准备好

斯坦福首门 AI 软件开发课讲师 Mihail Eric 谈初级开发者的三重困境、多 Agent 编排的真正难点、Agent 友好代码库的标准，以及为什么初级工程师的'无知无畏'在 AI 时代反而是超能力。