默认的远程桌面RDP协议存在较多使用限制，不太适合AI进行远程调试的场景。通过为Windows系统开启SSH服务，可以显著提升AI的操作自由度，让它如同管理Linux服务器一样操控Windows环境。

一旦SSH服务启用，AI便能完成文件部署、命令执行、系统服务安装等一系列工作。简单来说，为Windows配置好SSH，就等于为AI打开了一道将Windows操作全面自动化的门户。

首先需要手动启用Windows的SSH服务：

打开“设置” → “应用和功能” → “可选功能”

随后启动服务：

服务启动后，可在AI代理中检测Windows SSH服务的运行状态：

确认服务运行正常后，即可让AI代理远程接管Windows。例如，编写一套SSH服务的一键安装脚本，并将其发送到远程系统中自动执行。

全文完。

模型坍塌？

2024年7月，《自然》封面刊登Shumailov等人的研究，首次系统性揭示模型坍塌（Model Collapse）现象：在完全封闭的递归训练下，AI模型到第九代便完全失真——从中世纪建筑输出异化为不存在的兔子物种。斯坦福2026年AI指数报告指出，互联网新发布内容中AI生成占比已达51.72%。AWS研究显示约57%的网络文本已被AI处理过。高质量人类文本数据最早可能在2026-2032年间耗尽。合成数据因成本优势（合成图像0.06美元 vs 人工标注6美元）成为行业倚仗。

在此背景下，“AI吃掉自己产出就会完蛋”的悲观论调被广泛传播。但身为产品从业者，我们需要穿透情绪化叙事，回到工程与产品的维度来剖析问题。

模型坍塌的三个认知误区

误区一：将极端实验条件等同于现实

《自然》论文的实验前提是完全封闭循环——每代仅使用上一代AI输出，零人类数据。这是理论极端条件，并不等同于现实场景。将极端条件实验结论直接外推到现实，无异于以偏概全。

误区二：忽视人类文明递归的类比

人类文明发展本身就是递归过程：绝大多数人使用少数人创造的成果，却未产生原创知识。但文明持续进步，根源在于人类建立了纠错机制。人类文明递归模型可概括为：少数人原创创造 → 多数人套用 → 纠错机制运转（实验验证/同行评议/现实反馈） → 知识迭代升级。中世纪经院哲学的教训：纯粹封闭递归（只引经据典不做实验验证）导致千年停滞。科学革命的突破：引入实验验证（真实世界锚定）带来文明起飞。递归本身不是问题，缺乏纠错机制才是关键。这一原则同样适用于AI。

误区三：忽视已有解决方案

2025年，上海交通大学LUMIA实验室联合清华、北大、北京智源研究院，提出“标记级编辑”（Token-Level Editing）方法，并发表在ICML 2025上。其核心不是拒绝合成数据，而是对合成数据进行精细化标记级修正，以保持真实数据的长尾分布特征。2026年5月，挪威科技大学和伦敦国王学院的研究团队在《物理评论快报》发文：训练中加入哪怕一条真实数据，就能有效阻止模型坍塌——即便这条数据远少于AI生成数据，即便生成数据无限增加。

产品框架：AI产品数据纠错机制设计

基于上述分析，可以提炼一套AI产品训练数据管线的设计框架，我称之为“数据锚定纠正智能监控模型”。

【数据锚定】——真实数据锚定

在每一代训练数据管线中，强制保留一定比例的真实人类数据作为锚点。产品设计要点包括：定义“真实数据”标准（人类创作、经权威验证、具有长尾分布特征）；设置真实数据比例硬杠杆（关键领域如医疗/法律/金融≥50%，通用领域≥30%）；建立真实数据来源管理（专业内容创作、UGC、权威数据许可）；设计真实数据新鲜度机制（定期补充新的人类数据，避免锚点过时）。产品决策层面，真实数据是稀缺资源，需要在成本和质量间权衡。建议按产品风险等级分级管理——高风险产品如医疗AI高比例锚定，低风险产品如娱乐AI可适当降低。

【纠正】——迭代纠错

