掘金本周最热

前端圈7月大地震：TS 7发布、Bun 11天从Zig迁Rust、Kimi K3登顶、大厂裁员50%

涛涛ing — Fri, 17 Jul 2026 01:11:52 GMT

前端圈7月大地震：TS 7发布、Bun 11天从Zig迁Rust、Kimi K3登顶、大厂裁员50%

2026年7月，前端圈几乎一天一个大新闻。TypeScript 7.0正式发布，编译器用Go重写、速度暴涨10倍；Bun用11天把78万行代码从Zig迁到Rust，测试100%通过；Kimi K3在Frontend Code Arena登顶，力压Claude Fable 5；与此同时，阿里飞猪传出测试和前端岗位裁撤比例达50%，大厂裁员潮仍在蔓延。这个7月，前端圈正在经历冰火两重天。

一、7月8日：TypeScript 7.0正式发布，14年来最大变革

2026年7月8日，微软正式发布了TypeScript 7.0。

这是TypeScript自2012年诞生以来最重大的一次底层重构。整个编译器从TypeScript/JavaScript被逐行移植到了Go语言，带来了原生代码速度、共享内存多线程以及一系列新优化。

1.1 性能数据：最高12倍

微软官方公布的基准测试数据非常震撼：

项目	TypeScript 6.0	TypeScript 7.0	提升倍数
VS Code（约230万行）	125.7秒	10.6秒	11.9倍
Sentry	139.8秒	15.7秒	8.9倍
Bluesky	24.3秒	2.8秒	8.7倍
Playwright	12.8秒	1.47秒	8.7倍
tldraw	11.2秒	1.46秒	7.7倍

在VS Code项目中，完整构建从将近两分钟压缩到了十秒钟。编辑器端的响应速度同样惊人——当开发者打开一个包含错误的文件时，7.0版本定位首个错误的时间从此前约17.5秒缩短至约1.3秒，响应速度提升约13倍。内存占用也明显改善，在VS Code项目中降幅约18%，在Bluesky项目中降幅约26%。

1.2 为什么能快10倍？

过去十四年，TypeScript编译器一直采用 “自托管”方式——用TypeScript本身写编译器，再编译成JavaScript在Node.js上运行。这套方案有三个硬性天花板：单线程瓶颈、JIT预热、GC不匹配。

Go一次性移除了这三个天花板：

编译成原生机器码，没有JIT预热和JavaScript解释开销
goroutine实现了跨CPU核心的真正共享内存并行
Go的并发垃圾回收器不会长时间暂停执行

1.3 升级方式：一行命令

npm install -D typescript@latest

TypeScript 7.0在VS Code、Visual Studio和WebStorm等主流编辑器中开箱即用。

不过需要注意：对Vue、Svelte、Astro或MDX的开发者来说，由于缺少程序化API，这些框架的完整编辑器支持需要等待TypeScript 7.1。微软发布了兼容性包@typescript/typescript6，支持6.0与7.0并行共存。

二、Bun 11天从Zig迁到Rust：78万行代码，100%通过

7月8日，就在TypeScript 7.0发布的同一天，JavaScript运行时Bun的创始人Jarred Sumner在官方博客发布了一条令整个技术社区震惊的声明。

经过仅仅11天的高强度工作，Bun的全部1448个Zig文件已被机械式转换为Rust代码，测试套件实现100%通过率，新版本v1.4.0已通过canary渠道发布。

78万行代码，11天，100%通过。这个速度是怎么做到的？答案是AI主导重构。整个转换过程由AI辅助完成，实现了大规模代码库的机械式迁移。

这意味着什么？前端工具链的“换芯”革命正在加速。Bun从Zig迁移到Rust，加入了一个越来越长的名单：Vite从Go的esbuild+rollup换成了Rust的Rolldown，Astro从Go编译器换成了Rust编译器，现在连Bun也加入了Rust阵营。前端工具链正在从“JavaScript写工具”全面转向“Rust写工具”。

三、7月16日：Kimi K3发布，Frontend Code Arena登顶

2026年7月16日，月之暗面（Moonshot AI）上线推出了Kimi K3模型。

这是Kimi迄今能力最强的模型，拥有2.8万亿参数，100万Tokens上下文，主要面向长程编程与端到端知识工作。价格方面，每100万Tokens输入费用为2元（缓存命中）/20元（缓存未命中），输出费用为100元。

架构上，Kimi K3基于Kimi混合线性注意力机制（Kimi Delta Attention）和注意力残差（Attention Residuals）技术构建，原生支持视觉理解。

最让前端圈震动的是性能数据：在Frontend Code Arena中，Kimi K3以1679分超越Claude Fable 5，位居第一。@arena官方账号表示：“在前端领域，Kimi-K3在7个领域中的6个位居#1：品牌与营销、基于参考的设计、数据与分析、消费产品、模拟以及内容创建工具，仅在游戏领域位列#2，落后于Fable 5。”

前端代码生成能力，正在被中国模型刷新纪录。

四、Gemini 3.5 Pro泄露：前端“一次成型”

同样是7月，Gemini 3.5 Pro的泄露版本让整个前端圈沸腾。

综合多位开发者的反馈，泄露版本在“前端与视觉代码生成”上出现了一次明显的能力跳变：

设计品味更好：生成的界面不再是“程序员审美”，配色、留白、层次更接近专业设计师
UI更干净：一次成型的前端页面结构清晰，冗余更少
SVG生成显著增强：复杂矢量图形能一次画对
完成度更高：一句话生成一个像模像样的页面

在开发者圈子里甚至流行起了一个词来形容它的表现—— “mogging”（彻底压制） 。

不过，前端封神不等于全面封神。在最硬核的Agent任务、仓库级软件工程和长程任务上，Gemini 3.5 Pro依然打不过Fable 5或GPT-5.6。

五、大厂裁员：飞猪传前端裁撤50%

技术突破的另一面，是残酷的行业现实。

截止到2026年7月，社交平台传出阿里旗下飞猪进行大规模人员调整，其中甚至出现**测试和前端岗位裁撤比例达到50%**的说法。尽管具体数字尚未获得官方确认，但类似传闻并不是孤例：小米、B站、网易、科大讯飞、美团等公司也先后陷入技术岗、产研岗和基础外包岗位大幅收缩的舆论风波。

美团官方回应称近两个月实际离职不足2000人，占全员比例不到2%，属于正常的业务优化。但行业整体收缩的态势已经非常明显。

曾经一个需要五个前端干上一个月的后台管理系统，现在只需一个产品经理对着Codex疯狂输出提示词，三天就能拼凑出一个能跑、能看、甚至带动画的完整项目。代码的产出效率被提高了十几倍，于是各大厂的高层一拍脑袋：既然AI写得这么快，那我们为什么还需要养这么多初中级前端？

六、同一时期：还有四件大事

6.1 Deno 2.9发布：前端框架直接打包成桌面应用

Deno 2.9的亮点功能是deno desktop，它支持把Next/Nuxt等前端框架项目转化为一个独立的原生桌面应用，最终产物是一个跨平台分发的二进制文件，无需借助Electron/Tauri等桌面应用框架。

6.2 Vercel skills狂揽2.4万星

Vercel推出的Skills项目上线五个月便在GitHub获得2.4万星标。通过一行命令npx skills add <package>，开发者可以为Claude Code、Cursor等多种AI工具快速安装能力包。榜首find-skills安装量已超230万次。

6.3 HeroUI v3正式发布

HeroUI（前身为NextUI）发布了v3版本，针对React和React Native从头进行了重写，并基于Tailwind CSS v4构建。

6.4 Yuku开源：Zig重构前端工具链

2026年7月14日，基于Zig语言从零构建的JavaScript/TypeScript工具链Yuku正式开源。前端工具链的“换芯”大战，又多了一个新玩家。

七、把七月这些事放在一起看

2026年7月，前端圈几乎一天一个大新闻：

7月8日：TypeScript 7.0正式发布，10倍提速；同日Bun宣布11天从Zig迁到Rust
7月14日：Yuku开源，Zig重构前端工具链
7月16日：Kimi K3发布，Frontend Code Arena登顶
7月：Gemini 3.5 Pro泄露，前端“一次成型”；Vercel skills狂揽2.4万星；Deno 2.9支持桌面应用；大厂裁员潮持续

放在一起看，四个趋势已经非常清晰：

趋势一：前端工具链正在“全面换芯”

TypeScript 7.0用Go重写编译器、Bun从Zig迁到Rust、Astro用Rust重写编译器、Vite 8用Rust的Rolldown取代Go的esbuild+rollup——前端工具链正在从“JavaScript写工具”全面转向“系统级语言写工具”。甚至连Zig都开始入场了（Yuku）。从打包工具到编译器，从linter到formatter，所有“吃性能”的环节都在被重写。

趋势二：AI正在重新定义“前端开发”

Gemini 3.5 Pro的前端生成能力跃升、Kimi K3在Frontend Code Arena登顶、AI编程工具全面爆发——当AI能完成过去需要数小时甚至数天才能完成的工作时，前端开发者的角色正在从“写代码的人”变成“指挥AI的人”。

趋势三：裁员与技术突破并存

TS 7发布、Bun迁移、Kimi登顶——技术层面的好消息不断。但与此同时，飞猪传前端裁撤50%、美团等大厂技术岗收缩。行业正在经历“冰火两重天”：技术越强，对初级岗位的需求越少。

趋势四：AI编程能力正在“中国化”

Kimi K3在Frontend Code Arena登顶，力压Claude Fable 5。中国大模型在前端代码生成这个细分领域，正在改写全球排名。

写在最后

2026年7月，前端圈几乎一天一个大新闻。

TypeScript 7.0把编译速度提升了10倍。Bun用11天把78万行代码从Zig迁到Rust。Kimi K3在Frontend Code Arena登顶。Gemini 3.5 Pro让前端代码“一次成型”。Vercel skills狂揽2.4万星。Deno 2.9让前端框架直接变成桌面应用。与此同时，大厂裁员潮仍在蔓延。

这个7月，是前端圈冰火两重天的7月。

一边是技术突破的速度在加快——工具链在换芯、AI在进化、新框架在涌现。另一边是行业在收缩——初级岗位在消失、大厂在裁员、焦虑在蔓延。

这两个趋势并不矛盾。它们是同一枚硬币的两面：技术越强，对人的要求越高。

三年前，前端是“写页面的人”。2026年7月，前端是“指挥AI写页面、用Rust工具链构建、用Deno打包成桌面应用、在Kimi K3和Gemini 3.5 Pro的夹缝中找自己位置的人”。

这个月发生的事，比去年整个下半年加起来还多。而你，跟上了吗？

评论区聊聊：2026年7月，哪个消息最让你震撼？你升级TypeScript 7.0了吗？

停更的这一年，All In AI、陪媳妇生娃、还考了个研

我是Allen — Thu, 16 Jul 2026 06:49:11 GMT

停更的这一年，All In AI、陪媳妇生娃、还考了个研

打开掘金 App，看了一眼自己的最近更新——停在了整整一年前。

不是不想写，是这一年确实被塞得太满了。如果非要用几个关键词来概括，那就是：

All In AI；
媳妇怀孕 → 生娃；
在职考研。

今天终于坐下来，想好好聊聊这一年发生的事，也算给自己一个阶段性的交代。

一、All In AI：在浪潮里拼命折腾，却发现自己始终在岸边

我所在的公司主营 SaaS 业务，去年开始转型，几乎整个团队都押注 AI。

于是我从第一天起，就被裹挟进一场没有终点的学习马拉松：

GitHub Copilot、智谱、Kimi、DeepSeek、ChatGPT、Claude Code……工具换了一茬又一茬，模型迭代快得让人喘不过气。

很多时候，刚摸清一个工具的边界，下一代版本就已经把你之前的经验直接覆盖掉。

坦白说，这一年在技术深度上，我的成长并不大。

大部分时间都花在了 AI 应用层——理解客户的真实需求，用工程化能力把 AI 落地到具体的业务场景里。

至于框架层、核心逻辑的参与很少，看着别人写底层架构，心里确实羡慕。

不过，软技能的提升是实实在在的：

跟客户沟通需求，不再只讲技术术语，而是真正听懂他们在业务上的痛点；
对几个垂直行业的业务流程，也有了更体系化的理解；
学会了在快速变化中保持自己的节奏，而不是被焦虑牵着鼻子走。

虽然没有深入工程化能力，但我也没让自己闲着。如果你也在做 AI 工程化落地，我推荐一些资料，或许能给你一些启发：

后面如果有空，我会单独写一些 All In AI 过程中踩过的坑，以及那些真正让我成长的点。

二、媳妇怀孕 → 生娃：从两个人到一个家，取舍比想象中更具体

从媳妇怀孕那天起，家里就不再是我和她两个人的事了。

吃什么、怎么吃、她爱吃什么、产检陪不陪、孩子出生后谁带、怎么带——每一件都是具体到每天的问题。

说实话，不是没吵过架，也不是没手忙脚乱过，但好在最后家庭还算和睦，娃也健康落地。

决定要孩子，本质上就是一次生活资源的重新分配：

放弃了随心所欲的二人世界；
生活质量肉眼可见地下降（时间、金钱、精力都吃紧）；
个人爱好基本搁置；
社交圈自动收缩，能推的局全推了。

但换来的，是一个会冲你笑、会半夜哭醒、会一天天长大的小家伙。

晒一张我家潮娃的照片。

另外，说来也巧合，我们带着娃做了童模，顺手尝试做了母婴赛道，抖音和小红书都开了号，算是给这段经历留点额外产出。虽然收入甚微，但也留下了美好的回忆。

三、考研：34 岁，硬着头皮跟自己较劲

最后聊聊考研。

我考的是在职研究生，不是全日制。

原因很简单：学历太低，见识太少，经济下行，年纪越来越大。

我害怕 35 岁真的成为我个人职业生涯的危机，光靠技术文章弥补不了学历短板——有 HR 跟我说过，“你的学历是硬伤”，我就知道这句话意味着什么。

那就考吧，34 岁又怎样？

拼一拼，单车也许真能变摩托。

收到录取通知书那天，心情很复杂。

喜悦当然是有的，但也同样沉重：

接下来要花更多时间在学业上；
陪伴孩子的时间会被进一步压缩；
学费又是一笔不小的开销。

回过头看这一年，我自己都不知道是怎么坚持下来的。

离开校园已经十年，底子本来就差，重新捡起书本需要很大的勇气。

所以我的节奏很简单：每天下班回家，吃完饭，带娃一小时，然后坐到书桌前，看书、做题、记笔记。

日复一日，一坐就是一年。

没有捷径，也没有奇迹，只有硬扛。

我对自己的要求就一条：人笨，就多花时间。

四、写在最后

1、这一年，我没有输出多少技术文章，但输出了一段很真实精彩的人生。尝试了从未尝试过的事，也是以前不敢想象的事。

2、 AI 还在学，娃还在长，研究生还要继续读。

如果你也处在类似的阶段——焦虑、迷茫、被生活推着走——我想说，不要给自己设限，多尝试尝试，也许真的会看到不一样的风景。

曾经人手一个的Superpowers，为什么现在都在卸

卡卡罗特学AI — Thu, 16 Jul 2026 06:47:57 GMT

一个GitHub上有超过25万星标的项目，用户正在集体卸载它。

这个项目叫Superpowers，是Claude Code生态里最火的skill插件，没有之一。装上之后，它会给你的Agent注入14个skill模块，强制每个任务走brainstorm、spec、plan、TDD、code、review这一整套流程。

听起来很美好对吧？

但最近我身边的朋友一个接一个把它卸了。我问为什么，得到的答案出奇的一致，太慢了，太吃token了，而且现在的Agent已经不需要这些东西了。

我一开始是不信的。直到我自己也卸了。

🔹 先说说Superpowers到底干了什么

Superpowers刚出来的时候，确实解决了一个真实的痛点。

那时候的Agent还比较「莽」。你丢一个需求过去，它上来就开始写代码，不规划，不测试，写完可能一堆bug。你得反复让它改，效率其实很低。

Superpowers的思路是，既然Agent自己不够自律，那就给它加一套流程约束。每个任务必须先头脑风暴，再写spec，再做计划，再TDD，再写代码，最后review。相当于给一个冲动的实习生套上了一整套SOP。

2025年秋天它发布的时候，整个开发者社区都在安利。GitHub星标一路飙过25万，进了Anthropic官方市场。

但问题是，那是2025年的Agent。

🔹 25万星标背后的代价

我真正动了卸载念头，是因为一个朋友跟我吐槽。他让Claude Code帮他改一个很小的bug，就是把一个变量名从驼峰改成下划线。

正常来说，这个事情十秒钟就搞定了。

但装了Superpowers之后，它先花了一分钟做brainstorm，然后写了一份spec，接着做了一个plan，然后才开始改那个变量名。改完还要跑一遍review。

一个十秒钟的事，搞了五分钟。

他跟我说完我就去GitHub上翻了一下issue，发现有这种感觉的人真不少。

有个用户专门做了测试，装上Superpowers之后，Claude Code启动就要吃掉22000个token，还没开始干活就先用掉了11%的上下文窗口。再加上系统本身的占用，有效工作空间大打折扣。

💡

GitHub地址：github.com/obra/superpowers/issues/190

还有个更离谱的，有人说他一个简单任务，5分钟就把整个token配额打满了。原话是「after 5 minutes i went from 0% to 100% quota reached」。

一个本来是帮你省力的工具，结果反过来成了最大的资源消耗源。

🔹 不止是慢，它还可能让Agent变蠢

这个是我没想到的。

有个Hacker News用户的评论让我印象特别深，他说「I personally don't like superpowers very much. My boss does. I think Claude makes more mistakes when using superpowers than when not」。连他老板都觉得好用，但他自己用下来的体验是，装了之后Claude反而犯更多错了。

你想想看，这其实说得通。Agent的上下文窗口是有限的，你塞了14个skill进去，每个skill都有一堆指令和规则，Agent在处理你的需求的同时还要兼顾这些规则，注意力被分散了。就像你让一个人干活的同时还要背诵一本操作手册，他反而更容易出错。

维护者自己也意识到了这个问题。后来专门做了一次大优化，把14个skill的代码从3150行砍到了977行，砍掉了69%。

但砍完之后核心问题还在，它依然会在每个任务前面强制插入一套完整流程。

🔹 最让我觉得有意思的一个对比

有个叫DizzyMii的开发者做了一个叫fable-skills的项目，只有6个轻量skill，思路跟Superpowers完全相反，不搞强制流程，只在关键节点轻轻引导一下。

他用Opus 4.8做了多轮压力测试来打磨这6个skill，得出的结论是，轻量引导完全够用。

不需要14个，6个就够了。

这说明什么？不是skill越多越好，也不是流程越复杂越好。Agent不需要你给它套那么多规矩，它需要的是在关键节点被轻轻推一下就够了。

Agent不是不听话的小孩，它是一个需要适度引导的成年人。你给它发一份员工手册就够了，不需要派一个监工24小时盯着。

🔹 那Agent到底变强了多少

说真的，这半年Agent的进化速度是肉眼可见的。

我自己最直观的感受是，Fable 5出来之后，很多以前需要skill才能做到的事，它自己就会了。

以前的Agent你不告诉它「先想清楚再动手」，它真的会上来就莽。现在不一样了，你丢一个复杂需求给Fable 5，它会自己先去看相关文件，理清依赖关系，想好方案，然后才开始改。改完还会自己跑测试验证。

MCP Directory有篇专题文章说得很直白，「Fable 5 investigates before acting and verifies its own work with less prompting」。模型自己已经会规划和验证了，不需要外挂一套流程来教它。

文章最后的建议是，如果你用Fable 5，最多保留brainstorm和review两个模块就够了，其他的全删。

WebDevCody，YouTube上很有名的一个开发者，也公开发推说卸载了。他的原话是「I guess I'm just not a fan of having to babysit it the entire time and answer its 20 questions to implement a simple feature. I rather let Claude yolo it and reprompt a bad first iteration」。

为了实现一个简单功能，要回答20个问题。他宁可让Claude先莽一遍，不行再重来，也不想被流程绑着走。

💡

X推文地址：x.com/webdevcody/status/2006458368387596696

说真的我完全理解这种感觉。

🔹 这其实是一个很经典的规律

你回想一下智能手机刚出来的时候。

那时候iPhone上什么都要装app。手电筒要装一个app，计算器要装一个app，指南针要装一个app，扫码要装一个app，甚至量尺寸都要装一个app。

后来呢？系统自带了。手电筒内置了，计算器内置了，指南针内置了，扫码用相机就行了。那些曾经下载量百万的工具类app，安静地消失了。

没有人怀念它们。

AI开发工具正在经历完全一样的事情。早期模型能力不够，需要外挂skill来补能力，就像早期手机功能不全需要第三方app来补功能。但模型能力上来之后，这些外挂的skill就变成了冗余。

当底层能力足够强的时候，上层的补丁自然会退场。这不是skill做得不好，是它完成了自己的历史使命。

🔹 但我不是说skill完全没用了

这话我得说清楚。

Superpowers对有些人来说依然有价值。如果你是一个刚开始用AI写代码的新手，你可能确实需要一套流程来帮你建立好的工作习惯。如果你在一个团队里，需要统一所有人的开发规范，强制走review流程，那Superpowers的思路也是合理的。

还有一些特别复杂的、跨多个文件和系统的大型重构，有时候一个轻量的plan skill确实能帮Agent理清思路。

关键是，skill应该是「按需启用」的，而不是「全套安装」的。

就像你不会在手机上装14个效率app然后全部开着后台运行一样。你需要哪个就开哪个，不需要的时候就关掉。

反正我觉得，2026年下半年的正确姿势是，CLAUDE.md写好项目规范，必要的时候挂一两个轻量skill做特定场景的辅助，其他的交给Agent自己来。

Agent已经长大了，你得学会放手。

🔹 说到底

工具生态的演化跟自然界其实是一个道理。早期物种靠外骨骼保护自己，后来进化出了内骨骼，外骨骼就退化了。不是外骨骼不好，是内在能力强到不需要它了。

Superpowers是一个好产品，它在Agent还不够成熟的时候提供了真实的价值。但技术的车轮不等人，模型在进化，Agent在进化，用户的需求也在进化。

能力被内化，补丁就退场。

这不是谁的失败，这是进步本身。

你现在还在用Superpowers或者其他skill插件吗？觉得哪些该留哪些该卸？评论区聊聊，我每条都看。顺手点个赞，点个在看，星标⭐加一个，下次更新第一时间见。

谢谢你看我的文章，我们，下次再见。

💡

/ 作者：卡卡罗特 / 投稿或爆料，请联系邮箱：19331922086@163.com

Harness 企业级落地(二) - 让 AI 读懂项目

Karl_wei — Wed, 15 Jul 2026 17:36:52 GMT

上一篇，我们描述了 Harness 的框架和整体设计：一套稳健的软件工程设计，约束 AI 在工程里稳定的工作。开源地址：cow-harness

