/tag/继上

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： （点击了解更多详细信息） 继上午话题 【claude Fable5 测试】速搓一个体积云效果，请打分 后，我想再优化一下 添加了丁达尔效应云层动态流动、柔和地面云影等优化 以上均为claude-fable5实现，只是在实际效果上，我自己加了略微的调整把控整体方向 整个项目也已开源，有兴趣佬友可自行拉源码玩 github.com GitHub - 123164867376464646/tyndall-clouds: Rust + wgpu 实时体积云渲染:纯着色器程序化生成,丁达尔光柱、云层动态翻腾、egui... Rust + wgpu 实时体积云渲染:纯着色器程序化生成,丁达尔光柱、云层动态翻腾、egui 实时调参 这次的结果我评价是 顶级 欢迎各位佬给出评价，最好是附有评价的理由 云层效果投票 夯 顶级 人上人 NPC 拉完了 点击以查看投票。 Fable5投票 夯 顶级 人上人 NPC 拉完了 点击以查看投票。 1 个帖子 - 1 位参与者 阅读完整话题

基于佬友的帖子 Codex 更新后 Chrome / Computer Use 插件消失/无法使用，如何让codex自己修复 - 开发调优 - LINUX DO 让codex CLI自己修Codex Desktop结果发现重启或更新后就又会出现Computer Use 插件不可用，后面让codex读 BigPizzaV3/CodexPlusPlus: An enhanced tool for CodexApp, striving to make Codex better to use and more comfortable 一个CodexApp的增强工具，努力让Codex变得更好用更舒服 让他自己写了codex++的脚本来解决Codex Desktop重启或更新导致的Computer Use 插件不可用 codex++路径 1.tool路径 %HOMEPATH%\AppData\Local\Programs\Codex++\tools\ 2.用户脚本路径 %HOMEPATH%\AppData\Local\Programs\Codex++\user_scripts\ codex-bundled-plugin-repair.js.txt (3.6 KB) 1 个帖子 - 1 位参与者 阅读完整话题

如题 继上一次发帖的备案问题得知需要一个国内服务器最好是购买域名的服务商那里直接买 剧透 那么有啥比较便宜的机器没 我就用来挂个备案用的 7 个帖子 - 4 位参与者 阅读完整话题

继上一篇文章：程序员失业后该怎么办，文章《 干了六年程序员，从一名职工到创业接外包，现在开始迷茫了，想转行了有佬友推荐吗 》 发出后，一直在思索方向，我自己也做了这么多年公司，知道等是等不来机会的，脑子一热，回老家溜达了一圈，还别说真让我给溜达了一个项目，回去种植中草药。 首先是对市场进行了考察，个人认为项目能不能做首先要看市场缺不缺，东西好卖是关键，这半个月时间跑了很多种植基地，了解了很多的市场价格，结论就是，比我现在做AI程序员强！ 附上一些记录图 当前这件事情落地也是相当需要功夫的，现在我已经做了土壤检测汇测规划，还需要去采购种苗（又得花钱），加上互联网科学化种植（已经联系了农科院提供返乡创业技术支持）是有一定成功率的，佬友们怎么看，感兴趣的话我后面来持续更新，给大家汇报种地成果 37 个帖子 - 21 位参与者 阅读完整话题

