BMForge 项目
本文介绍我的新项目 BMForge。
目前，我使用 Codex 作为编程代理，背后运行的是 OpenAI 的 Sol 6.1 模型。
我非常喜欢它。开发速度、代码质量以及它展现出的能力都令人惊叹。它从根本上改变了我开发软件的方式。
但也存在一些严重的问题。
擅自引入组件
Codex 有时会自行做出技术选型。遇到一项需求，它就挑选一个库、安装它，然后开始把它整合进代码库。
有时这样做完全合理，有时却并不合适。
我希望参与这些决策。我有自己偏好的技术、现成的实现和成熟的开发模式。我不希望代理仅仅因为方便，就往项目里引入一个新框架。
毕竟，这是我的软件。
我的地盘，我的规矩
我开发软件已经很多年了，也形成了自己的一套工作方式。
编码规范、命名约定、目录结构、数据库接口、发布管理，以及 DEV、QA、PROD 环境之间的隔离，这些都是我的软件开发生命周期（SDLC）的一部分。
Codex 不可能天生就了解这一切，但我需要它遵循这些实践。
例如，排查生产环境的问题时，开发人员不应该直接在生产服务器上做实验。应该收集日志、导出数据库、把证据带回开发工作站，然后在那里复现问题。
这是基本的运维纪律。
Codex 是一名能力很强的开发者，但它并不一定了解我的开发环境是如何运作的。
一旦它开始临场发挥，事情就可能变得混乱。
这可不行。
不断重复自己
Codex 支持通过 AGENTS.md 文件提供项目专属指令。这很有用，但我发现自己总是在不同项目里重复同样的话。
比如：
- “看看 bmgeoip 的 new-release 脚本，照那个模式做。”
- “看看 /opt/dev/bmdynip 里的 BMDynIP 项目。它有一个报告服务器，可以参考它。”
- “snake-web-code 项目用了一个 GitPublisher，从那个实现入手。”
这样的情况非常多。
问题还不只是重复。每多写一个新实现，就多了一次引入细微不一致的机会。
我当然可以继续扩充 AGENTS.md，但我想要一个更系统的方案：可复用、有版本控制，而且能够持续改进。
BMForge 登场
BMForge 就是我为解决这些问题而做的尝试。
BMForge 的核心由三部分组成：
规范 + 流程 + 软件技术栈
它为使用可复用组件和成熟开发实践创建新应用提供了共同的工程基础。
仓库中包含：
- 组件规范： 定义行为、获准使用的 Python 模块、实现约束和测试要求。
- 可复用组件： 已经验证过的通用功能实现，例如数据库访问、HTTP 服务、ZeroMQ 消息传递、配置管理、本地化和可视化。
- 开发流程： 项目初始化、命名约定、目录结构、安装、升级、发布，以及其他 SDLC 活动。
- AI 代理技能： 教会编程代理如何遵循这些标准、执行既定流程的指令。
启动新项目时，BMForge 提供基础。应用自身拥有独立的实现，运行时不依赖 BMForge。
AI 代理技能
AI 技能正是我一直缺少的那块拼图。
技能越来越普及，网上也有大量现成的技能可供使用。
但要提醒一句：把第三方 AI 技能安装进自己的环境，应该像安装第三方软件一样谨慎。 技能可以指示代理执行命令、访问资源，以及与系统环境交互。一定要确认来源值得信任。
我没有依赖第三方技能，而是专门为自己的开发环境创建了一套技能。
它们不只是提示词的集合，更像是运维操作手册，就像系统管理员或运维分析师会遵循的操作规程。
例如，BMForge 的根本原因分析（RCA）技能教 Codex 如何排查生产应用的问题。
流程很简单：
- 通过 SSH 连接生产环境。
- 收集相关日志和数据库转储，不修改远端系统。
- 将证据传回开发工作站。
- 在本地复现、调查并修复问题。
进行 RCA 时，绝不修改生产环境。
就是这样。没有复杂的流程，也没有官僚式的繁文缛节，只是一套成熟的运维实践，现在 Codex 可以始终如一地遵循它。
其他技能则规定如何使用常量、构建数据库接口、实现 HTTP 服务，或准备发布版本。
关键在于，我再也不用每次都从头解释这些流程。
约束本身就是一项功能
BMForge 有意限制 Codex 可以引入的技术。
组件规范明确指定获准使用的软件技术栈。如果现有组件和模块无法满足某项需求，Codex 应该停下来与我讨论替代方案。
也许我们确实需要一个新库；也许应该扩展现有组件；也许需要重新审视需求本身。
但无论如何，这都应该是一个经过考虑的决定。
AI 参与工程流程，但不能单方面重新定义它。
构建组件库
BMForge 也被设计成一个可以持续成长的项目。
一些组件从已经部署的应用中提取而来。它们已经开发并投入使用，因此有实践基础。
另一些组件则根据规范创建，以满足未来应用的需求。
随着我继续开发软件，我会识别常见模式，并将其提升为 BMForge 中的可复用组件。
每个新项目都有可能为下一个项目贡献些什么。
可追溯性与持续改进
这是最让我兴奋的部分。
BMForge 组件带有元数据，用于标识其实现所依据的规范及版本。
这样，已部署应用与其组件背后的工程规范之间就建立了可追溯的联系。
想象一下，当我发现一个缺陷时会发生什么。
我可以从受影响的组件追溯到它的规范，判断问题究竟出在具体实现还是规范本身，然后改进相应的部分。
质量和性能方面的提升也遵循同样的原则。
随着时间推移，这些改进能够回流到 BMForge，供未来的应用使用。
发现问题。改进实现。完善规范。把积累的知识传承下去。
这才是目标：不只是复用代码，而是不断积累工程知识。
这是一个循序渐进、拾级而上的过程，每一项改进都有机会提高后续项目的质量。
可追溯机制已经就位。它所支持的更丰富的报告和分析功能，还有待我在未来实现。
让 AI 成为 SDLC 的参与者
BMForge 背后还有一个更宏观的想法。
我并不想仅仅因为 AI 的出现，就重新发明一整套软件开发方法论。
我已经有一套适合自己的 SDLC。
我要做的是将 AI 作为另一名参与者，融入现有流程。
Codex 带来惊人的速度和实现能力；我提供需求、架构、标准、运维经验以及工程判断。
BMForge 则提供一个共同框架，让我们可以有条理地协作。
代理理解了自己的工作环境，因此变得更高效。我不再反复解释相同的规则、重复构建基础设施，因此也更有生产力。
最终的软件仍然容易理解、易于维护，而且属于我自己。
初步成果
目前还只是起步阶段，但我已经用 BMForge 构建了 DevLog，一个用来记录我在各个 GitHub 项目上投入多少开发时间的应用。
DevLog 收集开发活动数据，并通过一个简单的 Web 仪表盘展示出来。
这是个不大的应用，却为这套方法提供了一次很有价值的实战检验。
BMForge 标准化并加速了项目初始化，提供了成熟的组件和开发约定，帮助 Codex 在不反复重造基础设施的情况下构建出结构清晰的实现。
无论是 DevLog 还是 BMForge 本身，都还有大量改进空间。
但这恰恰就是重点。
结语
BMForge 最初只是为了让我不必对编程代理反复说同样的话。
现在它正逐渐成为一个更有意思的东西：不断成长的规范、流程、可复用软件组件和运维知识集合，用来支持我自己的软件开发方式。
如今，我可以更快地构建应用，同时不放弃对架构、技术选型或运维实践的控制权。
如果出了问题，我也有一套机制把经验反馈进框架。
BMForge 让我以 AI 的速度开发软件，同时保留自己的工程纪律。
我认为这已经是一次成功，而且打算继续扩展和完善它。
用 AI 构建一个框架，再让这个框架教 AI 按照经过实践检验的人类工程模式开发软件，颇有一种循环往复的满足感。能够继续参与其中，感觉真不错！