随便取下来随便换个地方吸（🤣

#优质博文 #DevOps #GitLab #AI
Automating Code Quality and Security Fixes with Codex CLI on GitLab | OpenAI Cookbook

AI 摘要：文章演示如何在 GitLab CI/CD 中集成 OpenAI 的 Codex CLI，为代码合并请求自动生成 CodeClimate JSON 的代码质量报告，并对现有 SAST 结果进行去重、优先级排序与给出可操作的修复建议，进一步自动产出可验证的 git 补丁；通过严格的提示词、JSON 标记、模式校验与 diff 校验等守护栏，使 LLM 推理成为可落地的 DevSecOps 流水线能力，补强而非替代传统规则引擎。

author OpenAI Cookbook

#优质博文 #前端 #CSS #动画 #course
这篇写得真好，offeset-path 讲明白了。
The -path of Least Resistance (Part 2)

AI 摘要：本文从静态形状的剪切路径 (clip-path) 转向运动路径 (offset-path)，系统讲解如何用 offset-distance、offset-anchor、offset-position、offset-rotate 等控制元素沿自定义路径自然运动；阐明 offset transform 在 transform 栈的执行顺序及其对视觉结果与性能的影响；区分闭合与开放路径、负值与溢出距离的行为；展示用 shape() 切分路径与 ray() 创建无限射线；并给出交互触发与可访问性 (prefers-reduced-motion) 的实践建议与性能优化策略。

1. 概念与对比
• 从剪切路径 (clip-path) 的“控形”转向偏移路径 (offset-path) 的“控动”
• 参照系差异：clip-path 相对元素 border-box，而 offset-path 相对包含块 (containing block)
• shape() 浏览器支持度低于 offset-path 与 clip-path

2. 值与坐标
• 支持绝对单位与百分比，适配响应式
• 大量使用 CSS 变量，使路径定义、函数参数、单点坐标可参数化
• 路径静态由 offset-path 定义，位置动态由 offset-distance 驱动

3. 距离与动画
• 核心动画仅需 offset-distance: 0% → 100%
• 非线性运动：通过多关键帧实现往返与停顿
• 可用 transition 在 hover、focus、click 等交互中平滑过渡 offset-distance

4. 锚点与起点
• offset-anchor 决定元素哪个点贴合路径（类似 transform-origin）
• offset-position 决定路径在包含块中的起始位置：normal(居中)、auto(元素自身位置)、或显式坐标

5. 旋转与方向
• offset-rotate 控制沿路径方向的旋转：auto、固定角度、auto 叠加角度、reverse
• 通过 auto 使元素切线对齐，实现自然转向

6. 变换栈与相互关系
• 变换顺序：单独 transform 属性 (translate/rotate/scale) → offset transform → transform
• 相同路径在不同层次的变换组合会产生不同视觉结果

7. 性能考虑
• offset-path 属于 transform 栈，享受硬件加速，避免重排重绘
• 动画中避免改动 offset-path，本应动画 offset-distance；用变量或类切换路径
• 简化路径：简单直线不必用 shape()，circle() 性能优于大量曲段的 path()

8. 闭合与开放路径
• circle()、inset()、polygon() 天生闭合，0% 与 100% 连续循环
• path()、shape() 可开可闭；开放路径 100% 回到 0% 会“跳跃”
• 负值与溢出：闭合路径可环绕归一化，开放路径则钳制在 0%–100%

9. 分段路径与“切割”
• 使用 shape() 的 move 指令在中途打断并重启路径
• 适合制作从一点“传送”到另一点的分段运动效果

10. 无限射线 ray()
• ray(angle) 生成无穷直线；100% 通过关键字定义参照距离：closest-side、closest-corner、farthest-side、farthest-corner、sides
• 始终为开放路径，超过 100% 将无限延伸，适用于飞出屏幕、激光、方向性动画