继上一帖--------------------------------全局开美国节点使用即可 脚本主要新增和优化了这些功能： 打开 GPT 页面按钮 新增"打开 GPT 页面"按钮。 点击后会切到配置的注册/取链节点。 清理 Clash 旧连接。 尽力清理当前站点数据：cookie、localStorage、sessionStorage、CacheStorage、IndexedDB。 然后打开 fresh GPT 首页。 自动获取 Plus 链接流程优化 自动取链前切到配置节点。 清 Clash 旧连接，避免旧连接继续走原 IP。 创建 checkout 后，跳转支付页前恢复原节点。 导出本地 CPA JSON 新增"导出本地 CPA JSON"按钮。 从 ChatGPT session 读取 access token。 导出 GuJumpgate 兼容的 CPA 单账号 JSON。 没有真实 id_token 时，会生成 synthetic CPA 兼容 id_token。 导出时同时复制到剪贴板并下载文件。 SUB2API 相关 保留"导出 SUB2API JSON"。 保留"直接导入 SUB2API"。 CPA JSON 和 SUB2API JSON 现在都作为独立按钮显示。 面板 UI 排版优化 按钮区改成分组布局： 流程控制 GPT / Plus 导出 / 导入 两列 grid 排版，关键动作整行显示。 减少按钮堆叠感，看起来更清楚。 代理配置 Clash：Clash API 地址，例如 http://127.0.0.1:9097 密钥：Clash Secret 代理组：要切换的代理组，例如 GLOBAL 注册/取链：用于打开 GPT 和获取优惠链接的节点，例如 日本-自动选择 支付/接码配置 电话：支付页手机号 接码：验证码接口地址 如果用号池，还需要配置： 接码号池：手机号----验证码接口 卡信息 卡号 有效期 CVV 也可以不手填，直接用"随机生成卡"。 SUB2API 配置，只有需要导入 SUB2API 时才填 SUB2：SUB2API 地址 账号：SUB2API 管理员账号 密码：SUB2API 管理员密码 分组：目标分组，例如 codex 代理：可空，代理名或代理 ID 优先级：默认 1 远程配置，可选 配置源：远程配置服务地址 Token：远程配置服务密钥 远程配置内容文件： paypal-auto-config.json 远程配置服务程序： paypal-auto-config-server.js 启动脚本： start-paypal-auto-config-server.bat paypal_auto.zip (28.0 KB) 3 个帖子 - 3 位参与者 阅读完整话题

在tg买gpt x5 被骗300 搞七捻三 [image] [image] [image] 悲，在卡网买的，应该是追不回来了 回来了，好像闹了乌龙，站长人还不错，还给我补了一个 [image] 后续来了 昨天晚上tg老哥和我说5x没有了，今天看看，然后今天说5x的搞不出来了，直接把他的20x给我用了，他真的，我哭死 也感谢上一篇帖子的佬友和我说应该不是骗人的，真的有时候要反思下自己，不能情绪上头，凡是和和气气的讲话，理智才行 然后我就放个tg聊天图吧，这件事情到此打住，不占用大家资源了 2 个帖子 - 2 位参与者 阅读完整话题

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。

