毫无疑问，Marscode 能解决非常多基础问题，特别对于编程新手而言，它能相对准确地生成各种代码，完成编程任务，但其底层并不神秘，本质上就是在传统 IDE 基础上，搭配足够好的交互与足够好的 LLM，从而超越传统 IDE。交互方面，它在 VS Code 基础上，补充提供了：
- 提供了几乎毫无门槛的代码自动补全能力，并且支持多行编辑，这在一些场景，如修改变量名时，非常好用；
- 行内、独立问答面板，可用于快速解答问题；
在此基础上，配合豆包模型，算得上是国内最好的编程辅助工具了。但工具再好，错误的用法下生成效果很可能不能达到预期，因此，这里根据我个人的使用经验，汇总一些最佳实践技巧。
1. 频繁提交代码
切记，LLM 始终是随机的，无法保证下次执行结果的正确性，在使用过程务必养成习惯频繁提交代码，方便出现问题时随时回滚。我个人的操作习惯大致是：
- 使用 Marscode 各类面板生成代码后，先做一遍简单的代码 Review，修改变量名、循环结构等基础问题；
- 在软件上下文中集成调试，初步验证正确性后立即提交代码；
- 审阅代码设计，重点关注：函数输入输出结构、模块导入导出内容、逻辑与循环分支处理等等，在这个节点通常会持续让 LLM 按我的想法优化代码，或者自己上手做些小修改，迭代多次持续提交代码，这个过程通常耗时最多；
- 代码初步稳定后，继续让 LLM 帮我生成单测代码，这个阶段通常需要迭代多次，提交多次，直至单测通过，覆盖率达标为止；
- 功能代码、测试代码均准备就绪后，提交 PR 准备合码；
这个过程中，每次调用 LLM 都可能得到不符合预期的结果，但只要基本达标我都会立即 Commit，后续遇到问题随时 Revert 即可，虽然这会产生大量 Commit History ，但合码前使用 Rebase 等操作调整历史记录即可。
2. 重视 Code Review
其次，建议将更多时间精力放在 Code Review 上，因为 Marscode 生成的代码可能是局部最优，但可能因为缺失相对抽象的全局架构信息，而并不能做到全局最优，例如重复编写组件，或破坏某些约定俗成的架构规则等，日积月累同类代码可能最终导致可维护性、可读性都逐步劣化到无法继续迭代的程度(公正点说，人类智能也会导致这类问题)。
因此非常建议重视建立严谨的 Code Review 文化，理想情况应该是由 Marscode 生成尽可能多的代码，尽可能代替人类完成编码工作，再由人类智能负责验证、审查这些代码的合理性，保证结果正确且长期可维护。
3. 更好的工程化体系
如前所述，Marscode，或者说 LLM 生成的结果是随机的，无法保证每次都得到正确的结果，每次变更都有可能影响存量代码的稳定性，如果这些变更都必须由人类手动验证，那么测试成本会搞起不下，测试环节会成为工程中新的效率卡点。
更好的方式，应该是投入更多精力建设更稳健的工程化体系(这部分需求也可由 Marscode 辅助实现)，使用自动化工具代替人力完成诸多基础质检任务，例如引入 UT/E2E 完成运行质量测试，CI/CD 中加入 TS 类型检查、ESLint 风格检查等保证代码质量，等等。重点在于，使用更高效、成本更低的方式不断验证 AI 产物质量，更敏捷地应对变化，具体策略可参考我之前的文章：
此处不再赘述。
4. 使用 AI 友好的技术栈
在使用 Marscode 或其他同类辅助编程工具时，应尽可能选用各类 AI 友好的技术栈，以前端为例，如：Tailwind 优于原生 CSS/Less 等；Typescript 优于 JavaScript、CoffeeScript 等；React 或 Vue 等 MVVM 框架优于原生 JS + HTML + CSS；GraphQL 优于 Restful 等。
为什么技术栈之间会出现这种差异呢？关键在于 LLM 底层是基于概率推导实现内容生成的，结果好坏取决于模型质量、训练语料、上下文完整度、Prompt 等诸多因素，单就辅助生产代码这一任务而言，LLM 对技术栈的理解越充分必然效果越好；代码结构越聚焦，推导时信息噪音越低，结果也会越好；业务实现中的特化场景越少，通用规则越多，LLM 需要理解的内容越少，效果通常也会越好；等等。
基于这些维度，我个人总结了几类简单规则可用于辅助评估某种技术栈是否更适用于 AIGC 场景，包括：
- 社区热度：社区越繁荣，意味着使用者越多，相关的技术讨论、技术资料也必然越丰富，LLM 训练或执行时所能索引的信息就越完整，那么也就越容易推导出较好的结果。举个例子，假设你工作中遇到了某个非常具体而棘手的问题，若刚好有人也遇到过，并将该问题形成的底层原因、解决方案整理成文章并发布到互联网上，若 LLM 运行时能检索到该文章，则可以基于文章内容推导给出最终解决方案；若网络上没有这类信息，考虑到 LLM 并不具备复杂逻辑推理能力，那么大概率无法给出有效的解决方案。
- 结构化：技术栈本身的结构化、模块化水平越强，则其信息表现形式越是聚焦，越容易被 LLM 正确推导。比如，原子 CSS(如 Tailwind) 就是一个很好的例子，原生 CSS 是通过具体的属性的键值对表达页面元素的视觉效果，而原子化 CSS 则是通过原子类名表达某类样式规则集，信息更聚焦更容易被 AI 理解；并且受层叠规则影响，使用原生 CSS 时，元素样式可能受全局、祖先级元素、多种选择器等层级的样式规则影响，这对 LLM 而言意味着具体信息分散在项目的多个角落，需要消费、理解更多上下文才能推导出正确的结果，相对而言原子化 CSS 框架下，大部分样式信息都聚焦在元素对应的 Class 列表上，信息高度聚焦，推理成本更低，结果也会更可靠。
- 通用规则优于特化设计：技术栈的设计规范越是通用，则越容易被 LLM 理解，也就越是适用于 AIGC 场景。例如，GraphQL 明显优于 Restful，因为 GraphQL 提供了一套用于描述实体 + 实体关联关系的通用语言规则，足够用于表达绝大多数数据存、取、删、改等常规业务操作，因而对 LLM 而言只需理解这套通用语言规则，配合具体业务领域中的实体与实体关系即可基于 GraphQL 灵活编写出各类数据操作逻辑；而 Restfull 规范则更多聚焦在实体上，除几种基础的数据操作外，涉及复杂数据结构场景时，出于实用性、性能等角度考虑，通常不得不特化设计、特化开发，而这些特化处理对 LLM 而言会显得过于具体，相应的上下文复杂度与噪音也会更高，也就更难以推导出正确的答案。
- 自动化质检：技术栈的质检工具越强大，则能够越早、越全面地发现质量问题，进而更能低效 LLM 随机性带来的质量风险，也就更适用于 AIGC 场景了。例如，Typescript 之于 JavaScript，前者具有更强的类型声明系统，因此在静态代码分析阶段即可找出诸多类型不匹配问题，那么即使 LLM 生成了类型不匹配的代码，也能够在运行代码之前发现问题，纠错成本要低很多。
当然，上述规则仅仅是我的一家之言，随着大模型的迭代发展，具体规则后续必然还会新增或删改，这不重要，重要的是非常建议读者后续在做技术选型时，不要只是基于个人 or 团队喜好做决定，应该更多考虑技术栈对 AI 的适用性，甚至可以以此为首要原则，尽可能选用对 AI 友好的技术与工具，使得 LLM 更好、更准确地辅助完成各类开发任务，充分融入到日常工作中，提升个体与团队的整体效率。
5. 降低预期
对，标题没写错，你需要降低预期！前面也说过几次，LLM 并不是魔法，它有幻觉，有知识漏洞，有随机性，不擅长解决复杂问题，有各种各样的缺点，从我的使用经验来说，多数时候它还远没有达到我预期的状态，需要我参与到各种代码细节中。
例如，生成单测通常都跑不通，需要各种修改微调测试；生成的文档可能也会缺失某些重要内容，需要调整 Prompt 后多次重试，才有可能达到预期效果；生成的代码，即使在 Marscode 各种上下文引用能力的加持下，也经常会在细节处犯错，导致执行失败。以 LLM 的底层实现逻辑来说，这些结果都太正常不过了。
因此，建议降低对 Marscode 或者其他 LLM 工具的预期，它并不是魔法，无法完全代替人类智能，当下你还是需要认真做好导演角色，引导 Marscode 更准确更好地解决你的问题，认真研读理解仓库已有的代码与 LLM 生成的代码。更进一步的说，你自身还是需要有比较强的技术能力，理解各类技术底层细节，才能及时发现、修复问题。某种程度上，Marscode 就像一把刀，它的锋利程度取决于你自身的功力。
总结
本文讨论了 Marscode 作为编程辅助工具的优势、使用中的最佳实践技巧以及需要注意的问题。Marscode 在传统 IDE 基础上，搭配良好的交互与 LLM，能为编程新手准确生成代码，但仍存在局限性。
关键要点包括：
- 频繁提交代码：使用 Marscode 生成代码后，经过简单 Review、调试、审阅设计等步骤，多次迭代并及时提交，方便回滚。
- 重视 Code Review：Marscode 生成的代码可能局部最优但非全局最优，应重视人工审查以保证长期可维护性。
- 建立更好的工程化体系：投入精力建设稳健的工程化体系，用自动化工具代替人力完成基础质检任务。
- 使用 AI 友好的技术栈：选用社区热度高、结构化强、通用规则优、自动化质检好的技术栈，以提升 LLM 辅助效果。
- 降低预期：LLM 有诸多缺点，无法完全替代人类智能，使用者自身需具备较强技术能力。