核心内容摘要
黄品汇：品鉴生活的馈赠，汇聚美好的时光
最近一年AI编码飞速发展现在我的90%以上的代码都是出自AI。
想想在2024年调用OpneAI官方接口
5模型,超过10K的Token就让LLM的上下文完全混乱导致LLM无法记住太多东西更不用说调用工具生成代码了。
到目前为止用了各种工具已经半年以上了记录一下总体的实践经验。
后面将cursor、Claude Code、OpenCode等工具统称为AgenticCoding工具我的主要工作语言是go/Rust各个工具和模型在不同语言上会有所差异你自己的结论可能和我不太一样。
Agentic Coding是工具的扩展而不是智能的扩展就目前来看虽然现在接近90%以上的代码都能由AI生成但是这些工具还是依赖于你或者团队原先的见识、知识、流程等本质还是工具。
如果之前你的团队或者你没有接触过良好的软件工程管理、规范或实践那你在有了Agentic Coding之后只是感觉上让你更爽了一点而已对于软件工程的管理甚至会起到反作用。
比如更多的未经审查的代码会进入git仓库更多的不明确的需求导致Agnetic Coding工具的自由发挥空间过大AI在不恰当的地方过度设计未经审查合并代码后导致测试人员更难发现BUG以及提交自己看不明白的代码导致线上出问题后无法快速排查技术债越来越多。
【好的上下文工程一般的模型】效果好于【一般的上下文工程好的大模型】这里的上下文工程就是各类编码工具。
Agentic Coding工具就是使用良好的上下文管理加上你提供的提示词来调用大模型接口并使用大模型的接口的返回来决定下一步如何做。
仅就go语言而言经过几个月的测试Claude Code使用GLM
7(或者Kimi
2.
要好于 Kiro使用Claude Opus
5或者antigravity使用 Claude Opus
5。
这个也可能是与语言相关。
我没用过Claude Code搭配原生的Sonnet或者Opus模型但是在cursorOpus跟使用cursorkimi差异没有想的那么大。
如果你需求管理混乱你要先规范需求如果你的团队流程混乱你要先规范流程有些公司包括一些大公司的一些部门管理比较混乱。
需求评审的时候产品只能拿出一个想法和简单的几句话的文档但是又要开发预估时间之后开发过程中会不断发现问题导致后面需求和前面的需求大相径庭有时候进入测试之后产品还在调整需求文档。
部门领导对此视而不见如果有人说流程混乱、需求混乱那就先把提问题的这个人解决掉就不会有问题了。
有些小公司有这种情况有些大公司的某些部分也有这种情况。
如果我没遇到我敢瞎说不解决需求和流程混乱的问题在Agentic Coding的加持下每个人只会更累生成的代码也会更乱。
AI时代你首先得知道自己想要什么你不能在你自己还不清楚的情况下先把代码写完了。
要注重知识共享和落地讲解跟随AI工具的发展不要口头说一个东西多好多有用要在团队中打开项目以一个实际需求为例给大家展示一下这个技术有多好。
比如MCP/Skills不要夸他有多好不光要推荐给大家还要以实际拉个会议来讲解如果落地使用否则就跟空喊“努力努力加油加油”一样。
当然这也不是一个人责任团队中可以定期分享。
比如Claude Code中的斜杠命令、SubAgents、Skill等。
附加: 斯坦福大学的《CS 146S: 现代软件开发者》这门课。
一些技巧编写代码的时候一定要先使用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)。