11. 可访问性与交互
• 尊重用户减少动画偏好：@media (prefers-reduced-motion: no-preference) 有条件启用
• 交互驱动：用状态切换与 transition 提供可控运动反馈

12. 总结与实践要点
• clip-path 控形，offset-path 控动，二者组合形成 CSS 空间表达的完整语汇
• 选对参照系与锚点，明确起点与旋转策略
• 动画以 offset-distance 为主，路径参数化，注意性能与可访问性

author Amit Sheen

#前端 #新动态 #react
重塑 Remix：V3 将放弃 React，转而使用 Preact 的分叉：Remix v3 将弃用 React、改用 Preact 分叉以“自有”更多栈并最小化依赖，强调 Web API、运行时优先与可组合性并优化 LLM，社区反应不一且预览版尚未发布。

author Bruno Couriol

#优质博文 #新动态 #后端 #数据库 #ORM #Prisma #AI
Vibe Coding 给 Prisma 都整的加了个安全护栏了（草
太体贴了哥（
Release 6.15.0 · prisma/prisma

AI 摘要：本次版本聚焦稳定性与平台适配：为可能由 AI 代理触发的破坏性命令加入安全确认护栏；统一 prisma-client 运行时选项并允许无模型 schema 生成客户端；提供与 Vercel Fluid 的连接池托管方案；宣布 Prisma Postgres Management API 达到 GA 并接入 Pipedream；为 npx create-db 新增 --json 输出；强化 Prisma Postgres 直连能力，接近 GA，同时继续提供企业级支持服务。

1. 亮点
• AI 安全护栏：CLI 识别常见 AI 代理（如 Claude Code、Gemini CLI、Qwen Code、Cursor、Aider、Replit），对 prisma migrate reset --force 等破坏性操作要求显式确认，避免 AI 自动执行不可逆数据库重建。文档
• prisma-client 运行时与 schema 灵活性：
• 运行时输入统一：node 移除改用 runtime = "nodejs"；deno-deploy 移除改用 runtime = "deno"；vercel 替换为 runtime = "vercel-edge"；edge-light 作为 vercel-edge 的别名。
• nodejs、deno、bun 共用内部代码路径但保留独立输入值；VS Code 扩展已同步更新。
• 支持的运行时为：nodejs、deno、bun、workerd（alias cloudflare）、vercel-edge（alias edge-light）、react-native。
• 生成阶段改进：即使 schema 无模型也可用新生成器 prisma-client 成功生成客户端（与旧 prisma-client-js 一致）。文档
• 与 Vercel Fluid 协作：为解决无服务器挂起导致的连接泄漏，结合 Vercel attachDatabasePool 与 Prisma driver adapters，挂起前释放空闲连接，防止耗尽连接池；提供 pg + PrismaPg 的示例用法。Vercel 介绍 · 部署文档

#Newsletter #前端 #新动态 #周刊更新
周刊第 5 期～
FE Bits Vol.5｜Nx 包被投毒、ESLint 多线程 Linting 和 Firefox 实验性 PWA

#碎碎念 #杂谈 #前端
https://fixupx.com/himself_65/status/1962067299781013795

面包🍞 (@himself_65): 前一段时间有人问我怎么系统的学习前端。

我最近感触很深的是，很多东西过了多少年依旧没有变，比如我面过人类学的前端架构，里面问到的问题依然是2020年Slack的架构设计的博客内容。

即使是在AI时代，nothing is new：SSE、websocket……甚至正因为有了AI，很多设计模式来控制复杂度变得尤为重要。所以我觉得当今人应该更多放在整体的架构设计和代码复杂度控制。

所以我觉得付费给一些很无聊的人讲怎么vibe coding是很囫囵吞枣的事情，我觉得有很多人靠着贩卖焦虑来获得流量和收入，但我觉得有些事情是必须“纸上得来终觉浅，绝知此事要躬行”

很赞同，然后想补充几点：

