哈喽，今天来做一下复盘。今天主要处理公司的一些开发事项，目前使用的是阿里的Qoder，总的来说使用感觉还可以。

Qoder支持自有模型和其他开源模型，但从实际使用来看，还是它的自有模型表现更好——感觉是大部分开源模型没有做过优化，用起来感觉不太好，所以我一般用它的自有模型。

一、AI编程的核心感受：从“写代码”到“理需求”

在做AI编程的过程中，我最大的感受是：现在写代码不再是一个个具体的技术难点，更多的是要想清楚怎么把需求理清楚。

举个最近的例子：我做一个需求，需要查询老业务的历史数据，编写对应的SQL逻辑。整理这个过程其实很费时间，我花了大半天整理SQL相关的业务知识，把这些整理完之后，再把具体的编程要求、参考样例提供给Qoder，它就可以结合样例和需求生成设计。经过两轮AI交互，它就已经输出了成品代码，而且属于可用范围。

如果这个需求用“古法编程”的方式写，大概需要一天多时间，使用AI编程之后，帮我节省了大概半天时间。

它的核心逻辑是：已经有现成的参考样例，我只需要把业务侧不明确的知识整理好提供给它，它基于这些业务知识就能生成对应代码。我觉得这就是现在比较流行的Agentic Coding（智能体编程）框架。当然目前这套流程还不是很完善，因为还有很多体系化的东西没有搭建出来。

二、当前存在的痛点

全流程自动化缺失

比如代码提交之后能够自动走测试、走业务测试，目前是做不到的。现在它只是把代码生成出来了，后续的业务测试还得自己手动做，AI目前还覆盖不了业务测试。

这里我一直很纠结：怎么才能把全流程打通，更高效地生成业务代码？这也是我现在比较困惑的点。

老系统的业务知识难题

对AI来说，很多业务知识是未知的。我们维护的系统有不少是运行了几年甚至十年的老系统，很多业务知识没有对应的文档留存，你得去看代码、抠业务逻辑，整理出来的内容还不一定和实际代码逻辑一致。

这里引申出一个关键问题：AI除了要能“做出来”，还得知道“为什么这么做”。如果没法跟它讲清楚背后的原因，生成出来的东西可能很抽象，不一定贴合实际业务需求。这是我实际复盘下来的真实感受。

三、新动态：DeepSeek-V4发布

当然，今天DeepSeek-V4也正式发布了，我目前还没试用过，不过Qoder已经支持接入这个模型了。等后续有合适的业务需求，我会实际验证一下它的功能表现。

Qoder支持多模型切换，这点其实挺好的。但它的Token使用量相对来说比较少，如果要重度使用，可能需要购买更高档位的套餐。另外它的五折优惠到4月30日就要结束，之后会恢复原价。

四、成本与行业趋势

现在业界对于编程场景的Token供给在收紧，我们可选的比较优惠的方案越来越少。未来可能会进入常态化定价，Token会有一个相对统一的标准价格，不像现在能拿到这么大力度的优惠。说白了AI编程会慢慢变成常规工具，大家的工作方式可能也要随之调整。

以前做这类需求可能要花一两天，现在用AI辅助只要半天，但AI使用的成本也要算进去，得权衡到底值不值得用。当然，整体算下来，AI辅助的成本肯定还是比纯人力成本低一点，相对来说更划算。

五、底层制约与未来方向

说到底，现在制约我们使用Token的核心是算力，而算力的底层是电力。我看过一些相关分析：如果电力和底层技术没有突破，越好用的模型，对应的Token消耗就越大。

未来可能会往两个方向发展：一是在单位算力下实现更高的性能，做更多、更好的事；二是扩大底层基础设施的电力池，建设更多电力设施，支撑更大规模的AI生产应用。