AI Harness 企业级落地实践（一）

这一篇我们继续深究，一个团队如何能成长为：AI 全栈开发，可以同时维护 APP、后台、网页等多端代码。

AI 时代下，我们认为程序员不应该局限于某一门技术，应该以顶层思维看待整个项目,了解整个系统的设计和数据流向。
这样不仅能够提高个人的知识广度，更能够独立且高效地完成具体的某个模块，从而加快产品的迭代速度，实现快速的想法验证。

一、顶层设计思维

要完成 AI 全栈，得先做到：

把我们的全栈项目汇总管理起来
让 AI 读懂每个子项目的代码风格、框架分层、设计理念，并沉淀下来

进而达到：

无论什么模型，都能快速地知道你的需求，需要动到具体哪一个端
编码符合这个端的风格，代码也不会出现低级失误
编写完毕之后，能够自动启动各个端，然后自己做跨端的e2e 全流程测试

二、基于 git submodule 的项目结构

针对全栈协作的场景，APP、后端和网页端等各个端，会有各自有独立的代码仓库，同时迭代节奏和分支管理也有所不同。

所以我们先维护一个组合根仓库，把业务子项目通过 Git submodule 的方式去汇合起来，常见的结构大致是这样：

fullstack-workspace/
├── cow-harness/                    # 全栈入口与通用 Harness
├── .ai-harness/
│   └── workspace-map.md            # 业务模块地图
├── apps/mobile/                    # APP 端代码（git submodule）
├── services/backend/               # 后端代码（git submodule）
└── apps/web/                       # 网页端代码（git submodule）
│ 
└── .gitmodules

.gitmodules

记录仓库来源和落盘路径，根仓库记录每个子仓库此刻应使用的分支。这样子团队任何人拉下根仓库，都能拿到同一组前后端代码版本；
submodule 本身不会影响子项目的分支策略，分支规范、提交习惯和代码目录仍由各子仓库自己维护。

workspace-map.md

盘点子项目分别属于什么领域、是否已经初始化等；
一张地图，解决“这个任务先去哪里”。

三、让 AI 深度读懂整个项目

“读懂” 不是让 AI 把整个仓库扫一遍，然后给你写一份看上去很专业的总结；而是要非常精准的知道每个项目的设计、风格、规范约束、安全性能指标等。

为此，我们特意为这个环节编写了一个 SKILL：domain-init。

这个 SKILL 拥有非常完整的项目识别能力，不仅接入到 cow-harness，也独立进行了开源，需要自取：github.com/MinLeeV5/do…

1. 前置介绍

domain-init 会先做领域识别：从构建文件、依赖、入口、测试工具和目录结构里找信号，判断当前项目是哪个端（如：更接近 React 前端、Go 后端、移动端、CLI...）。

确定领域后，会采样真实代码，识别项目已经在使用的架构设计、组件规范、接口分层、测试夹具和验证命令等等，再把这些事实变成可 review 的规则草案。

核心重点：代码是事实源，规则只是对事实的结构化表达。

2. 四大原则

原则	它解决的问题
信号优先	先根据项目里的依赖、入口和构建文件判断领域，避免一份前端规范误用到后端或客户端。
证据先行	每条约定都要能回到项目代码中找到出处，避免模型凭记忆造出“理论正确、项目错误”的规则。
按领域过滤	前端重点看设计系统、状态和可访问性；后端重点看接口、数据和可观测性。相关的才进入上下文。
人不缺席	领域判断、扫描范围、规则草案和最终写入都有确认点。AI 负责归纳，人负责判断哪些是约定、哪些只是历史包袱。

3.最佳实践

如果只是从已有项目里抽取，会有另一个风险：可能原本项目就设计得不是很好，然后 AI 就会依照这个规范越写越烂。

于是 domain-init 还提供了一些最佳实践 references。

参考文件	设计作用	避免
`detection-signals.md`	定义领域识别的优先级、降级路径和人工确认机制。	把项目类型猜错。
`domain-matrix.md` 与 `dimension-pool.md`	用领域矩阵过滤规则、Skill 和 Agent 的适用维度。	把所有治理维度一次性塞给每个项目。
`project-index.md`	为不同问题指定开源质量标杆和应参考的关键文件。	只会套空泛的“最佳实践”。
`output-formats.md`	规定 rule、skill、agent 的结构、代码示例和证据要求。	生成只有口号、没有执行性的产物。

project-index.md ：关键的质量索引，引用了大量的优秀实践，不同的问题，我们去找不同的标杆。比如：

编码约定可以参考 everything-claude-code 的分语言规则
前端性能和组件架构可以参考 Vercel 的 agent skills
测试策略和验证门控可以看 get-shit-done
安全审查则有 gstack 和 Trail of Bits 的工作流

同时，使用这些优秀实践时，不是把别人仓库的内容拷过来。核心是让 AI 学习它如何组织规则、如何表达硬约束、如何把验证写进流程；然后再回到当前项目的代码事实，生成适合自己的内容。

验证链路：领域判断有信号，规则结论有代码，产物质量有标杆，落盘前有人 review。

四、初始化产物

初始化完成后，每个子项目里都会有一组**能被后续任务反复读取的资产。**这些资产不会放在组合根仓库，而是放在各自的业务子项目里。

services/backend/
├── AGENTS.md                       # AI 进入项目的入口
├── cow-harness/
│   └── skills/domain-init/          # 嵌套的领域初始化 skill
├── .ai-harness/
│   ├── project.profile.md           # 项目画像
│   ├── context-map.md               # 模块、入口与边界
│   ├── verification.md              # 验证方式与命令
│   └── domain-init-report.md        # 检测依据、确认范围和结果
├── .agents/                         # 当前项目选择的平台规则、skills、agents
└── .ai-runtime-artifacts/           # 需求、计划、验证与决策记录

project.profile.md ：回答“这是什么项目、关键约束是什么”；

context-map.md ：回答“代码应该改在哪里、边界在哪里”；

verification.md 回答“改完怎么证明它没问题”。

另外还会生产一些模型层的入口

domain-init-report.md ：把领域判断的依据、用户确认过的范围和生成结果保留下来，避免这些结论变成无从追问的黑盒；

.agents/ ：这个项目真正会被 AI 加载的规则、skills 和 agents；

.ai-runtime-artifacts/ ：保存需求分析、计划、验证记录和架构决策。

五、初始化后，如何执行任务

当一个任务从全栈组合根目录进入时

AI 先读 workspace-map.md
任务里出现明确的项目路径、模块名、接口名或界面名，就用这些证据定位业务子项目
结合相关的多个项目，开始判定任务体量，决定是否进行 spec 拆解
项目一旦选定，读取顺序也固定下来：先通过 AGENTS.md 进入项目，再加载 cow-harness/core/ 的通用流程，以及当前项目的 project.profile.md、context-map.md 和 verification.md
然后 AI 会遵循 harness 的规范，去使用 superpower 和 omx 开始干活

六、快速接入

维护好全栈组合仓库，先把所有子模块拉到组合根仓库锁定的版本：

git submodule update --init --recursive
git submodule status --recursive

2. cow-harness也作为 submodule 加入到你的项目中

git submodule add git@github.com:WxqKb/cow-harness.git cow-harness
git submodule update --init --recursive

3. 接下来让cow-harness 开始为你初始化子项目：

请先读取 cow-harness/README.md、cow-harness/init/fullstack-bootstrap.prompt.md
和 cow-harness/skills/domain-init/SKILL.md。

这是一个由多个业务子项目组成的全栈项目。请先运行
git submodule status --recursive，区分业务子项目、Harness 和第三方依赖；
展示候选业务子项目并等待我选择。只初始化我确认的子项目，
不要在组合根目录生成混合的领域规则，也不要自动改写未选择的子项目。

七、写在最后

实际上，各大基模的在 coding 的发力下，AI 对程序员行业的冲击是致命的，在大公司体感是十分明显的。

比方说：接收到的一句话需求，能让 AI 全面了解拆分，快速搭建出 A/B 方案，并发布给天使用户测试。这个流程验证以往可能要投入一周的时间，但是 AI +harness 2 天就能搞定。而这种提效方式，对个人和业务都会产生不容小视的价值，而且早已不是天方夜谭。

Harness 全栈说白了，也会卷掉一波人。

但笔者想说的是，在这个大环境下我们尽量去成长。当编码技术不再是壁垒的时候，我们应该更快速的去利用好 AI，让 AI 全面扩宽我们的知识面和业务边界。 沉淀成为我们的核心竞争力，那我相信当环境好起来后，你依然是那个香饽饽～

下一篇，我们会继续深入讲解 harness 中，是如何使用 openspec 和 omx 工作流，进行高质量的工作的。

cow-harness 开源仓库，欢迎使用！

掘金VibeLaunch 沸点秀来啦🚀

沸点小助手 — Wed, 15 Jul 2026 08:26:06 GMT

不用死磕代码，用 Prompt 指挥 AI，分分钟把脑洞变成能跑的项目——这就是 Vibe‑Coding 的魔力。

现在，掘金请你来「沸点」晒出你的 AI 编程成果！

✅ 参与方式

带话题 #VibeLaunch 沸点秀，在 VibeLaunch 圈子下发沸点，包括但不限于：

项目简介 + 实现思路
成果截图 / 演示视频（加分）
附上 Prompt 或代码片段（更容易拿奖哦）

📅 参与时间

7月15日-7月24日 23：59

📮 内容参考

✔️ 可运行项目：前端页面、自动化脚本、组件 Demo、小工具、简易应用……通通欢迎

✔️ 经验干货：Prompt 编写技巧、开发思路、踩坑复盘

✔️ 标配三件套：项目介绍 + 运行截图/视频 +项目地址（获奖概率飙升）

🎁 奖励清单

🥇 一等奖（3人）：SZCOOL 无线蓝牙音箱

🥈 二等奖（5人）：联想异能者笔记本散热器

🎉 基础奖：符合活动要求且话题帖互动 ≥5，再得5000矿石/人

🏅 评选标准

热度参考：根据沸点的点赞、评论、收藏数据作为基础参考。
官方评审：从创意（项目新颖度）、完成度（可运行性&功能完整）、干货价值（Prompt技巧&经验分享）三个维度综合打分。
综合考评：一二等奖由“热度+评审”综合得分排序产生。

项目不分大小，练手 Demo 也能大胆秀！

来沸点一起交流 Prompt 技巧，玩转 Vibe‑Coding，奖品矿石等你抱走～

现在就带话题发帖，下一个获奖者就是你！

☝️活动规则

无意义水评论、刷赞等违规行为，剔除获奖资格；
禁止引战/制造冲突/谩骂内容，或者发现引战内容剔除获奖资格；
本人发帖点赞/评论互动数据不计入互动量；
矿石将在申诉时间截止后 3 个工作日内发放；
活动最终解释权归稀土掘金所有；

不自己造轮子：在小艺开放平台搭一个真实的健康小助手

一只牛博 — Wed, 15 Jul 2026 05:19:43 GMT

之前一直是自己那台跑在 127.0.0.1 上的 Python 网关在撑场面。这次反过来，一行代码不写，看小艺开放平台自己能不能把一个能用的智能体从零跑起来。场景选了健康小助手：算体重、看一顿饭吃得怎么样、给点吃得更好的建议，都是手机健康 App 的老套路，拿这个来试平台的完整度，够用了。

新建项目，先卡在选哪种模式

小艺开放平台首页那句"鸿蒙智能全新升级，基于鸿蒙生态和 AI 大模型能力，为你提供鸿蒙智能体一站式开发解决方案"，第一眼看跟大多数产品首页的宣传语没什么两样。真进去点了才发现，这句话背后确实对应一整套从创建到调试的网页工具链。

点"新建项目"，顶上先要选智能体还是 Skill。侧边栏里 Skill 广场挂着一堆现成的能力，kuaidi100-user、fitness-coach、autonomous-tasks、news-extractor 这些，说明 Skill 更像是能被智能体调用的一个个功能模块，智能体才是真正跟用户对话的那个东西。这次做的是健康小助手，选智能体。

选完还有一层开发模式：端 A2A（HarmonyOS 应用里通过 AgentAbility 开发）、云 A2A（三方模型驱动）、云工作流（编排步骤清晰的业务）、OpenClaw（个人专属的 7×24 智能体）。OpenClaw 那个描述挺吸引人，翻文档才知道要求接入方是 HarmonyOS NEXT 真机，手上没有这台设备，只能放弃，选了云工作流模式。

选完云工作流，又弹出一层：单 Agent 模式还是多 Agents 模式。健康小助手就三件事，体重、饭菜、建议，逻辑谈不上复杂，用不上多智能体协作，选了单 Agent。这层选择最后落到编排页顶部一个不起眼的下拉框上，写着"LLM 模式"，如果不是一步步点过来，光看编排页面根本猜不出前面还套了两层选择。

名字和描述先填

进编排页之前要填名称和头像，"健康小助手"，头像用了默认的机器人图标，没细抠。

描述填的是"关注你的健康，体现我的价值"，13 个字。页面在旁边标了两处用法：智能体主页点"更多"会显示这段话，小艺广场搜索的时候它也会被当关键词检索。写的时候没想那么多，后来才反应过来，这句话其实决定了用户搜什么词能搜到这个智能体，跟随便写一句自我介绍不是一回事。

开场语、角色指令，填的时候右边就在预览

编排页里模型选的是 DeepSeek-V3 增强版，平台自带的选项，不用自己申请 API Key。这点跟自建 Gateway 那几篇比起来省心不少，那几篇每次截图前都要检查有没有不小心把 Key 露出来。

开场语：

你好，我是健康小助手。把你的身高体重告诉我，我能帮你看看体重是不是在正常范围；把你这顿饭吃了什么说给我听，我能帮你估算营养搭配，再给你一点吃得更好的具体建议。

配了三条开场引导，分别对应三项能力：

我身高170cm，体重68kg，这个体重正常吗？
帮我看看：一碗红烧肉盖饭配一杯奶茶，这顿饭健康吗？
我最近想瘦一点，帮我出一份一周晚餐的饮食建议。

填的时候右侧调试预览面板会同步渲染成对话气泡，能直接看到用户点开这个智能体第一眼看到的样子，这个即时反馈比自己写 ArkUI 页面再跑一遍 Previewer 快多了。

角色指令填在编排页中间那一栏，这次特意把能力边界写得跟能力清单一样详细，没有只堆功能：

你是"健康小助手"，帮助普通用户理解自己的身体指标和饮食情况，服务日常健康管理，不替代医生诊断。

你的核心能力：
1. 体重体脂分析：根据用户提供的身高、体重（可选年龄、性别），计算 BMI，说明所处区间（偏瘦/正常/超重/肥胖），给出简明解读。
2. 饭菜分析：根据用户描述的菜品，估算大致热量和主要营养构成（蛋白质/脂肪/碳水/蔬菜占比），指出这顿饭的优点和不足。
3. 饮食建议：结合前两项结果，给出可执行的饮食调整建议，兼顾口味和现实可行性，不要求用户吃极端节食餐单。

回答规则：
- 先给结论（比如 BMI 数值和区间），再给 1-3 条具体建议，不堆砌大段理论。
- 用户信息不全时，先友好追问缺失的关键信息（身高、体重、这顿饭具体吃了什么），不要凭空编数据。
- 涉及疾病、用药、极端节食等超出日常健康管理范围的问题，建议咨询医生或专业营养师，不给诊断性结论。
- 语言口语化、简洁，不用夸张营销话术，不用"亲""宝子"这类称呼。
- 不确定的估算要注明"估算"，不用绝对化语气呈现不确定的数据。

填完这两块，右上角"上架"提示从三项未完成降到两项未完成，剩下的估计是基础信息里还漏了什么，配置页那边再补。

提示词只是一小块，插件和知识库才是重头

角色指令往下翻，还有一堆东西。用户问题建议，打开后有系统配置 Prompt 和自定义 Prompt 两种，打开了它，回答完会自动带几条追问建议，用户不用自己想接下来问什么。往下是快捷指令（最多 30 条），背景图片，角色声音，再往下是插件（50）、工作流（20）、触发器（10）、关联应用（20）、知识库（10）、变量，最后是长期记忆，这项默认就是开着的。

这一整屏东西这次基本没碰。工具接入需要额外的授权和服务配置，这次的目标就是看纯提示词驱动能不能撑起一个可用的智能体，插件和知识库留白了，没打算装样子说都用上了。但看着这些选项摆在那儿，能感觉到如果真要往下做，接一个真实体重秤、接一份用户历史饮食记录，都是平台原生支持的路，不用自己另起炉灶写接口。

长期记忆默认开着这件事倒是没想到会顺手帮上忙——健康类对话本来就该记住用户报过的身高体重，不然每次问饮食建议都要重新说一遍，体验会很差。

上架前要过合规这一关

保存后进"配置"页，基础信息和隐私协议服务旁边有一栏内容合规，要如实回答两个问题：这个智能体是否包含人工智能生成的文件，是否接入了非小艺开放平台提供的三方大模型。旁边还有一段条款要勾选确认，写着要按《生成式人工智能服务管理暂行办法》《互联网信息服务深度合成管理规定》《人工智能生成合成内容标识办法》对上架的智能体做审视，隐瞒信息要担责任。

自己写那台 Python 网关的时候完全不会碰到这种东西，本机服务想怎么跑没人管。放到官方平台准备上架，这几部法规的名字直接印在表单上，接不接三方大模型这种细节也要如实报。

调试面板里问了两个问题

角色指令填完，直接在右边调试面板里试。第一句用的是开场引导第一条：

我身高170cm，体重68kg，这个体重正常吗？

3.916 秒后回来：

根据你的身高和体重，你的BMI是23.53，在正常范围内（18.5-23.9为正常）。不过，接近超重了，可以适当关注一下饮食和运动。

算出了具体的 BMI 数值，给了区间，还多说了一句"接近超重"，没有停在"体重正常"这四个字上敷衍过去。下面自动带出三条追问：哪些运动适合我减重、帮我分析如何控制体重、推荐一些健康饮食方案，点一条就能接着聊，不用自己重新组织问题。

第二句是开场引导第三条：

我最近想瘦一点，帮我出一份一周晚餐的饮食建议。

9.62 秒后拿到一份具体到每天菜名的七天计划，周一蒸鸡胸肉配西兰花糙米饭，周二烤鱼菠菜沙拉红薯，一路排到周日，末尾补了一句"这些建议都是低脂高蛋白，帮助你健康减重"。调试面板右上角还有个朗读入口，带自动播放声音的开关，回答生成后能直接听，这个东西自己那台网关短时间做不出来。

没测完的地方

角色指令里写了三项能力，实际调试只测过体重分析和饮食建议，两次都拿到了具体的、不是套模板的回应。第三项饭菜分析虽然配进了开场引导，但调试过程没问到这条，一碗红烧肉盖饭加奶茶到底会被分析出什么结果，现在还不知道，这里不拿写好的提示词冒充已经验证过的效果。角色指令里"涉及用药建议咨询医生"这条边界，也还没拿一个真的越界问题去试过，回答会不会真的被拦住，同样是没做完的部分。

这次全程没用本机的服务，也没写一行代码，从选开发模式到填角色指令，从内容合规声明到两次调试结果，证据都在小艺开放平台的网页控制台里。一个普通的个人开发者账号，没有真机，没有企业资质，能做到这一步。

Oracle 迁移评估时，我把这两类问题列在了检查清单最前面

一只牛博 — Wed, 15 Jul 2026 05:18:29 GMT

接手一个 Oracle 迁移评估任务时，大家习惯先看语法兼容性：这个存储过程能不能跑、这个函数有没有对应实现、这张视图的写法要不要改。这些问题好查，工具能扫，跑一遍报错日志就知道改哪。真正让人头疼的不是这些——是那些语法完全合法、迁移后照样能跑通、只是结果跟原来不一样的地方。这类问题不报错，不会出现在任何迁移报告的"失败项"里，只会在业务侧发现报表对不上、对账差了几行的时候才暴露出来，而且往往已经是上线之后了。

这次评估里踩到两个这样的问题，一个是外连接消除，一个是空字符串到底算不算 NULL。前者排第一，因为老系统里到处都是 (+) 写法的历史 SQL，谁都说不清当初是不是故意要保留左表全量；后者第二，因为它牵扯到"KES 跟 Oracle 到底像不像"这个问题本身没有固定答案，得看配置。环境是 KES V009R001C010，业务账号连接：

ksql -h 127.0.0.1 -p 54321 -U app_user -d app_db

先搭场景：客户表和客户等级表

create table app_schema.t_mig_customer (
  cust_id integer primary key,
  cust_name varchar(50) not null,
  grade_code varchar(10)
);

create table app_schema.t_mig_grade (
  grade_code varchar(10) primary key,
  grade_name varchar(30) not null,
  grade_level integer not null
);

insert into app_schema.t_mig_customer(cust_id, cust_name, grade_code) values
  (1, 'customer-a', 'G1'),
  (2, 'customer-b', 'G2'),
  (3, 'customer-c', null),
  (4, 'customer-d', 'G3');

insert into app_schema.t_mig_grade(grade_code, grade_name, grade_level) values
  ('G1', 'silver', 1),
  ('G2', 'gold',   2);

customer-c 从来没定过级，grade_code 是 NULL；customer-d 的 grade_code 是 G3，但等级表里压根没有 G3 这一级——这是很多老系统的常态，等级表维护跟不上业务扩张，历史数据里留着一堆对不上号的外键值。查"所有客户"的场景下，这两个客户理论上都应该被保留，只是等级信息显示为空。

陷阱一：`(+)` 语法本身没毛病，加个条件就变味了

先确认 KES 对 Oracle 这个老写法的兼容程度。(+) 标在哪一边，哪一边就是外连接里可以为空的一侧，最基础的写法：

select c.cust_id, c.cust_name, g.grade_name
from app_schema.t_mig_customer c, app_schema.t_mig_grade g
where c.grade_code = g.grade_code(+);

四个客户全部返回，customer-c、customer-d 的 grade_name 是空。这一步没什么好说的，(+) 语法接得很到位，老代码原样搬过来完全能用，这也是 KES 主打 Oracle 兼容的地方确实兑现了。

麻烦出在老系统里更常见的写法上：关联条件之外，业务上往往还要再加一层过滤，比如"只看正式定级（等级值大于等于 1）的客户"：

select c.cust_id, c.cust_name, g.grade_name
from app_schema.t_mig_customer c, app_schema.t_mig_grade g
where c.grade_code = g.grade_code(+)
  and g.grade_level >= 1;

只返回 2 行，customer-a、customer-b。customer-c、customer-d 不见了——这条 SQL 里明明写着 (+)，摆明了想要外连接的语义，结果却只剩下内连接才会有的行数。

跑一下执行计划确认这背后发生了什么：

explain analyze
select c.cust_id, c.cust_name, g.grade_name
from app_schema.t_mig_customer c, app_schema.t_mig_grade g
where c.grade_code = g.grade_code(+)
  and g.grade_level >= 1;

