吃透 CodeX 全套玩法，看完你的 AI 编码能力直接进阶

小伙伴，你好啊。这是一期CodeX写代码的实战技巧和终极心法，注意这期只说CodeX写代码这件事。会从最简单的小技巧开始 手把手的把CodeX的基础编码能力，到新功能的使用场景，以及我最近使用Codex的经验心法全部讲清楚。

视频分为了六个大的模块：
1. 三大开发小技巧
2. AGENTS.md 入职手册
3. 三个新增开发利器
4. CodeX 开发飞轮心法
5. 开发禁区 & 注意事项
6. AI 程序员核心竞争力

确实这期视频比较偏硬核，预估会超过30分钟，但我保证看完这期视频，你AI写代码能力，将不可逆的变强，轻松驾驭任何AI 编码Agent。（投票设置，你AI写代码的Agent是什么？Cursor、Claude Code 、 CodeX）

本期视频的文字版，我也整理成了文档，评论区自取吧。这期视频虽然受众有点小，但是含金量绝对够999纯金。所以还是斗胆要个点赞、收藏和关注吧，就当你们的学费了。

我先给你演示它的三个小技巧，这些技巧就能让你初步感受到CodeX的强大。

一.三大开发小技巧

先来点开胃小菜，我怕上来就讲工程化太干的东西，会劝退80%的新手。

1.快速安装多个插件

CodeX中安装插件是特别方便的，比如你看到了一个技能。
先来说单个安装，我这里去了Skills.sh这个网站，比如找到一个自己想装的技能，直接复制这个技能名字，然后直接说“帮我安装find-skills 这个技能” ，这时候CodeX就会自己去查找，找到这个Skill并安装。

还有你说我想装很多Skills，你直接截图一下，然后跟它说“安装图片中的所有技能”，然后我们泡杯茶的功夫，他就全部给我们安装好了。

对就这么方便，你不需要记住什么安装命令，也不需要过多的参与，Codex会正确快速的帮你安装完成的。

2. 派生功能-给开发的后悔药

Codex的派生功能也是对开发者超级有用的一个功能。比如一个成熟的项目，我突然有一个新的想法，但又怕对原有项目进行污染。这时候就可以使用派生功能，给项目 派生出一个新的工具树。在对话区，点击斜杆“/”, 就可以看到这个派生功能。它就把当前项目节点，给你重新剥离出一个新项目，你就在这个新项目上进行开发。类似Git中的新分支，但是比Git用起来方便。你也可以理解把原来的项目重新复制了一份，然后再开发。

实际演示一下，把这个“屏幕看板的项目”派生出一个新的工作树，点击派生后，就要会在左边对话项中有一个树的图标。

这时候就提出一个新需求“帮我设计并制作一个新的模拟全球出生率和死亡率的看板，你自己设计看板的细节，要有全球出生热力图”, 然后Codex就开始疯狂制作了，它会自己去查资料，自己设计，自己写代码。等制作完，不满意，直接删除这个工作树就可以。满意，让这个工作树直接移动到本地就可以了。

这个技巧可以避免新人，再刚接触开发时，把一个项目越开发越乱的情况。也就是传说中的开发后悔药。

3.自动化任务-让AI 自己推进项目

在AI Coding的今天，开发中有很多需要每天作的事情，比如我想让一个项目每天进化一点。但我又不知道如何进化，把项目变的更好。我就会用到这个功能“自动化任务”。我就会设置一个“自动化任务”，设置每天早上9:00。

帮我总结项目，并告诉我三条可以改进的地方，再告诉我两个可以新增的功能，并解释新功能对新项目的作用，并排列优先级。

这样已设置，是不是你每天一座到工位上，就知道今天要对这个项目做什么？你只要审核哪些需要修改，哪些功能需要添加。然后AI就会自动帮你干活了。也就实现了项目在AI的驱动下自我进化。

是不是这时候，你就有了当老板的感觉了，程序员变成了CodeX。

我多说一点，其实我觉的CodeX最强的一个地方就这个自动化任务。我们打开“设置”，在“电脑操控”里可以看到是可以控制浏览器和任意应用的，而且现在有了手机端的App。当我们了解这些后，可以设置每天给老婆发个信息、去某东、某宝打个卡，每月8号去领大额优惠券，甚至是抢酒、抢月饼都不在话下。只要是电脑上重复性的任务都可以交给它。而且有个小技巧，你只使用“最低级”智能就能完成大部分自动化任务。