在训练循环中嵌入纠错环节，确保每一代训练后进行质量评估和反馈修正。产品设计要点包括：设计训练后质量评估指标（输出多样性、长尾知识覆盖、事实准确性）；建立退化检测机制（对比每代模型输出与前代的分布差异，检测坍塌早期信号）；设计纠错触发规则（当退化指标超过阈值自动触发纠错流程）；建立纠错执行管线（引入真实数据、调整合成数据比例、应用ToEdit等方法）。产品决策层面，纠错频率是关键参数。人类以年为单位纠错（论文发表周期），AI可以小时为单位纠错（自动评估+自动触发）。建议设计自动化纠错管线，减少人工干预延迟。

【智能】——AI数据智能识别

对训练数据池中的AI生成内容进行识别和标记，建立数据来源的可追溯体系。产品设计要点包括：部署AI内容检测器（对爬取/采购的数据进行AI生成概率评估）；建立数据来源标签体系（标记每条数据的来源——人类创作/AI生成/混合）；设计数据污染预警机制（当数据池中AI内容占比超过阈值触发预警）；建立数据溯源链路（从数据采集到模型训练全链路可追溯）。产品决策层面，AI内容检测技术目前准确率约80-90%，存在误判风险。建议作为辅助信号而非绝对标准，配合人工审核使用。

【监控】——分布监控

持续监控训练数据和模型输出的分布特征，防止模式坍缩和长尾消失。产品设计要点包括：监控训练数据分布（词汇多样性、主题覆盖度、长尾知识占比）；监控模型输出分布（输出多样性指标、重复率、新颖性评分）；设计分布偏差告警（当输出分布与目标分布偏差超过阈值时告警）；建立分布修复机制（通过数据增强、分布校正等技术修复偏差）。产品决策层面，分布监控是模型坍塌的“早期预警系统”。建议在产品中设计实时分布监控面板，让产品经理和工程师能直观看到数据健康度。

模型应用场景

真实数据百分比：医疗AI产品 > 法律AI产品 > 通用对话AI > 内容生成AI > 娱乐AI产品
检测精度：高精度 → 标准精度 → 基础精度
纠错频率：单次 → 定期 → 按需
监控频次：实时 → 每日 → 每周 → 每月

核心判断

1. 模型坍塌不是AI末日。

它暴露的不是AI技术的天花板，而是数据管线的短板。

2. “AI吃AI会完蛋”是伪命题。

真正的风险不是递归本身，而是缺乏纠错机制的封闭递归。人类文明的递归成功证明：有纠错机制的递归是进步引擎，无纠错机制的递归是退化螺旋。

3. 人类有自主意识，AI有扩展能力。

两条进化路径不同但都可行。AI以小时为单位的纠错频率远高于人类以年为单位的频率，这是AI的独特优势。

4. AI产品经理的核心能力正在变化。

从关注模型参数和功能设计，扩展到训练数据质量管理和纠错机制设计。RAID模型提供了一个可落地的框架。

Anthropic 虽然拒绝公布其新模型 Mythos 的架构细节，但一份测试成绩却让社区窥见了端倪。根据官方发布的 system card，Mythos 在 GraphWalks BFS（复杂图结构广度优先搜索）测试中拿下了惊人的 80.0%，而自家的 Opus 4.6 仅考到 38.7%，GPT-5.4 更只有 21.4%。在其他基准上，各家的差距从未如此悬殊。Meta 机器学习工程师 Chris Hayduk 率先指出，这一异常尖峰正指向一类特殊的架构——循环语言模型。有趣的是，字节跳动 Seed 团队在去年 10 月发表论文，提出了名为 LoopLM 的架构：让同一组 Transformer 层对输入反复运行多次，将复杂的推理过程隐藏在模型内部迭代中，而非像传统思维链那样生成大量显性文字。图灵奖得主 Yoshua Bengio 也是该论文的共同作者。论文明确强调，图搜索正是循环模型的理论强项。其开源的小模型 Ouro 中，仅 14 亿参数就能对抗约 40 亿参数的标准 Transformer。第二个关键线索：Mythos 在 SWE-bench 评估中消耗的 token 量仅为 Opus 4.6 的 1/5，但推理速度反而更慢。若按常理，输出越短理应越快，可如果计算都集中在模型内部的循环迭代里，这一矛盾便迎刃而解。Anthropic 已将架构列为“研究敏感信息”，拒绝置评。这一切仍处于推测阶段，但若成真，便意味着下一代顶尖模型的架构突破，或许部分源自中国团队的公开研究。

销售、财务都在用的 ChatGPT Work，究竟在做什么

