AI 编程

过去做产品，我们反复讲先做 MVP，快速上线、快速验证、快速迭代。现在借助 AI，五分钟做出原型、半小时搭出一个看起来相当成熟的展示网页，已经不是什么值得惊讶的事情。一个人就能把过去需要团队配合的想法迅速变成可以运行的东西。 开发门槛降下来了，市场却没有因此变得好做。产品越来越多，用户越来越难打动；Demo 越来越容易，可靠交付、获客和商业化依然艰难。模型和工具还在不断换代，今天值得投入的能力，明天就可能成为模型或通用工具的基础功能。能把产品做出来，已经远远不够。 上一篇 Opsx 实践谈到，研发节奏应该先服从真实问题。这篇继续展开：独立开发者和小团队该怎么选市场、做产品，让用户用起来、愿意付费；什么值得长期积累，什么时候应该停，以及产品经理怎样在变化中保持探索、观察与敬畏。 产品已经过剩，客户不会因为你做出来了就买单 现在既是一个低欲望的时代，也是一个产品井喷、供给高度过剩的时代。客户的预算一再收缩，需求又不断被通用 AI 和大厂产品抢走。某项能力一旦成为已有工具的附带功能，客户就少了单独购买它的理由，留给新产品的付费空间越来越小。 用户的审美被大幅拉高，对新鲜事物的兴趣也在下降。漂亮界面、流畅 Demo，已经不够让人兴奋。除非做到 ChatGPT、《黑神话：悟空》这样的现象级产品，才有机会真正点燃用户，形成病毒式、爆炸性的自传播。日常用的应用还是那几个，手机里的 App 反而越来越少。AI、小程序已经能解决的事情，为什么还要专门安装一个 App？产品供给越来越多，用户愿意留给新产品的位置却越来越少。 大模型能力的进化速度又超乎想象，能做的事情越来越多，能力越来越强，AGI 看起来已经指日可待。今天还需要专门开发的能力，下一轮模型升级就可能直接具备。自己的开发成本降低了，竞争者的成本也降低了，产品赖以成立的前提正在快速变化。 OpenClaw 这种现象级产品，也基本就火了三个月，后来的 Hermes 也是，腾讯“龙虾”QClaw 也宣布将停止运营。新产品不断涌现，注意力很快就转向下一轮。我相信绝大多数产品经理都不会觉得自己能做出一个比 OpenClaw 更现象级的产品。连这样的产品都不能一直占据注意力，凭什么觉得闭门打磨几个月，市场就会等着自己？ 没有充分的产品调研，没有能够接触、服务并建立信任的客户资源，只凭想法投入商业研发，大概率会失败。 至少要知道第一批用户在哪里，能不能约到，愿不愿意让你进入真实场景验证。 找到用户，还要看他们愿不愿意付费。国内个人 IT 市场有两个直接障碍：付费意愿极低，技术用户又总想自己手搓一个。免费工具、开源方案和已有订阅已经够多，AI 又让自己动手更容易。我们用 AI 提高研发效率，客户也会用 AI 降低对我们的依赖。对独立开发者和小团队来说，不要做国内个人 IT 付费市场，尤其是面向技术用户的通用效率工具。 放到面向个人用户的商业产品市场，能看到的成功路径也主要集中在游戏、娱乐、色情这三个赛道，其他赛道基本看不到清晰的成功路径。连曾经兴起的知识付费都越来越撑不下去了：用户能直接问 AI，为什么还要为一份整理好的答案和资料买单？ 国内 To B，也不要轻易做纯软件。 除非有很强的垄断地位、技术壁垒，或者融合了众多行业属性、指标和流程的垂直业务场景，否则很难靠一款软件打开市场。 在这类客户心里，看不见的软件往往就意味着没什么技术含量，短时间可以复制一份。尤其有了 AI，自己招研发就能做，还美其名曰“自主可控”。但持续维护、处理故障、适应业务变化的责任并没有消失，拿到源码也只是换了一种方式承担成本。 如果市场真有潜力，大厂也会下场直接做。国外更常见通过收购补齐产品，国内小团队却很难等来这样的结局，反而要直接面对大厂的客户、渠道和产品组合。不要把“做起来以后等收购”当成退路。 纯软件最后往往变成定制化开发服务，甚至卖源码。卖出一份软件，和获得一个定制开发项目，是两种不同的生意。 接项目就按项目成本和交付能力算账，不能套用软件低成本复制的预期。把投入放在能接触到的垂直业务上，将行业积累转化为客户看得见、愿意购买的结果。 少替用户想象，尽快让真实问题检验产品 只有乐观主义才会驱动人做出好产品。但市场没有义务奖励这种相信。 产品经理很容易爱上自己规划的系统：看板、知识库、协作、社区，每个模块都讲得通，却说不清客户为什么需要，或者为什么要选自己的产品。AI 又让“顺便做一下”格外容易，功能越积越多，产品越来越重。产品越做越完整，客户选择它的理由却未必增加。 需求讨论应该往回追问：谁遇到了什么问题？现在怎么处理？最麻烦的一步在哪里？客户说想要一个看板，可能只是每天不知道哪些订单需要处理，未必需要一整套可视化系统。需求必须追溯到真实问题，开发者觉得不错、客户随口说想要，都不能免检。 用户有需求，和用户会选择你的产品，是两回事。 立项前要把竞争推演一遍：客户现在用什么，有哪些竞品和开源项目，为什么要换成你的？优势在哪里，有没有技术壁垒？大厂如果抄过去、整合进现有产品，还剩什么竞争力？下一代更强的 LLM，会不会直接覆盖这项能力？ 同时算清楚，做到能交付需要多久、多少人、多少钱，后续维护和服务还要投入多少。等产品做出来，今天看到的机会还在不在？这些问题要在投入前列出依据和待验证的假设，不能靠一句“用户确实有需求”就跳过。 实现之前，先看哪些能力已经有了。小团队不要再造轮子。操作系统、数据库、IDE，甚至通用 Agent，都不要轻易碰。 Claude Code、Codex、OpenCode、DeepSeek Harness（DSH）已经提供了优秀的 Agent 能力，直接用起来，围绕客户场景组合和扩展。能做出相似的 Demo，不代表能长期追上它们的研发、维护和生态投入，别把商业项目变成底层技术练习。 不要轻易把优秀开源产品改头换面，包装成自己的商业产品。改个界面、加几个功能，不会自动产生付费价值，却可能背上跟进上游、维护分支和独立交付的负担。把精力放在行业场景、系统接入和实际交付上，别把拥有一份自己的代码当成竞争力。 确实需要自己开发的部分，尽可能提供原子功能，内部保持能力可组合，按场景组织数据读取、分析、生成和执行。搭好框架，让用户能够自己配置模型、权限和工作流，别把产品经理自认为不错的整套模块强加给客户。轻量化在当下尤其重要，需求应该随着真实问题生长。 Make it exist first. Make it good later. 尽快做一版，放进真实场景，验证客户是否愿意用它解决问题。第一版就要明确任务、完成标准和风险边界；企业产品还要找到具体使用者和验收人，不能把愿意听介绍当成愿意使用，更不能当成愿意购买。 ...