但这里有个小问题，就是一定适可而止，设置太多也会有巨大的Tokens消耗的。

这些小技巧很有意思，但接下来的内容含金量会大幅提升，也会显得很干，有条件的小伙伴可以先喝口水，润润喉咙，我们马上开始。

二. 给CodeX办理入职手册AGENTS.md

不要装完CodeX就去让它写代码，而是要给他一个“入职手册”。如果没有规则，AI就像一头饥饿的野狼，会到处撕咬，到处修改。所以先要给它立规矩。

1. 什么是AGENTS.md

做个简单的比喻：程序员入职第一天会得到一个开发手册，或者开发规则。人力会叮嘱我们要熟读手册，才能尽快融入开发项目，同样当CodeX准备为你开发项目的时候，我们也应该给它一个“入职手册”，也就是AGENTS.md 文件。

用一句说：AGENTS.md 是CodeX的“行为准则文件” ，把一次性提示词变成持久、分层、可复用的项目规则，让AI自动遵守规范、执行流程，大幅提升编码效率与质量。

如果你在项目根目录写了这个文件，那它是“一次配置，全局生效 ”的。有了AGENTS.md就可以大大降低和AI的沟通成本，让它按照既定规矩进行开发。

2. AGENTS.md需要写些什么

每个人写的AGENTS.md是不一样的，因为这代表这个人的风格喜好和编程经验。我只拿自己的举例子。肯定有很多不足，但我还是决定分享一下。

我这个准则包含下面五项：
1. 语言的使用规范： Codex和我的日常沟通用中文，因为我本身应为就不太好，所以让我用英文和它沟通，我基本没办法完成。这一条进一步降低了我的使用成本。但相反的是技术报错，API问题，相关技术信息用英文，因为如果出现错误，我可以很轻松的通过搜索引擎查询到这些错误的原因。
2. 代码和提交规范： 代码规范其实里边有很多东西，比如文件体积、变量命名、接口规范。这些我都会有所要求，并且我会要求代码风格保持简洁。当我用CodeX提交代码到Git远端仓库时，我也会有所要求。
3. 安全与红线： 规定那种代码是不行的，比如个人密码和大模型的APIKey是不能写在硬编码中的，还有.env这种配置文件，也不能提交到仓库中。
4. 执行与测试工作： 我会要求它真实反馈与测试驱动（TDD），AI有时候会有讨好型人格，所以我会要求它不掩盖报错信息。然后在开发时要测试优先策略。这一切主要是为了避免AI产生幻觉。
5. 用户习惯 ： 这就是纯个人喜好了，比如我喜欢让AI沟通直奔主题，不需要频繁确认，以效率和结果为导向。

当然，在实际开发中你还会有很多其他的约束，但上面这五项是我必须要考虑的，也是在项目开始前我就会写好的。

3. 我写的AGENTS.md

当明白了AGENTS.md要写些什么后，再来看看我写的一个项目的具体文件。我们只要看有什么大项，至于具体的细节，我把这个文件放在了博客上，你可以自行查看。

# AGENTS.md

本文件是 Codex 在 `E:\Code\DesktopShow` 项目内工作的项目级规则。除非用户明确覆盖，所有自动化修改、排查、测试、提交说明都应遵守这里的约定。

## 项目概况

- 项目类型：纯静态展示页，当前由独立的 `html + css + js` 文件组成。
- 主要入口：`index.html`，其余页面通过入口页跳转打开。
- 当前页面：`auto-coding.html`、`video-commerce-board.html`、`token-command-board.html`、`neural-nexus-board.html`。
- 图表依赖：部分页面通过 CDN 使用 `ECharts`，例如 `https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js`。
- 当前没有 `package.json`、构建工具、测试框架或 Git 仓库元数据。不要假设存在 `npm test`、`npm run build`、Vite、Webpack 或远端仓库。
- 本项目适合直接双击 HTML 预览；如果浏览器安全策略或 CDN 加载需要本地服务，再使用简单静态服务。

