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 从“生成代码片段”进化为“完成可验证的交付”：
Asset Graph 提供确定性上下文
├─ 目标仓库明确：repo-modb-front（dev 分支用于测试）
├─ 测试环境明确：host_test_app_01 + motest-01 Runtime
├─ 生产影响范围可查询：关联的服务、数据库和依赖
└─ 验收标准清晰：SSR、静态资源、接口、浏览器页面
Runtime 提供跨资产执行能力
├─ Git 操作：由关联仓库的 Runtime 执行 fetch、rebase、commit
├─ 构建部署：由测试主机的 Runtime 完成 Nuxt 构建和 Docker 发布
├─ 验证检查：由具备 curl 和浏览器能力的 Runtime 完成页面和接口验收
└─ 证据回流：构建日志、部署状态、验收结果返回 Issue
Git 提供审计和回退底座
├─ 每次修改都有 commit 和 diff
├─ 失败可以 revert 到已知正确版本
├─ 代码审查仍然可以在任何 IDE 进行
└─ 历史记录可追溯、可恢复
这为 AI 编程提供的不是一个更长的 Prompt，而是确定性上下文：目标仓库明确，能执行的 Runtime 明确，生产影响范围可查询，代码修改仍然落在 Git 的提交、差异和回退机制之内。
传统 IDE 在这里并没有消失，只是不再是唯一工作入口。对于明确的任务，Agent 可以直接在关联仓库中阅读、搜索、修改、构建和提交；人仍然可以在任何熟悉的 IDE 中审阅差异、补充判断或接手复杂设计。Opsx 的目标不是替代开发者，而是把“找到正确代码并完成一次可验证修改”的过程从个人桌面扩展为资产关联的系统能力。
图：墨天轮前端仓库在 Opsx 中的资产视图，显示了仓库身份、关联服务以及 Shell、LLM 的 Runtime 路由。这些确定性上下文让 AI 知道“应该在哪里改代码”。
三种已开始收敛的代码工作
同样是“让 AI 改代码”，实际难度并不相同。以墨天轮当前的实践来看，可以先区分三类已经发生的工作，再明确第四类尚未交给平台的边界。
第一类是被动修复。 应用日志、外部监控或用户反馈定位到异常后，Opsx 通过关联的服务、日志和 Repository Asset 收集证据；确认是代码缺陷时，Agent 在受控仓库中修复，再通过已有的发布路径进入生产。这条链路的长期方向，是把已经验证、影响范围清楚的 Bug 修复从人工小时级响应继续压缩；但“分钟级自修复、自发布”只适用于低风险且有明确验收、回退条件的场景，不能把所有线上报错都直接交给模型修改生产。
第二类是主动的小改动。 issue_199 调整首页资讯展示，issue_200 删除已经不再准确的页脚内容，都是目标清晰、影响范围有限的页面修改。这类需求不应再套用一套冗长的需求文档、多人转交和人工复制代码流程。当前两个 Issue 的代码修改已经完成，状态仍为 in_review；这正是合理的边界：小改动可以快速完成，但仍保留 Git 审阅和发布确认。
第三类是跨模块的中等规模改造。 issue_198 属于这一类。它不是删一段无用文案，而是第一阶段代码瘦身：需要在前后端多个模块中识别历史功能、处理引用关系、移除代码并不断编译验证。总代码变更达到万行级，最终前后端共精简 17,831 行。此时，单靠模型生成 diff 并不可靠；真正决定效率的是能否在接近真实的测试环境里反复验证与纠正。
第四类则是完整的新模块或基础架构研发：从需求发现、产品设计、架构取舍、编码测试、生产上线到增长运营的一整条链路。这还不是 Opsx 当前可以宣称已经自动完成的能力。它需要人提供真实客户问题、业务边界与优先级，也需要能力更强的 LLM、Agent 以及更严格的设计审查和测试验证。把这一边界写清楚，比给出一个过度承诺的“全自动研发”口号更重要。
issue_198：大规模删除之前，先建立可以快速证伪的环境
瘦身工作的风险不在于删除命令本身，而在于历史系统中的依赖并不总是显式可见：一个旧模块可能仍由动态路由、SSR、后端接口、构建配置或某个页面入口间接引用。一次构建通过，也不等于页面、接口和生产式运行环境都能工作。
因此，issue_198 的关键基础设施不是某个特定 Agent，而是新接入的测试主机 Asset host_test_app_01 及其 motest-01 Runtime。它提供了与正式交付隔离、但可以完成完整构建和部署的执行环境。Repository、测试主机、测试前端服务和运行时证据开始被放在同一条任务上下文中。
这条测试路径的价值在于缩短反馈周期，而不是绕过工程治理：
仓库中的受控修改
→ 测试主机拉取 dev 分支
→ 现场执行 Nuxt 构建
→ 构建唯一标签的镜像并推送
→ Docker Swarm 滚动更新 test_emcs-front
→ 验证服务副本、SSR、静态资源、接口与浏览器页面
→ 成功：保留 Git 提交和验证证据
└ 失败：切回上一镜像，继续定位和修复
kw_184 将这条路径沉淀为 active Playbook。它明确规定：测试环境使用 dev 分支和唯一镜像标签；发布前记录原服务镜像；Swarm 最终必须恢复到预期副本数；验收不能只看 HTTP 200，还要检查 Nuxt 资源、服务日志、业务接口和浏览器页面。若验收失败，则先切回上一镜像，再通过正常的 Git revert 回退源码，而不是强推或破坏性重置。
下面是从该 Playbook 删减后的核心命令结构。它仅用于说明测试发布机制；实际主机、仓库和镜像身份由 Asset 与 Runtime 的受控配置提供。
set -eu
git fetch origin dev
git rebase origin/dev
/usr/bin/time -p npm run gray
image="<registry>/test_modb_front:<unique-tag>"
docker build -t "$image" .
docker push "$image"
docker service update --image "$image" test_emcs-front
# 服务稳定后,再验证页面、资源和接口;失败则切回发布前记录的镜像。
curl --fail --silent --show-error https://<test-domain>/dbRank -o /tmp/page.html
这不是用测试环境取代 CI/CD。它解决的是万行级改造在验证阶段的反馈速度：无需等待每一次小修复都走完冗长的线上流水线，Agent 和维护者能够在测试环境中看到构建、部署和页面的实际结果。通过测试后，生产发布仍应走既有的分支、审核和发布边界。
失败不是例外，关键是能否回到同一条证据链
issue_198 的测试过程并非一次完成。一次页面调整留下了数组空项，SSR 在读取菜单字段时触发异常，页面返回 500。这个问题如果发生在传统的异步交接中，常常意味着重新描述现象、重新定位环境、重新等待构建结果。
在测试闭环中，现场已经具备源码、构建工具、镜像、Swarm 服务和页面入口。修复后重新构建并部署，测试站点根路径与相关页面恢复 200，服务副本回到预期状态。这里真正有价值的不是“AI 从不出错”，而是 Agent 的每次操作都能得到环境反馈；发现新事实后，可以围绕同一资产和同一任务继续调整，而不是让失败变成另一段脱离上下文的聊天记录。
这个过程也暴露了 Opsx 自身需要继续演进的地方。最初，issue_198 的自动知识沉淀过度依赖早期的任务标题和失败记录，没有正确识别后续已经完成的测试发布闭环。人工发现后，才将最终验证证据整理为 kw_184，同时补充了“以时间线上最后一次完整验证结果判断”的回归测试。平台能够积累经验的前提，是它也必须接受自己的误判并修正规则。
这正符合 Opsx 的 Self-Evolving 含义：不是默认任何模型都正确，而是让 Asset、Issue、Execution、Git 和最终验收共同构成可以被复核的事实，再将验证过的方法沉淀为下一次任务的起点。
在 AI 时代，研发节奏应先服从真实问题
这次代码瘦身并不只是一次工程效率实践，也影响了我对产品研发的判断。
当 LLM 与 Agent 的能力快速变化时，花数月进行重型设计、完成大量功能后才验证市场，风险正在变得更高：需求可能并不存在，用户可能不愿切换，或者原本计划自行实现的能力已经被更通用的模型和工具吸收。技术债、沉没成本和团队叙事又会使人更难及时停止。
我更认同一种克制的节奏：从一个确定、正在发生的真实问题出发，先让方案存在，再持续把它做好——Make it exist first. Make it good later. 这不是鼓励把未经验证的系统直接推向生产，而是要求把第一版的范围、验证方式、风险边界和退出条件同时设计出来。
图：SpaceX Raptor 引擎的快速迭代策略。从 Raptor 1 到 Raptor 3，每一版都在实际飞行中验证，而不是在实验室里追求完美后才测试。这与“Make it exist first. Make it good later”的理念一致：先让方案在真实环境中运行，再持续改进。
并非每个产品都必须从第一天开始追求外部市场。许多工具天然可以定位为个人使用或公司内部使用：只要解决一个高频、明确的效率问题，先实现足够可靠的核心能力就有价值。此时投入应保持有限，收益则体现在个人或团队每天节省的时间、减少的错误和更短的反馈周期；随着真实使用不断累积，工具也可以持续改进。等到有更多精力、使用经验和可验证价值后，再将产品构想、实现方法或代码分享出去，甚至选择开源。
对面向用户的产品，第一版应尽快接触真实使用者，并预先设置可量化的继续或停止条件。例如，团队可以在立项时定义：若产品在 100 天内无法达到约定的月活或付费验证目标，就停止继续投入，而不是用更多功能掩盖缺乏需求的事实。对 To B 产品而言，这个约束更直接：没有明确的最终客户、业务场景和验收人，就不应把大量研发资源投入到“可能有用”的功能清单中。
这也是 Opsx 必须与具体 LLM、Agent 解耦的原因。模型、IDE 形态和执行工具都会变化；真正值得长期保存的是资产身份、系统关系、Runtime 路由、Issue 证据、Git 历史、验收方法以及已经被验证的 Knowledge。今天由 Claude 完成的仓库分析、由 Codex 完成的测试环境修复，未来可以由另一种 Agent 接手；平台不应把自己的价值押在某个单一模型的能力曲线上。
从这个角度看，第一阶段 17,831 行代码的精简并不是终点。它验证的是一条更重要的路径：把 AI 的代码能力放进真实系统，让它能够在明确资产、Git 审计、测试环境和回退边界中持续交付；同时让每一次交付帮助团队更快验证问题、更快承认错误，也更快决定下一步是否值得继续投入。