一边做业务一边做重构：将真实债务项目重构成 AI 可维护项目
被河/godbasin 分享边做业务边重构：关键转折是搭建 AI 上下文工程，让重债务项目从「AI 胡言」变为可定位可落地；强调提效常卡在业务上下文而非模型本身。
godbasin
站点来源 · 不代表单一作者
当前已导入的历史，每页 50 篇；不代表网站完整历史。筛选作用于当前页，更多内容可由 Grok 后续补齐。
访问原站 ↗前端这几年--16. AI 时代的开发
被河谈 AI 时代开发：经验者提效、新人被抬高预期却少试错空间；合作或更多经 AI 中转，系列文近终章思考成长路径。
2026 程序员指南
更新日期: 2025 年大概是 AI 在各个场景的应用很让人吃惊的一年了。 2025 年，程序员的技术壁垒在被打破 2025 年初，复杂类应用、垂直类应用的程序员，技术壁垒依然很高。一个工作经验不足的新人，对比一个在某个领域深耕多年的开发，缺失的经验积累可能无法在短时间内能替代其工作内容。 但这种技术壁垒，随着 AI 模型能力越来越强，正逐渐被打破。 大多数的程序员的日常开发工作，已经无法离开 AI 了。亲自写的代码比重，已经大幅度地降低。 2025 年底的今天，大多数的业务，只用给一个新人能力足够强的 AI，便能迅速胜任开发工作。 目前或许还有跨环境、跨链路、人工调试和验收的工作无法完全用 AI 闭环，但这些依赖“工作经验”的事情，可预见会被逐渐替代。 2026 年，程序员的工作方式也将转变 从前通过堆屎山建立技术壁垒、依赖屎山堆工作经验来让自身不可替代的野路子，已经被打破。 从代码层面。
如何提升项目管理能力
更新日期: 前面在《如何设计与管理一个前端项目》一文中，提到过需要做风险把控、事后复盘、数据量化，但具体怎么执行呢？本文主要结合以前的实战经验进行说明。 前面提到，我们需要主动把控各个环节的情况，及时推动和解决出现的一些多方协作的问题，先从风险控制说起。 1. 风险控制 举个例子，之前我接过一个需要带外包同学进行小程序开发的项目。在项目启动之前，我找到另外一个有过相同经验的开发咨询他们项目的一些情况，得到的反馈包括以下问题： (1) 交付物质量问题： - 主流程无法正常体验 - 代码中充斥着调试代码，交付时接口还连着测试环境 (2) 代码规范问题： - 格式缩进混乱 (3) 性能问题： - 只是用一个方法，随意引入第三方开源库 (4) 可维护性问题： - 多页面重复逻辑 - 多页面写死appid等应该配置的数据 - 接口调用及处理放在多个页面逻辑代码内 (5) 代码健壮性问题： - 需求逻。
前端性能优化--网页复杂度设计
更新日期: 关于复杂度，相信所有开发都了解这个词。毕竟准备面试过程中，多少都会刷刷题，了解过算法复杂度这个词。 今天想聊的，是关于网页复杂度的一些想法。 怎样算复杂？ 相信经常看我写的性能相关文章的小伙伴都知道，复杂的前端应用、大型前端应用这个词经常会出现在我的文章里。 是的，我经常说像在线文档、在线表格这样的应用是很复杂的大型应用，但是具体是复杂在哪呢？代码量大算复杂吗？模块很多算复杂吗？功能繁杂又该怎么定义呢？ 在我们的工作里，也经常会提到一些网页之所以卡顿、加载慢，是因为它很复杂。但是，我们只能用“复杂”二字来概括所有的无法精细描述和量化的场景吗？ 关于网页复杂度的畅想 关于复杂度，相信所有开发都了解这个词。在计算机领域，复杂度常常出现在程序算法中，主要包括：时间复杂度、空间复杂度。 我们衡量不同算法之间的优劣主要是通过时间和空间两个维度去考量： - 时间维度：是指执行当前算法所消耗。
第 1 页