前端其实也分很多类别，toC 前端、toB 前端，基建前端，WebGL 前端，所以要系统性的学习前端，首先得先找好方向，专注用户体验还是专注写业务还是搞工具链，以 toC 前端视角给建议的话，前端动画、CSS、Three、交互表现、性能优化、SEO 有太多太多要学的了，使用的生态是随着业务去选的。

比如 CSS 其实一直在努力变得更好用，内置嵌套、if 函数、新的锚点定位、各种新特性，浏览器也一直在加强各种兼容性，WebGPU 在 iOS26 也支持了（虽然我天天骂 Safari，但是支持那么多的新特性和渐进式增强确实是很不容易的事儿），前端现在有各种遗留问题都很糟糕，但我感觉不能完全忽视这些进步。

以及，推荐一篇之前看到的文章 HTML is Dead, Long Live HTML Rethinking DOM from first principles

前端并不是一成不变的，有些看不太到的地方其实一直在变，用户也不是只有企业系统的用户，也有专注网页展示形式，专门制作创意展示网站的用户～～我觉的这些都是前端，游戏前端也是前端，未来可能的 VR/XR 页面也是前端，浏览器插件是前端，小程序开发也是前端。再泛化一些的话，其实我觉得跨端也都能算前端（好像有点偏离主题了hhh）

#优质博文 #前端 #JavaScript #WebAPI #浏览器 #性能
Say bye with JavaScript Beacon

AI 摘要：作者指出在 beforeunload/unload 里用 XMLHttpRequest 或 fetch 上报并不可靠，因为浏览器不会为脚本阻塞卸载流程，网络请求易被取消；推荐使用信标接口 (Beacon API) 的 navigator.sendBeacon 进行 fire-and-forget 异步上报：无需回调或 Promise，JS 立即结束，由浏览器后台传输；虽仅支持 POST 且负载很小，但非常适合离开页面、实时埋点与轻量级前后端同步等无需等待响应的场景，文末附 MDN 文档。

1. 问题背景与常见误区
• 用户离开网站不只关闭标签页，也可能修改地址栏或点书签，难以精准用单一事件捕获。
• 常见做法是在 beforeunload/unload 里用 XMLHttpRequest/fetch 上报，但实践中经常不稳定。

2. 为什么 beforeunload 不可靠
• 浏览器不会为执行 JavaScript 而阻塞卸载流程，以免影响用户体验。
• 页面卸载时网络请求可能未发出或被浏览器取消，导致上报丢失。

3. Beacon API 介绍与用法
• 核心调用：navigator.sendBeacon(url, data)；发送后立即返回，无回调或 Promise。
• 特性：fire-and-forget，浏览器接管传输，JS 执行立即结束，内存不被占用。
• 设计目标：在卸载等敏感时机可靠传递小数据。

4. 适用场景
• 页面关闭/跳转时的 analytics 上报、自动登出提示或状态同步。
• 任意时刻的轻量数据同步（如输入草稿、埋点）——无需等待响应即可继续交互。

5. 限制与注意事项
• 仅支持 POST，负载较小，适合“微消息”而非大体量数据。
• 不适用于需要确认响应、复杂重试或事务保证的场景；这类应选用 fetch/XHR 并在交互上做等待或队列重试。

6. 参考链接
• Beacon API - MDN

author Hemath

#优质博文 #前端 #CSS #响应式设计 #可访问性 #视口单位 #排版 #打印
很棒的关于 CSS 长度单位的大合集介绍。
Making Sense of CSS Length Units

AI 摘要：文章以开发者视角概览 CSS 长度单位，强调 px 在高密度屏幕上已是“虚拟像素”并非绝对单位；屏幕端应优先 rem 以尊重用户字号设置提升可访问性，应用端用视口单位（viewport）适配全屏，打印场景用物理单位；并细分 vh/vw/vi/vb 及 sv*/lv*/dv* 的差别与适用时机，同时给出 em、% 的陷阱与 ch/ex/cap 等小众单位的用途。

