Now vibe coding, so learning hammer FE ?
《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
标签：
#软件工程 #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
Here's mine
《在 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/
标签：
#软件工程 #前端性能优化 #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.
《我们现在都是产品工程师了》
标签：
#软件开发 #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/
标签：
#软件开发 #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/
《框架还重要吗？》
标签：
#编程 #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 和
5. **框架战争的终结与新机遇**：作者认为 2013-2024 年的"框架战争"已经结束，人们不再渴望为框架争论，但这不意味着框架不再重要。他指出当前框架领域仍存在明显不足，特别是缺乏真正全栈、基于 Web 标准、易于 AI 协作且代码可理解的 JavaScript 框架。
6. **对未来的呼吁**：尽管承认 AI 正在重塑软件开发，且没人知道其长期影响，作者仍坚持认为认为"所有问题都已解决"是一种颓废的态度。他呼吁继续构建新框架，探索更好的抽象和模式，而不是停留在"现有框架足够好"的舒适区。
URL：
https://brookslybrand.com/posts/do-frameworks-matter-anymore/
> 个人觉得有点片面化，remix 脱离 react 转而用 preact 自创轮子
标签：
#编程 #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 自创轮子
Brookslybrand
Do Frameworks Matter Anymore?
《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
标签：#科技趋势 #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
Terezatizkova
Software is becoming marketing
Four ways software products and jobs change in the age of abundance
《编程 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
标签：#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 已死、瓶颈从实现转向评审、通才比以往更有价值。