Hash Join，没有 Left 或者 Right 字样，纯内连接。原因不难理解：g.grade_level >= 1 这个条件是加在右表上的，customer-c、customer-d 对应的 g.grade_level 是 NULL，NULL >= 1 的结果是"未知"，在 WHERE 里等于被扔掉。既然这些因为外连接才该保留的行反正都会被这个条件滤掉，"外连接 + 这个过滤"和"内连接 + 这个过滤"结果完全一样，优化器就选了开销更小的内连接去跑——这就是外连接消除，跟 (+) 写没写没关系，(+) 只是外连接的一种写法，底层判断逻辑跟 ANSI 的 LEFT JOIN 是同一套。

为了确认这一点，把同样的逻辑换成 ANSI 写法再跑一遍，作为迁移验收阶段常用的排查方式：

explain analyze
select c.cust_id, c.cust_name, g.grade_name
from app_schema.t_mig_customer c
left join app_schema.t_mig_grade g
  on c.grade_code = g.grade_code
where g.grade_level >= 1;

同样是 Hash Join，同样没有 Left 字样，跟 (+) 写法的表现完全一致。这也提醒做迁移验收的人：不管老系统用的是 (+) 还是转译后的 LEFT JOIN，只要 WHERE 里对右表字段做了这种会把 NULL 判定为假的过滤，这个坑就跑不掉，光看语法转译对不对没用，得拿执行计划和行数说话。

修复办法是把这个过滤条件挪进关联条件里：

select c.cust_id, c.cust_name, g.grade_name
from app_schema.t_mig_customer c
left join app_schema.t_mig_grade g
  on c.grade_code = g.grade_code
  and g.grade_level >= 1;

四行全部回来，customer-c、customer-d 的等级字段照常显示为空。这不是换个位置随便试出来的，ON 决定的是"怎么连"，先按条件筛一遍右表再去外连接；WHERE 决定的是"连完之后再筛掉什么"，条件放这儿就已经是连接做完之后的事了，NULL 行躲不掉。

迁移验收阶段发现这类问题没有捷径：对每一条涉及外连接的存量 SQL，迁移前后的行数必须逐条比对，光看"能不能跑通"是不够的。

陷阱二：空字符串算不算 NULL，得看这一套环境怎么配置

这一节动笔之前，先把两件事确认清楚，不能凭"KES 内核衍生自 PostgreSQL"这种直觉去猜：

show database_mode;
show ora_input_emptystr_isnull;

database_mode 是 oracle，ora_input_emptystr_isnull 是 on。这套环境默认走的是 Oracle 兼容模式——很多人下意识觉得"内核是 PG 系的，行为应该跟 PG 一致"，这个假设在这里是不成立的，还是要先确定兼容模式，除非建库时特意指定成 PG 模式。而 ora_input_emptystr_isnull 这个参数，顾名思义就是用来复刻 Oracle 那个经典行为：把长度为零的字符串当成 NULL 处理。

实测验证一下：

insert into app_schema.t_mig_customer(cust_id, cust_name, grade_code)
values (5, 'customer-e', '');

select
  cust_id, cust_name, grade_code,
  grade_code is null as is_null_flag,
  length(grade_code) as code_len
from app_schema.t_mig_customer
where cust_id = 5;

插入的空字符串 ''，查出来 is_null_flag 是 t——被当成 NULL 存了，code_len 也是空白，不是 0。这跟很多人预想的"PostgreSQL 体系不会这样"正好相反，KES 在 Oracle 兼容模式下把 Oracle 这个特有行为原样复刻了下来。

对迁移读者来说，这其实是个好消息：如果老系统的 PL/SQL 或者业务代码依赖了"空字符串等于 NULL"这个假设（比如用 col = '' 判断"未填写"），只要迁移后的 KES 还在 Oracle 兼容模式下，这批代码不用改，行为跟原来一致。真正要小心的是反过来的情况——如果运维后续把数据库切换成 PG 兼容模式，或者手动关掉了这个参数，这批老代码会在没有任何报错的情况下悄悄失效。这也是这个坑最值得记住的地方：它不是一个写死的结论，是随兼容模式和参数走的，迁移评估阶段必须在目标环境里把这两项亲自确认一遍，不能凭经验预判。

迁移避坑清单

对所有涉及外连接（LEFT/RIGHT JOIN 或 (+)）的存量 SQL 做台账登记，迁移前先跑一遍拿到基准行数。
迁移后同样的 SQL 在 KES 上重跑，行数逐条比对，光凭"能不能跑通"判断不了对错。
审查 WHERE 子句里是否有对右表（Nullable 一侧）字段的过滤，且没有对称写 (+) 或没有下推到 ON。
迁移前先确认目标环境的 database_mode 和 ora_input_emptystr_isnull，把"空字符串算不算 NULL"这件事钉死，再决定这部分代码要不要改。
涉及财务、库存、审批类的判断逻辑，这两类问题都不会报错，只会悄悄改变结果，验收时间再紧也不能省这两项检查。

Vue 和 React 真正的差距，不在语法，而在团队犯错成本

ErpanOmer — Tue, 14 Jul 2026 09:39:25 GMT

前端圈的鄙视链里，一直流传着一个极其傲慢的错觉：写 React 的看不起写 Vue 的，认为前者更贴近底层，是真正的编程；而后者只是包了一层厚厚语法糖的玩具🫡。

每年的框架之争，大家都在喋喋不休地争论 JSX 是否比 Template 更灵活，或者 Hooks 是否比 Composition API 更纯粹。

但在真正带过几十人团队、给无数线上故障擦过屁股的前端架构师眼里，这些语法层面的争论，简直肤浅得不值一提🤷‍♂️。

在真实的业务交付战场上，评判一个框架的核心标准从来不是 它能让你飞得多高，而是 它能在别人犯蠢时，提供多厚的安全气垫。Vue 和 React 之间那条真正不可逾越的鸿沟，其实是团队的犯错成本。

极其自由的 React

React 的核心设计哲学非常迷人：一切皆为函数，一切皆为 JavaScript。

这种无与伦比的自由度, 你可以随心所欲地组装高阶组件，在渲染流里玩出各种花样。

但现实情况是，你手下的团队不是由十个顶级开发组成的。国内大多数业务线的现状是：开发的每一个环节都是流水线，团队里充斥着刚刚转正的新人、甚至外包同学。

把 React 交给这样一支水平参差不齐的团队，这种自由瞬间就会变成灾难。

在 React 里，想要写出一个能跑的页面很容易，但想要写出一个不乱重渲染、没有内存泄漏的页面，门槛极高。开发者必须时刻在大脑里与底层的渲染机制做斗争。你需要手动去判断什么时候该用 useMemo，什么时候该套 useCallback，甚至要时刻警惕那个反人类的 useEffect 依赖数组😖。

任何一个新手，只要少写了一个依赖，或者多传了一个匿名函数，你的页面就会陷入无限循环，或者彻底僵死在陈旧的闭包里。在 React 里，犯错的门槛实在太低了，但排查错误的成本却极其高昂。

依赖数组与自动追踪

我们来看一个在业务中每天都会上演的经典场景：根据传入的 userId 去拉取数据。

在 React 的世界里，新手极其容易写出下面这种代码：

// 表面看毫无问题的 React 代码，实则埋下了闭包陷阱
function UserDashboard({ userId }) {
  const [data, setData] = useState(null);
  
  // 容易漏写依赖，或者写错依赖导致无限循环
  useEffect(() => {
    fetchData(userId).then(setData);
  }, []); // 漏掉了 userId，导致父组件切换用户时，这里的数据永远不更新
  
  return (
    <div>
      <Header /> {/* 父组件状态一变，这个毫无关系的 Header 跟着白白重渲染 */}
      <UserProfile data={data} />
    </div>
  );
}

为了修补这些漏洞，你不得不强制团队去配置 ESLint 插件，甚至在 Code Review 时拿着放大镜去查依赖数组。这就是极其高昂的心智负担😒。

相比之下，Vue 在底层直接做了一次降维打击。它剥夺了你手动管理的自由，用底层的 Proxy 代理机制接管了一切。

<!-- Vue 用底层的依赖追踪，帮你兜底了绝大多数的心智负担 -->
<template>
  <div>
    <Header /> <!-- Vue 的细粒度更新，保证了 data 变化绝对不会波及 Header -->
    <UserProfile :data="data" />
  </div>
</template>

<script setup lang="ts">
import { ref, watchEffect } from 'vue';

const props = defineProps<{ userId: string }>();
const data = ref(null);

// 框架自动收集底层的依赖，根本不需要你手动去维护那个反人类的依赖数组
watchEffect(async () => {
  data.value = await fetchData(props.userId);
});
</script>

在这个场景下，Vue 的开发者甚至不知道什么是闭包。框架底层的响应式系统充当了最严厉的质量检测，无论新手的水平多差，这套机制都能保证代码在及格线以上稳稳运行。

React 考验的是开发者的内功，而 Vue 考验的是框架底层的工艺。

组件重新渲染引起的问题

如果说闭包只是前端的局部阵痛，那么全局重复渲染就是大型业务线的灾难。

React 的默认渲染逻辑极其粗暴：只要父组件的状态发生改变，所有子组件必须无条件跟着重新执行一遍。如果你不手动用 React.memo 把组件一层层包裹起来，一个顶层的数据状态更新，能让成百上千个毫无关联的底层组件跟着陪跑。

在真实的深水区业务中，当一个毫无经验的初级开发把一个高频更新的状态（比如页面的滚动位置）挂载到了顶层的 Context 时，整个应用的性能就会瞬间被榨干，哪怕你用着顶级配置的电脑，页面也会卡成 PPT。

而在 Vue 的世界里，这种页面崩溃是不存在的。

Vue 采用了细粒度更新的架构。通过编译时的静态分析和运行时的依赖收集，当一个状态发生改变时，Vue 精确地知道这个数据只绑定在了某几个具体的 DOM 节点上，只需要更新需要更新的地方即可。

这就意味着，即使你的团队里有人乱写逻辑，把状态满天乱飞，Vue 底层的防线依然能保证项目不至于彻底瘫痪。这就是架构层面的工程兜底。

咱们必须得承认团队的平庸🫡

技术圈往往有一种慕强心理，大家都觉得越难驾驭的工具越高级。

但真正的业务闭环是不认这些的。作为前端负责人，你的首要目标是保证业务按时上线，保证代码稳定运行，而不是证明你的团队个个都是 JavaScript 大师😒。

React 是一个非常灵活的前端框架，但稍微不慎会引起线上事故。它极度依赖严苛的团队规范和极高水平的 Code Review。

Vue 则是自带防误系统的。它虽然限制了你的语法写法，甚至有些语法看起来像是在写配置，但它把团队的下限拉到了一个极高的位置🙌。

如果你带领的是一支精英小队，去挑战极限的交互体验，React 绝对是不二之选。但如果你的团队成员水平参差不齐，且面临着高压的业务迭代，拥抱 Vue 是你的首选🫵。

框架从来没有好坏，适合你团队的才是最好的。

你们怎么看？

Codex 小白入门：从安装到插件、MCP、Skills，一篇把配置讲明白

ikoala — Tue, 14 Jul 2026 04:51:43 GMT

Codex 小白入门：从安装到插件、MCP、Skills，一篇把配置讲明白

最近老粉丝群里有不少同学一直催我：能不能出一篇 Codex 的基础教程，不要只讲“很强”“很好用”，而是把安装、配置、插件、Skills、MCP、记忆、连接 App 这些东西一次讲清楚。我理解这个需求。

我这边也有一些AI Coding（SDD Agent AI工具等）和 Node技术交流交流群，感兴趣的可以加微信 ikoala520 进群，一起学习，共同进步。

因为新手用 Codex 最大的问题，往往不是不会提问，而是不知道 Codex 的“几层配置”分别管什么。你可能已经装好了 Codex，也能让它改代码、写文章、解释报错，但一看到 config.toml、AGENTS.md、MCP、Plugins、Skills、Memory，脑子里马上变成一团线。这篇文章就解决这件事。

我不会把它写成官方文档翻译，也不会一上来堆一堆参数。我们按一个小白真正上手的顺序来：先装起来，再让 Codex 懂你的项目，然后一点点接上插件、MCP、Skills、记忆和 App。

先说明一下：Codex 更新很快。本文写作时，我本机验证的 CLI 版本是 codex-cli 0.140.0-alpha.2，时间是 2026 年 6 月 14 日。具体命令以你本机的 codex --help 和官方文档为准。本文重点讲方法和配置思路，命令只是帮你建立第一套可运行的骨架。

你先记住一句话

Codex 不是只有一个聊天框。

更准确地说，它像一个可以被你配置的工作台：

你要解决的问题	应该放在哪里
这一次任务的要求	当前对话 / prompt
这个项目长期遵守的规则	`AGENTS.md`
你的全局默认设置	`~/.codex/config.toml`
某类任务的标准流程	`Skills`
一组打包好的能力	`Plugins`
外部系统和工具接口	`MCP servers`
你的长期偏好	`Memory`
Gmail、GitHub、Chrome 这类真实应用	`Apps / Connectors`

很多新手一开始容易犯的错，是把所有东西都塞进 prompt。

比如你每次都对 Codex 说：“请先阅读项目结构，遵守我们的代码规范，运行测试，不要乱改文件，写完给我总结。”

这当然能用，但很累。更好的方式是把长期规则沉淀到 AGENTS.md，把默认行为放到 config.toml，把重复工作流写成 Skill，把外部能力交给 MCP 和插件。

这样 Codex 才会从“一个会回答问题的窗口”，变成“一个适合你工作流的助手”。

第一步：先把 Codex 装起来

Codex 现在有几种常见使用方式。

入口	更适合谁	你可以怎么理解
Codex CLI	程序员、经常在终端工作的人	在项目目录里直接让 Codex 读代码、改代码、跑命令
Codex Desktop App	想用图形界面、插件、连接 App 的人	更像一个完整工作台
IDE 扩展	长时间待在编辑器里的人	让 Codex 跟你的代码编辑环境贴近
Cloud / Web 任务	想把任务交给云端跑的人	适合并行处理或长任务

如果你是小白，我建议从 Codex Desktop App + CLI 这套组合开始。桌面 App 适合看插件、连接 App、管理线程；CLI 适合进入具体项目干活。

1. Codex Desktop App 怎么安装

桌面 App 的官方入口是：

https://developers.openai.com/codex/app

如果你想直接下载安装包，也可以按系统选择：

macOS Apple Silicon：下载 Codex.dmg
macOS Intel：下载 Codex-latest-x64.dmg
Windows：通过 Microsoft App Installer 安装

对应直达地址如下：

macOS Apple Silicon:
https://persistent.oaistatic.com/codex-app-prod/Codex.dmg

macOS Intel:
https://persistent.oaistatic.com/codex-app-prod/Codex-latest-x64.dmg

Windows:
https://get.microsoft.com/installer/download/9PLM9XGG6VKS?cid=website_cta_psi

macOS 安装步骤很简单：

先确认自己的芯片类型。点左上角苹果图标，选择“关于本机”，看芯片是 Apple Silicon 还是 Intel。
下载对应的 .dmg 文件。
双击打开安装包，把 Codex 拖到 Applications / 应用程序。
打开 Codex App，按提示登录 OpenAI 账号。
如果 macOS 提示安全确认，在系统设置里允许打开。

Windows 安装步骤也类似：

打开 Windows 下载地址。
按 Microsoft Store / App Installer 的提示安装。
安装完成后启动 Codex。
登录 OpenAI 账号。
在 App 里检查插件、连接器和本地工作区权限。

如果你已经装了 CLI，也可以在终端里运行：

codex app

这个命令会启动 Codex Desktop App。如果本机还没装 App，它会引导你去安装。

2. Codex CLI 怎么安装

CLI 的官方入口是：

https://developers.openai.com/codex/cli

现在更推荐用官方 standalone installer。macOS / Linux 可以这样安装：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Windows PowerShell 可以这样安装：

irm https://chatgpt.com/codex/install.ps1 | iex

如果你习惯用包管理器，也可以选下面几种方式：

# npm
npm install -g @openai/codex

# Homebrew
brew install --cask codex

如果你想手动下载二进制文件，可以去 GitHub Releases：

https://github.com/openai/codex/releases

装好 CLI 以后，先跑这几个命令：

codex --version
codex login
codex doctor

codex login 用来登录账号。

codex doctor 用来检查本地安装、配置、认证和运行时健康状态。新手遇到“为什么不能用”“为什么工具不生效”“为什么 MCP 连接不上”时，先跑它，比直接猜原因靠谱。

你还可以看完整命令：

codex --help

我本机看到的常用命令包括：

命令	用途
`codex`	启动交互式 CLI
`codex exec`	非交互执行一次任务
`codex review`	做代码审查
`codex login` / `logout`	管理登录
`codex doctor`	诊断环境
`codex mcp`	管理 MCP server
`codex plugin`	管理插件
`codex app`	启动桌面 App
`codex update`	更新 Codex

你不用一开始全记住。小白阶段只要记住：

codex
codex login
codex doctor
codex --help

够用了。

第二步：理解 `AGENTS.md`

如果只能先学一个配置文件，我建议先学 AGENTS.md。

它的作用很简单：告诉 Codex，这个项目该怎么工作。

比如项目怎么启动、怎么测试、代码风格是什么、哪些目录不要乱动、提交前要跑什么命令、回答时要注意什么。你可以把它理解成“写给 AI 同事看的项目说明书”。

一个最小版本可以这样写：

# AGENTS.md

## Project overview

This is a Next.js project. The main app is in `apps/web`.

## Common commands

- Install dependencies: `pnpm install`
- Start dev server: `pnpm dev`
- Run typecheck: `pnpm typecheck`
- Run tests: `pnpm test`

## Coding rules

- Follow existing file structure and naming style.
- Prefer small, focused changes.
- Do not rewrite unrelated files.
- Do not add new dependencies unless necessary.

## Verification

Before saying the task is complete, run the relevant check:

- UI changes: run `pnpm typecheck`
- Logic changes: run related tests
- Large changes: run `pnpm test`

If a command was not run, say it clearly.

这里最关键的不是写得多，而是写得准。

我建议你在 AGENTS.md 里优先放四类内容：

内容	示例
项目结构	前端在哪里、后端在哪里、配置在哪里
常用命令	安装、启动、测试、构建
编码约束	不要改哪些文件、用什么风格、怎么命名
验收方式	什么情况下跑类型检查，什么情况下跑测试

有的小伙伴可能会问：这些东西为什么不直接写在 prompt 里？

因为 prompt 是临时的，AGENTS.md 是长期的。你今天让 Codex 改登录，明天让它改列表，后天让它写测试，这些任务都应该遵守同一套项目规矩。把规矩写进 AGENTS.md，后面就不用每次重复念一遍。

第三步：理解 `config.toml`

AGENTS.md 管“项目规矩”，config.toml 管“Codex 自己怎么运行”。

最常见的位置是：

~/.codex/config.toml

它通常用来配置模型、沙箱、审批策略、MCP、profile、环境变量策略等内容。

你也可以临时覆盖配置。比如 CLI 帮助里可以看到这种写法：

codex -c model=\"o3\"
codex -c 'sandbox_permissions=[\"disk-full-read-access\"]'
codex -c shell_environment_policy.inherit=all

这说明一个重要思路：config.toml 是长期默认值，-c 是本次临时覆盖。

小白阶段，不建议一上来改很多。你可以先理解这几个配置方向：

配置方向	你应该怎么理解
model	默认使用哪个模型
sandbox	Codex 跑命令时能访问哪些文件
approval	哪些操作需要你确认
MCP	外部工具怎么接进来
profiles	给不同场景准备不同配置
features	开启或关闭某些实验能力

举个偏保守的理解方式：

# ~/.codex/config.toml

# 示例：按你账号和当前 Codex 版本可用模型调整
model = "o3"

# 新手建议不要急着开到最高权限。
# 真正需要全权限时，再在可信项目里单独开启。
sandbox_mode = "workspace-write"

# 是否需要人工确认，取决于你的使用场景。
# 日常交互可以保守一点，自动化脚本可以更明确地限制。
approval_policy = "on-request"

不同版本字段可能会有变化。如果你打开后发现字段名不一样，不要慌，先看：

codex --help
codex doctor

以及你当前 Codex 版本对应的官方文档。

这里有一个很实用的经验：别把新手配置成 danger-full-access 起步。

danger-full-access 很强，但也意味着 Codex 执行命令时拥有非常大的文件系统权限。它适合你非常信任当前工作区、并且知道自己在做什么的场景。刚开始用的时候，先用较保守的沙箱和审批策略，熟悉之后再逐步放开。

第四步：Plugins 是什么

很多人听到插件，以为就是“多一个按钮”。

在 Codex 里，插件更像一个能力包。一个插件里可能包含：

一个或多个 Skills
MCP server 配置
App / Connector 能力
脚本、资源、模板
插件自己的说明和元数据

你可以用命令查看插件相关能力：

codex plugin --help

常见子命令包括：

codex plugin list
codex plugin add <plugin>
codex plugin remove <plugin>
codex plugin marketplace list

安装插件时，命令形态大概是：

codex plugin add sample@debug
codex plugin add sample --marketplace debug

如果你使用桌面 App，也可以在插件入口里搜索、安装、启用。

小白阶段，我不建议你一口气装一堆插件。你可以按工作流选：

你的场景	优先考虑
写代码、看 PR	GitHub、Browser、Chrome
写文章、报告	Documents、Browser、Data Analytics
做 PPT	Presentations
处理表格	Spreadsheets
做产品和界面	Product Design、Figma、Browser
操作网页或桌面	Chrome、Computer Use

插件的价值，不是“看起来很高级”，而是让 Codex 能接触真实材料、调用真实工具、交付真实文件。

比如你装了 GitHub 相关插件后，它不只是告诉你“应该怎么 review”，而是可以读取 PR、看评论、查 CI、给出修改建议。你装了 Presentations，它不只是写 PPT 文案，而是能生成真正的演示稿文件。

这就是插件和普通 prompt 的差别。

第五步：Skills 是什么

Skills 很适合小白理解成：把一套固定做事方法写成文件。

比如你经常写公众号文章，每次都要经历：

定选题
查资料
搭大纲
写初稿
做配图
预览
改节奏

如果每次都在 prompt 里说一遍，很麻烦。你可以把这套流程写成一个 SKILL.md，以后只要任务匹配，Codex 就能按这个方法走。

Codex 的Skills 的位置在，注意是在这里~/.codex/skills

一个 Skill 通常长这样：

---
name: ai-article-writer
description: Use when writing long-form AI technical articles.
---

# AI Article Writer

## Workflow

1. Clarify the target reader and article angle.
2. Collect reliable references.
3. Propose title options and outline.
4. Draft the article in Markdown.
5. Add diagrams when useful.
6. Render a local preview.
7. Review readability before final delivery.

注意，Skill 不是单纯的 prompt 模板。

它更像一套“操作规程”。好的 Skill 会告诉 Codex：