许多人把 ChatGPT Work 和 Codex 混为一谈，以为只是换了名字，或者干脆认为 Codex 被取消了。实际上，二者是并行存在的，Work 正在把“让 AI 真正完成工作”这件事推向更广阔的人群。先看几个实战案例，就能明白它的价值。

销售团队：七位数的销售线索，交给 Work 自动跟进

Zapier 营销主管 Angela Ferrante 曾分享过一个做法：她让 ChatGPT Work 搭建了一套可重复运行的系统，每月自动审阅数千条潜在客户。Work 会追踪 CRM、邮件以及其他工具中的客户触点，判断哪里的跟进出现了断层，然后生成每周高管看板，把被遗漏的销售管道机会标注出来。最终，这套机制揭示出的潜在销售额达到了七位数。

如果全部由人工去盯几千条线索，不仅耗时耗力，还极易遗漏。Work 恰好没有体力上限，也不会疏忽。

另一个销售场景：24 小时完成概念验证

OpenAI 自己的销售团队也有过类似的实践。一次探索性的客户对话，按以往从需求理解到完成概念验证交付，至少需要几周。ChatGPT Work 拿到对话笔记后，自动整理出关键需求，把请求转发给解决方案架构师，并协同技术团队推进，24 小时内就做出了可交付的概念验证。

使用 Work 的人不用再在同事之间来回传话，只需要专注和客户交流，剩下的拆解步骤、寻找资源、进行验证等工作，都由 Work 在后台完成。

财务团队：月底结账从几天变成几小时

OpenAI 财务部门用 Work 做月底结账与预测。过去，需要手动从各个系统获取数据，再搬运到 Excel 里做对账、画幻灯片、验证结果，整套流程走下来至少要花去几天。

现在 Work 可以帮忙找数据、填表、对账、生成幻灯片，财务同事只需要审核结果、解释变化原因，并向高管提出下一步建议。整套结账和预测流程便从几天压缩到了几小时。

缩短时间只是其一。更重要的是，财务分析师被解放出来，能把精力放在“数字为什么变动”的分析上，而不是困在“数字从哪里来”的搜集工作上。

定时任务：让 Work 每天、每周自动运行

Work 的排程功能在下面这几种场景中特别实用：

• 每周定时查看 Slack 新消息，自动更新例会议程
• 每天早上检查指定网站和看板，把变化汇总成报告发给你
• 监控新的客户反馈，自动归纳出产品需求清单
• 收到新邮件反馈时，自动更新对应的汇报 PPT

这些规则明确、重复性高的事情，以前需要人工定时查看，现在全部交给 Work。早上打开电脑，整合好的报告就已经在邮箱里了。

一条指令跑完一整条链路：从研究到多市场落地

官方曾展示过一个十分完整的例子：你只需要给出一个目标，Work 就能把一整套流程跑通——客户研究转化为营销活动简报，再用简报生成营销素材，最后针对不同市场做本地化适配，全程保持上下文一致。

过去这些事情需要分别调动不同岗位：研究人员出报告、策划人员写简报、设计人员做素材、运营人员改本地化版本。如今只需一个人下达指令，Work 就可以从头跑到尾。虽然每个环节的最终产物仍然需要你来审核，但你的角色已经从“在各个部门之间对接”变成了“在关键节点把握方向”。

在 zcode 中，我们可以通过模型参数直接设定上下文（context）大小：

比如 GLM-5.1 的上下文窗口为 200,000 tokens（200K），到了 GLM-5.2 则一举提升至 1,000,000 tokens（1M）。参数配置完成后，界面上就会清晰显示“100万”上下文。

而在 Claude Code 中，默认的模型上下文大小被设置为 200K。项目刚启动、会话还很“空”的时候，显示如下：

如果一直使用默认值，上下文很容易就被填满。用满之后，状态会变成这样：

此时界面右下角会明确提示“100% context used”，意味着上下文窗口已经没有余量。

那到底该如何调整上下文的大小呢？答案是通过环境变量：

export CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000

配置完成后重启 Claude Code，上下文就已经改成 1M 了：

需要明确的是，上下文并非越大越好。大上下文在处理长程任务时确实有优势，至少不用担心上下文爆炸，但长时间在高负载的上下文下运行会消耗大量 token。更经济高效的做法是，当项目推进到一定阶段，可以汇总生成项目文档，然后使用 /compact 命令压缩上下文，从而节省 token。

