+ 
+ 上周我和朋友聊到了一些 AI 开发相关的问题。
+一开始只是一个很具体的工具使用问题：Claude Code 的桌面端和 CLI 到底有什么区别？他平时用终端比较多，但又觉得终端复制 Markdown 不方便。比如写邮件、写文档、整理内容时，他希望复制出来就是渲染好的格式，而不是一堆原始 Markdown 文本。
+但聊着聊着，话题很快就从“桌面端和 CLI 哪个更顺手”，延伸到了 AGENTS.md、上下文记忆、项目规则、Spec 开发这些东西。
+聊完之后我有一个很强的感受：这些东西并不是学不会，而是很多人根本不知道自己需要学，也不知道应该从哪里开始学。
+今天又看到有人在讨论 Loop Engineering，也就是所谓的“循环工程”。这个概念一下子把我最近的很多感受串起来了。
+过去我们总是在讨论 Prompt 怎么写，怎么把一句话写得更准、更完整、更能让 AI 听懂。但真正开始高频使用 Claude Code、Codex、Cursor 这类 AI Coding 工具之后，我越来越觉得，Prompt 只是入口，真正决定效率上限的，是你有没有设计出一套能持续运转的工作流。
+这个问题表面上是在问工具形态：一个是桌面端，一个是命令行。但越往后聊，我越觉得它背后其实是另一个更大的问题：
++我们到底应该怎么正确使用 AI Coding 工具？
很多人第一次接触 Claude Code、Codex、Cursor 这类工具时，本能上还是把它们当成一个更强的 ChatGPT。打开对话框，输入一句 Prompt，让它写代码；不满意，再补一句；跑不通，再让它 debug。
+这个流程当然能用，但它本质上还是“人一轮一轮推着 AI 往前走”。
+Addy Osmani 最近在 Loop Engineering 视频里讲了一个很有意思的判断：未来真正重要的，不是你自己一遍遍去 Prompt Agent，而是设计一个系统，让这个系统去驱动 Agent。换句话说，Prompt 不是没用了，而是它的位置变了。它不再是整个工作流的核心，而只是 Loop 里的一个零件。
+这也是我最近越来越强烈的感受。AI 驱动开发真正改变的，不是“我少写了几行代码”，而是开发者的工作重心开始往后退一层：从写代码，退到写 Spec；从写 Prompt，退到写 AGENTS.md；从临时沟通，退到设计规则、记忆、验证和循环。
+所以这篇文章不想写成一篇单纯的工具测评，也不想只讨论“Claude Code 和 Codex 谁更好用”。我更想借着这次和朋友的聊天，重新梳理一件事：
++ +在真正进入 AI 驱动开发之前，我们到底需要先知道什么？
01 你到底在用哪种 AI Coding 工具？
+
+ 先从最小白的问题开始：桌面端和 CLI 到底有什么区别？
+在我看来，桌面端更像“人看的工作台”。它适合聊天、复制内容、整理 PDF 等文档、生成图片、跨应用操作。比如你让 AI 写一段邮件、整理一份文档、生成一张图片，桌面端的体验通常会更自然，因为它更接近我们平时使用软件的方式。
+CLI 则是另一种完全不同的入口。它需要在终端里启动，也就是那个黑黑的窗口。你不会像使用普通软件一样到处点按钮，而是主要通过键盘输入命令来操作。对于刚接触的人来说，这个界面一开始会有点陌生，甚至有点“不像软件”。
+CLI 里通常会有一套 slash command，也就是以 / 开头的斜杠命令。它们不是发给模型的普通 Prompt，而是用来控制工具本身的功能入口。
+但 CLI 的优势也正是在这里。因为它没有复杂的前端界面和图形渲染，整体会更轻、更直接。尤其是在处理多任务、长时间跑代码、执行测试、读取项目文件时，CLI 往往不会像桌面端那样容易受到界面卡顿的影响。很多命令也支持自动补全，你只需要输入前几个字母，它就能帮你补全后面的内容。熟悉之后，这种方式反而非常快。
+所以桌面端和 CLI 不是谁替代谁，而是面向不同任务。
+如果你的任务是写邮件、整理材料、做内容、跨应用操作，桌面端会更舒服。如果你的任务是改代码、跑测试、维护项目上下文，CLI 往往更自然。一个偏向“人如何看和调度”，一个偏向“Agent 如何在工程现场执行”。
+这个区别在 Codex 和 Claude Code 这一类工具上会越来越明显。早期很多 AI Coding 工具的 CLI 功能更强，因为它们本来就是给极客程序员和重度开发者准备的。但现在桌面端也在快速补齐能力，甚至开始拥有更多面向普通用户的自动化入口，比如浏览器操作、桌面操作、跨应用控制等。
+这背后其实是厂商在做用户分层。
+如果你是刚入门的小白，甚至还没有形成“每个项目都应该在固定文件夹里打开”的习惯，那你直接使用 Web 端或者桌面端里的 Chat 模块，反而更合适。你不需要关心当前工作目录在哪里，也不需要理解 git、shell、依赖环境这些东西，系统会帮你把会话和结果保存在默认位置。
+但如果你已经比较熟悉代码开发，就应该知道，真正写项目时最好在本地创建一个专门的代码目录，然后在 CLI 或 IDE 里打开这个目录。因为 AI Coding 不是让模型凭空生成一段代码，而是让它进入你的项目现场，理解文件结构、执行命令、跑测试、根据反馈继续修改。
+简单来说，可以先这样理解：
+| 使用场景 | +更适合的入口 | +
|---|---|
| 日常问答、写作、内容整理 | +ChatGPT / Claude Desktop / Codex 桌面端 | +
| 图形化管理 AI 编码任务 | +Codex App / Claude Desktop Code 模块 / IDE 插件 | +
| 重度开发、终端工作流、项目级执行 | +Codex CLI / Claude Code CLI | +
02 AI Coding APP 不是聊天框，而是 Agent Harness工程
+
+ 很多人用 Claude Code / Codex，还是 ChatGPT 的使用习惯：
+++“帮我写一下。”
+“再改一下。”
+“再修一下。”
+
但真正的 AI Coding 工具不是聊天框，而是一个能读文件、改文件、跑命令、维护上下文的本地 Agent Harness。
+这里有一个很重要的分界线：
++如果你只是把它当聊天框，你用到的是模型能力；如果你把它当 Harness，你用到的才是 AI 驱动开发能力。
大模型现在对于上下文足够的任务处理得非常出色。但上下文能力只是基础，真正让 AI Coding APP 变得不一样的，是它开始拥有“进入项目现场”的能力。
+如果你在 ChatGPT 里问：“这个 bug 怎么修？”它大概率会给你一段建议，或者生成一段代码。但在 AI Coding APP 里，它可以直接打开你的项目文件，找到相关代码，修改实现，执行测试，然后告诉你哪些测试通过了，哪些地方还需要继续处理。
+这件事听起来只是“多了几个工具调用”，但实际体验差别非常大。因为软件开发从来不是单纯写一段代码。它是一整条链路：理解需求、定位文件、修改实现、跑测试、看日志、修复问题、确认结果。过去这些环节都需要人手动串起来，现在 Agent Harness 开始把这些动作接到同一个工作流里。
+这条分界线很重要，因为它决定了你到底是在“和模型聊天”，还是在“让 Agent 参与开发流程”。
+这也是为什么我越来越不建议新手一上来就只研究“Prompt 怎么写得更好”。Prompt 当然重要，但它只是入口。真正决定上限的，是你有没有让 AI 进入正确的工作环境，有没有给它足够清晰的上下文，有没有让它知道项目规则，有没有让它执行完之后进行验证。
+换句话说，AI Coding APP 的重点不是“让 AI 多说一点”，而是“让 AI 真正参与一轮开发闭环”。
+这时候，开发者的角色也会发生变化。你不再只是一个给模型下指令的人，而更像是在管理一个可以执行任务的 Agent：你要告诉它目标是什么，边界在哪里，哪些文件能动，哪些地方不能碰，做完之后怎么验证，失败了应该怎么记录。
+ +03 Prompt Engineering还有用，但没那么有用了
+
+ 讲到这里，就可以回到最近很火的那个说法：提示词工程是不是已经死了？
+我觉得这个说法有传播性，但不够准确。
+Prompt 没死，只是它不再是最核心的能力。
+在24年更早一点的时候，大家使用 AI 的方式很简单：打开一个对话框，然后想办法把第一句话写清楚。你要告诉它背景是什么、目标是什么、输出格式是什么、语气是什么、限制条件是什么。那时候大家讨论最多的东西，就是 Prompt 怎么写得更好。
+这个阶段当然有价值。因为模型如果连你的需求都没听懂，后面所有生成结果都会跑偏。
+但当模型能力变得越来越强，能够在更长上下文里调用更多工具时，问题开始发生变化。真正耗时间的，往往已经不是第一句 Prompt，而是后面那一整串反复发生的动作：它写完之后你要检查，报错之后你要让它修，修完之后你要跑测试，测试失败之后你要继续补充上下文，最后还要记录这轮到底做了什么。
+这时候，如果你还把全部精力放在“怎么写一句完美 Prompt”上，就很容易陷入一个误区：你以为自己在自动化开发，其实还是在手动推动每一轮对话。
+Addy Osmani 在 Loop Engineering 视频里提到的核心变化，正好对应这个问题。未来更重要的，不是人一遍遍去 Prompt Agent，而是设计一个系统，让这个系统去驱动 Agent。也就是说，我们要关注的不只是“这一句话怎么说”，而是“这一整轮工作应该怎么转起来”。
+Prompt 更像一次性指令。Loop 更像持续运转的系统。
+Prompt 是你临时告诉 AI：这次你应该怎么做。Loop 是你提前设计好：每一轮应该从哪里启动，读取什么上下文，执行什么动作，用什么方式检查结果，失败了怎么重试，成功了记录到哪里，什么时候继续，什么时候停下来交还给人。
+这两者的差别非常大。
+如果你只写 Prompt，你每次都要重新解释一遍背景、规则和目标；但如果你开始设计 Loop，你就会把这些东西沉淀下来，让它们变成可复用的流程。比如项目规则写进 AGENTS.md，上下文沉淀到 docs/ai/context/，开发前先写 Spec，改完之后跑测试，失败结果写回记录里，下一轮再基于这些记录继续推进。
+所以我更愿意把 Prompt 理解成 Loop 里的一个零件，而不是整个 AI Coding 的核心。
+真正的变化不是“以后不用写 Prompt 了”，而是 Prompt 从前台退到了后台。以前我们追求的是一句话让 AI 做对，现在我们追求的是一套流程让 AI 持续做对。
+这也是 AI 驱动开发开始变难的地方。它不是让你彻底不用思考，而是把你的思考从“怎么写一句话”挪到了更高一层：
+-
+
- 这个任务适不适合交给 Agent？还是在对话窗口简单 chat 就能解决？ +
- 它需要哪些上下文？上下文哪些能否保存复用？ +
- 执行之后怎么验证？ +
- 失败之后怎么恢复？失败怎么兜底？ +
- 哪些结果应该被记住并持久化保存？ +
- 什么情况需要人介入？ +
这些问题，才是 Prompt 之后真正重要的东西。
+ +04 如何用长期记忆更高效地使用 Codex、Claude Code？
+
+ 讲到这里，就会进入一个很关键的问题：如果 AI Coding APP 不是普通聊天框，那我们到底应该怎么更高效地使用它？
+我的理解是，第一步不是去写一个更长的 Prompt，而是先把那些长期重复出现的规则沉淀下来。
+以 Codex 为例，当你安装并使用它之后，在你的全局目录下会有一个隐藏目录，比如 Windows 上通常是 C:\Users\yui\.codex\。这个目录里可以放一个全局的 AGENTS.md 文件。它不是某一次任务的临时提示词，而更像是你长期希望 Codex 遵守的个人工作习惯。
比如你希望它默认使用中文，希望它修改代码前先做设计和计划，希望它不要覆盖用户已有改动，希望它把上下文记录到固定目录里，这些都适合写进全局 AGENTS.md。
+而当你进入一个具体项目时，这个项目本身也可以有自己的项目级 AGENTS.md。它负责描述当前项目的规则：项目怎么启动，测试命令是什么，哪些目录不能动，代码风格是什么，文档和上下文应该保存到哪里。
+最后，才是你每次对话时输入的 User Prompt。它负责描述这一次具体要做什么，比如“修复这个 bug”“补一组测试”“把这段 OCR 文本整理成公众号文章”。
+这三层不是简单地互相替代，而是叠在一起工作：
++User Prompt 负责这一次要做什么，项目级 AGENTS.md 负责这个项目里应该怎么做，全局 AGENTS.md 负责你长期希望 Codex 以什么方式做事。
越具体、越靠近当前任务的指令，通常优先级越高。
+Claude Code 里也有类似的思路，只是文件名和生态习惯不同。很多人会在项目里维护 CLAUDE.md，用来告诉 Claude Code 当前项目的开发规则、命令、边界和偏好。
+但这里有一个坑：不要一开始就为了写规则而写规则。
+如果你一上来就预设一个庞大、死板、面面俱到的规则文件，很容易把 AI 约束死。它可能变得不敢动，也可能在一堆抽象规则里抓不到重点，最后反而更容易跑偏。
+更好的方式是先跑起来。
+当你在真实使用中发现自己第二次、第三次重复提醒 AI：“测试脚本必须先执行某个前置命令”“前端组件统一使用类似 Apple 的磨砂玻璃 UI 风格”“所有设计文档都要落到 docs/ai/context/ 目录”，这时候就说明这条规则值得被沉淀下来。
+直白来说：
++如果你长期反复使用一套流程，就应该把它写进规则文件里，而不是每次都重新在聊天框里解释一遍。
比如我的全局配置里，会放一些长期稳定的偏好：
+# 通用偏好
+
+- 默认使用中文；文档、说明、总结、计划、回复和代码注释都必须使用中文，除非用户明确要求英文
+- 代码注释写原因，不写过程
+- 表达简洁直接，不要多余总结
+
+## 代码风格
+
+- 函数式优先，组合优于继承，TS/JS 中避免 OOP
+- 新功能优先复用或重构现有代码，不堆砌
+- KISS、DRY，采用最简可行方案
+- 发现设计不合理：小问题直接重构，大问题原地加 TODO 并说明原因
+
+## 文档与上下文
+
+- 在进入任何实现前，必须先完成 design / plan 阶段
+- 所有改动、上下文、tradeoff、背景信息，都保存到项目的 `docs/ai/context/` 目录
+- 新增内容时只允许创建新文件，不要覆写、重命名或删除之前的历史文件而项目级配置会更具体。比如某个项目的 AGENTS.md 里，我会放这个项目已有的上下文索引：
+## 项目上下文索引
+
+- `docs/ai/context/20260607-134929-home-character-html-plan.md`：记录人物图片透明背景处理、新建白底居中 HTML 的设计、取舍和验证方式。
+- `docs/ai/context/20260607-140547-new-homepage-demo-plan.md`：记录将老主页文字和导航转换为图一风格新主页 demo 的设计、取舍和验证方式。
+- `docs/ai/context/20260607-172109-video-frame-loop-plan.md`：记录将 73 帧视频逐帧透明化，并在首页以 5 秒前进/倒序循环播放的设计、取舍和验证方式。这样做的好处是，AI 每次进入项目时，不会像一个完全陌生的新同事。它能先看到项目过去发生过什么、哪些方案已经做过、哪些取舍已经确定、接下来应该沿着什么方向继续。
+所以很多人以为 AGENTS.md 或 CLAUDE.md 只是 Prompt，但在我看来，它更像 AI Coding APP 的“项目操作手册”。
+它应该回答的是这些问题：
+-
+
- 项目怎么启动？ +
- 哪些目录不能动？ +
- 代码风格是什么？ +
- 实现前要不要写 plan？ +
- 修改后要跑哪些测试？ +
- 上下文要保存到哪里？ +
- 什么情况必须问用户？ +
- 什么情况可以直接执行？ +
这也是我现在越来越确定的一点：
++真正高级的 Prompt，不应该反复写在聊天框里，而应该沉淀成规则文件。
Prompt 解决的是这一次怎么做，规则文件解决的是以后每一次都应该怎么做。
+当你开始把这些规则沉淀下来，AI Coding 才会从“每次重新沟通”变成“持续积累工作流”。这也是从 Prompt 走向 Loop 的第一步。
+ +05 Skill：把规则进一步拆成可复用能力
+
+ 如果说 AGENTS.md / CLAUDE.md 更像项目规则，那么 Skill 更像一套可复用的工作流模块。
+项目规则解决的是“这个项目里应该怎么做”。Skill 解决的是“遇到某一类任务时，应该按什么流程做”。
+比如写文章可以有一个 Skill，做代码 Review 可以有一个 Skill，做 Spec 开发可以有一个 Skill，做 OCR 整理可以有一个 Skill，做 PR 巡检也可以有一个 Skill。
+这两者不是互相替代的关系，而是可以嵌套使用。
+举个例子，我可以在全局 AGENTS.md 里要求 Codex 每次新对话开始时，先读取并使用 using-superpowers 这个 Skill。这样我就不需要每次开发前都手动提醒它：“你先别急着写代码，先做设计和计划。”规则文件会自动告诉它：进入实现之前，必须先完成 design / plan 阶段。
+这就是规则文件和 Skill 配合起来之后的效果。
+这里还有一个很重要的点：
++Skill 应该服务你的工作流，而不是反过来让你迁就 Skill。
比如 using-superpowers 这类 Skill，默认可能会把生成的设计文档、计划文档放到它自己的目录里。但我的项目习惯是把所有 AI 上下文都保存到 docs/ai/context/。所以我会在项目级 AGENTS.md 里明确要求：所有设计、取舍、背景信息和结果文档，都必须落到我指定的 docs/ai/context/ 目录下。
+原因很简单：这是我的项目上下文系统。
+我不希望上下文散落在各个工具自己的目录里，也不希望以后回看一个项目时，还要到处翻 Skill 的内部文件夹。真正有价值的上下文，应该回到项目本身，成为项目资产的一部分。
+这也是我为什么会把 Skill 的输出重新约束回项目目录。
+更进一步，Skill 不只可以用于单次任务，还可以和自动化任务结合起来，变成一个长期运行的小助手。
+我最近就做过一个这样的工作流：每隔 12 小时，Codex 会自动检查我 GitHub 账号 cnYui 下所有 open PR 的最新反馈。如果有新的 review comment、maintainer comment、CI 失败或者 requested changes，它会按风险分级处理。
+这个任务大概会做几件事：
+-
+
- 拉取我当前所有 open PR。 +
- 检查 review comments、issue comments、CI/check runs、merge 状态。 +
- 只处理我上次回复之后的新反馈，避免重复评论。 +
- 如果是事实性问题、CI 权限、CLA、外部服务阻塞这类不需要改代码的问题，就直接用简短、基于证据的方式回复。 +
- 如果反馈要求改代码、补测试、修真实失败的 CI，就自动检出对应 PR 分支，在独立目录里修改、测试、提交、推送，再回到 PR 里说明改了什么、跑了什么验证。 +
- 如果遇到需要用户账号操作、签署协议、付费授权、维护者权限或者产品方向决策的问题，就不上手乱改，只上报 blocker。 +
这样一来，它就不是一个“帮我看一下 PR”的临时 Prompt，而是一个每 12 小时自动运行的 PR 巡检 Loop。
+更有意思的是，这个 Loop 还可以继续扩展。比如你可以把它接到 Gmail 上：一旦 Gmail 里出现 GitHub 发来的 PR 反馈邮件，就触发对应任务，读取邮件内容，再进入 PR 检查、修改、提交和回复的流程。
+这时候你会发现，所谓 AI Harness 开发，不只是 Agent 自己调用工具的那个小循环，而是一个“用户 + AI + 工具 + 规则 + 记忆”的大循环。
+在这个大循环里：
+-
+
- 用户通过全局规则、项目文档、Skill 和自动化任务，组合出一套自己的工作流。 +
- 每个工作流内部，又可以嵌套很多个 Agent Loop，让 Agent 去读文件、改代码、跑测试、查 PR、写回复。 +
- Agent 能调用哪些工具、怎么调用、什么时候停下来，都需要用户提前在规则和文档里定义清楚。 +
所以真正难的不是“让 AI 执行一个任务”。
+真正难的是你要站在更高一层，设计这个系统怎么转起来。
+这也是我为什么说，Prompt 只是最外层的入口。
+++Prompt 是一句话。
+AGENTS.md / CLAUDE.md 是一份规则。
+Skill 是一套可复用动作。
+Automation 是让这套动作定时或按事件启动。
+Loop 则是把这些东西串起来，让它持续运转。
+
当你熟悉掌握了这点之后，AI Coding 就不再只是“小白会用工具”的阶段，而是进入“进阶用户设计系统”的阶段。
+你不再只是问 AI：“帮我做一下这个。”
+你开始设计的是：以后每次遇到这种事情，AI 应该如何自动发现、自动处理、自动验证、自动记录，以及在什么情况下必须停下来交还给人。
+