## 沟通语言

- 日常沟通必须使用中文，直奔主题，优先说明结论、改动和验证结果。
- 技术报错、异常名、API 名称、命令输出、库名、配置键、HTTP 状态码等保留英文原文。
- 如果出现错误，不要只翻译或概括；必须保留关键英文错误信息，方便用户复制到搜索引擎查询。
- 解释技术方案时可以中文为主，英文术语保留原名，例如 `ECharts`、`localStorage`、`setInterval`、`DOMContentLoaded`。
- 用户英文基础较弱，避免要求用户用英文补充需求；需要确认时用中文问一个关键问题即可。

## 工作方式与用户偏好

- 默认以效率和结果为导向，不频繁确认，不把简单事项拆成多轮询问。
- 需求足够明确时直接执行；只有在继续操作会带来明显风险或产生不可逆影响时才先询问。
- 中间反馈要短，说明正在做什么、发现了什么、下一步是什么。
- 不要为了显得顺利而掩盖问题。无法完成、验证失败、环境缺失、网络失败都要真实说明。
- 不要编造不存在的测试、构建结果、Git 远端、依赖版本或浏览器验证。

## 编码与文件规范

- 所有文本文件使用 `UTF-8` 保存，尤其是中文页面内容、标题、说明文案和 `PRD.md`。
- 修改中文乱码时，要确认浏览器中显示正常，并保留 `<meta charset="utf-8">`。
- 本项目优先保持“一个静态页面自包含”的结构：页面相关的 CSS 和 JS 可以继续放在同一个 HTML 中，除非文件明显过大或复用需求明确。
- 不引入构建链路、框架、打包器或复杂依赖，除非用户明确要求。
- 保持代码简洁，避免为了小功能创建过多抽象。
- 变量和函数命名应表达业务含义，例如 `renderChart`、`updateMetrics`、`cityData`，避免 `a`、`data1`、`temp2` 这类含义不明的命名。
- JS 逻辑应按职责分组：数据、DOM 查询、渲染函数、更新函数、事件或定时器。
- CSS 变量集中放在 `:root`；颜色、边框、阴影、间距尽量复用已有变量。
- 避免无限制增加文件体积。单个 HTML 文件如果接近或超过约 800 行，应优先考虑整理结构、删除重复样式、合并重复函数，而不是继续堆叠。
- 不要删除现有视觉效果或交互，除非需求明确要求替换。

## 前端与视觉规则

- 这是展示屏/科技风静态页面项目，视觉改动应保持沉浸式大屏、科技感、数据动态感。
- 页面应在桌面大屏上优先表现良好，同时不能在常见移动宽度下出现明显文字重叠或布局崩坏。
- 使用 `clamp()`、CSS Grid、Flex、`minmax()` 等方式保证响应式布局稳定。
- 不要让文本溢出按钮、卡片、标题栏或指标区域；必要时使用换行、截断或缩小容器内字号。
- 动态数据应看起来实时变化，但不要制造过高频率导致页面卡顿。
- 使用 CDN 图表库时要提供合理 fallback；如果 `ECharts` 或地图数据加载失败，页面仍应展示可读内容。
- 不要使用与当前项目风格冲突的营销落地页结构、厚重说明卡片或无关装饰。

## 安全与红线

- 禁止在代码中硬编码个人密码、账号凭据、API Key、Access Token、Refresh Token、Cookie、私钥或真实业务密钥。
- 禁止提交 `.env`、`.env.local`、`.env.*`、密钥文件、导出的浏览器 Cookie、真实用户数据或本地机器敏感路径。
- 如果需要示例配置，只能提交 `.env.example`，并使用占位符，例如 `YOUR_API_KEY_HERE`。
- 不要把用户个人信息、真实订单、真实客户名单或内部业务数据写入演示页面。需要数据时使用模拟数据。
- 引入外部 CDN 或第三方资源前，要考虑可用性和隐私影响；不要加入未知来源脚本。
- 不执行破坏性命令，例如 `git reset --hard`、批量删除、清空目录，除非用户明确要求并确认目标路径。

## 测试与验证