上下文是维持项目连续性的关键。一旦退出会话，agent 会重新扫描项目目录，效果等同于执行了 /clear 命令。而压缩上下文并不会清空记忆，它只是将关键信息提炼后写入上下文。例如，之前上下文使用率接近 100%，在执行 /compact 后，占用率可以降至 23% 左右，同时核心记忆不受影响。

如果中途需要调整上下文大小，就必须重启会话。具体操作是先执行 export CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000 设置目标大小，然后通过 --resume 参数恢复会话。

这种情况下，虽然重启了会话，但上下文仍然能够衔接上，之前的记忆不会丢失。

Claude Code 的会话历史查看起来并不直观，但我们可以让 Claude Code 自己生成一个项目会话查看工具，方便后续 resume 时快速定位。Claude Code 的会话是按项目独立存储的，在对应的项目目录内执行相关命令，就能查看该项目历史会话列表。

社区中有人基于Karpathy在X平台发表的看法，在GitHub上创建了andrej-karpathy-skills仓库，目前已经收获184K个星标：

https://github.com/multica-ai/andrej-karpathy-skills

我向来觉得这类通用规则似乎无需特意编写，大模型或AI编码工具迟早会内化这些准则。为此，我特意查看了Claude Code在用户全局级设置的CLAUDE.md文件：

·# Development Guidelines## Philosophy### Core Beliefs- **Incremental progress over big bangs** - Small changes that compile and pass tests- **Learning from existing code** - Study and plan before implementing- **Pragmatic over dogmatic** - Adapt to project reality- **Clear intent over clever code** - Be boring and obvious### Simplicity Means- Single responsibility per function/class- Avoid premature abstractions- No clever tricks - choose the boring solution- If you need to explain it, it's too complex## Process### 1. Planning & StagingBreak complex work into 3-5 stages. Document in `IMPLEMENTATION_PLAN.md`:```markdown## Stage N: [Name]**Goal**: [Specific deliverable]**Success Criteria**: [Testable outcomes]**Tests**: [Specific test cases]**Status**: [Not Started|In Progress|Complete]```- Update status as you progress- Remove file when all stages are done### 2. Implementation Flow1. **Understand** - Study existing patterns in codebase2. **Test** - Write test first (red)3. **Implement** - Minimal code to pass (green)4. **Refactor** - Clean up with tests passing5. **Commit** - With clear message linking to plan### 3. When Stuck (After 3 Attempts)**CRITICAL**: Maximum 3 attempts per issue, then STOP.1. **Document what failed**:   - What you tried   - Specific error messages   - Why you think it failed2. **Research alternatives**:   - Find 2-3 similar implementations   - Note different approaches used3. **Question fundamentals**:   - Is this the right abstraction level?   - Can this be split into smaller problems?   - Is there a simpler approach entirely?4. **Try different angle**:   - Different library/framework feature?   - Different architectural pattern?   - Remove abstraction instead of adding?## Technical Standards### Architecture Principles- **Composition over inheritance** - Use dependency injection- **Interfaces over singletons** - Enable testing and flexibility- **Explicit over implicit** - Clear data flow and dependencies- **Test-driven when possible** - Never disable tests, fix them### Code Quality- **Every commit must**:  - Compile successfully  - Pass all existing tests  - Include tests for new functionality  - Follow project formatting/linting- **Before committing**:  - Run formatters/linters  - Self-review changes  - Ensure commit message explains "why"### Error Handling- Fail fast with descriptive messages- Include context for debugging- Handle errors at appropriate level- Never silently swallow exceptions## Decision FrameworkWhen multiple valid approaches exist, choose based on:1. **Testability** - Can I easily test this?2. **Readability** - Will someone understand this in 6 months?3. **Consistency** - Does this match project patterns?4. **Simplicity** - Is this the simplest solution that works?5. **Reversibility** - How hard to change later?## Project Integration### Learning the Codebase- Find 3 similar features/components- Identify common patterns and conventions- Use same libraries/utilities when possible- Follow existing test patterns### Tooling- Use project's existing build system- Use project's test framework- Use project's formatter/linter settings- Don't introduce new tools without strong justification## Quality Gates### Definition of Done- [ ] Tests written and passing- [ ] Code follows project conventions- [ ] No linter/formatter warnings- [ ] Commit messages are clear- [ ] Implementation matches plan- [ ] No TODOs without issue numbers### Test Guidelines- Test behavior, not implementation- One assertion per test when possible- Clear test names describing scenario- Use existing test utilities/helpers- Tests should be deterministic## Important Reminders**NEVER**:- Use `--no-verify` to bypass commit hooks- Disable tests instead of fixing them- Commit code that doesn't compile- Make assumptions - verify with existing code**ALWAYS**:- Commit working code incrementally- Update plan documentation as you go- Learn from existing implementations- Stop after 3 failed attempts and reassess<!-- CODEGRAPH_START -->## CodeGraphIn repositories indexed by CodeGraph (a `.codegraph/` directory exists at the repo root), reach for it BEFORE grep/find or reading files when you need to understand or locate code:- **MCP tools** (when available): `codegraph_explore` answers most code questions in one call — the relevant symbols' verbatim source plus the call paths between them. `codegraph_node` returns one symbol's source + callers, or reads a whole file with line numbers. If the tools are listed but deferred, load them by name via tool search.- **Shell** (always works): `codegraph explore "<symbol names or question>"` and `codegraph node <symbol-or-file>` print the same output.If there is no `.codegraph/` directory, skip CodeGraph entirely — indexing is the user's decision.<!-- CODEGRAPH_END -->

