文章

技术思考、项目复盘与 AI 实践

文章系列

全部文章

技术实践

前端工程化(十):从联系表单理解运行时稳定性

运行时稳定性需要同时回答三个问题:用户看到什么,服务端操作是否已发生,开发者怎样定位故障。结束 loading 只是其中一步,超时也不能直接当作业务失败。

技术实践

前端工程化(九):React 与 Next.js 的渲染边界

SSR、SSG、ISR、CSR 描述页面内容的生成时机与方式;Server Component 和 Client Component 描述组件的运行边界。判断一个 Next.js 页面需要同时检查源码、数据获取、构建结果和实际响应,不能只看有没有 `use client`

AI 实践

从候选检索到带引用回答:我在个人网站里补上的 RAG 问答边界

RAG 的关键变化,是让模型回答受到检索证据约束,并让用户看到可追溯的公开来源。 no_evidence 不是普通回答,也不是系统故障;它表示当前索引、过滤条件和阈值下没有足够证据。 相似度分数只能表示语义相关性,不能直接当成事实置信度。 来源展示应与答案引用分开设计,并且只投影公开字段。 专项协议测试和类型检查通过,不等于真实 Provider、数据库和浏览器端到端已经完成。

技术实践

前端工程化(八):性能指标与加载优化

性能优化应该从测量开始,而不是看到某个大文件就直接压缩、拆包或懒加载。先记录 LCP、INP、CLS、TTFB、请求瀑布、资源体积和主线程任务,再根据证据选择优化手段。当前页面指标良好时,最有价值的动作往往是保留可复现基线,防止后续功能增长造成回归。

技术实践

前端工程化(七):测试体系怎么分层与取舍

测试体系不是把所有场景都写成 E2E,也不是追求测试数量越多越好。应让确定性强、反馈快的测试覆盖底层逻辑,让组件、契约和集成测试覆盖协作边界,再用少量 E2E 验证关键用户路径。测试结果还要区分通过、断言失败和环境阻断,避免把环境问题误判成业务结论。

AI 实践

Embedding 与向量检索不是 RAG:从公开内容到可验证候选

Embedding 与向量检索是 RAG 的检索前置层:它负责在可信范围内找候选证据,但不负责生成答案,也不自动证明内容正确。

技术实践

前端工程化(六):代码规范与提交门禁

ESLint、Prettier、TypeScript 和测试解决的是不同风险:Prettier 统一格式,ESLint 检查代码质量,TypeScript 检查静态类型关系,测试验证运行时行为。它们应该组成一条从本地到 CI 的质量门禁,而不是互相替代。

技术实践

前端工程化(五):依赖版本与可复现安装

package.json 表达项目想要什么,lockfile 记录本次实际解析出了什么;semver 决定允许更新的范围,packageManager 固定安装工具版本,缓存负责加速下载,npm ci 负责在 CI 中按 lockfile 做干净、可复现的安装。它们解决的是不同层次的问题,不能互相替代。

技术实践

前端工程化(四):TypeScript、Babel 与浏览器兼容

TypeScript 主要负责开发和编译阶段的类型检查,Babel 或框架编译链负责语法转换,`target` 决定输出语法方向,Polyfill 补足浏览器缺失的运行时 API,Browserslist 声明需要覆盖的浏览器范围。它们共同参与兼容性建设,但不能互相替代。

技术实践

前端工程化(三):打包器如何从入口生成构建产物

打包器不是简单地把多个文件拼接起来。它从入口开始解析模块,递归建立依赖图,通过 loader 或转换流程处理资源,再根据入口和动态导入边界生成 chunk,最后输出带 hash、source map 和路由映射的构建产物。性能判断必须回到真实产物和运行时数据,不能只看文件数量或单个未压缩体积。

技术实践

前端工程化(二):从模块系统到依赖图与代码分割

模块系统决定依赖如何被声明和分析;动态 `import()` 建立代码分割边界;Tree Shaking 负责在满足条件时移除未使用代码。三者不能混为一谈,最终结论必须分别通过源码、构建产物和浏览器网络行为验证。

技术实践

前端工程化(一):从流程封装到稳定交付

前端工程化是把开发、检查、构建、测试、发布、监控和维护等流程标准化、自动化,让项目从“能运行”走向“能持续交付”。

AI 实践

Tool Calling:让模型提出请求,而不是获得执行权

Tool Calling 的重点不是让模型生成一段可解析的 JSON,而是把模型的调用意图放进一条由服务端校验、授权、执行、审计和降级的受控协议。

AI 实践

AI 流式输出不是逐字显示:一套可恢复、可追踪、可验证的任务协议

AI 流式输出不是把回答切成小段逐字显示,而是让一次生成在任务状态、业务事件、数据库约束、恢复游标和可信上下文的共同约束下,能够被持续交付、重新连接和确定性验证。

AI 实践

合法 JSON 之后:我如何用四层校验逼近可交付的结构化输出

合法 JSON 只能证明模型输出可以被程序读取;要让内容接近可交付,还必须继续验证字段结构、业务质量和事实依据。

AI 实践

我终于看懂了个人网站里的 AI 调用链路

接入大模型不难,真正重要的是能不能把一次模型调用拆成可配置、可失败、可定位、可继续改造的工程链路。

项目复盘

我如何把栖光做成可复用的业务项目样本

一个项目真正产生长期价值,不是因为它功能越来越多,而是因为它能被整理成可展示、可复盘、可迁移的业务样本。

开发笔记

一个小型业务系统如何做版本、测试和交付

一个业务系统的交付能力,不只体现在功能能不能跑,还体现在每次改动能不能被验证、被记录、被追溯。

开发笔记

我怎样用文档驱动一个全栈项目

全栈项目想长期维护,不能只靠代码记忆,需求、架构、任务、测试、发布和验收都应该留下可追踪的文档痕迹。

技术实践

OpenAPI 和自动生成类型在全栈项目里怎么落地

在栖光这种同时有后端、后台和小程序的项目里,OpenAPI 的价值不是“生成几个类型”,而是让三端围绕同一份接口结构协作。

技术实践

后台数据看板如何区分经营口径和资金口径

后台数据看板的难点不在于把数字查出来,而在于先定义清楚这些数字分别回答什么业务问题。

项目复盘

一个真实业务系统的三端闭环怎么搭

一个真实业务系统的“三端闭环”,不是把小程序、后台和后端都做出来,而是让三类角色围绕同一套订单与运营规则协同工作。

项目复盘

Next.js + Payload CMS 如何做个人品牌中枢

暂无摘要