看完这篇文章，我越来越觉得，现在很多人对 Claude Code、Codex 这些 AI Coding 工具的理解，可能还停留在一个比较初级的阶段。 打开工… · @UPing123zzz · TwKit

@UPing123zzz

看完这篇文章，我越来越觉得，现在很多人对 Claude Code、Codex 这些 AI Coding 工具的理解，可能还停留在一个比较初级的阶段。 打开工具，输入需求，让 AI 写代码，遇到报错就继续把问题丢给 AI，直到项目能够运行，我自己之前也是这样用的。 但这几个月一直在做 AI 项目，我慢慢发现，真正值得研究的，不只是怎么让 Agent 写出更多代码，而是怎么建立一套让 Agent 按照规则工作、复用经验、自动验证结果的工程体系。 这篇文章把 Claude Code 的 Agent 开发体系分成了五个部分，我觉得很值得参考。 第一层是 CLAUDE.md，用来定义整个项目的规则。比如项目架构、代码规范、文件目录、测试要求，以及哪些操作不能随便执行。否则你每次开启新会话，都要重新告诉 Agent 应该怎么做。 第二层是 Skills，把一些重复性的工作方法沉淀下来。比如做 RAG 系统时，文档应该怎么解析、检索效果怎么评估、哪些情况必须拒答。与其每次重新写一堆提示词，不如把经过验证的流程整理成可复用的 Skill。 第三层是 Hooks，在一些关键操作前后自动执行检查。比如修改代码后触发测试，提交前检查格式，执行高风险命令前增加限制。但 Hooks 也不是万能的，真正涉及敏感数据和生产环境的操作，依然需要权限控制和人工审批。 第四层是 Subagents，把不同任务分配给专门的 Agent。一个负责研究方案，一个负责实现功能，一个负责测试或者 Code Review，而不是让一个 Agent 从头到尾包办所有事情。 第五层是 Plugins，把这些可复用的能力打包，方便在不同项目之间使用。再配合 MCP 连接外部系统，整个 Agent 的能力边界就能够进一步扩展。 这五层不一定是每个项目都必须使用的标准架构，但它提供了一个非常值得参考的思路。 不要只把 Claude Code 当成一个写代码的工具，而应该思考，怎么围绕它建立一套真正适合自己的开发工作流。 我自己现在主要使用 Codex，虽然不同工具的具体实现不完全一样，但很多工程思想是相通的。 比如以前做一个项目，遇到问题就让 AI 修改，解决之后也没有把过程完整记录下来。下次碰到类似问题，可能又要重新研究一遍。 现在我越来越想把项目规则、技术决策、错误案例、测试方法和交付标准沉淀下来，让 Agent 在后续任务里能够复用，而不是每次都从零开始。 尤其是企业 AI 项目，真正困难的地方往往不是让 AI 把功能写出来，而是需求发生变化怎么办、修改代码会不会影响原有功能、测试有没有覆盖关键场景、交付之后出了问题能不能追溯。 这些事情靠不断输入 Prompt，很难长期解决。 当然，也没必要一上来就给所有项目配置几十个 Skills、多个 Subagents，甚至搭建一套复杂的多智能体系统。项目本身很简单的时候，过度设计只会增加成本。 但如果一个项目需要长期维护、持续迭代，或者涉及真实客户和生产环境，我觉得这套思路就很有价值了。 AI Coding 的下一步，不应该只是比较哪个模型写代码更快，而是研究怎么让 Agent 的工作过程变得可控、可复用、可验证。 以前我们关心的是，怎么让 AI 帮自己完成一个任务。 现在更值得思考的是，怎么把每一次完成任务的经验，逐渐积累成一套可以持续使用的工程体系。 这也是我接下来想在自己项目里不断实践的方向。 毕竟真正有价值的，不是今天让 Codex 帮我写了多少行代码，而是半年以后，我能不能拥有一套越来越成熟、越来越可靠的 AI 开发工作流。

曝光 494 · 评论 2 · 点赞 4 · 书签 0