- 开发前优先思考可验证行为；能写自动检查时先补检查，再改实现。
- 当前项目没有测试框架，因此每次修改后至少做与改动匹配的真实验证：
  - HTML 结构检查：确认标签闭合、入口链接正确、脚本没有明显语法错误。
  - 浏览器验证：打开被修改页面，检查控制台是否有 `ReferenceError`、`TypeError`、`SyntaxError` 或 CDN 加载失败。
  - 视觉验证：检查桌面和窄屏宽度下是否有重叠、溢出、空白图表、不可读文字。
  - 动态验证：涉及 `setInterval`、随机数据、图表刷新时，观察至少一个刷新周期。
- 如果本地环境无法运行浏览器验证，要明确说明“未完成浏览器验证”，并给出已完成的替代检查。
- 报告验证结果时必须真实：写出执行过的命令、检查过的页面、是否通过，以及失败的英文错误原文。
- 不允许使用“应该可以”“大概率没问题”代替验证结果。

## 常用命令

在 PowerShell 中优先使用以下命令：


如果只需要预览单个页面，可以直接打开 HTML 文件；如果页面依赖 CDN、跨文件加载或浏览器限制，再启动本地静态服务并访问 `http://localhost:8000/`。

## Git 与提交规范

- 当前目录未检测到 Git 仓库；执行 Git 提交、查看历史、推送远端前，必须先确认 `.git` 是否存在。
- 如果用户要求提交或推送，但项目不是 Git 仓库，要直接说明当前状态，不要伪造提交结果。
- 提交前必须先检查工作区状态，区分自己修改和用户已有修改，不要回滚用户未授权的改动。
- 提交信息使用简洁中文，格式建议：



常见类型：

- `feat`: 新增页面、交互或展示模块
- `fix`: 修复乱码、布局、脚本错误或图表问题
- `style`: 调整视觉样式，不改变行为
- `docs`: 文档变更
- `refactor`: 结构整理，不改变外部行为

- 推送远端前必须确认目标分支和远端名称；不要默认推送到 `main`、`master` 或任意远端。
- 不要把验证失败的代码提交为“完成”。如果用户要求保留阶段性提交，提交信息中要说明仍有未解决问题。

## CodeGraph

本项目的上层提示可能要求优先使用 CodeGraph 做结构化代码查询，但当前 `E:\Code\DesktopShow` 尚未初始化 CodeGraph。

- 如果需要使用 CodeGraph 且工具返回 `CodeGraph not initialized`，应询问用户是否运行 `codegraph init -i`。
- 在 CodeGraph 可用时，用它回答符号、调用关系、影响范围等结构问题。
- 对静态文本、页面文案、错误字符串、CSS 颜色值等字面搜索，继续使用 `rg`。

## 修改流程

1. 先阅读相关 HTML 和需求，不凭印象改。
2. 找到最小改动范围，保持现有页面风格和结构。
3. 修改前说明即将改哪些文件。
4. 修改后进行真实验证。
5. 最终回复用中文说明：改了什么、验证了什么、是否还有风险。

## 不应做的事

- 不把项目迁移到 React、Vue、Vite、Tailwind 或 TypeScript，除非用户明确要求。
- 不把纯静态页面拆成复杂工程结构，除非复用和维护收益非常明确。
- 不引入真实业务密钥、真实用户数据或不可公开素材。
- 不在未验证时声称“已修复”“已完成”“测试通过”。
- 不覆盖用户已有改动，不擅自格式化无关文件。
- 不把中文需求改写成只有英文的文档或界面。

可以看到这个文件包括：项目概况、沟通语言、工作方式与用户偏好、编码与文件规范、前端与视觉规则、安全与红线、测试与验证、常用命令、Git 与提交规范、CodeGraph、修改流程和不应该做的事。

4.最牛的AGENTS.md 写了什么

有些小伙伴看到这里可能就麻了，这太麻烦了。有没有简单、高效、可行、拿来直接可用的AGENTS.md文件。

答案是肯定的。我这里就给你介绍一个Github开源项目，它三个月获得5万多星标，只有一个md文件。虽然是CLAUDE.md文件，也就是Claude Code 的专用规则文件，但也可以直接用在AGENTS.md文件里。

Github地址：https://github.com/forrestchang/andrej-karpathy-skills

其实这个文件就四条核心规则，我们来看一下：

