星火计划学习实践情况汇报

文熙总：

您好！第八期星火计划已进入第5周，现将近期学习、实践和思考情况汇报如下，主要涵盖四个方面的内容：

• 关于应用研发的一些想法
• 智能体编程探索实践与初步成果
• 对团队角色分工的一些观察
• 与星火学员交流的情况以及一个商机

关于应用研发的一些想法

我始终认为，对外输出的服务最好有软件（工具、应用或平台）作为载体，这有助于提升服务的可见性和影响力。过去几年，我一直希望能够更深入地参与应用开发，确保使设计意图能够按照预期实现。但是受到专业背景和资源的限制，这些想法未能实现。编程智能体的出现，为我带来了转机，也同时带来了新的问题：如果人人都能借助智能体开发应用，那么如何体现专业价值？

我认为，智能体编程大幅降低开发门槛的背景下，我们应该更加重视应用研发所使用的工程方法和应用服务所搭载的业务方法。

讲究工程方法，为的是持续以高效、可靠的方式开展应用开发和维护工作，确保其质量达标且能够在严肃的生产环境中长期运行。智能体编程时代下，拉开专业开发者与业余开发者之间距离的关键，并非单纯的“高效”，而是以“可持续”、“可靠”和“质量”为前提的“高效”（我最近在思考一个关于“模板应用”的想法：这个应用不提供具体的业务功能，但是充分满足关键的非功能性需求，包括但不限于智能体编程规范、流程，以及国家和集团提出的各类安全运维要求等。这个应用可以作为构建其他应用的基础。如果能够实现的话，相信会具有一些推广价值，尤其是在集团提出的各种安全要求越来越多的情况下。我想我可能会在进一步掌握智能体编程方法后尝试做一些相关的工作）。

讲究业务方法，为的是科学地解决业务问题，提升应用服务效果，进而更好地创造价值。对于我们数据团队来说，业务方法主要是指数据能力建设、运营、产品化与治理等方面的方法。当前，高质量数据集和可信数据空间等新兴领域仍处于探索阶段，还有很多问题需要解决。AI尚无法直接提供成熟的方案，所以，能否在这些领域进行深入研究、提出好的思路和创意，并且借助应用将其落地，将直接决定团队竞争实力。

总而言之，编程智能体已经解决了如何在较短时间内把应用做出来的问题，所以我们应该将更多注意力用于考虑如何把应用做好。“把应用做好”并不是智能体编程时代对开发者或厂商提出的新要求，但涉及到一些变化，特别是在工程方法方面。前段时间，我结合一个实际项目进行了这方面的初步探索，现汇报如下。

智能体编程探索实践与初步成果

以下是我使用编程智能体的简要时间线：

• 1月：开始使用智能体编程工具处理日常工作；
• 3月：首次向物联网客户洞察系统提交代码；
• 4月：尝试从零构建数据能力目录应用，获得原型；
• 5月：改变实践方法，重新构建数据能力目录应用；
• 6月：完成数据能力目录应用第一版上线。

为了避免氛围编程的相关问题，我在首次构建数据能力目录应用时，使用了speckit（一种规范驱动的智能体编程工具）。尽管这个工具能在一定程度上缓解问题，但效果有限，因为：

• 每次新增需求都会生成一组新文档，导致文档数量和内容快速膨胀；
• 各组文档独立描述需求规格、设计方案和实现计划，缺乏统一的视角，几乎不可避免地会出现互相冲突的地方，并且容易导致重复造轮子的问题。

上述情况很快就会使人类对文档失去掌控，进而出现由于AI自主发挥而导致的各种问题。我认为这种方式仍然没有脱离氛围编程的范畴，至少对企业级应用来说并不可靠。

为解决上述问题，我认为需要设置一组核心文档作为唯一事实源，所有新需求及设计方案应当先融入该文档，再衍生出计划、进行实施。人类的职责是长期维护并保证该组文档的质量，而AI的职责则是按照该组文档准确地提供实现。这些核心文档与瀑布式开发的文档有点类似，但在智能体编程时代下需要解决一些新的问题：

• 如何确立一个最小完备集，它所提供的信息量，不会导致人类认知过载，同时又能够使AI准确理解和执行？
• 如何在应用长期演进的过程中，更加高质高效地持续维护文档、以及文档与应用之间的关系？

我在5月份的应用重构工作中，尝试建立了一组核心文档，但方法还比较原始。坦白说，该应用目前仍然主要是以氛围编程的方式实现的。现在我有不少零散的想法和思路，但尚未进行系统梳理、也还没有开始实现；等有了实际进展我再来汇报。

对团队角色分工的一些观察

前些天，党校邀请了B站多模态数据基建体系负责人郑志升为学员授课。课间我向他请教了智能体编程的实践方法，以及关于团队分工的问题。他表示，其团队已不再按照需求分析、前/后端研发、数据开发等传统角色进行分工，而是在制定应用服务整体骨架和规范后，由每个成员负责一个模块的端到端全栈研发工作。

我认为这个模式有一定的可取之处。我在参与物联网客户洞察系统研发的过程中深刻体会到，沟通是研发效率和质量的一个重要影响因素。在现有的分工模式下，需求从客户侧传达至研发侧，需要经过多个人/环节，期间容易出现信息丢失、理解偏差等情况，导致工期延长、实现不达预期；同时，由于一个需求的实现由多人参与，容易出现职责边界不清的问题。

对于小型应用来说，如果成员能够在编程智能体帮助下独立完成全栈开发，那将会是最高效的方式；对于大型应用来说，拆解出可以由个人全程负责的模块，不仅能减少沟通成本，还能使责任归属更加明确，有助于强化成员的责任意识。当然，这对团队成员的综合能力要求会有所提高，同时也要求成员在思想上做出一些转变，不要被自己当前的岗位职责所限制。

与星火学员交流的情况以及一个商机

我在课程间隙与其他学员进行了一些工作上的交流。其中，我提到了关于机房节能的话题，引起了来自河北数智公司的集团专家仝晓文的注意。

他表示有很多委托他们建设和管理智算机房的客户（主要是美团等互联网厂商）普遍具有节能需求，他们团队近期也正在开展一些算法预研和节能平台原型设计工作。我利用去年参与智汇星河竞赛的汇报材料，向他介绍了我们的解决方案、落地效果以及所获得的荣誉专利等。他表达了进一步交流的意向，并称如果节能效果理想（他期望能达到10%的节能率），希望能与我们开展合作，避免重复建设。

目前他正在与他们团队的成员沟通，后续我将继续跟进此事，在合适的时候组织两边成员进行线上交流。