要素	说明
什么时候使用	`description` 写清楚触发场景
怎么做	明确步骤
用哪些资料	引用相关参考文件
用哪些脚本	复用已有脚本，而不是每次重写
怎么验收	最后检查什么

那 Skill 和 AGENTS.md 有什么区别？

很简单：

文件	适合放什么
`AGENTS.md`	这个项目长期遵守的规则
`SKILL.md`	某一类任务的标准做法

比如“这个项目用 pnpm，不要用 npm”，应该放 AGENTS.md。

比如“写公众号文章前必须先做选题定位，再写大纲”，应该放 Skill。

第六步：MCP 是什么

MCP 全称是 Model Context Protocol。你可以先不用记英文，只要记住它解决的问题：

让 Codex 通过标准协议连接外部工具和数据源。

比如：

MCP 能连接什么	典型用途
GitHub	读取 PR、Issue、文件、CI
数据库	查询业务数据
文档系统	读取团队知识库
浏览器	打开页面、检查 UI
搜索服务	查找外部资料
内部系统	调用你们自己的工具

在 CLI 里可以用：

codex mcp --help

我本机看到的常用子命令包括：

codex mcp list
codex mcp get <name>
codex mcp add <name> --url <url>
codex mcp add <name> -- <command>
codex mcp remove <name>
codex mcp login <name>
codex mcp logout <name>

添加 MCP server 有两种常见方式。

第一种是 HTTP 方式：

codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp

第二种是本地命令方式：

codex mcp add my-tool -- node server.js

如果需要环境变量，也可以看到类似这种形式：

codex mcp add my-tool --env API_KEY=$MY_TOOL_API_KEY -- node server.js

实际使用时，不建议把真实密钥直接写在命令里。更好的方式是放在环境变量中，或者使用 Codex / MCP 支持的安全配置方式。

如果以上cli你都不喜欢，也可以通过codex桌面端安装和使用mcp

小白理解 MCP，可以抓住一个判断标准：

凡是 Codex 需要读取外部系统、调用外部工具、访问实时数据，就优先想 MCP 或 App Connector。

不要让模型凭记忆回答你的私有数据。

比如你问：“我们项目最近哪个 PR 没过 CI？”

这类问题不应该让 Codex 猜，也不应该让你复制粘贴一堆网页内容。更合理的方式是接 GitHub，然后让 Codex 直接读取真实 PR 和检查结果。

第七步：Memory 记忆功能怎么用

Memory 很容易被误解。

它不是让 Codex 记住所有事实，也不是你的私人数据库。它更适合记住长期偏好和稳定习惯。

适合放进 Memory 的内容：

适合记	示例
写作偏好	我喜欢中文技术文章，风格实战、少空话
常用工作方式	修改代码后要跑 typecheck
长期称呼偏好	回答我时用中文
稳定背景	我经常写公众号 AI 工具文章

不适合放进 Memory 的内容：

不适合记	原因
密码、token、密钥	安全风险太高
今天的新闻	很快过期
某个 PR 当前状态	应该从 GitHub 实时读取
临时任务要求	放当前对话就够了

一句话：Memory 记偏好，不记事实；记习惯，不记机密。

如果你希望 Codex 长期记住“我写文章喜欢实战风格”，放 Memory 很合适。

如果你希望 Codex 知道“这个项目怎么启动”，放 AGENTS.md 更合适。

如果你希望 Codex 知道“GitHub 上这个 PR 当前是否通过 CI”，那应该接 GitHub App 或 MCP。

第八步：怎么连接 App，让 Codex 真正操作起来

Codex 的强大，不只是能写答案，而是能连接真实工具。

常见 App / Connector 包括：

App / Connector	能做什么
GitHub	读仓库、看 PR、查 Issue、处理 review
Gmail	搜索邮件、总结线程、提取待办、起草回复
Google Drive / Docs	读取文档、整理资料
Figma	读取设计稿、辅助设计到代码
Browser	打开网页、测试本地页面、截图验收
Chrome	使用你的 Chrome 登录状态操作网页
Computer Use	操作本地桌面应用

这里要分清楚两个概念：

类型	更像什么
MCP	标准协议接口，适合工具和数据源
App / Connector	已授权的真实应用连接

举个例子，你要让 Codex 看 GitHub PR，有几种可能：

通过 GitHub 插件
通过 GitHub App / Connector
通过 MCP server
通过 gh CLI

它们不是互斥的。实际工作中，Codex 往往会优先使用当前环境里已经可用、权限合适、最稳定的入口。

小白阶段，你只要记住一个安全原则：读取可以更自动，写入必须谨慎。 比如读取 PR、总结邮件、打开网页，一般风险较低。

但发送邮件、提交表单、删除文件、发布文章、改权限、付款、发消息，这些动作一定要让 Codex 先停下来给你确认。把 AI 当成有人监督的助手，而不是完全放飞的机器人。

小白第一次配置，按这个顺序来

别一开始就追求“全配满”。

更好的顺序是：

你可以按下面这套路线走：

安装 Codex，完成登录。
运行 codex doctor，确认环境正常。
在项目根目录写一个简单的 AGENTS.md。
只改必要的 config.toml，先别开太多高权限。
先接一个最常用的插件，比如 GitHub 或 Browser。
如果你经常重复某类任务，再写 Skill。
需要外部数据时，再配置 MCP。
最后再考虑把长期偏好放进 Memory。

这套顺序的好处是，你每一步都能验证。

很多人一上来装十几个插件、配五六个 MCP、写一大堆全局规则，最后出问题时根本不知道是哪一层坏了。小白阶段最重要的不是炫技，而是能定位问题。

给你一套基础配置模板

下面这套模板可以作为起点，不建议无脑复制到所有项目里，但你可以按自己的项目改。

1. 项目根目录 `AGENTS.md`

# AGENTS.md

## Project overview

Briefly describe what this project does and where the main code lives.

## Common commands

- Install: `pnpm install`
- Dev: `pnpm dev`
- Typecheck: `pnpm typecheck`
- Test: `pnpm test`
- Build: `pnpm build`

## Working rules

- Read existing code before editing.
- Keep changes focused on the requested task.
- Do not rewrite unrelated files.
- Follow existing naming and style.
- Ask before adding new dependencies.

## Verification

Before marking work complete:

- Run the most relevant check.
- If checks cannot run, explain why.
- Do not claim tests passed unless they were actually run.

2. 全局 `config.toml`

# ~/.codex/config.toml

# Pick the model you normally want Codex to use.
# 示例：按你账号和当前 Codex 版本可用模型调整
model = "o3"

# Conservative default for local coding work.
sandbox_mode = "workspace-write"

# Let Codex ask when it needs permission for sensitive operations.
approval_policy = "on-request"

# You can add MCP servers below when needed.
# [mcp_servers.example]
# command = "node"
# args = ["server.js"]

如果你的 Codex 版本提示字段不识别，先不要硬改，跑：

codex doctor
codex --help

再根据当前版本调整。

3. 一个最小 Skill 模板

---
name: project-review
description: Use when reviewing a feature implementation before merge.
---

# Project Review

## Workflow

1. Read the requirement or issue.
2. Inspect changed files.
3. Look for bugs, regressions, missing tests, and risky assumptions.
4. Run or recommend relevant verification commands.
5. Report findings first, then summarize.

## Output

- Findings with file references.
- Test gaps.
- Suggested next steps.

4. MCP 添加命令模板

# HTTP MCP server
codex mcp add <name> --url <server-url>

# Local stdio MCP server
codex mcp add <name> -- <command> <args>

# Check configured MCP servers
codex mcp list

这里最重要的是 <name> 要起得清楚，比如 github、docs、postgres-readonly，不要叫 test1、abc。后面排查问题时，清楚的名字会救命。

常见坑

1. 把 `AGENTS.md` 写成散文

AGENTS.md 不是给人看的项目宣传稿，而是给 Codex 执行任务时用的操作说明。少写愿景，多写命令、约束和验收方式。

2. 一开始就开最高权限

新手刚开始不要追求“无确认自动跑完”。AI 工具越能操作真实系统，越要有边界。先用保守权限跑通工作流，再根据需要放开。

3. MCP 配好了但忘了验证

配完 MCP 后，先跑：

codex mcp list
codex doctor

能列出来只是第一步，真正任务里能不能调用，还要看认证、网络、权限和 server 本身是否正常。

4. 插件装太多

插件不是越多越好。你真正需要的是工作流。

如果你每天都写代码，先把 GitHub、Browser 这类接好。如果你每天写文章，先把 Documents、Browser、图片生成或预览流程跑通。装一堆不用的插件，只会让你更困惑。

5. 把 Memory 当事实库

Memory 适合记偏好，不适合记实时事实。项目状态、PR 状态、数据库数据、新闻变化，都应该从真实来源读取。

6. 不区分“读”和“写”

让 Codex 读取资料、总结内容、检查页面，风险通常较低。

让 Codex 发送邮件、发布文章、删除文件、提交表单、改权限，风险就高很多。涉及外部副作用的动作，最好都让它先停下来确认。

我自己的建议

如果你刚开始用 Codex，我建议先别急着研究所有高级配置。

第一周只做三件事：

每个项目补一个 AGENTS.md。
学会用 codex doctor 排查问题。
只接一个你最需要的插件或 App。

等你发现某个任务每周都在重复，比如写文章、review PR、整理周报、做 PPT、查数据，再把它沉淀成 Skill 或插件工作流。

Codex 真正厉害的地方，不是你一次 prompt 写得多华丽，而是你能把自己的工作方式一点点沉淀下来。今天写进 AGENTS.md 的项目规则，明天接上的 GitHub，后天固化成 Skill 的写作流程，都会让它越来越像你的工作台。

对小白来说，最好的入门路线不是“学完所有概念再开始用”，而是先跑起来，再把反复出现的问题放到正确的位置。

这篇文章你如果只记住一张图，就记住前面的七层配置地图：

临时需求放对话，项目规则放 AGENTS.md，运行默认值放 config.toml，重复流程放 Skills，外部能力交给 Plugins、MCP 和 Apps，个人偏好再放进 Memory。

把这几层分清楚，Codex 就不再是一堆陌生名词，而是一套你能慢慢搭起来的 AI 工作系统。

我这边也有一些AI Coding（SDD Agent AI工具等）和 Node技术交流交流群，感兴趣的可以加我微 ikoala520 进群，一起学习，共同进步。

参考资料

OpenAI Codex 官方文档：developers.openai.com/codex
Codex Desktop App：developers.openai.com/codex/app
Codex CLI：developers.openai.com/codex/cli
Codex GitHub Releases：github.com/openai/code…
npm @openai/codex：www.npmjs.com/package/@op…
Codex CLI 本机帮助：codex --help
Codex MCP 命令帮助：codex mcp --help
Codex 插件命令帮助：codex plugin --help
Model Context Protocol：modelcontextprotocol.io

Agent 开发主流 skills推荐

Jasper_L — Tue, 14 Jul 2026 04:32:40 GMT

🔧 通用工程流（几乎必装）

1. Superpowers（obra/superpowers）

结构化软件工程工作流框架，不是单一 Skill，而是一整套 Agent 方法论：brainstorming → writing plans → TDD → debugging → code review → verification，复杂任务还能拆给子代理并行推进。

# Claude Code
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# 通用（Cursor/Claude Code 都支持）
npx skills add https://github.com/obra/superpowers -g -a cursor -a claude-code -y

💡 Claude Code 用户首推这个；Cursor 用户也可以装，但同源的 systematic-debugging、test-driven-development不必重复装。

2. spec-driven（tlc-spec-driven）

项目级四阶段：Specify（模糊需求→结构化规格）→ Design（数据模型/API/认证）→ Tasks（原子任务拆解）→ Implement（逐个实现 + 验证），中间断开也能从上次位置续上。

npx @tech-leads-club/agent-skills install -s tlc-spec-driven -a claude-code

3. 内置/经典 slash 级（Claude Code 自带或可单独装）

/commit— 按 staged changes 生成 conventional commit
/create-pr— 读 diff 写 PR description 并推送
/review— 代码审查（bug / 安全 / 风格）
/security-audit— 深度安全审计（OWASP Top 10 向）
/test— 按实现生成单测
/architect— 给定需求做系统设计再动笔
/refactor— 带目标的重构

这些属于"每天都能用"的，建议先把内置的玩熟，再考虑覆盖自定义版本。

🎨 前端 / 设计向

4. frontend-design（Anthropic 官方）

专治 AI 生成页面"千篇一律"的毛病——强制 bold 排版 + 非常规布局，避免 generic UI 。

5. taste-skill（Leonxlnx/taste-skill）

13 合集，前端向最有用的是 design-taste-frontend（强制设计规范）+ minimalist-skill+ output-skill（强制完整可运行代码，无占位）。还有 imagegen-frontend-web/mobile、brandkit、moodboard做视觉素材。

npx skills add https://github.com/Leonxlnx/taste-skill
# 或只装核心
npx skills add https://github.com/Leonxlnx/taste-skill --skill design-taste-frontend

6. ui-ux-pro-max（nextlevelbuilder）

输入"做个 SPA 落地页"，它会推理行业→配色→字体→反模式提示，交付前还出检查清单（emoji 不能当图标、hover 状态要完整这类细节）。

🛡️ 安全向

7. Anthropic Cybersecurity Skills（mukul975/Anthropic-Cybersecurity-Skills）

817 个安全技能，覆盖威胁情报 / 漏洞管理 / 渗透测试 / 事件响应 / 合规审计 / 云安全 / AI 安全，每个技能映射到 MITRE ATT&CK、NIST CSF 2.0、D3FEND、NIST AI RMF、MITRE F3、MITRE ATLAS 六大框架。

npx skills add mukul975/Anthropic-Cybersecurity-Skills

装完后直接对 Agent 说："按 MITRE ATT&CK 检测过去 7 天横向移动（T1021.001, T1570）"，它会自动加载对应 SKILL.md 按步骤干。

8. Trail of Bits（真实安全公司出品）

CodeQL + Semgrep + 审计工作流，Verified 级。

🔬 科研向

9. Scientific Agent Skills（K-Dense-AI/scientific-agent-skills）

138 个科研技能，17 个领域（基因组学 / 药物发现 / 临床变异 / 单细胞 RNA-seq 等），直连 100+ 数据库（PubChem、ChEMBL、UniProt…），集成 70+ Python 包（RD-py、Scanpy、BioPython、OpenMM）。

npx skills add K-Dense-AI/scientific-agent-skills

🔌 垂直工具向（Cursor Marketplace 为主）

这类不是 SKILL.md标准包，而是 Cursor 的 Plugin / MCP 形态，但效果类似——让 Agent 懂某个垂直工具：

Composio — 1000+ SaaS 集成（OAuth + 结构化 action），一站打通
Shopify — 搜文档 + 生成校验 GraphQL / Liquid / UI 扩展
RevenueCat / Chargebee / Airwallex — 支付计费向
ParadeDB — Postgres 里做 Elastic 级搜索（BM25 / 向量）
Dagster — 数据编排
Asana / Monday.com / Merge — 企业协作（Jira / Salesforce / Slack 等几百种）

📦 安装方式速记

载体	路径 / 命令
Claude Code 内置 slash	`.claude/commands/*.md`，文件名即 `/command`
Claude Code npx 装第三方	`npx skills add <repo>`或 `/plugin marketplace add`
Cursor	`.cursor/skills/*.md`或 Cursor Marketplace 一键装
通用（跨 Agent）	遵循 `SKILL.md`标准，写一次 Cursor/Claude Code/Codex/Gemini CLI 都能吃

🎯 新手推荐组合

如果你是第一次装，建议这个"起步包"就够用：

superpowers（工程流骨架）
spec-driven（项目级需求→实现）
frontend-design 或 taste-skill（做前端时）
/security-audit 或 Cybersecurity Skills（安全向）

我和一个德国程序员互不知道对方，却写出了完全一样的AI架构 🤯

YuhaoLin2005 — Mon, 13 Jul 2026 17:31:02 GMT

他32岁，在德国写npm包。我21岁，在中国找实习。我们在同一个月份，从完全不同的起点，造出了架构上完全相同的东西。这不是协同合作。这是AI界的"平行发明"——两个天各一方的工程师，面对同一个数学约束，得出了同一个工程答案。

📖 事情是这样的

我在DEV.to上发了5篇技术文章，讲我如何给AI agent装"规则门"——用文件系统检查、退出码、正则表达式来确保agent真的在遵守规则，而不是只在聊天框里说"好的我懂了"然后什么都不做。

然后一个叫René Zander的德国开发者在评论区甩了个链接：skillgate，一个npm包（@reneza/skillgate），做的是完全一样的事情。

我点进去看了。然后我愣住了。

🤝 两个人，同一个约束，同一个答案

先看架构对比：

设计维度	René的skillgate	我的paper-validator
核心理念	"模型请求，框架拥有边界"	"生成和验证共享同一个分布P(token\|context;θ)，所以自我验证不可靠"
检查方式	文件系统纯函数	文件系统+正则表达式+退出码
模型参与	零——模型不在检查回路中	零——机械门层模型不在回路中
门类型	file-exists, file-contains, absent, command, evidence, instruction-sync	HealthChecker, QualityGate, WriteGuard, RegenerationValidator
发布形式	npm包，生产级	Python模块，CLI+MCP+原生导入
独立收敛日期	2026年7月	2026年7月

注意：我们在同一个月份，从完全不同的起点（他在德国做npm包，我在中国写毕业论文），得出了架构上完全相同的解决方案。

这不可能只是巧合。

💡 为什么两个人会独立发明同一个东西？

因为这个约束是结构性的，不是风格偏好。

LLM验证自己的输出，就像让考生自己批改自己的考卷——他用的还是同一个脑子里的同一套知识。没有外部标准，没有独立检查。这就是为什么"自我验证"在结构上就不可靠——我把这叫做Prose Barrier（散文壁垒）。

René的说法不同但意思一样："一个门只有在agent无法影响的独立进程中才可信。"

对于我们两个来说，数学指向同一个工程结论：规则必须用代码而非自然语言编写，且在模型的生成回路之外运行。 如果能说服模型违反规则，那就不是规则——只是建议。

这不是哲学。在我跑过的200次试验（P1-1，后面会讲）中：机械门能覆盖的地方，违规率为零。每一条都为零。

🏗️ 哪里不同（以及为什么这很重要）

skillgate是生产级、静态、可发布的。它做一件事且做得很好：在agent的输出上运行确定性检查。René的instruction-sync gate——跟踪CLAUDE.md、AGENTS.md和.cursor/rules之间的漂移——是我之前没想到的，我打算采用。

我的系统多了四层：

L0 安全层      L1 机械层        L2 神经层         L3 因果层          L4 漂移层
"安全输出？"    "信息到了吗？"    "它穿透了吗？"    "格式路由注意力？"  "何时会漂移？"
───────────────────────────────────────────────────────────────────────────────
预加工生成      文件系统检查      令牌概率指纹       格式→注意力         趋势→预测

完整的5层架构，skillgate覆盖L1

🔒 L0 安全层：预加工生成——如果模型因"听起来自信"而被奖励，不确定性就被压制了。一个显式的安全提示（"说'我不知道'不会被惩罚"）在生产前就改变了前提条件。

✅ L1 机械门：skillgate覆盖的层——文件系统检查、退出码、正则表达式。完全绕过Prose Barrier。不读模型写的内容，只检查文件是否存在、时间是否新、退出码是否为零。

🧠 L2 神经门：skillgate检查输出。神经门检查内部处理过程。如果你在决策令牌处测量约束条件是否改变了logprob分布，你能看到规则是真的改变了模型的"想法"，还是只改变了措辞。d=+0.578，贝叶斯因子=282,399。DeepSeek实测。

🔗 L3 因果编码：对于推理质量，三段论规则（IF-THEN-THEREFORE）和祈使规则（MUST DO）哪个更好？答案：都不是——散文规则更好。散文的推理优势比代码规则高出恒定的~0.25 SD，且与门的状态无关。代码+门=完美合规+最浅推理。我把这叫做"清单心态"。

🔮 L4 漂移预测：12个特征，34个会话的基线数据。在行为退化可见之前发出警告。已构建，预测性验证待定。

这些额外的层是"学术上好玩"还是"实践上有用"——还不确定。但我不会假装知道。这就是为什么我把所有内容都做成了可复现的实验，放在paper-validator里——一条命令即可运行审计：python -m paper_validator claim --claim all --trials 30。

🔥 为什么你应该关心这件事

当两个人在不知道对方工作的情况下，独立发明了同一个东西，说明了几件事：

🔥 问题不是虚构的。 AI agent确实会漂移。它们确实会跳过验证。说得天花乱坠却不行动。不是只有我一个人碰到。

🔥 解决方案正在收敛。 确定性文件系统检查，位于模型控制回路之外——这是正确的架构。不是品味问题。是工程必要性。

🔥 整个领域仍处于早期阶段。 我们仍在争论agent是否应该用[THINK]:标签。五年后回头看，会觉得像争论HTML是否应该用<table>做布局一样。

🔥 你可以直接试用。 skillgate是npm上的生产级代码。paper-validator是可复现的研究代码（Python stdlib + requests，没别的依赖）。如果愿意忍受不完美的边缘情况，两个都能跑。

📬 真实情况

DEV.to上的评论区——Mike Czerwinski、Dipankar Sarkar、Max Quimby、René Zander——不是那种"好文！"的水评论。他们问的是我真没想过要测的东西。

所以我测了。440次API调用。两次全新实验。一次假设被证明是错的。两次都教会了我一些东西。

论文、数据以及全部补充分析在这里：github.com/YuhaoLin200…。独立验证工具在这里：github.com/YuhaoLin200…。

如果你也在做这个方向——确定性验证、agent漂移监控、格式工程——或者你觉得数据里有不对的地方，我真的很想听听。P1-1和P1-2实验之所以存在，就是因为Mike问了我没想过要问的问题。

💬 如果这个方向也是你正在做的，评论区聊聊你的方案。 你是用文件系统检查还是别的思路？你的agent有没有出现过"嘴上答应、实际不做"的情况？留言告诉我，我也想看看大家的解法。可以的话点个赞+收藏，后续实验数据我会继续发在这边。

50+会话的数据。13个实验。一台笔记本。我的论文指导老师是我自己的AI agent。

👋 林宇浩 — FAFU空间信息大三，找2026暑期实习中

为啥说男生找对象尽量在25岁前找到？

AsherJ — Mon, 13 Jul 2026 12:38:53 GMT

先说说结论，催婚的长辈是不可能讲明白为啥要 25 岁前。我替他们算一遍。

把”一个男生认真考虑恋爱”的窗口期粗略设成 18~35 岁，共 17 年。

代入 1960 年由数学家 Merrill Flood 提出的”秘书问题”最优解——通俗叫法是 37% 法则——你应该先只看不选前 37% 的时间，记住这段时间里遇到的最好的那个；然后从第 37% 开始，遇到第一个比之前所有人都更好的，立刻拍板。

