AI Native研发组织变革路线图：角色、流程与工程体系重构
作者：吴穹博士
最近一次公开演讲，我分享了我们用AI重构研发管理产品Kanban2的实践。现场的题目里有一句“日产万行业务代码”，但走过这段过程，我越来越关心的是：当代码生成已经很快，组织能不能接得住？本文从角色责任、研发流程和工程体系三个层面，梳理从个人提效走向组织进化的实践路线。
一、每个人都变快了，为什么大家反而更累？
这段时间，与企业交流AI研发实践，经常听到一种相似的感受：产品经理写需求更快了，开发人员写代码更快了，测试人员生成用例也更快了。可到了管理者那里，感受到的往往是工具和Token账单增加，需求交付却没有同样明显的变化。
更微妙的是，每个人都觉得自己提效了，也觉得周围的人拖慢了自己。
以前，产品经理交来五页文档；现在，AI可以帮他写出五十页。开发人员看不过来，又让AI生成十页评审意见。双方都增加了产出，沟通成本也一起增加。旧流程中原本就存在的澄清、等待、交接和验证，没有因为代码生成变快而自动消失。
我在演讲中借用了布朗运动作类比：每个粒子都运动得更剧烈，并不意味着整体正在朝目标前进。组织需要共同目标，也需要能够把个体能力汇聚到客户价值上的工作方式。
所以，判断AI有没有带来组织收益，要回到真实交付：需求从提出到可用用了多久？交付结果是否可靠？用户是否采用？团队为修复和维护付出了多少成本？
代码生成速度只是其中一个环节。新的生产力，正在要求我们重新设计组织、角色、流程和工程底座。
二、岗位边界松动了，结果责任要更完整
过去，一个人往往擅长一个技术领域，其他领域必须依靠同事配合。Agent扩大了个人能够行动的范围：理解业务的人可以做出原型，后端工程师可以修改前端，体验设计者也可以直接改善真实产品。
专业判断仍然重要，但许多曾经必须通过岗位交接完成的工作，现在可以由一个人借助Agent推进到可验证结果。继续沿用原来的边界，就会留下大量等待和翻译。
因此，我们提出围绕产品成果重新划分五类结果责任。
**Prototyper，产品原型师。**判断什么值得做，构造可运行的原型，尽早验证价值和范围。
**Productizer，产品化工程师。**把原型变成可靠产品，对实现、测试、修复与运行质量形成完整责任。
**Challenger，质量挑战者。**从独立视角挑战边界、异常与风险，寻找构建者容易遗漏的问题。
**Beautifier，体验精修师。**进入真实产品，直接改善界面、交互、可用性和体验细节。
**Grower，增长运营师。**关注用户采用、持续使用和价值兑现，把真实反馈带回产品演进。
这五类责任可以由不同的人承担，也可能由同一个人兼任。我们当前的六人团队，实际配置是一个Prototyper、四个Productizer和一个Beautifier，并没有机械地为每类责任设置一个岗位。
在更大的组织里，小队还需要产品和平台支持。深入业务现场的FDE小队负责验证场景，产品团队沉淀可复用能力，基础设施团队提供模型、数据、环境和交付底座。小队能够独立行动，背后依赖的是共享能力的成熟。
三、从“交出一份文档”，到“完成一个工作闭环”
角色变化之后，工作流程也要跟着变。
传统研发流程强调逐段交接：需求、设计、开发、测试、部署。我们在实践中更强调一个人与Agent围绕目标持续工作：提出想法，讨论计划，构建与测试，验收，部署，再观察使用结果。
计划环节仍然重要。需要明确目标、范围、约束、方案和验收标准，也可以让另一个模型评审计划。实现过程中，Agent持续获得测试反馈；确认功能符合预期后，再补齐与实际交付一致的需求记录和使用说明。
这不意味着需求和设计可以省略。它要求这些内容在恰当的时机形成，并且随着产品变化保持一致，真正成为后续工作能够使用的资产。
不同角色都可以发起这样的闭环。产品原型师发现价值机会，就构造并验证；产品化工程师看到日志报错，就定位、修复并回归；体验精修师发现操作不顺，就修改界面并在真实页面里验证。
团队协作也随之变化：大家围绕同一个产品、同一个系统智能体和共享资产协同，减少在中间产物上的反复交接。每日对齐仍有价值，重点是当前目标、冲突和需要共同判断的问题。
当Agent承担更多执行工作，人对目标、取舍和质量结果的责任也要更加完整。
四、六人团队重构Kanban2：产出之外，更要看验证
Kanban2来自我们长期服务研发组织的经验。金融客户的管理方式存在大量细微差异，我们希望通过本体、配置和产品能力承接这些差异，减少长期依靠定制开发的负担。
AI让我们有机会重新推进这套产品。按V45 PPT记录，2026年5月31日至10月23日，同口径统计的仓库存量文本由约39.9万行增长到377.3万行。其中，业务代码约163万行，测试与CLI约145.4万行，文档约68.9万行。
这些数字展示了一个小团队能够推进的工作规模，但不能直接换算成效能提升倍数，更不能等同于原创贡献和客户价值。原型构建、产品精修、客户支持的任务不同，代码产出也会不同。
“日产万行”同样需要说明口径。PPT记录的2026年7月21日工作切面中，我有52次提交，业务代码净增12,819行，该项统计包含测试。它是一日工作样本，不能当作每天稳定交付同等规模功能的承诺。
比代码量更值得关注的，是这些变化有没有被验证。
按PPT中2026年10月25日登记的结果，Java业务合计行覆盖率为74.18%，Rust图数据库产品子集为67.56%。前端行覆盖率尚未采集，Java driver覆盖率仍待加强；不同范围不能直接合并成一个全栈覆盖率。
覆盖率也只是一个观察维度。我们更关心的是：每次改动之后，能否快速得到可信反馈；出现问题时，Agent能否找到证据、修复并重新验证。
五、九步Harness建设：给Agent一套能工作的环境
很多团队希望找到一个更强的Agent，解决研发中的全部问题。但如果系统无法操作、测试数据不稳定、日志读不到、环境需要人工反复启动，Agent就会不断停下来等人。
我们把支撑Agent行动、观察、验证和修复的工程底座称为Harness。它需要随着真实任务逐步建设。演讲中，我将这段实践归纳为九步。
第一步，构建CLI，让系统能够被稳定操作。
把系统能力暴露为明确的命令、参数和执行结果。Agent可以调用和组合，自动化测试也能使用同一入口完成造数、操作与核查。界面验收依然需要，但大量重复操作可以先通过可编程入口完成。
第二步，建设稳定的测试数据。
环境启动了却没有可信数据，很多业务就无法验证。我们通过CLI逐步造数，也用OrgSpec描述目标组织、模型和数据，再由初始化引擎构造场景。稳定、可重复的初始状态，让失败更容易复现和定位。
第三步，让分层测试成为Agent的反馈系统。
前端检查、后端单元与集成测试、图数据库测试、CLI测试和真实Gateway上的API测试，各自负责不同范围。失败报告要说明哪一层、哪个用例出了什么问题，让Agent能够据此继续行动。
这张报告值得保留，因为它展示了真实失败。测试体系需要准确暴露问题，失败被重试掩盖以后，后续判断就失去了依据。
第四步，让运行环境可以被观测。
Agent需要读取日志、截图和trace，关联服务、时间、请求路径与代码。我们尝试让智能体定时巡检，聚合异常，给出带证据的缺陷线索，减少人来回搬运日志和解释背景。
第五步，把环境与流水线变成可执行能力。
启动、停止、重启、依赖检查和构建验证，都需要明确入口。按改动重启受影响服务，检查端口与健康状态，用锁控制并发，减少多个Agent互相影响。独立任务还需要相应的环境和数据隔离。
第六步，在真实界面中完成验收。
接口返回成功之后，还需要确认用户看见的页面、操作和反馈是否正确。开发智能体应验收自己的工作，独立探索测试智能体再挑战遗漏与边界。两者都需要明确场景、操作路径、预期结果和复现证据。
第七步，让上下文随系统一起版本化。
需求、设计、实现、测试案例、部署脚本和运行知识需要相互关联。我们沿用Everything as Code的思路，让这些资产进入同一条可追溯的变更链。下一次Agent开始工作时，能够找到当前有效的约束和决策。
第八步，把成熟做法封装成系统专属技能。
每个系统的架构、业务规则和验证方式都不同，需要维护自己的AGENTS.md、Skills与项目知识。通用Agent提供基础能力，系统资产帮助它在具体产品里可靠工作。
第九步，持续优化，及时处理技术债。
测试需要稳定，也需要足够快，才能支撑高频迭代。每次失败都应推动改进：修复不稳定的数据与环境依赖，优化慢步骤，把重复踩到的问题写回规则和测试。重复、耦合与边界混乱也要及时重构，避免继续放大。
九步建设最终形成一个循环：Agent执行任务，环境给出反馈，团队修复问题，再把经验沉淀成下一次工作的默认能力。
六、从一个真实产品开始，让组织接住AI收益
把这次实践放回组织层面，会看到几件事需要一起发生。
角色围绕结果承担责任，个人与Agent形成完整工作闭环，团队共享系统知识与工程资产，平台让操作、验证和运行反馈变得可复用。哪一部分长期缺失，其他部分都会付出额外成本。
与此同时，应用、数据与Agent还需要各自合适的研发工艺。业务功能要验证正确性、性能和安全，数据要保证可信与新鲜，Agent行为则需要任务评测、边界约束和失败恢复。这些能力共同交付，最后仍要回到业务结果验证。
对正在推进AI转型的团队，我更建议从一个真实产品、一个明确目标和一支小队开始：让他们把一项改动从想法推进到上线后的可验证结果，记录在哪些地方反复停下来等人，再逐项补齐系统能力。
这个过程积累的CLI、数据、测试、文档和Skills，会成为后续任务的起点。组织收益也应该用交付周期、质量、用户采用和维护成本来持续检验。
走过这几个月，我最深的体会是：**代码生成越容易，组织就越需要有能力判断、验证和承接这些变化。**这也是我们继续探索AI Native组织的出发点。
本文根据吴穹博士近期公开演讲整理，配图选自《AI Native组织》V45版演讲PPT。实践数据采用该版本标注的日期与统计范围。