augment code确实很好用，我用了一个月，说一下我的心得与使用技巧：
1.不要使用sequential thinking这个mcp工具，实测用了会导致：代码准确率下降，上下文消耗更快，agent不会自动用task list工具了。
2.规则文件请保持简洁，太长太乱的规则文件会导致agent生成的代码质量下降。可以每过一段时间就让agent帮忙整理一下规则，保持规则能反应当前项目的真实情况，而不是过时的。
3.不需要太在意在一个聊天窗口中完成所有需求，这样会导致上下文污染。每次做一个新需求时，都可以开一个新窗口。修改某个需求的bug时，请使用做这个需求时用的窗口，这样上下文信息有助于分析bug。我遇到过让改个东西始终改不好的情况，但新开一个窗口就完美解决了。所以要注意管理好上下文。
4.做大需求，改动大，涉及的文件多，业务复杂时。先使用GPT5帮助分析需求，并让它给出设计文档。文档要求它详细说明需求细节、需要阅读的文件以及上下文信息、方案等。第一次对话你要详细描述需求，让它通读项目代码或文档。并要求它跟你多次对话以确认需求细节，完全掌握所有信息后再开始写文档。要求它不要在文档里写代码，只写思路。因为GPT5的特点是全局把握好，但写代码能力不行。然后新开窗口，用claude4让它读文档以及项目代码，然后分步骤开始实施。这样做就相当于：让GPT5作架构师，claude4作程序员。各取所长。
5.在审查GPT5给的方案文档时，着重关注数据结构部分。有没有新增不必要的数据结构，这很关键。很多时候AI生成屎山代码就是因为不管现有数据结构，自己另起炉灶，导致代码难以维护。然后大致看一下方案思路，是否符合你预期即可。大多数时候不需要仔细看，就算有一些小问题，也只会导致bug。后期修复即可，不会出现代码完全不可用的情况。
6.修改bug时，最好自己人工分析一下，大致定位bug可能的位置即可。比只告诉AI bug的现象要强很多。因为代码是AI写的，它认为没问题。但你只告诉它有问题，它会不知所措到处乱改。告诉它bug的方向后，它就可以顺藤摸瓜，更容易解决bug。
7.把开发过程中AI反复犯错的地方，记录到记忆文档里。
8.记得把设置里的音效打开。这样对话完成后会有提示音，期间你只需要戴上耳机刷B站就好了。完成了会通知你，你再去测试看代码即可。娱乐工作两不误。
9.项目中请增加单元测试框架，例如jest等。并且在规则里要求AI增加新功能都需要写单测。这样可以杜绝很多bug，进一步提升代码准确率。但记得维护测试用例。因为AI经常不听话，改了代码不改测试用例，导致用例大面积不通过。
问题以及回复：
问：
关于第四点：让GPT5作架构师，claude4作程序员。
1.请问这个操作是直接在augment里面进行模型切换即可吗，也就是在适当的时机（如你提到的开发需求的前期准备阶段/实际代码运行阶段）切换使用augment适当的模型，已完成最好的开发体验？
2.还是需要开第三方ai进行审查？
回复：
直接在augment里面切换。前期准备阶段切GPT5，跟它聊需求。只让它给出详细需求说明、需要阅读的代码或文件、实现方案设计。千万不要让它给具体代码以及实施计划。因为给了代码，claude4会用这些代码，而不会自己去写。当GPT5给的代码有问题，它就很凌乱。让GPT5列出需要阅读的代码以及文档，是因为GPT5的全局把控能力更强，也更听话。给出这些可以为claude4写代码时查漏补缺，防止出现该阅读的关键上下文信息遗漏，导致产出的代码不符合预期。人需要做的就是把关，对它的方案进行把关。着重从数据结构设计把关，因为数据结构对了，代码不会差到哪里去。实施之前，你也可以让claude4再过一遍设计文档，调整文档的问题，对于不明确的地方跟你沟通，此时可以让它补充一些关键代码，你也可以审查这些代码。并增加实施计划，然后按计划开始实施。基本上不会有什么大问题。完成后你自己测试一下，测试没问题了就审查一下代码。把代码不合理的地方挑出来，让它优化。反正就是开发需求、测试、改bug、优化，然后再开发需求。这样无限循环。注意需求不能过于大，如果实现这个需求的代码量超过五千行，你就要反思是不是需求拆分不合理。一般两千行以内最佳。优化过程就是产除屎山代码的过程。如果不优化，做几个需求之后，你就很难再加新功能了。因为ai喜欢另起炉灶，明明可以利用现有代码，简单实现。ai就感觉无视这些代码一样，自己重新写。或者某些设计不合理，它加功能时不会想着重构一下再加，而是直接在之前的函数或者组件中堆砌代码，导致超大函数或者组件或者超长文件出现。在ai生成代码之后，你可以根据代码量判断是否靠谱。例如，这个需求你预计一千行代码就可以完成，但它给你生成了五千行代码。这是好你应该果断拒绝这些代码，这会导致后期优化工作繁重。你要有修改提示词，多次尝试的心理准备。直到生成了你最满意的代码，这样后期优化就很快。写提示词的时候，尽量避免“你不应该xxx”这种描述，老外的模型对这种句式理解很不好。要改成命令式，例如，“xxx接口要xxx方式返回数据”。把你了解的上下文信息列出来，例如“上下文信息如下：1.xxx接口调用了xxx函数。2.你可以用xxx数据判断用户登陆。”这样不容易让ai产生误解。augment提供的提示词美化功能很有用，但也不要过于依赖，有时候生成的并不好，不如自己写。
问：
哥，我对你对augment的心得体会里面有一点不太明白，基于一个全新的项目，我在前期给他做文档的时候，你提到：”考虑各需求所需上下文，即需要阅读的代码或文档”——这句话如何进行理解？
我的疑惑：
因为项目开始初期应该没有什么代码或者文件，我认为是实时的将项目推进到某个程度，或者在已有项目之上，我想要在额外的进行二次开发新功能的时候，才会涉及到需要让ai读取原有的项目结构或者上下文，做出足够的了解，再进行实际开发？
因此，对从零起步的新项目，我正在和ai进行需求文档以及技术架构文档问答环节的时候，如何去理解：“考虑各需求所需上下文，即需要阅读的代码或文档”？
回：
从零开始的项目，前期可以粗旷式的开发。想到什么功能要做，就跟ai说。用我这一套思路没问题，反而更简单。因为不需要考虑老代码，新代码写起来很自由。前期你要求ai写的每一个功能，能实现就行了。当你项目代码量有一定规模了，就需要考虑开始优化了。我说的这些上下文、文档啥的都是针对给大项目加新功能。项目中要多写一些文档，每个模块都可以让ai写一个Readme文档。这样ai在扩展该模块的时候可以要求它先读文档，按照该模块设计架构去设计新代码。不然ai就会乱写，把你架构好的模块打乱。总之，前期可以随意一些，不用太在意代码可维护性。等到了有一定代码量了，就可以着手开始优化了。整个过程中，人起主导作用。
我所说的考虑上下文的意思是：要求GPT5 通读项目代码，然后再理解你的需求并制定最佳实现方案。期间你可能需要跟GPT5多轮对话以确认需求或者设计细节。最终把这些整理成文档，要明确要求在文档里写明需要阅读的关键代码或文档。这样文档里就会有类似“阅读xxx文件，以获取xxx信息”的记录。然后切换到claude4 让它读文档并制定实施计划。这样就相当于让GPT5指导claude4大致怎么做，需要读哪些关键文件都在文档里，claude4就对项目把握更全面了。这样再写代码准确率更高。相当于是利用了GPT5思考全面、稳重的特点，又利用了claude4写代码能力强的特点。把两者结合起来，各取所长。
说人话就是：让GPT5做上下文压缩，总结。让claude4根据这些总结压缩后的信息写代码。
任何项目都不可能通过几次对话就可以完成。当你对话几次之后，获得了一些代码。此时你再增加新功能就要考虑上下文管理了。特别是代码量大的项目，ai无法所有文件都读一遍。你可以通过排除不想干代码、多写文档、利用上下文大的模型做需求设计 等手段来压缩上下文长度，且不降低效果。例如：你知道做某个需求需要先读a文件，不需要读b文件。你就告诉ai。某个模块b有几十个文件，这次需求需要扩展b模块。那么ai最好能读这几十个文件，完全理解了再扩展会更准确。但你也可以先让ai只读这个模块的文件，并且输出一个该模块的说明文档。然后做需求时直接跟它说：如果要扩展b模块，你就读一下这个说明文档。这样就起到了压缩效果，类似于人的总结能力。最后就是利用GPT5做设计文档，相当于把很多需要在代码中提取的信息，事先提取了一遍并输出为文档。claude4写代码时，就不需要阅读这么多上下文信息了，一篇设计文档顶一大堆代码。这也是上下文压缩技巧。你理解了如何压缩上下文信息，如何提炼准确的上下文信息。就理解了如何更好的利用ai来写代码。ai无非就是你给它一些提示词以提供一些上下文信息，它根据你提供信息生成代码。代码质量取决于你提供信息的质量。信息量越大，信息越准确，提供这些信息所需的文字越少。ai输出的结果质量就越高。