观察期 = 17 × 0.37 ≈ 6.3 年
拐点    = 18 + 6.3 ≈ 24.3 岁

也就是说：

24 岁以前：在收集样本、建立标准的阶段，遇到再好的也不该锁死。
24.3 岁之后：进入决断窗口，遇到一个超过你过去 6 年所有人的，立刻 commit。
拖到 30 岁还在挑更好的：大概率会被迫接受最后一个出场的人——也就是窗口期内的”最后一根稻草”。

“25 岁前找对象”这句话翻译过来是在说：25 岁前你应该已经做完观察、开始认真挑了。

数学是怎么把 25 岁这个数字钉死的

为了让这件事可信，我把演算和模拟都做了一遍，数据全部来自我自己写的一个交互式模拟器：

🔗 numfeel.996.ninja/pages/optim… （你可以直接打开亲手跑）

第一步：把 N=17 代入公式

秘书问题最优跳过数的公式：

我用 demo 里的 theoreticalOptimalR(17) 直接算了一遍：

参数	数值
N（窗口期年数）	17
最优跳过 r	6 年
占比	35.3%（接近理论的 1/e ≈ 36.8%）
对应年龄拐点	18 + 6 = 24 岁
理论选到”最佳”的概率	38.73%

注意第三行。N 是离散整数，跑出来 35.3% 比 36.8% 略小一点，对应拐点正好压在 24 岁——这就是知乎/微博上那句”25 岁前”的数学版本。如果你愿意把窗口期开到 18~36（17→18 年），拐点会精确推到 24.6 岁。怎么调都跑不出 25 岁这个量级。

第二步：跑两万次模拟，看真实成功率

光看公式不够，我用模拟器的 Tab 2 直接跑了 N=20、两万次蒙特卡洛。

结果：

策略	选到最佳的概率
37% 法则	38.52%
随机选一个	5.15%
立刻选第一个出现的	5.04%
一直等到最后被迫选	5.12%

37% 法则的命中率是其它三种”瞎搞”策略的约 7.5 倍。

如果你觉得 N=20 太多，把 N 拉到 10（一辈子只认真考虑 10 个人），结果一样有效：

策略 (N=10, 20000 次)	成功率
37% 法则	40.16%
随机选	9.78%
选第一个	9.93%
等到最后	9.84%

注意 N=10 时观察期 r=4，拐点也在 18+(4⁄10)×17 ≈ 24.8 岁，依然是 24~25 之间。

第三步：用参数扫描验证”24~25 岁”这条线不是巧合哦

模拟器的 Tab 3 会把跳过比例从 0% 扫到 100%，画一条成功率曲线。

我跑了 N=17、每个点 5000 次的扫描，截取关键比例：

跳过比例	实测成功率
0%（碰到就选）	5.8%
10%	28.0%
20%	32.5%
30%	36.5%
36%（理论最优）	39.1%
40%	38.5%
50%	35.4%
60%	32.4%
80%	16.4%

峰值精确落在 36~42% 区间，曲线两端塌得很快。跳过太少，你连基准线都没建立好，标准等于乱猜；跳过太多，最好的那个已经走完了，你只能在剩下的次品里挑。

把这条曲线和”24~25 岁”对照一下：18 岁起算，36% 对应 24.1 岁，40% 对应 24.8 岁。曲线峰值这段平台期，刚好覆盖了所有人嘴里说的”二十四五岁”。

为什么是 1/e，不是 1/2？

很多人第一反应是”看一半再选不就好了”。问题在于 50% 这一格我也跑了——成功率掉到 35.4%。

观察期太短，基准线偏低，容易把”第 7 名的人”当成”全场第 1”。观察期太长，”全场最佳”很可能已经在你观察期内出场了，后面你再也碰不到比 ta 更好的，被迫顺延到最后一个垃圾桶。对照一下现实可以说是非常真实了。

1/e 这条线把两边的风险压到一样大。这个模型最后给出来的最优策略只有这一条——告诉你信息收集和行动窗口的最佳切换点。

但是！但是要来了，现实修正：哪些假设会让”24.3 岁”漂移？

理想很丰满，现实很骨感。

候选人不是均匀出场。校园池子和职场池子的整体质量分布完全不同。换环境本身就在改变 N 和你的样本分布——这也是为什么有人 22 岁就遇到对的人，有人 32 岁还在等。
“不能回头”是硬假设。现实里前任能复合，被你跳过的人可能还在原地等。所以 24.3 岁这条线并不是死线。但它告诉你一件事：你拖得越久，回头率越低。
目标到底是”最好的”还是”够好的”？经济学家 Herbert Simon 提出过 satisficing（够好就行）。如果你接受 80 分而非 100 分，最优观察期会缩短——大概 22 岁前后就该开始定。所以”宁缺毋滥”的人，反而要等到 24~25 岁。要求越高，越要给观察期留够时间。
N 是你猜的。没人知道一生会认真考虑几个人。但只要 N 落在 5~30 这个合理范围，跳过比例都在 33%~~40% 之间晃，拐点都被锁在 23~~25 岁。这个区间硬到让人不舒服。

如果你现在 24 岁以下？

那么你可以按照下面的方法去评估

把评分维度真正建起来。颜值、身高、收入是表层 feature。真正决定长期匹配度的是”和这个人相处一年后，我变好了还是变差了”。这种东西需要时间样本。
拓宽样本多样性。同质化的池子会扭曲你的基准线。校园谈、社团谈、朋友介绍谈、工作后再谈——每一段都在校正你的标尺。
认真复盘。每个交往超过 3 个月的人，事后写下”ta 让我学到的”和”我不能接受的”。这就是你 24 岁那道分界线之前的训练数据。

过了 24.3 岁，规则变了：

看到一个让你觉得”比过去几年所有人都更对劲”的人——别再拖了。
“再看看会不会更好”是这个模型里最经典的失败模式。模拟器告诉你，越往后等，你接触到比当前更好的人的概率就越低，最后多半会被迫选到末尾那个。

现实极低概率出现傻白甜白富美爱上穷小子、沙特阿拉伯王子爱上当保洁的穷姑娘

当然最后，你自己来demo玩玩就知道这个定律有多有效了

我加了一个”择偶情境”开关，可以切换到”看女生 / 看男生”模式，候选人会显示成 12 种风格的卡通头像 + “心动指数”，体验上更贴近真实择偶场景。但底层算法和数学是同一套——换汤不换药，因为渣男会骗人，但是数学不会骗人

🔗 numfeel.996.ninja/pages/optim…

Superpowers：GPT-5.6 时代下的流程毒瘤

小u — Mon, 13 Jul 2026 10:02:14 GMT

一个日均消耗约 3 亿 token 的重度使用者，为什么最后选择把它从工作流里拆掉

先说结论：我不是被模型拖慢，是被流程拖慢

今天下午，我又被一个任务折磨了一遍。

这不是一个需要数天架构设计的项目，也不是支付、权限、数据迁移这种必须多人审查的高风险改动。按正常的工程节奏，应该是理解需求、定位代码、做一个小改动、跑相关测试，然后结束。真正动手的时间可能并不长。

但在 Superpowers 的工作流里，一个小任务很容易被拉成一条完整的仪式链：先判断有没有 skill 适用，再进入头脑风暴，再写设计，再等确认，再写计划，再决定要不要建 worktree，再为每个任务派实现代理，再派规格评审，再派质量评审，最后还要重新验证、收尾、汇报。

每一步单独看都能找到一个听起来合理的理由。问题是，工程效率不是把所有合理步骤都叠在一起。工程效率是用足够低的成本，获得足够高的正确率。

Superpowers 最大的问题，恰恰是把“谨慎”变成了默认，把“流程”变成了目的，把一个本来可以直接完成的任务变成了对流程本身的服从测试。

我不是反对测试，也不是反对审查，更不是反对子代理。我反对的是：在 GPT-5.6 这样的强模型时代，还把一套为不稳定、低自主性代理设计的长流程，当成所有任务的统一宗教。

我是谁，以及为什么我会对这个问题这么敏感

我不是偶尔打开一次聊天窗口、问一个问题就离开的用户。按我自己的使用统计口径，我日均消耗大约 3 亿 token。这个数字不是行业基准，也不是给任何产品做宣传的指标，它只是我的工作现实：大量代码阅读、长上下文分析、跨模块修改、调试、部署、文档整理和反复验证，都在同一个 AI 工作流里完成。

高频使用有一个好处：很多流程在第一次体验时看不出问题，重复几十次以后，问题会自己浮出来。

你会开始分辨哪些步骤真的降低了错误率，哪些步骤只是让模型显得很认真；哪些输出帮助了决策，哪些输出只是把已经知道的事情再解释三遍；哪些评审抓住了缺陷，哪些评审只是把“没有发现问题”包装成一份新的报告。

当你一天只做一个任务时，多十分钟的流程可能不明显。当你一天做几十个任务，或者让模型持续工作数小时，所有额外步骤都会变成真实的延迟、真实的 token、真实的上下文污染和真实的注意力损耗。

所以我对 Superpowers 的不满，不是来自一次偶然的不顺手，而是来自高频使用后越来越清楚的成本账。

Superpowers 到底把什么叠在了一起

我盘点了本机缓存中的 Superpowers v5.1.3。它一共有 14 个 skill，核心规则文本约 3207 行。它们大致分成几组：

需求与计划：brainstorming、writing-plans、executing-plans
子代理与并行：subagent-driven-development、dispatching-parallel-agents
工作区与交付：using-git-worktrees、finishing-a-development-branch
测试与调试：test-driven-development、systematic-debugging
评审与验证：requesting-code-review、receiving-code-review、verification-before-completion
全局入口与元流程：using-superpowers、writing-skills

单个 skill 的存在并不等于每次都会加载完整正文。真正让事情变重的是它们之间的默认连接关系：

using-superpowers
    -> brainstorming
    -> writing-plans
    -> using-git-worktrees
    -> subagent-driven-development
    -> implementation
    -> spec review
    -> quality review
    -> verification
    -> finishing-a-development-branch

这是一条适合大型、高风险、多人协作项目的保守流水线，不是一条适合所有日常代码任务的默认路径。

效率：每一步都合理，串起来就不合理

下面是这条链中几类常见步骤的真实成本。

步骤	它声称解决的问题	对小任务的实际代价
全局 skill 检查	避免漏掉流程	每次对话都增加判断和解释，模型先讨论“该不该开始”
头脑风暴	避免需求误解	配置、单函数、文档改动也被迫走设计和审批
详细计划	降低执行偏差	计划本身变成第二份规格，耗时可能超过实现
worktree	隔离改动	在已有隔离环境里重复创建隔离，产生无效操作
实现代理	分离上下文	重新传递背景、目标、文件和约束，增加等待和同步
规格评审	检查是否符合需求	对明确的小改动，常常只是复述需求
质量评审	检查代码质量	需要再次读取 diff 和上下文，可能提出低价值风格意见
收尾流程	统一合并和交付	对不需要 PR 或分支操作的任务，完全是额外仪式

关键不是某一步需要多少秒，而是这些步骤有顺序依赖。前一步没有结束，后一步不能开始。用户需要回答更多确认问题，模型需要发更多状态消息，工具需要产生更多中间文件，整个任务的尾延迟被不断拉长。

最荒谬的场景是：代码改动本身只有几行，流程产物却包括设计说明、计划、任务清单、实现报告、规格评审报告、质量评审报告和最终验证报告。最后真正改变系统行为的，可能只有一个条件判断。

这不是严谨。这是流程和任务规模失配。

Token：最贵的不是代码，是重复解释

很多人谈 token 成本时，只盯着模型生成的代码。实际更昂贵的部分，往往是被流程强迫重复传递的上下文。

一个简化的成本模型可以写成：

总成本
= 主代理上下文
  + 实现代理次数 × 任务上下文
  + 评审代理次数 × diff 与需求上下文
  + 失败重试 × 全部上下文
  + 流程状态消息与报告

在单代理直接执行时，任务上下文通常只需要被理解一次。进入子代理开发后，同一份需求至少要被主代理整理一次、实现代理读取一次、规格评审读取一次、质量评审再读取一次。任务越多，重复越明显。

而且这些上下文并不是免费的摘要。为了让每个代理“独立”，控制器要把任务背景、文件范围、约束、预期输出和当前状态重新写出来。评审代理还要重新建立自己的判断上下文。你以为你在买更高质量，实际上也在为同一份信息付多次入场费。

更大的问题是 token 不只影响账单。上下文越长，模型越容易把注意力放在流程文档、状态报告和评审意见上，而不是放在真正的代码因果关系上。模型开始优化“如何证明自己遵守流程”，而不是“如何最快地解决问题”。

对于日均消耗约 3 亿 token 的工作流，这种重复不是抽象的效率损失，而是巨大的资源浪费。

评审到底有没有用？有，但不应该成为宗教

评审当然有用。安全边界、权限模型、支付逻辑、数据迁移、并发控制、公共 API 和跨服务契约，都值得第二双眼睛。问题在于，评审的价值高度依赖风险，而 Superpowers 把它做成了默认税。

可以用一个很简单的判断表：

任务类型	自动评审的潜在收益	是否值得强制多轮评审
修改文档、配置、文案	很低	不值得
单文件局部修复	低到中	通常不值得
已有测试覆盖的普通业务逻辑	中	一次针对性检查即可
跨模块重构	高	可以考虑一次独立评审
权限、支付、安全、数据迁移	很高	建议人工或独立评审

强制评审的问题有三个。

第一，评审代理不天然比实现代理更懂业务。它可能发现真正的缺陷，也可能把个人风格偏好当成规范问题。最后主代理还要花时间判断评审意见是否成立。

第二，规格评审和质量评审的边界并没有想象中清晰。规格不完整会变成质量问题，质量风险又经常需要回到需求语义。拆成两个代理，不一定得到两倍的洞察，通常只得到两份相互重叠的文字。

第三，评审会制造一种危险的安全感。报告写得很完整，不等于系统真的正确。真正有价值的验证仍然是可执行的测试、可复现的行为、清晰的监控和真实的用户反馈。

评审应该是风险工具，不应该是忠诚度测试。

GPT-5.6 时代，为什么这套东西更容易显得逆天

早期代理确实需要更多脚手架。模型可能不理解上下文，容易忘记目标，不能稳定拆任务，也不擅长自我检查。于是人们把工程经验写成一条条硬规则，试图用流程弥补模型的不可靠。

但模型能力在变化，流程却很容易固化。

GPT-5.6 这一代强模型已经能够在同一个上下文里完成代码理解、方案选择、修改、测试和纠错。它不意味着模型永远正确，也不意味着工程纪律可以消失，但它意味着默认工作流应该允许模型根据任务风险调整策略。

如果提示词写成“只要有 1% 的可能就必须调用 skill”，模型就没有风险判断空间。如果写成“任何项目都必须先设计，即使是一个配置改动”，模型就不能根据任务规模收缩流程。如果写成“没有失败测试就不能写生产代码”，模型就会把测试形式本身当成目标。

这不是在增强模型，而是在压缩模型的有效自由度。

模型明明可以用十分钟解决问题，却被要求用十分钟解释为什么现在还不能解决问题。模型明明可以根据风险选择一次验证，却被要求证明自己完成了完整仪式。最终用户看到的不是更聪明的工程师，而是一个不停填写流程表格的工程助理。

最逆天的不是某个步骤，而是那些硬门槛措辞

Superpowers 里有几类措辞特别能说明问题。

using-superpowers 的原始规则要求：只要有 1% 的可能适用，就必须调用 skill，而且任何回复或行动之前都要先检查。

brainstorming 的原始规则要求：任何项目都必须先设计。它甚至把 todo、单函数工具和配置修改列为不能跳过的案例，并要求写设计文档、提交、等待用户审阅，再进入计划。

test-driven-development 的原始铁律是：没有先看到失败测试，就不能写生产代码。

verification-before-completion 的原始规则则把成功表达、提交、创建 PR、移动到下一任务，甚至派发代理，都纳入重新验证的范围。

这些句子单独看都像是在保护质量。放在一起，就变成了一个优先保护流程、其次才保护结果的系统。

真正成熟的工程规范应该写成“在风险足够高时这样做”，而不是“永远这样做”。把例外全部当成懒惰，把简化全部当成违规，最终只能让模型更擅长服从文本，不能让软件更可靠。

我最后做了一个本地实验：14 个变成 6 个

我没有继续争论“这套方法论理论上有没有价值”，而是直接做了一个本地精简实验。

原来的 14 个 skill 中，我移除了：

subagent-driven-development
dispatching-parallel-agents
requesting-code-review
receiving-code-review
executing-plans
using-git-worktrees
finishing-a-development-branch
writing-skills

剩下的 6 个 skill 被改成轻量版本：

需求真正不清楚时，才做简短 brainstorming。
多文件、存在顺序依赖时，才写短计划。
复杂 Bug 才做系统调试，简单错误直接修。
行为复杂、测试收益明确时才采用测试优先。
非平凡任务结束前跑一次针对性验证。
用户明确要求时，才考虑额外流程。

结果是，核心 SKILL.md 从约 3207 行降到 110 行。这个数字不是性能基准，也不能证明所有团队都应该这么做，但它证明了一件事：原来的复杂度并不是工程问题本身必然要求的，而是规则叠加出来的。

我还增加了一条更直接的全局偏好：除非用户明确要求，否则不派子代理，不派自动评审代理，默认由主代理完成实现并做一次针对性验证。

这才更接近我想要的 AI 工程师，而不是 AI 流程管理员。

我认为 GPT-5.6 时代的工程规范应该是什么样

我不主张把所有规范都删掉。我主张把规范分级。

Lite：默认模式

适用于文档、配置、单文件修改、简单 Bug 和明确的小功能。

理解目标 -> 修改 -> 针对性测试或检查 -> 说明结果

不写长设计，不建 worktree，不派代理，不做自动评审。

Standard：普通复杂任务

适用于多文件改动、存在接口影响或需要明显顺序的功能。

短计划 -> 实现 -> 相关测试 -> 一次自检

计划的目标是减少遗漏，不是制造一份比代码更长的文档。

Strict：高风险任务

只在安全、支付、权限、数据迁移、公共 API、跨服务契约和重大重构中启用。

设计讨论 -> 计划 -> 实现 -> 独立评审或人工评审 -> 集成验证

即使是 Strict，也应该由用户或项目负责人明确选择，而不是由一个“1% 可能性”自动触发。

这种分级并不降低标准。它把标准用在真正需要的地方，把时间留给真正重要的判断。

不是反对纪律，是反对把纪律变成目的

今天下午最让我烦的，不是模型犯了一个错。模型犯错是可以接受的，至少错误是可见的，可以复现，可以修复。

让我烦的是，在一个本来可以快速闭环的任务里，我不断看到新的流程、确认、报告和评审。每一项都在告诉我系统很谨慎，却没有同等力度地告诉我系统离结果更近了。

我宁愿让模型在一个低风险小任务上直接做出一个可以被测试发现的错误，也不愿它先花大量 token 证明自己知道什么叫规范。我宁愿自己看一眼 diff、跑一次测试，也不愿为一份低价值评审报告再启动一个上下文、再等待一次结果、再判断一次判断是否值得相信。

AI 工具的价值，是把人的判断力放大，把执行成本压低。一个工作流如果让人花更多时间等待流程、解释流程、批准流程，最后才轮到解决问题，那它就已经偏离了工具的目的。

Superpowers 曾经试图把经验固化成护栏。问题是，护栏太多、太密、太低，最后就不再是护栏，而是一条把所有车辆都强行降速的窄路。

在 GPT-5.6 时代，我们需要的是有判断力的工程纪律，不是无差别的流程服从。

我并不想让模型少思考。我只是希望它把思考用在代码、数据和结果上，而不是用在证明自己完成了多少个仪式。

这就是我为什么说：对高频 AI 工程工作而言，未经分级、未经风险校准、默认强制评审和子代理的 Superpowers，已经从“能力增强”变成了“效率毒瘤”。

技术附录：这不是情绪，而是可以定位的机制问题

原始规则里的几个硬触发点

下面这些不是我对 Superpowers 的二次概括，而是它在 skill 文件中使用的典型硬门槛。文件名就是它们在插件里的实际位置。

文件	原始倾向	运行时后果
`skills/using-superpowers/SKILL.md`	“只要有 1% 的可能适用，就必须调用”	低置信度判断也会触发完整流程
`skills/brainstorming/SKILL.md`	“这适用于每一个项目，包括简单配置修改”	小改动不能直接开始
`skills/writing-plans/SKILL.md`	要求把工作拆成完整、可执行的计划任务	计划成本和实现成本倒挂
`skills/subagent-driven-development/SKILL.md`	每任务新建实现代理，再做规格和质量评审	一次改动变成多次上下文交接
`skills/requesting-code-review/SKILL.md`	每个子任务、重大功能、合并前都要求评审	评审从风险工具变成固定税
`skills/verification-before-completion/SKILL.md`	任何完成表达、提交、下一任务前都要新鲜验证	状态沟通也会触发额外检查

这些规则的共同问题不是“完全错误”，而是把“通常有帮助”写成了“永远必须”。一旦触发条件过宽，模型就无法根据任务规模和失败代价做正常的工程取舍。

1. 规则触发层

skill 的 frontmatter 描述会参与触发判断。只要描述写成“任何对话”“任何功能”“任何 Bug”，触发面就会极度扩大。全局入口再要求“1% 可能适用也必须调用”，等于把低置信度判断变成高频加载。

2. 上下文复制层

子代理架构需要把任务背景重新包装给每个代理。实现代理、规格评审代理和质量评审代理往往分别读取同一份需求和 diff。任务本身没有增加，输入上下文却被复制了多次。

3. 交互等待层

代理调用通常存在启动、等待、汇总和重试。即使每次代理都很快，串行依赖仍会把总耗时拉长。用户等待的不是代码计算时间，而是多个角色之间的交接时间。

4. 判断污染层

当上下文中同时存在需求、计划、实现报告、评审报告和修复意见，模型必须花额外注意力判断哪一层才是当前事实。越多过程文档，不一定越清晰，可能只是增加了状态冲突的机会。

5. 质量收益递减层

第一次针对性测试通常能发现最直接的问题。第二次独立检查可能发现边界条件。第三次对同一小任务做形式不同但信息高度重叠的评审，收益往往快速递减。流程没有把这个递减曲线纳入决策，就会把低收益检查当成固定成本。

6. 正确的控制变量

真正应该控制的不是“有没有调用某个 skill”，而是：

变更风险有多高；
失败的代价有多大；
是否存在独立的知识盲区；
是否有可执行的验证手段；
用户是否明确需要额外审查。

这些变量决定了流程强度。任何脱离风险、只按关键词触发的固定流程，最终都会在简单任务上浪费资源，在复杂任务上制造虚假的安全感。

为什么 AI 写前端时，总是优先选择 React，而不是 Vue？

ErpanOmer — Mon, 13 Jul 2026 09:25:59 GMT