原文在这里： logseq 。 这篇文章是我同事在出差的时候问我能不能分享一些 AI 经验给客户，进而形成的一篇文章，内容可能有点乱，可以多看看 skill 部分，那里是我用过的所有 skill ，是最核心最能给大家提效的部分。 大家也可以 follow 一下我 github ，最近也在做一些好玩的项目，希望和大家交流经验和感悟～ 1. 背景 本文是一篇面向开发者的 AI 提效 Harness 教程，主要讲讲我自己是怎么把 Codex App 、模型、skills 、提示技巧、编辑器、终端和任务管理方式串起来用的。 这里的 Harness 不是一个具体的软件，也不是一个神奇 Prompt 。 你可以简单理解成：为了让 AI 更稳定地参与开发工作，我们提前搭好的一套工作框架。 ps: 这篇文章不讲很玄学的 AI 理论，主要是偏开发者日常使用的教程。如果你平时已经在用 Codex 、Cursor 、Claude Code 、Warp 、Zed 这些工具，应该会比较容易理解。 2. AI 提效 Harness 是什么？ 我这里说的 AI 提效 Harness ，主要包含下面这几部分： 模型：比如 gpt-5.5 、gpt-5.4 、gpt-5.3-codex 这类稳定可用的模型。 skills：比如 think 、hunt 、check 、design 、find-docs 、agent-browser 、git-commit 、pr-creator 这些固定工作流。 提示技巧：不是神级 Prompt ，而是把目标、上下文、约束、验收标准写清楚。 工具与环境：比如 Codex App 、Warp 、Zed 、浏览器 Agent 。 如果用一句话来解释： Harness 就是把 AI 从一个聊天框，变成一个可以进入开发流程的工作系统。 没有 Harness 的时候，你可能是这样用 AI 的： 遇到问题 -> 问 AI -> 拿到回答 -> 自己试 -> 不行再问 有 Harness 以后，流程更像这样： 明确任务 -> 选择模型 -> 选择 skill -> 给出项目规则 -> 执行 -> 测试 -> 看 diff -> 总结沉淀 看起来步骤变多了，但是实际会更稳。 因为 AI 最容易出问题的地方，往往不是它不会写代码，而是它不知道边界在哪里。 3. Harness 的组成部分 3.1 模型层 模型层主要解决一个问题：什么任务用什么模型。 不建议每次都临时纠结。可以直接给自己定一个默认规则。我一般是用 gpt ，claude 也行，不过 codex 太好用了，所以我选 openai 系的模型，直接用最好的就行，比如 gpt-5.5 的超高 think 。 模型这方面最好是公司去做支持，做到每个人畅用，退而求其次的话就是去闲鱼买账号，保密性公司就用自己能力范围内最好的模型即可（不过这种方式我只能说跟闭源顶级模型没法比，效率天地之差）。 3.2 skills 层 Skill 也不是必须使用的，当你觉得任务对于 codex 很困难的时候或者说对 codex 没信心或者想要更好的效果时再使用。 skills 层主要解决一个问题：怎么把重复工作流固定下来。 我之前在 Skills 里整理过一批自己在用的 skill ，这里按使用场景完整列一下。 3.2.1 编码类 Waza ：tw93 出品，我很喜欢的一套 skill 。 think：构建之前的验证过程，会做调研、方案生成、方案攻击、交付验证。 design：生成界面设计，可以引用参考著名网站，效果很好。 check：PR 合并前的专业检查，适合交付前审一遍。 hunt：修复 BUG 专用，核心是先找根因，再动手改。 shadcn ：如果项目里用了 shadcn/ui ，这个基本是必备的。 vercel-composition-patterns ：React 组件和 API 的常见可复用模式。 vercel-react-best-practices ：React 性能和重构指南。 create-readme ：专门写 README 的 skill ，比较简单，但是够用。 3.2.2 设计类 impeccable ：我现在主要用的设计类 skill 。 impeccable：总控 skill ，一般先 teach ，再多次 craft ，必要时 extract ，然后继续 craft 。 polish：交付之前的最后完善，用来对齐设计系统和精调页面。 critique：设计总监视角的 UX 评审，适合找下一步应该修什么。 live：适合细节级别的页面选项，不适合整体大改。 audit：上线前或重构前做代码级检查，包含可访问性、性能、主题、响应式等。 distill：删繁就简。 clarify：优化文案。 optimize：优化 UI 性能。 onboard：处理新用户进入相关的产品交互。 harden：补边界情况和压力测试。 animate：给具体功能增加有目的的动画。 colorize：有策略地修改整体配色。 bolder / quieter / delight：分别用于增强、减弱、增加惊喜感。 adapt / typeset / layout：分别处理多端适配、文字排版、布局改进。 overdrive：想做超出常规边界的 UI 时使用。 shape：开工之前做功能 UI 访谈。 logo generator ：生成 logo 的 skill 。 3.2.3 浏览器和文档处理类 agent-browser ：使用 agent-browser 这个 CLI 操作浏览器，返回数据精简，适合 AI Agent 。 不过我现在一般使用 codex 内置的 browser use 和 computer use ，很好用。 docx ：处理 docx 。 pdf ：处理 PDF 。 find-docs ：Context7 查官方文档的 skill 。 3.2.4 提交和协作类 git-commit ：根据 diff 生成规范提交信息。 pr-creator ：提 PR 用的，生成规范的标题和描述。 3.2.5 写作和研究类 Waza 里的 read 、learn 、write 也很常用。 read：获取网页或者 PDF ，内置了一些常见网站的处理脚本和参考。 learn：新领域深挖、研究型文章写作、已有资料的系统化产出，时间较长但是效果很好。 write：编写、改写、润色文案，同时减轻 AI 味。 kami ：固定风格和模板的 PPT / PDF 生成 skill ，可以生成简历、一页纸、长文档、信件、作品集、PPT 、个股研报、更新日志。 khazix skills ：数字生命卡兹克的 skills 集合，内容质量很高。 neat-freak：**每次任务跑完后**跟文档、CLAUDE.md / AGENTS.md 、Agent 记忆三者对齐，最好手动触发。 hv-analysis：横纵分析法，适合研究产品、公司、概念、人物，会生成一个深度分析报告。 khazix-writer：写卡兹克风格的公众号文章。 3.2.6 不适合我，但是值得知道 taste ：比 Waza design 和 impeccable 更激进，适合生成一些落地页。 oh-my-codex ：一套固执己见的 Codex 增强套装，适合新手，但是侵入性比较强。 gstank ：YC 总裁的一整套 skill 体系，适合 CEO 等新人人群，一键使用，但是不太适合灵活开发者。 andrej-karpathy-skills ：简洁优先的一套 CLAUDE.md 思路，用来解决复杂度过高的问题，可以用 skill 模式参考，不建议直接装成全局规则。 注意：skill 不是越多越好。开发者的 skills 宗旨应该是简单、功能聚焦、可用性强、不花活、快速。 我个人不建议一上来安装几十个 skill 。 因为功能重叠以后，AI 可能也不知道该用哪个，你自己也记不住（我列的这里面主要设计方面的 skill 有几个冲突的，我一般是用 waza 的 design ）。 先保留 6-10 个最常用的就够了。 3.3 项目规则层 项目规则层主要解决一个问题：AI 进入项目以后，应该遵守什么规则。 这里我之前写得不完整，规则其实至少要分两层。 全局规则：放所有项目都适用的个人偏好和安全边界。 项目规则：放当前仓库的目录结构、命令、测试方式、业务边界。 以我自己的机器为例，全局规则在 ~/.codex/ AGENTS.md 。 这个文件里适合放这类规则： 不要执行数据库写操作，除非我明确要求。 生产部署默认构建并推送 linux/amd64 镜像。 查库、框架、SDK 、CLI 文档时默认使用 Context7 。 测试阶段需要推远程镜像时，默认用我已经配置好权限的镜像仓库。 这些规则和具体项目无关，但是对所有项目都应该生效，所以适合放全局。 项目级规则就不要写这些机器级偏好，而是写当前仓库的真实信息。 比如项目级 AGENTS.md 可以这样写： # 项目规则 ## 项目说明 - 这是一个 xxx 项目 - 前端目录在 xxx - 后端目录在 xxx ## 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 类型检查：pnpm typecheck - 单元测试：pnpm test - lint：pnpm lint ## 修改约束 - 不要修改无关文件 - 不要重构本次任务之外的代码 - 不要覆盖用户已有改动 - 不要执行数据库写操作，除非用户明确要求 ## 验收标准 - 修改完成后说明改了什么 - 尽量运行相关测试 - 如果测试失败，需要说明失败原因 - UI 改动需要检查桌面和移动端效果 这个文件不需要写得很长。 写得太长反而容易让重点被稀释。 一个比较好用的原则是： 全局规则写「我永远不希望 AI 做什么」。 项目规则写「这个仓库应该怎么做」。 最开始建议只写三类内容： 常用命令。 禁止操作。 交付标准。 后面你发现自己反复提醒 AI 的事情，再慢慢补进去。 我项目下一般会放哪些规则文件？ 使用 neat-freak 这个 skill 每次任务完成后对这些文件进行更新 DESIGN.md ：写设计风格 ROADMAP.md ：路线图，用来给 Codex 划分优先级 AGENT.md ：Codex 规则文件，写项目介绍、基本规则（ Not do ）、运行命令等等，写啥 Codex 自己知道 docs 文件夹 architecture.md：架构文档 ia.md：页面结构文档 product.md：产品文档 references.md：参考文档，如果我这个项目有别的现有参考项目，会维护在这里 runbook.md：运行命令的详细介绍 3.4 工具与环境层 工具层主要解决一个问题：每个工具负责什么。 我自己的使用方式大概是这样： Codex App （核心常用，功能很多，文章末尾有教程学学我这里不写了，其他的都是偶尔打开）：负责长任务、多文件修改、跑测试、总结结果。 Warp：偶尔跑跑命令，用来做主工作台也可以，适合喜欢终端的人，也能做到类似 codex app 这种侧边栏的效果（我之前就用 warp ，后来切换到 codex app ） Zed：负责最后看 diff 、精修文字、手动改一些细节。一般是很严格正式的项目我会仔细看一下，大部分我不会细看。 agent-browser：负责真实打开页面、点击、截图、做前端验证。 Git：负责版本边界、提交、回滚和 PR 。 环境的话就稍微说一下，关于我怎么让 codex 使用环境。 我一般的话是开发使用本地环境，然后在本地放一个内网测试环境的 kc ，然后让 codex 直接操作 kc 往测试环境上部署。这样验收是非常方便的，就不需要你写测试环境的命令。 我会告诉 codex 我们当前项目在哪个 ns 下，然后 codex 自己是能读懂各种 k8s 相关的东西，测试环境崩了也没事，一般不会崩，崩了基本可以回退，如果崩了不可以回退，codex 误操作的概率不大（除非你指定了一些危险操作），崩了说明环境有问题，可以反促进去对测试环境的维护和代码鲁棒性的提升。 3.5 怎么管理自己的任务？ 用 Codex 用多了之后，你会发现需要同时推进特别多的项目，包括需求和 bug 。 有一些管理的技巧： 使用你最常用的工具来管理你的所有任务，我是使用我最常用的笔记软件 logseq 来管理所有的任务，我会把所有任务都标记成 Now 状态，然后 now 状态会一直挂在我打开笔记的第一个屏幕。然后你就可以慢慢处理。 Codex App 有任务完成的小蓝标，也很方便可以让你看到任务完成的标志。 3.6 关于提示技巧 没太多技巧，能把需求讲清楚尽量讲清楚。这里有个核心技巧就是，在讲完需求之后让 AI 复述一下需求。这样就能够判断你俩对没对齐。 再就是尽量显式指定 skill 去让 codex 执行，skill 对效率的提升是巨大的。 4. 怎么搭建自己的 Harness ？ 4.1 第一步：先写一个最小规则文件 不要一开始就写很复杂。 先写全局规则，再写项目规则。 全局规则写在 ~/.codex/ AGENTS.md 这类位置，用来放所有项目都通用的规则。 项目规则写在当前仓库里，用来放当前项目的命令和约束。 全局规则建议只包含： 安全边界。 默认偏好。 通用工具使用方式。 项目规则建议只包含： 项目说明。 常用命令。 不允许做的事情。 验收标准。 这个文件的目标不是写得漂亮，而是让 AI 少犯重复错误。 4.2 第三步：精简你的 skills 先不要追求全。 先保留你真正会用的。 比如： 设计就用 design 。 修 bug 用 hunt 。 做方案用 think 。 交付前用 check 。 查文档用 find-docs 。 测页面用 agent-browser 。 提交用 git-commit 。 提 PR 用 pr-creator 。 等你发现某类工作经常重复，再考虑新增 skill 。 再就是 skill 的话尽量不要靠 codex 自己去决定使用什么，而是自己明确指定，因为很多情况下 codex 不会知道调用什么 skill ，我们指定会得到更好的结果。 4.3 第五步：每周复盘一次 Harness 不是一次写完的。 你可以每周看一下： 哪些话你反复对 AI 说。 哪些任务 AI 经常跑偏。 哪些测试 AI 经常漏掉。 哪些文件 AI 经常误改。 然后把这些东西补到 AGENTS.md 或者对应 skill 里。 这样你的 Harness 会越来越贴合自己的工作方式。 5. 推荐阅读 怎么使用 Codex App 看这个视频： {{video( https://www.bilibili.com/video/BV1dhdSB6E9E?share_source=copy_web)}} 如果你想继续看一些和 Agent 、Harness 、上下文工程有关的资料，可以先看下面这些资料。 想学习 skill 的话就直接看上面那些 skill 是咋写的即可。 Anthropic：Building effective agents ：这篇文章把 workflow 和 agent 区分得很清楚，适合理解为什么不要一上来就追求全自动。 Anthropic：Claude Code best practices ：Claude Code 官方实践，里面很多内容和本文说的项目规则、任务拆分、验证很接近。 OpenAI：A practical guide to building agents ：OpenAI 的 Agent 实践指南，偏产品和系统设计视角。 OpenAI：Codex AGENTS.md 指南 ：讲 Codex 怎么使用 AGENTS.md ，可以直接参考它的结构。 OpenAI：Codex prompting guide ：适合看 Codex 任务怎么写得更清楚。 HumanLayer：12-Factor Agents ：非常有名的一组 Agent 工程原则，适合理解为什么上下文、状态、人工介入和可控流程很重要。 Cursor Rules ：如果你使用 Cursor ，可以参考它的 rules 体系来补自己的工具规则层。 Aider：Linting and testing ：Aider 对 lint/test 的支持很适合说明为什么验证应该成为 Harness 的一部分。 Andrej Karpathy：Software Is Changing Again ：这不是纯教程，但适合理解 AI 时代软件开发形态的变化。 6. 总结 总之，面向开发者的 AI 提效，不应该只关注哪个模型最强，也不应该只收藏各种 Prompt 。 更重要的是搭一套自己的 Harness： 固定模型路由。 写清项目规则。 精简 skills 。 明确工具分工。 把验证方式写清楚。 持续复盘和沉淀。 只要这套东西跑起来，AI 就不再只是一个问答工具，而会慢慢变成开发流程的一部分。 大功告成。