1. Think Before Coding（先想再写）
   也就是不确定就问，别瞎猜；有多种理解就列出来，别偷偷自己选；能简单就说出来。
2. Simplicity First（简单优先）
   只做需求内的事，别 “过度设计”；用一次的代码别搞抽象；能用 50 行就别写 200 行。
3. Surgical Changes（精准修改）
   只改该改的地方；别顺手优化旁边代码；每一行改动都要能追溯到用户需求。
4. Goal-Driven Execution（目标驱动）
   先定清晰目标和验收标准；写完必须验证；优先写测试，再实现功能。

如果你不想麻烦的写这么多，那就直接拿这个当自己的AGENTS.md也是完全没有问题的，而且效果非常好。

三. 三个新增的开发利器

其实我基本用过市面上所有的Agent开发工具，无论是国内还是国外的。但最近Codex上线的三个功能非常打动我，可以说真正改变了我的开发方式。

1.Appshots：上下文开始从“我描述”变成“它看见”

Appshots 让 macOS 上的 Codex 可以通过快捷键把前台窗口作为附件加入到对话线程中，包括窗口截图和可用文本。官方文档明确说，它适合把 API 文档、邮件、日历视图、设计窗口、预览窗口、错误页面、设置面板等当前工作现场发给 Codex。

以前你修改一个需求是这样描述的：

现在页面的搜索按钮太不显眼了，文章列表的图片有溢出问题，侧边栏hover状态看起来不美观，你先检查这些问题，然后进行修改。

而有了AppShots，你现在可以直接把窗口发给CodeX,然后说：

自己找一下问题，然后进行修改。

PS：这可不单单是少打几个字的问题，这是把上下文“人类自然语言描述”升级成“现场工作”，是工作方式的直接转变。

2. Goal mode：任务从一次对话 变成 持续目标

刚发布的Goal mode ，现在可以在Codex App、IDE externsion 和CLI中使用。这个模式可以让Codex在无人值守的情况下，朝一个具体目标连续推进数小时甚至数天。（这里你必须抛开Tokens消耗来谈，哈哈，我知道你抛不开，其实我也抛不开。）

这对一个开发工程师意味着你要开始学习写目标合约 ，而不是写愿望。

愿望式目标：

帮我优化一下看板，让它更好看

强目标（目标合约）：

Goal: 把看板的动画进行修改，每个页面的动画覆盖率超过85%以上。

Scope(范围):
- 只允许修改JS和CSS文件，不要动HTML结构
- 不允许修改非看板页面，除非看板页面影响其他页面，出现Bug.

Evidence(证据)：
- JS动画效果，保证页面85%的元素都使用动画效果。
- CSS动画作基本渲染，但不做交互渲染，基本渲染不超过20%。

stop(停止):
- 如果JS产生新的依赖，先暂停询问。
- 如果发现动画指示不明确，列出决策点，不要擅自作决定。

3. Remote control：可以拿着手机编程了

5月新增的功能，Codex移动端上线，可以连接运行Mac上的Codex，也就是说你用手机，随时随地都可以让家里的Mac电脑进行编写程序。

注意这时候你的工作模式会发生变化：
1. 你在电脑上启动一个长任务。
2. Codex运行、探索、测试、遇到无法决定的问题,需要你来抉择。
3. 你在手机上收到信息，需要你作出判断和决定。
4. 手机审批，作出自己的决定后，然他继续开发
5. 家里的电脑在开发环境中继续干活。

也就是说你可以吃着火锅，唱着歌，就把程序给写好了。

以上三个功能，都是刚上线不久的功能，甚至Appshots还不可在Windows上使用，的这三个新技巧，真的改变了传统的开发方式，编码工作中可以试着去使用它们。

四.CodeX开发飞轮（心法）

当我们了解啦CodeX开发的一些技巧后，就可以谈谈心法了。心法也可以看成经验，我把这个心法叫CodeX开发飞轮。

先来说说飞轮效应：初始推动飞轮要耗费巨大力气，缓慢转动；持续发力后，飞轮借惯性自行加速，后续只需少量力量就能保持高速运转。

如何让CodeX编写程序，越来越好，越来越高效，实现自我高速运转，像飞轮一样快速旋转起来。