在上一篇代码瘦身实践中，我把 Opsx 参与代码工作的范围分成了几个层次：修复 Bug、调整小功能、跨模块改造，以及更进一步的新模块研发。当时，前三类已有实践支撑；对于新模块，我仍然认为需要人的业务判断、更强的 Agent，以及贯穿实施过程的审核和验证。 需求来自我一直维护的数据库服务。此前，数据库巡检长期只有 Oracle 一种，近期才上线基于 Skill + LLM 的 MySQL 巡检，PostgreSQL 仍是待补齐的一环。AWR 报告分析虽然已有入口，背后却还是一套较早开发、依赖固定规则的 Java 程序，也缺少报告对比分析能力。我希望逐步完善数据库巡检的覆盖范围，同时更新已有的性能分析方式。 这些能力通过两个入口提供：墨天轮面向数据库社区用户，MES 仅供内部员工使用。两者服务的人群不同，但可以复用底层分析能力，让用户沿用离线采集、上传分析、查看报告的方式获得新服务，同时保留已有 Oracle 巡检和历史报告。 这一次，我开始用 Opsx 与 Codex 协作推进这项改造：将原来专用于 MySQL 巡检的服务抽象为通用 Skill Service，先实现 PostgreSQL 巡检，再利用这套基础快速完成 AWR 分析重构，并上线 AWR 报告对比分析。它需要同时处理前后端交互、分析服务、数据库记录与测试部署，改动范围涉及五个源码仓库。 这次研发没有要求我在本机搭建这五个仓库对应的开发环境，也无需在本地安装业务依赖、编译和部署各项服务。前后端与分析服务涉及不同的技术栈，如果都在本机运行，需要准备相应的工具链、服务配置与计算资源，还要维护它们之间的连接。Opsx 让 Agent 直接使用已接入的远程研发和测试环境，省去了在个人电脑上重建整套环境的负担，也不必同时打开多个 IDE 来组织这次跨仓库改造。 我通过 Opsx Issue 和 Codex 提出要求、审核方案、查看运行结果，再根据实际使用继续调整。源码阅读与修改、数据库查询、构建、部署和测试，由 Agent 通过已接入的工具与环境完成；产品范围和最终验收仍由我判断。 这些能力已经具有独立工具产品的完整形态。PostgreSQL 巡检需要连接采集工具、数据库与主机检查、上传解析、异步分析和报告管理；AWR 分析需要从复杂报告中提取性能证据，形成诊断建议；AWR 报告对比分析则进一步判断同一数据库在不同时段的变化。每项都可以作为独立的产品方向，本次将它们整合进已有业务，并共享用户体系与服务基础。 对 Opsx 而言，这是一次新的里程碑：此前接入的资产、源码和执行环境，已经能够支撑具有独立产品形态的能力从设计走向上线。 研发过程中需要触达的主要节点——前后端仓库、数据库、测试主机、构建工具、部署服务、日志与文件存储——基本贯通，Agent 可以在明确目标和授权范围内连续推进设计、编码、构建、部署、测试与修复。人的判断集中在产品取舍与验收，不必逐个环节代为操作。 将 MySQL 巡检服务抽象为通用 Skill Service Bethune Workspace 中的 issue_205 最初提出的需求，是分析服务器上已有 MySQL 巡检的逻辑和流程。在此基础上，我希望将其中可复用的执行机制抽离出来，使服务能够承载不同 Skill，而不再围绕单一数据库类型组织。 ...

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 从“生成代码片段”进化为“完成可验证的交付”： ...