六个月的疯狂编程，30万行代码！一名程序员每月

六个月的真实项目实践，重写30万行代码……听起来像是天方夜谭，但事实上，这是一个开发者jokinggold5455的亲身经历。他单枪匹马地承担了一个复杂的微服务项目的转型。为了让老板同意，他当场拍着胸口承诺六个月内完成。后来他又转身把克劳德·科德培养成得力助手，帮助他管理和重写。在此之前，他每个月花费200美元（约合人民币1422元）开通Max 20x套餐，将原来约10万线的项目重建到30万到40万线的规模。要知道，人工智能运用得当，效率可以成倍提高；如果使用不当，加班时间只会增加。为了彻底挖掘Claude Code的潜力，JokeGold5455做了很多调优，让AI输出更加准确、好用。基于这些实践经验，他整理了一份完整的GitHub参考资料brary（https://github.com/diet103/claude-code-infrastruct-showcase），希望能给您优化 AI 编程环境和工作流程的实用启发。来源：https://www.reddit.com/r/claudeai/comments/1oivjvm/claude_code_is_a_beast_tips_from_6_months_of/author | Jokegold5455 编辑 |我们做到了Csdn（id：csdnnews） 一点背景知识：我是一名软件工程师，过去七年一直在生产环境中开发 Web 应用程序。当AI浪潮袭来时，我几乎张开双臂拥抱它。与很多人的焦虑相比，我并不担心人工智能会取代我的工作——相反，我会用它作为提高我技能的工具。有了这个，我可以更快地开发新功能，创建演示解决方案，并将 Claude 思维和 GPT-5 等模型集成到我们的产品应用程序中。过去我没有时间去思考这些项目的优化工作。今天，它们成了我“保住工作”的秘诀，让我我是公司的“人工智能顾问”——我觉得其他同事在日常工作中应用人工智能的深度可能比我晚了近一年。带着这种信心，我提议对我们公司内部使用的 Web 应用程序进行大规模重构/改造。本来这个Web应用程序是一个大学生在实习期间写的，是从我7年前实习期间开发的另一个项目中fork出来的，所以不难想象这个应用程序的质量有多么粗糙。然而为了让公司老板买账，我拍着胸脯答应在几个月内完成整个项目（大约10万行代码）的重新设计和重构。我当时就知道这意味着加班，即使有了克劳德法则的帮助，事情也不会变得更容易。但我很清楚，如果这个项目成功，将会使大量的手动流程实现自动化，并为公司节省大量时间。现在，斯x个月后...是的，我现在觉得我给自己设定的时间安排真的很激进。为了完成这个项目，过去我不仅把Claude Code的能力推到了极限，也几乎把自己的理智推到了崩溃的边缘。在这次尝试中，我彻底放弃了旧的门面，一方面是因为它太落伍了，另一方面是因为我想借此机会体验一些新的技术栈。以下是我改造的 Web 应用中使用的新旧技术栈的对比： React 16 JS → React 19 Typescript React Query V2 → TanStack Query V5 React Router V4 (Hashrouter) → Tanstack Router (File Route) Material UI V4 → MUI V7 所有真正严格遵守最佳实践的技术迭代。现在该项目已经发展到大约 30 万-40 万行代码，毫不夸张地说“我可能因此失去了五年的生命”。但结果真的很棒——这个项目终于进入测试阶段了，成品我很满意。这个项目本来技术债务如山，测试覆盖率为零，开发体验很糟糕（调试就是地狱），各种奇奇怪怪的问题一一冒出来。今天，我给它添加了一个很大的测试范围，控制了技术债务，编写了一个命令行工具来生成测试数据，并在各个功能前面添加了“开发模式”以方便测试。在这个过程中，我逐渐理解了克劳德代码的行为，以及在不同情况下我可以从它中榨取多少“生产力”。在使用 claude 代码六个月、仅重写 30 万行代码的过程中，我构建了一个这样的系统： 技能系统：开发文档可以在工作流程需要时自动激活：不留任何错误”一个 AI 团队：专门的代码审查、测试和规划 在这篇文章中，我想谈谈我的一些实践经验唱克劳德代码，以及我在学习中的爆发如果充分谈谈我在克劳德代码中的一些实践经验，以及我在工作中的探索如果充分谈谈我在克劳德代码中的一些实践经验。基础设施——包括自动激活技能、钩子、代理等组件。先说明一下：本文所有内容都是我目前感觉最方便有效的配置。这并不意味着它是唯一正确的方法。希望这些经验可以为您在编程 AI 代理时提供一些见解。受到启发。我不是专家，只是分享我的想法和经验，仅供参考。 值得一提的是，我使用的是 Claude Codemax 20X 套餐（200 美元/月，约 1422 元/月），所以你的体验可能会有所不同。如果您只是寻找一种“轻松、随意地编写代码”的氛围，那么本文可能不适合您。但如果你想真正重新要认识到克劳德代码的潜力，您需要与它“合作”：一起计划、分析、热身并探索不同的解决方案。 关于质量和一致性的说明。在论坛和各种讨论区，我经常看到相同的话题：人们抱怨克劳德代码的使用次数限制太苛刻，或者认为这个模型的输出质量“用得越多就越差”。我想首先澄清这一点 - 我并不是试图否认这些经历，我也不是说“你只是错误地使用了它们”。每个人的情况和需求都不同，这个反馈值得认真对待。不过，我想分享我的故事。个人感觉，最近两个月claude代码的输出质量有了很大的提高。我想这主要得益于我对工作流程的不断调整和优化。如果你能从我的系统中获得一点灵感，并将类似的想法融入到你自己的方式中和克劳德一起工作，也许你也可以做得更一致、更快乐。当然，我们要明确一点——克劳德翻转了。有时，它只是没有抓住要点，并且生成的代码的质量很难描述。原因有很多。首先，人工智能模型是随机的，相同的输入可能会导致完全不同的输出。有时它是“糟糕的查帕拉兰”，模型给出的结果确实令人不满意。其次，直接词语的表达方式也很关键。即使只改变几个单词，输出也可能完全不同。克劳德对这门语言的描述非常直白，如果你写得含糊其词或含糊不清，它很容易“偏离轨道”。有时你必须把事情掌握在自己手中。人工智能很强大，但它不是魔法。总有一些问题是人类的直觉和模式识别更胜一筹的。如果你看到克劳德在两分钟内与虫子搏斗，这没什么好羞耻的。把它想象成催促某人骑自行车——有时当你情绪稳定时你必须帮忙，这种情况更常见，尤其是在涉及逻辑推理和实际常识的问题上。当然，克劳德可以用“蛮力”来提供答案，但人们往往会更快地看到问题的本质。不要陷入“人工智能应该自动完成所有事情”的热潮，这只会浪费你的时间。如有必要，果断采取行动，解决问题，然后继续前进。我个人经历过很多次“灾难提示”——通常是在一天结束的时候，我懒得写提示，输出结果自然很糟糕。所以如果你感觉 Claude 的输出质量最近有所下降，他怀疑 anthropic 暗中“削弱”了模型。他也可以静下心来想想自己最近的留言写得有多好。尝试多次。妈妈可以按两下ESC键调出历史提示，选择一项重新分支。您会惊讶地发现使用该方法经常会获得更好的结果一旦你了解自己不喜欢什么，就会得到同样的提示。简而言之，导致输出质量下降的原因可能有很多 - 进行一些调查并思考是否可以提供更好的背景和指导通常比仅仅抱怨更有效。正如一位智者曾经说过的：“不要问克劳德能为你做什么，而要问你能为克劳德提供什么背景。” - 一个聪明人。好了，布道时间结束了，现在是真正的内容了。 我的系统 在过去的六个月中，我对 Claude Code 的整个工作流程进行了许多调整。非常轻的效果——至少我这么认为。 1. 自动激活系统技能（真正的游戏规则改变者！） 这一部分应该独立存在，因为它完全改变了我使用 Claude Code 的方式。简单来说，可以翻译为“技能自动激活系统”。问题出现后不久，当Anthropic推出技能时（https://www.anthropic.com/news/skills），我的第一反应是：“这太棒了！” Anthropi 的功能c技能可以理解为一个允许Claude自动调用特定“技能模块”的系统：每个技能都包含一组可用的任务指令、脚本或资源。当克劳德遇到相关任务时，它可以自动识别并触发相应的技能。要完成工作，请启用自动、模块化和可扩展的任务处理，而无需用户每次都手动定义操作。 此功能使 Claude 能够引用可移植、可重用的指令集，该指令集可用于在大型代码库中保持一致性 - 这是理想的。于是我花了很多时间和Claude一起写了一套完整的详细实践配置，包括前端开发、后端开发、数据库操作、工作流管理等模块，涵盖了数千行最佳实践、设计模式和示例代码。然后……什么也没发生。克劳德并没有自动给他们打电话。我还写了技能说明关于提示中的关键字——最终，仍然没有任何反应。我打开应该触发 kas featureananay 的文件 - 仍然没有。这种情况真是令人悲哀：我可以清楚地看到这个功能的潜力，但是这些技能就像小摆设一样，坐在那里一动不动，就像装饰品一样。 “啊哈！”那一刻我想是时候使用钩子了。如果克劳德不会自动使用技能，为什么不建立一个系统，在执行任何操作之前检查相关技能是否可用？于是我开始学习Claude Code钩子系统，并使用Typescript构建了多级自动激活架构。这是真的——它有效！它是如何工作的 我创建了两个主要钩子： 1. UserPromptSubMit 钩子（在 Claude 看到您的消息之前运行） 检查输入提示单词，提取关键字和意图模式；检查哪些技能可能相关； Claude 上下文中的 Iction 格式的提醒。例如，如果我输入：“布局系统如何工作？”克劳德首先看到了一条提示：“技能激活检查-使用project-catalog-developer技能”，知道在读题之前要加载技能“Project-Catalog-Developer”（这是我前端中一个大而复杂的数据网格组件模块）。 2.停止事件钩子（在Claude的响应完成后运行）检查哪些文件发生了变化；分析高风险模式（try-catch、数据库操作、异步函数等）；输出温和的自检提醒，例如：“有错误”添加了处理？棱镜操作是否遵循存储模式？”这不是强制提示，但它可以让克劳德保持一种“自省”的感觉，不会太得意忘形。基于此配置Skill-rules.json，我还创建了一个中心配置文件来定义每个技能的逻辑触发，包括：关键字：清晰的主题匹配（如“布局”、“工作流程”、“数据库”）；意图模式：使用正则表达式捕获动作意图（如“（创建|添加）。*？（功能|路线）”）；th触发器：根据文件路径中编辑的技能激活；内容触发器：检测文件内容中的特定模式（如棱镜导入、控制器定义等）。示例片段：} 显示效果 现在，当我生成后端代码时，Claude 会自动完成以下步骤： 在阅读提示之前加载技能建议；致电相关导游；按既定模式维持 维持恒定输出；粘上一个钩子，温柔地提醒你在最后检查一下自己。结果是一个巨大的变化：不再有样式不一致的代码，不再抱怨“Claude 正在重用旧模式”，也不需要每次都手动提醒它“检查该指南”。 运行自动激活系统后遵循Anthropic官方的最佳实践（经验教训），我仔细研究了Anthropic官方的Best Practices文档。事实证明我之前用的方法是错误的。官方建议是每个核心的做法。md file 应限制为 500 行，并通过“渐进式加载”引用外部资源文件。我当时的情况是前端开发指南超过 1,500 行；还有很多技能也超过了1000行。这些大型“技能巨石”文件完全违背了技能系统“按需加载”的目的。所以我重新安排了整个结构：Frontend-Dev-Guidelines → 主文件 398 行 + 10 资源文件 backend-devidelines → 主文件 304 行 + 11 资源文件。现在，克劳德可以先加载轻量级的核心文件，只有在绝对必要时才加载详细的资源文件。结果：Token使用效率提升40-60%，大部分请求的响应速度和稳定性也显着提升。我创建的技能列表是我当前的技能阵容：指南和最佳实践 backend-dev-guidelines-routes → controllers → services → repositories frontend-dev-guidelines-patterns 和基于 React 19、Mui V 的实践7、Tanstack查询/技能路线-Developer-元技能（元技能）专门用于创建其他元技能发布技能中的专门技能）工作流引擎模式通知-开发人员-电子邮件和通知系统开发数据库-验证-防止列表错误（此技能具有“保护性”，在检测到问题时防止更改！） Project-Catalog-Developer-DataGrid布局系统这些技能会根据我编辑的文件或任务自动激活。这就好像有一个经验丰富、记忆力很长的高级工程师在克劳德的身上工作一样，总是在背后提醒它：“嘿，用这个模式。”为什么在使用技能+钩子之前很重要：即使我在文档中更新了新的设计模式，Claude仍然会使用旧的模式；我每次都要手动提醒它阅读best_practices.md；超过30万行的代码库充满了不一致的风格；组织克劳德的“自由发挥”花费了太多的时间。使用滑雪板后lls + hook：自动应用和检查统一模式；在我看到代码之前，克劳德正在纠正自己；我可以确保代码风格遵循既定的准则；审查和纠正时间大大减少。如果您还维护一个大型的、定义良好的代码库，我推荐这个系统。刚开始搭建需要两三天的时间，但回报至少是十倍。 Claude.md 和文档系统的演变我在六个月前发布的帖子中提到了一个观点：“规则是你最好的朋友”，并且遵循 p 我也是在这一点上。但我的 claude.md 文件失控了 - 它占用了太多函数，包括 1400 多行 best_practices.md 文件，Claude 有时会读取该文件，有时会忽略该文件。于是，我花了一个下午的时间，和Claude一起重新整理整合了整个文档系统。调整后的结构如下： 移至原来的Best_Practices of Skills 包含： Coding Definitions Coding；反应模式（钩s，实质内容，悬念）；后端 API 模式（路由、控制器、服务）；错误处理（哨兵集成）；数据库设计和棱镜使用规范；测试指南；性能优化技术。现在所有这些内容都已迁移到技能系统中，并且钩子会自动激活，以确保克劳德可以使用它们。不再祈祷“记住阅读该文件”。 claude.md 中保留的内容当前的 claude.md 仅关注项目特定信息（~ 200 行）：常用命令（PNPM PM2：Start、PNPM build 等）；服务特定配置项；任务管理系统和文档开发；路线验证的测试程序；工作流程的试运行模式；浏览器配置工具。新的文档结构： └── repo 的具体怪癖和命令的本质是：Skills 负责“如何编写代码”，Claude.md 负责“这个项目如何工作”。关注点分离确实是一个问题伊维德。 所有改进（除了技能（外部））进度的文档系统，这个系统带来了最大的好处。Claude 就像一个“自信但完全健忘”的初级工程师，总是容易忘记自己在做什么。这个系统就是专门为了解决这个问题而设计的。来自 Claude.MD 的 Dev Docs Snippet： - 更新“最后更新”时间戳 这些文档每当开发新功能或主要任务时都会自动生成。在此之前，我经常遇到 Claude “走神”的情况在开发过程中，他在开发过程中发现了“轨迹”，而他30分钟前制定的计划被完全忘记了，因为它被一些随机的想法夺走了。我的计划过程都是从计划开始的。计划是核心。如果你在要求克劳德实现一个功能之前不进入计划模式，你可能会遇到麻烦。就像建筑工人没有权利kta不会开始建造建筑物，而是先画线。当我开始计划一个功能时功能，我首先进入计划模式，尽管我要求 Claude 将计划写在 Markdown 文件中。我不确定这一步是否真的有必要，但在我看来，进入计划模式可以让 Claude 更好地探索代码库，获得正确的上下文，并提出更完整的计划。我创建了一个子代理，即战略计划架构师，它是一个计划怪物：擅长收集背景信息；分析项目结构；制定完整的计划，包括执行摘要、分阶段、任务、风险评估、成功指标和时间表；自动生成三个文件：计划、上下文和任务列表。但我发现有两件事很烦人：1.你看不到子代理的输出；2.你看不到子代理的输出。 2.如果tang拒绝其提案，则代理将直接被销毁，讨论无法继续。因此，我使用主克劳德代码示例中的相同提示创建了自己的自定义 /dev-docs 命令，以实现相同的功能。当克劳德输出那个好计划时，我花了有时间仔细回顾一下。这一步非常重要。检查一下，您会惊讶地发现它经常犯一些愚蠢的错误或完全误解请求中的关键点。通常，退出规划模式后，我只剩下不到 15% 的上下文，但这没关系 - 然后通过将所有必要的信息存入开发文档系统来“重置上下文”。 Claude 经常渴望直接开始写作，所以我立即按 ESC 中断它并运行 /dev-docs 命令。此命令将使用批准的计划自动创建三个文档，并在上下文足够的情况下填补空白。完成后，我几乎完全放心地让 CLA UDE 执行整个功能，永远不会失去焦点，永远不会忘记计划，即使在自动压缩后也能保持正确的方向。我偶尔会提醒克劳德更新任务列表和上下文文件。当当前没有足够的上下文时会话中，只需运行 /Update-Dev-Docs 命令，Claude 将记录所有相关上下文、后续步骤，并在压缩之前更新任务状态。在新的对话中只需一句话：“继续”，连接就会无缝。在实施过程中，我会要求Claude根据任务的大小单独实施一两个部分。这样，我可以及时检查中间结果，避免传播错误。我还有一个子代理负责定期进行代码审查，以便及早发现潜在的大问题。如果您还没有让 Claude 检查您的代码，我强烈建议您尝试一下 - 它为我节省了很多麻烦，并发现了严重的错误、缺少实现、不一致的逻辑，甚至一些安全漏洞。 PM2 流程管理（后端调试的终极工具） 这是我最近添加的链接，但它将后端调试体验提升到了一个全新的水平。问题是我的项目运行了七个后端d 同时微服务。问题是 - 当服务运行时，Claude 无法查看 dir logekta。也就是说，我不直接问这个：“邮件服务出现错误，发生了什么？”因为克劳德本身无法读取日志，除非我手动将其复制并粘贴到对话中。一段时间的临时解决方案，我让每个服务通过 Devlog 脚本将输出写入带时间戳的日志文件。它有效，但很笨拙。克劳德可以读取日志文件，但无法实时更新。该服务崩溃后不会自动重启，管理起来非常困难。真正的解决方案：PM2 直到我发现 PM2 - 一个彻底的游戏规则改变者。我用一个命令让所有后端服务通过 PM2 运行： PNPM PM2：启动 它的好处包括： 每个服务作为独立的托管进程运行，并且可以拥有自己的日志文件 claude 可以实时读取各个服务的日志 在服务崩溃后使用 PM2 日志实时输出监控自动重新启动使用 PM2 monit 监控内存和 CPU 使用简单易用的服务管理命令（如 PM2 重新启动 PM2 或 PM2 Stop 以及易于配置的示例：}; 前后对比配置过程 -debug。 现在： Claude: “服务重新启动，仍然有错误。现在 Claude 可以自己完成调试。唯一的缺点是 PM2 不支持热重载。但是，对于那些不需要频繁热重载的后端服务， PM2 是完美的。 Hooks System (Left Untangled) 我的项目有一个多根结构。根目录中有八个不同的存储库——一个前端、七个后端微服务和工具服务。我经常在多个存储库之间来回切换开发。最让我困扰的是 Claude 经常忘记在编辑文件后运行构建命令。因此，代码中会留下十几个类型错误，当我要求它在几个小时后构建时，它不会说：“有一些类型错误或者，但它们并不重要，所以没问题！”不，克劳德，我们现在有麻烦了。挂钩：文件编辑跟踪器首先，我创建了一个工具使用后挂钩，在每次编辑/写入/多重编辑操作后运行。记录它：哪个 mga 文件被编辑，这些文件的哪个存储库首先属于时间戳我在每次编辑后立即运行它，但不是很有效。克劳德通常先修复损坏的东西，然后立即修复它。挂钩：构建检查器（构建检查器）因此我添加了一个停止钩子（在 Claude 的响应之后运行），其中： 读取编辑日志并找出更改的存储库 运行构建脚本以检查每个受影响的存储库的 TypeScript 错误 如果有 5 个错误：直接向 Claude 显示 如果有 ≥ 5 个错误：建议启动自动错误解析器代理来记录日志以进行调试。通过启用此系统，Claude 不再有任何错误。克劳德将在继续之前修复它：更漂亮的格式化程序很简单，但是。易于使用。 Claude 回应后，他自动运行 better，用每个 repo 的 .PRETTIERRC 配置来格式化所有编辑过的文件。不再需要手动打开文件来运行格式，也不再需要看到二十个尾随逗号的更好更改，因为克劳德上次忘记添加它们。不过，我不再推荐这个钩子了。自从我分享这篇文章后，就有读者留言提供详细数据——更改文件将立即触发并消耗许多上下文令牌。仅仅因为自动格式化，他们就在 3 次对话中消耗了 160,000 个令牌。此效果将根据项目的大小和格式规则而有所不同。但我最终还是去掉了这个钩子——格式化可以手动完成，不需要牺牲令牌来替换，有点方便。要保持自动格式化，您可以在会话之间手动运行它，而不是克劳德会话。 Hook：错误处理错误 这是我前面提到的“友情提醒”Hook。它将分析在 Claude 响应后，编辑文件以识别风险模式（try-catch、异步操作、数据库调用、控制器等）。如果检测到危险代码，会显示自检提示。克劳德会自己判断是否需要添加处理错误，而不是强迫或中断，并且会保持对风险的认识。输出示例： 每次克劳德回复时完成钩子过程，他都会经历以下过程： 最终结果：干净、格式均匀、无错误的代码。另外，在Claude开始工作之前，自动UserPromptSubmit Hook会加载相关技能。结果：没有混乱。完美的。 附加到技能的脚本我从 Anthropic 官方 github 上的实践示例中学到了一个很酷的模式：将实用脚本附加到技能。例如，我的后端开发指南实践中有一个关于测试验证路线的部分。实践中不仅解释了认证过程，还引用了一个实际的脚本：nodescripts/test-auth-route.js http://localhost:3002/api/endpoint 这将处理每个人确切知道要使用哪个脚本以及如何使用它。不再需要每次都“让我写一个测试脚本”，重新发明轮子。我计划将这种模式扩展到更多技能，并让 Claude 直接使用现成的这些ol，而不是每次都从头开始构建。 工具和其他帮助 SuperWhisper (MAC) 当你的手累的时候，你可以使用文本到文本的输入，克劳德很好地理解了我的语音输入。内存 MCP 我现在很少使用它，因为技能功能处理了大部分“内存模式”工作。但它仍然适合跟踪不属于实践的特定于项目的决策和架构选择。 BetterTouchTool 从光标复制相对 URL（用于共享代码引用） 我将打开 VSCODE，以便更轻松地找到我需要的文件。我可以双击大写锁定，BTT 将输入快捷键复制相对 url，同时使用 @Simbolo 准备剪贴板内容，然后 f打开终端并粘贴文件路径 - 全部通过双击热键快速切换应用程序（CMD+CMD 打开 Claude Code，OPT+Opt 打开浏览器）并设置常用操作的自定义操作。说实话，不用在不同的应用程序之间来回切换，可以节省大量时间，这足以让购买 BTT 变得值得。脚本涵盖了一切。几乎任何繁琐的任务都可以通过脚本来解决，例如用于生成模拟测试数据的命令行工具。在使用 Claude Code 之前，生成这些数据很烦人 - 我必须向包含大约 120 个问题的表单提交一次答案，只是为了生成测试用例。验证测试脚本（获取token、测试路由）数据库重置和schema填充迁移前数据差异检查提示开发数据库自动备份和恢复：当Claude帮你写出有用的脚本时，立即记录在Claude.MD中或附加到相关技能中。未来你会感谢你的现在是小精灵。文档（仍然重要，但发生了变化）我认为文档几乎与计划一样重要。我实时记录开发过程，包括为每个任务或功能生成的开发文档。从系统架构、数据流图到开发者文档、API文档，一应俱全。但变化是这样的：文档现在与实践一起工作，而不是取代它们。技能：可用模式、最佳实践、操作方法文档：系统架构、数据流、API 参考文档（850 多个 markdown 文件），但现在专注于架构 tcry 项目，而不是重复实践中常见的最佳实践。当然你不必走极端，我建议你设置多层次的文档：广泛的架构概述指向更具体的子文档（不同的模块、服务或功能细节），以便 Claude 可以更好地导航你的代码库。使用提示的技巧 编写提示时，尝试尽可能具体和清晰地说明所需的结果。就像你不会让建筑商在没有先查阅蓝图的情况下就开始建造新浴室一样。如果你不确定细节，也没关系：把研究留给 Claude，有多种选择，或者使用子代理/其他 AI 接口来进行研究，这样你就可以根据 ClaudeAt 的修复计划判断好坏，否则只是盲目输入“vibe-coding”，你甚至可能不知道要包含哪些文件的上下文。另外，避免引导性问题以获得客观反馈：不要问“这好吗？”更好：描述情况并询问“有什么想法或选择吗？”这会给你一个更平衡的答案。代理、Hook 和 Slash 命令（三位一体） 代理 我创建了一个由专业代理组成的小团队： 质量控制：代码架构审阅者：检查代码是否遵循最佳实践 构建错误解析器：TypeScript 错误的系统修复 重构规划器：基因评价全面的重构计划 测试和调试： auth-route-tester：使用身份验证测试后端路由 auth-route-debugger：调试 401/403 错误 Frontend-Error-Fixer：诊断和修复前端错误 规划和策略：战略计划架构师：制定详细计划 计划审查者：实施前审查计划 文档架构师：创建/更新文档 特色功能：前端-Ux-Designer：维护和更新UX 发布 Web-Reskare UI 使用代理的指南要点：澄清角色并恢复内容。避免代理“去做他们想做的事”，然后只是告诉你“我修好了！”钩子（上面介绍过） 钩子系统是整个系统的粘合剂：没有钩子→技能闲置、错误滑倒、代码格式不一致、没有自动质量检查钩子→技能自动激活、零错误保留计划 /dev-docs-update：压缩前更新开发文档 /create-dev-docs：将批准的计划转换为开发文档文档并审核 /code-review：代码架构 /searchof 受影响的路由并开始测试 /test-route：测试特定的身份验证路由 Slash 命令的美妙之处在于： 可扩展到整个提示符 将多个上下文和指令压缩为单个命令，比每次手动输入指令更方便 结论 经过六个月的密集使用，我总结了一些观点： 必须具备的要素： 计划 斜线命令 重复过程 全面的文档记录 实用脚本 附加 MCP 记忆技巧 对记录决策有用，这就是我现在能想到的全部了。正如我一开始所说的，我只是一名普通的开发人员，我准备倾听大家的经验、技能，甚至批评和指正——因为我总是想不断优化我的工作流程。我写这封信是为了分享这只是为了告诉别人什么对我有用，因为在现实生活中我很难找到合适的人来交谈（我的团队很小，每个人都是sl）如何采用人工智能）。 特别声明：本文由网易自媒体平台“网易号”作者上传发布，仅代表作者观点。网易仅提供信息发布平台。 注：以上内容（包括图片和视频，如有）由网易HAO用户上传发布，网易HAO为社交媒体平台，仅提供信息存储服务。