你问它：“这个 Hook 要不要抽？”它可能已经开始帮你设计参数了。你问它：“这个 bug 怎么修？”它可能已经准备加 if 了。你问它：“这个状态该放哪？”它可能一边回答，一边顺手给你搬出一个状态管理方案。问题是，很多工程判断，最危险的地方不在“不会写代码”，而在“太快进入写代码”。所以我试着换了一个角度看 dan-abramov-skill：不把它当工具介绍。而是把它当一个“AI 代码评审人格”，看看它和普通 AI 的回答差在哪。https://github.com/eric1774-FE/dan-abramov-skill先说清楚：这不是 Dan 本人
dan-abramov-skill 是一个 AI Skill。它不是 Dan Abramov 本人，也不代表他的真实观点。它更像是把 Dan 公开写作、React 官方材料、Overreacted、Redux、Create React App 等资料里反复出现的工程思维，整理成一套 AI 可以调用的判断框架。它不是“请 Dan 来帮你看代码”。它是“让 AI 在看代码时，学会先问几个 Dan 风格的问题”。这个抽象真的需要吗？这个 API 改善了用户体验吗？这个 bug 有复现吗？这个复杂度到底被谁承担了？为什么是 Dan Abramov？
如果你写过 React，大概率绕不开 Dan Abramov。他因为 Redux 被很多人认识。Redux 最初是一个 conference demo，核心是为了讲清楚 time travel 调试。后来，它成了 React 生态里非常重要的状态管理工具。2015 年，他加入 Facebook，也就是后来的 Meta，进入 React Core 团队。之后几年，他参与过 React 文档、Hooks 推广、开发体验、Create React App 等工作。2023 年，他离开 Meta。后来去了 Bluesky，做 React Native app 质量、性能和团队工程指导。到 2025 年，他在 Overreacted 上说，自己开始做少量 UI engineering consulting。React 官网团队页现在也把他列为 Independent Engineer。因为他不是单纯“会写代码”的工程师。他更擅长的是：把复杂的 UI 工程问题，讲成一个人能理解的心智模型。测评方式
我没有测 token、速度、通过率。我只拿三个前端里最常见的问题，比较两种回答风格：普通 AI：倾向于直接给方案。Dan Abramov Skill：倾向于先拆问题。案例一：这个 Hook 抽得挺漂亮，要不要保留？
function useAsyncAction(action) { const [loading, setLoading] = useState(false); const [error, setError] = useState(null); async function run(...args) { setLoading(true); setError(null); try { return await action(...args); } catch (error) { setError(error); } finally { setLoading(false); } } return { run, loading, error };}
普通 AI 可能会怎么答？
普通 AI 大概率会沿着“怎么把这个 Hook 变得更好”的方向继续走：可以加泛型。可以补错误类型。可以支持 onSuccess 和 onError。可以加取消请求。可以加防重复提交。可以把 error 类型收窄。Dan Abramov Skill 会怎么问？
Like 可能需要乐观更新，失败要回滚。Save 可能需要防重复提交，失败要保留草稿。这时候，最好的答案可能不是“把 Hook 抽得更通用”，而是“先别抽”。重复几行代码，不一定是坏事。错误抽象，才可能变成以后每次改需求都要还的债。差别在哪？
普通 AI 在优化答案。Dan Abramov Skill 在质疑问题。普通 AI 问：“这个抽象怎么写得更漂亮？”Dan Abramov Skill 问：“这个抽象现在就该存在吗？”很多项目不是死于代码太重复。而是死于每个重复都被提前封装了。案例二：这个 bug 偶现，能不能先加个防御判断？
偶现。刷新一下好了。本地不复现。线上有人遇到。日志还不够。if (!data?.items) return [];
普通 AI 可能会怎么答？
这里可能是空值。这里需要 optional chaining。这里加 fallback。这里处理 loading 状态。但如果问题是竞态、stale closure、缓存污染、多实例共享状态，guard 只是把症状盖住。你以为你修了 bug。其实你只是把错误提示静音了。Dan Abramov Skill 会怎么问？
用户做了什么？期望看到什么？实际发生什么？能不能把页面删到只剩一个状态、一个事件、一个渲染路径？如果没有 repro，直接修就像闭眼修水管。你听见水声没了，但你不知道水漏到哪去了。边界当然要防御。但如果 guard 只是为了让报错消失，而不是解释错误为什么出现，那就危险。差别在哪？
普通 AI 更像急诊止血。Dan Abramov Skill 更像追病因。止血有价值。但如果每次都止血，从来不查为什么出血，项目迟早变成补丁展览馆。案例三：RSC 是不是就是组件放服务器上跑？
React Server Components 很容易被一句话讲歪：普通 AI 可能会怎么答？
减少 bundle。更接近数据源。首屏更快。SEO 更好。服务端直接访问数据库。Dan Abramov Skill 会怎么问？
哪些代码会进客户端 bundle？哪些值必须可序列化？哪些状态属于交互？哪些逻辑应该靠近数据？错误、streaming、缓存、导航怎么跨边界？RSC 的重点不是“服务器更快”这个口号。重点是 client/server 边界进入了模块系统。它把一部分复杂度从业务代码里吸走，同时放进框架、协议、构建工具和安全边界里。这可能值得。但只有当团队真的理解这些边界时才值得。差别在哪？
普通 AI 容易把新技术讲成功能清单。Dan Abramov Skill 更关心问题形状有没有变。因为很多技术债，不是因为你选了坏工具。而是因为你用旧问题理解了新工具。这个 Skill 真正有用的地方
看完这三个例子，我觉得 dan-abramov-skill 最有价值的地方，不是“回答更像 Dan”。普通 AI 很擅长补全。但工程判断很多时候不是补全。是删除。是质疑。是承认不知道。是先找复现。是先问用户体验。是先看这个抽象到底该不该存在。安装方式
如果你的 AI runtime 支持 Agent Skills，可以用一行命令安装：npx skills add eric1774-FE/dan-abramov-skill
git clone https://github.com/eric1774-FE/dan-abramov-skill.git ~/.codex/skills/dan-abramov-skill
如果你的工具暂时不支持自动加载 Skill，也可以直接打开仓库里的 SKILL.md，把内容复制到对话里使用。https://github.com/eric1774-FE/dan-abramov-skill怎么触发它？
用 Dan Abramov 的视角帮我看这个 React 抽象
切换到 Dan Abramov Skill，帮我 debug 这个 UI 状态 bug
这个 Hook 到底该不该抽？用 dan-abramov-skill 帮我判断
最后
我觉得这个 Skill 适合放在 AI 写代码之前，也适合放在 AI 写完代码之后。写之前，用它防止 AI 太快开工。写之后，用它检查 AI 有没有过度抽象、跳过复现、混淆边界。但它能让 AI 少一点“我来封装一切”的冲动。多一点“这东西真的需要吗”的分寸。参考资料
- Skill 仓库:https://github.com/eric1774-FE/dan-abramov-skill
- Dan Abramov 自述:《My Decade in Review》：https://overreacted.io/my-decade-in-review/
- Dan Abramov 近况:《I'm Doing a Little Consulting》：https://overreacted.io/im-doing-a-little-consulting/
- React 团队页:https://react.dev/community/team
- Redux 官方文档:https://redux.js.org/introduction/getting-started
- React 官方:《Sunsetting Create React App》：https://react.dev/blog/2025/02/14/sunsetting-create-react-app
夜雨聆风