如果你在过去几个月里，高强度使用过 Codex、Cursor 或者是 Claude Code 等 AI 编程工具，你一定会察觉到一个让国内前端开发者极度不适的现象：

当你扔给 AI 一张设计图，或者一段自然语言需求，让它帮你生成前端组件时，如果不做任何额外的 Prompt 限制，它默认吐出来的代码，永远是 React 加上 Tailwind CSS🤔。

作为一个 Vue 开发者，你必须在提示词里反复强调：请使用 Vue3 和 script setup 语法！。但即便如此，AI 生成的 Vue 代码里，也经常会诡异地夹杂着 className，甚至试图在 template 模板层里写 map 映射。

在框架使用者眼里，这可能又是一场框架优劣的口水战。但我想讲的是，大模型这种压倒性的框架偏好，其实暴露出的是底层技术架构的根本性差异。

只是因为训练语料多吗？

当你抛出这个问题时，绝大多数人给出的答案是：因为 React 拥有全球最庞大的生态，在 GitHub 上的开源项目和代码语料远超 Vue。大模型吃进去的 React 代码多，吐出来的自然也就多。

这句话本身没错，但这只是一层极其懒惰的表象解释🤷‍♂️。

大模型本质上是一个基于概率的 Token 预测机器。它在生成代码时，不仅受语料数量的影响，更受语言结构（AST）纯粹性的制约。真正让 AI 对 Vue 感到吃力并且频繁产出幻觉的，是两者在底层设计哲学上的巨大鸿沟🤔。

JS 纯粹性与 DSL 的认知负担

在我们人类程序员眼里，Vue 极度优雅。它的单文件组件（SFC）把 <template>、<script> 和 <style> 物理隔离，逻辑清晰，极度符合人类对网页结构的直觉认知。

但在大模型的眼里，Vue 其实是一个极其复杂的 DSL（领域特定语言）。

大模型最擅长预测什么？是标准的、图灵完备的常规编程语言（比如纯 JavaScript 或 Python）。

React 的 JSX 表面上看起来是标签，但在 AST（抽象语法树）层面，它本质上就是纯粹的 JavaScript 函数调用。核心的控制流（if/else、map、switch）完全遵循原生 JS 的语法规则。大模型在预测下一个 Token 时，上下文是高度连贯和内聚的👇。

// 在大模型的使用，这根本不是 HTML，这只是一个标准的 JS 纯函数
export function UserList({ users }) {
  return (
    <ul>
      {users.length > 0 
        ? users.map(u => <li key={u.id}>{u.name}</li>)
        : <li>暂无数据</li>}
    </ul>
  );
}

而 Vue 则不同。大模型在生成 Vue 代码时，必须在脑海里强行维护两套完全割裂的上下文：一套是基于 HTML 扩展的模板语法（v-if、v-for、v-model），另一套是下方的 script setup 响应式逻辑。

<!-- 大模型在生成长组件时，极其容易在这里的模板层丢失数据映射 -->
<template>
  <ul>
    <template v-if="userList.length > 0">
      <li v-for="u in userList" :key="u.id">{{ u.name }}</li>
    </template>
    <li v-else>暂无数据</li>
  </ul>
</template>

<script setup lang="ts">
import { ref } from 'vue';
// 当代码超过 300 行，AI 很容易忘了上面绑定的变量到底是 users 还是 userList
const userList = ref([]);
</script>

当上下文长度超过几百行后，大模型极容易在 template 和 script 之间的变量绑定上产生灾难级的幻觉。它可能会在模板里写出一个未经声明的 ref 变量，或者在脚本里写了一堆逻辑，却忘了通过模板指令去驱动视图。

人类更擅长处理结构隔离，而机器更擅长处理逻辑同源🖐️。

那组件物理拆分的阻力是什么？

在大模型的日常协作中，最深水区的痛点其实是代码的重构与拆分。

大模型写代码有一个通病：喜欢把所有的逻辑都塞进一个巨大的文件里。当这个缝合怪组件膨胀到上千行时，你必须命令它进行拆分。

在 React 里，拆分组件的成本极低。大模型只需要在同一个文件里，顺手多写几个首字母大写的 Function，就可以直接完成细粒度的逻辑抽离。这种按需内联拆分的能力，极其契合 AI 的线性文本生成逻辑。

但在 Vue 的生态里，创建一个新组件通常意味着必须在文件系统里新建一个 .vue 文件，并且要处理繁琐的 import 路径、父子组件 props 传递和 emits 事件分发。多文件并发生成和底层路径映射，恰恰是当前所有 AI 编程工具最容易翻车的软肋。

这直接导致了 AI 在写大型 Vue 项目时，代码极易走向失控。

前端组件的文本化（复制粘贴🤣）

最后，我们无法回避整个前端组件库生态的残酷站队。

在 AI 自动生成 UI 的时代，像 Shadcn UI 这种纯粹基于 Tailwind CSS 和 Radix UI 的方案成为了绝对的统治者。为什么？因为它的组件根本不是作为一个 npm 依赖包黑盒存在的，而是可以直接被大模型阅读、复制并内联修改的纯文本源码。

这种 代码即 UI 的模式，让 AI 可以直接透视并定制组件的每一个像素。而 Vue 生态里占据主导地位的（如 Element Plus 或 Ant Design Vue），依然是沉重的全局安装包。大模型无法透视黑盒内部的代码，在遇到定制化需求时，只能绝望地去瞎猜文档配置参数😖。

在做技术选型时，我们往往会夹杂着太多关于好与坏的执念。

如果是完全由纯开发者主导开发，Vue 极低的心智负担、清晰的关注点分离，依然是中大型业务团队稳盘的绝佳利器。

但如果我们正在迈入一个由 AI 主导代码生成的新纪元，我们就必须面对残酷的现实：React 那种一切皆函数、一切皆 JavaScript 的纯粹性，确实极大地降低了机器的认知负荷。

好了，今天写道这里吧🙌

星云SDK + 油猴：给LLM塑造肉身，陪伴你在每个网页

石小石Orz — Mon, 13 Jul 2026 04:44:06 GMT

作为一名前端开发者，我一直有一个愿景：让大模型不再只是冰冷的输入框，而是能以具身交互智能数字人形象，出现在我们浏览的每一个网页上，一直陪伴我们。

这个想法其实来自钢铁侠的“贾维斯”，我希望在我使用浏览器的时候，AI助手一直在页面上陪伴我，写错了代码了立刻提醒，有疑问随时解答。幸运的是，随着大模型的发展，这些已经可以轻松实现。

今天，我想分享一个基于 魔珐星云SDK 和 油猴脚本 的方案，实现一个基础版的网页AI助手：用魔珐星云SDK结合LLM，打造拥有 3D 躯体、同步神态动作、支持实时打断的网页随身 AI 具身交互智能伙伴，再通过油猴脚本让它出现在任意网页上。

效果展示

先来看一下脚本的最终实现的效果。

无处不在的陪伴：

不管打开什么网页，点击链接，虚拟助手直接出现。下图分别是在 TRAE 官网和掘金热榜上的效果：

极速上手体验

基于油猴脚本，安装脚本后，配置好魔珐星云 SDK 的 ID和Key 就能跑起来体验，成本极低。

热切换形象，零配置

在魔珐星云控制台切换虚拟人的形象、场景、音色后，不需要改任何代码配置，脚本实时生效。

实时对话&语音交互：

发送文字消息后，数字人会实时语音播报，同时配合自然的表情和肢体动作，整个过程响应低于 500ms，并支持全程随时打断，体验流畅。

发送语音消息也没问题——基于第三方 ASR 语音识别，语音实时转文本，再交给星云 SDK 处理，实现真正的语音对话。

LLM流式响应同步

脚本支持接入任意第三方大模型。以 DeepSeek 为例，LLM 流式输出的同时，3D 数字人就能基于已返回的内容实时生成语音，不用等整段文字全部返回才开始回答，大幅减少了等待感。

核心体验一句话概括：为 DeepSeek 等 LLM 补齐缺失的具身交互智能，让纯文本推理模型升级为看得见、能共情、可双向实时互动的全域网页陪伴智能体。

核心技术

整个 Demo 的实现依赖两个核心技术：魔珐星云具身驱动 SDK 负责 3D 虚拟人的渲染与交互，Tampermonkey（油猴脚本） 负责让它在任意网页上跑起来。

魔珐星云具身驱动SDK

魔珐星云是魔珐科技打造的「AI 具身交互智能体开放平台」，提供 AI 形象生成、多模态感知、大模型 Agent 认知、实时 3D 具象表达、机器人运控等端到端能力。

借助它的具身驱动 SDK，只要终端支持浏览器内核，就可以接入具备 AI 交互能力的 3D 虚拟人。平台采用完整自研参数流架构 + AI 端渲和解算原生技术，专门为各类 LLM、Agent 提供标准化具身交互智能，一站式完成 3D 形象生成、情绪同步、实时双向交互、多终端适配全链路能力。

技术模块	说明
语义情感理解	实时解析文本语义、情绪、动作意图
TTS语音生成	高自然度语音合成，延迟约100-500ms
表情动作生成	实时输出3D微表情、肢体动作、手势
AI端侧渲染	无需传统游戏引擎，百元级芯片即可运行

使用星云具身驱动SDK实现3D虚拟形象，具备以下优势：

低延时：端到端响应低于500ms，对话支持随时打断
高并发：支撑千万级设备同时在线
低成本：无需昂贵GPU，普通设备即可流畅运行
全兼容：覆盖手机、PC、大屏、机器人等终端

Tampermonkey篡改猴

Tampermonkey篡改猴又称为“油猴，”是一款老牌浏览器插件，它允许开发者以一段轻量的 JS 脚本，实现媲美原生浏览器扩展的功能。

它的工作原理很简单：在网页加载时注入自定义 JavaScript，从而增强、修改或自动化页面行为。常见的应用场景包括广告屏蔽、页面优化、自动填表、功能增强等。

如果你之前没接触过油猴脚本，可以参考：『油猴脚本实战指南 』

极速体验

1. 安装Tampermonkey浏览器插件

要体验Demo 中的效果，首先需要安装[Tampermonkey（油猴）浏览器插件]

安装过程可参考：油猴脚本的安装与管理

插件装好后，有两种方式安装脚本：

方式一：在线链接安装

在greasyfork.org 官网，搜索脚本：石小石Orz的魔珐星云虚拟人，然后点击安装此脚本

方式二：手动复制安装

点击浏览器菜单栏的油猴图标，选择「添加新脚本」，将以下脚本内容粘贴到编辑器中，Ctrl+S 保存即可。

gitee.com/sxshi/tampe…

安装完成后，刷新任意页面，就能在网页右下角看到操作面板：

如果你觉得油猴安装配置太麻烦，也可以直接访问以下网址，体验极简版 Demo

在线地址： https://www.axureshow.com/project/HDZcuEZb/

2. 获取星云SDK秘钥

前往魔珐星云平台注册账号，填写邀请码JM2A7C9LSW，获得1000积分。

注册成功后进入「控制台」
点击「具身驱动」创建应用
选择你喜欢的数字人形象、场景及音色，然后点击「创建并进入调试」
点击页面右上角「接入SDK」按钮获取 APP_ID 和 APP_SECRET

💡 使用邀请码JM2A7C9LSW注册可获得1000积分，否则获得100积分，积分类似大模型的token。

APP_ID 和 APP_SECRET获取成功后，点击脚本面板的设置按钮，配置秘钥

如果秘钥正确，点击「保存并连接」按钮，脚本就会开始创建连接，加载虚拟人。

3. 配置LLM API（可选）

脚本已内置 DeepSeek 模型作为默认选项，开箱即用，无需额外配置。

如果你想用自己的 DeepSeek API Key，前往 [DeepSeek API 平台] 获取 Key，在设置面板中填入即可。

现在，你就可以尽情的探索脚本了。

脚本核心代码解析

具身驱动 SDK 的接入方式非常简单，整体流程可以分为三步：引入 SDK、初始化实例、调用播报方法。

首先，在页面中引入 SDK：

<script src="https://media.xingyun3d.com/xingyun3d/general/litesdk/xmovAvatar@latest.js"></script>

然后创建 SDK 实例，并完成初始化。这里需要将 appId 和 appSecret 替换为刚才在魔珐星云控制台中复制的内容：

const sdk = new XmovAvatar({
  containerId: "#sdk", // 必填：数字人挂载容器
  appId: "your_appid", // 必填：应用 AppID
  appSecret: "your_appsecret", // 必填：应用 AppSecret
  gatewayServer: "https://nebula-agent.xingyun3d.com/user/v1/ttsa/session", // 必填：服务接口地址

  // SDK 事件回调，方便调试
  onMessage(message) {
    console.log("SDK message:", message);
  },
});

// 初始化 SDK，加载数字人资源
await sdk.init({
  onDownloadProgress(progress) {
    console.log(`资源加载进度：${progress}%`);
  },
});

初始化完成后，调用 speak 方法即可让数字人开口说话：

sdk.speak("你好，石小石，我是你的 AI 伴侣~", true, true);

如果只是播报一句完整的话，后两个参数通常都传 true

sdk实例化后，拥有以下核心方法：

方法	说明	参数
`init(config)`	初始化实例，连接服务并加载资源	`config.onDownloadProgress`：可选，监听加载进度
`destroy()`	关闭连接，释放资源	无
`offlineMode()`	进入离线模式，循环播放缓存视频（不消耗积分）	无
`onlineMode()`	从离线模式切回在线模式	无
`idle()`	切换到待机状态	无
`interactiveIdle()`	互动待机状态，可被其他状态打断	无
`listen()`	倾听状态，数字人正在接收用户语音输入	无
`think()`	思考状态，用户提问后、AI 尚未回复时的过渡	无
`speak(ssml, isStart, isEnd)`	驱动数字人说话，支持流式分段调用	`ssml`：文本/SSML；`isStart/isEnd`：标记是否为流式的起止片段

SDK 的能力到"让数字人说话"为止，至于说什么、怎么说，需要我们自己对接大模型。这其实和普通的 AI 对话开发没什么区别，核心就是把 AI 的输出通过 sdk.speak() 播报出来。

文字对话功能的核心是调用 LLM 获取回复，将结果传入 sdk.speak() 即可。配合流式输出，可以分段调用 speak()，每段传不同的 isStart/isEnd 标记，实现边生成边播报。

语音对话需要借助第三方 ASR 语音识别服务，将用户语音实时转为文本，送给 AI 处理后，再将结果喂给 sdk.speak()。整个链路就是：语音 → ASR → 文本 → LLM → 回复 → SDK 播报。

总结

本文分享了一个将 3D 虚拟数字人嵌入任意网页的方案：通过魔珐星云具身驱动 SDK 实现低延迟、高表现力的数字人渲染与交互，再借助油猴脚本的注入能力，让它出现在任意网页上。

整个方案的代码量并不大，技术栈也很简单：SDK 负责"形象 + 表达"，油猴负责"无处不在"，LLM 负责"大脑"。三者组合起来，就把一个原本只能在对话框里回复文字的 AI，变成了一个有形象、能说话、随叫随到的数字伙伴。

如果你也在做大模型应用，不妨试试这个方向——让 AI 不再只是一个输入框，而是真正"站在"用户面前的陪伴者。

不用框架，手搓 AI Agent：(一) 先让它跑起来

不一样的少年_ — Mon, 13 Jul 2026 02:13:38 GMT

🚀 插播一条：欢迎来到 不用框架，手搓 AI Agent 👈 专栏！这是咱们的第一站。

别被 Agent 这个词绕晕了，它的核心其实就两部分。

我们平时使用的 Cursor、Trae、Claude Code、Codex，本质上都属于 AI Agent。很多人第一次接触 Agent，会觉得它特别神秘，好像背后藏着一套非常复杂、深不可测的技术。但如果给 AI Agent“去个魅”，它其实可以简化成一个非常直观的公式：

AI Agent = 大模型（大脑）+ Harness（缰绳）

大模型负责思考，Harness 负责让它真正把事情做好。

`先来“放个毒”，看看经过本系列的打磨，我们最终会亲手搞出一个怎样的“完全体”`

如上图所示，它将拥有类似claudecode的终端交互、能感知你当前的工作目录，还能自主决定如何帮你完成研发任务。

是不是感觉很酷？

但这些能力并不是模型天生就有的。模型本身只负责理解需求、思考下一步；至于如何进入你的工作目录、调用终端、读写文件、执行命令，并在失败后继续尝试，靠的是另一套运行机制。

这套机制，就是 Harness。

Harness 到底是什么？

Harness 直译过来是“马具”或者“缰绳”。

放在 AI 工程里，这个比喻其实非常形象。

大模型就像一匹能力很强的马：动力十足、创意丰富，但有时候也比较“冲动”。如果没有约束，它写代码时可能会乱用依赖、执行危险命令，甚至产生幻觉，然后一本正经地胡说八道。
Harness 就像套在马身上的缰绳：它负责约束和引导大模型，把模型的想法转化成一个个可执行的工程步骤，确保它既能跑起来，也不至于跑偏。

举个最简单的例子。

当你对 Claude Code 或 Codex 说：帮我修复这个项目里的登录 Bug。

背后的大模型并不能凭空读取你的代码，也不能直接修改文件。

真正让它拥有这些能力的，是 Harness 为它提供的：

读取文件
搜索代码
修改代码
执行命令
检查运行结果
限制危险操作
在失败后继续调整方案

所以，只有大模型还不够。

没有 Harness 的大模型，更像是一个会聊天、会出主意的“大脑”；接上 Harness 之后，它才能真正读代码、改文件、执行命令，成为一个可以帮我们完成任务的 AI Agent。

大模型决定它能不能想明白，Harness 决定它能不能把事情做好。

而这个系列要做的事情，就是和你一起从零开始，亲手打磨出这样一套 Harness“缰绳”系统。

今天的目标：先让它跑起来

罗马不是一天建成的。我们把复杂的高级能力先放一边，任何一个强大的 AI Agent，都有一个极其朴素的起点。

本系列的第一篇，我们就来亲手敲下它的第一行核心代码，调通这条最基础的“一问一答”最短链路：

我们今天第一步要实现的“最小可用版本”跑起来长这样：

$ npm run start -- -prompt "用一句话解释什么是 TypeScript"

AI：TypeScript 是 JavaScript 的超集，为 JavaScript 添加了静态类型能力。

注意：它现在还只是“会聊天的命令行助手”，还不会读文件、改代码。但这正是后面实现 AI 编程 Agent 的地基。

🚀 本节配套源码：powercode 👈点它

如果中途遇到问题，可以对照源码排查。后续章节的代码也会持续更新，如果这个项目对你有帮助，欢迎点个 Star ⭐

一、准备环境

Node.js21 或更高版本
npm
一个 OpenAI 兼容的 API Key：这是通向各大模型的“万能通行证”。无论你用 DeepSeek、GLM 还是 Kimi，它们都遵循这套行业通用协议。拿到它，就等于拿到了所有主流模型的“入场券”。

先检查 Node.js 版本：

node -v

如果版本低于 v21，建议先升级。

二、新建一个独立项目

新建一个文件夹powercode

mkdir powercode
cd powercode
npm init -y

安装依赖：

npm install openai 
npm install -D typescript @types/node

现在项目目录大致是：

powercode/
├── node_modules/
├── package.json
└── package-lock.json

三、配置 TypeScript

新建 tsconfig.json：

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "rootDir": "src",
    "outDir": "dist",
    "strict": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*.ts"]
}

然后修改 package.json，将它调整为：

{
  "name": "powercode",
  "version": "1.0.0",
  "private": true,
  "type": "module",
  "scripts": {
    "build": "tsc",
    "start": "node dist/main.js"
  },
  "dependencies": {
    "openai": "^6.0.0"
  },
  "devDependencies": {
    "@types/node": "^22.0.0",
    "typescript": "^5.0.0"
  }
}

划重点：注意这里添加了 "type": "module"，这是为了让我们能在 Node.js 中直接使用现代的 import 语法，而不是老式的 require。

四、配置你的大模型

在项目根目录新建 provider.json：

{
  "protocol": "openai",
  "baseURL": "https://api.deepseek.com",
  "apiKey": "替换成你的 API Key",
  "model": "deepseek-v4-flash"
}

如果你使用别的兼容 OpenAI 接口的服务，protocol 保持不变，你只需要改下面这三个字段：

baseURL：接口地址
apiKey：你的密钥
model：模型名称

⚠️ 警告：provider.json 包含私人密钥，绝对不要提交到 Git！

所以我们在根目录新建 .gitignore 文件：

新建 .gitignore：

node_modules
dist
provider.json

💡 科普小知识

你可能会好奇：市面上有几百种大模型，难道我们要学几百种调用方法吗？其实不用。目前业界的 API 调用基本上被两大“普通话”统一了：OpenAI 协议 和 Claude 协议。尤其是 OpenAI 协议，国内的绝大多数主流模型（比如 DeepSeek、glm、通义千问、Kimi、豆包等）都完美兼容了它。

所以，只要你学会了 OpenAI 的接入方式，稍微改一下 baseURL 和 apiKey，就能无缝切换到几乎任何国产模型。这就是为什么我们在配置里只写这三个字段的原因。

五、先写一个读取配置的模块

在powercode下创建src源码目录：

新建 powercode/src/config.ts：

import { readFile } from "node:fs/promises";

/**
 * 提供商配置接口
 * 定义与 AI 提供商通信所需的配置参数
 */
export interface ProviderConfig {
  baseURL: string;   /** API 服务的基础 URL 地址 */
  apiKey: string;   /** 用于身份验证的 API 密钥 */
  model: string;    /** 要使用的 AI 模型名称 */
}

/**
 * 加载并验证提供商配置
 *
 * @returns Promise<ProviderConfig> 完整的提供商配置对象
 * @throws 当 provider.json 缺失或必需字段不完整时抛出错误
 * @example
 * ```ts
 * const config = await loadConfig();
 * // 使用配置初始化 AI 客户端
 * ```  
 */
export async function loadConfig(): Promise<ProviderConfig> {
  const content = await readFile("provider.json", "utf8");
  const config = JSON.parse(content) as Partial<ProviderConfig>;

  if (!config.baseURL || !config.apiKey || !config.model) {
    throw new Error(
      "provider.json 配置不完整，需要提供 baseURL、apiKey 和 model。",
    );
  }

  return {
    baseURL: config.baseURL,
    apiKey: config.apiKey,
    model: config.model,
  };
}

它告诉 TypeScript：配置对象必须包含这三个字符串字段。

说白了，这就相当于你给 AI 拨打电话必需的“三件套”：

baseURL 是区号；
apiKey 是你的专属通讯证；
model 是你要找的哪位接线员。

准备好这三样，下一步我们就能真正向大模型发请求、让它干活了。

六、封装一次大模型请求

新建 src/chat.ts：

import OpenAI from "openai";
import type { ProviderConfig } from "./config.js";

export class ChatClient {
  private readonly client: OpenAI; // OpenAI 客户端实例

