圈友令狐峰在 7 天内烧了 230 亿 Token，价值 2.6 万美元，把 Codex 用到了极致
他是一家内容营销公司的负责人，正推进全流程 AI 化，成果包括把可商用笔记从日产 100 条提到 1000 条，内部工具开发周期从 1 个月缩到 3 天。我结合他的分享和自己的 AI 编程实践，重新梳理了这 50 条经验，逐条加上我的用法和观察。希望帮你少走弯路。
第一部分：AI Native 的工作方式
1. 相信普通人靠想法也能快速验证产品。过去你得组团队找投资，现在用 Codex 这类工具，极低成本就能试错。烧 Token 就是你的研发预算，大胆消耗，让 AI 替你跑通路径，你只做判断和决策。
2. 真正拉开差距的与其说是会不会用 AI，不如说是有没有 AI Native 思维。别让自己成为流程里的手工中继。我们做笔记工具时，一开始每批生成完还要人工检查、排版、上传，后来把整个流程交给 Codex 调度，人只做抽查。你敢不敢让 AI 连续工作几小时，甚至几天，长期维护一个目标？
3. 先搞定稳定低成本的模型调用方案。我们早期直调 GPT-4 API，做一次大规模测试要上百美元，导致不敢频繁试错。后来切换 DeepSeek 和 OpenCodex 混合方案，成本降到原来 1/10，才敢并行跑几十个任务。成本不下来，你会下意识少思考、少尝试、少并行。
4. 想办法让账号拥有更充足的 Token 配额。去研究 OpenCodex 的配额申请规则，或者用 CC Switch 这样的第三方中继服务。配额越足，大规模实验的胆量就越大。
5. 别把“省 Token"当成最高原则。Token 可以再买，但你的时间、注意力和市场机会窗口才是真正的稀缺品。花 200 美元验证一个想法，总比闷头开发两个月划算。
6. 烧 Token 与其说是让 AI 陪你聊天，不如说是让它持续搜索、分析、执行、验证，最后交付可以直接使用的结果。我每次启动任务前会问自己：这次对话最后能产出文件、图表、代码，还是一个可运行的页面？
7. 最有价值的与其说是一个神奇提示词，不如说是一套可重复运行、持续优化的工作流。我们公司的笔记生成流水线，从选题到发布已经能自动运行，提示词只是其中一小环。
8. 相信 AI，理解 AI，然后尽可能把权限和任务交给它。很多人抱怨 AI 写代码出错，但问题是他们只让 AI 写片段，不给完整项目上下文和测试反馈。你让它读一遍你的代码库，问题复现率能降一半。
9. 不要让人成为工作流里的瓶颈。每次需要你复制、粘贴、确认、整理，都应该思考能否自动化。现在我看到同事手动整理数据，第一反应是：这个动作有没有 API 或脚本可以替代？
10. AI Native 与其说是“原来的业务加一个聊天框”，不如说是重新设计整个业务，让 AI 成为默认执行者。比如我们重新设计了内容生产流程：需求输入→AI 调研→大纲生成→多人审校→AI 排版发布，人只做策略和审核，执行全交给 Codex。
第二部分：从陌生行业快速切入新项目
11. 不懂一个行业有时反而是优势。你没有被旧规则限制，更容易和 AI 一起从第一性原理重新拆解行业。有一次客户要求做家电种草，我们完全外行，但用 AI 抓了上千篇笔记、拆解了用户决策树，最后方案反而比老手更切中痛点。
12. 遇到新行业，别花三个月学习。先让 Codex 调研市场格局、整理术语、分析 Top10 竞品，再用一个真实小项目反向学习。做中学，效率高十倍。
13. 做新业务时，先考虑能不能用 AI 完成，再考虑要不要招人。过去需要一个团队做的事，现在可能一个负责人加一套 AI 流水线就够了。我们新业务线跑通前，坚决不扩人。
14. 一定要优先使用当前能力最强的模型。模型能力差一点，整个复杂任务可能直接跑不通。我们有一次因成本问题降级模型，结果一连串脚本生成错误，返工耗时远超省下的 Token 费。
15. 简单任务交给便宜模型，关键判断、复杂编码和长期任务必须上顶级模型。我在 Codex 里建立了一个模型路由规则：内容润色用 Haiku，代码审计用 Sonnet，架构设计用 Opus。
16. 观察 Codex 的额度重置时间，它是有规律的。我们团队每周重置前会拉清单：代码审计、竞品调研、批量测试这些重任务，专门留在最后一天用余额跑。
17. 不要等到额度快过期才胡乱烧。提前准备一个“高 Token 任务池”，搜集想做的分析、想优化的代码、想生成的数据报告，一旦有余量直接启动。
18. 学会使用目标模式。我习惯把一个需要数小时甚至数天的结果设为最终目标，写清楚验收标准，然后让 Codex 自己规划中间步骤并持续推进，中间只做关键决策。
第三部分：让 AI 从想法走到可交付结果
19. 目标要写结果，不要只写动作。别说“研究一下竞品”，要说“交付包含 20 个竞品的数据库、差异分析报告和一条可执行的切入建议”。结果越具体，AI 交付越少变成半成品。
20. 复杂任务一定先用 Plan 模式。让 Codex 拆步骤、找潜在风险、确定验收标准，再开始执行，能减少一半的返工。有一次做日报生成器，跳过规划直接开干，中间改需求导致重写两次，后来花了双倍时间。
21. 判断标准很简单：做错一次的返工成本高不高？如果高，花些 Token 做详细的 Plan；如果只是拉个数据，直接干。
22. 给 Codex 明确的完成标准。比如“做一个落地页”，要细化到“页面加载速度小于 3 秒、移动端适配、包含异常状态提示、并写明白动化测试用例”。没有标准，你收到的永远是 70 分的及格品。
23. 告诉 AI 做什么之外，也要告诉它做到什么程度。我们内部的开发文档中，每个需求都附带“通过标准”：必须跑过哪些测试、在什么浏览器下验证、异常日志如何捕获。
24. 大任务尽量交付文件、代码、表格或网页，不要只停留在聊天答案。可沉淀的成果才有复利。我们每次调研结束，都会让 AI 输出带格式的分析报告，累积成内部知识库。
25. 让 Codex 先读取现有项目、历史文档和真实数据，再提出方案。上下文越真实，输出越少像套话。我现在新开一个项目对话，第一件事是把 README 和相关文档喂给它。
第四部分：把重复操作做成长期流程
26. 为长期项目编写 AGENTS.md。我会把项目规则、目录结构、禁止使用的库和验收方式写进去，放到根目录。以后每次和 AI 协作，它自动遵守，省去反复解释。
27. 把经常重复的操作做成 Skill。比如我们有一个“竞品快速扫描”Skill，只需输入行业关键词，自动抓取数据、清洗、打标签、输出分析表。一次写好规则，以后一句话触发完整流程。
28. 提示词升级为模板，模板升级为 Skill，再把多个 Skill 串成自动运行的业务系统。我们的内容生产线就是三个 Skill 串联：选题策划→正文生成→排版发布，中间通过 API 调用衔接。
29. 学会使用工具和连接器。让 Codex 直接读取你的 GitHub 仓库、Slack 消息、Notion 数据库，尽量少做人工搬运。我们内部所有的开发任务都从 GitHub issue 自动同步。
30. 不要复制几万行日志给 AI。让 Codex 自己搜索关键词、定位异常时间段、提取相关上下文，又快又准。我习惯把日志文件路径给它，让它自己用 grep 和正则提取。
第五部分：让 AI 完成调研、开发和测试
31. 遇到 Bug，别只让 AI 猜原因。要求它复现问题、读取日志、缩小范围、编写测试用例，最后才修复并验证。流程越完整，修复越彻底。
32. 修复 Bug 时，先让 Codex 写一个会失败的测试用例，确保这个测试能捕获当前缺陷，再修改代码让测试通过。测试驱动的修复能显著降低复发率。
33. 绝不用“感觉差不多”验收。让 Codex 跑自动化测试、检查页面渲染结果、验证关键日志输出，用证据链证明任务已完成。
34. 做网页时，让 Codex 同时检查桌面端、移动端、加载状态、空状态和错误状态，别只看首页截图。我们有一次上线后移动端排版全乱，就是因为只在桌面端验证。
35. 学会让 Codex 操作浏览器。大量调研、数据录入、页面测试和后台操作，本质上都可以转化为浏览器自动化工作流。我们维护了一个 Playwright 脚本集，Codex 能直接调用。
36. 让 AI 看图、看截图、甚至看视频，不要什么都靠文字描述。多模态输入经常比你解释十分钟更准确。现在我们调试 UI 问题时，直接截图喂给 AI，错误定位速度提升一倍。
37. 不要手动逐个整理竞品。让 AI 批量搜集产品信息、分类、去重、打标签，你只需要快速浏览并判断哪些是真正值得关注的信号。
38. 相信自己的想法，但前提是你看过足够多的竞品、用户反馈和失败案例。自信应该建立在信息密度上。我们每季度会让 AI 汇总行业所有失败复盘，研读完再定策略。
39. 一个想法不要只生成一套方案。让 Codex 同时给出保守版、激进版、低成本版和最快验证版，放在一起比较，能看清更多维度。
40. 学会并行推进。市场研究、产品设计、技术验证和内容生产可以同时进行，不必等上一件事做完。我通常开 3-4 个 Codex 对话，分别处理不同模块，最后汇总。
41. 并行与其说是让十个 AI 回答同一个问题，不如说是把大目标拆成互不依赖的子任务，分别并发处理，最后再汇总判断。这需要你前期花时间做任务拆解，但总耗时能缩短一半以上。
第六部分：用复盘和配置提高长期效率
42. 最好模型用最高推理能力做审查，日常执行用中等推理就够了。比如用 Opus 审阅代码架构，用 Sonnet 生成具体功能，用 Haiku 写注释和文档。
43. 重要决策不要只问“这个想法好不好”，要主动让 AI 反对你。让它找出哪里可能失败、哪些假设最危险、怎么低成本证伪。这种红队演练能避免很多坑。
44. 留意 Codex 或 Claude 的周额度重置时间，它是有规律的，一般在北京时间周一下午重置。我会在周日把余量任务排满，一周算下来能省下两到三天的等待时间。
45. 一次对话只解决一个问题是浪费。尽量把“调研、方案、实现、测试、复盘”连成闭环。我的习惯是，一个项目一个主对话，所有相关执行和讨论都在里面，上下文连贯，AI 的连续工作力能得到发挥。
46. 每完成一个项目，都让 Codex 复盘。统计哪些步骤浪费了 Token，哪些信息被重复要求提供，哪些流程可以进一步自动化。上次复盘发现每次都要重复描述数据表结构，于是写了一个 Skill，后续效率提升 15%。
47. 建立自己的失败案例库。AI 犯过的错误、无效的提示词、项目踩过的坑，都应该沉淀成下一次的约束条件。我们有一个共享文档《AI 协作教训》，新同事入职必读。
48. 买一台性能更好的电脑。我建议 1 万元以上的 Mac，尤其当你需要同时运行 Codex、浏览器、开发环境和 Docker 时。我有一段时间只用笔记本，每天最多处理 30 亿 Token 的并行任务，电脑一卡，效率狂掉。换了 32G 内存的 Mac Studio 后，并行任务数翻倍。
49. 别为了烧而烧。装几个有用的 Skill 来实际降耗：MarkItDown 插件可以把 PDF、Word、PPT 转成干净 Markdown，减少无效 Token 消耗；Ponytail 技能自动检测并复用已有代码，避免重复编写，Token 消耗降低一半以上。
50. 最终的竞争与其说是谁掌握了更多提示词，不如说是谁建立了一套能持续消耗算力、自动完成任务、不断积累数字资产的 AI 生产系统。这系统是你真正的壁垒，它会随着时间越来越强。
你不需要一次性把 50 条全用上。先找一个每周都重复的任务，把目标、验收标准和上下文交代清楚，让 Codex 完整跑一遍。跑完复盘，把重复步骤写进 AGENTS.md 或做成 Skill。当 AI 开始持续替你推进真实任务，Token 才真正花到了结果上。