AI摘要
Codex 用了 55 亿 token 都干了啥
过去这段时间，我对 Codex 的使用已经不再停留在“问一个问题、拿一个答案”的阶段。更准确地说，它变成了一个长期陪跑的工程助手、资料整理员、方案参谋、测试搭子、代码审查员和自动化工作流实验场。
如果把 55 亿 token 看成一条很长的工作轨迹，那它并不是被消耗在闲聊里，而是被消耗在反复试错、方案打磨、项目拆解、代码验证、文档整理、知识沉淀和工具链建设上。很多事情单看都不大，但连在一起，就形成了一套越来越清晰的个人 AI 工程工作方式。
1. 这段时间使用 Codex 的总结
这段时间使用 Codex，最大的变化是从“让 AI 给答案”，逐渐变成“让 AI 参与完整工作流”。
一开始，Codex 更多像一个随叫随到的助手：帮忙写文档、整理教程、生成页面、处理 Markdown、做一些小工具。但用得越多，越发现它真正的价值不只是生成内容，而是把一个模糊想法推进成可落地的结果。比如一个方案，不只是写几段介绍，而是可以拆成背景、目标、架构、部署、策略、流程、容量、验收；一个系统，不只是看页面能不能打开，而是可以按接口、按钮、权限、审计、真实数据、上线准入逐项检查。
这三个月里，Codex 被用在了几类事情上：
- 写作和资料整理：把微信文章、教程、AGENTS.md、Codex 使用手册、工程计划、安全方案等整理成可阅读、可复用的 Markdown。
- 工程验证：对 KDBOSS3 这类业务系统做页面验收、接口抓包、按钮下钻、风险清单和上线准入判断。
- 前端和原型：生成 SaaS 风格界面、资产台账页面、侧边栏、菜单、预览图，并用浏览器和截图做验证。
- 自动化和脚本：写 Python/Node 脚本，抓取音乐元数据、处理视频帧、生成素材和转换文档。
- AI 工作流建设：安装中文 agents、安装 superpowers-zh、整理 Codex 全局配置，让 Codex 自己变得更好用。
- 多媒体实验：做 Codex 宠物、咖啡猫、番茄发芽视频、图片裁切、帧标注等偏创意的项目。
- 架构和方案：输出软件系统评审方案、信息化模块工厂 30 天落地计划、南凌入侵防御与检测建设方案。
这说明 Codex 的使用重心已经从“单点生产力”变成了“工作系统”。它可以写，但不只是写；可以改代码，但不只是改代码；可以查资料，但更重要的是能把资料变成结构、流程、检查项和可执行计划。
另一个明显变化是，Codex 开始承担“第二双眼睛”的角色。比如 KDBOSS3 验收时，它不是只看页面好不好看，而是去确认有没有 404、有没有真实后端接口、按钮是不是真的下钻、AI 助手有没有越权、操作日志能不能支撑审计。这类检查很适合 Codex，因为它耐心、细、可以反复走流程，也能把发现的问题整理成 P0/P1 缺陷清单。
还有一个收获是，AI 的产出质量很依赖约束。只说“写个方案”，它会写成通用方案；明确目录、业务背景、南凌场景、MPLS-VPN、ISP/BGP、SD-WAN、数据中心、SOC 联动后，方案马上就能从“看起来正确”变成“更像能拿去评审”。这也是这段时间最重要的经验之一：AI 不怕复杂，怕的是目标不清。
2. 我通过 Codex 都学到了什么？
第一，学到了如何把一个想法拆成工程问题。
以前一个需求可能只是“做个方案”“写个页面”“检查一下系统”。现在会自然地追问：背景是什么，目标是什么，边界在哪里，验收标准是什么，风险点在哪里，谁来运营，失败了怎么回滚。这种拆解方式比单纯产出文本更有价值。
第二，学到了 AI 协作需要上下文管理。
AGENTS.md、项目日志、outputs 目录、knowhow 知识库、每日经验沉淀，这些看起来像“杂活”，实际是在给 AI 建记忆和边界。Codex 不是万能记忆体，但只要把关键经验写进文件、把项目产物有序保存，下次再处理类似问题时，就能少走很多弯路。
第三，学到了验证比生成更重要。
生成一段代码、一篇方案、一张页面并不难，难的是确认它真的能用。KDBOSS3 验收、Playwright 页面检查、截图确认、接口抓包、日志检查、文件大小检查、编码问题定位，这些工作都说明：AI 时代不是不需要工程师，而是更需要懂验证、懂边界、懂风险的工程师。
第四，学到了“提示词”不如“工作流”重要。
单个 prompt 再漂亮，也只是一次请求。真正让 Codex 变强的是固定流程：先读上下文，再拆任务，再执行，再验证，再记录日志，再沉淀经验。安装 agents 和 superpowers-zh，本质上也是在把临时经验固化为长期可复用的方法。
第五，学到了 AI 可以成为学习放大器。
通过 Codex，很多以前需要单独花时间摸索的东西可以被快速拉通：Markdown 写作、PowerShell 约束、Python 脚本、Node 工具、Delphi XE2 小程序、前端页面、浏览器自动化、安全方案、SOC 流程、DDoS/BGP 联动、IDS/IPS/NDR 架构等。Codex 不只是给结论，它会把知识组织成结构，让人更快形成自己的理解。
第六，学到了自己真正需要的不是“万能 AI”，而是“懂我工作方式的 AI”。
比如默认用简体中文，Windows PowerShell 环境，编码统一 UTF-8，复杂 Python 不用 bash heredoc，每天记录工作成果，经验沉淀到知识库。这些规则不是形式主义，而是在长期协作中减少摩擦。AI 越遵守这些工作习惯，越像一个真正能接入日常工作的伙伴。
3. 都做了些什么项目？项目的大概介绍
3.1 Codex 使用方法与知识库建设
这一类项目主要是把 Codex 从“能用”变成“好用”。
包括整理 Codex 小白教程、命令手册、全局 AGENTS.md、把 Codex 用到极致、Hermes Agent 指南、Codex 更新解读等文章。还包括安装 agency-agents-zh，把 266 个中文 AI 专家角色转换并安装到 Codex agents；安装 superpowers-zh，把 20 个中文 workflow skills 接入全局；同时清理旧插件缓存，避免不同版本能力互相干扰。
这个项目的意义在于，它不是做某个业务功能，而是在建设一套个人 AI 工程环境。后续所有项目，都能复用这些规则、技能、角色和经验。
3.2 KDBOSS3 MVP 验收与 SaaS UI 原型
KDBOSS3 相关工作主要分两部分：一是 UI 原型，二是真实验收。
UI 原型部分输出了资产台账、侧边栏、菜单、明暗主题预览图等 SaaS 风格页面，用来探索企业级后台系统的视觉和交互风格。
验收部分则更偏工程化。Codex 对 KDBOSS3 MVP 进行真实页面检查，覆盖 22 个二级页面，检查是否能打开、是否有 404 或白屏、是否调用真实后端接口、关键按钮是否真正下钻、GIS 和拓扑页面是否有真实数据支撑、AI 助手是否越权、操作日志是否满足审计。最后输出了检查结果、P0/P1 缺陷、上线准入判断和修复建议。
这个项目说明 Codex 不只是会“写页面”，也能按验收清单做系统级质量检查。
3.3 信息化模块工厂 30 天工程落地计划
这个项目是把《信息化模块工厂孵化组落地方案》拆成 30 天可执行计划。
Codex 将目标拆成管理层能看懂的里程碑和工程团队能执行的每日任务，围绕“业务需求 -> 需求澄清 -> Agent 拆解 -> AI 生成初稿 -> 实习生初测 -> 三方验收 -> 接入门户/MCP -> 复盘扩展”设计模块生产线。
计划中包含周里程碑、上线红线、验收指标、模块包交付清单、需求澄清卡、问题清单、验收表和 AI 调用记录表。这个项目的价值在于，把一个组织建设想法变成了可以排期、可以验收、可以复盘的工程计划。
3.4 入侵防御与检测方案
这个项目最初是根据山石网科 IDS/IPS 产品页面，整理一份通用入侵防御与检测方案。后来又按南凌业务结构重写，变成面向 MPLS-VPN、ISP/BGP、SD-WAN、数据中心、云资源池和客户托管安全服务的专项方案。
方案覆盖建设背景、业务场景、建设目标、总体架构、ISP/BGP 出口安全、MPLS 骨干检测、SD-WAN/CPE 安全接入、数据中心与云资源池安全、SOC/监控中心/运维中心联动、流量采集与阻断、DDoS 清洗与 BGP 联动、租户隔离、策略体系、安全运营流程、容量测算、产品选型、实施计划和验收标准。
这个项目体现了 Codex 在“资料提炼 + 行业经验 + 结构化方案”上的能力。只要给出明确目录和业务背景，它可以快速把通用产品能力转成行业落地方案。
3.5 软件系统评审方案
这是一个通用的软件系统评审模板，目标是为软件系统设计一套可落地的评审方法。
内容覆盖架构、需求、接口、数据、安全、性能、可靠性、测试、运维和交付风险。方法上采用分阶段评审：先明确目标和范围，再建立系统地图，然后按高风险优先级开展专题评审，最后输出问题清单、整改路线、验证计划和发布建议。
这个项目沉淀的是工程师视角的评审框架，后续可以复用于不同业务系统。
3.6 微信文章转 Markdown 与技术资料整理
这类工作主要是把外部文章和技术资料转换为本地 Markdown，方便长期保存和复用。
已经整理的内容包括 Codex 教程、Codex 命令手册、AGENTS.md 模板、Hermes Agent 指南、Codex 更新解读等。它们不只是资料备份，也逐渐组成了一套“如何使用 Codex 工作”的方法库。
3.7 BEYOND 音乐元数据整理
这个项目通过脚本抓取和整理 BEYOND 音乐数据，输出 raw 和去重后的 CSV/JSON 数据，并保留 summary。
它是一个典型的数据整理项目：先获取原始数据，再清洗、去重、选择优先版本，最后输出结构化结果。这个项目虽小，但展示了 Codex 在脚本生成、数据清洗和文件产物组织方面的效率。
3.8 多媒体与创意实验
这一类包括 Codex pet monk、coffee cat pet、jiujiu-pet、番茄发芽视频等。
Codex pet monk 和 coffee cat pet 更偏图像/宠物素材生成与处理；jiujiu-pet 是一个小型 Web 互动项目；番茄发芽视频则把一组图片帧处理成 15 天生长视频，并输出中英文标注版本。
这些项目看似轻松，但它们验证了 Codex 处理图片、帧、脚本、前端交互和视频产物的能力，也让工作流不只停留在严肃文档和代码里。
3.9 Delphi XE2 HelloWord 小程序
这是一个面向 Delphi XE2 的最小 VCL 测试程序。
项目包含 HelloWord.dpr、MainForm.pas、MainForm.dfm、HelloWord.dproj 和编译后的 exe。功能很简单：启动主窗口，点击按钮弹出 HelloWord。它的意义不在于功能复杂，而是在验证 Codex 能不能围绕老技术栈、Windows 桌面开发和传统 IDE 项目结构完成最小可运行工程。
3.10 文档审阅与渲染
这类项目围绕 docx 文档审阅、渲染和结果整理展开。
通过输入 Word 文档，生成可检查的渲染结果或审阅材料。它说明 Codex 不只是写代码，也可以参与办公文档处理、格式转换、报告生成等日常工程管理工作。
结语
所以，Codex 用了 55 亿 token 都干了啥？
它帮我写过文章，做过页面，跑过脚本，查过接口，验过系统，生成过视频，整理过知识库，安装过 agent，设计过安全方案，也拆过 30 天工程计划。
但更重要的是，它让我逐渐形成了一种新的工作方式：把经验写下来，把流程固化下来，把检查项标准化，把项目结果文件化，把 AI 从“临时问答工具”变成“持续协作的工程系统”。
这 55 亿 token，表面上是在生成文字、代码和文件；实际上，是在一点点训练一套属于自己的 AI 工作方法。