不清楚这份文件是何时生成的，但对比网络上流传的各种“神奇咒语”，感觉内容其实大同小异吧。

程序员永远能在枯燥的代码里找到乐子。这一次，有人给 Codex 搞了一套主题皮肤，仅凭一张概念图就在一夜之间斩获 5.5K Star，直接让“老师”陪你氛围编程，这体验可比悄悄摸鱼刺激多了。

情景展示

不感冒日本明星？国产明星立马安排！

迪丽热巴跟你结对编程，写 Bug 都感觉元气满满。

如果你是 10 后女程序员，易烊千玺来陪你敲代码可好？

小哥哥盯着屏幕看你写循环，写完了还能脑补一句“代码写得真好”。

审美比较独特？没问题，“雨姐”上线跟你聊聊人生。

什么？旷世佳人也只是红粉骷髅？
你不贪美色，不恋帅哥，脑子里只有搞钱？
好的，财神爷直接搬进你的 Codex。

你说你既不馋身子也不馋铜板，你要搞一票大的？
那这款皮肤一定合你胃口：

Make Coding great again！

看到这里，你是不是已经蠢蠢欲动，恨不得马上给自己的编辑器换上这套皮肤？

立马上手！

心动就动手，实际只要两步，三分钟全部搞定。

第一步，打开 Claude 桌面版：

第二步：把这段话发给 Claude！

完整提示词：

https://github.com/Fei-Away/Codex-Dream-Skin 帮我查看一下这个项目，克隆到本地，然后按它的教程，给 Codex 换一个主题！

Claude 根本不带犹豫，一次性成功，绝不多尝试一次。它还会主动问你要哪款主题：

皮肤装好后，桌面还会生成几个小工具，方便你随时切换。
看 Claude 干活真的很享受，整个过程它的一举一动都清清楚楚：

我先看看这个项目，然后克隆到本地。  
  
先创建一个工作目录并克隆：  
  
Cloned successfully. Let me read the tutorial/README.  
  
这是一个给 Codex 桌面版换主题（换肤）的工具。你在 macOS 上，我看一下 macOS 的详细说明和安装脚本。  
  
我理解了这个工具。它通过本机 CDP 注入的方式给官方 Codex 桌面版换背景主题，不修改官方安装包。先确认前置条件：Codex 桌面版是否已安装并至少启动过一次。  
  
前置条件基本满足：`~/.codex/config.toml` 存在，node 可用。工具会查找 `com.openai.codex` 应用。先确认 Codex 桌面应用的具体位置，再看安装脚本内容。  
  
一切就绪：Codex 桌面版（ChatGPT.app，bundle id `com.openai.codex`）已安装，`config.toml` 存在，node 可用。安装脚本要求安装时 Codex 处于关闭状态。检查一下是否在运行：  
  
Codex（ChatGPT.app）正在运行。安装过程需要先关闭它（脚本会安全地改写 `config.toml`，之后换肤会通过 CDP 重新以调试模式启动 Codex）。我先优雅退出它，再安装。  
  
先跑一下自检，然后安装：  
  
Codex 已关闭。现在运行自检并安装：  
  
自检基本通过（末尾的报错是测试场景内预期的、尚未应用主题的分支）。现在安装到稳定路径，不自动启动：  
  