1. 基础与绝对单位
• px 已虚拟化：在高像素密度（retina）设备上代表逻辑像素而非物理像素，因此不再“绝对”。
• 打印用物理单位：cm/mm/q/in/pc/pt 设计为打印介质；不同打印机 DPI 差异巨大，屏幕端不宜使用。
• 打印建议：为确保一致输出，优先使用打印友好单位或相对单位以适配不同分辨率。

2. 相对单位
• %（百分比）：相对包含块（containing block）；当元素 absolute 定位时，包含块判定更复杂，易出错。
• em：相对父元素 font-size，组件嵌套会累积放大/缩小，需谨慎。
• rem：相对根元素 html 的 font-size，组件在不同容器中保持一致尺寸；浏览器默认 16px，可用 html{font-size:62.5%} 将 1rem ≈ 10px（便于心算，非必须）。
• 可访问性（accessibility）：以 rem 构建能尊重用户自定义字号；纯 px 布局可能忽略用户设置并导致可读性问题。

3. 视口单位（viewport）
• 基本单位：vh/vw（视口高/宽）、vmin/vmax（较小/较大维度），vi/vb 随书写方向（writing-mode）切换，横排时 vi≈vw、vb≈vh，竖排语言会反转。
• 尺寸变体：sv*（浏览器控件可见时的“小”视口）、lv*（控件隐藏时的“大”视口）、dv*（当前动态视口，随控件显隐变化）。未指明前缀的 v* 等同于 lv*。
• 实战提示：全屏布局用 dvh 更贴合当前高度；为避免移动端地址栏显隐导致跳动，可按需组合 svh/lvh/dvh。

4. “奇特”单位与适用场景
• ch（“0”的宽度）、ex（“x”的高度）、cap（大写字母高度，适合图标对齐文本）、ic（CJK“水”字宽度）、lh（父元素行高）、rlh（根元素行高）。
• 适配文字排版和细粒度对齐；因支持度差异，需评估兼容与降级策略。

5. 实践要点与推荐方案
• 打印：使用 mm 等物理单位获得精确尺寸，或配合相对单位确保跨设备一致性。
• 网页：以 rem 为主，选用 1rem=10px 的设定仅为心算便利；避免全用 px 影响可访问性。
• Web 应用：用 dvh/dvw 填充视口，结合 vi/vb 适配不同 writing-mode。
• 选型原则：优先考虑用户设置与设备独立性、布局稳定性与可维护性，再选最贴合场景的单位。

6. 常见陷阱
• 绝对定位元素用百分比时误判包含块，导致尺寸/位置异常。
• 盲目使用 px 使布局对用户字号调整不敏感，影响可读性与无障碍。
• 移动端 100vh 在地址栏显隐时引发布局跳动，应改用 dvh 或配合 svh/lvh。

author Oded Sharon

#优质博文 #前端 #CSS #HTML #course
You no longer need JavaScript

AI 摘要：作者以“很多站点并不需要 JavaScript”为引子，系统展示现代 CSS 的强大与可用性：从 Nesting、相对颜色、:has、@starting-style、color-scheme/light-dark，到输入校验与 details 组件、Web 动画与视口单位 dvh/lvh/svh，以及 Baseline 兼容性保证；论证在性能（合成器线程 compositor thread）、可访问性与隐私友好方面 CSS 具备天然优势，主张用 CSS 做到能做的事，把 JS 作为渐进增强，并提出若干 CSS 心愿单与个人的创作观。

1. 观点与动机
• 批评“臃肿 JS + 追踪脚本”导致的糟糕体验，但承认框架在合适场景的价值。
• 核心主张：并非所有站点都需要 JavaScript；HTML/CSS 已能覆盖大量交互与视觉需求。
• 目标：科普现代 CSS 能力，帮助开发者减少不必要的 JS。