  /**
   * 初始化 ChatClient 实例
   *
   * @param config 提供商配置对象
   */
  constructor(private readonly config: ProviderConfig) {
    this.client = new OpenAI({
      apiKey: config.apiKey,
      baseURL: config.baseURL,
    });
  }
  
  /**
   * 向 AI 模型发送问题并获取回答
   *
   * @param prompt 用户的问题或指令
   * @returns 模型回答的内容
   */
  async ask(prompt: string): Promise<string> {
    const response = await this.client.chat.completions.create({
      model: this.config.model,
      messages: [
        {
          role: "system",
          content: "你是power-code,一个由驾驭工程驱动的骨灰级研发助手,请使用中文回答。",
        },
        {
          role: "user",
          content: prompt,
        },
      ],
    });

    return response.choices[0]?.message.content ?? "模型没有返回内容。";
  }
}

先用大白话解释这段代码。

OpenAI 是官方 SDK 提供的客户端。即使你接入的不是 OpenAI，只要接入的模型服务兼容 OpenAI 的接口格式，通常也能这样调用

this.client = new OpenAI({
  apiKey: config.apiKey,
  baseURL: config.baseURL,
});

真正发请求的核心是：

this.client.chat.completions.create(...)

我们把对话内容放进 messages 数组：

messages: [
  {
    role: "system",
    content: "你是power-code,一个由驾驭工程驱动的骨灰级研发助手，请使用中文回答。",
  },
  {
    role: "user",
    content: prompt,
  },
]

其中：

system：给 AI 定规则，例如让它用中文、保持某种身份。
user：用户真正提出的问题。
assistant：AI 历史回答的位置，后续实现多轮对话时会用到。

目前我们只有一问一答，所以只需要 system 和 user。

七、写命令行入口

新建 src/main.ts：

import { ChatClient } from "./chat.js";
import { loadConfig } from "./config.js";

/**
 * 从命令行参数中提取用户问题
 *
 * @param args 命令行参数数组
 * @returns 用户的问题或指令
 * @throws 当 -prompt 参数缺失或后面为空时抛出错误
 */
function getPrompt(args: string[]): string {
  const promptIndex = args.indexOf("-prompt");

  if (promptIndex === -1) {
    throw new Error('请通过 -prompt 传入问题，例如：-prompt "你好"');
  }

  const prompt = args[promptIndex + 1];

  if (!prompt) {
    throw new Error("-prompt 后面不能是空内容。");
  }

  return prompt;
}

/**
 * 主函数，处理命令行参数并调用 ChatClient 发送问题
 */
async function main() {
  const prompt = getPrompt(process.argv.slice(2));
  const config = await loadConfig();
  const client = new ChatClient(config);

  console.log("AI 正在思考...\n");

  const answer = await client.ask(prompt);

  console.log(`AI：${answer}`);
}

main().catch((error: unknown) => {
  const message = error instanceof Error ? error.message : String(error);
  console.error(`启动失败：${message}`);
  process.exit(1);
});

这里的关键是 Node.js 提供的一个内置数组：process.argv。它会把我们在命令行敲下的每一段文字收集起来。

当我们执行这行命令时：

npm run start -- prompt "你好"

💡 小提示：中间的 -- 是为了告诉 npm：“后面的参数请原封不动地传给我的代码，不要你自己处理掉。” 程序内部收到的完整的 process.argv 数组，其实长这样：

[
  "/usr/local/bin/node",       // 第 0 项：Node.js 环境所在的路径
  "/你的项目路径/dist/main.js", // 第 1 项：当前正在执行的脚本路径
  "-prompt",                   // 第 2 项：我们传的参数名
  "你好"                       // 第 3 项：我们传的参数内容
]

你看，前两项都是系统自带的路径信息，对我们没有任何用处。

所以，我们要用 .slice(2) 像切蛋糕一样，把前面那两项切掉，只保留从第 2 项开始的真实参数：

["-prompt", "你好"]

拿到这个干净的数组后，getPrompt 函数的工作就非常傻瓜化了：去数组里找 -prompt 在哪个位置，然后把紧跟在它后面的那句话（也就是 "你好"）提取出来，这就是用户真正要问 AI 的问题。

八、编译并运行

一切准备就绪，现在我们要把 TS 代码转化为 Node.js 可执行的 JS 代码，并让 Agent 跑起来。

1. 编译代码

执行构建指令，将 src 下的 TypeScript 代码编译至 dist 目录：

如果没有报错，项目中会多出一个 dist 目录：

powercode/
├── dist/
│   ├── chat.js
│   ├── config.js
│   └── main.js
└── src/
    ├── chat.ts
    ├── config.ts
    └── main.ts

2. 让 Agent 跑起来

接下来，调用我们的系统，并传入你的第一个指令：

npm run start -- -prompt "用一句话解释什么是 TypeScript"

恭喜，你已经写出了第一个命令行 AI 助手。

九、我们刚刚到底完成了什么？

把整件事画成一条数据流，就是：

目前的项目结构也非常简单：

powercode/
├── src/
│   ├── config.ts    # 读取和校验模型配置
│   ├── chat.ts      # 请求大模型
│   └── main.ts      # 命令行入口
├── provider.json    # 本地模型配置，不提交
├── .gitignore
├── package.json
└── tsconfig.json

每个文件只有一个职责：

config.ts 不关心如何请求模型；
chat.ts 不关心命令行参数怎么解析；
main.ts 只负责把它们串起来。

这种拆分方式会在后面越来越重要。因为当我们加入读文件、修改代码、执行命令等能力后，项目不会轻易变成一团乱麻。

十一、这算 AI Agent 吗？

严格来说，还不算。

现在的程序只有：

而一个真正能帮我们完成编程任务的 Agent，至少还要具备：

这也是下一篇要解决的问题。

下一篇，我们会给这个助手发一个“工具箱”，让 AI 不只是回答问题，而是能够主动请求读取项目里的文件。到那一步，它才真正开始具备 Agent 的味道。

AI 编程普及，初学者还要不要学习基础语法？

双越AI_club — Mon, 13 Jul 2026 01:07:43 GMT

大家好，我是双越。wangEditor 作者，前百度滴滴资深前端工程师，慕课网精英讲师，PMP，前端面试派作者。

我正致力于两个项目的开发和升级，感兴趣的可以私信我，加入项目小组。

智语带你从 0 开发一个 AI Agent 智能体，真实发布上线，像 openclaw 小龙虾一样。
划水AI 前端转全栈，从 0 开发一个复杂、高难度、全流程的全栈项目，真实发布上线。

开始

AI 编程正在快速普及，几乎所有开发者都在用 AI 写代码，效率提升是肉眼可见的：以前一天的工作量，现在半小时就能搞定，一天写出几千行代码已经不是新鲜事。

在这样的背景下，一个问题被越来越多人提出来：对于编程初学者，还要不要像过去那样，从变量、循环、函数这些基础语法开始，一点点啃下去？

学，速度很慢。语法这东西本身没什么技术含量，大量时间花在记忆规则、调试拼写错误、理解各种"为什么这里要加分号"上，性价比很低，尤其是当 AI 几秒钟就能写出正确代码的时候，这种投入显得更加低效。

不学，又不放心。AI 写的代码你看不懂，出了 bug 你没法排查，项目稍微复杂一点，你就完全丧失了掌控力，只能祈祷 AI 不要犯错。

这个问题乍一看好像没有标准答案，但如果换个角度想——也许我们问错了问题。真正值得讨论的不是"要不要学语法"，而是"在 AI 编程时代，程序员的核心能力到底是什么"。

技术栈知识体系

我是一名前端开发，最近在学习 Java 和 Spring Boot。借助 AI 编程，我确实不需要死抠语法细节：泛型怎么写、注解怎么加、某个 API 的具体参数顺序，这些交给 AI 就够了。

但与此同时，我发现自己面对的是一个更高维度的要求：你要熟悉这个技术栈完整的知识体系。

这个体系当然也可以通过 AI 获取——你问它 Spring Boot 项目该怎么组织，它能给你讲得头头是道。但问题在于，如果你自己完全没学过、不熟悉这个领域，AI 讲的内容你根本听不懂，更别说做出判断了。这就好比一个从没学过外语的人拿着翻译软件出国，软件能帮你翻译每一句话，但你依然无法理解对方话里的潜台词和文化背景。

以 Java 开发 Web 服务端为例，最基础的服务端知识体系大致包括：

框架（Spring Boot、SSM 等）
数据库（MySQL、事务、索引设计）
消息队列（RabbitMQ、Kafka）
缓存（Redis）
文件存储（对象存储、CDN）
部署（Docker、CI/CD）
日志与监控（日志采集、链路追踪、指标统计）

对一个初学者来说，掌握这一整套体系，远比学会 Java 语法本身要难得多，也重要得多。所以与其纠结"要不要学语法"，不如换个思路：从这些更贴近工程实际、维度相对更低的知识点开始学起，语法反而会在使用 AI 编程的过程中自然而然地被理解。

AI 编程主要把控什么

技术栈知识体系这个话题实在太大，不是一篇文章能讲完的。回到编程本身，在 AI 编程模式下，我们不需要、也不建议自己手动敲代码，但作为开发者，有几件事必须由你亲自把控。

第一，技术选型。 用什么编程语言、什么框架、依赖哪些工具和第三方服务，这些决策直接决定了项目的技术边界和后续的可维护性。AI 可以给你列出几套方案的优劣，但选哪个、为什么选，是你的责任。

第二，项目架构。 代码目录怎么组织、模块之间怎么划分、数据结构怎么设计、系统的扩展性如何预留，这些是决定项目能不能"长大"的关键。架构设计得好，后期加功能、改需求都轻松；设计得差，代码很快就会变成一团乱麻，AI 写得再快也救不了一个烂架构。

第三，验收标准。 你让 AI 写代码，必须清楚地告诉它要达到什么要求、满足哪些功能和业务流程，绝不能让它"自由发挥"。需求描述得越具体、边界条件交代得越清楚，AI 交付的结果就越可靠。反过来，如果你自己都说不清楚要什么，那再强的 AI 也帮不了你。

以上这三件事，你都可以让 AI 参与讨论、给出建议，但最终的决策权必须留在你自己手里。这其实也是 AI 编程时代对开发者能力要求的一次转移：从"会不会写代码"转向"会不会做判断"。

善用测试

很多人担心 AI 写的代码里藏着漏洞，于是想着要逐行审核 AI 产出的每一段代码。

这种做法就好比，你是一个团队的负责人，你担心下属做事不靠谱，于是事无巨细地审核他做的每一个步骤、每一个动作。抱着这种心态做事，凡事都要亲力亲为、事必躬亲，团队是无法真正做大做强的——你的精力终究是有限的，靠人力审核代码的方式，在 AI 一天能产出几千行代码的效率面前，根本跟不上节奏。

更靠谱的做法是：你不需要审核 AI 写的每一行代码，而是让它把测试写好，包括单元测试和集成测试。

具体来说，你可以规定测试用例必须覆盖所有需求涉及的功能点，并且要求每一次代码改动之后，所有单元测试都必须通过。你只需要把控好测试用例的设计和覆盖的业务场景，剩下的交给测试去验证——只要测试真实、全面，并且全部通过，这种质量保证方式其实比你自己肉眼扫一遍代码要靠谱得多，也快得多。

换句话说，AI 编程时代，测试不再只是"锦上添花"的工程规范，而是你和 AI 之间建立信任的核心机制。你把关的对象，从"代码写得对不对"变成了"测试设计得全不全"，这本身就是一种能力升级。

最后

AI 编程普及之后，初学者不必再从零开始死磕基础语法，也不需要逐行审核 AI 写出的每一行代码——这两件事，在过去是程序员的立身之本，但在今天，它们的重要性正在被重新评估。

真正值得花时间投入的，是做好技术选型、设计合理的技术方案，同时让 AI 承担起单元测试和集成测试的编写工作，并且明确规范好 AI 编程的验收标准。这三件事做扎实了，AI 才能真正成为你的生产力放大器，而不是一个让你提心吊胆的黑盒。

随着工作经验的增长，你会逐步掌握所在技术栈的完整知识体系——从框架到数据库，从消息队列到部署运维——这个过程本身，就是从"会用 AI 写代码"到"能驾驭 AI 做工程"的进阶之路。走到这一步，你依然会是一名优秀的程序员，只是你的核心竞争力，已经从"熟练敲代码"变成了"精准做判断"。

Flutter Windows 开始支持 Impeller ，还修复了多窗口 bug

恋猫de小郭 — Mon, 13 Jul 2026 01:03:44 GMT

因为这段时间一直在使用 Flutter 多窗口的原因，有一个 windows 多窗口的 bug 一直挺难受的，就是在切换到项目子窗口的时候，会默认激化主窗口，之后才能再次点击回到子窗口：

更准确说是，就是激活一个 child RegularWindow 后，主窗口会重新回到前台并盖住它。

这个问题的诱因很多，但是实际上主要就是代码写的太草台。

原因之一是在 Engine 里，Engine 收到 Windows 的 WM_ACTIVATE 消息时，不管窗口是激活还是失活，都会执行：

FocusRootViewOf(this);

也就是让当前窗口里的 Flutter view 获得焦点，但是问题在于，当主窗口正在失去焦点时，它也会执行这句，然后就导致主窗口本来应该退到后面，然后又主动 SetFocus 自己，然后 Windows 又把主窗口重新激活并拉到最前面。

这个 Bug 就算了，主要是 Flutter framework 还把多个窗口的 focus tree 挂错了层级，Flutter 的多窗口里，每个窗口都有自己的 View ，但 Framework 里子窗口的 FocusScope 居然还会有挂在父窗口的 FocusScope 下面的情况，这样会造成一个新问题：

子窗口获得焦点时，主窗口的 focus scope 也被认为“有焦点”，然后主窗口又又又通知 engine：“我有焦点了，把我的 native window 激活”，然后又又又又会把主窗口拉到前面····

而且整个过程，也没有判断是否已经有另一个窗口拿到焦点，这就导致这个 Bug 是综合好几个地方导致，之前好久一直没能根本修复问题。

一直只能写兜底代码来强切。

不过针对这三个问题，最近终于修复了：

如果收到的是 WA_INACTIVE，也就是窗口正在失活，就直接返回，不再抢焦点
每个 View 的 focus subtree 直接挂到全局 root scope 下
只有在没有其他窗口申请焦点时，才恢复旧焦点

然后在我合并完这部分代码之后，马上又躺了另外一个坑：Flutter windows 开始启用 Impeller 了，是的，Flutter 开始在 Windows 上用 OpenGLESSDF 适配 Impeller 了：

然后问题又出现了，在绘制 canvas 的时候，出现了细线看起来比 Skia 粗约 1.3–1.6 个物理像素的情况，而且更暗：

如果叠加 alpha ，还会直接失效，这些以前在我项目里若隐若现的细线，在 Impeller 出来后直接就变成又大又粗：

根据 issue 的计算，目前不同的粗细在 Impeller 上变化倍率也不一样：

笔画宽度 (logical→physical)	Skia 覆盖度	Impeller 覆盖度	倍数
0.5 → 0.75 px	0.75	2.00	2.7×
1.0 → 1.5 px	1.50	2.78	1.9×
2.0 → 3.0 px	3.00	4.59	1.5×
4.0 → 6.0 px	6.00	7.50	1.25×

而且粗细还不是主要问题，主要问题是：

在 canvas transform 缩放下，AA 边缘也跟着被放大，导致缩放比例越大线条越糊（zoom=4 时 0.5px 线变成 12px 宽模糊带）
Alpha 值被完全忽略：0xCC 和 0x66 渲染结果像素完全一致
极细线在某些情况下整条消失

这个问题看起来像是 Impeller 的 SDFAlpha 实现有问题， smoothstep 范围是固定的物理像素宽度，比如 smoothstep(-fade_size, fade_size, sdf) 会在笔画边缘两侧分别产生约半个 pixel_size * aa_pixels 的渐变过渡带，而这个过渡带是固定宽度（取决于 aa_pixels 参数，代码中设置为常量）。

然后对于 Skia 这样的解析式 AA，覆盖度 = 笔画宽度，但是对于 SDF 的 smoothstep，覆盖度 = 笔画宽度 + 固定边缘过渡带，所以当笔画只有 0.75 物理像素宽时，这个固定的 ~1.2px 过渡带就变得很明显，导致渲染出来的线是"实心宽线 + 两侧晕染"。

另外 float half_stroke = max(stroke_width, base_pixel_size) * 0.5 的最小宽度钳制没有补偿 alpha ，当 stroke_width < 1 像素时，这里会把宽度强制钳制到至少 1 个像素（base_pixel_size），但没有按比例降低 alpha 来补偿。

而Skia 的做法是亚像素线宽：把线变成 1 像素宽但按比例降低 alpha（0.75px 线 ≈ 38% 不透明的 1px 线），Impeller 的 SDF 实现直接给了满 alpha 的 1px+ 宽线，所以看起来更暗更粗。

也就是 SDFStroke 根本没有把 alpha 纳入计算，alpha 值到 fragment shader 时已经在别处处理，没有和宽度钳制联动。

目前暂时缓解的办法有：

用 drawRect 替代 drawLine ：用高度等于期望线宽的 filled rect 代替 stroked line，fill 路径的 UberSDF 覆盖度是正确的
强制使用 Skia：--no-enable-impeller
1px 整像素线宽：用 1.0 物理像素宽的线

目前看来，Impeller 在 Windows 上估计还是要经历一次 Android 的问题，不得不说，自渲染的维护成本确实高，不过多窗口在 Windows 上确实也可以用了，自从 bug 解决之后，基本没什么大问题了。

链接

github.com/flutter/flu…

没写一行代码！我用 ChatGPT 5.6 (Sol) 做了一个智慧充电站 3D 大屏

柳杉 — Mon, 13 Jul 2026 00:32:54 GMT

先说结论。

从设计稿到能在浏览器里打开、点击充电桩弹出状态面板的 3D 可视化大屏，我没有写任何一行代码，没有在 Blender 里手动拖过一次控件，也没有切过一张图。

整条链路交给了 ChatGPT 5.6 (Sol)。

但这篇文章不是来吹 AI 有多厉害的。我想说的是：这条路上我踩了哪些坑，以及为什么同样的工具，用法不同，结果差了十万八千里。顺便对有了大屏设计稿还不够，我又用Gpt-image-2把里面的素材全扒了出来这篇文章做一个补充和资源切割提示词的修复。

这个是我最终实现的网页效果，我觉得效果还行。

四个步骤，每一步的输入都是上一步的输出

链路本身不复杂：

设计稿 → 切割透明素材 → Blender 自动建模 → 3D 大屏网页

工具组合是 Codex（ChatGPT 5.6 (Sol)）、blender、blender-mcp、还有一个是我之前做的 @lius1314/visual-dashboard-scaffold 的大屏脚手架。

听起来很顺。实际上还是碰到很多的问题的，那我们按照步骤来看看整体流程遇到的问题和如何解决的吧。

第一步：设计稿

设计稿不是一次成型的，来回定了好几轮。先是照着一张暗色科技等距沙盘风格的参考图生成第一版充电站概念图，看完觉得质感不够，又重做成最高画质的 16:9 版本。到这一步设计稿已经能用了，但为了配合后面的切图流程，我又单独出了一版预留透明背景的稿子——因为素材切割终归是要把图标、边框从背景里挖出来，源头设计稿如果本身没有为分离预留干净的边界，后面怎么切都费劲。

上面的设计稿是主体蓝的，我觉得做这种太多了，然后它的界面我觉得太大众了，所以我就重新设计了设计稿，下面的暗黑色的是我觉得还不错的。

这一步花的时间不算少，但没出什么坑，跳过不细说，直接进第二步。

第二步：切图

第一版，27 个素材，全部白切

设计稿定稿后，我让 Codex 按坐标把图标、卡片边框、分割线抠出来。提示词是使用之前这篇文章的提示词有了大屏设计稿还不够，我又用Gpt-image-2把里面的素材全扒了出来 —背景色 #0B1426，抠出图标和边框，校验一下尺寸和 RGB。

跑出来 27 个素材，数字上什么都对：12 个图标、7 个卡片外框、6 个装饰件，尺寸和颜色校验全部通过。

然后我把它们贴到页面上。

图标放大到 200%，全是虚的。原图里很多图标本身只有二三十像素见方，切图脚本直接插值放大凑数，边缘发糊，内部镂空的地方糊成一片。更离谱的是背景压根不透明——贴到页面上，只要页面背景和 #0B1426 差一点，图标周围就多出一圈矩形色块，像贴了一块膏药。

27 个素材，等于白切了。

后来我想明白了。当时的提示词里有一句"RGB 无 Alpha、#0B1426 背景色校验"——这句话自己就打架。既然要求 RGB 无 Alpha 通道，背景只能是实色，根本谈不上透明。模型照着这句话做，做出来的东西完全符合要求，但就是没法用。

这不是模型的问题，是我的问题。提示词只写了要做什么，没写怎么判断做得够不够好。没有判定标准，模型就会挑最省事的路走——插值放大代替清晰，实色背景代替真透明，给你一个看起来合格的结果。

第二版，把"验收标准"写进提示词

我没有在原来的提示词上打补丁，直接推倒重写。核心变化就一个：把"描述任务"改成"描述任务 + 每一步验收标准"。

透明度按死：图标、卡片底板、标题背景、分割装饰，全部必须输出 PNG-32 RGBA，空白区域 Alpha 必须为 0。白底、黑底、棋盘格伪透明，全部列为禁止项。

清晰度分路处理：原图主体大于 64 像素、轮廓还看得清，走精确抠取，保留原始像素；原图本身就糊，走受约束的高清重建——但只能照着原图的外轮廓、比例、线宽去理清边缘，不允许凭空加纹理，不允许加原本没有的细节；要是连重建的依据都不够，直接跳过并说明原因，不硬凑一个将就能用的版本。

验收动作也写进流程里：每个素材切完，分别放到纯白和纯黑背景下看边缘有没有残留描边，再用透明棋盘格确认 Alpha 通道是不是真的生效。以前这一步靠人工事后抽查，现在模型给结果之前先自查一遍。

另外定了一条硬规矩：一图一资产，每个元素单独成文件。之前模型有时候图省事把图标拼成一张宫格图，这版直接禁掉。

用新提示词跑下来，20 个素材，四角 Alpha 全部为 0，白底黑底验边全部通过。

这里就列举了一些，貌似切割的资源还是不是很超清，但是已经很够用了。

拉开效果差距的，不是换了更强的模型，是把验收标准写进了提示词。这句话值得记一下。

下面是新的切割素材资源提示词，需要的可以自取

# 高级 UI 资产透明拆解专家 v5.1

> 输入：一张完整的可视化大屏设计稿（通常为 1920×1080 PNG）
>
> 输出：按批次拆分、可直接用于前端项目的独立透明 PNG 素材

你是一名专业的 UI 资产拆解与图像抠取专家。你的任务是识别设计稿中的可复用视觉元素，将它们逐个分离，输出轮廓清晰、边缘干净、背景真实透明的生产级素材。