安装成功（Codex Dream Skin Studio 1.2.0，使用 Codex 自带签名 Node）。现在挑主题。先看看可用的预设：  
  
有 6 个预设。选主题是你的口味决定的，我列几个让你挑（另有已验证的实拍精选 romantic-rose，但它是 AI 生成的真人肖像素材）：  
  
用桥本有菜精选主题。应用它并启动 Codex：  
  
主题已应用，Codex 已在换肤调试模式下启动。跑一下 Verify 确认注入状态：  
  
搞定了。✅ Verify 显示 `"pass": true`，桥本有菜主题已成功注入，Codex 正在换肤模式下运行。

完成的事：

Codex 与 ChatGPT 合体之后，在 GPT 5.6 和不断重置额度的推动下，活跃用户即将突破 1000 万。可能很多人对这个数量级没有实感，但要知道，这里面很大一部分是重度付费用户，其中还有不少是从 Claude 迁移过来的。这个成绩本身就足够有说服力。

合体后，大家最先注意到的通常是代码能力和工作能力，但很少人知道 Codex 还开放了一项“站点”功能，英文名叫做 Sites。即使听过的人，也多半认为它就是个普通的网页生成工具。我最近深度试用了一下，发现它的实际表现远远超出预期。

目前这个功能仍处于公开测试阶段，我是 Pro 套餐，可以直接使用。它出现在 ChatGPT 桌面端和网页端的侧边栏里，能够创建、托管、迭代和分享网站、Web 应用与小游戏，最关键的是，它无缝接入了 Codex 的本地开发能力。

你可以从一句话的需求开始构建一个 Web 产品，也可以把兼容的本地项目直接交给它检查、调整并发布。

举个例子，我让 Sites 直接把我的博客内容搬过来，并做一次全新的设计：

@Sites 把我的 Blog https://macshuo.com 的内容搬到这里来。它马上开始执行：

生成的设计风格大致是这样的：

整个过程完全不需要我介入，数据、布局、样式、迁移方式，Codex 都能独立处理。如果对生成的效果不满意，那就换一个风格，直接把喜欢的设计样式 md 文件投喂给它就行：

在实际工作场景中，它的价值更直接。过去做一个活动落地页，需要和 AI 反复讨论需求、生成代码、启动本地服务、处理各种构建问题，再到处寻找部署平台并配置权限。现在在 Codex 的站点里，可以直接生成预览、按需求修改、完成构建并保存版本，最后输出正式地址。访问权限可以设为私密、公开，或者指定分享对象。

修改方式也更贴近日常对话。你可以直接说“首屏太满，减少文字，把报名按钮提前”，也可以上传截图、图片和文件，让 Codex 结合新材料调整页面。它很适合做落地页、作品集、信息看板、内部工具和小游戏，能快速产出一个可直接使用的完整结果。

如果需求涉及业务数据，Sites 还能为表单、任务、用户进度和分数配置 D1 关系型数据库，也可以为图片、文档、音频和视频配置 R2 对象存储。你只需要在提示中明确说明哪些内容需要持久化，Codex 会自动选择合适的存储方式。

站点发布后不会随着对话结束而消失。它会留在桌面端的 Sites 入口，也可以通过 ChatGPT 网页端继续管理、修改和发布。访问范围可以设为仅自己或受邀者、工作区成员，以及任何拥有链接的人，具体选项受工作区管理员控制。

如果你有自己的域名，可以直接在该站点的设置里，配置自定义域名和 DNS，一个博客就这样轻松上线了。

Sites 还自带访问分析，不用再接入其他分析 SDK，就能直接看到独立访客、页面浏览量以及时间趋势的变化。

它将预览、版本管理、托管、权限控制、存储和基础分析整合到一起，让产品经理、运营、设计师甚至独立开发者都能用自然语言完成一次小型交付。

我尝试了两种工作方式：一种是把本地开发好的项目直接丢到站点上进行预览、修改和部署；另一种是完完全全从零开始，所有东西都在云端完成。

目前来看，两种方式的效果都很不错，非常推荐你亲自试一试。

Codex 定制皮肤看起来并非刚需，但实际体验却充满趣味。一大早我便在 macOS 系统上通过简短命令成功部署，下午又将其移植到 Windows 上。

