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.如果你需求管理混乱，你要先规范需求；如果你的团队流程混乱，你要先规范流程

  有些公司，包括一些大公司的一些部门，管理比较混乱。需求评审的时候，产品只能拿出一个想法和简单的几句话的文档，但是又要开发预估时间，之后开发过程中会不断发现问题，导致后面需求和前面的需求大相径庭，有时候进入测试之后产品还在调整需求文档。部门领导对此视而不见，如果有人说流程混乱、需求混乱，那就先把提问题的这个人解决掉，就不会有问题了。有些小公司有这种情况，有些大公司的某些部分也有这种情况。如果我没遇到，我敢瞎说？
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

这个有用。

鼓励转贴优秀软件安全工具和文档！

用心讨论，共获提升！

感谢分享，学习下。