2. 现代 CSS 能力与可用性
• 语法与可读性：原生 Nesting 显著改善层级样式组织；短类名也更可控。
• 相对颜色与 color-mix：可在多色彩空间就地变换/混合，轻松生成主题、悬停态等。
• 新语法与单位：媒体查询支持范围表达式 (width <= 768px)、lh 单位、scrollbar-gutter 等。
• Baseline 计划：用“新近可用/广泛可用”标识保障跨浏览器一致性与上线时机判断。

3. 性能、可访问性与渐进增强
• 性能：CSS 动画运行在合成器线程 (compositor thread)，避免事件循环抖动，低端设备也更顺滑；如需 JS 触发，优先用 Web Animations API。
• 可访问性与隐私：无脚本也可完整浏览；对安全研究者/隐私用户更友好。
• 渐进增强 (progressive enhancement)：交互与主题切换用 CSS 实现，偏好持久化可由 JS 或服务端补充。

4. 实战示例与模式库
• 过渡与入场：@starting-style 简化“初始态 + transition”实现，无需 keyframes/JS 强制触发。
• 主题与暗色模式：color-scheme: light dark + light-dark() 一键适配系统主题；用 radio + :has 覆写用户选择。
• 表单与交互：
• 自定义单选/标签：:has(input:checked)、:has(input:focus-visible) 驱动样式与无障碍焦点。
• 选项卡：在父级用 :has(#id:checked) 切换内容显示。
• 折叠面板：details/summary 原生手风琴，支持 [open] 状态与可搜索。
• 校验：pattern、:valid/:invalid 与 :user-valid/:user-invalid 组合，既即时反馈又避免“未输入即报错”；可配合 :has 进行联动样式。
• 其他经验：使用自定义元素名（带连字符）组织结构；在 body 内邻近放置 style 以优化首屏可读性（实践有效但规范上未正式推荐）。

5. 视口与虚拟键盘适配
• 移动端视口单位陷阱：vw/vh 在地址栏显隐时不稳定，易致元素被截断或背景不满屏。
• 解决方案：使用响应式单位 lvh/svh/dvh（背景用 lvh，必须始终可见的按钮用 svh，dvh 动态变化慎用以免抖动）。
• 键盘覆盖处理：
• meta viewport 的 interactive-widget=resizes-content（跨浏览器、无 JS）。
• VirtualKeyboard API（Chromium 专属）：navigator.virtualKeyboard.overlaysContent 与 env(keyboard-inset-height) 获取键盘尺寸；跨端性不足，谨慎采用。

6. CSS 心愿单（提案/期望）
• 可复用块：在原生 CSS 内支持类似 @apply 的类复用。
• 组合 @media 选择器：在同一规则中合并媒体条件与选择器列表，减少重复。
• nth-child 变量：将子序号暴露为变量，便于位置/颜色等按序计算。
• nth-letter 选择：扩展 ::first-letter 为 ::nth-letter(n) 做文本特效。
• 单位移除：更直观地得到无单位数值（当前需 tan/atan2 等技巧与 @property，期望直接除法）。
• 更好的 image()：实现带回退色与图像片段裁剪的函数，优于 url() 场景。
• 允许 body 内 style 合规：实务上有利于感知性能

author lyra

#优质博文 #前端 #CSS #性能优化 #font
这篇讲字体的文章写的超级棒。
You’re loading fonts wrong (and it’s crippling your performance)

AI 摘要：作者指出大多数站点把字体当装饰而非基础设施，导致体积臃肿、加载策略失当、CLS 爆炸与隐私合规风险；文章从历史与神话、浏览器渲染管线、现代 CSS 描述符、子集化与可变字体、系统栈与自托管、预加载与 Early Hints、文件格式与图标字体替代、非拉丁脚本与 Emoji、到工具审计与行动清单，给出“系统优先、仅用 WOFF2、内联 + 预加载、智能子集、设计回退、变量字体有的放矢、尊重全球脚本、持续测试”的全套可落地策略。

author Jono Alderson

#优质博文 #前端 #CSS #动画 #渐进增强 #浏览器兼容 #HTML
The interpolate-size property is a great example of progressive enhancement

AI 摘要：文章以 details 元素的展开动画为例，展示如何在 :root 启用 CSS 属性 (interpolate-size) 以允许对 auto 等关键字尺寸做插值过渡，利用 lh 单位与自定义属性计算闭合态高度，开启态使用 height: auto 与 overflow: clip；无需 @supports 包裹，因为未知属性会被忽略，从而在 Chromium 获得平滑动画，在 Firefox/Safari 等未支持浏览器优雅降级为无动画但不破坏布局的最小可用体验，体现了渐进增强的最佳实践。

1. 背景与定义
• 需求来源：长期呼声是能将高度或宽度过渡到 auto 及 min-content、max-content、fit-content 等关键字尺寸。
• 能力说明：CSS 属性 (interpolate-size) 允许对关键字尺寸进行插值，使 height/width 过渡到 auto 成为可能。
• 支持现状：当前主要在 Chromium 系列可见效果，其他浏览器尚未跟进，属于渐进增强的理想目标场景。
• 参考阅读：Animate to height: auto、MDN 兼容性表、Shoptalk Show #679

2. 实践方案与代码思路
• 全局启用：在 :root 设置 interpolate-size: allow-keywords；无需 @supports 包裹，未识别属性会被忽略。
• 闭合态高度计算：采用 lh 单位 (lh) 获取文本行高，结合自定义属性计算 padding，使用 calc 组合出闭合态 height。
• 动画设置：对 height 做 transition，选择线性 (linear) 且时长短促，保证“迅捷而不拖沓”的交互手感。
• 展开态处理：使用 height: auto 配合 overflow: clip，避免滚动条并实现干净的内容裁切。
• 延伸阅读：lh 单位介绍、overflow: clip 详解

3. 渐进增强与兼容策略
• 无需防守式 @supports：未知属性在旧浏览器被忽略，不会破坏布局与交互。
• 分层体验：Chromium 获得平滑动画；Firefox/Safari 获得“无动画但可用”的最小可用体验 (MVE)。
• 零 polyfill 负担：不引入沉重的脚本或补丁，等待兼容性完善后即刻“自动生效”。
• 方法论回顾：什么是渐进增强

4. 适用场景与实用建议
• 手风琴/折叠面板：在多组 details 组成的手风琴中，可用相同 name 属性实现互斥展开。
• 动效节奏：尺寸动画更适合线性插值与短时长，避免拖沓的缓动曲线影响可用性。
• 可配置性：通过自定义属性调整 padding 与动画时长，便于在不同组件语境重用。

5. 关键要点速览
• interpolate-size 让“过渡到 auto”成为可能，但目前只在部分浏览器体现动画。
• 利用“未知即忽略”的 CSS 特性，直接书写未来语法，旧浏览器自然降级。
• 以 lh 为基础计算闭合态高度，展开态使用 auto + clip，代码简洁且语义清晰。

author Andy Bell

#碎碎念
看多了这种网页，有点羡慕海外什么都能出个小网站展示～
专辑、画师、公益、酒店、食品、企业宣传……都有做创意小网站，这太有趣了

#优质博文 #AI #上下文工程 #LLM
几天前就想发了，忙忘了，很棒的一篇文章。

谈谈 AI 编程工具的进化与 Vibe Coding：区分 Vibe Coding 与 Context Coding，系统梳理 Copilot、Cursor、Claude Code 的上下文工程（Context Engineering）路径与实践取舍，并给出可操作的方法论与职业思考

AI 摘要：指出 Vibe Coding 短期易致缺陷与安全问题、长期堆积技术债；职业上，中位“翻译者”型编程会被挤压，具抽象能力或商业与独立开发能力者将受益，持续学习与上下文工程将决定竞争力。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 术语澄清与立场：Vibe Coding vs Context Coding
• Vibe Coding 的原始内涵：忘记代码存在、全对话驱动、不看 diff、一次性项目可用但有趣而不严肃。
• 混用导致争论，应区分：Vibe Coding（对话式全托管）与 Context Coding（上下文驱动的 AI 辅助编程）。

2. Context Coding 的核心：上下文工程（Context Engineering）
• 除大语言模型（LLM）能力外，关键在于“如何给到合适的上下文”。
• Chat、RAG、Rules、MCP、文档接入等，实质都是提升上下文质量与可控性。

3. GitHub Copilot：从窗口上下文到补全范式
• 优点：将当前文件上下文提供给 LLM；基于注释的补全提升效率。
• 局限：模型能力与上下文长度受限、跨文件理解弱、早期无法直接编辑代码、需人工复制粘贴。

4. Cursor：从补全到“编程智能体”
• 能力叠加：专用 Tab 模型 + Claude 3.5 Sonnet，速度与质量同步提升，支持直接编辑。
• 上下文工程：对 codebase 做 RAG 索引，语义检索多文件上下文；@ 文件/目录、Git 历史、文档索引、Rules 保持风格一致性。
• 场景覆盖：跨文件调用、多文件修复、模块重构、功能新增。
• 商业取舍：次数/速率/模型自动降级等策略影响体验，存在波动。

5. Claude Code：命令行范式与“量大管饱”的上下文
• 全局分析：开场即扫描项目结构与技术栈，耗费 tokens 换来更贴合原项目规范的输出。
• 检索策略：采用 grep/find/git/cat 等 Unix 工具代替 RAG，更符合工程师的搜索路径。
• 争议对比：RAG 注重召回广覆盖但精度与时效可能不稳；grep 精度高匹配业务上下文但对话轮次与 tokens 消耗更多。
• 适配生态：天然契合 bash、MCP、CI/CD 与 DevOps 自动化的脚本化工作流。

6. 如何更好地进行 Context Coding（实践清单）
• 规则文件：提供技术栈、目录结构、命名约定与用途（.github/copilot-instructions.md、.rulers、CLAUDE.md；可用 Ruler 统一管理）。
• 上下文建模：常用脚本（install/lint/test/build）、工具类、核心模块/方法的清单与定位。
• 开发流程：需求拆分为子任务、记录进度、渐进式修改与小步提交、优先可读性与一致性、函数聚焦单一职责。
• 调试与知识更新：以日志替代 IDE 调试；用 MCP/context7 接入最新文档与浏览器/网络日志，降低训练数据过时风险。
• 风险提示：上下文不是越多越好；易变信息需及时维护，否则误导大于帮助。

7. 个人实践与取舍
• 严肃工程偏好 Tab 补全，由人控抽象与分层，效率更稳定。
• Claude Code 适合陌生代码库的全局理解与不熟技术栈任务。
• 工具中立：择善而用，不做工具信徒；LLM 正改变调试与一次性代码的工作习惯。

8. Vibe Coding 的风险与案例
• 风险画像：短期带来缺陷与安全漏洞，长期堆积技术债、可理解性与稳定性下降。
• 反面案例：Leo 使用 Cursor 全程 Vibe Coding，上线后遭攻击与越权，最终关停并复盘“生产环境不应部署不安全代码”。
• 正面机会：levelsio 以 100% AI + Cursor + Grok 3 做 MMO，17 天达 100 万美元 ARR；但其自身具接管能力与经验。
• 职业演进：LLM 蚕食“翻译者”型编程，中位岗位被压缩；顶尖工程师与具商业/营销能力的开发者将受益；独立与小团队更主流。

9. 结语与方法论走向
• LLM 能力与上下文工程相辅相成；上下文管理与可视化（如 /context）是关键产品力。
• 谁能提供“更好上下文 + 更好控制”，谁就更可能在 AI 编程时代胜出。

author Guangzheng Li