不过在 Windows 上的过程就比较曲折。起初想让 Codex 自行完成操作，结果不仅没成功，反馈的情况还与真实环境严重不符。意识到问题可能超出它的处理范围后，果断转用 Claude 接手——实打实的「你不干，有的是人干」系列。

随后便让 Claude 顺带制作了一个可独立运行的图形界面 exe 主题包。

这个时代确实神奇，代码还没完全看懂，exe 已经封装完成。拿到这个 exe 后双击启动，完全无需安装或额外配置，打开即用。

启动后选择喜欢的主题，点击重启 Codex 并注入，就能立刻看到新的皮肤。

Codex 界面马上焕然一新。

对话界面效果如下：

当前主题的配色不太符合个人硬朗的风格。但因为原始项目在 Windows 端能直接使用的皮肤版本不多，便先保留下来，后续再慢慢调整。

这个小工具经过整理，具备以下特性：

• 零配置：无需额外 SDK 或手动改动 Codex 文件。
• 一键启动：一键拉起 Codex 并启用皮肤。
• 一键切换：选取主题后即时生效，无需反复设置。
• 多主题切换：内置多款主题，随时预览、切换。
• 自定义背景：导入自己的图片即可生成专属主题。
• 一键还原：随时恢复到 Codex 官方原始外观。

我已经将项目发布到 GitHub 上：

https://github.com/JarvisPMS/CoderStyle

第一个版本已经打包，虽然文件名有些小问题，待后续微调。软件可在文末获取。研究过程中发现这条思路很有趣，一旦打通，可以调整的内容相当多。

下面分享整个制作过程。

通常完成一项工作后，我会结合操作记录整理思路。这次也不例外，一开始就直接将开源项目的地址抛给它，让它直接帮我给电脑上的 Codex 更换皮肤。macOS 上非常顺利，几分钟搞定；Windows 上却遇到一连串问题（这确实比较考验耐心）。

开发过程中遇到的那些坑

这份踩坑记录并非自己总结，而是让 O 哥自行输出。我在 Agents.md 里有一条规定：遇到问题必须记录现象、根因、解决方式和经验教训。这跟过去自己写代码一样，出现问题并解决后需要做笔记。否则以我鱼的记忆，即使写过几十万行代码，几天不回顾就会一片空白。

坑 1：PowerShell 5.1 错误

之前我们讨论过“有水快流”理念，强调在窗口期尽量把资源用足。没想到话音刚落，AI编程领域的竞争就突然升级。昨晚三家每月200美元的Claude Fable与Codex订阅额度刚被消耗殆尽，今早Codex直接重置额度——满血复活。

Claude同样不甘沉寂。官方宣布原定于今日结束的Fable 5访问期限再次延长至19日，这已是第三次延期。

这一轮角逐远不止延长访问时间。Codex直接取消原有的5小时单次限额，目前仅保留周总量控制；Claude Code则宣布将每周总使用额度上调50%。双方几乎在X平台同步贴出公告，针尖对麦芒，用户自然喜笑颜开。

这正是鹬蚌相争，渔翁得利。

不过与Codex相比，Claude这次仍显得有所保留：它只延长了Fable 5的访问窗口，却没有像上一次那样直接重置已消耗的额度。昨晚Fable 5已被用到100%，虽然访问资格在，仍需等待额度恢复才能继续。而Codex的重置让今早的工作状态直接回到满额。

Codex与ChatGPT的负责人Tibo在X上分享，Codex活跃用户已突破600万，甚至打趣明天就要庆祝突破700万。这个增长速度着实夸张。Codex的营销有时就是这么直接——舍得投入额度、舍得释放资源，用户自然会用行动支持。反观Claude Code，产品能力虽强，但策略上总有些反复试探用户底线的感觉。

这轮较量再次印证了一个简单的道理：市场必须有竞争，用户才能拿到真正的实惠。任何一家形成垄断，最终都会限额、涨价、挤牙膏；只有双方真正硬碰硬，限制才会被打开，额度才会增加，用户才有便宜可占。

实战检验：Codex的高强度工程产能

最近用两个Codex账号完成了一系列大型任务。其中之一是收集、整理并校对PostgreSQL扩展生态中1600余个扩展的详细信息，包括功能说明、文档、安装方式与使用手册。此外还构建了一个自用的APT/YUM仓库管理工具SOW，以及一个用Go重构Patroni的项目。再加上文档修缮、Bug/Issue/PR处理、扩展打包构建等，任务强度极大。

