前文提到了 IDE 在开发中的关键位置。本文尝试从顶层需求开始分析，探讨一下 IDE 理应具备的功能，最后是中文（母语）编程工具的优势。实现细节、复杂度，一些非技术问题如开源协议、商业模式等暂不讨论。
前文是从 mcuScript 展开，本文也以单片机领域开发为例。个人近二十年前在大学时初次接触单片机、FPGA 开发，04 年毕业后有幸参与了某国产嵌入式系统的 IDE 开发（主要是 Eclipse 插件）。08 年来美读硕时又重修了 FPGA 开发，但之后十年甚少接触这个领域，文中如有脱节错谬之处还请指出。
开发是手段，满足某个需求才是目的。软件开发中很大比例时间都是在搞清需求（到底想要什么）、调研现有产品（看看是否已有同样或相近产品）并将需求细化文档化，但个人项目往往对这一步比较忽视，或者说也没有什么好用的工具提供辅助。往往是从一开始的大概“想法”，在网上搜一搜大概方案，然后就开始着手开发了。
这是现有的 IDE 大多专注的部分。根本上是为了让用户更快、更准确地完成需求，为此在开发过程中不断“纠偏”，将潜在问题尽早反馈给开发者并帮助解决。
比如语法高亮是为了代码更可读，代码补全是为了更易写对代码，各种编辑、编译期间的警告报错信息和修改建议、自动测试框架等都是为了尽早提示用户可能出错的位置、以免拖到运行期，集成的调试器是为了更快地定位运行时问题，仿真器是为了节省在真实硬件上运行调试的开销。
IDE 的完善程度很大决定了开发效率。但如果遇到靠 IDE 以及内置的帮助文档无法理解或解决的问题怎么办？
易语言、按键精灵等等中文编程工具都有自己的论坛或者群，供问题交流、代码或可执行文件分享、甚至甲方乙方交易，也有随编程工具捆绑销售教程的，这些都是查看社区生产的产品（无论是教程中的例程还是论坛的分享）、比照自身需求、解决开发问题的渠道，但是它们毕竟与 IDE 是分离的，各种内容往往碎片化，难以整理和搜索（尤其对新手来说）。即使有管理员做了类似索引置顶帖之类的入口，很多常见问题往往还是一再出现。对于新编程工具的作者，往往要花费大量时间应付新用户的雷同问题，尤其在编程工具尚未完备、各种报错信息尚不完善之时。
可以看到，IDE 几乎不参与需求调研和交流部分，而实际上这两部分占据了“产品开发所耗时间“的很大部分。单纯开发期的辅助功能已基本被 IDE 覆盖，而且并没有太大提升的空间（当然新出的编程工具覆盖上面列出的辅助功能肯定需要一定时日），那么很自然，应该从被忽视的其他部分着手，将其纳入 IDE 的集成范畴中。这也将是与其他编程工具差异化的关键之处。
思路很简单，开发者只要拿到这个 IDE，就可以通过它这一个渠道，尽早达成需求。当然，这是理想情况，但方向定了之后，就可以采取各种方式接近它。下面对上述各个方面逐一构想相应功能。
没有现成的方案，才需要开发。即便是就想自己从头造轮子，如果一开始就能找到其他人的轮子草图，也会有很大参考价值。对于业务人员或者开发新手，即便只有目标文件（可执行文件）对需求调研也很有用，因为这可以让他们及早确认这个编程工具可以完成他们的想法。
那么如果 IDE 集成了一套覆盖常见应用的例程、或者开发者分享的项目（甚至只有可执行文件）的话，再加上一定的搜索功能，用户就可以不用自己写一行代码而找到自己需求相近的方案并进行尝试运行，以达到辅助需求分析的目的。
这个”搜索“就大有文章可作。最基本的是关键词搜索，比如在例程的题目、描述、代码全文等搜索某个关键词，再进一步就是用某个 DSL 描述自己的需求（“高级搜索”其实就是一种初级的 DSL）再由 IDE 在例程项目中进行匹配，甚至在开发过程中提示你的代码“很像”某个/些例程以供用户参考。
在现有的辅助功能基础上，与领域知识库深度集成可以让用户的“自助”能力大大提升。单片机领域牵涉了很多硬件知识（如果支持多个硬件平台背景知识就更多），在开发、调试方法上有很多独特之处。在开发全过程中，对各种报错警告信息都可以指向相关的知识点、例程、或是他人提过的问题和解决方法（如何集成论坛或是问题追溯平台功能另行讨论）。
知识库完备地越早，编程工具作者就可以省去越多应对用户问题的开销，从而更专注于编程工具和知识库更新和改进本身。
上面提到了与开发过程的集成，如相似需求、开发问题的匹配。此外，知识库的积累也可以借助社区的力量，如一些用户分享的围绕某功能的教程、疑难杂症的调试方法等。知识库的整理和搜索也是个很大的课题。
还有一个重要方面：所有对 IDE 的用户操作数据都可以成为 IDE 或编程工具链改进的重要参考。比如说上面提到的关键词搜索，即使不对其他开发者完全可见，也可以进行数据分析后得出一些热门需求，并有针对性地加强该方面的生态加强（例程覆盖、API 和相关开发手段改进等等）。这样可以更深入了解编程工具的用户群和使用趋势，以及时调整开发方向。再比如，假如对某个问题的搜索特别频繁，那么就有必要看看是否能在工具层面尽量避免这个问题的发生。
此外，是否能将其他现在论坛背负的功能比如甲方乙方市场集成到 IDE 内，都可以畅想一下。
基于上面的功能构想，只要能做到绝大多数例程的标识符为中文、报错信息、知识库为中文，就会有不少优势。
无论是需求相关术语或者单片机领域专用术语都是中文的，就可以贯穿需求到实现。在上面的例程搜索时，可以更方便地找到合适的解决方案。在报错信息搜索时，也可以更方便地找到相关知识点。
前文提过，中文例程可以更大程度代替文档的作用。这样在建设知识库时，可以更倚重例程，减少文档量。鉴于例程是更可直接利用、综合价值更大的，可以在例程库上投入更多精力意味着生态完善得更快、社区发展也更快。
从用户角度说，一站式提供解决方案的工具是最理想的。IDE 理应从最源头的用户需求开始就及早参与，并贯穿整个产品研发过程。也许“集成开发环境”这个词汇也应与时俱进。
成文仓促，请不吝指摘。