Agentic Coding一些实践总结

  最近一年AI编码飞速发展，现在我的90%以上的代码都是出自AI。想想在2024年调用OpneAI官方接口（3.5模型）,超过10K的Token就让LLM的上下文完全混乱，导致LLM无法记住太多东西，更不用说调用工具，生成代码了。到目前为止，用了各种工具已经半年以上了，记录一下总体的实践经验。后面将cursor、Claude Code、OpenCode等工具统称为AgenticCoding工具，我的主要工作语言是go/Rust，各个工具和模型在不同语言上会有所差异，你自己的结论可能和我不太一样。

  1.Agentic Coding是工具的扩展，而不是智能的扩展（就目前来看）

  虽然现在接近90%以上的代码都能由AI生成，但是这些工具还是依赖于你或者团队原先的见识、知识、流程等，本质还是工具。如果之前你的团队或者你没有接触过良好的软件工程管理、规范或实践，那你在有了Agentic Coding之后只是感觉上让你更爽了一点而已，对于软件工程的管理甚至会起到反作用。比如更多的未经审查的代码会进入git仓库，更多的不明确的需求导致Agnetic Coding工具的自由发挥空间过大，AI在不恰当的地方过度设计，未经审查合并代码后导致测试人员更难发现BUG，以及提交自己看不明白的代码导致线上出问题后无法快速排查，技术债越来越多。

  2.【好的上下文工程+一般的模型】效果好于【一般的上下文工程+好的大模型】

  这里的上下文工程就是各类编码工具。Agentic Coding工具就是使用良好的上下文管理加上你提供的提示词来调用大模型接口，并使用大模型的接口的返回来决定下一步如何做。

  仅就go语言而言，经过几个月的测试，Claude Code使用GLM 4.7(或者Kimi 2.5) 要好于 Kiro使用Claude Opus 4.5或者antigravity使用 Claude Opus 4.5。这个也可能是与语言相关。 我没用过Claude Code搭配原生的Sonnet或者Opus模型，但是在cursor+Opus跟使用cursor+kimi差异没有想的那么大。

  3.如果你需求管理混乱，你要先规范需求；如果你的团队流程混乱，你要先规范流程

  有些公司，包括一些大公司的一些部门，管理比较混乱。需求评审的时候，产品只能拿出一个想法和简单的几句话的文档，但是又要开发预估时间，之后开发过程中会不断发现问题，导致后面需求和前面的需求大相径庭，有时候进入测试之后产品还在调整需求文档。部门领导对此视而不见，如果有人说流程混乱、需求混乱，那就先把提问题的这个人解决掉，就不会有问题了。有些小公司有这种情况，有些大公司的某些部分也有这种情况。如果我没遇到，我敢瞎说？😓

  不解决需求和流程混乱的问题，在Agentic Coding的加持下，每个人只会更累，生成的代码也会更乱。AI时代，你首先得知道自己想要什么，你不能在你自己还不清楚的情况下先把代码写完了。

  4.要注重知识共享和落地讲解，跟随AI工具的发展

  不要口头说一个东西多好多有用，要在团队中，打开项目，以一个实际需求为例，给大家展示一下这个技术有多好。比如MCP/Skills，不要夸他有多好，不光要推荐给大家，还要以实际拉个会议来讲解如果落地使用，否则就跟空喊：“努力努力，加油加油”一样。当然这也不是一个人责任，团队中可以定期分享。比如Claude Code中的斜杠命令、SubAgents、Skill等。

  附加: 斯坦福大学的《CS 146S: 现代软件开发者》这门课。

  5.一些技巧

•  编写代码的时候一定要先使用Plan模式制定规划，并再次让AI审查计划，之后才让AI编写代码。目前主流Agentic Coding工具均已支持Plan模式
• 让AI写代码之前，先将当前的代码都提交。这样如果AI生成的不满意可以随时撤销代码。同时【个人建议】不要给工具git commit和git push权限
• 如果Agentic Coding工具生成的代码，时常偏离项目或者你的预期。你需要将你的预期以及限制写到类似CLAUDE.md或者skills中，来让AI来遵守
• 所有AI生成的代码，目前阶段都要人工审核后才能提交到代码仓库
• 在达到LLM的上下文阈值之前开启新会话来做任务。目前几百K的Token注意力，在某些时候感觉已经超过了人类的注意力(我没有关注的点，AI会意外的考虑到)，但是上下文一长之后就容易腐坏(Context Rot)。