代码瘦身

AI 编程最容易被误解为“根据一句需求生成一段代码”。这当然已经很有价值，但离真实交付还差得很远。 一个改动真正进入系统，通常还要回答一系列更实际的问题：应修改哪个仓库、哪个分支，是否会影响生产服务，在哪里构建，如何部署到测试环境，怎样确认 SSR、静态资源、接口数据和浏览器页面都正确，失败后又回到哪个镜像、哪个提交。缺少这些上下文时，Agent 即使能写出看似合理的代码，也只是完成了一次局部编辑。 墨天轮第一阶段代码瘦身让我重新审视了这件事。围绕 issue_198，前后端共精简了 17,831 行代码；更重要的是，Opsx 没有把它停在一次大规模删除上，而是把仓库、测试主机、构建部署、验证证据和后续回退方法组织成一条可以复用的交付路径。这个案例也让我逐渐形成了对 AI 时代产品研发节奏的一些判断。 图：issue_198 在 Opsx 中的执行视图，显示了多次 Execution、代码变更和测试验证的完整记录。 图：前端瘦身分支合并到 master 的提交记录。合并前已在测试环境完成构建、部署和验证。 图：该合并请求涉及 115 个文件，变更为 +1,545 / -14,962，前端净减少 13,417 行。这里的新增与删除是该次合并的 Diff 口径。 代码不是孤立文件，而是资产关系中的一个节点 在 Opsx 中，repo-modb-front 不是一段模糊的“前端代码”。它是一个具有稳定身份的 Repository Asset，记录了源码用途、分支、运行位置，并关联墨天轮前端服务。此前接入的生产环境、应用服务、数据库和日志资产，使一次报错能够沿着“现象 → 服务 → 仓库 → 相关依赖”的方向收敛，而不是由维护者先在多个 IDE、终端和控制台之间猜测范围。 这正是普通 AI 编程工具难以触达的层次。它们可以生成看似合理的代码，却不知道： 这段代码应该提交到哪个仓库的哪个分支：缺少 Asset Graph 提供的仓库身份和分支策略 修改会影响哪些服务和依赖：缺少资产关系图谱，无法评估影响范围 在哪个环境可以安全测试：缺少 Runtime 能力，无法连接到真实的测试主机和构建工具 如何验证 SSR、静态资源和接口都正确：缺少与浏览器、服务和数据库的执行通道 失败后如何回到已知正确的版本：缺少与 Git 的集成，无法安全回退 这些问题的答案不在单个文件或 Prompt 中，而是分散在资产关系、测试环境、Git 历史和验收标准里。Opsx 通过 Asset-Grounded 设计，让 AI 从“生成代码片段”进化为“完成可验证的交付”： ...