以SOW项目为例，它采用的是一套典型的双模型协作流程：先用Claude Fable 5配合BMAD方法完成需求分析、架构设计和产品需求文档，再将具体执行交给Codex 5.6 Sol Ultra。目标锁定后Codex便开始“蹬车”，一口气连续运行三十多个小时，直接打满整周额度。最终，依靠“任务一旦启动系统会尽量执行完成”的机制，硬是超额产出一版接近2.7万行代码的初稿。

今天额度一重置，满血复活，立即可以继续迭代。从纯粹“干活”的角度看，Codex 5.6 Sol Ultra已非常令人满意。它未必有Fable 5那样灵巧，但差距有限，尤其在长时间执行、稳定交付和工程落地方面，已经展现出极强的生产力。

双模型分工：Fable负责设计，Codex负责建造

现在并不会用一个模型包打天下，而是根据任务类型进行明确分工。在日常思考、文章写作、创意发散，以及从零到一的产品设计阶段，需要更强的抽象能力、创造力与整体判断，这时更倾向于使用Fable。但当设计基本敲定，需要的是可靠执行、稳定交付和长时间连续工作，任务就会交给Codex 5.6 Sol Max或Ultra。

代码审查同样采用类似流水线：通常先让Codex汇总项目上下文，完成第一轮审查并整理出清晰的问题清单；随后，把上下文和审查结果自动转交给Fable 5，进行对抗性复核。两边一般经过两轮交叉审查，就能形成相当可靠的共识。最近顺手把一批过往项目重新扫描了一遍，确实发现并修复了一些以前未曾察觉的问题。这种“双模型对抗审查”的效果，远胜于让单个模型自问自答。

模型之间不应是简单替代关系。真正高效的用法，是让擅长设计的负责设计，让擅长执行的负责执行，再让另一个模型站在对立面进行复核。

Codex的“最后一个任务”配额技巧

分享一个通过反复实践观察到的Codex配额使用现象，请注意这不是官方承诺，机制随时可能调整。在Codex中，只要任务是在周额度完全耗尽之前启动的，即便执行过程中越过配额线，系统通常也不会立刻掐断任务，而是会尽最大努力完成当前任务。比如，本周额度只剩1%，此时启动一个规模足够大的任务，最终能够继续消耗的算力往往远远超过这1%。观察下来这种额外产出有上限，但额外跑出来的工作量可接近一整周的配额。理想情况下，一次额度重置带来的实际可用量几乎相当于两周配额。

因此，周额度快要见底时，不要再用零碎的小问题一点点耗光最后那点余量。更合理的做法是提前准备好一个目标明确、上下文完整、能够长时间连续运行的巨型任务，然后用最后的额度把它启动起来。这才是对剩余额度更高效的利用方式。听说最近Codex更新可能调整了该机制，可以晚些升级再验证。

200美元订阅，撬动数千美元算力

按照实际使用强度粗略估算，一个每月200美元的Coding Plan，如果把额度真正用满，能够撬动的算力，按API列表价计算（考虑95%缓存）可达五千美元。如果再算上重置和最后一个任务可能生成的额外执行量，一次重置带来的额外Token按列表价折算，可能相当于1.5万到2万元人民币的算力。两个账号叠加，就是2万到4万元人民币量级。

这里讲的是“按列表价折算的算力价值”，并不等同于现金收益，也不意味着所有人都能稳定再现同样的使用量。但它至少揭示了一点：目前这些高价Coding Plan仍处在补贴力度巨大的红利期。200美元的订阅能够撬动数千美元列表价的模型调用量，这本身就是当前AI时代最明显的红利。

不过，消耗Token并不自动等于创造生产力。如果没有清晰的设计、合理的任务拆分、完整的上下文和严格的审查流程，再多的Token也可能只是生成更多低质内容。真正有价值的是把这些算力投入能够长期沉淀的资产：代码、文档、自动化工具、知识库，以及可以反复复用的工作流。Token用得好，是生产力杠杆；用得不好，只是昂贵的电费和订阅成本。

总的来说，还是那句：有水快流，过期不候。

这种补贴窗口不会永远存在。趁Codex和Claude还在贴身竞争，趁双方还愿意用额度交换用户，尽可能把这些Token转化成真正有价值的数字资产。

对于善于把握窗口期的实干者，这是最好的杠杆与机会窗口。已有计划开启第四个每月200美元的订阅，继续扩大生产力工具底座。