像我这样的软件开发型OPC（由一个人承接软件定制开发、负责客户沟通与项目交付的一人公司），越来越在意一件事就是：项目接下来了，利润能不能留下来。
客户愿意谈，需求也有价值，但需求沟通、设计开发、测试上线、后续维护，每个环节都要自己盯。报价确定后，多一轮返工、多几次修改，都在消耗原本预留的利润。
一次CRM开发项目，让我重新思考了一个人能承担多大交付范围的问题。这次，我把Brookley引入交付流程，从需求梳理、首版上线到后续迭代，尝试用它完成一套客户管理系统。
项目走下来，我的答案是：在范围清晰、能够分阶段交付、客户愿意参与反馈的项目中，一个人确实可以借助AI承担更完整的交付。 但要把效率变成利润，需求、验收和变更这几件事，仍然要自己管好。
项目能做，难在一个人如何兼顾全程
客户的需求听起来很直接：把散落在表格和聊天记录里的客户资料集中起来，让销售及时记录跟进情况，负责人随时查看业务进展。
可一旦进入实施，问题就具体了：客户由谁录入、分配给谁、销售能看哪些资料、人员调整后历史记录怎么处理？每一项都关系到系统能不能真正投入使用。
找外协，需要分出预算，也增加了沟通协调工作；全部自己做，开发一忙起来，获客和商务沟通就得往后排。一人公司的交付成本，还包括被项目占用之后，没时间处理的其他业务。
我选择引入的Brookley，是百溪科技自主研发的下一代企业级软件交付智能体（Delivery Agent），通过AI Agent与软件工程深度融合，将自然语言业务需求转化为可运行、可持续迭代的企业级软件及Agent应用。它覆盖从需求提炼、设计开发到测试部署和持续迭代的完整交付流程，能够为像我这样的软件开发型OPC提供交付能力支持。
针对这次项目，我最想验证的是：它能否帮助我减少具体开发工作的投入，让我有精力把需求和交付质量管住。
第一阶段：先把需求问透，减少后面的返工
客户最初说：“销售能录客户，老板能看进度就行。”
这句话表达了目标，却还不足以指导开发。销售能不能看别人的客户？两个人录入同一家企业怎么办？客户转交之后，历史跟进记录是否保留？
过去，这些问题容易边做边补。等页面搭好，才发现权限逻辑需要调整，已经完成的工作就可能重来。
这次，我先把业务流程和初步想法交给Brookley，借助Requirement-Lab梳理需求，再将需要客户拍板的问题带回去确认。首期范围最终收在四件事：录入客户、指定负责人、记录跟进、查看进度。销售查看自己负责的客户，管理者查看全部客户，转交操作由管理者完成。
同时，我写清楚了暂时不做的功能，避免客户把“以后可能需要”理解成“这次已经包含”。
对固定报价的项目而言，需求阶段多确认一个关键规则，就可能减少后面一轮返工。AI可以辅助梳理问题，但范围必须由我和客户共同确认，后续开发才有明确依据。
第二阶段：先跑通核心流程，再讨论使用细节
需求确认后，我把首版重点放在一条完整流程上：新客户录入系统，分配给销售，销售填写跟进记录，负责人查看进展。
Brookley参与设计、开发和部署，我负责检查结果是否符合已经确认的业务规则。首版可以运行后，我让客户使用测试数据走一遍：录入是否顺手，销售看到的范围是否正确，负责人能否找到最近一次跟进记录。
这一步让沟通具体了很多。原来需要反复口头解释的地方，现在可以直接点开讨论；客户确认的流程，也能逐项记入验收清单。
不过，系统能打开、页面能操作，只是验收的起点。我仍然检查权限、异常输入和数据保存，确认它在实际操作中是否按规则运行。
我的工作重心也随之改变：更多精力用于判断业务是否正确、客户是否会用，以及交付结果是否达到约定。Brookley承担部分实施工作，我则对最终交付负责。
第三阶段：管住变更，让后续迭代有账可算
CRM试用后，客户提出一个新需求：销售人员调整时，希望批量转交客户资料，逐条操作太慢。
界面上看似只增加一个按钮，背后却涉及操作权限、客户归属和历史记录。如果没有先明确规则，很容易改完一个地方，又带出其他问题。
我先确认变更范围：谁有权批量转交、可以转交给谁、原有跟进记录如何保留，再交给Brookley，通过Base＋Delta在已有系统上继续迭代。
修改完成后，我重点检查：选中的客户是否全部转交，未选中的客户是否被误改，历史记录是否完整，普通销售能否越权操作。客户确认后，这项变更才算完成。
对以接单软件开发为业务的一人公司来说，在现有系统上持续迭代，意味着交付后还能承接客户的系统升级与功能扩展需求。但修改更方便，也更需要把新增需求的费用和时间提前说清楚。
迭代能力决定能否持续服务，变更管理决定这份服务能否持续盈利。 如果所有新增需求都被算进免费售后，前期节省的时间，仍可能在后续维护中被消耗掉。
“单兵成军”之后，还要算清利润账
这次CRM项目让我看到，Brookley能够扩展一个人的交付能力，让我把更多时间放在需求判断、客户沟通和质量验收上。但交付效率提高多少、利润增加多少，需要完整记录成本才能回答。
核算时，工具、部署、外协、维护，以及自己的工时，都应计入投入。还可以持续记录需求确认时长、返工次数、交付周期和维护响应时间，判断节省的投入是否超过新增支出。
项目选择同样重要。对于范围清楚、能分阶段验收的企业管理系统，可以从核心流程开始验证；涉及超大型、高并发或金融核心账务等场景，则需要另行开展专业评估。
所以，AI时代，做软件开发型的OPC能不能“单点成军”？亲测Brookley之后，我的答案是YES——前提是把项目选好，把规则讲清，把验收做实。
如果你也在承接CRM、审批流或其他企业定制项目，可以先拿一项真实需求，跑通“需求确认—首版交付—反馈迭代”的完整过程，同时记下投入的时间和费用。当一个人既能完成交付，又能守住质量与利润，“单兵成军”才真正成为一门可持续的生意。
