差不多四个半月以来，我的网站一直披着TRANSMISSION那层外壳：深色、青色、琥珀色，刻意带着技术味。
藏青配炭灰的背景。青色点缀。玻璃质感的面板。我当初是故意这么做的。我在广告行业待了十八年。我四十岁的时候自学了写代码。我希望这个网站让这段转身被看见——任何一个落到博客页面、滑过站标、注意到那种开发者工具美学的人，收到的信号就是：这个人跨过去了。
它完成了它的使命。然后，它的任务就结束了。
趁着Memorial Day长周末，我上线了一次彻底的改版，看起来跟之前完全不像。亮色模式。温暖的纸质背景。用胭脂红代替了青色。细线条代替了圆角卡片。角落里有一个清晰可见的"Vol. 04 · Issue NN"——卷数是我开始公开记录所建之物以来的年份，期数是当前的ISO week，两个数字都会自动更新。你读到这篇的时候，那一行可能写着Issue 22、Issue 23或者Issue 41，全看你哪天落到这里。整个网站再也没有一个Sparkles图标。新版现在已经上线，在chandlernguyen.com。
我大可以专门写一整篇文章讲这些设计决定。但更有用的，是讲讲工作流。我把这次改版拆给了两个不同的AI模型。Claude Opus 4.7配合extended thinking负责设计。跑在GPT-5.5上、推理档位拉到最高的Codex负责执行。而Codex里那个/goal功能，让它能够在我出门散步或者吃晚饭的时候，自主连续跑接近四个小时。
四天。两个模型。差不多三十次commit。一个网站。
下面是我学到的——哪个模型适合做哪种事，以及边界目前还落在哪里。
为什么TRANSMISSION必须退场
过去两年，我从广告行业跨进了代码的世界。今年年初的时候，网站终于追上了我自己：我特地把它改成TRANSMISSION风格，就是要让这段跨越被看见。四个半月之后，这个信号已经发完了。
接下来的任务不一样。从博客文章、LinkedIn帖子或者Google搜索过来的访客，并不是为了确认"我会写代码"才来的。他们来，是为了了解AI在媒体运营里能做什么，是为了考虑要不要买课程，或者是为了把课程、Prova、DIALØGUE和STRAŦUM当作一个产品阶梯来比较。这个网站需要少一点"发信号"，多一点"做引导"。
最简单的说法是：旧网站是一个人格。新网站是一套运营模型。背后还是同一个人，但任务变了。这意味着审美也要变——更轻、更安静、更编辑化，让一篇长博客可以呼吸、让课程CTA显得诚实而不是推销味。用温暖的纸质感代替玻璃感。
但更难的不是审美。难的是吞吐量。这个网站有十三种语言、大概八个公开页面（首页、博客列表、文章页、products、learn、about、ask、课程销售页）、一条需要登录的课程访问流程、一个Stripe结账，以及一个Sydney RAG接口。要全靠手工重写，少说也得几周。我没有几周。
所以我把工作拆给了两个AI模型。
为什么要把设计和执行拆开
设计和执行是两种不同的认知任务。
设计是慢的。它是关于构图、关于克制的判断，是去琢磨某一种暖纸色在iPhone上是不是太黄、另一种是不是又太冷。它要先问*"这是一种什么样的界面？"，然后才轮到"那这一段怎么实现？"*。好的设计工作其实是在压缩时间——你想两个小时，做出一个决定，就帮你省下十个小时的执行。
执行是快的。它是模式应用。给一套设计系统，就能生成对应的组件。给一个组件，就能把它铺到十三种语言里去。给一个页面布局，就能交付各种变体。这活儿并不是更没技术含量，只是没那么暧昧。对照着spec，对的答案通常都站得住脚。
不同的AI模型，擅长的认知任务也不一样。从我过去几个月的亲身体验——先是Claude Opus 4.6，现在是4.7，两个都开了extended thinking——**Opus是更全面的伙伴。**它更擅长头脑风暴。它的设计判断更好。在纯代码上它慢一点、外科手术式的精准度差一些，但它回答之前会先把整个构图想一遍，它的推理方式能抓得到为什么一种字体显得太亲切、另一种才对。
**而开到高推理档位、跑在GPT-5.5上的Codex，感觉像一个能力很强、从来没靠近过设计部门的资深软件工程师。**它快。它在多步tool use上非常出色——打开文件、读文件、改文件、跑测试、再打开下一个。它对一个按钮是不是太高没有特别强的意见，但它会把按钮交付出来，并且毫无怨言地把按钮的每一种变体在十三种语言里都铺开。它的/goal功能允许你给它一个目标——比如说，"convert the v3 design tokens into the Next.js app, wire the new shell, ship working BottomNav, MobileAppBar, ReadingProgress, verify the build passes with the flag off"——然后你就可以走开。它会自己规划子步骤、执行、跑build、修复出错的地方、再继续。在这个项目里，它无人值守跑过的最长一段，差一点就到四个小时。
我得承认，一开始我并没有刻意要这样分工。在长周末之前的那几天，我已经跟Opus做过设计对话了。等长周末真正开始的时候，我手里已经有设计方向文档和桌面端原型了。周末本身，是我把执行交给Codex的时候，而我交出去不到一个小时，就注意到每个模型有多么适合自己那一半的工作。
Opus做了什么：设计阶段
设计工作是在重建之前那几天，跟Opus的一场长对话里发生的。这场对话产出了两个东西，现在都还留在仓库里：
1. 一份设计方向文档。 放在doc/v3-design/下面的六个markdown文件——为什么、设计token、移动端模式、页面规范、可访问性约束、执行计划。一万三千多字的决定，大部分是Opus根据我给它的brief写的。指令是："下一版网站要让人感觉像一本小型印刷杂志，不要像SaaS仪表盘。靠克制赢得注意力。把Operating Model 2×2框架当作视觉签名。"
2. 一份桌面端HTML原型。 平铺在public/design-prototype-v2/目录里，有六个页面和一个共享的style.css。没有React，没有Tailwind，没有框架——就是手写的HTML，让我可以在本地服务器上点开每一页，去感受这套设计系统到底站不站得住脚。这份原型之后整整一个周末都是视觉风格的真理来源。重建过程中只要不确定，答案就是"对齐原型"。
Opus做了最重要的那些决定。几个具体的瞬间：
-
字体的反向选择。 之前有一轮设计基于"可用性"和"实施容易"的理由把Manrope锁成了display字体——是在一次Claude Sonnet 4.6的会话里定下来的。十八个小时之后，我把设计对话搬到了开extended thinking的Opus 4.7，Opus上来第一件事，就是重新审视这个锁定。我花了一个晚上对照PP Neue Montreal的官方specimen页面去比字形，然后把切换提上去了。那一条commit message读起来像一份字体犯罪现场报告："Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." 有意思的地方在于，两个不同的Claude模型在同一个决定上给出了不同的判断。Sonnet选了安全选项。Opus选了对的那个。 -
胭脂红的选择。 青色是AI产品的默认强调色。Opus和我最后落在了胭脂红——
#c33824，一种印刷油墨般的红，是编辑在校样上的批注色，也是Loeb Classical Library书架上拉丁文卷宗的颜色。理由非常具体："the site is trying to feel editorial, not developer-tool. Cyan signals tech. Carmine signals craft. Use the carmine sparingly, always at high contrast, ideally on warm paper." 这不是一个执行导向的模型会主动去选的决定。 -
把Operating Model当成视觉签名。 我在课程里教的那个2×2框架——Automate / Protect / Deepen / Change——成了新网站上一个安静的品牌标记。在目前的实现里，它只克制地出现在两个地方：首页的thesis区块，以及长文章页上的一个小小thesis标记。框架本身是我自己的，但把它做成网站的视觉身份，这一步是从跟Opus的设计对话里冒出来的。
-
亮色优先。 Opus主张亮色模式是性格，深色模式是被支持的变体。理由：长文阅读，在暖纸色上比在玻璃质感上更轻松；价格标签放在亮色背景上感觉更诚实；几乎每个AI工具默认都是深色，所以亮色才是差异化。我反对了几个小时，然后同意了。
Opus基本上扮演的是设计和review的循环；具体落地的passes是Codex做的。Opus那一半工作，刚好是"慢"能带来收益的那一半。
Codex做了什么：执行阶段
设计文档和原型一就位，工作就交到了Codex手上。
我开了一个新的Codex会话，把设计方向文档喂给它当上下文，然后开始跑/goal会话。每一个goal都是一个有清晰终态的多步骤目标：
Goal: Convert the v3 design tokens from
doc/v3-design/components/tokens.cssintosrc/app/globals.css. Remove the conflicting TRANSMISSION tokens. Wire up the three new fonts viasrc/lib/fonts.tsandsrc/app/layout.tsx. Generate the v3 shell behind the feature flagNEXT_PUBLIC_ENABLE_V3_DESIGN. Ship a workingBottomNav,MobileAppBar, andReadingProgress. Verify the build passes and that no existing pages are visually affected when the flag is off.
这种多阶段的目标，正是/goal设计来做的事情。Codex自己规划子步骤、执行、跑pnpm build检查类型错误、修掉出错的部分、再跑一次build、然后继续。我散步回来，v3 shell已经在flag后面活在代码库里了，新字体加载好了，bottom nav在移动端也渲染出来了。
后续几个/goal会话：
- 从原型出发，生成v3的首页和归档页。
- 生成v3的文章页布局，包括阅读进度条和v3的分享按钮。
- 生成v3的products和learn页面，按照spec里的阶梯结构来。
- 把现有的课程销售页、登录、注册、MFA和访问页面在视觉上对齐到v3，底层的Stripe和Supabase Auth逻辑一行都不动。
- 把v3的课程页面和Ask Sydney页面翻译/本地化到所有十三种语言，翻译来源是已经存在的
messages/{locale}.json。
不需要人介入就跑完的最长一次是差一点就到四个小时。最短的大约四十五分钟。这四天里我交付了差不多三十个commit——大部分是Codex的第一次或第二次pass，再加上一些手动微调，那些是模型输出虽然正确、但形状不太对的地方。诚实地讲：我觉得今天在生产上跑的代码，大部分是Codex写的。剩下的部分由我自己写或改。
/goal最有用的地方不是速度。是自主性。我用AI工具跑过的大多数编程会话，都需要我守在键盘前——确认一处改动、接受下一个文件、看diff。/goal让你可以指定你想要的终态然后走开。你回来时要么是一个完成了的变更，要么是一个停在"模型需要你做一个判断"那一刻的暂停会话。工作的形状不一样了。你从单次编辑的保姆，变成了多小时会话的规划者。
边界目前还落在哪里
把设计和执行拆给两个模型，并不是什么魔法。还是有一些时刻，一个模型需要另一个；甚至有几个时刻，光靠两个都不够。
那个Sparkles图标。 Codex生成的v3移动端外壳很干净，在Ask那个tab上挂了一个Sparkles ✨图标——这是AI工具的万能信号。对照spec来看图标是对的；spec里没有写*"不要用这种俗套。"*我过了两天注意到这个，然后回到Opus那边讨论替代方案。我们走了好几轮迭代：先是Operating Model的标记，然后是一个胭脂红的Newsreader斜体问号——那种你可能在一篇老文章页边批注里看到的字符。最终方案是Opus的想法。Codex十五分钟就上线了。
日之丸时刻。 Operating Model的那个标记一直放在移动端app bar的左上角，紧挨着我的名字，我盯了它两三天。一个暖纸色方块上的小小胭脂红圆点。然后某天晚上，我用别人的眼光看它，心里咯噔一下。它看起来跟日本国旗一模一样。日之丸。淡色底子上的一轮小红日。Opus没看出来，Codex也没看出来。Opus设计了这个标记；Codex实现了它；两个都review过。这种视觉联想是一种文化模式，两个模型都看不到。我从站标里删掉了那个标记，去找了另一个解决方案。（之后那个Newsreader斜体的?刚好补上了Ask tab上的位置。）
十三种语言的铺开。 Opus本来也可以认真地为每种语言的UI细节做出周全的设计，但要花上好几天。Codex一个人没法做出那种设计判断，但一旦模式定下来，它一个晚上就能把所有十三种语言铺完。这是这种拆分最直白的例子：设计要慢，执行要快。
挑三种相互搭配的字体。 Opus选了Satoshi（display）、Newsreader（斜体强调）和JetBrains Mono（标签）。这种组合Codex一个人不会选——说实话，没有Opus在对话里那种慢，我自己也未必能选出来。三种字体的搭配是设计决定，不是执行决定。
两个系统之间的"对话"，是发生在我脑子里，不是发生在两个模型之间的。这是2026年还没法自动化的那一部分——我认为也正是这一部分，定义了当下"品味"是什么意思。
诚实地算一笔账
四天。差不多三十次commit。生产环境的v3已经在chandlernguyen.com上线。新网站正在做新工作——帮访客找到下一篇要读什么，而不是告诉他们"我已经跨过去了"。
网站还有一个我还在追的问题。写这篇草稿的时候，生产环境的Lighthouse mobile显示博客归档页落在4.6秒，而我本地Chrome DevTools trace上同一张图片只用了264毫秒就画出来——同样的代码，差别很大的网络模型。我目前最看好的修复方向是字体preload压力：三个被preload的webfont，加上三个会block render的CSS chunk，在被限速的移动网络上一起跟图片抢线。我在过去这一天部署了那个修复里"杠杆最小"的那一版，还需要新跑一遍Lighthouse来确认是否真的奏效。你正在读的这一篇，是在修复后数据出来之前写完的。
订阅成本：我那个最高档位的Codex订阅，加上原本就有的Claude Max订阅。加起来一个月几百美元。考虑到产出的吞吐量，这个价格算便宜。
v3之所以是四天而不是三周，主要原因就是设计阶段和执行阶段被分开了、并且各自交给了在那一半工作上更强的模型。我并不觉得这是普适的。有些项目一个模型就能两头都做；也有些项目两个模型都不是合适的伙伴。但对于一个多页面、多语言、多种界面、还带有强烈设计观点的改版来说，这种拆分是我下次还会去抓的工作流。
如果你最近做过自己的AI辅助重建，我很想听听你是怎么拆分工作的。你是从头到尾用同一个模型？你是像我这样按阶段拆，还是按别的轴拆——按组件、按文件、按任务类型？我觉得build in public的下一波手艺，重点会落在为哪一部分工作选哪一个AI，而不只是"你到底用不用AI"。
如果想看成品，你正在看的就是。首页在chandlernguyen.com。产品阶梯在/zh/products/。带出整套"operating model"想法的那门课程在/zh/learn/。
祝好， Chandler