✦
Creative Front-end
用 Canvas / WebGL / CSS 把设计稿里那点「说不清的感觉」真正做出来。
ReactThree.jsGSAP
DESIGN
MOTION
DEVELOP
↑ 滚得越快 · 三层文字重叠得越深
About
我做的是
我做的是
界面里的手感
六年时间，从像素级的还原走到自己写 shader。相信好的界面不只是「好看」， 而是每一次 hover、每一次滚动都在回应你。
◈
Motion & Interaction
缓动曲线、惯性、速度反馈——让页面像有重量的实体一样运动。
LenisSpringFLIP
◑
Design System
从 token 到组件库，把一次性的漂亮沉淀成可以复用的规范。
FigmaTokensA11y
◐
Performance
再炫的效果也得 60fps。合成层、重绘、内存，一个都不放过。
rAFGPULighthouse
AI Engineering
AI 不是更快的手，
AI 不是更快的手，
是更大的上下文
我对 AI 的判断在过去两年被改写过一次：它一开始像个「打字更快的人」， 现在我更愿意把它当作团队协作协议的一部分。下面是我目前的三条判断， 以及在几十人规模的项目里真正落得下去的做法。
01
AI 放大的是规范，不是产能
同一个模型，在约定清晰的仓库里是加速器，在约定混乱的仓库里是放大器—— 它会以更快的速度，把已有的混乱复制到每一个角落。 所以引入 AI 的第一步从来不是选工具，而是把团队里那些「大家心里都懂」的隐性约定， 变成任何人都能读到的显性文字。
02
提示词不是资产，上下文才是
个人调教出来的 prompt 会跟着聊天记录一起消失，也无法被第二个人复用。 真正沉淀下来的，是仓库里那份任何人、任何时刻拉下来都能读到的约定文件—— 它跟着代码走，跟着 PR 一起被 review，过期了就按 bug 处理。
03
生成很便宜，验证很贵
当写一千行的成本趋近于零，瓶颈就整个移动到了「怎么确认这一千行是对的」。 工程化的重心也因此从提效转向建立信任链：类型、测试、CI、明确的人工确认点， 一个都不能省。评审能力，正在变得比编写能力更值钱。
The Practice
这三条判断，我落成了一套可执行的规范
从上下文文件、CI 护栏，到工作流固化与效果评估，再到让一支团队用出同一种手感的流转链路。
完整做法（含一份可以直接抄的 CLAUDE.md）都在详情里。
L01 Context
L02 Guardrail
L03 Workflow
L04 Evaluation
AI Practice
具体实践
把 AI 装进大型项目的四层地基
Context · Guardrail · Workflow · Evaluation从下往上，每一层只解决一个问题。缺了任何一层，上面的都会塌。
# 技术栈 Next.js 15 · TypeScript strict · Prisma · Tailwind # 目录语义（AI 与人共用同一套） app/ 路由与页面，禁止写业务逻辑 core/ 领域模型，不依赖任何框架 adapters/ 外部系统的唯一出入口 # 禁区 —— 改动一律需要人工确认 prisma/migrations/** auth/** billing/** # 约定 一个 PR 只做一件事；新增依赖必须先在 issue 里讨论
L01
Context · 上下文层规范住「它知道什么」
- 仓库根部一份
CLAUDE.md/AGENTS.md：技术栈、目录语义、命名与提交约定、明确的禁区 - 按目录分层覆写，让每个子系统自带它自己的上下文，而不是塞进一个越来越长的巨型文件
- 上下文文件是代码的一部分：跟着 PR 提交、跟着 PR 被 review，写错了和写错代码一样要改
- 宁可写「不要做什么」。禁区比正面描述更能约束住一个乐于助人的模型
L02
Guardrail · 护栏层规范住「它能改什么」
- 生成的代码走和人完全一样的门：类型检查、lint、单测、CI，不设特例通道、不开绿色通道
- 迁移脚本、鉴权、支付、密钥这类目录显式标记为需人工确认，工具再自信也不能自己按下去
- 可自动执行的命令是一份枚举出来的白名单，而不是一句「你看着办」
- 高风险改动跑在隔离的分支或工作树里——「随时可以整个丢掉」是最便宜的安全网
L03
Workflow · 工作流层规范住「它怎么做」
- 把高频任务固化成可调用的技能与命令：发版、建模块、写迁移，取代每个人各自的临场发挥
- 大改动一律先出方案再落地。方案本身就是 review 对象，它比 diff 更早暴露分歧，也更便宜
- 约定单次任务的粒度：一个任务一个目标，能在一次 review 里读完
- 让工具自己跑验证——测试、构建、截图。人来判断结果，而不是替它跑一遍
L04
Evaluation · 评估层规范住「做得好不好」
- 先定义什么叫「这次用对了」：一次通过率、review 返工率、缺陷密度——而不是「感觉快了很多」
- 规范本身也要做回归：改了约定，要能验证产出质量没有偷偷退化
- 每个失败案例都回流成下一版上下文，让同一个坑只踩一次
- 警惕唯一真正危险的指标：代码量。它涨得最快，也最没有意义
让一支团队用出同一种手感
Individual → Commit → Verify → Inherit个人效率的提升会自然发生，一致性不会——它必须被设计出来。 我的做法是把「某个人的好用做法」变成一条固定的流转链路。
01 · Individual
有人试出来了
某个同事摸索出一套好用的方式，此刻它还只存在于他自己的手感里。
02 · Commit
写进版本库
不进收藏夹、不进群聊、不进个人笔记——提交成仓库里的一次改动。
03 · Verify
被自动检查
规范和代码一样会腐坏，所以它同样需要 CI 来证明自己还成立。
04 · Inherit
全员继承
新人第一天克隆下来，就带着团队至今为止的全部约定，不需要口口相传。
这条链路里最关键的是第二步。团队不该奖励「我的 prompt 更好」， 而该奖励「我把它写进了规范」——前者制造个人英雄，后者才产生一致性。
接下来会发生什么
我的展望，以及我认为不会变的那部分。 越是往后，我越觉得关键变量不在模型，而在我们把话说清楚的能力。
Now · 现在
结对的另一半
AI 承担生成，人承担判断。协作的单位还是文件和函数， 节奏仍然是「我说一句、它写一段、我看一眼」。
Next · 下一步
从按键，到编排
协作单位会从「文件」上移到「任务」。工程师的日常将从敲代码， 变成拆解任务、给出验收标准、并行编排多个 agent 再合流。 而这要求团队先有清晰的任务边界和接口契约——绕了一圈，还是回到规范。
Later · 再远一点
规范成为主产物
如果生成足够可靠，仓库里最有价值的资产会是那份把业务约束写清楚的规范， 代码更像是它的编译产物。到那时，「写文档」不再是发布前的负担，而是主要工作本身。
Constant · 不变的
责任无法外包
无论工具走多远，签下这个 PR、在故障复盘会上说明原因的，永远是人。 这也是我不追求「全自动」的原因——我要的从来不是一条无人值守的流水线， 而是一条我随时能接管、也随时说得清它为什么这么做的链路。
Selected Works
精选项目
往下滚，卡片会按你的滚动速度层层叠上来——停下来，它们就归位。
Gallery
视觉碎片
跑马灯会跟着滚轮加速；鼠标悬停放慢，点击任意一张放大查看。