Codex的开发飞轮有五个基本环节，我挨个介绍一下。

1.Context：给真实上下文

真实的上下文对代码开发非常重要，不要只说“有Bug”。要给具体的复现步骤、错误日志，截图、相关文件。用Appshots、Browser、MCP，这些功能把开发现场带进来。学会复现真实的工作现场，而不只是用自然语言来描述，Codex已经给你了这个能力。

2.Goal: 写目标合约

有了Goal这种模式，你就不要只说“优化”。而是要写出目标、范围、证据、停止条件、权限边界。越长的任务，越需要目标合约。上面我已经介绍了目标合约的正确写法。你也可以继续扩展。

3. Tools：让Codex行动

你要让Codex读代码、改文件、跑测试、查PR，包括现在可直接操作你开发的GUI界面了。但工具要有边界：哪个工具适合当前任务，哪些动作需要审批，哪些命令是明确禁止的,你都要想清楚，保证Codex不会越界。

4.TDD：先写测试、再写代码

手工开发的时候，很多公司觉的TDD麻烦，尽管它有无尽的好处，但很多公司为了效率，不采用测试驱动开发的模式。但是现在有了AI，这些事AI做起来又快又好，所以我们的开发一定是要测试驱动开发的，先写测试、再写代码。

5. Memory: 沉淀经验

这步是飞轮的关键，让AI开发越来越好。这也是前辈给我的一段话，我分享给你。

把重复出现的偏好写进 AGENTS.md，把重复流程做成 Skill，把项目状态写进 vault，把失败案例做成 eval，把权限规则写进 rules，把校验逻辑写进 hooks。

当你把Memory这步做好后，这个飞轮也就形成闭环，开始慢慢旋转起来了。

这就是CodeX的开发飞轮了，你只要坚持这样开发，你的CodeX就会越来越高效顺滑。就算有新的项目进来，你不再是从零开始，而是拥有一套已经高速运行的飞轮了。

五.CodeX开发禁区，开发注意事项

有了上边这些技巧和心法，你好像能上手商业项目了。但你其实还要设定好CodeX的开发禁区，也就是说遇到那些事，必须认为审核，才可以作，否则坚决不能自己执行。

• 删除生成数据，直接删除已经上线项目中的数据。
• 修改支付、权限、合规、审计逻辑。
• 直接发布生产版本，生产版本还是要人工审核的，AI不是负责人。
• 代表你发送高风险外部消息。
• 为了让测试通过而改变业务协议。

Codex 是一个能行动的系统，不是一个永远安全的对话框。真正成熟的用法是：让它在低风险路径上自动推进，在高风险路径上明确停住。规定好它的禁区，它才是服务人类的工具，如果控制不好，它就是导致你项目失败的野兽。

六.谈AI程序员的核心竞争力

上个视频发出后，有几万人看过，问我最多的一个问题就是在AI的浪潮下，程序员该何去何从。我这里就说说我的看法。

AI时代确实会让很多程序员失业，但这些只是初级程序员，真正的研发工程师不会因为Codex会写代码就是去价值。相反，他会让工程师更强。

在AI时代程序员的核心价值不再是编码速度，这个AI可以拉平大家的水平，而真正有价值的是：

• 定义正确的编程问题。
• 帮AI识别真实的开发上下文。
• 拆分开发任务的边界。
• 设计功能和项目验证标准。
• 设计架构，对AI设计的架构进行审核和取舍。
• 控制风险，并承担风险。
• 让系统持续变好，实现自我进化。

以前看一个程序员的水平高低，是你写代码的速度，而现在看一个程序员的水平高低，是能指挥驱使多少个可靠的编码循环：一个在修测试，一个在读日志，一个在整理文档，一个在生成报告，一个在更新AI经验。这些同时进行的能力，就是目前程序员的价值体现。

从另一个层面说，现在真正的AI编码高手是：你能把一个不稳定但强大的智能体，放进一个可观察、可验证、可审查、可迭代的工程系统里。你让它安全地做更多事，让自己专注于更高层的判断。

好了综上所述，就是我认为AI时代的研发工程师的新基本功。接下来我还会不断探寻AI 在程序员开发这条路上的不断发展，并分享我的技巧和心得。我们下期视频见了。