---

## 最高优先级硬约束

以下规则优先于本文其他要求；发生冲突时，以本节为准。

1. **真实透明**：除 BATCH-05 外，全部输出 `PNG-32 RGBA`。元素外区域的像素必须为 `Alpha=0`。
2. **禁止伪透明**：严禁使用白底、黑底、深色底、纯色底或棋盘格模拟透明；棋盘格只能出现在预览界面，不能被写入图片。
3. **一图一资产**：每个文件只包含一个独立元素。禁止输出宫格、拼图、联系表、带标签的预览板。
4. **清晰优先**：禁止把低分辨率裁片仅靠 Lanczos、双三次插值或锐化放大后冒充高清素材。
5. **忠实原稿**：保持元素的轮廓、比例、颜色、线宽、光效、透视和视觉含义，不得改变设计语言或添加原稿中不存在的细节。
6. **边缘无污染**：发光、阴影、羽化、抗锯齿必须正确过渡到透明，不能残留原设计稿底色形成深色描边、色边或矩形光晕。
7. **无法保证则不输出**：若当前工具不能导出真实 Alpha PNG，必须停止并明确说明，禁止用带底色图片代替。

---

## 任务指令

基于上传的设计稿，每次只处理一个批次，严禁混合输出：

- 【BATCH-01】通用图标：功能、状态、导航、UI 图标
- 【BATCH-02】卡片底板：空心边框、信息容器
- 【BATCH-03】标题背景：标题底板、标题装饰条
- 【BATCH-04】分割与装饰：线条、角标、科技装饰
- 【BATCH-05】模块背景：大面积分区底板、整体背景
- 【RESCAN】补扫：提取指定批次中遗漏的元素

每个视觉元素只能归入一个批次，禁止重复提取。

---

## 输出常量

| 项目 | 要求 |
|---|---|
| BATCH-01～04 背景 | 真透明，空白区域 Alpha=0 |
| BATCH-01～04 格式 | PNG-32 RGBA，sRGB |
| BATCH-05 格式 | PNG-24 RGB 或 PNG-32 RGBA，按原稿保留 |
| 安全边距 | 5%～10%；最小 8px；发光元素最小 16px |
| 图标画布 | 256×256px；主体占画布 70%～85% |
| 文件命名 | `{batch编号}_{序号}_{英文描述}.png` |

原设计稿底色只用于识别元素和消除边缘污染，不得写入 BATCH-01～04 的最终图片。

---

## 统一拆解流程

每个资产必须依次完成以下步骤：

1. **定位**：从上到下、从左到右扫描，记录元素在原图中的位置。
2. **判类**：根据元素的主要功能分配批次，不按颜色或大小随意归类。
3. **判定独立性**：仅提取轮廓完整、未被遮挡、可与周围内容分离的元素。
4. **选择处理方式**：
   - 原图足够清晰：执行像素级精确抠取。
   - 原图过小或已有明显像素化：执行一次“受约束高清重建”。
5. **去除背景**：删除元素之外的所有像素，使空白区域 Alpha=0。
6. **边缘净化**：消除原大屏底色造成的色边，同时保留合理的半透明抗锯齿和光效。
7. **规范画布**：等比缩放、居中放置、保留透明安全边距，严禁拉伸。
8. **双底检查**：分别放在纯白和纯黑背景上检查边缘，再用透明棋盘格确认 Alpha 通道。
9. **独立导出**：每个元素输出为一个单独 PNG 文件。

---

## 清晰度处理规则

### A. 像素级精确抠取

符合以下条件时使用：原图中元素主体短边 ≥64px，且轮廓、细线和内部镂空清楚可辨。

- 最大限度保留原始像素和原始视觉效果。
- 不做风格化、重绘、过度锐化或对比度增强。
- 如需缩放，仅进行一次等比高质量重采样。

### B. 受约束高清重建

仅在元素短边 ＜64px、明显模糊或放大后无法使用时启用。

- 原图是唯一视觉依据，重建的是同一个图标，不是创作相似图标。
- 必须锁定：外轮廓、长宽比例、内部结构、线宽关系、颜色、渐变方向、发光强度和朝向。
- 仅恢复清晰边缘与连续线条，不得增加纹理、符号、层级或装饰。
- 简单线性图标应具有稳定线宽、连续轮廓和干净内孔。
- 禁止用加粗描边、强锐化、过度发光或提高对比度制造“清晰”假象。

若无法忠实重建，应跳过该元素并说明原因。

---

## 复杂元素归类规则

1. 传递功能或状态含义 → BATCH-01
2. 用于容纳或框住内容 → BATCH-02
3. 专门服务于标题区域 → BATCH-03
4. 用于分隔、角部点缀或科技装饰 → BATCH-04
5. 构成大面积区域整体底图 → BATCH-05
6. 与文字、图表或其他元素严重粘连且无法可靠分离 → 跳过

---

## 分批次规则

### 【BATCH-01】通用图标

属于：独立功能图标、状态图标、导航图标、UI 操作图标。

不属于：图表数据点、标题装饰、卡片角标、与卡片不可分离的业务图形。

要求：

- 每个图标输出为独立的 256×256px 透明 PNG。
- 图标主体在画布内视觉居中，占画布 70%～85%，不得贴边。
- 保留完整轮廓、内孔、细线、发光和阴影；不得断线、粘连或堵孔。
- 不得把原图中包含底色的矩形裁片直接作为输出。
- 不得包含任何文字、数字、水印、名称或编号。

逐图验收：

- [ ] PNG 为 RGBA，四角像素 Alpha=0
- [ ] 透明区域没有白底、黑底、深蓝底或棋盘格像素
- [ ] 白底和黑底预览均无矩形底、深色边、杂色边或异常光晕
- [ ] 100% 显示清晰；200% 显示时轮廓连续、细线无断裂、内孔未堵塞
- [ ] 图标形状、颜色、比例和视觉含义与原稿一致
- [ ] 文件内只有一个图标且无文字

### 【BATCH-02】卡片底板

属于：完整边框容器、独立面板外框。

不属于：标题栏、模块整体背景。

要求：

- 只保留外边框、科技角、描边、边缘发光和多层装饰结构。
- 移除标题、文字、数字、图标、图表、数据和内部填充。
- 容器外部与中心区域均须真实透明，形成可直接叠加的空心边框。
- 输出宽度 ≥512px，高度等比，透明安全边距完整。

### 【BATCH-03】标题背景

属于：标题区域底板、标题装饰条。

不属于：完整卡片边框、独立角标。

要求：

- 移除所有标题文字，仅保留装饰底板。
- 保留复杂轮廓、渐变、节奏线条和两端渐隐。
- 渐隐与发光必须自然过渡到 Alpha=0。
- 输出宽度 ≥640px、高度 ≥128px。

### 【BATCH-04】分割线与装饰

属于：独立分隔线、科技线条、角标装饰。

不属于：卡片边框的一部分、标题装饰条。

要求：

- 线条和角标必须分别独立导出。
- 保留线条端部羽化，并自然过渡到 Alpha=0。
- 水平线长度 ≥512px；垂直线高度 ≥512px；角标画布 ≥128×128px。

### 【BATCH-05】模块背景

属于：大面积分区底板、整体面板背景区域。

要求：

- 保留纹理、网格、渐变和发光轮廓。
- 移除文字、数字、图标、图表和业务内容。
- 最小输出 1920×1080；若原图更大则保持原始尺寸。
- 本批次本身是背景层，可保留原稿背景，不受透明背景硬约束。

---

## 排除条件

遇到以下情况应跳过并说明，不得强行输出劣质资产：

- 元素被遮挡、被画面边缘截断或与其他元素无法可靠分离
- 去除文字后无法合理恢复底层结构
- 原始信息不足，无法忠实重建形状或内部结构
- 去背景后出现无法消除的严重色边、断线或透明孔洞
- 输出仍包含文字、数字、业务数据或其他批次元素

---

## 不合格重做条件

以下任一条件成立，必须重做：

| 检查项 | 不合格条件 |
|---|---|
| 透明背景 | 四角任一像素 Alpha≠0，或存在纯色底/棋盘格底 |
| 边缘污染 | 白底或黑底预览出现原背景色描边、杂色边、矩形光晕 |
| 清晰度 | 100% 即可见模糊；200% 出现断线、堵孔、双重边缘或严重锯齿 |
| 忠实度 | 轮廓、比例、颜色、线宽或视觉含义偏离原稿 |
| 完整性 | 发光、阴影、羽化或边角被裁切 |
| 内容纯净 | 存在文字、数字、水印、标签或其他无关元素 |
| 文件组织 | 多个元素被合并到同一张图 |

---

## 数量与命名

- 单批次每轮最多输出 12 个资产。
- 文件命名格式：`{batch编号}_{序号}_{英文描述}.png`。
- 示例：`b01_03_settings-icon.png`、`b02_01_card-frame-large.png`。
- 达到 12 个时停止并提示：

> 本批次已提取 12 个资产。回复「继续」提取剩余元素，或指定新批次。

---

## RESCAN 补扫模式

触发示例：


补扫 BATCH-01，左侧面板第 3 个图标未提取


仅提取明确指出的遗漏元素，不重复已完成资产；仍须通过原批次全部透明度、清晰度和忠实度检查。

---

## 每轮文字报告

报告内容不得写入图片。完成一批后，在回复中逐项列出：

1. 文件名
2. 元素在原图中的位置
3. 处理方式：`精确抠取` 或 `受约束高清重建`
4. 输出尺寸
5. Alpha 检查结果
6. 白底/黑底边缘检查结果
7. 被跳过元素及原因

---

## 启动方式

请上传设计稿并指定批次，例如：


开始 BATCH-01


可选告知原大屏底色，它只用于去除边缘底色污染，不会写入最终透明资产。

第三步：建模与烘焙

设计稿切完，四周的图标、边框、分割线交给前端 UI 层；中间那块 3D 场景插画不进前端，拿去给 blender-mcp （地址获取 github.com/ahujasid/bl… Codex 照着它在 Blender 里自动建模。

先验证了一下连通性，让 Codex 在场景里建一个正方体，确认 MCP 通道能跑通。通了之后，拿设计稿中间那张暗色科技等距沙盘图重新生成一张更完整的充电站参考图，然后让 Codex 照着这张图逐个模块建出来：场地底座、光伏顶棚、充电桩、车辆、储能电池舱、变压配电设备、控制室、发光地面线路、悬浮 UI 面板。整个过程不用人工在 Blender 里手动操作，Codex 通过 MCP 下发的是可重复执行的建模脚本，哪里不对改脚本重跑，不用从头摆一次场景。

第一版模型的问题：形状对了，没有质感

建出来之后感觉哪里不对，但说不清楚。盯着看了一会儿才反应过来：材质是平的。金属没有高光，地面纯色没有微纹理，玻璃没有透射，车漆像塑料——整个场景像是一个精确的玩具，而不是一个真实的场地。

重做时把 PBR 材质流程补齐：金属件的金属度和粗糙度分开调，地坪加微纹理，玻璃做透射，车漆加清漆层，光伏板加反射。建模颗粒度也往上拉，最终建出来一千多个对象，四辆车、四套充电桩、双排储能柜、冷却设备、线槽都单独建出来，不再用简化的占位模型糊弄。

烘焙前先分组，别等前端接入了才想起来

模型精细了，但没法直接扔给前端实时渲染——这么多物体的 PBR 材质，帧率根本扛不住。所以要把光照和材质信息烘焙成贴图。但烘焙也有讲究，不是一把梭全烘成静态图就完事。

在烘焙之前，我先按"将来要不要交互"把所有物体分了一次组。会被点击的——车辆、充电桩、终端机、电池柜、服务器、变压器、控制台，二十多个根节点，各自单独烘焙贴图，保留独立材质通道，前端可以单独控制它们的高亮和状态切换。纯粹是背景的——地面、建筑主体、光伏顶棚、固定附件，按区域合并成几组图集一起烘焙，减少渲染开销。

每组贴图统一导出 BaseColor、Normal、ORM、Emission 四张。ORM 这张把 AO、粗糙度、金属度分别塞进 RGB 三个通道，前端一张图拿到三种材质信息。玻璃部件要保留透射效果，没有参与合并，单独留成透明子物体。

这一步的判断标准只有一条：凡是交互逻辑会碰到的物体，宁可多花烘焙成本也要保留独立性；纯粹填场景的，能合并就合并。这个分组做在烘焙阶段，而不是等到前端接入时再补——正是因为提前想清楚了，后面接脚手架的时候基本没有返工。

最终实测：源 GLB 约 77.3 MB，Web 优化后压到 25.32 MB，107 张内嵌 WebP，贴图最大边 1024，23 个交互根节点完整保留。

第四步：拼成网页

前面三步产出的是三堆各自独立的东西：透明 UI 素材、烘焙好贴图的 Blender 场景、材质通道文件。这些东西要变成用户能打开的网页，还差一层骨架——页面布局、区块管理、屏幕自适应。这部分接了 @lius1314/visual-dashboard-scaffold 这个大屏脚手架(可以看这篇文章可视化大屏设计器脚手架：从设计到交付的一站式方案，如果你需要源码的话可以看这篇可视化大屏脚手架源码：一周下载突破 700，为什么这么多人选它？)，一个不绑定具体图表库的 React 大屏容器，默认 1920×1080，跟前面切图流程里素材尺寸的约束刚好对得上。

业务图表或者 3D 场景不用改脚手架源码，通过 registerBlock 把组件注册成一个区块 ID，脚手架负责区块的拖拽、缩放、层级和样式；预览模式下接 autofit.js 做整体等比缩放，边调边看，不用来回换分辨率去试。

烘焙阶段做的那个分组在这里起作用：中心 3D 场景包一层 Three.js 渲染组件挂到对应区块位置上，充电桩、储能柜这些单独烘焙过的物体各自是可交互对象；背景和建筑那部分只作为一张整体贴图渲染，不参与交互逻辑，渲染开销压得住。

切图流程产出的图标、边框、分割线，按脚手架约定的静态资源目录放进去就能用。信息卡片、告警列表、能耗曲线这些常规区块，是标准 React 组件按区块 ID 注册。整套配置最后导出成 JSON 作为初始配置加载，后面调布局不用改代码，直接在编辑模式里拖。

最后

做完这整条链路，我觉得有两件事值得单独拎出来说。

第一件事，提示词里有没有验收标准，决定了你拿到的是素材还是无法使用的。没有可执行的判定标准，模型永远挑最省事的路。它不是在糊弄你，它只是在照章办事——你说的章，本来就没写清楚。把验收标准显式写进提示词之后，产出质量的提升比换一个更强的模型明显得多，这让我多少有点意外。

第二件事，前期的分层决策，决定了后期的返工量。烘焙阶段有没有提前想清楚哪些物体将来要被点击，直接决定前端接入时要不要重来一遍。做在正确的时间点，后面每一步都会顺；做晚了，代价是把整个场景重新烘焙一遍。

Codex（ChatGPT 5.6 Sol）在切图、生成参照图、下发 Blender 建模脚本这几个环节都能给出结构化、可执行的结果，中间不需要人再补细节。这是整条链路能接起来的前提。但前提之外，还是得自己想清楚每一步要的是什么。

另外发现 gpt5.6 sol在 3D建模方面还是不能真正的还原设计图，也没有做到那种工业级的质感，不过做的模型确实也很不错了，未来可期。

预览地址：liush.top/solar-stora…

如果你需要源码参考的话，可以来 柳杉前端 公众号同名文章自取哈。

中后台越做越乱后，我用插件化把它救回来了

知航驿站 — Sun, 12 Jul 2026 15:37:34 GMT

背景

公司里前端项目不少，我也试过几种组织方式，最后留下来的是这套插件化方案。原因不复杂: 商城、系统设置、报表这类模块边界已经很清楚了，继续全塞在宿主里，后面只会越来越乱。所以我把宿主收回到启动、布局和全局守卫，把业务域拆成 packages/plugin-*，再让插件通过统一协议交出自己的路由、菜单、多语言和初始化逻辑

文档地址、演示地址、源码地址

插件协议怎么定

export interface AdminPlugin {
  id: string // 插件唯一标识
  name: string // 插件名称
  version: string // 插件版本
  enabled?: boolean // 默认是否启用
  order?: number // 注册顺序
  dependsOn?: string[] // 依赖的插件 id
  routes?: AdminRouteRecordRaw[] // 插件提供的路由
  menus?: MenuConfig[] // 插件提供的菜单
  locales?: {
    'zh-CN'?: Record<string, any>
    en?: Record<string, any>
  } // 插件自己的语言包
  install?: (app: App, context: PluginContext) => void | Promise<void> // 初始化钩子
}

我比较在意的一点是，插件要把自己的边界说清楚，而不是嘴上说自己是“独立模块”，代码里还在不停伸手改宿主，所以后面的插件架构要设计好，大概做了以下功能点

项目预览

插件功能点

📦 定了一套统一的插件协议，把 id、name、version、enabled、order、dependsOn、routes、menus、locales、install 这些字段先收口
🔢 插件注册排序，用 order 控制接入顺序
🟢 默认启用控制，通过 enabled 配置插件初始状态
🔗 依赖声明和依赖校验，避免插件在缺少前置模块时硬挂进来
🛡️ 冲突检测，主要拦重复插件 id、路由 path / name 和菜单 path
🧭 插件路由注册，把页面入口统一挂到宿主路由系统
🗂️ 插件菜单收集，把各业务插件的导航配置汇总到宿主
🌐 语言包合并，让插件自己的 locales 能注入到宿主
🪝 install 钩子，方便插件做自己的初始化
📋 运行时插件清单，宿主能拿到当前注册过的插件信息
🔌 插件启停能力，支持在运行时打开或关闭某个插件
💾 启停状态持久化到 localStorage
🔄 刷新后恢复插件状态，宿主重新引导时继续使用本地启停结果

一个插件长什么样

const reportPlugin: AdminPlugin = {
  id: 'plugin-report',
  name: '报表插件',
  version: '1.0.0',
  order: 20,
  dependsOn: ['plugin-shop'],
  routes: [
    {
      path: '/report/list',
      name: 'ReportList',
      component: () => import('./views/ReportList.vue'),
      meta: {
        title: 'report.list',
        layout: 'default',
        permissions: ['report.read']
      }
    },
    {
      path: '/report/detail/:id',
      name: 'ReportDetail',
      component: () => import('./views/ReportDetail.vue'),
      meta: {
        title: 'report.detail',
        layout: 'default',
        permissions: ['report.read'],
        activeMenu: '/report/list',
        noCache: true,
        hidden: true
      }
    }
  ],
  menus: [
    {
      path: '/report',
      title: 'report.title',
      icon: 'chart',
      children: [
        {
          path: '/report/list',
          title: 'report.list'
        }
      ]
    }
  ]
}

这段代码最关键的地方，不是“能跑起来”，而是它把自己该交给宿主的信息一次性带齐了。宿主看到这个插件，基本就知道要把什么东西接进去。

最后

做到这里之后，我最直接的感受就是，新增一个业务模块时，接入方式终于稳定下来了。对我来说，这就够了。至少这个中后台后面继续长的时候，不会再回到什么都往宿主里塞的状态。

掘金本周最热

前端圈7月大地震：TS 7发布、Bun 11天从Zig迁Rust、Kimi K3登顶、大厂裁员50%

前端圈7月大地震：TS 7发布、Bun 11天从Zig迁Rust、Kimi K3登顶、大厂裁员50%

一、7月8日：TypeScript 7.0正式发布，14年来最大变革

1.1 性能数据：最高12倍

1.2 为什么能快10倍？

1.3 升级方式：一行命令

二、Bun 11天从Zig迁到Rust：78万行代码，100%通过

三、7月16日：Kimi K3发布，Frontend Code Arena登顶

四、Gemini 3.5 Pro泄露：前端“一次成型”

五、大厂裁员：飞猪传前端裁撤50%

六、同一时期：还有四件大事

6.1 Deno 2.9发布：前端框架直接打包成桌面应用

6.2 Vercel skills狂揽2.4万星

6.3 HeroUI v3正式发布

6.4 Yuku开源：Zig重构前端工具链

七、把七月这些事放在一起看

趋势一：前端工具链正在“全面换芯”

趋势二：AI正在重新定义“前端开发”

趋势三：裁员与技术突破并存

趋势四：AI编程能力正在“中国化”

写在最后

停更的这一年，All In AI、陪媳妇生娃、还考了个研

停更的这一年，All In AI、陪媳妇生娃、还考了个研

曾经人手一个的Superpowers，为什么现在都在卸

🔹 先说说Superpowers到底干了什么

🔹 25万星标背后的代价

🔹 不止是慢，它还可能让Agent变蠢

🔹 最让我觉得有意思的一个对比

🔹 那Agent到底变强了多少

🔹 这其实是一个很经典的规律

🔹 但我不是说skill完全没用了

🔹 说到底

Harness 企业级落地(二) - 让 AI 读懂项目

一、顶层设计思维

二、基于 git submodule 的项目结构

三、让 AI 深度读懂整个项目

1. 前置介绍

2. 四大原则

3.最佳实践

四、初始化产物

五、初始化后，如何执行任务

六、快速接入

七、写在最后

掘金VibeLaunch 沸点秀 来啦🚀

✅ 参与方式

📅 参与时间

📮 内容参考

🎁 奖励清单

🏅 评选标准

☝️活动规则

不自己造轮子：在小艺开放平台搭一个真实的健康小助手

新建项目，先卡在选哪种模式

名字和描述先填

开场语、角色指令，填的时候右边就在预览

提示词只是一小块，插件和知识库才是重头

上架前要过合规这一关

调试面板里问了两个问题

没测完的地方

Oracle 迁移评估时，我把这两类问题列在了检查清单最前面

先搭场景：客户表和客户等级表

陷阱一：(+) 语法本身没毛病，加个条件就变味了

陷阱二：空字符串算不算 NULL，得看这一套环境怎么配置

迁移避坑清单

Vue 和 React 真正的差距，不在语法，而在团队犯错成本

极其自由的 React

依赖数组与自动追踪

组件重新渲染引起的问题

咱们必须得承认团队的平庸🫡

Codex 小白入门：从安装到插件、MCP、Skills，一篇把配置讲明白

Codex 小白入门：从安装到插件、MCP、Skills，一篇把配置讲明白

你先记住一句话

第一步：先把 Codex 装起来

1. Codex Desktop App 怎么安装

2. Codex CLI 怎么安装

第二步：理解 AGENTS.md

第三步：理解 config.toml

第四步：Plugins 是什么

第五步：Skills 是什么

第六步：MCP 是什么

掘金VibeLaunch 沸点秀来啦🚀

陷阱一：`(+)` 语法本身没毛病，加个条件就变味了

第二步：理解 `AGENTS.md`

第三步：理解 `config.toml`

1. 项目根目录 `AGENTS.md`

2. 全局 `config.toml`

1. 把 `AGENTS.md` 写成散文

Agent 开发主流 skills推荐