copilot目前大行其道，以及顺带衍生的workspace、cursor等更是青出于蓝而胜于蓝。
copilot基本功能是代码补全，它最大的功效是通过插件动态获取编码上下文，上下文来源于热点文件、兄弟文件（相同目录）、类似文件名文件、同一工程或者来自远程/本地知识库等，拼装成的prommpt一般为光标前代码+光标后代码+相似代码+依赖代码，然后让大模型进行补全，客户端收到返回值后进行截取和整理，形成候选代码。
但是，有了copilot是否就可以高枕无忧了呢？
工欲善其事必先利其器，但是工具和人是互相塑造的关系，有了工具之后，如何用好用熟就成了关键。比如热兵器时代，因为火枪对人的体能需求相对降低了，在武力方面，实现普通农民和军事贵族之间的平权。一个农民可以通过火枪和一个武士对决。
但是绝对不是说有了火枪就完事大吉了，火枪一定带来了新的技能要求，比如要熟悉枪械原理，懂得弹道，懂得枪械的使用，比如装弹、开保险，更重要的是据枪、瞄准、射击等。
copilot的使用也一样，要用好还是有一定要求的，只有熟悉工具，并熟练到肌肉记忆的程度，才能取得真正的效果。就像射击一样，对个人来说要培养成神枪手，对团队来说，要能尽量多的首发命中，需要多组织打靶多练习。
先给出两点洞见：
1、大模型补全本质还是通过动态prompt补全代码，代码越是解耦越是有利于生成。
2、大模型编码是实现了软件通用编程能力的平权，注意，一定是通用编程能力。即越是接近通用知识的代码实现，生成代码的采纳率越高。
解耦之前，我们先看看高频场景的耦合在哪，代码开发的场景中，按粒度可以分为系统级、组件级、类/文件级、函数/行级。
通过项目实际数据可以看出，主要的软件编码过程都集中在函数级级和行级层面，而这个层面的代码都是由业务流程+业务逻辑组成，它们之间的耦合是占比最高的。
其中业务逻辑负责垂直单项功能的实现，比如字符串处理、排序算法等等，这方面基本都是通用逻辑，大模型非常擅长；业务流程负责业务逻辑的编排和组合，打通端到端业务。
最需要就进行业务流程和业务逻辑的解耦。
解耦后其中业务逻辑尽可能使用大模型生成。代码编写前还是要做简单的设计，拆分出业务流程和业务逻辑，就像用枪射击之前，装弹、开保险是必不可少，但是据枪和瞄准才是重中之重。
目前大模型生成代码主流是使用copilot，copilot具有以下主要功能：行内补、行补、块补、通过签名补、通过注释补全几类。
很多同学都不喜欢在copilot中使用注释生成代码，原因就是觉得补全一行代码，就要写一行注释，性价比不合适。
其实，大模型生成代码时，越是整块知识，生成越准确；另外相对于生成单行代码，通过注释生成代码块性价比也较高。
所以，我们推荐的做法如下：
1、拆分需求成业务流程+业务逻辑
2、针对业务逻辑设计函数签名或注释
3、使用函数签名/注释生成代码块
4、使用行内补/单行补进行细节补充和调整。
那么，遗留代码上新增功能和修复bug该怎么做呢？
这里我们强烈推荐采用发芽模式。
如上图，在遗留的老物件上长出新的绿芽，从而焕发了生机一样。我们同样可以在依赖代码上新增功能时参考类似方式，即不在原代码处展开修改，而是对新增功能做一些内聚，把具体实现放入新增的类/文件中，同时对外暴露接口，然后在修改处引入这些类/文件，并调用其中对外暴露的接口从而完成功能。
当然如果是简单修改，直接在原文件上修改；如果稍微复杂的修改，尽可能使用发芽模式，具体参照上图，即把修改点内聚到右侧新的芽（类/文件）中，左侧的修改点调用左侧的芽文件。
这样我们就可以在芽文件中拆分业务流程和业务逻辑，然后在业务逻辑中使用通过函数签名进行代码补全和通过注释进行代码补全。
综上，copilot对开发人员来说如虎添翼，但是工具和人之间是互相塑造的，就像火枪代替弓箭一样，扛了枪不代表就能胜利，据枪和瞄准才是关键。
用好工具是需要一定技能和门槛的，用好copilot的关键是做好业务流程和业务逻辑的解耦和拆分，写好函数签名和块补全的注释才是关键，本文详细讲述了如何高效的使用copilot的具体方法和路径，希望能给大家以启示。
